Bluetooth WHITE PAPER
`
`DATE
`Aug 25th 99
`
`N.B.
`
`RESPONSIBLE
`Riku Mettala
`
`E-MAIL ADDRESS
`riku.mettala@nmp.nokia.com
`
`DOCUMENT NO.
`1.C.120/1.0
`
`STATUS
`
`Bluetooth Protocol Architecture
`Version 1.0
`
`This white paper describes the protocol
`architecture developed by the Bluetooth Special
`Interest Group (SIG). Various usage models are
`presented and complemented with a description
`of the protocols relevant to their implementation.
`
`Samsung Exhibit 1047
`Samsung v. Affinity
`IPR2014-01181
`Page 00001
`
`

`
`Bluetooth Protocol Architecture
`
`Page 2 of 20
`
`Special Interest Group (SIG)
`The following companies are represented in the Bluetooth Special Interest
`Group:
`Ericsson Mobile Communications AB
`IBM Corp.
`Intel Corp.
`Nokia Mobile Phones
`Toshiba Corp.
`
`Contributors
`
`Bisdikian, Chatschik
`Bouet, Stephane
`Inouye, Jon
`Mettälä, Riku
`Miller, Brent
`Morley, Ken
`Muller, Thomas
`Roter, Martin
`Slotboom, Erik
`
`IBM Corporation
`
`Nokia Mobile Phones
`
`Intel Corporation
`
`Nokia Mobile Phones
`
`IBM Corporation
`
`3Com Corporation
`
`Nokia Mobile Phones
`
`Nokia Mobile Phones
`
`Ericsson Mobile Communications AB
`
`Disclaimer and copyright notice
`
`THIS DOCUMENT IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER,
`INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS
`FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF
`ANY PROPOSAL, SPECIFICATION OR SAMPLE. All liability, including liability for
`infringement of any proprietary rights, relating to use of information in this document is
`disclaimed.
`
`No license, express or implied, by estoppel or otherwise, to any intellectual property rights are
`granted herein.
`
`Copyright © Nokia Mobile Phones 1999.
` *Third-party brands and names are the property of their respective owners.
`
` 29 September 1999
`
`2
`
`Page 00002
`
`

`
`Bluetooth Protocol Architecture
`
`Page 3 of 20
`
`Contents
`
`1
`
`2
`
`3
`
`4
`5
`6
`
`2.4
`
`2.3
`
`Introduction ......................................................................................... 4
`1.1
`Bluetooth Protocol Stack............................................................. 4
`Protocols in Bluetooth Architecture.................................................. 6
`2.1
`Bluetooth Core Protocols ............................................................ 7
`2.1.1 Baseband ....................................................................... 7
`2.1.1.1 Audio................................................................ 7
`Link Manager Protocol ................................................... 7
`2.1.2
`Logical Link Control and Adaptation Protocol................. 7
`2.1.3
`2.1.4 Service Discovery Protocol (SDP).................................. 8
`2.2 Cable Replacement Protocol ...................................................... 8
`2.2.1 RFCOMM ....................................................................... 8
`Telephony Control Protocol......................................................... 8
`2.3.1
`Telephony Control – Binary............................................ 8
`2.3.2
`Telephony Control – AT Commands .............................. 8
`Adopted Protocols....................................................................... 9
`2.4.1 PPP ................................................................................ 9
`2.4.2
`TCP/UDP/IP ................................................................... 9
`2.4.3 OBEX Protocol ............................................................... 9
`2.4.3.1 Content Formats .............................................. 9
`2.4.4 WAP............................................................................. 10
`2.4.4.1 Content Formats ............................................ 11
`Bluetooth Usage Models and Protocols ......................................... 12
`3.1
`File Transfer.............................................................................. 12
`3.2
`Internet Bridge .......................................................................... 12
`3.3
`LAN Access .............................................................................. 13
`3.4
`Synchronization ........................................................................ 14
`3.5
`Three-in-One Phone ................................................................. 14
`3.6 Ultimate Headset ...................................................................... 15
`Summary............................................................................................ 16
`References......................................................................................... 17
`Acronyms........................................................................................... 19
`
` 29 September 1999
`
`3
`
`Page 00003
`
`

