Short Range Radio Protocols: Bluetooth and IR

Abstract

The main topic of discussion in this chapter is short range radio protocols for wireless personal area network. Bluetooth is a radio based communication protocol which was initially conceived as a cable replacement technology for personal computers. It has also been increasingly used for data access and peer to peer ad hoc network connectivity. Yet, its primary use is in the domain of person centric communication such as mobile headphones, and other wearable accessories. Infrared, on the other hand, is a limited range optical wireless communication technology which provides interference free line of sight communication within a short range. IR has been used for robust connectivity between high precision equipment in avionics, medical and military hardware. The chapter provides protocol level details of both IR and Bluetooth.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

A personal communication model is defined in terms of a person’s interactions in three spaces [10], namely,

• 1. Personal space,

• 2. Immediate neighborhood, and

• 3. The rest of the world

A personal space is centered around a person, or in close vicinity of the person. An immediate neighborhood is the community where a person lives in. The rest of the world is the space outside the community of a person. The description of personal communication model (given above) though generic, looks imprecise. The space boundaries are loosely defined. So, there is a need to concretize the space modeling through practical examples. The Book of Visions 2000 [10] describes three typical scenarios, namely, (i) a smart healthy home, (ii) a professional environment, and (iii) a futuristic multimedia traveler. Customized extensions of these scenarios can be found in military environment too [4].

An example oriented modeling creates more confusion instead of eliminating the ambiguities. It is, therefore, important to abstract out the definitions of the spaces via use-case semantics. For example, the person centric communication space originates from a user’s interaction requirements around the close proximity. A person’s close proximity is defined through the wearable and the portable devices on the person’s body. A person’s apparels, and PDAs or laptops form a Personal Area Network (PAN) [5]. The reach of a PAN is only a few meters centered around a person. But it offers capabilities to communicate with the person’s community as well as with the rest of the world via wired or wireless backbones. The communication among the members in a community is facilitated by Community Area Network (CAN) [11], while communication outside CAN is handled through Wide Area Network (WAN). A PAN may be wired or wireless. A wired PAN uses a USB or an IEEE 1394 interface (serial bus) for the network connectivity. Wireless PANs are formed using wireless network technologies like Infra Red, Bluetooth, Ultra-wideband (UWB) [9], HomeRF [8], Z-wave [13], or ZigBee [2].

The purpose of this chapter is to discuss about two popular wireless personal area communication technologies, namely, Infra Red, Bluetooth. ZigBee, on the other hand, is a PAN communication technology that is more relevant to machine two machine communication. ZigBee protocol is, therefore, discussed separately in the following chapter.

Bluetooth is originally conceived as a wireless technology for replacing cables connecting portable and fixed devices located within a short distance from one another. The main focus of development in Bluetooth is the interoperability of the devices manufactured by different vendors. So, Bluetooth cannot just be considered as a wireless communication interface, but it should allow devices to discover, explore and utilize services offered by one another.

Infra Red (IR) is not based on radio communication. It provides optical wireless communication in unregulated space. IR network adapters can offer virtually unlimited bandwidth. It is easy to confine IR signals by opaque barriers in the line of sight (LOS). Therefore, IR provides low cost secure communication which is ideal for WPAN.

2 Bluetooth

Bluetooth specification [6] defines a radio based short range, low power wireless communication technology. Bluetooth was initially conceived and developed by Ericson as a cable replacement technology for connecting peripherals and accessories such as headphone, keyboards to devices like laptops, desktops, mobile phones, tablets, etc. Since then it has evolved as an industry standard for short range radio based wireless communication technology for Personal Area Network (PAN). It is, therefore, appropriate to view Bluetooth as wireless communication technology for PAN of all the devices tied to the personal operating space of an individual. Bluetooth network operates like a seamless peer-to-peer, self configurable, one hop network. It is different from WLAN. Bluetooth needs a host for its existence, whereas WLAN is a network component and independent of a host. IEEE 802.15.1 [5] standard (released in 2002) reviewed Bluetooth technology and provided additional resources for implementing Bluetooth on devices.

A Bluetooth radio works in 2.4 GHz unlicensed Radio Frequency (RF) band. It forms an 1-hop ad hoc network using frequency hopping spread spectrum, which hops 1600 times per second between 79 frequencies in the frequency band from 2.402 to 2.48 GHz. Each frequency channel is of 1 MHz wide. Frequency switching time is 220 $\upmu$s. Bluetooth supports a maximum data rate of 710 kbps with a maximum packet size exceeding 300 bytes.

Depending on transmit power requirements, Bluetooth devices can be classified into three classes:

