M
M/S
Figure 3: Scatternet consisting of two piconets
In the physical layer, Bluetooth supports two different types of links between Bluetooth devices:
circuit switched synchronous connections (SCO, synchronous connection oriented).
packet switched asynchronous connections (ACL, asynchronous connectionless).
SCO links are point-to-point links formed between master and specific slave, they are used for time dependent services such as voice. A master can have a maximum of three SCO links to either one slave or different slaves, while a slave can have a maximum of three SCO links to one master or one SCO link for two different masters. One voice channel supports 64 kbps of streamed voice for each direction.
ACL links are point-to-multipoint links between master and slaves in piconets and they support both asynchronous and isochronous services. There can be only one ACL link between a master and a slave. ACL links are used for data transfer with packet retrans-mission method applied, to ensure the integrity of the data. A master can broadcast to its slaves by not addressing the ACL packet to a specific slave. Asynchronous channel supports either 433.9 kbps synchronous channel or 723.3 kbps asynchronous where the return channel is 57.6 kbps.
4.3 Bluetooth protocol architecture
There are four basic protocols that all Bluetooth applying devices have to have imple-mented. These are baseband, Link Manager Protocol (LMP), Logical Link Control and Adaption Protocol (L2CAP) and Service Discovery Protocol (SDP). Baseband and LMP
reside under Host Control Interface (HCI) and are usually implemented in hardware.
Their functionality is controlled through HCI from the software of the device. L2CAP and SDP are software that is run on the Bluetooth applying device to ensure a minimum interoperatibility between all the devices using Bluetooth wireless technology. [GEH00]
Figure 4: Bluetooth protocol architecture
RFCOMM is used to emulate serial cable connection and is referred as cable replacement protocol. Higher level protocols such as PPP (Point-to-Point Protocol) and OBEX use RFCOMM. Audio connections have their own protocols. The upper layer protocols can run on top of different lower level protocols. For instance OBEX could be implemented on top of PPP or IP instead of RFCOMM. In this project the OBEX layer was implemented on top of RFCOMM as it was defined in Bluetooth profiles in chapter 4.4. Therefore it is also used in the guidance system at that place. The whole Bluetooth protocol architecture is presented in figure 4. [MET99a][KAS00]
The guidance system needs a simple protocol to enable communication between the user and the system. The chosen protocol for this is OBEX. To allow the OBEX connection, RFCOMM is needed as well as the basic lower layer Bluetooth protocols. These proto-cols are overviewed in the following chapters. How these protoproto-cols are used to create a working Bluetooth application is discussed in the chapter 4.4.
4.3.1 Lower layer protocols
Lower layer protocols are Baseband and LMP. These protocols are usually implemented in the Bluetooth chip. The communication to the chip is done through HCI, which has been defined for serial port, USB and PCMCIA. While it is good to know how these protocols work, the implementor of the guidance system does not have to deal with them.
Lower layer protocols take care of forming SCO and ACL links, frequency hopping, low level error connection, link level encryption and many other Bluetooth specific issues.
These protocols are usually implemented in the Bluetooth chip, which is called Bluetooth host.
4.3.2 HCI
Between the Bluetooth host and the software stack there is an interface called HCI, through which the functionality of the Bluetooth host can be controlled. Most of the functionality needed by the guidance system can be done by using the higher layer proto-cols. However since the upper layer protocols are specified for special needs, Bluetooth specific commands cannot be done through them. For the guidance system it means that finding out the devices on the area of guide has to be done with HCI commands. HCI is also needed to find out the unique address of the device that wants to join the guidance system, as L2CAP does not show the 32 bytes BD_ADDR but instead the user friendly name for the device like “Printer”.
4.3.3 L2CAP
L2CAP resides on top of HCI. It adapts the higher level protocols over the baseband.
L2CAP handles the link control for packets that contain upper layer payload while LMP under HCI takes care of other link controlling. L2CAP provides protocol multiplexing, segmentation and reassembling for upper layers connection oriented or connectionless data services.
4.3.4 SDP
SDP is used to find out what types of services the given device supports. This ensures that a device which has no support for audio, is not sent any audio messages. SDP is also used to find certain types of services such as printers or calendars when they are needed.
In the guidance system, SDP is needed to find out what kind of guidance messages can be sent to the user.
4.3.5 RFCOMM
RFCOMM is a serial line emulation for Bluetooth and is also referred as cable replace-ment protocol as it emulates RS-232 standard control and data signals. Many existing applications have been implemented to be used over serial cable and thus the change from cable to Bluetooth should cause very little trouble. RFCOMM protocol is also heavily influenced by IrCOMM from IrDA specification and therefore changing application to use RFCOMM instead of IrCOMM should be a fairly easy task. OBEX implementation of Lappeenranta University of Technology has been implemented over RFCOMM.
4.3.6 OBEX
OBEX is protocol adopted from IrDA specification. IrDA Object Exchange has been designed for simple data exchange between devices supporting infrared communication with IrDA protocols. The strength of OBEX is its simplicity and the good support on the portable devices already using infrared as communication medium. The chosen protocol for the guidance system is OBEX mainly for two reasons:
1. OBEX is a very light protocol but has enough functionality for the guidance system needs.
2. OBEX protocol is used on IrDA devices and therefore most of mobile devices have implemented it already.
OBEX communication bases on the model of request and response, where one device is server and another is client. Actions are initiated by the client and it can either PUSH or PULL objects to or from the server. PUSH and PULL models are presented in more detail at two theses done by workers of this project. [HUO00][KAR01] How to use OBEX is explained in the chapter 4.4 when discussing the OBEX profile.
4.3.7 WAP
Wireless Access Protocol has been developed by WAP forum [WAP01], for browsing information over a wireless communication medium. While in this thesis the chosen
technology has been OBEX, the required functionality could have been done with WAP too. The current version of Bluetooth specification do not define any use case that bases on WAP. It is expected though that in the next version of Bluetooth specification, the WAP usage is defined. The new specification can open new possibilities as OBEX is suitable only for some types of services and can be cumbersome for browsing through different information. [SEE99] [WAP01]