`
`Bluetooth Protocol Architecture
`
`Page 4 of 20
`
`1
`
`Introduction
`
`The Bluetooth Special Interest Group (SIG) has developed the Bluetooth
`Specification Version 1.0 Draft Foundation (thereafter to be referred to as the
`”Specification”), that allows for developing interactive services and
`applications over interoperable radio modules and data communication
`protocols. The objective of this paper is to provide an overview of the
`protocols in the Specification, their capabilities and the relation to each other
`(referred to as the “Bluetooth protocol architecture”). Moreover, a number of
`usage models identified by the Bluetooth SIG will be presented and it will be
`shown how (and which of) these protocols are stacked to support these usage
`models.
`
`1.1 Bluetooth Protocol Stack
`
`The ultimate objective of the Specification is to allow applications written in a
`manner that is conformant to the Specification to interoperate with each other.
`To achieve this interoperability, matching applications (e.g., corresponding
`client and server application) in remote devices must run over identical
`protocol stacks. The following protocol list is an example of a (top-to-bottom)
`protocol stack supporting a business card exchange application: vCard →
`OBEX → RFCOMM → L2CAP → Baseband. This protocol stack contains both
`an internal object representation convention, vCard, and “over-the-air”
`transport protocols, the rest of the stack.
`
`Different applications may run over different protocol stacks. Nevertheless,
`each one of these different protocol stacks use a common Bluetooth data link
`and physical layer, see more details on the protocol layers in the next section.
`Figure 1 shows the complete Bluetooth protocol stack as identified in the
`Specification on top of which interoperable applications supporting the
`Bluetooth usage models are built. Not all applications make use of all the
`protocols shown in Figure 1. Instead, applications run over one or more
`vertical slices from this protocol stack. Typically, additional vertical slices are
`for services supportive of the main application, like TCS Binary (Telephony
`Control Specification), or SDP (Service Discovery Protocol). It is worth of
`mentioning that Figure 1 shows the relations how the protocols are using the
`services of other protocols when payload data needs to be transferred over
`air. However, the protocols may also have some other relations between the
`other protocols. E.g., some protocols (L2CAP, TCS Binary) may use LMP
`(Link Manager Protocol) when there is need to control the link manager.
`
`Introduction
`
`29 September 1999
`
`4
`
`Page 00004
`
`

`
`Bluetooth Protocol Architecture
`
`Page (cid:31) of 20
`
`vCard/vCal
`
`OBEX
`
`WAE
`
`WAP
`
`UDP
`
`TCP
`
`IP
`
`PPP
`
`RFCOMM
`
`Host Controller Interface
`
`AT-
`Commands
`
`TCS BIN
`
`SDP
`
`Audio
`
`L2CAP
`
`LMP
`
`Baseband
`
`Bluetooth Radio
`
`Figure 1 Bluetooth Protocol Stack
`
`As seen in Figure 1, the complete protocol stack comprises of both Bluetooth-
`specific protocols like LMP and L2CAP, and non-Bluetooth-specific protocols
`like OBEX (Object Exchange Protocol) and (cid:31)DP ((cid:31)ser Datagram Protocol). In
`designing the protocols and the whole protocol stack, the main principle has
`been to maximi(cid:31)e the re-use of existing protocols for different purposes at the
`higher layers, instead of re-inventing the wheel once again. The protocol re-
`use also helps to adapt existing (legacy) applications to work with the
`Bluetooth technology and to ensure the smooth operation and interoperability
`of these applications. Thus, many applications already developed by vendors
`can take immediate advantage of hardware and software systems, which are
`compliant to the Specification. The Specification is also open, which makes it
`possible for vendors to freely implement their own (proprietary) or commonly
`used application protocols on the top of the Bluetooth-specific protocols. Thus,
`the open Specification permits the development of a large number of new
`applications that take full advantage of the capabilities of the Bluetooth
`technology.
`
`Introduction
`
`29 September 1999
`
`(cid:31)
`
`Page 00005
`
`

`
`Bluetooth Protocol Architecture
`
`Page (cid:31) of 20
`
`2 Protocols in Bluetooth Architecture
`
`The Bluetooth protocol stack can be divided into four layers according to their
`purpose including the aspect whether Bluetooth SIG has been involved in
`specifying these protocols. The protocols belong into the layers in the
`following way.
`
`Protocol layer
`
`Protocols in the stack
`
`Bluetooth Core Protocols
`Cable Replacement Protocol
`Telephony Control Protocols
`Adopted Protocols
`
`Baseband (cid:31)1(cid:31), LMP (cid:31)2(cid:31), L2CAP (cid:31)(cid:31)(cid:31), SDP (cid:31)4(cid:31)
`RFCOMM (cid:31)(cid:31)(cid:31)
`TCS Binary (cid:31)(cid:31)(cid:31), AT-commands (cid:31)(cid:31)(cid:31),(cid:31)(cid:31)(cid:31),(cid:31)9(cid:31)
`PPP (cid:31)10(cid:31), (cid:31)DP(cid:31)TCP(cid:31)IP (cid:31)10(cid:31), OBEX (cid:31)11(cid:31), (cid:31) AP (cid:31)12(cid:31),
`vCard (cid:31)1(cid:31)(cid:31) , vCal (cid:31)14(cid:31), IrMC1 (cid:31)1(cid:31)(cid:31), (cid:31) AE (cid:31)1(cid:31)(cid:31)
`
`Table 1: The protocols and layers in the Bluetooth protocol stack
`
`In addition to the above protocol layers, the Specification also defines a Host
`Controller Interface (HCI), which provides a command interface to the
`baseband controller, link manager, and access to hardware status and control
`registers. This interface is not discussed further in this paper, but more
`information can be obtained from the functional specification of Bluetooth host
`controller interface (cid:31)1(cid:31)(cid:31). In Figure 1, HCI is positioned below L2CAP but this
`positioning is not mandatory but HCI can exist e.g., above L2CAP.
`
`The Bluetooth Core protocols comprise exclusively Bluetooth-specific
`protocols developed by the Bluetooth SIG. RFCOMM and the TCS binary
`protocol have also be developed by the Bluetooth SIG but they are based on
`the ETSI TS 0(cid:31).10 (cid:31)1(cid:31)(cid:31) and the IT(cid:31)-T Recommendation (cid:31).9(cid:31)1 (cid:31)19(cid:31),
`respectively. The Bluetooth Core protocols (plus the Bluetooth radio) are
`re(cid:31)uired by most of Bluetooth devices, while the rest of the protocols are used
`only as needed.
`
`Together, the Cable Replacement layer, the Telephony Control layer, and the
`Adopted protocol layer form application-oriented2 protocols enabling
`applications to run over the Bluetooth Core protocols. As mentioned earlier,
`the Bluetooth Specification is open and additional protocols (e.g., HTTP, FTP
`(cid:31)10(cid:31), etc.) can be accommodated in an interoperable fashion on top of the
`Bluetooth-specific transport protocols or on top of the application-oriented
`protocols shown in Figure 1.
`
`
`1 Not shown above OBEX in Figure 1.
`2 “Application-oriented” here is with respect to Bluetooth transport services and should be
`interpreted as any protocol layer, or application that runs on top of the Bluetooth-specific
`transport protocols.
`
`Protocols in Bluetooth Architecture 29 September 1999
`
`(cid:31)
`
`Page 00006
`
`

`
`Bluetooth Protocol Architecture
`
`Page (cid:31) of 20
`
`2.1 Bluetooth Core Protocols
`2.1.1 Baseband
`
`The Baseband and Link Control layer enables the physical RF link between
`Bluetooth units forming a piconet (cid:31)1(cid:31). As the Bluetooth RF system is a
`Fre(cid:31)uency-Hopping-Spread-Spectrum system in which packets are
`transmitted in defined time slots on defined fre(cid:31)uencies, this layer uses in(cid:31)uiry
`and paging procedures to synchroni(cid:31)e the transmission hopping fre(cid:31)uency
`and clock of different Bluetooth devices.
`
`It provides 2 different kind of physical links with their corresponding baseband
`packets, Synchronous Connection-Oriented (SCO) and Asynchronous
`Connectionless (ACL) which can be transmitted in a multiplexing manner on
`the same RF link. ACL packets are used for data only, while the SCO packet
`can contain audio only or a combination of audio and data. All audio and data
`packets can be provided with different levels of FEC or CRC error correction
`and can be encrypted.
`
`Furthermore, the different data types, including link management and control
`messages, are each allocated a special channel.
`
`2.1.1.1 Audio
`
`Audio data can be transferred between one or more Bluetooth devices,
`making various usage models possible and audio data in SCO packets is
`routed directly to and from Baseband and it does not go through L2CAP.
`Audio model is relatively simple within Bluetooth(cid:31) any two Bluetooth devices
`can send and receive audio data between each other just by opening an audio
`link.
`
`2.1.2 Link Manager Protocol
`
`The link manager protocol (cid:31)2(cid:31) is responsible for link set-up between Bluetooth
`devices. This includes security aspects like authentication and encryption by
`generating, exchanging and checking of link and encryption keys and the
`control and negotiation of baseband packet si(cid:31)es.
`
`Furthermore it controls the power modes and duty cycles of the Bluetooth
`radio device, and the connection states of a Bluetooth unit in a piconet.
`
`2.1.3 Logical Link Control and Adaptation Protocol
`
`The Bluetooth logical link control and adaptation protocol (L2CAP) (cid:31)(cid:31)(cid:31) adapts
`upper layer protocols over the baseband. It can be thought to work in parallel
`with LMP in difference that L2CAP provides services to the upper layer when
`the payload data is never sent at LMP messages.
`
`Protocols in Bluetooth Architecture 29 September 1999
`
`(cid:31)
`
`Page 00007
`
`

`
`Bluetooth Protocol Architecture
`
`Page (cid:31) of 20
`
`L2CAP provides connection-oriented and connectionless data services to the
`upper layer protocols with protocol multiplexing capability, segmentation and
`reassembly operation, and group abstractions. L2CAP permits higher level
`protocols and applications to transmit and receive L2CAP data packets up to
`(cid:31)4 kilobytes in length.
`
`Although the Baseband protocol provides the SCO and ACL link types,
`L2CAP is defined only for ACL links and no support for SCO links is specified
`in Bluetooth Specification 1.0.
`
`2.1.4 Service Discovery Protocol (SDP)
`
`Discovery services are crucial part of the Bluetooth framework. These services
`provide the basis for all the usage models. (cid:31)sing SDP, device information,
`services and the characteristics of the services can be (cid:31)ueried and after that,
`a connection between two or more Bluetooth devices can be established. SDP
`is defined in the Service Discovery Protocol specification (cid:31)4(cid:31).
`
`2.2 Cable Replacement Protocol
`2.2.1 RFCOMM
`
`RFCOMM is a serial line emulation protocol and is based on ETSI 0(cid:31).10
`specification. This “cable replacement” protocol emulates RS-2(cid:31)2 control and
`data signals over Bluetooth baseband, providing both transport capabilities for
`upper level services (e.g. OBEX) that use serial line as transport mechanism.
`RFCOMM is specified in (cid:31)(cid:31)(cid:31).
`
`2.3 Telephony Control Protocol
`2.3.1 Telephony Control – Binary
`
`Telephony Control protocol - Binary (TCS Binary or TCS BIN) (cid:31)(cid:31)(cid:31), a bit-
`oriented protocol, defines the call control signaling for the establishment of
`speech and data calls between Bluetooth devices. In addition, it defines
`mobility management procedures for handling groups of Bluetooth TCS
`devices. TCS Binary is specified in the Bluetooth Telephony Control protocol
`Specification Binary, which is based on the IT(cid:31)-T Recommendation (cid:31).9(cid:31)1
`(cid:31)19(cid:31), applying the symmetrical provisions as stated in Annex D of (cid:31).9(cid:31)1
`
`2.3.2 Telephony Control – AT Commands
`
`Bluetooth SIG has defined the set of AT-commands by which a mobile phone
`and modem can be controlled in the multiple usage models (See Chapters (cid:31).2
`and (cid:31).(cid:31)). In Bluetooth, AT-commands, which are utili(cid:31)ed, are based on IT(cid:31)-T
`Recommendation V.2(cid:31)0 (cid:31)20(cid:31) and ETS (cid:31)00 91(cid:31) (GSM 0(cid:31).0(cid:31)) (cid:31)21(cid:31). In addition,
`the commands used for FAX services are specified by the implementation.
`These may be either:
`• Fax Class 1.0 TIA-(cid:31)(cid:31)(cid:31)-A (cid:31)22(cid:31) and IT(cid:31) T.(cid:31)1 Service Class 1.0 (cid:31)2(cid:31)(cid:31)
`
`Protocols in Bluetooth Architecture 29 September 1999
`
`(cid:31)
`
`Page 00008
`
`