• 1. Class 1: up to 100 mW, but the devices dynamically adjust their requirements to avoid interferences with other devices.

• 2. Class 2: up to 2.4 mW, and

• 3. Class 3: up to 1 mW.

Three principal usage models for Bluetooth network have been described by Fig. 5.1. These include:

Fig. 5.1

Bluetooth network

• 1. Cable replacement,

• 2. Data access, and

• 3. Peer to peer ad hoc connection.

The primary use of Bluetooth is a person centric communication technology is rooted at connecting laptops with cell phones, mouse, headphones and other accessories without wires. The second most important use of Bluetooth is for LAN and Internet connectivity. A cell phone can be turned into a wireless hot spot to which devices can hook up to the Internet via Bluetooth connectivity. Likewise, GPRS or CDMA based public pay phones at the airports can be upgraded to work as Bluetooth modems and allow Internet access to the travelers. Of course, this has to be made possible by the assistance of higher-level protocols such as PPP on the top of serial port. The other main use of Bluetooth is to create an ad hoc peer to peer network of devices for person centric services.

The usage models dictate some of the engineering challenges in the operations of a Bluetooth network.

• Flexible application topology: Bluetooth devices should have capabilities to choose and connect to the peers in its neighborhood.

• Self configurable: Even with the constraints of selective connectivity requirements, Bluetooth should still be self configurable. The users will find it too complicated to use, unless a Bluetooth device figures out by itself whom should it or should it not talk, and how.

• QoS for voice: Bluetooth must be able to provide QoS support for voice communication.

• Low power operation: Since, Bluetooth is primarily positioned as a communication technology for PAN, the power requirement to support its capability must be very low. If there is a need for frequent recharging of battery then the users would find it irritating to use Bluetooth.

• Small form factor: The portability requirements for the PAN devices enforce the requirement for a small form factor for these devices. Adding Bluetooth capabilities should not cause an increase in size of the devices.

• Low cost: Though it will be convenient to have Bluetooth replace cables, the cost factor cannot be ignored. So, Bluetooth enabled devices should not be more expensive than their wired counterparts.

A set of Bluetooth nodes, sharing a common channel, consists of at most 8 nodes organized in the form of a star topology. One of these (center of star) is called the master, and the remaining nodes are known as slaves. This basic star topology is referred to as a piconet [3]. It is possible to extend a piconet by merging two or more piconets to form a what is known as a scatternet. When a device is present in more than one piconets, it should time-share and synchronize with the masters of the respective piconets to avoid interference. As shown in Fig. 5.2, a node common to two piconet, known as a bridge and may be a slave in both piconets. The bridge node may also act as a master in one piconet and slave in the other. The master node controls transmission schedule of all devices in piconet.

Fig. 5.2

Piconets and scatternet

Bluetooth devices waiting to be connected to a piconet are in standby or listening mode. In this mode, the radios of the devices waiting to be discovered by other radios of other devices or for a request to be connected to the piconet. The process of discovery is triggered by an inquiry command by a Bluetooth device. The listening radios respond with their FHS (Frequency Hopping Sequence) packets. It provides the inquiring node a list of all the Bluetooth devices in the range with their respective Global ID (GID). To establish a connection, the master node pages a responding slave with its own GID. The paged radio then responds giving its GID. Following this the master node’s radio sends an FHS packet to the slave. The paged slave then loads master’s GID, adjusts its own clock offset to synchronize with the master’s clock, and this completes the establishment of a connection.

When a Bluetooth device joins a piconet, it gets a 3-bit Active Member Address (AMA). After a piconet has 8 members (including the master), the master can take subsequent slave devices and put them on park mode in the piconet. The radios of parked devices are synchronized with the master’s clock, but are assigned 8-bit Passive Member Addresses (PMA) instead of 3-bit AMAs. AMA and PMA combination allow up to 256 radios to reside in a piconet. However, only eight of these can be active at any time. The parked radios listen at a beacon interval to get any data addressed to them.

Fig. 5.3

Functional overview of piconet

Figure 5.3 gives a functional overview of forming and maintaining a piconet. Apart from the park mode, a Bluetooth device can be in two other low power modes: (i) sniff, and (ii) hold as shown in above figure. In the sniff state, a device can be told to transmit data on specific intervals. For example, the keyboard of desktop can be asked to send data after 25 slots. However, in the hold state no data transmission can take place. The park state differs from the two low power states mentioned above. In the parked state, a Bluetooth device keeps its radio synchronized with the master device, and a PMA, instead of an AMA, is assigned to it. A parked device can become active on receiving a wakeup call from the master. On each beacon interval, it looks for a wakeup call from the master and finds out (i) if the device has been asked to become active, or (ii) wishes to become active, or (iii) have been sent any broadcast data.

