throbber
[ .......... Bluetooth: Vision, Goals, and Architecture ............. i Jaap Haartsen a Mahmoud Naghshineh b Jon Inouye c Jaap.Haartsen @ emn. ericsson.se mahmoud @ us.ibm, com Jon. W.Inouye @ intel, corn Olaf J. Joeressen d Warren Allen c Olaf Joeressen @ nmp. nokia, corn Warren.Allen @ tais. toshiba, corn Ericsson, Enschede, The Netherlands b IBM Watson Research Center, Hawthorne, NY, U.S.A. e Intel Corporation, Chandler, AZ, U.S.A. d Nokia Mobile Phones, Bochum, Germany e Toshiba Corporation, Irvine, CA, U.S.A. A few years ago it was recognized that the vision of a truly low-cost, low-power radio-based cable replacement was feasible. Such a ubiquitous link would provide the basis for portable devices to communicate together in an ad hoc fashion by creating personal area networks which have similar advantages to their office environment counterpart - the local area network (LAN). Bluetooth is an effort by a consortium of companies to design a royalty free technology specification enabling this vision. This article describes the vision and goals of the Bluetooth program and introduces the radio-based technology. I. Vision link In recent years, wireless connectivity has been an active area of research as we have witnessed a large number of gov- ernment and industry initiatives, research efforts and standard activities that have aimed at enabling wireless and mobile net- working technologies. As a result, today we have a diverse set of wireless access technologies from satellite networks, to wide area cellular systems, and from wireless local loop and PCS to wireless LANs. However, most of these solutions tar- get narrow and specific application scenarios. With all such efforts spent on wireless link technologies, we still lack a uni- versal framework that offers a way to access information based on a diverse set of devices (e.g., PDAs, mobile PCs, phones, pagers, etc.) in a seamless, user-friendly and efficient manner. brings computing, consortium Formed in February 1998 by mobile telephony and comput- ing leaders Ericsson, IBM, Intel, Nokia, and Toshiba, the Blue- tooth special interest group (SIG) is designing a royalty-free, technology specification where each of the founding compa- nies has a significant stake in enabling this vision. We believe that Bluetooth can revolutionize wireless connectivity for per- sonal and business mobile devices, enabling seamless voice and data communication via short-range radio links and allow- ing users to connect a wide range of devices easily and quickly, without the need for cables, expanding communications capa- bilities for mobile computers, mobile phones and other mobile devices, both inside and outside of the office. Considering a wide range of computing and communication devices such as PDAs, notebook computers, pagers, and cellular phones with different capabilities, we envisage Bluetooth to provide a solu- tion for access to information and personal communication by enabling a collaboration between devices in proximity of each other where every device provides its inherent function based on its user interface, form factor, cost and power constraints. Furthermore, the Bluetooth technology enables many new us- age models for portable devices. For notebook computer man- ufacturers, the development of a short-range radio frequency 38 (RF) solution enables the notebook computer to connect to different varieties of cellular phones and other notebook com- puters. For cellular handset manufacturers, the RF solution re- moves many of the wires required for audio and data exchange. Wireless hands-free kits operate even while the cellular phone is stored in a purse. As an example for a new usage model, we enable a connection from a mobile computer to the Internet using a cellular phone as a bridge. In some cases, even when the cellular phone is stored out of plain sight inside a briefcase, for example. In this scenario, the connection to the Internet is automatically established and auto-configured without requir- ing a conscious effort on the user's part to connect the mobile computer to the cellular phone and configure these two devices to communicate. We refer to this as a hidden computing or an unconscious connectivity model that is a powerful paradigm for new and exciting applications. A very key characteristic of Bluetooth that differentiates it from other wireless technologies is that it enables combined usability models based on functions provided by different de- vices. Let us consider a connection between a PDA (comput- ing device) and a cellular phone (communicating device) using Bluetooth and a second connection between the cellular phone and a cellular base station providing connectivity for both data and voice communication. In this model, the PDA maintains its function as a computing device and the phone maintains its role as a communication device - each one of these devices provide a specific function efficiently, yet their function is sep- arate and each can be used independently of the other. How- ever, when these devices are near each other they provide a useful combined function. We believe that this function and connectivity model based on a combination of wireless access technologies - each matched to different device capabilities and requirements - is a powerful paradigm that will enable ubiquitous and pervasive wireless communication. Many of these wireless link technologies are available today, however there is a need to provide a wireless connectivity, network- ing, and application framework to realize the total solution. This is exactly the charter of the Bluetooth SIG. In addition Mobile Computing and Communications Review, Volume 2, Number 4 / /
`
`APPL-1013 / Page 1 of 8
`Apple v. Uniloc
`
`

`

`to combining the resources of a personal network, the RF link could also connect the personal network to the wired infras- tructure. A data access point in an office, conference room, or airport kiosk would act as an information gateway for a note- book computer or cellular handset. The remainder of this paper is organized as follows. Sec- tion II describes the goals the Bluetooth SIG hopes to achieve. Section III provides an overview of the Bluetooth architecture as it currently exists. Section IV compares the Bluetooth SIG to other industry initiatives involving wireles~ technology and Section V summarizes the article. II. Goals II.A. New Usage Models The Bluetooth SIG is attempting to enable new usage models and create additional benefits for users of portable telephony and computer products. In addition to the examples presented in Section I, the SIG wants to enable the following future pos- sibilities. • The Three-in-One Phone. In this scenario, you are able to use the same phone wherever you are. When you're at the office, your phone functions as an intercom (no tele- phony charge). At home, it functions as a portable phone (fixed line charge). And when you're outdoors, the phone functions as a mobile phone (cellular charge). • The Briefcase Trick. Use e-mail while your notebook is still in the briefcase. When your notebook receives an e-mail, you'll get an alert on your mobile phone. You can also browse all incoming e-mails and read those you select in the mobile phone's window. • The Automatic Synchronizer. Automatic background syn- chronization keeps you up-to-date. Automatic synchro- nization of data on your desktop, notebook, personal dig- ital assistant(PDA), and mobile phone. For instance, as soon as you enter your office the address list and calendar in your notebook will automatically be updated to agree with the one in your desktop, or vice versa. Collect a business card on your phone and add it to your address list on your notebook PC. II.B. System Challenges The usage models described above require various system re- quirements to be met. In this section, we review several re- quirements and the challenges they offer. Support for both voice and data. The air protocol must sup- port good quality real-time voice, where "good" is considered to be wired phone line quality. Voice quality is important to both end-users who are accustomed to it, and for speech recog- nition engines whose accuracy depends on it. Able to establish ad hoc connections. The dynamic nature of mobility makes it difficult to make any assumptions about the operating environment. Bluetooth units must be able to de- tect other compatible units and establish connections to them. A single unit must be able to establish multiple connections in addition to accepting new connections while connected. Ignor- ing a new connection requests while connected is confusing to the user and deemed unacceptable, especially if we want to support unconscious computing while retaining the ability to perform interactive operations! Able to withstand interference from other sources in an unli- cenced band. • The Bluetooth radio operates in the unlicensed 2.4 GHz band where many other RF radiators are expected to exist. The fact that microwave ovens operating at this fre- quency is one reason why this band is unlicensed in most coun- tries. The challenge is to avoid significant degradation in per- formance when other RF radiators, including other personal area networks in nearby use, are in operation. Worldwide use. Not only are "standard" cables equipped with a variety of connectors, different standards exists in dif- ferent geographical locations throughout the world. Experi- enced mobile travelers are accustomed to carrying around a number of different power, phone, and network connectors. The challenge here is very regulatory in nature with many gov- ernments having their own set of restrictions on RF technol- ogy. And while the 2.4 GHz band is unlicensed through most parts of the world, it varies in range and offset in a number of different countries. Similar amount of protection compared to a cable. In addi- tion to the radio's short-range nature and spread spectrum tech- niques, Bluetooth link protocols also provide authentication and privacy mechanisms. Users certainly don't want others listening in on their conversations, snooping their data trans- missions, or using their cellular phones for Internet access. Small size to accommodate integration into a variety of de- vices. The Bluetooth radio module must be small enough to permit integration into portable devices. Wearable devices in particular, such as mobile phones, headsets, and smart badges have little space to spare for a radio module. Negligible power consumption compared with the device in which the radio is used. Many Bluetooth devices will be bat- tery powered. This requirement implies the integration of the Bluetooth radio should not significantly compromise the bat- tery lifetime of the device. Encourage ubiquitous deployment of the technology. To achieve this goal, the SIG is designing an open specification defining the radio, physical, link, and higher level protocols and services necessary to support the usage models in the vi- sion. The Specification will be made available under favorable adoption terms, including royalty free, to SIG members. II.C. The Specification The Bluetooth Specification defines the requirements ensur- ing interoperable operation between Bluetooth devices from different manufacturers. The Bluetooth Specification is work- in-progress and any material presented here is preliminary and Mobile Computing and Communications Review, Volume 2, Number 4 39
`
`APPL-1013 / Page 2 of 8
`
`

`

`Application Programs IrDA Interoperability (OBEX) WAP tnteroperability RFCOMM I TCP/IP LOGICAL LINK CONTROL LINK MANAGER BASEBAND RADIO Figure 1 : Application Framework subject to change without notice, l The Specification draft is composed of two sets of documents: the radio and protocol definitions, and the compliance requirements. Figure 1 outlines the application framework in the context of the radio and protocol stack. The Radio takes care of send- ing and receiving modulated bitstreams. The Baseband (BB) protocol defines the timing, framing, packets, and flow control on the link. The Link Manager (LM) assumes the responsibil- ity of managing connection states, enforcing fairness among slaves, power management, and other management tasks. The Logical Link Control handles multiplexing of higher level pro- tocols, segmentation and reassembly of large packets, and de- vice discovery. Audio data is mapped directly on to the Base- band while audio control is layered above the logical link con- trol. Above the data link layer, RFCOMM and network level protocols provide different communication abstractions. RF- COMM provides serial cable emulation using a subset of the ETSI GSM 07.10 standard [2]. Other parts of the Bluetooth Specification deal with interoperability with other protocols and protocol stacks. Defining TCP/IP over Bluetooth requires that bridging, address resolution, MTU definition, and mul- ticast/broadcast mappings be solved. To accelerate the num- ber of wireless-specific applications, the Bluetooth SIG is con- templating interoperability with higher layer IrDA 2 and WAP 3 protocol stacks. 4 For example, IrOBEX [4] defines a transport- independent format and session protocol for object exchange and is used as the basis for a variety of applications from exchanging files and business cards to synchronizing address book and calendar schedules. The compliance requirements section of the Specification I The Bluetooth SIG disclaims all liability, including liability for infringe- ment of any proprietary rights, relating to use of information in this article. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted herein. 21nfrared Data Association. See http://www.irda.org. 3Wireless Application Protocol Forum. See http://www.wapforum.org. 4Third party brands and names are the property of their respective owners. 40 Piconet A Figure 2: Scatternet Example ? defines the radio and protocol features that are required for different classes of devices. Due to the wide variety of possible Bluetooth devices, different sets of requirements are needed. For example, one would not expect an audio headset to have the same minimum requirements as a notebook computer. The goal of the Specification's compliance section is ensuring that any device wearing a Bluetooth "logo" supports a minimum set of benefits for its user. III. The Bluetooth Architecture Bluetooth has been specified and designed with emphasis on robustness and low cost. Its implementation is based on a high-performance, yet low cost, integrated radio transceiver. Bluetooth is targeted at mobile and business users who need to establish a link, or small network, between their computer, cellular phone and other peripherals. The required and nom- inal range of Bluetooth radio is thus set to l0 meters (with 0 dBm output power). To support other uses, for example the home environment, the Bluetooth chipset can be augmented with an external power amplifier to extend the range (up to 100m with +20dBm output power). Auxiliary baseband hard- ware to support, for example, four or more voice channels can also be added. These additions to the base chip set are fully compatible with the nominal specification and may be added depending on the application. Bluetooth operates in the international 2.4 GHz ISM band, at a gross data rate of 1 Mbit/second, and features low energy consumption for use in battery operated devices. Bluetooth uses an ad hoc, piconet structure hereafter referred to as scat- ternet. Figure 2 illustrates an example scatternet, with one unit participating in both piconets. With the scatternet technology described later in this document, it has been possible to achieve an aggregate throughput of over 10 Mbits/second or 20 voice channels within a fully expanded scatternet. The structure also makes it possible to extend the radio range by simply adding additional Bluetooth units acting as bridges at strategic places. A single unit can support a maximum data transfer rate of 721 kbits/second or a maximum of 3 voice channels. A mix- ture of voice and data transfer is also possible in order to sup- port multimedia applications. A robust voice coding scheme with a rate of 64kbits/second per voice channel is used. To sustain these transfer rates in busy radio environment, a packet switching protocol with frequency hopping and advanced cod- Mobile Computing and Communications Review, Volume 2, Number 4 / I
`
`APPL-1013 / Page 3 of 8
`
`

`

`ing techniques are employed. It should also be mentioned that the Bluetooth features a graceful degradation of both voice and data transfer rates in busy RF environments. III.A. Master/Slave definitions In the Bluetooth network all units are peer units with identi- cal hardware and software interfaces distinguished by a unique 48-bit address. At the start of a connection, the initializing unit is temporarily assigned as a master. This assignment is valid only during this connection. It is the master which initiates the connection and controls the traffic on the connection. Slaves are assigned a temporary 3-bit member address to reduce the number of addressing bits required for active communication. III.B. Network topology The Bluetooth network supports both point-to-point and point- to-multipoint connections. A piconet is the network formed by a master and one or more slaves. Each piconet is defined by a different frequency hopping channel. All units participating in the same piconet are synchronized to this channel. III.C. Robust Air Protocol and Adaptive Range To achieve the highest possible robustness for noisy radio en- vironments, Bluetooth uses a packet-switching protocol based on a frequency hop scheme with 1600 hops per second. The entire available frequency spectrum is used with 79 hops of 1 MHz bandwidth, defined analogous to the IEEE 802.11 stan- dard [3]. This frequency hopping gives a reasonable band- width and the best interference immunity by utilizing the entire available spectrum of the open 2.4 GHz Industrial, Scientific, and Medical (ISM) band. Virtual channels are defined using pseudo-random hop sequences. The frequency hopping scheme is combined with fast Au- tomatic Repeat Request (ARQ), cyclic redundancy checks (CRC), and Forward Error Correction (FEC) for data. For voice a continuous variable slope delta modulation (CVSD) scheme is used. All of this results in a very robust link for both data and voice. To save power and minimize radio interference problems, a RSSI (Received Signals Strength Indicator) with a 72 dB dynamic range will be employed. The RSSI will measure the signal received from different units and adapt the RF output power to the exact requirement in each instance. That is, with a mouse or headset, the output power could be limited to a 1 m range, whereas a handset may need a range of 100 m or more. III.D. Establishing network connections When first establishing a network or adding components to a piconet, the units must be identified. Units can be dynamically connected and disconnected from the piconet at any time. Two available options lead to connection times of typically 0.64 and 1.28 seconds respectively. This applies when the unit address is known and not more than about 5 hours have elapsed since the previous connection. A unit does not need to be connected at all times since only a typical delay of under one second is required to start a transaction. Hence, when not in use, the unit can be in a sleep state (STANDBY) most of the time where only a Low Power Oscillator (LPO) is running. This is, of course, beneficial for battery operation. Before any connections are made, all units are in standby mode. In this mode, an unconnected unit will only listen to messages every 1.28 seconds or 2.56 seconds depending on the selected option. Each time a unit wakes up, it will listen on one of 32 hop frequencies defined for this unit. The connect procedure is initiated by one of the units, the master. A connection is made either by a PAGE message if the address is already known, or by the INQUIRY message followed by a subsequent PAGE message if the address is un- known. In the initial PAGE state, the paging unit (which is the master) will send a train of 16 identical page messages on 16 different hop frequencies defined for the unit to be paged (the slave). The train covers half the sequence of frequencies in which the slave can wake up. It is repeated 128 or 256 times (1.28 or 2.56 seconds) depending on the needs of the paged unit. If no response is received after this time, the master trans- mits a train of 16 identical page messages on the remaining 16 hop frequencies in the wake-up sequence. The maximum de- lay before the master reaches the slave is 2 times 1.28 seconds or 2.56 seconds if a periodicity of 1.28 seconds was chosen for paging and 5.12 seconds with 2.56 seconds periodicity respec- tively. This allows devices to trade off between access delay and standby power savings. The hop frequencies in the first page train are based on the master's slave clock estimate. The train will include the esti- mated wake-up hop, and 8 hops before and 7 hops after this hop. As a result, the estimate can be ± 7 hops in error and still the master reaches the slave with the first page train. Because the estimate is updated at each connection establishment, the acquisition delay is shorter when a shorter time has elapsed since the units were last connected. With a Low Power Oscil- lator (LPO) inaccuracy better than ± 250 ppm, the first train is still valid after at least 5-hours lapse with no connection. That is, for a time period of at least 5 hours since the last connection, the average acquisition times are 0.64 seconds and 1.28 seconds respectively. If the first train does not cover the slave's wakeup frequency, the second train does and the aver- age acquisition delays are 1.92 seconds and 3.84 seconds. The INQUIRY message is typically used for finding pub- lic printers, faxes and similar equipment with an unknown ad- dress. The INQUIRY message is very similar to the page mes- sage but may require one additional train period to collect all the responses. If no data needs to be transmitted, the units may be put on HOLD where only an internal timer is running. When units go out of HOLD mode data transfer can be restarted instanta- neously. Units may thus remain connected, without data trans- fer, in a low power mode. The HOLD is typically used when connecting several piconets. It could also be used for units where data needs to be sent very infrequently and low power consumption is important. A typical application would be a room thermostat which may need to transfer data only once every minute. Two more low power modes are available, the SNIFF mode and the PARK mode. If we list the modes in increasing order of power efficiency, then the SNIFF mode has the higher duty cycle, followed by the HOLD mode with a lower duty cycle, and finishing with the PARK mode with the lowest duty cycle. Mobile Computing and Communications Review, Volume 2, Number 4 41
`
`APPL-1013 / Page 4 of 8
`
`

`

`Figure 3 describes the various possible connection states. Unconnected Standby Connecting States Active States Low Power Models / ~.k own ~ ~,~ow,~ 1 Releases Keeps Member Address Member Address Figure 3: Connection State Machine III.E. Link types Once a Bluetooth unit has been connected to a piconet it may communicate by means of two link types. That is, between any two members of the piconet forming a master-slave pair. Two link types are supported. These links are: • Synchronous Connection Oriented (SCO) link • Asynchronous (or isochronous) Connectionless (ACL) link. Different link types may apply between different master-slave pairs of the same piconet and the link type may change arbi- trarily during a session. The link type defines what type of packets can be used on a particular link. On each link type, 16 different packet types can be used. The packets differ in func- tion and data bearing capabilities. For full duplex transmis- sions a Time Division Duplex scheme is used. Each packet is transmitted in a different hop channel than the previous packet. An SCO link is a point-to-point full-duplex link between the master and a slave. This link is established once by the master and kept alive until being released by the master. The SCO link is typically used for a voice connection. The master reserves the slots used for the SCO link on the channel. The ACL link makes a momentary connection between the master and any of the slaves for the duration of one frame (master-to-slave slot and slave-to-master slot). No slots are re- served. The master can freely decide which slave to address and in which order. The member subaddress in the packet header determines the slave. A polling scheme is used to con- trol the traffic from the slaves to the master. The link is in- tended for asynchronous or isochronous data. However, if the master uses this link to address the same slave at regular inter- vals, it becomes a synchronous link. The ACL link supports both symmetric and asymmetric modes. In addition, modes have been defined with or without FEC, and with or without CRC and ARQ. III.F. Packet Definition A packet (see Figure 4 consists of three fields: a 72-bit access code, a 54-bit header, and a payload of variable length (2-342 bytes). Packets may consist of the (shortened) access code only, the access code and the header, or the access code, header and payload. / LSB 72 54 16-2745 MSB i ccF s oo i .EAo i AVLO,,D b Figure 4: Typical packet format The packet starts with a 72-bit channel access code. This access code is used for synchronization, DC offset compensa- tion and identification. The access code identifies all packets exchanged on the channel of the piconet: all packets sent in the same piconet are preceded by the same channel access code. In the receiver of the Bluetooth unit, a sliding correlator cor- relates against the access code and triggers when a threshold is exceeded. This trigger signal is used to wake up the entire signal processing of the receiver. In addition, it is used to fix the receive timing. The correlator remains active during the entire search window: when a new correlation value is found which is larger than a previous correlation value which initially triggered the receiver, the entire receiver is reset and triggered again. The channel access code consists of a preamble, a sync word, and a trailer, see Figure 5. Both preamble and trailer are fixed bit patterns. LSB 4 64 4 MSB I REAM.LE[ SY CWO.O I ""A'LE" I / \ oc. I ,rAP I.RK.I 34 24 6 Figure 5: Channel Access Code The preamble is a fixed zero-one pattern of 4 symbols used to facilitate DC compensation. The sequence is either 1010 or 0101, depending on whether the LSB of the following access code is 1 or 0 respectively. The sync word is a 64-bit code and is derived from the master's lower address part (LAP) of its 48- bit unique address. The code guarantees large Hamming dis- tance between sync words based on different addresses. In ad- dition, it has good auto- and cross-correlation properties which improves the timing synchronization process. Like the pream- ble, the trailer is a fixed zero-one pattern of four symbols used for fine compensation. The sequence is either 1010 or 0101 42 Mobile Computing and Communications Review, Volume 2, Number 4 d
`
`APPL-1013 / Page 5 of 8
`
`

`

`depending on whether the MSB of the sync word is 0 or 1 respectively. LSB 3 4 I 1 I 8 MSB M_ADDR TYPE HEC I L ARQN Figure 6: Header format the return packet. The success of the reception is checked by means of a cyclic redundancy check (CRC) which is added to each pay!oad that contains data. An unnumbered ARQ scheme is used which means that the ARQN relates to the packet just received. SEQN: This is a numbering field to distinguish new packets from retransmitted packets. The SEQN bit is toggled for each new packet transmission. A retransmitted packet keeps the same SEQN bit. If two consecutive packets are received with the same SEQN bit, the second packet is ignored. The header, shown in Figure 6, contains lower-level link control information. It consist of 6 fields: a 3-bit sub ad- dress (M_ADDR), a 4-bit packet type (TYPE), a 1-bit flow control bit (FLOW), a 1-bit acknowledge indication (ARQN), a 1-bit sequence number (SEQN), and an 8-bit header error check (HEC). The total header information consists of 18 bits, but is protected with a 1/3 forward-error correction coding re- sulting in a 54-bit header length. M_ADDR: This field represents a member address used to distinguish the active participants on the piconet. With the M_ADDR, the master can separate the different slave active on the piconet. This M_ADDR is assigned temporarily to a unit for the time it is active on the channel. Packets exchanged between the master and the active slave all carry the M_ADDR of this slave. The all-zero address is reserved for broadcasting purposes. Slaves in the PARK mode are inactive but are still locked to the FH channel. The parked slaves do not use an M_ADDR but their full 48-bit unique address. TYPE: Sixteen different types of packets can be distin- guished. The 4-bit TYPE code specifies which packet type is used. Important to note is that the interpretation of the TYPE code depends on the physical link type associated with the packet. First, it shall be determined whether the packet is a SCO or an ACL packet. Then, it shall be determined which of the SCO packet types or ACL packet types we are dealing with. The TYPE code also reveals how many slots the current packet will occupy. This allows the non-addressed receivers to go to sleep for the duration of the occupied slots. FLOW: This bit is used for flow control over the ACL link. When the RX buffer for the ACL connection in the recipient is full and is not emptied by the link support unit, a STOP indication (FLOW=0) is returned to stop the transmission of data temporarily. Note, that the STOP signal only concerns ACL packets. Packets including only link control (POLL and NULL packets) or SCO packets can still be received. When the receive buffer is empty, a GO indication (FLOW=l) is re- turned. When no packet is received or the received header is in error, a GO is assumed implicitly. ARQN: This is an acknowledge field to inform the sender whether the reception of the packet in the preceding slot was successful (ARQN=I) or unsuccessful (ARQN=0). When no valid ARQN field is received, ARQN=0 is assumed implicitly. ARQN=0 is the default value. The ARQN is piggy-backed in HEC: Each header has a header-error-check to check the header integrity. The HEC consist of an 8-bit word generated by the polynomial 647 (octal representation). Before generat- ing the HEC, the HEC generator is initialized with the 8-bit upper address part (UAP) of the master identity. The HEC is then calculated over the 10 header bits. Before checking the HEC, the receiver must initialize the HEC check circuitry with the proper 8-bit UAP. If the HEC fails, the entire packet is dis- carded. III.G. Packet types The 4-bit TYPE code in the packet header specifies 16 differ- ent packet types. The packet types have been divided into 4 segments. The first segment consists of 4 packets and is re- served for control packets common to all physical link types. The second segment consists of 6 packets and is reserved for packets occupying a single time slot. The third segment con- sists of 4 packets and is reserved for packets occupying three time slots. The fourth segment consists of 2 packets and is reserved for packets occupying five time slots. The slot oc- cupancy is reflected in the segmentation and can directly be derived from the type code. Table 1 summarizes the packets defined for the SCO and ACL link types. At this moment, four different SCO packets have been de- fined. So far, only single-slot packets have been defined. SCO packets are typically used for synchronous information like voice. The packets differ in the amount of FEC coding ap- plied and whether part of the packet is reserved for data as well as voice. For the ACL link, 6 different packet types have been defined. They differ in the in the amount of data carried, in the presence of absence of FEC coding, and whether ARQ is applied or not. hline III.H. Error correction There are three error-correction schemes defined for Blue- tooth: 1/3 rate FEC, 2/3 rate FEC, and an ARQ scheme for data. The purpose of the FEC scheme on the data payload is to reduce the number of retransmissions. However, in a reason- able error-free environment, FEC gives unnecessary overhead that reduces the th

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket