IN-HOME NETWORKING
`
`An Overview of the
`Bluetooth Wireless Technology
`
`Chatschik Bisdikian, IBM Corporation
`
`ABSTRACT
`The Bluetooth™1 wireless technology is
`designed as a short-range connectivity solution
`for personal, portable, and handheld electronic
`devices. Since May 1998 the Bluetooth SIG has
`steered the development of the technology
`through the development of an open industry
`specification, including both protocols and appli-
`cation scenarios, and a qualification program
`designed to assure end-user value for Bluetooth
`products. This article highlights the Bluetooth
`wireless technology.2
`
`INTRODUCTION
`For the last few years the wireless world has
`been bombarded daily with information about a
`new generation of radio frequency (RF) tech-
`nologies that would profoundly impact, if not
`revolutionize, the way we live and contact our
`businesses. This new generation of technologies
`spans the full spectrum of wireless communica-
`tions coverage. Third generation (3G) wireless
`technologies are being developed to enable per-
`sonal, high-speed interactive connectivity to wide
`area networks (WANs). The IEEE 802.11b wire-
`less local area network (LAN) technology finds
`itself with an increasing presence in corporate
`and academic office spaces, buildings, and cam-
`puses. Furthermore, with slow but steady growth,
`the 802.11b technology is making inroads into
`public areas such as airports and coffee bars.
`WAN and LAN technologies enable device
`connectivity to infrastructure-based services,
`either through a wireless carrier provider or
`through a campus or corporate backbone
`intranet. The other end of the coverage spec-
`trum is occupied by the short-range personal
`wireless connectivity technologies that allow per-
`sonal devices to communicate with each other
`directly without the need for an established
`infrastructure. At this end of the coverage spec-
`trum the Bluetooth wireless technology offers to
`the personal connectivity space the benefits of
`omni-directionality and the elimination of the
`line of sight requirement of RF-based connectiv-
`ity. The personal connectivity space resembles a
`communications bubble that follows people
`around and empowers them to connect their
`
`personal devices with other devices that enter
`the bubble. Connectivity in this bubble is sponta-
`neous and ephemeral and can involve several
`devices of diverse computing capabilities, unlike
`wireless LAN solutions that are designed for
`communication between devices of sufficient
`computing power and battery capabilities.
`The Bluetooth wireless technology3 will serve
`primarily as a replacement of the interconnect
`cables between a variety of personal devices,
`including notebook computers, cellular phones,
`personal digital assistants (PDAs), digital cam-
`eras, etc. The Bluetooth wireless technology aims
`to serve as the universal low cost, user friendly,
`air interface that will replace the plethora of pro-
`prietary cables that people need to carry and use
`to connect their personal devices. While personal
`devices typically communicate based on the RS-
`232 serial port protocol, proprietary connectors
`and pin arrangements make it impossible to use
`the same set of cables to interconnect devices
`from different manufactures, and sometimes
`even from the same manufacturer. The primary
`focus of the Bluetooth wireless technology is to
`provide a flexible cable connector with reconfig-
`urable pin arrangements permitting several per-
`sonal devices to interconnect with each other.
`Another focus of the technology is to enable
`a uniform interface for accessing data services. A
`user using any number of data-capable devices
`will be able to connect to a LAN access point
`that provides access to, for example, the corpo-
`rate intranet infrastructure and services. Like-
`wise, the user will be able to connect to her
`cellular phone and access WAN data services.
`Applications can then be written that could pro-
`vide the user with a similar connectivity experi-
`ence connecting to data service in either manner.
`Connecting to data services through one’s cellu-
`lar phone gives rise to the concept of a personal
`gateway. People will carry their personal gate-
`ways wherever they go. The personal gateway
`will serve as a facilitator in accessing remote
`data services, with the added convenience that it
`can be kept hidden away from the line-of-sight
`of its communicating Bluetooth partner. The
`Bluetooth wireless technology enables the unob-
`trusive separation of the functionality of con-
`necting to a data service from viewing and
`interacting with the information provided by the
`
`1 Bluetooth is a trademark
`owned by the Bluetooth
`SIG, Inc., USA.
`
`2 Any opinions expressed
`in this article represent
`only the personal opinions
`of the author and do not
`reflect a position of the
`author’s employer or any-
`body else’s.
`
`3 According to the Blue-
`tooth brand requirements
`document, the term
`“Bluetooth” must always
`be used as an adjective.
`Furthermore, when the
`term “Bluetooth” is used
`to denote the correspond-
`ing technology, the term
`“wireless” must be insert-
`ed between Bluetooth and
`technology. The author
`recognizes that the above
`rules are not always fol-
`lowed and the term “Blue-
`tooth” has grown to
`represent both the tech-
`nology and the whole
`industry behind it.
`
`86
`
`0163-6804/01/$10.00 © 2001 IEEE
`
`IEEE Communications Magazine • December 2001
`
`Canon Exhibit 1017, Page 1
`
`

`