Bluetooth supports two types of physical links :

• 1. Synchronous Connection Oriented (SCO), and

• 2. Asynchronous Connection Less (ACL).

A SCO link is a point to point link between a master and a slave. Typically, SOC links carry voice transmissions, and use only reserved time slots. A master can support upto 3 SCO links to one or multiple slaves. A slave can also support upto 3 links to the same master, but can support only two SCO links to different masters. The master transmits to a slave in its own reserved time slot (even numbered) while the slave responds in the following slave-to-master time slot (odd numbered). SCO packets are just single slot packets, and none of them carries a CRC. Since Bluetooth uses Forward Error Correction (FEC) code and a slot time is very small, the degradation of voice transmission is not noticeable even in a noisy environment. Therefore, SCO packets are never retransmitted. ACL links are used for data transmission. There can be just one ACL link per piconet. Only the addressed slave can respond to data transmission by the master. Though ACL can also use FEC in payload, automatic repeat request (ARQ) can also be applied causing packets to be retransmitted.

2.1 Packet Format

Time division multiplexing is used to share channel across multiple slaves . Each channel is divided into slots. The master node determines the slot time in which a slave sould transmit. The slaves can sleep during inactive slots. A slot time is 625 $\upmu$s. The slots are numbered from 0 to $2^{27}-1$ using master node’s clock time with cycle of length $2^{27}$. A 28 bit counter is used for the clock which wraps around after $2^{28}-1$. The length of one clock tick is 312.5 $\upmu$s. So, a slot consists of 2 clock ticks, and a Bluetooth clock ticks at the rate of 3.2 kHz. The repetition interval for the clock is approximately 23 h.

The transmission of packets between a master and a slave is illustrated in Fig. 5.4. A Bluetooth packet or frame may be of 1, 3 or 5 slots long. With single slot packets a maximum data rate of 172 kbps can be reached. However, with multislot packets, higher data rates due to reduction in the packet header overhead and better turn around time. A single slot packet can hop at the rate of $1/(625\times 10^{-6}) = 1600$ hops per second.

Fig. 5.4

Transmission slots of master and slaves

A 5-slot packet has a payload of 341 bytes or 2728 bits. The total time for a 5-slot transmission should also include 1 extra slot for transmission of acknowledgement (ACK) from the master. Since a slot is 2 ticks long, in 12 clock ticks 2728 bits are transmitted. The time required for the same is $6\times 625\,\upmu$s = 3.75 ms, giving a maximum bandwidth = (2728/0.00375) bits per second, or 710 kbps. A comparison of single slot and multi-slots packet is shown in Fig. 5.5. The figure also identifies the transmission slots TX and RX.

Fig. 5.5

Single slot and multi slot Bluetooth packets

Fig. 5.6

Frame format for Bluetooth network

The structure of a Bluetooth frame is shown in Fig. 5.6. Each Bluetooth frame starts with a 72-68 bits long access code. It consists of a preamble, a sync word, and a trailer. A fixed zero-one pattern of 4 symbols defines a preamble. It is used to signal the arrival of a packet at a receiver. Sync word is used for timing synchronization with the receiver. A 4 bit trailer gets appended to the sync word if packet header follows immediately thereafter. So, the length of access code is dependent on the presence of the packet header. If the packet header is present then the length access code is 72 bits, otherwise it is 68 bits.

Access codes are of three types:

• 1. Channel Access Code (CAC): identifies a piconet with the master’s ID. All packets sent over same piconet channel will have same channel access code.

• 2. Device Access Code (DAC): used for special signaling requirements such as paging and response to paging.

• 3. Inquiry Access Code (IAC): has two subtypes, namely, General IAC (GIAC) and Dedicated group IAC (DIAC). GIAC is used to inquire about any Bluetooth device while DIAC is used to inquire about group of devices that share a common characteristic.

The packet header, if present, consists of 18 bits. To avoid retransmission, rate 1/3rd FEC is used. In this FEC scheme, each bit is transmitted 3 times and a triplet of bit is mapped to the majority bit in the same. So, total length of the header becomes $18 \times 3 = 54$ bits.

Fig. 5.7

Bluetooth packet header

