蓝牙协议文档

Bluetooth WHITE PAPER 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. RESPONSIBLE DATE N.B. Aug 25th 99 Riku Mettala E-MAIL ADDRESS riku.mettala@nmp.nokia.com STATUS DOCUMENT NO. 1.C.120/1.0 Bluetooth Protocol Architecture Page 2 of 20 29 September 1999 2 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 IBM Corporation Bouet, Stephane Nokia Mobile Phones Inouye, Jon Intel Corporation Mettälä, Riku Nokia Mobile Phones Miller, Brent IBM Corporation Morley, Ken 3Com Corporation Muller, Thomas Nokia Mobile Phones Roter, Martin Nokia Mobile Phones Slotboom, Erik 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. Bluetooth Protocol Architecture Page 3 of 20 29 September 1999 3 Contents 1 Introduction ......................................................................................... 4 1.1 Bluetooth Protocol Stack............................................................. 4 2 Protocols in Bluetooth Architecture.................................................. 6 2.1 Bluetooth Core Protocols ............................................................ 7 2.1.1 Baseband ....................................................................... 7 2.1.1.1 Audio................................................................ 7 2.1.2 Link Manager Protocol ................................................... 7 2.1.3 Logical Link Control and Adaptation Protocol................. 7 2.1.4 Service Discovery Protocol (SDP).................................. 8 2.2 Cable Replacement Protocol ...................................................... 8 2.2.1 RFCOMM ....................................................................... 8 2.3 Telephony Control Protocol......................................................... 8 2.3.1 Telephony Control – Binary............................................ 8 2.3.2 Telephony Control – AT Commands .............................. 8 2.4 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 3 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 4 Summary............................................................................................ 16 5 References......................................................................................... 17 6 Acronyms........................................................................................... 19 Bluetooth Protocol Architecture Page 4 of 20 Introduction 29 September 1999 4 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. Bluetooth Protocol Architecture Page 5 of 20 Introduction 29 September 1999 5 Host Controller Interface IP RFCOMM WAPOBEX Audio TCPUDP TCS BIN vCard/vCal WAE L2CAP SDP PPP AT- Commands Baseband LMP 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 UDP (User Datagram Protocol). In designing the protocols and the whole protocol stack, the main principle has been to maximize 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. Bluetooth Protocol Architecture Page 6 of 20 Protocols in Bluetooth Architecture 29 September 1999 6 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 Baseband [1], LMP [2], L2CAP [3], SDP [4] Cable Replacement Protocol RFCOMM [5] Telephony Control Protocols TCS Binary [6], AT-commands [7],[8],[9] Adopted Protocols PPP [10], UDP/TCP/IP [10], OBEX [11], WAP [12], vCard [13] , vCal [14], IrMC1 [15], WAE [16] 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 [17]. 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 07.10 [18] and the ITU-T Recommendation Q.931 [19], respectively. The Bluetooth Core protocols (plus the Bluetooth radio) are required 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 [10], 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. Bluetooth Protocol Architecture Page 7 of 20 Protocols in Bluetooth Architecture 29 September 1999 7 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 [1]. As the Bluetooth RF system is a Frequency-Hopping-Spread-Spectrum system in which packets are transmitted in defined time slots on defined frequencies, this layer uses inquiry and paging procedures to synchronize the transmission hopping frequency 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; 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 [2] 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 sizes. 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) [3] 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. Administrator 匹克网 rf：射频系统 Bluetooth Protocol Architecture Page 8 of 20 Protocols in Bluetooth Architecture 29 September 1999 8 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 64 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. Using SDP, device information, services and the characteristics of the services can be queried and after that, a connection between two or more Bluetooth devices can be established. SDP is defined in the Service Discovery Protocol specification [4]. 2.2 Cable Replacement Protocol 2.2.1 RFCOMM RFCOMM is a serial line emulation protocol and is based on ETSI 07.10 specification. This “cable replacement” protocol emulates RS-232 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 [5]. 2.3 Telephony Control Protocol 2.3.1 Telephony Control – Binary Telephony Control protocol - Binary (TCS Binary or TCS BIN) [6], 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 ITU-T Recommendation Q.931 [19], applying the symmetrical provisions as stated in Annex D of Q.931 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 3.2 and 3.6). In Bluetooth, AT-commands, which are utilized, are based on ITU-T Recommendation V.250 [20] and ETS 300 916 (GSM 07.07) [21]. In addition, the commands used for FAX services are specified by the implementation. These may be either: • Fax Class 1.0 TIA-578-A [22] and ITU T.31 Service Class 1.0 [23] Administrator 串行仿真 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 Bluetooth Protocol Architecture Page 9 of 20 Protocols in Bluetooth Architecture 29 September 1999 9 • Fax Class 2.0 TIA-592 [24] and ITU T.32 Service Class 2.0 [25] • 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 [10] and PPP-Networking is the means of taking IP packets to/from the PPP layer and placing them onto the LAN. Usage of PPP over Bluetooth is described in [26]. 2.4.2 TCP/UDP/IP These protocol standards are defined by the Internet Engineering Task Force and used for communication across the Internet [10]. Now considered as the most widely used protocol family in the world, TCP/IP stacks have appeared on numerous devices including printers, handheld computers, and mobile handsets. Access to these protocols is operating system independent, although traditionally realized 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/IP/PPP is used for the all Internet Bridge usage scenarios in Bluetooth 1.0 and for OBEX in future versions [11]. UDP/IP/PPP is also available as transport for WAP [12]. 2.4.3 OBEX Protocol IrOBEX [27] (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 realizes a reliable transport base. Along with the protocol itself, the "grammar" 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 [11]. Future implementations are likely to support also TCP/IP as a transport. 2.4.3.1 Content Formats vCard [13] and vCalendar [14] are open specifications developed by the versit consortium and now controlled by the Internet Mail Consortium. These Bluetooth Protocol Architecture Page 10 of 20 Protocols in Bluetooth Architecture 29 September 1999 10 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 [15]. 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 synchronizing data between devices. 2.4.4 WAP Hidden computing usage models can be implemented using the WAP features. Bluetooth as a WAP Bearer is defined in [12]. The Wireless Application Protocol (WAP) Forum is building a wireless protocol specification [16] 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 WAP framework is depicted. Bearers: GSM IS-136 CDMA PHS