`
`Bluetooth Protocol Architecture
`
`Page 9 of 20
`
`• Fax Class 2.0 TIA-(cid:31)92 (cid:31)24(cid:31) and IT(cid:31) T.(cid:31)2 Service Class 2.0 (cid:31)2(cid:31)(cid:31)
`• Fax Service Class 2 - No industry standard
`2.4 Adopted Protocols
`2.4.1 PPP
`
`In the Bluetooth technology, PPP is designed to run over RFCOMM to
`accomplish point-to-point connections. PPP is the IETF Point-to-Point Protocol
`(cid:31)10(cid:31) and PPP-Networking is the means of taking IP packets to(cid:31)from the PPP
`layer and placing them onto the LAN. (cid:31)sage of PPP over Bluetooth is
`described in (cid:31)2(cid:31)(cid:31).
`
`2.4.2 TCP/UDP/IP
`
`These protocol standards are defined by the Internet Engineering Task Force
`and used for communication across the Internet (cid:31)10(cid:31). Now considered as the
`most widely used protocol family in the world, TCP(cid:31)IP stacks have appeared
`on numerous devices including printers, handheld computers, and mobile
`handsets. Access to these protocols is operating system independent,
`although traditionally reali(cid:31)ed using a socket programming interface model.
`The implementation of these standards in Bluetooth devices allows for
`communication with any other device connected to the Internet: The Bluetooth
`device, should it be a Bluetooth cellular handset or a data access point for
`example is then used as a bridge to the Internet.
`
`TCP(cid:31)IP(cid:31)PPP is used for the all Internet Bridge usage scenarios in Bluetooth
`1.0 and for OBEX in future versions (cid:31)11(cid:31). (cid:31)DP(cid:31)IP(cid:31)PPP is also available as
`transport for (cid:31) AP (cid:31)12(cid:31).
`
`2.4.3 OBEX Protocol
`
`IrOBEX (cid:31)2(cid:31)(cid:31) (shortly OBEX) is a session protocol developed by the Infrared
`Data Association (IrDA) to exchange objects in a simple and spontaneous
`manner. OBEX, which provides the same basic functionality as HTTP but in a
`much lighter fashion, uses a client-server model and is independent of the
`transport mechanism and transport API, provided it reali(cid:31)es a reliable
`transport base. Along with the protocol itself, the (cid:31)grammar(cid:31) for OBEX
`conversations between devices, OBEX also provides a model for representing
`objects and operations. In addition, the OBEX protocol defines a folder-listing
`object, which is used to browse the contents of folders on remote device.
`
`In the first phase, RFCOMM is used as sole transport layer for OBEX (cid:31)11(cid:31).
`Future implementations are likely to support also TCP(cid:31)IP as a transport.
`
`2.4.3.1 Content Formats
`
`vCard (cid:31)1(cid:31)(cid:31) and vCalendar (cid:31)14(cid:31) are open specifications developed by the versit
`consortium and now controlled by the Internet Mail Consortium. These
`
`Protocols in Bluetooth Architecture 29 September 1999
`
`9
`
`Page 00009
`
`