There are 6 fields in the packet header besides a checksum as shown in Fig. 5.7. These six fields are: Active Member Address (AMA), Type, Flow (F), ARQ (A), SEQN (S) and HEC. The AMA represents the address of an active member in a piconet, and it is specified by 3 bits. A 4-bit type field is used to specify the packet type which is associated with link characteristics. It can define 16 different types of payloads. A SCO link packet may be of 4 types, whereas a ACL link may be of 7 types. The type code also tells about the number of slots that current packet occupies. A single bit flow flag can be set to 1 to indicate “stop” flow when receiver’s buffer is full. It is only applicable for ACL links. SCO packets can flow in even if stop bit is set. The next bit is for Automatic Repeat reQuest (ARQ). It indicates the success or the failure of transmission. The 1 bit field which follows ARQ is SEQN. SEQN is inverted with a new packet. Header Error Check (HEC) is a 8-bit field for checking integrity of header.

2.2 Protocol Stack

Bluetooth stack consists of four set of layers:

• 1. Bluetooth core protocol,

• 2. Cable replacement protocol

• 3. Telephone control protocol, and

• 4. Adopted protocol.

The core protocol layer is present in every Bluetooth devices. It provides four important set of protocols on the top of Bluetooth RF layer. These core protocols are: Baseband, Link Manager Protocol (LMP), Logical Link Control Adaptation Protocol (L2CAP), and Service Discovery Protocol (SDP). The protocols of other layers are used on need basis. The cable replacement protocol RFCOMM provides RF-oriented emulation of the serial cable line settings and the status. It emulates full 9-pin RS 232 serial port over an L2CAP channel. Telephone Control Specification Binary (TCS Binary) provides three functionality, namely, call control, group management and connectionless TCS. Call control deals with signalling for establishing and releasing voice and data connection between Bluetooth devices. Group management handles signalling for management of groups within Bluetooth devices. Connectionless TCS deals with exchange of signalling information not related to an ongoing call. The adopted set of protocols are defined by specification of standards by other organizations and integrated with overall Bluetooth protocol. The idea is that the protocols from other existing standard should not be reinvented and would be incorporated with Bluetooth on need basis.

Apart from the protocol layers, there is also a Host Control Interface (HCI). HCI specifies the implementation of commands for Bluetooth hardware through uniform interface for accessing baseband commands, link manager commands, hardware status registers and event registers.

The architecture of Bluetooth protocol suite is as shown in Fig. 5.8. Besides exhibiting functional dependencies among the four layers of Bluetooth stack, it also illustrates how the various Bluetooth protocols interact.

Fig. 5.8

Bluetooth protocol stack

The combination of RFCOMM, TCS-Binary and adopted protocol layer essentially provides application oriented transport protocols for allowing applications to run over Bluetooth core layer. Since Bluetooth specifications are open, additional protocols like HTTP, FTP, etc., can be integrated in an interoperable fashion on the top of Bluetooth transport framework or on the top of application oriented protocols that leverage Bluetooth specific transport service.

Bluetooth devices form a piconet via physical RF links, established through Baseband and Link Control layer. Inquiry and paging mechanisms are used by the layer to synchronize frequency hopping sequence and clocks of different Bluetooth devices. Baseband provides both SCO links and ACL and multiplexes the packets on the same RF link. ACL packets are used for data while packets meant for SCO link may contain audio or a combination of audio and data. The audio data is transferred between devices by opening an audio link. It does not have to go through L2CAP.

Link Manager Protocol (LMP) is responsible for setting up the link between Bluetooth devices. It is concerned with authentication, security and encryption. Apart from negotiating Baseband packet sizes. Additionally, it is also responsible for power control and duty cycle of Bluetooth units in a piconet.

Logical Link Control Adaptation Protocol (L2CAP) may be viewed as the data plane for the Bluetooth link layer. The size of Baseband packets are too small for transportation to higher layer protocol. So L2CAP provides a thin layer for exporting big size packets to higher layers. This task, obviously, can be realized through a generic segmentation and reassembly protocol. But L2CAP is highly optimized for the job together with the Baseband layer. For example, since the Baseband packets are already CRC protected, there is no need to check data integrity. Likewise, the Baseband packets are assumed to be reliably delivered in proper sequence. So, L2CAP could just concentrate on the simple logic for segmentation and reassembly of Baseband packets.

The higher layer protocols can be multiplexed and demultiplexed by using channels. A channel should be viewed a logical instance of connection between two L2CAP end points serving a single application. It is possible to create multiple instances of a channel between any two L2CAP end points. Each data stream is carried in a different channel. Each packet sent over the channel carries a tag identifying the channel. The receiver can uniquely identify both the source and the protocol being transported over the channel by examining the channel identifier tag. L2CAP specification also has a provision for a connectionless channel in order to support broadcast and multicast group communication. However, this is still under development [6].

