Short Range Radio Based Ad-hoc Networking:
`Performance and Properties
`
`Per Johansson
`Ericsson Radio Systems AB,
`S-126 25 STOCKHOLM, Sweden
`Phone: +46 8 719 02 90
`E-mail: Per.Johansson @ericsson.com
`
`Niklas Johansson, Ulf Korner
`Department of Communication Systems
`Lund Institute of Technology
`Box 118, S-221 00 LUND, Sweden
`Phone: +46 46 222 33 19,
`+46462229007
`E-mail: niklasj,ulfk@ tts.lth.se
`
`Johannes Elg, Goran Svennaqs
`Ericsson Mobile Communications A13
`S-221 83 LUND, Sweden
`Phone: +46 46 19 35 02
`+4646193449
`E-mail: johannes.elg@ecs.ericsson.sc:,
`GoranSvennarp @ecs.ericsson.se
`
`Abstract - The current research and development of short range
`radio technologies will provide new means to implement ad-hoc
`networking between cellular phones, notebook computers, and
`small, low powered devices such as electronic calendars. An indus-
`try consortium has recently released preliminary specifications
`for a short range radio technology named Bluetooth. The Blue-
`a transmission power in the range of -30 - 20 dBm. The Bluetooth
`tooth radio operates in the unlicensed ISM band at 2.4 GHz with
`radio nodes form ad-hoc networks called piconets, each of which
`offers a gross bit rate of 1 Mbps and allows a mix of voice and data
`communication channels. This study presents a number of differ-
`ent network usage cases for Bluetooth ad-hoc piconets and a sub-
`set of these scenarios is further analysed by means of simulations.
`A mix of data traffic and voice traffic is used in the simulations,
`where the data traffic streams are modelled with IBP processes. A
`worst case laptop conference scenario is simulated to stress the ro-
`bustness of the Bluetooth system under very high load and bursty
`traffic conditions. Moreover, simulations are also made with
`measured voice traffic to study a mixture of bursty data and voice
`packet traffic.
`
`I. INTRODUCTION
`Recently, much attention have been brought to research and
`development of mobile ad-hoc networks. Traditionally, ad-hoc
`packet radio networks have mainly concerned military applica-
`tions, where a decentralized network configuration is an advan-
`tage or even a necessity. Networks using an ad-hoc configura-
`tion concept can be used in a large collection of military appli-
`cations, ranging from interconnected wireless access points to
`networks of wireless devices carried by individuals. The latter
`is often referred to as a Personal Area Network, PAN, and could
`consist of a digital map, body-sensors, voice communication
`etc. Combinations of wide range and short range ad-hoc net-
`works seek to provide a robust, global coverage, also during se-
`vere operating conditions.
`For the commercial sector, equipment for wireless, mobile
`computing has not been available at a prize affordable for any
`larger market. However, as the capacity of common mobile
`computers is steadily increasing, the need for wireless net-
`working is expected to do likewise. Moreover, a person that
`daily uses various mobile devices, e.g. a cellular phone with
`
`headset and a Personal Data Assistant (PDA), would awid the
`tedious work related with cables, if wireless links were lgplied
`between hisher devices. Such a scenario has several si rnilari-
`ties to the PAN in the military environment.
`The Piconet research project at Olivetti and Oracle Research
`Laboratory (ORL) [3] is an example of a network concept
`based on a low-powered and short-range radio technology, typ-
`ically required for PANs. The need for a flexible and generic
`protocol architecture is also identified. However, radio technol-
`ogy used for the test-bed provides only a 9.6 kbps comrrunica-
`tion link, which is insufficient to support, for instance, a head-
`set-to-cellular-phone connection.
`The current alternatives for commercial mobile computing
`basically extend to wireless local area networks, WLANs (e.g.
`IEEE 802.1 1 [SI), for the office and campus area and cellular
`based access for the wide area (GSM, CDPD). In the near fu-
`ture, the General Packet Radio Service, GPRS [2], is expected
`to bring higher data rates to the wide area than today (in the or-
`der of hundreds of kbps instead of tens of kbps). Still, these al-
`ternatives represent a centralized networking concept that gen-
`erally forces closely adjacent nodes to use a network access
`point to exchange information, instead of communicating di-
`rectly. There do, however, exist WLAN products based on the
`IEEE 802.1 1 standard, that support ad-hoc communication.
`For PANs, two techniques, and potential standards, can be
`distinguished in particular:
`The Shared Wireless Access Protocol, SWAP [4], w nich is
`a protocol that, in short, combines parts of IEEE 802.1 1
`and DECT for cable replacement in the home environ-
`ment.
`A technology under name Bluetooth [l], focuses O,I very
`low cost cable replacement implemented in cellular
`phones, laptop computers etc.
`Even though an overlap between the two efforts can b: iden-
`tified, Bluetooth specifically aims for the business scgment
`(mobile office) environment, while SWAP is more intended for
`interconnecting consumer electronics in the home eiiviron-
`ment. For voice services in particular, SWAP requires the sup-
`port of a base station (a Connection Point), while Bluetooth op-
`
`0-7803-5284-X/99/$10.00 Q 1999 IEEE.
`
`1414
`
`IPR2020-00910
`Garmin, et al. EX1036 Page 1
`
`

`

`erates in an ad-hoc fashion also for these services. ?;his paper
`focuses on a preliminary analysis of an ad-hoc network based
`on the Bluetooth system, only.
`Since the Internet Protocol (IP) is the global network proto-
`col for data communications of today and is an emerging pro-
`tocol also for telecommunications, many ad-hoc network im-
`plementations could be expected to use IP to achieve global
`connectivity. Along this line, the Internet Engineering Task
`Force (IETF) Mobile Ad-hoc Internet working group, Manet
`[7,8], is designated to specify one, or several, routing protocols
`for ad-hoc IP networks. Even though the work presented herein
`focuses on the link and media access related functionality, a
`strong dependency exist between the network routing protocol
`and link layer functions (e.g. link status sensing, link reliability,
`and adjacent node discovery, discussed in [6]). This kind of
`mechanisms may be provided by the link and physical layer of
`the Bluetooth system, especially in “thin”, low-powered units,
`and offered to upper protocol layers.
`The paper is organized as follows. In Section I1 a system de-
`scription of the Bluetooth protocol is given. In Section I11 a net-
`work scenario and a sequence of usage cases are described. In
`Section IV a simulation study of some of the described usage
`cases is presented. Conclusions of the presented work and
`plans for further studies are given in Section V and Section VI,
`respectively.
`
`11. SYSTEM DESCRIPTION
`The Bluetooth radio uses a fast frequency hopping scheme
`and short data packets to make the link robust in a noisy radio
`environment. In addition, the use of Forward Error Correction
`(FEC) limits the impact of random noise. The physical commu-
`nication range will be in the interval 10 cm to 10 m, but can be
`extended to above 100 m. A Gaussian-shaped Frequency Shift
`Keying (GFSK) modulation is applied to minimize transceiver
`complexity and the system gives a gross data rate of IMbps.
`The transceiver power will be in the range -30 dBm to 20 dBm
`with a nominal value of 0 dBm. Furthermore, Bluetooth uses a
`slotted Time-Division Duplex (TDD) scheme for full-duplex
`transmission, where each slot is 0.625 ms long (two slots form
`one frame).
`The Bluetooth baseband protocol is a combination of circuit
`switching and packet switching, where time slots can be re-
`served for packets carrying synchronous information (Synchro-
`nous Connection Oriented, SCO, voice link) or dynamically al-
`located for asynchronous information (Asynchronous Connec-
`tionless, ACL, data link).
`Fig. 1 illustrates how the slotted channel can be used for dif-
`ferent combinations of SCO and ACL links. A SCO link will
`always be symmetrical, i.e. a down-link slot is followed by one
`up-link slot. An ACL link, however, can convey packets that
`covers several, continuous slots, either symmetric or asymmet-
`ric. Based on the SCO/ACL structure the system supports one
`to three 64 kbps synchronous channel(s), carrying 1.25 ms, 2.5
`ms, or 3.75 ms worth of speech per packet. The ACL link offers
`
`a maximum 721 kbps in one direction while permitting 57.6
`kbps in the return direction, or a 432.6 kbps symmetric link.
`However, voice cannot be carried simultaneously for this case
`(alternative 4 in Fig. 1).
`
`Fig. 1. Bluetooth radio channel time slots showing SCO/ACL link com-
`binations.
`
`Fig. 2. A scatternet formed by three joined piconets.
`A. Network topology
`A collection of devices connected via Bluetooth links in a
`star configuration is referred to as a piconet. A piconet starts
`with two connected devices, such as a portable PC and a cellu-
`lar phone, and may grow to eight active connected devices and
`several “parked” units (discussed below). All devices are peer
`units and have identical implementations. However, in a pi-
`conet, one unit will act as a master and the other@) as slave(s)
`for the duration of the piconet connection.
`Several piconets can be established and linked together in an
`ad-hoc fashion (as illustrated in Fig. 2), forming a scutremet in
`which each piconet is identified by a different frequency hop-
`ping sequence. All nodes participating in the same piconet are
`synchronized to this hopping sequence.
`B. Network nodes
`The master unit controls the link bandwidth by polling the
`slaves for any data to be exchanged and performs thus band-
`width allocation to each slave. However, SCO packets may be
`sent without previous polling. In order for the master to distin-
`guish between the slaves in a piconet, a 3-bit active member ad-
`dress (AM-ADDR) is assigned to each unit participating in the
`piconet.
`A unit may temporarily give up its AM-ADDR and enter a
`(parked) power save mode denoted PARK, while still being
`part of a piconet, i.e. still be synchronized with the master. This
`mode enables also a sharing of the AM-ADDR space. Further-
`more, a unit may also save power by entering any of the modes
`SNIFF or HOLD, in which the unit does not send or receive
`data during a specified number of slots.
`For ACL traffic, an unnumbered ARQ scheme is applied in
`which data transmitted in one slot is directly acknowledged by
`the recipient in the next slot.
`
`14 15
`
`IPR2020-00910
`Garmin, et al. EX1036 Page 2
`
`

`

`C. Authentication and Privacy
`Bluetooth provides user protection and information privacy
`mechanisms at the physical layer. Authentication is based on a
`challenge-response algorithm and connections may require a
`one-way, two-way, or no authentication. A stream cipher is
`used for encryption, with secret key lengths of 8 to 128 bits.
`
`HI. NETWORK SCENARIO AND USAGE CASES
`The network scenario dealt with henceforth comprises a
`number of indoor users (2 - 20 say), each carrying a set of user
`devices interconnected with Bluetooth radios. Each such set, or
`PAN, is assumed to accommodate a cellular phone, a laptop
`computer, and a headset capable of communicating with either
`the cellular phone or the laptop.
`Furthermore, each device in the scenario may be addressed
`through individual, dynamically configured IP addresses.
`However, small accessories, like a headset, will most likely not
`be associated with an IP address in the foreseeable future.
`In a sequence of events, the usage cases will be introduced
`into the network scenario. To simplify the presentation, only
`four PANS are used in the scenario.
`A. Initial state; four isolated piconets
`A PAN is assumed to be formed by creating a piconet of the
`Bluetooth devices that belong to one user and are powered on.
`In Fig. 3 this initial state is illustrated with four PAN piconets,
`i.e. there is no communication between the piconets. Within a
`piconet, however, synchronization of data between devices
`(e.g. between the cellular phone and the laptop) may take place.
`
`Fig. 3. Initial state: four isolated piconets
`
`\
`I
`/
`
`Fig. 4. The conference table scatternet.
`
`B. The conference table; communicating laptops
`The laptop intercommunication is established by ex€ anding
`the piconet, formed by PAN1, with slave entities in the other
`laptop computers (in PAN2 - PAN4). This expansion is per-
`formed by inviting the other laptops one by one as desci ibed in
`[ 11. Note that the other devices in PANl remain as slaves in the
`expanded piconet. Fig. 4 illustrates the conference tab e case.
`Since several piconets now are communicating, the entire net-
`work can be referred to as a scatternet. The solid lines denote
`where active communication takes place.
`C. The Internet bridge; IP telephony and web browsin,;
`The user in PAN2 decides to make an IP-telephony call using
`the headset, via the laptop, concurrently with the laptop confer-
`ence. A Bluetooth based WLAN, assumed present in the build-
`ing, is utilized as an access network to an IP-backbone net-
`work. The Bluetooth access points of the N A N are assumed
`to serve as either masters or slaves depending on the cornmuni-
`cation context.
`The remaining capacity for the laptop conference and lap-
`top-to-access point traffic will become limited in case Ibe lap-
`top operates as a slave, since time will be spent synchronizing
`between the different piconets (consumes one frame). Instead,
`the laptop (PAN2) is made master, which gives a better control
`of the link level activities running simultaneously in PAN2
`(laptop conference, headset, and access point). Note that the
`master of the laptop conference (PAN1) now has to initiate, and
`shift to, a slave entity in order to communicate with the laptop
`in PAN 2.
`The headset is a simple device that handles SCO lin <s only
`and in this case every third frame in PAN2 contains SCO link
`traffic (alternative 3 in Fig. 1). Discarding of “silent” SCO
`packets and voice compression are functions running in I he lap-
`top, which makes it worthwhile to utilize an ACL link to the
`WLAN access point to save bandwidth. This ACL link may
`also be shared by other traffic than voice.
`The following steps are run through to accommodate the IP-
`telephony call:
`1) The laptop (PAN2) invites the access point as a sla (e into
`the piconet of PAN2 (the headset is already there and the
`cellular phone remains in a power saving mode; Sh IFF or
`PARKED).
`2) The laptop (PAN2) resigns as slave in the laptop confer-
`ence.
`3)The laptop (PAN2) invites the laptop of PANl as a slave
`in the new piconet (the laptop in PANl now also runs one
`slave entity).
`Note that the conference table communication now covers
`two piconets.
`Incorporation of new nodes, withdrawal of already existing
`ones, and change of traffic loadtype may create an unbalanced
`distribution of the traffic in a scatternet, which will affect the
`performance of other nodes. The management of the resources
`in a scatternet in such cases is assumed to be handled by higher
`
`1416
`
`IPR2020-00910
`Garmin, et al. EX1036 Page 3
`
`

`

`layer protocols and lays outside the scope of this study.
`Bluetooth
`
`\ - / - \ <WLAN
`
`/
`/
`
`'
`
`burstiness in the simulations.
`
`I
`\
`\
`
`\.
`
`Fig. 5. The Internet bridge case: IP telephony via WLAN access and
`web browsing combined with a PSTN call using an GSMlGPRS access.
`The laptop conference is also still active, but covers two piconets.
`As a last usage case (not simulated), the user in PAN4 choos-
`es to use the cellular (GPRS) phone to access a website in a cor-
`porate intranet with his laptop. In addition, a GSM call is made
`in conjunction with the web browsing. For the web browsing
`part, the cellular phone remains as slave to the laptop in PAN4,
`but for the GSM call the headset is released from the laptop pi-
`conet and enters a new piconet with the cellular phone as mas-
`ter. Fig. 5 shows the resulting scatternet with its simultaneous
`communication cases. Symbols for the master (M) and slave
`(S) entities are attached to each link to clarify the distribution
`of these in the scatternet.
`
`IV. SIMULATIONS
`The current version of the Bluetooth simulator models an ar-
`bitrary number of units in one piconet. The model simulates
`discrete time with a time resolution of one time slot in the Blue-
`tooth system. Each unit (slave or master) has a packet generator
`for data traffic using ACL links, but can also reserve capacity
`for SCO links. The data packet generator is working according
`to an Interrupted Bernoulli Process (IBP), which enables bursty
`traffic characteristics.
`The number of users in the modelled network is relatively
`small and they are assumed to transfer either web-like data traf-
`fic or voice traffic between the nodes in the piconet. For the data
`traffic, this combination is expected to result in bursty traffic
`streams in the network. The voice traffic was simulated using a
`measured trace of real voice.
`In Fig. 6 a state diagram for the traffic generator is given,
`where p and q are the transition probabilities and h is the prob-
`ability for a packet generation in a slot. The latter is set to zero
`for the OFF state and one for the ON state. Furthermore, the
`time slots for all generators are aligned with the time slots in
`the modelled piconet. The squared coefficient of variation, C2,
`for the packet interarrival times were used as a measure of
`
`Fig. 6. IBP-process for the traffic generator.
`For the IBP process used herein, C2 is given below.
`c =
`2 q - p 9 - q 2
`(P + qI2
`Transmitted packets may be lost due to bit errors and is mod-
`elled with a constant loss probability. All lost ACL packets are
`resent according to the Bluetooth ARQ scheme. In all the sim-
`ulations presented herein, the packet loss probability was set to
`
`(1)
`
`2
`
`Two sets of simulations were carried out. First, the laptop
`conference from the conference table scenario above was sim-
`ulated, and secondly, the WLAN communication part of the In-
`ternet bridge case was simulated.
`D. Conference Table
`In the conference table simulation, eight laptops inter-com-
`municated in a single piconet. Data packets were sent slave-to-
`slave and master-to-slave according to a uniform distribution,
`where the traffic between slaves always passed through, and
`was controlled by, the master. The slave-to-slave down-link
`traffic was mixed with traffic originating from the master. The
`master served (polled) the slaves using a strict round robin
`(RR) scheduling principle and maintained a separate output
`queue per slave (see Fig. 7).
`A case using only single slot packets (27 bytes payload) was
`compared with one that allowed multiple slots per packet. (3 or
`5 slot packets with 180 and 338 bytes payload respectively).
`The single slot case gives a fixed capacity per slave, since one
`slot is always used to poll a slave even if it results in no data
`being sent. In the multi slot packet case, longer packets can be
`used to temporarily allocate more capacity to active nodes. In
`the simulations, a node simply sent as long packet as it had data
`to fill, i.e. a queue with 0 (poll response) to 179 bytes gave one
`or more ]-slot packet@), a queue with I80 to 337 bytes gave
`one or more 3-slot packet(s), and 338 or more queued bytes
`gave one or more 5-slot packet(s).
`
`"la"e.sla"~&gJ
`
`6
`
`,
`
`Fig. 7. Simulated model of the Conference Table case.
`
`1417
`
`IPR2020-00910
`Garmin, et al. EX1036 Page 4
`
`

`

`r
`
`50 45t
`301 f
`
`1
`
`40
`
`35
`
`Simulations were run at two different burstiness levels, de-
`noted “low” (p+q=l, C2 approximately 1 ) “high” (p+q=O.Ol,
`C2 in the interval [I 70, 2001). In Figs. 8 and 9 the mean packet
`delays are plotted for packets received at an arbitrary slave (low
`and high burstiness cases respectively) against the load. As
`could be expected, the delay increased dramatically for the
`high bursty traffic case due to the extended ON-periods of the
`IBP processes. In Fig. 10 the mean delays for the multi slot
`packet case is given for the high burstiness traffic. As can be
`seen, the delays are decreased dramatically thanks to a better
`capacity distribution during temporary overload situations in
`the slaves. The long queues in the slaves are drained out more
`efficiently if multi slot packets are allowed. This is clearly seen
`in Figs. 11 and 12 where part of the queue length trace of one
`slave queue at 25 percent load are plotted for the single slot and
`multi slot cases respectively.
`
`f
`
`f
`
`f
`
`
`
`0
`
`U 2
`
`0 4
`
`Laid
`Fig. 10. Average delay against load for the high burstiness case, with
`multi slot packets.
`
`06
`
`I_
`0 8
`
`H
`
`m
`
`2
`h 2
`
`350
`
`300
`
`Lold
`Average delay against load for the low burstiness case with sin-
`Fig. 8.
`gle slot packets.
`
`3wo
`
`3000
`
`2SM
`
`2000
`
`1500
`
`I000
`
`I
`
`f
`
`f
`
`t
`
`f
`
`
`
`Fig. 11. Trace of the queue length in a slave output queue for high
`bursty traffic and single slot packets (25% load, 7 slaves).
`
`500
`
`0.6
`0.8
`Lami
`Fig. 9. Average delay against load for the high burstiness case with
`single slot packets.
`
`Fig. 12. Trace of the queue length in a slave output queue for high
`bursty traffic and multi-slot packets (25% load, 7 slaves).
`To summarize, the laptop conference simulation showed that
`
`1418
`
`IPR2020-00910
`Garmin, et al. EX1036 Page 5
`
`

`

`the fixed and symmetric bandwidth allocation causes long de-
`lays for bursty traffic. The capability to allocate bandwidth
`more dynamically through multi-slot packets alleviates the sit-
`uation considerably for a bursty traffic case as shown by the
`simulations.
`E. The Internet Bridge
`In the Internet Bridge scenario, a mix of SCO traffic and
`ACL traffic was sent from the master (laptop) in PAN2. As stat-
`ed earlier, the headset was assumed to use every third frame for
`its SCO link (64 kbps) and the laptop (PAN2) then forwarded
`non-empty voice packets using an ACL link to the WAN ac-
`cess point, i.e. “silent” SCO packets did not generate any ACL
`packets. In addition, voice compression was assumed to be ap-
`plied on the traffic passing between the laptop and the W A N .
`The simulated model is depicted in Fig. 13, where also the
`frame distribution for the master node is illustrated for the two
`cases.
`Two sets of simulations were run. In the first (I), only every
`third frame was used for the conference data traffic, based on
`the assumption that the system used a strict round robin sched-
`uling and did not utilize any ACL frames left empty by the
`voice traffic.
`Access point ., .
`
`W A N
`
`&:PtP_p
`
`~
`
`~
`
`Fig. 13. Simulation model of the Internet Bridge usage case.
`These empty slots occur either due to the voice compression,
`or due to suppressed “silent” SCO packets.
`Secondly (11), the laptop conference was assumed inactive,
`and instead web traffic was sent on the ACL link whenever no
`voice traffic were present due to silence or voice compression.
`However, only single slot packets were simulated in this case
`even though 3-slot packet was possible (in case (I) single slot
`packets is the only alternative).
`To get a realistic measure of silent slots in the network, the
`voice packet traffic trace used in both cases above originated
`from a measured four minute conversation. The voice codec in
`the laptop was assumed to send two ACL packets, 224 bits
`each, with a 30 ms voice interval, which gave the resulting
`packet interarrival times shown in Fig. 14. The full voice data
`rate between the laptop and the access point was 14.9 kbps in
`both directions under these assumptions.
`In Fig. 15 the average packet delay is given for the data traf-
`fic from slave to master (PAN1 laptop to PAN2 laptop). The
`maximum available capacity in this case for one-slot packets
`(28 bytes payload) was 60 kbps in both directions, since no
`
`empty voice slots were utilized. Still, the average delay was ful-
`ly acceptable (around 150 ms) for 40 - 50 percent load for the
`bursty data stream (C2=50), which ran concurrently with the
`active IP telephony call. Note that the voice traffic for the IP
`call traverses the air interface twice.
`For the web traffic case (11), the same parameters for the
`packet generator as in case (I) were used, giving an actual load
`spanning from 2.8 to 50.8 percent for case (11).
`In this case, one ACL frame was always available for web
`traffic plus one additional frame when no voice packet was sent
`between the laptop (PAN2) and the AP. This gave a capacity of
`at least 100 kbps, which resulted in a decreased delay by ap-
`proximately one third (see Fig. 16) for the same input traffic.
`Thus, note that the load values are not the actual load in case
`(11), but refers to the load in case (I).
`
`2
`
`I5
`
`1
`
`0 5
`
`0
`
`0
`
`4aX)
`
`Mao
`Rcke1 nurnbcr
`Fig. 14. Voice packet inter arrival times of the input trace.
`Case (11) shows the potential gain in using a priority mecha-
`nism to select between real-time and non-realtime data over an
`ACL link. It would also have been possible (a third case) to
`resume the laptop conference and let it share the ACL band-
`width with the web session.
`
`12m
`
`0
`
`0 2
`
`0 4
`
`O b
`
`0 8
`
`1
`
`Load Ease (I)
`Fig. 15. Average packet delay for the data traffic when no empty slots
`are utilized.
`
`1419
`
`IPR2020-00910
`Garmin, et al. EX1036 Page 6
`
`

`

`tooth system.
`
`I
`
`- 1
`
`so c
`
`t
`
`I
`I
`
`20 ’
`
`0
`
`-
`
`0 2
`
`0 4
`
`0 6
`
`0 8
`
`I
`I
`
`Load car cn
`Fig. 16. Average packet delay for the data traffic when empty slots are
`utilized. Note that the load values are for case (I).
`V. CONCLUSIONS
`This study of the Bluetooth system gives a preliminary anal-
`ysis of the networking concepts proposed by the Bluetooth
`group. The network scenarios presented herein exemplify to
`some extent the versatility of a system based on a simple ad-
`hoc networking philosophy. Exchange and sharing of data con-
`currently with multi-hop voice traffic was shown possible also
`at high load and very bursty traffic.
`In the pure data exchange case (the laptop conference) the
`system exhibited a robust behaviour also for very bursty arrival
`streams. The simulated case showed that even with two radio
`hops and very bursty traffic (Cz = 200) the delays were in the
`order of hundreds of milliseconds for low to moderate load val-
`ues. The use of asymmetric links and multi-slot packets for the
`high burstiness case improved the delays significantly also dur-
`ing the severe load conditions. Furthermore, the simulated sce-
`nario was intended to test a worst case: a piconet with a maxi-
`mum number of active slaves, sending over two radio hops si-
`multaneously. In a real situation, the piconet could be broken
`into separate piconets to substantially increase the overall ca-
`pacity.
`The Internet bridge scenario showed upon one very attrac-
`tive property with the Bluetooth system: a good support for
`voice traffic. Obviously, the choice of relatively short packets
`and the use of a synchronous channel mode contributes to this
`characteristic. Nevertheless, the simulations of the Internet
`bridge case also indicates that web applications may very well
`operate concurrently with ongoing voice traffic.
`Conclusively, the Bluetooth system represents a very inter-
`esting approach to enable short distance connectivity. A mass-
`spread of Bluetooth implementations, or similar technologies,
`in consumer products opens up a wide arena for new short
`range networking applications, some not yet even thought of.
`At the same time, it is also a challenging task for developers
`and researchers to fully utilize, and further develop, the net-
`work functionality provided by technologies such as the Blue-
`
`VI. FURTHER WORK
`Future studies of the Bluetooth technology will analyse
`functions this preliminary work did not cover. In >particular
`piconet and scatternet formation principles,
`multicast performance, and
`support of different classes of service (QoS) through
`scheduling and priority mechanisms.
`Future versions of the simulator will use
`realistic input traffic (e.g. measured traffic), and
`model a shared radio channel to capture effects imposed
`by interfering piconets.
`Further studies will also investigate how the Blluetooth tech-
`nology will support a global IP networking for “thin” low-pow-
`ered devices.
`That activity may comprise topics such as
`IP addressing,
`ad-hoc routing protocols, and
`Mobile IP and scatternet interworking.
`
`REFERENCES
`The Bluetooth Special Interest Group, Documentation availabl: at
`http://www.bluetooth.codtechn/index.asp, February 1999.
`ETSI, “Digital cellular telecommunications system (Phase 2+); General
`Packet Radio Service (GPRS); Service description; Stage 2 (G!;M 03.60
`version 5.2.0)”, December 1997.
`Frazer Bennet e? al. “Piconet: Embedded Mobile Networking”, IEEE
`Personal Communications, October 1997.
`HomeRF, “Technical Summary of the SWAP Specification”, Documen-
`tation available at http://www.homerf.org/tech/, February 1995.
`IEEE 802.1 1 Standard, “Wireless LAN Medium Access Control (MAC)
`and Physical Layer (PHY) Specifications”, 1997.
`The IETF Manet WG, “An Internet MANET Encapsulation Protocol
`(IMEP) Specification”, Available at URL draft-ietf-manet-iriep-spec-
`Ol.txt, September 1998.
`The IETF Manet WG, “Manet Charter”, Available at UF:L http://
`www.ietf.org/html.charters/manet-charter.htm1,
`February 1995.
`The IETF Manet WG, “Mobile Ad-hoc Networking (MANET: : Routing
`Protocol Performance Issues and Evaluation Considerations”, Available
`http://www.ietf.org/intemet-drafts/dra~-ietf-~et-issues-
`at URL
`02.txt. February 1999.
`
`1420
`
`IPR2020-00910
`Garmin, et al. EX1036 Page 7
`
`