`
`Bluetooth Protocol Architecture
`
`Page 10 of 20
`
`specifications define the format of an electronic business card and personal
`calendar entries and scheduling information, respectively. vCard and
`vCalendar do not define any transport mechanism but only the format under
`which data is transported. By adopting the vCard and vCalendar, the SIG will
`help further promote the exchange of personal information under these well-
`defined and supported formats. The vCard and vCalendar specifications are
`available from the Internet Mail Consortium and are being further developed
`by the Internet Engineering Task Force (IETF).
`
`Other content formats, which are transferred by OBEX in Bluetooth, are
`vMessage and vNote (cid:31)1(cid:31)(cid:31). These content formats are also open standards
`and are used to exchange messages and notes. They are defined in the IrMC
`specification, which also defines a format for the log files that are needed
`when synchroni(cid:31)ing data between devices.
`
`2.4.4 WAP
`
`Hidden computing usage models can be implemented using the (cid:31) AP
`features. Bluetooth as a (cid:31) AP Bearer is defined in (cid:31)12(cid:31).
`
`The (cid:31) ireless Application Protocol ((cid:31) AP) Forum is building a wireless protocol
`specification (cid:31)1(cid:31)(cid:31) that works across a variety of wide-area wireless network
`technologies. The goal is to bring Internet content and telephony services to
`digital cellular phones and other wireless terminals. In Figure 2, the protocol
`stack of the (cid:31) AP framework is depicted.
`
`Applicartion Layer (WAE)
`
`Session Layer (WSP)
`
`Transaction Layer (WTP)
`
`Security Layer (WTLS)
`
`Transport Layer (WDP)
`
`Other Services and
`Applications
`
`Bearers:
`GSM
`
`IS-136
`
`CDMA
`
`PHS
`
`CDPD
`
`PDC-P
`
`Etc…
`
`Figure 2 WAP Framework
`
`The idea behind the choice of (cid:31) AP is to reuse the upper software applications
`developed for the (cid:31) AP Application Environment ((cid:31) AE). These include (cid:31) ML
`and (cid:31) TA browsers that can interact with applications on the PC. Building
`application gateways which mediate between (cid:31) AP servers and some other
`application on the PC makes it possible to implement various hidden
`
`Protocols in Bluetooth Architecture 29 September 1999
`
`10
`
`Page 00010
`
`