In order to be able to exchange data over a Bluetooth link, the end devices must support compatible sets of protocols. So, prior to starting of an application, sometimes it may be necessary to configure protocol and set the stack parameters. Bluetooth’s Service Discovery Protocol (SDP) standardizes the procedure for a device to query and discover the types of services supported by another device. SDP operates in client-server mechanism. The server provides a list of service description records about the characteristics of the services. A client can issue SDP queries to browse through all available service description records, and retrieve the required attribute values of a service from the corresponding records.

A universally unique identifier (UUID) is assigned at the time of defining the service. The uniqueness of identifier provides the ability to distinguish between two independently created services. This is similar to placing a UDDI registry record as in the case of web services. If the UUID of the service is already known to a client, then the specific service attributes can be queried easily. The alternative search procedure, as indicated earlier, is to browse and select one out of the list of available services. Thus, Bluetooth SDP is not as powerful as other generic service discovery protocols like SLP (Service Location Protocol) and Jini. But SDP is optimized to run over L2CAP. The limited search capabilities can also lead to efficient and small foot print for implementation on small devices.

To establish a L2CAP channel, the link manager is expected to perform certain Baseband-specific control checks. The important among these are creation of piconet, assignments of master-slave role, and link configuration. These control functions are part of the Bluetooth link layer, and depend on the link manager to exchange link manager packets. Depending on the operating environment, the link manager must adjust certain piconets as well as link-specific parameters. A few of these adjustable parameters are for: adjusting power level, increasing the packet size, and changing the QoS demand on an ACL.

The primary objective of the Bluetooth specifications is interoperability. The interoperability requirements originates from the following incompatibilities:

• 1. Applications may run on different devices.

• 2. A device may use a protocol stack from one vendor and a Bluetooth chip from a different vendor.

Interoperability between the applications can only be achieved if the implementations conform to the same core and profile specifications. All Bluetooth chips implement the Baseband and LMP specifications. So, at the lowest layer, this uniformity ensures interoperability over the air. However, part of Bluetooth stack consisting of L2CAP, SDP, and RFCOMM layers may be implemented either in firmware or in software. At the lowest layer, a Bluetooth stack interfaces with a Bluetooth chip through the standard Host Control Interface (HCI). This seems to suggest that porting a Bluetooth stack from one platform to another may not be difficult. However, the task of porting is not as easy due to absence of a standardized API for accessing the control functions. An application should use the API provided by the stack implementor to initiate a Bluetooth inquiry for discovering other devices in its neighborhood. It forces the application developers to know API specific to the stack implemented by a vendor.

Fig. 5.9

Structure of Bluetooth profiles

Fig. 5.10

Protocol stacks for various Bluetooth applications

2.3 Bluetooth-Enabled Applications

Applications are implemented using Bluetooth profiles. Bluetooth profiles specify wireless communication interface between a pair of Bluetooth enabled devices. There is a wide range of profiles which describe different types of applications. Three key information in a Bluetooth profile are: (i) the format of user interface, (ii) the dependence on the other profiles, (iii) the part of Bluetooth protocol stack needed by the profile. A Bluetooth device must be compatible with the subset of Bluetooth Profiles in order to provide services such as file transfer, cable free connectivity, wireless modem connectivity, personal area network, etc. These profiles sit on the top of Bluetooth core protocols and may require some additional protocols. The structure of the general Bluetooth access profile with protocol requirement is shown in Fig. 5.9. The generic access profile consists of service discovery profile, telephone control specification profile, and serial port profile. Serial port profile requires the communication and generic object exchange profiles. Apart from the core Bluetooth protocols, the requirements of other protocols for implementation of a Bluetooth application will depend on the specific profile and its dependence on other profiles. The protocol requirements of some of the applications are given in Fig. 5.10.

3 Infra Red

IrDA (Infrared Data Association) standard [7] provides the specification for short-range free space optical communication based on Infra Red (IR) light which have a wavelength in the range of 859–900 nm. The approximate communication distance supported by IR is 1 m with a maximum data rate of up to 4 Mbps. A low power IR standard is also defined, whose range can be as low as 20 cm. Lower range prolongs the life of batteries.

There are many advantages in using IR connectivity. First of all, no prior regulatory approval is required for optical communication. Unlike radio frequencies, IR is free from interferences. Therefore, it provides robust connectivity leading to safe use in environments such as avionics, medical instruments, or military equipment. IR-enabled wireless connectivity facilitates easy mobility in personal space. Finally, the cost of IR connection is as low as wire connection. So, replacement of wired connection using IR is advantageous on many counts.