`data service. Thus a PDA can be used as a more
`convenient I/O device for entering and receiving
`data, while using the personal gateway purely for
`communicating with the wireless data carrier.
`Yet another focus item for the Bluetooth
`wireless technology is to enable ad hoc connec-
`tivity among personal devices. This will permit
`individuals to form collaborative groups, for
`example, during a conference meeting, to
`exchange data without the need to rely on an
`infrastructure to support their communication.
`In this article, we present an overview of the
`Bluetooth wireless technology. This article is
`organized as follows. We present a history of the
`Bluetooth wireless technology, followed by a dis-
`cussion of the Bluetooth specification, including
`the core and the profile portions of the specifica-
`tion. We conclude with a summary of the article.
`
`THE HISTORY OF THE
`BLUETOOTH WIRELESS TECHNOLOGY
`The development of the Bluetooth industry stan-
`dard started late in the winter of 1998 when
`Ericsson, IBM, Intel, Nokia, and Toshiba formed
`the Bluetooth Special Industry Group (SIG) to
`develop and promote a global solution for short-
`range wireless communication operating in the
`unlicensed 2.4 GHz ISM (industrial, scientific,
`medical) band.
`The name Bluetooth comes from the Danish
`king Harald Blåtand (Bluetooth). King Bluetooth
`is credited with uniting the Scandinavian people
`during the 10th century. Similarly, the Bluetooth
`wireless technology aims to unite personal com-
`puting devices. The name was chosen temporari-
`ly to describe the yet unannounced development
`project. However, the search for a new name
`never came to a successful fruition and the tem-
`porary name became permanent. In retrospect,
`the selection of this joyful name can be credited
`highly for the recognition and acceptance the
`technology has received so far.
`To facilitate the wide acceptance of this new
`technology, the SIG decided to offer all the
`intellectual property explicitly included in the
`Bluetooth specification royalty-free to adopter
`members of the technology when it is used to
`introduce Bluetooth products in the market. The
`SIG announced its existence and intentions to
`the public in May 1998, joined at the time by
`approximately 70 adopter members. As of this
`writing there are approximately 3000 adopter
`members. A little over a year later, in the sum-
`mer of 1999, the over 1600-page Bluetooth spec-
`ification version 1.0A became publicly available.
`Due to the Bluetooth SIG license agreement,
`the development of the specification is not made
`available to the general public until it is finished
`and approved by the Bluetooth SIG. Adopter
`members have the privilege to look at the speci-
`fication prior to its public availability.
`The Bluetooth specification, currently at ver-
`sion 1.1, comprised the following two parts,
`which we discuss later in the article:
`• The core specification defining the radio
`characteristics and the communication pro-
`tocols for exchanging data between devices
`over Bluetooth radio links.
`
`IEEE Communications Magazine • December 2001
`
`• The profile specification that defines how
`the Bluetooth protocols are to be used to
`realize a number of selected applications.
`To make free use of the intellectual property
`in the Bluetooth specification, adopter members
`need to qualify any Bluetooth products they
`intent to bring to market through the Bluetooth
`qualification program (BQP). The BQP includes
`radio and protocol conformance testing and pro-
`file conformance testing (when applicable) as
`well as interoperability testing.
`In December 1999 the promoter group
`increased from five to nine with the addition of
`3Com, Lucent, Microsoft, and Motorola. As of
`early 2001, Agere, a Lucent spinoff comprising
`its former microelectronics division, has taken
`the place of Lucent in the promoters group.
`In March 1999 the IEEE 802.15 standards
`working group was created to develop a family
`of communications standards for wireless per-
`sonal area networks (WPANs).4 In the first
`meeting of the new working group in July 1999,
`the Bluetooth SIG submitted the just created
`Bluetooth specification as a candidate for an
`IEEE 802.15 standard. The Bluetooth proposal
`was chosen to serve as the baseline of the
`802.15.1 standard. As of this writing, the devel-
`opment of the draft standard is in its final stages,
`having successfully completed two sponsor bal-
`lots. In addition to the IEEE 802.15.1 activity,
`the IEEE 802.15.2 task group studies coexis-
`tence issues between 802 wireless technologies.
`The 802.15.3 task group is developing standards
`for high-rate radios (>20 Mb/s). Finally, the
`802.15.4 task group is developing standards for
`low-rate radios (<200 kb/s).
`
`THE BLUETOOTH SPECIFICATION
`The Bluetooth specification has been written pri-
`marily as an implementation manual rather than
`a formal communications standard document.
`This aspect of the specification reflects its devel-
`opment process by a group of engineers that
`actually developed the technology in parallel with
`the development of the specification. These engi-
`neers wrote in a prose style, describing in the
`specification their experiences gained in imple-
`mentations. This is in contrast to the formal lan-
`guage commonly used in a formally developed
`standard. This approach has its pros and cons.
`On the upside, the specification is easier to read
`than a formal standards document. On the down-
`side, using prose, which is naturally imprecise,
`the specification is sometimes open to conflicting
`interpretation. The latter issue is being addressed
`through an errata resolution process.
`Figure 1 depicts the Bluetooth protocol stack,
`which also shows the application and profiles
`“layer” for completeness. (We discuss the latter
`later in this section.) The protocols in the stack
`have been grouped in two categories: the trans-
`port and the middleware protocols. The transport
`protocols comprise protocols developed exclu-
`sively for the Bluetooth wireless technology.
`These protocols are involved in all data commu-
`nications between two Bluetooth devices. The
`middleware protocols comprise both Bluetooth-
`specific protocols and other adopted protocols.
`These protocols are used selectively to enable
`
`The search for a
`new name never
`came to a
`successful fruition
`and the
`temporary name
`became
`permanent. In
`retrospect, the
`selection of this
`joyful name can
`be credited highly
`for the
`recognition and
`acceptance the
`technology has
`received so far.
`
`4 WPAN is a trademark of
`IEEE.
`
`87
`
`Canon Exhibit 1017, Page 2
`
`

`

`Applications/profiles
`
`Middleware
`protocols
`
`Other
`
`RFCOMM TCS
`
`SDP
`
`Transport
`protocols
`
`L2CAP
`
`A_P
`
`HCI
`
`Link manager
`
`C_P
`
`Baseband
`
`Radio
`
`HCI: Host controller interface A_P: Audio path C_P: Control path
`
`I Figure 1. The Bluetooth protocol stack.
`
`different applications, including both legacy and
`new applications, to exchange data using the
`Bluetooth wireless technology. Whenever
`desired, the middleware protocols shield these
`applications from the specifics of the Bluetooth
`transport protocols.
`This grouping of the protocols in the Blue-
`tooth protocol stack is not part of the specifica-
`tion. Rather, it is used here as a natural grouping
`of the protocols for ease of presentation.
`THE TRANSPORT PROTOCOLS
`The Radio — The radio layer defines the tech-
`nical characteristics of the Bluetooth radios. A
`Bluetooth radio operates on the license-free 2.4
`GHz ISM band and is compliant with FCC part
`15 regulations for intentional radiators in this
`band. It employs a fast (1,600 hops/sec), fre-
`quency-hopping, spread-spectrum (FHSS) tech-
`nique. The radio hops in a pseudo-random
`fashion on 79 one-MHz channels.5 The frequen-
`cies are located at (2,402 + k) MHz, k = 0, 1,
`…, 78.
`The modulation technique is a binary Gaus-
`sian frequency shift-keying (GFSK) and the baud
`rate is 1 Msymbol/s. Hence, the bit time is 1 ms
`and the raw transmission speed is 1 Mb/s. The
`Bluetooth radios come in three power classes,
`depending on their transmit power. Class 1 radios
`have transmit power of 20 dBm (100 mW); class
`2 radios have transmit power of 4 dBm (2.5 mW);
`class 3 radios have transmit power of only 0 dBm
`(1 mW). Due to the power and cost constraints
`of the various personal devices that use Blue-
`tooth radios, class 3 and class 2 radios are expect-
`ed to be the ones mostly used in these devices.
`
`The Baseband — The baseband defines the key
`procedures that enable devices to communicate
`with each other using the Bluetooth wireless tech-
`nology. The baseband defines the Bluetooth
`piconets and how they are created, and the Blue-
`tooth links. It also defines how the transmit
`resources are to be shared among several devices
`in a piconent, as well as the low-level packet types.
`
`5 The specification per-
`mits a reduced channel
`hop over only 23 channels
`for countries that have
`restrictions in their corre-
`sponding ISM band.
`
`88
`
`The Bluetooth Address and Clock — Each
`Bluetooth device has two parameters that are
`involved in practically all aspects of Bluetooth
`communications. The first one is a unique IEEE-
`type 48-bit address assigned to each Bluetooth
`radio at manufacture time. The Bluetooth device
`address (BD_ADDR) is engraved on the Blue-
`tooth hardware and it cannot be modified. The
`second parameter is a free-running 28-bit clock
`that ticks once every 312.5 ms, which corresponds
`to half the residence time in a frequency when
`the radio hops at the nominal rate of 1,600
`hops/sec.
`Bluetooth devices can communicate with
`each other by acquiring each other’s Bluetooth
`addresses and clocks, as will be further described
`later.
`
`The Bluetooth Piconet — A piconet is a col-
`lection of Bluetooth devices that can communi-
`cate with each other. A piconet is formed in an
`ad hoc manner without any infrastructure assis-
`tance, and it lasts for as long as the creator of it
`needs and is available to communicate with
`other devices. A piconet contains at least one
`device identified as the master of the piconet and
`at most seven other devices identified as slaves
`with which the master is actively involved in com-
`munications. The terms master and slave are rel-
`ative to a particular existing piconet. The terms
`are not assigned to the radio units at manufac-
`ture time. A Bluetooth radio may serve either as
`a master or slave at different times.
`To identify each slave, the master of a piconet
`assigns a locally unique active member address
`(AM_ADDR) to the slaves participating in active
`communications in the piconet. The master regu-
`lates and controls who transmits and when. While
`up to seven slaves may be actively communicat-
`ing in a piconet at one time, additional devices
`may be registered with the master and be invited
`to become active whenever necessary. These
`additional devices are called parked. Bluetooth
`devices not associated with any piconet are in
`stand-by mode. Figure 2 shows two piconets with
`a number of slaves and parked devices associated
`with them, and a few standby devices. Bluetooth
`piconets can coexist in time and space indepen-
`dently of each other. Furthermore, a single device
`may be a member of several piconets, a case
`referred to as scatternet in Bluetooth parlance.
`The communications channel in a piconet is
`defined as the sequence of the frequency hops
`followed by the piconet members in a synchro-
`nized manner. The transmit and receive time axis
`are slotted, with each slot lasting the duration of
`a nominal frequency hop, 625 ms. Each baseband
`transmission resides fully within the boundaries
`of a slot. However, multi-slot packets occupying
`three or five slots instead are also allowed. Dur-
`ing the transmission of a multi-slot packet, the
`transmit frequency does not change. When fre-
`quency hopping resumes, it resumes with the fre-
`quency whose turn it would have been if the
`devices were to use only single-slot transmissions.
`To maintain time synchronization for the
`hops, slaves utilize the Bluetooth clock of the
`master and the fact that hops occur in multiples
`of 625 ms; slaves actually maintain the offset
`time between their Bluetooth clock and that of
`
`IEEE Communications Magazine • December 2001
`
`Canon Exhibit 1017, Page 3
`
`

`

`their master. Slots in a piconet are identified as
`even or odd according to the value of the second
`least significant bit of the Bluetooth clock of the
`master; recall that the Bluetooth clock ticks at a
`rate twice that of the slot rate. To recreate the
`frequency hop sequence in a piconet, a slave uti-
`lizes the Bluetooth address of the master of the
`piconet. Furthermore, the Bluetooth clock of the
`master identifies the particular frequency to be
`used at a particular slot. Therefore, the commu-
`nications channel in a piconet is fully identified
`by the master. As a result, in the case of scatter-
`nets a device can serve as a master for only one
`piconet, otherwise the two piconets cannot be
`distinguished from each other.
`The master and the slaves alternate transmit
`opportunities in a time-division duplex (TDD)
`fashion. In particular, the master transmits on
`even numbered slots, as defined by the master’s
`Bluetooth clock, while the slaves transmit on odd
`numbered slots (recall that each slot lasts 625
`ms). A slave can transmit only if the master has
`just transmitted to this slave. A transmission may
`last one, three, or five slots; however, the specifi-
`cation requires that only the one-slot transmis-
`sions be mandatory. In the case of scatternets, a
`device cannot receive or transmit data simultane-
`ously in two or more piconets. However, such a
`device may time-share its participation in each
`piconet over non-overlapping time intervals.
`To engage in communications in a piconet,
`the slaves in the piconet need to know the
`BD_ADDR and Bluetooth clock of the master.
`Likewise the master needs to know the identities
`of the slaves. This information is acquired in two
`phases: the inquiry phase, for locating devices,
`and the the paging phase, for inviting specific
`devices to join a piconet. A good overview of
`these phases is given in J. Haartsen’s “The Blue-
`tooth Radio System” in [1].
`The inquiry process is a device discovery pro-
`cess during which the master of a future piconet
`discovers other devices in its vicinity. The master
`makes its presence known by transmitting inquiry
`messages. Devices that perform inquiry scan, that
`is, search actively for inquiry messages, respond
`with inquiry response messages that, among other
`things, contain the BD_ADDR of the device.
`Armed with the knowledge of the identity of
`devices in its vicinity, the master of a piconet
`may explicitly page devices to join its piconet. A
`master with prior knowledge of the identity of a
`device may skip the inquiry process and go
`directly to paging the device. If the device does
`not respond, it may mean that it is not in the
`transmit range of the paging device.
`With the information sent by the paging
`device to the paged device, the paged device can
`now join as a slave the piconet whose master is
`the paging device. After joining the piconet, the
`master and the slave may negotiate reversal of
`roles, in which case the (original) master
`becomes a slave in the piconet whose master will
`be the (original) slave.
`Next we present how masters and slaves
`exchange data.
`
`The Bluetooth Links and Baseband Packets —
`There are two types of links supported in the
`Bluetooth piconet. Between a master and a slave
`
`Sb
`
`P
`
`Sb
`
`Sb
`
`P
`
`S
`
`S
`
`M
`
`Radius of
`coverage
`
`S
`
`M
`
`S
`
`S
`
`M: master
`S: slave
`P: parked
`Sb: stand-by
`
`S
`
`I Figure 2. Bluetooth piconets.
`
`there is a single asynchronous connectionless
`(ACL) link supported. Optionally, a piconet may
`support synchronous connection-oriented (SCO)
`links. Up to three SCO links may be supported
`in a piconet.
`The ACL link is a best-effort link appropriate
`for asynchronous data transmissions. It main-
`tains integrity by using retransmissions and
`sequence members, as well as forward error cor-
`rection (FEC) if necessary. The SCO link sup-
`ports periodic audio transmissions at 64 Kb/s in
`each direction. SCO traffic is not retransmitted,
`but it can use FEC mechanisms to recover from
`transmission errors when they occur.
`Figure 3 shows the various baseband packet
`types. They all contain an access code (AC) field,
`which is used to distinguish transmissions in differ-
`ent piconets. With the exception of the ID packet,
`all other packets also have a header portion. With
`the further exception of the poll and null packets,
`all other packets also have a payload section.
`The ID packet is used during inquiry searches
`and to obtain time synchronization during pages.
`The poll packet is used by the master to explicit-
`ly poll a slave when no payload information
`needs to be sent to the slave. The null packet is
`used to acknowledge a transmission when no
`payload information needs to be sent.
`The frequency-hopping sequence (FHS) packet
`is used during the creation of a piconet and it is
`used to pass address (BD_ADDR and AM_ADDR)
`and clock information between future masters
`and slaves. The payload of an FHS packet is
`encoded with a shortened Hamming code with
`rate 2/3. The number of bits shown in the figure is
`after the application of the FEC.
`The ACL or SCO packets carry asynchronous
`
`IEEE Communications Magazine • December 2001
`
`89
`
`Canon Exhibit 1017, Page 4
`
`

`

`The link manager
`protocol is a
`transactional
`protocol between
`two link
`management
`entities in
`communicating
`Bluetooth devices
`whose
`responsibility
`is to set-up the
`properties of the
`Bluetooth link.
`
`LSB
`
`ID
`(bit-count)
`
`POLL/NULL
`
`FHS
`
`ACL/SCO
`
`DV
`
`AC
`68
`
`AC
`
`72
`
`AC
`
`72
`
`AC
`
`72
`
`AC
`
`72
`
`MSB
`
`BB_header
`
`54* (1/3FEC)
`
`BB_header
`
`54 (1/3FEC)
`
`BB_header
`
`54 (1/3FEC)
`
`BB_header
`
`54 (1/3FEC)
`
`FHS payload
`
`240 (2/3 FEC)
`
`ACL or SCO payload
`
`0-2744 ({1,2,3**}/3 FEC)
`
`SCO payload
`
`80
`
`ACL payload
`
`32-150 (2/3 FEC)
`
`(*) the bit counts include any FEC applied; (**) a 3/3 FEC implies no FEC
`(cid:0)
`
`I Figure 3. The baseband packet types.
`
`and synchronous data in their payload, respec-
`tively. The payload of ACL packets may be
`encoded with an FEC with rate 2/3, or not
`encoded at all. The payload of SCO packets
`may be encoded with an FEC with rate 2/3 or
`1/3, or not encoded at all. When the FEC with
`rate 1/3 is used, each bit is simply repeated
`three times. The data voice (DV) packet is a
`packet that contains both ACL and SCO data
`and is transmitted at the periodic instances of a
`regular SCO packet, whenever there is a need
`to send ACL data to the recipient device of the
`SCO transmission.
`Figure 4 depicts the fields in the header and
`the payload of a baseband packet. The AM_ADDR
`field identifies the destination slave of a master
`transmission or the source slave of a slave trans-
`mission. The PDU_type field identifies the type of
`baseband packet as shown in Fig. 3. The flags are
`used for controlling the transmission and retrans-
`
`mission of ACL packets. In particular, ACL pack-
`ets use a stop-and-go ARQ scheme and a 1-bit
`sequence number. Furthermore, the ACL link is
`flow-controlled. The header is protected by an 8-
`bit header error check (HEC) code. The ACL
`payload has its own header and body portion (see
`also Fig. 5) and it is protected with a 16-bit cyclic
`redundancy check (CRC).
`When AM_ADDR = b‘000’, then the packet
`is a broadcast packet from the master to all the
`slaves. Broadcast packets are not acknowledged
`and are not retransmitted.
`The L_CH field in Fig. 5 is used to identify
`the logical channel for this baseband transmis-
`sion. When L_CH = b‘11’, then the body of the
`ACL packet payload is passed to the link man-
`ager and is used for the configuration of the
`Bluetooth link. When L_CH = b‘01’ or b‘01’,
`then the body is passed to L2CAP for further
`processing (discussed later).
`
`AC
`
`72
`
`BB_header
`
`54 (1/3FEC)
`
`preamble
`
`synch word
`
`4
`
`68
`
`trailer
`
`4
`
`AM_ADDR
`
`PDU_type
`
`flags(**)
`
`HEC
`
`3
`
`4
`
`3
`8
`(**) flags: |flow|ARQ|SEQN|
`
`SCO payload
`
`SCO data
`
`({1,2,3*}/3) FEC applied whenever appropriate
`
`ACL payload
`
`ACL_pld_hdr
`
`ACL_pld_body
`
`CRC
`
`({2,3*}/3) FEC applied whenever appropriate
`
`(*) a 3/3 FEC implies no FEC
`
`I Figure 4. The baseband packet fields.
`
`90
`
`IEEE Communications Magazine • December 2001
`
`Canon Exhibit 1017, Page 5
`
`

`

`LSB
`
`ACL_pld_hdr
`
`1 (or 2) octets
`
`MSB
`
`ACL_pld_body
`
`0 to 339 octets
`
`L_CH
`
`flow
`
`length
`
`reserved(**)
`
`2
`
`1
`
`5 or 9(*)
`
`4
`
`(bit-count)
`
`(*) for multislot baseband packets
`(**) present only when length is 9 bits
`
`I Figure 5. The ACL packet payload format.
`
`The Link Manager Protocol — The Link Man-
`ager Protocol (LMP) is a transactional protocol
`between two link management entities in com-
`municating Bluetooth devices whose responsibil-
`ity is to set-up the properties of the Bluetooth
`link. For LMP packets, the L_CH field in Fig. 5
`is set to the binary value b‘11’.
`Through LMP transactions one device may
`authenticate another device through a challenge
`response mechanism. For authenticated devices,
`the link may be further encrypted. Two link
`managers may learn each other’s features, for
`example whether the devices support SCO links,
`what size of packet transmission do they sup-
`port, or whether they support any of the low
`power consumption modes. SCO connections
`are established using LMP transactions; polling
`intervals and agreed upon packet sizes are also
`set up through LMP transactions.
`Figure 6 shows the format of an LMP packet.
`The LMP packets are carried in the payload of
`one-slot ACL packets with logical channel L_CH
`= b‘11’; optionally, when supported, DV packets
`may also be used. The header of an LMP packet
`is just one octet. The tr_ID (for transaction ID)
`simply signifies the initiator of an LMP transac-
`tion, which could be either the master (tr_ID =
`b‘0’) or the slave (tr_ID = b‘1’).
`
`Security Procedures — The algorithms for
`authentication and encryption are part of the
`baseband portion of the Bluetooth specification.
`However, the act of authentication, as well as
`the negotiation for encrypting the link between
`two devices, are part of the LMP specification.
`Thus, the discussion about the security proce-
`dure is included here.
`Bluetooth devices may be authenticated and
`links may be encrypted. Due to the ad hoc nature
`of Bluetooth communications and the fact that
`Bluetooth devices do not depend on infra-
`structure services for communications, certificate
`and public key infrastructure (PKI) approaches
`for authentication do not apply directly to Blue-
`tooth piconets. Instead, the authentication of
`Bluetooth
`devices
`is
`based
`on
`a
`challenge/response mechanism based on a com-
`monly shared secret, a link key generated
`through a user-provided PIN.
`Authentication of devices may happen at any
`time during the lifetime of a connection between
`two Bluetooth devices. The authentication starts
`
`LSB
`
`MSB
`
`ACL_pld_hdr
`1 octet
`
`ACL_pld_body
`
`2 to 17 octets
`
`LMP header
`
`L_CH=b'11'
`
`tr_ID
`
`opCode
`
`LMP_payload
`
`1 (bit-count)
`
`1
`
`7
`
`8-128
`
`LMP packets are encoded with a 2/3 rate FEC
`
`I Figure 6. The LMP packet format.
`
`with the transmission of an LMP challenge pack-
`et. The challenge packet contains a random
`number generated by the challenger, which is the
`device that attempts to authenticate the other
`device. The receiver device of the challenge,
`called the claimant, operates on the challenge
`using a 128-bit authentication key. The claimant
`returns the result of the operation to the chal-
`lenger, who can then compare the result with the
`expected outcome of the operation and, thus,
`verify the identity of the claimant.
`Following device authentication, the devices
`may further encrypt the link between them to
`protect against eavesdropping. Using the link
`key, the devices will generate a sequence of
`encryption keys to encrypt their transmissions.
`The encryption key changes with each packet
`transmission. Encryption is a mutual operation,
`and encryption encrypts the whole link, both the
`asynchronous and synchronous transmissions.
`The encryption key can be up to 128 bits
`long. However, the size of the encryption keys is
`ultimately dictated by government regulations.
`The authentication and encryption keys are gen-
`erated based on the SAFER+ algorithm [2].
`
`The Low Power Modes — As with the security
`algorithms, the actual low power modes of oper-
`ation are part of the baseband. However, these
`modes can be configured and activated via LMP
`transactions, and they are highlighted here.
`In the sniff mode, a slave agrees with its mas-
`ter to listen for master transmissions periodical-
`ly, where the period is configured through LMP
`transactions.
`
`IEEE Communications Magazine • December 2001
`
`91
`
`Canon Exhibit 1017, Page 6
`
`

`

`The algorithms
`for authentication
`and encryption
`are part of the
`baseband portion
`of the Bluetooth
`specification.
`However, the act
`of authentication,
`as well as the
`negotiation for
`encrypting the
`link between two
`devices, are part
`of the LMP
`specification.
`
`L2CAP_hdr
`
`4 octets
`
`L2CAP_payload
`
`0 to 65,535 octets
`
`length
`
`dst_CID
`
`(octet-count)
`
`2
`
`2
`
`(a)
`
`(b)
`
`(c)
`
`opCode
`
`identifier
`
`length
`
`sgnl_data
`
`....
`
`1
`
`PSM
`
`2
`
`1
`
`2
`
`CL_payload
`
`CO_payload
`
`a) dst_CID = 0x'0001' (signaling channel)
`b) dst_CID =0x'0002' (connectionless channel)
`c) dst_CID > 0x'0002' (connection-oriented channel)
`
`I Figure 7. The L2CAP packet format.
`
`In the hold mode, a device agrees with its
`communicating partner in a piconet to remain
`silent (in the particular piconet) for a given
`amount of time. A device that has gone into
`hold mode does not relinquish its temporary
`address, AM_ADDR.
`Finally, in the park mode a slave device agrees
`with its master to park until further notice. As a
`device enters the park mode, the device relin-
`quishes its active member address, AM_ADDR.
`While parked, a device will periodically listen to
`beacon transmissions from the master. A device
`may be invited back to active communications
`using a broadcast transmission during a beacon
`instant. When the slave wants to be unparked, it
`would send a message to the master in the slots
`following the beacon instant.
`The above modes of operation are designed
`to reduce the power consumption of a device.
`However, they are optional features. While in
`any of these modes, a device may be involved in
`other tasks, such as entering inquiry scans, partic-
`ipating in active communications in another
`piconet, etc. Hence, the low power modes of
`operation, while designed for this purpose, enable
`additional modes of operation for a device.
`
`The Host Controller Interface (HCI) — As
`the name states, this is not a protocol per se.
`Rather, it is an interface for host devices to
`access the lower layers of the Bluetooth stack
`through a standardized interface. Through the
`HCI, a host device passes and receives data des-
`tined to or coming from another Bluetooth
`device. Also through the HCI, a host may
`instruct its baseband to create a link to a specific
`Bluetooth device, execute inquiries, request
`authentication, pass a link key to the baseband,
`request activation of a low power mode, etc. The
`HCI will not be discussed further here; for more
`information see the Bluetooth specification.
`
`The Logical Link Control & Adaptation Pro-
`tocol — The Logical Link Control & Adapta-
`tion Protocol (L2CAP) layer shields the specifics
`of the Bluetooth lower layers and provides a
`packet interface to higher layers. At the L2CAP
`
`layer, the concepts of master and slave devices
`do not exist anymore. The L2CAP supports the
`multiplexing of several logical channels over the
`device’s ACL links. Note that a slave has only
`one A