`
`Bluetooth Protocol Architecture
`
`Page 11 of 20
`
`computing functionality, like remote control, data fetching from PC to handset
`etc. (cid:31) AP servers also allow for both content push and pull between PC and
`handset, bringing to life concepts like information kiosks.
`
`(cid:31) AP framework also opens up the possibility of custom applications for
`handsets that use (cid:31) ML and (cid:31) ML Script as (cid:31)universal(cid:31) Software Development
`(cid:31)it.
`
`2.4.4.1 Content Formats
`
`Supported content formats for (cid:31) AP over Bluetooth are (cid:31) ML, (cid:31) MLScript,
`(cid:31) TA event, (cid:31) BMP, and vCard(cid:31)vCal. These are all part of (cid:31) AE. More
`information on (cid:31) AE can be found from (cid:31)1(cid:31)(cid:31).
`
`Protocols in Bluetooth Architecture 29 September 1999
`
`11
`
`Page 00011
`
`

`
`Bluetooth Protocol Architecture
`
`Page 12 of 20
`
`3 Bluetooth Usage Models and Protocols
`
`In this chapter, the highest priority usage models identified by the SIG(cid:31)s
`marketing group are briefly introduced. Each usage model is accompanied by
`a Profile. Profiles define the protocols and protocol features supporting a
`particular usage model. Bluetooth SIG has specified the profiles for these
`usage models. In addition to these profiles, there are four general profiles that
`are widely utili(cid:31)ed by these usage model oriented profiles. These are the
`generic access profile (GAP) (cid:31)2(cid:31)(cid:31), the serial port profile (cid:31)29(cid:31), the service
`discovery application profile (SDAP) (cid:31)(cid:31)0(cid:31), and the generic object exchange
`profile (GOEP) (cid:31)(cid:31)1(cid:31).
`
`3.1 File Transfer
`
`The file transfer usage model (See also the file transfer profile (cid:31)(cid:31)2(cid:31)) offers the
`ability to transfer data objects from one device (e.g., PC, smart-phone, or
`PDA) to another. Object types include, but are not limited to, .xls, .ppt, .wav,
`.jpg, and .doc files, entire folders or directories or streaming media formats.
`Also, this usage model offers a possibility to browse the contents of the folders
`on a remote device.
`
`In addition, simple push and exchange operations, e.g., business card
`exchange are covered in the object push profile (cid:31)(cid:31)(cid:31)(cid:31), with vCard specified as
`the format for pushed business card content.
`
`In Figure (cid:31), the re(cid:31)uired protocol stack presented for this usage model is
`presented. The figure does not show the LMP, Baseband, and Radio layers
`although those are used underneath (See Figure 1).
`
`File Transfer application
`
`OBEX
`
`RFCOMM
`
`SDP
`
`L2CAP
`
`Figure 3 Protocol Stack for File Transfer Applications
`
`3.2 Internet Bridge
`
`In this usage model, mobile phone or cordless modem acts as modem to the
`PC, providing dial-up networking (cid:31)(cid:31)(cid:31) and fax (cid:31)9(cid:31) capabilities without need for
`
`Bluetooth (cid:31)sage Models and Protocols29 September 1999
`
`12
`
`Page 00012
`
`