IR is predominantly used for replacing wire connection (RS 232 port) in short range communication. A normal wired connection to a host is illustrated in Fig. 5.11. The connection is through a host controller. The host controller has a RS 232 line driver and provides RS 232 port as the connection interface to outside world. RS 232 port is attached to a DB-9 connector and then a serial cable. DB-9 is a common 9 pin connector for serial cable. For the replacement of cable, MCP21xx protocol handler substitutes RS 232 line driver and DB-9 connector is replaced by optical transceiver. The emittance of light performs the functions of cable connection.

Fig. 5.11

IR for replacement of cable connection

IR based communication is restricted within a range of a circular cone having 30$^\circ$ half angle with respect to the axis of communication. The receiver can receive the signal within a circular cone having a half angle of 15$^\circ$. As illustrated in Fig. 5.12 transmission from the source $S_1$ would be able to reach receiver $R_1$, but it cannot reach receiver $R_2$ as it falls outside the stipulated communication cone.

Fig. 5.12

Infrared communication cone

Communication in IR system resembles client/server programming model TCP and WinSock APIs. Transmission is half duplex, i.e., simultaneous transmission and reception are not possible. The receiver is blinded by the light of its own transmitter when the transmission is on. However, two way communication is possible by alternately switching between transmission and reception modes. The client application connects to a server application by providing the server device address on that server. Applications on different devices can open multiple reliable connection between themselves for sending and receiving data.

A base IR equipment, consists of a pair of devices, the one is primary and the other is secondary. A primary device is responsible for selecting a secondary device in its visual space. Initially, a primary device enters the discovery phase, and examines every device visible within its communication cone. A secondary device responds to the primary device’s discovery, then two devices negotiate their capabilities, and jump to highest common transmission speed. So, notwithstanding the existing differences in respective capabilities, the connection can be optimized to match each other’s capabilities. The primary device controls the timing of the link for two way communication. But both primary and secondary devices are bound by some hard constraints and communicate fast by turning around the link.

Fig. 5.13

IR protocol suite

3.1 IR Protocol Stack

IR protocol stack consists of two groups of layers, viz., mandatory and optional as shown in Fig. 5.13. The mandatory set of protocols (shaded dark) consists of:

• Physical Layer: which is responsible for signal management or the optical portion of the transmission.

• Link Access Protocol (IrLAP): it establishes the basic reliable connection.

• Link Management Protocol (IrLMP): its role is to multiplex services and application on the link access protocol.

• Information Access Service (IAS): it provides directory (yellow page) services on a device.

The set of optional protocols (lightly shaded) usually found in an IrDA implementation are:

• Tiny Transport Protocol (TinyTP): it adds per-channel flow control to keep data transmission smooth.

• OBject EXchange protocol (IrOBEX): it assists in easy transfer of files and data objects. Usually be needed by many applications.

• Parallel, and serial port emulation protocol (IrCOMM): it enables existing applications using parallel or serial communication to work with IR communication without any problem.

• Local Area Network access protocol (IrLAN): it enables LAN access for laptops and other devices with slow pedestrian mobility.

The communication begins at a normal data rate of 9600 bits per second, then settles at a speed compatible with the receiver device. The possible data rates could be 2400, 9600, 19200, 38400, 57600, 115200, 4000000 bps. Apart from optical transmission, the other major responsibility of physical layer is framing. The framer is a software layer which accepts incoming frames from hardware and presents it to IrLAP. The framer also adjusts the speed of the hardware as desired by IrLAP. The format of IrLAP frame [1] is depicted in Fig. 5.14. The Beginning of a Frame (BoF) and End of a Frame (EoF) are specified by a unique identifier. The Frame Check Sequence (FCS) is, a 8-bit value, calculated from contents of IrLAP packet. BoF, EoF and FCS are implemented by the framer (in the physical layer). The 7 bits of the address field represent the address of the secondary device, and the remaining 1 bit indicates whether the frame is a command or a response. The control field contains sequence numbers (not relevant for the unnumbered frames), frame type identifiers (supervisory/information), and command codes. The information field contains the actual data and can have a maximum size of 2048 bytes. Interested reader can refer to [1] for more details on frame format.

Fig. 5.14

The IrLAP frame structure

IrLAP, which sits on the top of the framer, corresponds to the data link layer of OSI model. It is based on high level and synchronous data link control. For reliable data transfer, IrLAP supports retransmission, low level flow control, and error detection. However, it is advisable to use Tiny TP in place of low level flow control. Data delivery may fail if the path of infrared beam is blocked. The environmental characteristics influencing the development of IrLAP are:

• Point-to-point connections: such as the connection between digital camera and desktop/laptop. The distance range is usually 1 m or less.

• Half-duplex transmission: as explained earlier, only half duplex communication is possible. But link can be switched around frequently for bi-directional communication.

• Narrow cone of communication: as illustrated by Fig. 5.12, the communication is possible if the receiver’s communication cone is within the transmitter’s communication cone.

• Hidden nodes: the nodes not in current communication cone of an IR device, cannot immediately receive the transmission. They must wait to find if the link turns around before they can enter into a communication.

• Interference: IrLAP of a device must overcome the interference from other IR devices, ambience light of room including the sun light and the moon beams.

• Absence of collision detection: any collision should be handled at software level, hardware design does not include protection against collisions.

The operations in IrLAP are divided between a master and a slave with each having distinct responsibilities. In each connection, one device plays the role of a primary device. A primary device shall not normally suffer from resource problem. Typically, a desktop or a laptop would take up the role of a primary station. The three main responsibilities of primary station are:

• 1. Sending control frames to initiate a connection,

• 2. Controlling data flow, and

• 3. Dealing with unrecoverable data link errors.

The slave or the secondary station sends only response frames. The typical IR secondary devices are printer, camera and other resource constrained or less complex devices. IrLAP has three operational modes, viz., link initialization, normal (disconnected), and connected. During initialization IrLAP chooses a random 32-bit address for the device. It is possible for IrLAP to choose the same device address for multiple devices. But there are mechanisms to detect and resolve conflicts arising out of choice of same address. After a link has been initialized IrLAP enters normal disconnected mode (NDM). In NDM mode, the device must listen to find if a communication is ongoing (medium is busy). The absence of activity for more than 500 ms implies that the medium is free, and a connection can be established. The other mode of operation is known as normal response mode (NRM). A device in connected state operates in this mode. Figure 5.15 explains the state transitions in IrLAP’s operation.

Fig. 5.15

Flow of IrLAP operation

The responsibility of device discovery procedure is to detect other IrDA devices within communication range of the host. If some of the participating devices have duplicate addresses, then address resolution procedure is initiated by one of the conflicting devices. The initiator asks the other device to choose another address. A specific slot marker is also given to the conflicting device to respond with a new address. If the conflict still exist, the process of address resolution is repeated. After resolution process is completed, the application layer may be able to decide about connecting to one of the discovered devices. The connection is established when the application layer requests for a connection. The connection request is serviced by IrLAP by generating a Set Normal Response command Mode (SNRM) frame with poll bit on. The poll bit mandates a response from the remote device. It basically tells that the source (requester) wishes to initiate a connection. If the remote device wishes to accept the connection request, then it responds by an Unnumbered Ack (UA) frame with final bit set. After that the requester becomes the primary and the connection accepting remote node becomes the secondary.

The IrLMP is the third layer of IrDA specification. It provides support for two main functions, viz., (i) Link Management MUltipleXing (LM-MUX), and (ii) Link Management Information Access Service (LM-IAS). LM-MUX, which sits on top of IrLAP layer, provides link multiplexing support for application level. LM-IAS provides directory service through which applications can discover devices and access the information base in a remote device. LM-MUX used for addressing individual connection among those multiplexed. It adds an overhead of 2 bytes to address fields of each IrLAP frame. These address fields uniquely identify the Link Service Access Points (LSAPs) in both source and destination. Each LSAP is addressed by 7-bit selector (LSAP-SEL). LSAP-SELs within range (0x)01 to (0x)6F can be used by application. LSAP-SELs (0x)00 and (0x)70 respectively are for IAS server and connectionless data service. The remaining LSAP-SEL values from (0x)71 to (0x)7F are currently unused. LM-IAS works like a service registry. It maintains information about the services provided by a host device. Remote devices may discover the services available on host, and learn about the configuration information for accessing the services through LM-IAS. For example, IAS provides LSAP-SEL value which is the most important piece of information for locating a service.

With several IrLMP connections operating together, the data flow among the peers becomes complicated. IrLMP shares the link provided by IrLAP between primary and secondary devices. IrLAP’s flow control mechanism is not equipped to handle such problems. The simple reason is that once the IrLAP flow control is turned on one side, the flow of data on LAP connection (which carries all the LMP connections) ceases completely in that direction. So, unless the LAP flow control is turned off, the other side cannot get any data. However, this causes serious disruption in its function, specially if timers are involved. Furthermore, deadlock may occur or flow in some connections could as well be uneven considering the requirements of the applications. For example, while a device is waiting for its peer application’s response before releasing buffer, a different connection may use up the remaining buffer space. This would cause IrLAP to flow control the link until buffer space becomes available. Now, if both connection wait for responses from remote devices before releasing the respective buffer spaces then a deadlock situation can occur .