`
`Bluetooth Protocol Architecture
`
`Page 1(cid:31) of 20
`
`physical connection to the PC. The dial-up networking scenario of this usage
`model needs a two-piece protocol stack (in addition to the SDP branch), which
`is shown in Figure 4. The AT-commands are needed to control the mobile
`phone or modem and another stack (E.g., PPP over RFCOMM) to transfer
`payload data. The fax scenario has a similar protocol stack but PPP and the
`networking protocols above PPP are not used and the application software
`sends a facsimile directly over RFCOMM.
`
`Modem Emulation or Driver application
`
`AT-commands
`
`PPP
`
`SDP
`
`RFCOMM
`
`RFCOMM
`
`L2CAP
`
`Figure 4 Dial-up Networking Protocol Stack
`
`3.3 LAN Access
`
`In this usage model (See also the LAN access profile (cid:31)2(cid:31)(cid:31)), multiple data
`terminals (DTs) use a LAN access point (LAP) as a wireless connection to a
`Local Area Network (LAN). Once connected, the DTs operate as if it they were
`connected to the LAN via dialup networking. The DT can access all of the
`services provided by the LAN. The protocol stack is nearly identical to the
`protocol stack in the Internet bridge usage model except that the AT-
`commands are not used. The protocol stack is represented in Figure (cid:31).
`
`LAN Access application
`
`E.g. IP
`
`PPP
`
`SDP
`
`RFCOMM
`
`L2CAP
`
`Figure 5 Protocol Stack of LAN Access (PPP) Usage Model
`
`Bluetooth (cid:31)sage Models and Protocols29 September 1999
`
`1(cid:31)
`
`Page 00013
`
`