Tiny TP (TTP) [12] is IrDA’s transport protocol. It lies on the top of IrLMP layer. TTP is responsible for maintaining per-channel flow control, and oversees the overall smooth communication. Maintaining multiple IrLMP connections on a single IrLAP connection is complex. TTP maintains flow per-LMP connection basis. TTP applies a credit based mechanism to control per-LMP connection. One credit point is assigned for the permission to send one LMP packet. The receiver sends credits to the transmitter. The number of credits can vary between 1 and 127. Periodically, the receiver would issue more credits. If the sender has no credit it cannot send data. So, the senders using up credits at faster pace are likely to suffer. Note that the role of the sender, and the receiver are not fixed, both sides of a LMP connection can send as well as receive. So, both sides will issue credits and use credits issued by each other. Credit bytes are sent as part of a LMP data packet. So there is no need to use extra packets as long as there is data to send and credit to issue. The design of a good credit policy requires careful planning. The other function of TTP is segmentation and reassembly. TTP breaks large data into pieces called service data units (SDU). The maximum size of SDU is negotiated at the time of TTP/LMP connection. The broken pieces should be re-assembled at the receiving end.

IrOBEX stands for infrared object exchange. The protocol’s responsibility is for transfer of files and other data objects. It functions like a mini HTTP for IrDA. However, it does not have resources like HTTP, and its target devices have different usage models than web. Furthermore, HTTP is more a pull based object exchange architecture, while IrOBEX is evenly balanced supporting both pull and push. IrOBEX design is quite comprehensive, which simplifies the development of communication based applications. It has following components:

• Session protocol: it specifies the rules for operations like Get and Put related to exchange of object during a connection. It allows termination of an object transfer without closing the connection, and also a graceful closing of the connection.

• Object model: it basically specifies a flexible and extensible representation for describing objects.

• Use and extension rules: it allows defining new session operations and new object types.

• IAS entry: for a default OBEX server and the description of its capability.

The infrared communication protocol (IrCOMM) provides for serial and parallel port emulation. It enables the legacy applications that use serial and parallel communication to use infrared without change. Basically, IrCOMM aids in replacement of cables by virtual wires for connecting computers with its peripherals like keyboard, mouse, printer, etc. It enables direct synchronization of such devices by selecting a virtual COM port of the computer.

IrLAN Provides LAN access for laptops and other devices. It offers following capabilities:

• A computer can attach to a LAN via an Access Point Device, an IR LAN Adapter.

• Two computers can communicate as though they are attached to a LAN with access to the other machines’ directories and other LAN capabilities. So, a computer can be attached to a LAN through a second computer if the latter is already attached to the LAN.

The description on IrDA protocol in this section touches all mandatory and a few important optional IrDA protocols. Yet, it remains incomplete without a discussion on how an arbitrary data object is exchanged from one device to another. Object exchange protocol IrOBEX or OBEX is the most basic and desirable feature of IrDA stack. A wide range of objects can be exchanged through IrOBEX which functions much like HTTP protocol. Both are designed as request-response type of protocol for exchanging arbitrary data between the devices. Both support GET and POST commands make it possible to transfer binary data between the devices. Both have headers which describe the content and the body. In fact, it will not be an over statement to call OBEX as IrDA HTTP protocol. Yet there are many dissimilarities between the two. The design of HTTP is more pull oriented compared to OBEX which is evenly balanced for both pull and push. OBEX is designed specially for resource constrained devices and works only on single hop distance between the source and the destination devices. OBEX is stateful unlike HTTP which is fundamentally stateless but uses cookies to maintain state.

OBEX consists of two important components, namely, (i) representation model for objects, and (ii) a session protocol which puts a structure around the conversation between two devices. The session protocol resides on the top of TinyTP, which is a reliable transport protocol. No additional protocol is needed except for the upper layer APIs which allow communications through TinyTP. The protocol layering remains as indicated in Fig. 5.13.

4 Comparison of Bluetooth and Infrared

A comparison of the physical characteristics of Bluetooth and Infrared is provided in Table 5.1. Bluetooth works over radio communication, whereas Infrared is an optical communication framework. So it can avoid detection. Therefore, it can find use in short range communication between computers aboard naval warships, planes and armoured vehicles. Yet, the requirement of line of sight for optical communication is a major handicap for IR based communication.

Table 5.1 Comparison of physical characteristics of Bluetooth and Infrared