`
`Bluetooth Protocol Architecture
`
`Page 14 of 20
`
`3.4 Synchronization
`
`The synchroni(cid:31)ation usage model (cid:31)(cid:31)4(cid:31) provides a device-to-device (phone,
`PDA, computer, etc.) synchroni(cid:31)ation of the PIM (personal information
`management) information, typically phonebook, calendar, message, and note
`information. Synchroni(cid:31)ation re(cid:31)uires business card, calendar and task
`information to be transferred and processed by computers, cellular phones
`and PDAs utili(cid:31)ing a common protocol and format. The protocol stack for this
`usage model is presented in Figure (cid:31). In the figure, the synchroni(cid:31)ation
`application block represents either an IrMC client or an IrMC server software.
`
`Synchronization application
`
`IrMC
`
`OBEX
`
`SDP
`
`RFCOMM
`
`L2CAP
`
`Figure 6 Protocol Stack for Synchronization
`
`3.5 Three-in-One Phone
`
`Telephone handsets built to this profile may connect to three different service
`providers. First, telephones may act as cordless phones connecting to the
`public switched telephone network (PSTN) at home or the office and incurring
`a fixed line charge. This scenario (cid:31)(cid:31)(cid:31)(cid:31) includes making calls via a voice
`basestation, making direct calls between two terminals via the basestation and
`accessing supplementary services provided by an external network. Second,
`telephones can connect directly to other telephones for the purpose of acting
`as a “walkie-talkie” or handset extension. Referred to as the intercom scenario
`(cid:31)(cid:31)(cid:31)(cid:31), the connection incurs no additional charge. Third, the telephone may act
`as a cellular phone connecting to the cellular infrastructure and incurring
`cellular charges. The cordless and intercom scenarios use the same protocol
`stack, which is shown in Figure (cid:31). The audio stream is directly connected to
`the Baseband protocol indicated by the L2CAP bypassing audio arrow.
`
`Bluetooth (cid:31)sage Models and Protocols29 September 1999
`
`14
`
`Page 00014
`
`

`
`Bluetooth Protocol Architecture
`
`Page 1(cid:31) of 20
`
`Cordless Phone or Basestation application
`
`TCS-BIN
`
`SDP
`
`Audio
`
`L2CAP
`
`Figure 7 Protocol Stack for Cordless Phone and Intercom Scenarios
`
`3.6 Ultimate Headset
`
`The headset can be wirelessly connected for the purpose of acting as a
`remote device(cid:31)s audio input and output interface. The headset increases the
`user(cid:31)s freedom of movement while maintaining call privacy. A common
`example is a scenario where a headset is used with either a cellular handset,
`cordless handset, or personal computer for audio input and output. The
`protocol stack for this usage model is depicted in Figure (cid:31) (cid:31)(cid:31)(cid:31). The audio
`stream is directly connected to the Baseband protocol indicated by the L2CAP
`bypassing audio arrow. The headset must be able to send AT-commands and
`receive result codes. This ability allows the headset to answer incoming calls
`and then terminate them without physically manipulating the telephone
`handset.
`
`HS Gateway or Headset application
`
`AT-commands
`
`RFCOMM
`
`L2CAP
`
`SDP
`
`Audio
`
`Figure 8 Ultimate Headset Protocol Stack
`
`Bluetooth (cid:31)sage Models and Protocols29 September 1999
`
`1(cid:31)
`
`Page 00015
`
`

`
`Bluetooth Protocol Architecture
`
`Page 1(cid:31) of 20
`
`4 Summary
`
`The Bluetooth protocols are intended for rapidly developing applications using
`the Bluetooth technology. The lower layers of the Bluetooth protocol stack are
`designed to provide a flexible base for further protocol development. Other
`protocols, such as RFCOMM, are adopted from existing protocols and these
`protocols are only modified slightly for the purposes of Bluetooth. The upper
`layer protocols are used without modifications. In this way, existing
`applications may be reused to work with the Bluetooth technology and the
`interoperability is ensured more easily.
`
`The purpose of the Specification is to promote the development of
`interoperable applications targeted at the highest priority usage models
`identified by the SIG(cid:31)s marketing team. However, the Specification also
`services as a framework for further development. Naturally, vendors are
`encouraged to invent more usage models within this framework. (cid:31)sing the
`Bluetooth technology with the capabilities of current computers and
`communications devices, the possibilities for new future wireless applications
`are unlimited.
`
`Summary
`
`29 September 1999
`
`1(cid:31)
`
`Page 00016
`
`

`
`Bluetooth Protocol Architecture
`
`Page 1(cid:31) of 20
`
`5 References
`
`(cid:31)1(cid:31) Bluetooth Special Interest Group, Baseband Specification
`(cid:31)2(cid:31) Bluetooth Special Interest Group, LMP Specification
`(cid:31)(cid:31)(cid:31) Bluetooth Special Interest Group, L2CAP Specification
`(cid:31)4(cid:31) Bluetooth Special Interest Group, SDP Specification
`(cid:31)(cid:31)(cid:31) Bluetooth Special Interest Group, RFCOMM with TS 0(cid:31).10
`(cid:31)(cid:31)(cid:31) Bluetooth Special Interest Group, Telephony Control Protocol
`Specification
`(cid:31)(cid:31)(cid:31) Bluetooth Special Interest Group, Headset Profile
`(cid:31)(cid:31)(cid:31) Bluetooth Special Interest Group, Dial-(cid:31)p Networking Profile
`(cid:31)9(cid:31) Bluetooth Special Interest Group, Fax Profile
`(cid:31)10(cid:31) Internet Engineering Task Force, IETF Directory List of RFCs
`(http:(cid:31)(cid:31)www.ietf.org(cid:31)rfc(cid:31)), (cid:31)uly 1999.
`(cid:31)11(cid:31) Bluetooth Special Interest Group, IrDA Interoperability
`(cid:31)12(cid:31) Bluetooth Special Interest Group, Interoperability Re(cid:31)uirements for
`Bluetooth as a (cid:31) AP Bearer
`(cid:31)1(cid:31)(cid:31) The Internet Mail Consortium, vCard - The Electronic Business Card
`Exchange Format, Version 2.1, September 199(cid:31).
`(cid:31)14(cid:31) The Internet Mail Consortium, vCalendar - The Electronic Calendaring
`and Scheduling Exchange Format, Version 1.0, September 199(cid:31).
`(cid:31)1(cid:31)(cid:31) Infrared Data Association, IrMC (Ir Mobile Communications)
`Specification, Version 1.1, February 1999.
`(cid:31)1(cid:31)(cid:31) (cid:31) AP Forum, (cid:31) AP Forum Specifications
`(http:(cid:31)(cid:31)www.wapforum.org(cid:31)what(cid:31)technical.htm), (cid:31)uly 1999
`(cid:31)1(cid:31)(cid:31) Bluetooth Special Interest Group, Bluetooth Host Controller Interface
`Functional Specification
`(cid:31)1(cid:31)(cid:31