Personal Area Networks (PANs)

11 Personal Area Networks (PANs) 11.1 Introduction to PAN Technology and Applications 11.1.1 Historical Overview The concept of a Personal Area Network (PAN) differs from that of other types of data networks (e.g. LAN, MAN, WAN) in terms of size, performance and cost (Figure 11.1). PANs are the next step down from LANs and target applications that demand short-range communications inside the Personal Operating Space (POS) of a person or device. The term POS is used to define the space in the near vicinity of a person or device and can be thought of as a bubble that surrounds him. As the person goes through his regular daily activities, his POS changes to include a number of different devices (such as cellular phones, pagers, headphones, PC interfaces, etc.) with whom the ability for easy and transparent information exchange would be useful. PANs aim to provide such ability in an efficient manner. There exist a number of different communication mediums to choose for implementing a PAN, such as electric and magnetic fields, radio and optical signal transmission. One of the first research concepts for PANs dates back to an IBM research project in 1996 and is known Figure 11.1 The various kinds of wireless networks as ‘Near-field Intra-body Communication PAN (NIC-PAN)’ [1]. This approach uses the human body as the communication medium, which can conduct electricity due to its natural content of salt. According to this approach, NIC-PAN-compliant devices worn by a user can communicate with each other through the user’s body, thus no wires are needed. Furthermore, a user wearing such a device can initiate communication with another device located on another user by means of a simple handshake. In order to transmit data between devices attached to the users’ bodies or clothing, the NIC-PAN device transmitter charges and discharges the human body, thus resulting in an oscillating potential appearing between the body and the environment. These changes of potential are picked up by the receiving NIC-PAN device and thus a communication channel is established. The electrical current used in this approach is approximately 1 nA, which is much lower than the natural electrical current of the human body. In the context of this research, a small prototype was built, which achieved data rates around 2.4 kbps. However, the NIC-PAN approach did not evolve into something more than a research project, whereas the true revolution in the area of PANs was brought about by the use of wireless transmission-based PANs (WPANs 1 ). The first attempt to define a standard for PANs dates back to an Ericsson project in 1994, which aimed to find a solution for wireless communication between mobile phones and related accessories (e.g. hands-free kits). This project was named Bluetooth, after the king that united the Viking tribes. Bluetooth was a promising approach and as a result, Nokia, Intel, Toshiba and IBM joined Ericsson to form the Bluetooth Special Interest Group (SIG) in May 1998. The purpose of the Bluetooth SIG is to develop a de facto standard for PANs that meets the communication needs of all mobile computing and communication devices located in a reduced geographical space regardless of their size or power budget. The size of the SIG has grown from the initial five members to nearly 2000 others at the present day. Any interested company is allowed to join the SIG provided that it lets all other members of the SIG use its patents royalty-free, in an effort to keep the standard open. Version 1.0 of the Bluetooth specification was released by the SIG in 1999, followed by version 1.1 in 2001. Both these versions support 64 kbps voice channels and asynchronous data channels either asymmetric, with a maximum data rate of 721 kbps in one direction and 57.6 in the other or symmetric with a 432 kbps maximum rate in both directions. Bluetooth uses Frequency Hopping Spread Spectrum (FHSS) modulation in the 2.4 GHz ISM band. The supported range is 10 m with the possibility of extending this to 100 m [2]. Another initiative from industry members to develop a PAN standard was made in 1997 by the formation of the HomeRF Working Group. The primary goal of this group is to enable interoperable wireless voice and data networking within the home. Version 1.0 of HomeRF was published in 1999. It supported four 32 kbps voice connections and data rates up to 1.6 Mbps at ranges up to 50 m. Version 2.0 of HomeRF was released in 2001 and increased these numbers to eight channels and 10 Mbps, respectively, making HomeRF more suitable than Bluetooth for transmitting music, audio, video and other high data applications. However, Bluetooth seems to have more industry backing. Like Bluetooth, HomeRF also supports voice and asynchronous data channels using FHSS modulation in the 2.4 GHz ISM band. After the appearance of the Bluetooth and HomeRF initiatives, IEEE also decided to join the area of developing specifications for PANs. Thus the 802.15 Working Group [2–5] was Wireless Networks300 1 Since all PAN technology alternatives today employ wireless transmission, the terms PAN and WPAN are used in this book synonymously. formed in March 1999, with the responsibility of defining physical and MAC layer specifica- tions for PANs having low implementation complexity and low power consumption. Although Working Group 802.11, which deals with Wireless LANs, already existed, it was decided that a new Working Group was needed for PAN standardization. This is attrib- uted to the fact that there is a much greater concern over power consumption, size, and product cost in PANs stemming from the demands for PAN devices compared to WLAN devices: † Less size and weight, in order to be easily carried or worn for long periods of time. On the other hand, the size and weight of WLAN cards is a matter of secondary importance. This is because WLAN devices are typically either attached to portable computers, which of course are not carried by users all of the time, or to fixed desktop PCs. † Lower cost, in order not to burden the total cost of the device. PAN devices aim to provide wireless connectivity to commercial electronic appliances. In order to enable small device size, PAN functionality will be integrated within the devices. To earn market acceptance, the cost burden of PAN functionality on the total cost of the device should be small. Users, on the other hand, can buy WLAN cards separately, thus the impact of their cost is less important. There are four Task Groups (TGs) inside Working Group 802.15: † TG1. This group is working on a PAN standard based on Bluetooth. † TG2. This group aims to facilitate coexistence of PAN and WLAN networks. † TG3. This group aims to produce a PAN standard with data rates exceeding 20 Mbps, while maintaining low cost, power consumption and interoperability with industry stan- dards. † TG4. This group aims to produce a PAN standard that will enable low-rate operation while achieving levels of power consumption so low, that a battery life of months or years will be possible. Due to the fact that industry consortia initiatives for PAN standards development preceded the initiative of IEEE, a key mission of the 802.15 Working Group will be to work closely with such consortia, such as Bluetooth and HomeRF, in order to achieve interoperability for PANs coexisting in a shared wireless medium. 11.1.2 PAN Concerns There are certain issues that need to be taken into account when designing a PAN. The most obvious one affects all types of wireless networks and concerns the increased Bit Error Rate (BER) of the wireless medium. As has been mentioned, the primary reason for the increased BER is atmospheric noise, physical obstructions found in the signal’s path, multipath propa- gation and interference from other systems. The primary source of interference in the 2.4 GHz ISM band in which PANs operate, comes both from narrowband and wideband sources, such as microwave ovens. Apart from the good interference avoidance properties of SS modula- tion, which is employed for unlicensed transmission in the 2.4 GHz ISM band, Automatic Repeat Requests (ARQ) and Forward Error Control (FEC) techniques can also be used in this direction. Furthermore, PANs have to deal with interference from collocated PANs and WLANs, although this should not be a big problem due to the use of FHSS modulation. Personal Area Networks (PANs) 301 PANs should provide full communication capability between all devices in the POS of a person. However, two PAN devices that initiate communication inside the POS should not interfere with other devices when this is not wanted. Consider for example the case of a person entering a conference room. After sitting in a chair, a PAN interface nearby could communicate with a handheld device of the person and deliver to him the information he wants. However, automatic initiation of communication with the devices of nearby confer- ence attendants may not be desirable for privacy reasons. A person carrying a PAN-enabled device could find him-/herself in a diverse range of situations, whether personal or professional, that demand information delivery through the PAN device. Therefore, PAN devices should be compatible to enable information exchange in all cases. Returning to the conference example, imagine two attendants wanting to exchange information, discovering that their systems are not compatible and thus they need to exchange the information on paper. In such case, the market community would see PANs as a waste of time and money. Compatibility not only involves following a specific PAN standard but also software compatibility. For example, the file formats on each of the above devices should be able to be read by both devices. PAN-enabled devices will be typically be carried by people for long periods of time. Thus, they need to be small enough in order to be carried around without burdening. PAN devices should therefore be as small and light as possible. Their energy efficiency should be enough in order not to trouble the user with frequent recharging of batteries, while maintaining a low device weight. Therefore, both low power consumption devices and high capacity batteries are desirable. Furthermore, the efficiency in terms of size and weight should not come at an expense over the price of PAN devices, in order to enable market acceptance. Security issues are also crucial in PANs. Communications should be secure and difficult to eavesdrop. Consider the case of a malicious user approaching pedestrians carrying PAN devices. The unpleasant ‘Big Brother’ scenario of Orwell’s 1984 is obvious here and should be as difficult to achieve as possible. It should be very hard for the malicious user to obtain information regarding the unsuspected pedestrians, such as their names, home addresses, etc. Therefore, robust authentication and encryption schemes should be developed in an effort to prevent unauthorized initiation of communication and eavesdropping. These schemes should be developed while keeping in mind the relatively low processing and power capabilities of PAN devices which stem from the requirements for reduced cost, size and weight. Finally, as in the case of all wireless networks human safety issues are of great concern. A PAN device will typically be very close to the user for long periods of time and therefore even small dangers could potentially have some impact on the user over time. The good thing here is that PAN (like WLAN) devices typically transmit at power levels up to 0.5 W. Despite the fact that a final answer to the question of radiation threats to human health has yet to be given, it is reassuring for the consumers to know that the operating power levels of a PAN device are substantially lower than the 600-mW to 3-W range of common cellular phones. 11.1.3 PAN Applications The main goal of PANs is freedom from cables and easy sharing of information between all kinds of wireless devices. The number of different possible applications can be very large. In the following we outline a representative set: Wireless Networks302 † Personal device synchronization. Automatic data synchronization between mobile wire- less equipment such as a mobile phone, notebook PC, etc. that execute similar applica- tions. † Ad hoc connectivity. Transferring files, and other information to another user’s PAN- enabled device. † Cordless computer. Wireless interfacing of devices like mice, keyboards, game pads to the computer. † Cordless peripherals. Access to a variety of wireless peripherals including printers, scan- ners, fax, copier, storage systems, etc. † Localized wireless LAN access. PAN-enabled devices can gain access to services offered by wired LANs through PAN-compatible Access Points (APs). † Internet access. Downloads of email or browsing a web page using a PAN-enabled device, such as a mobile phone. † Wireless synchronization. Synchronization of portable devices with the stationary servers via PAN APs. † Cordless telephony/headset. A user selects a contact name from a handheld, the handheld wirelessly prompts the mobile phone in its proximity to dial the number and the audio from the call is wirelessly forwarded to the user’s headset. † Home automation. Seamless transfer of commands to PAN-enabled home devices. For example, automatic unlocking of the door upon the arrival of the user at his home, or automatic tuning of the television to the user’s favorite channel upon his entrance to the room. † Electronic purchases/reservations. PAN devices can be used to electronically book tick- ets. For example, the PAN device of a user can be programmed to instantly initiate a request for booking a ticket for a specific flight when the user enters the airport, thus avoiding the long queues and waiting times of the traditional booking procedures. † Emergency situations. Medical devices with PAN interfaces can be used in order to increase the safety of patients. For example, pacemakers could be monitored and controlled remotely through PAN interfaces, or can be programmed to immediately call an ambulance while also transmitting the patient’s medical condition in the case of a heart attack or other serious health problem. 11.1.4 Scope of the Chapter The remainder of this chapter provides a detailed presentation of technological alternatives in the PAN area. Section 11.2 presents the Bluetooth specification and discusses, among others, the way Bluetooth devices establish connections and exchange data. Furthermore, Blue- tooth’s provisions on security and power management are discussed. Section 11.3 is a similar discussion on the HomeRF standard. The chapter ends with a brief summary Section 11.4. 11.2 Commercial Alternatives: Bluetooth 11.2.1 The Bluetooth Specification The Bluetooth specification 1.1 [6–9] comprises two parts: core and profiles. The core Personal Area Networks (PANs) 303 specification defines the layers of the Bluetooth Protocol stack. The aim of the stack (shown in Figure 11.2) is to provide a common data link and physical layer to applications and high- level protocols that communicate over the Bluetooth wireless link and maximize reuse of existing protocols at the higher layers. The protocols that run at different layers of the stack can be categorized into three groups: Bluetooth core, cable replacement protocols (RFCOMM), telephony control protocols (TCS and AT commands) and adopted protocols (such as IP, PPP, etc.). From these protocols, only the core protocols, RFCOMM and TCS are Bluetooth-specific protocols (those run at the shaded layers of Figure 11.2). The layers of the stack are summarized below: † The radio layer provides the electrical specifications in order to send and receive bitstreams over the wireless channel. These specifications are discussed in Section 11.2.2. † The baseband layer enables the operation of the Bluetooth links (described in Section 11.2.4) over the wireless medium. This layer is also responsible for framing, flow control and timing operations and it also manages the links between communicating Bluetooth devices. † The Link Management (LM) layer runs the Link Management Protocol (LMP). This is an entity responsible for managing connection states, ensuring access fairness, performing power management and providing authentication and encryption services to upper layers. Power management issues are discussed in Section 11.2.7 while security is discussed in Section 11.2.8. † The Logical Link And Adaptation Layer (L2CAP) provides connection-oriented and connectionless data services to upper layer protocols with protocol multiplexing capabil- ity, segmentation and reassembly (SAR) operations, and group abstractions. L2CAP permits higher-level protocols and applications to transmit and receive L2CAP packets up to 64 kilobytes in length. L2CAP supports only data traffic. As can be seen from Figure 11.2, audio data is not conveyed through L2CAP but is mapped directly to the baseband layer. Thus, data for audio connections is exchanged directly between the baseband layers of Bluetooth devices. † The service discovery layer runs the Service Discovery Prototcol (SDP), which is used in Wireless Networks304 Figure 11.2 The Bluetooth protocol stack. Shaded layers implement Bluetooth-specific protocols order for a Bluetooth device to learn about services on offer and neighboring device information. Using SDP, neighbors of a device can be queried and if some requirements are met, a connection can be established. † The RFCOMM layer runs a serial line RS-232 control and data signal emulation protocol. It is used for cable replacement, offering transport capabilities over the wireless link to applications that use serial lines as a transport mechanism. † The TCS layer defines call control signaling procedures for the establishment of voice and data calls between Bluetooth devices. † The Host Controller Interface (HCI) is not a stack layer but an interface that provides the means for accessing the Bluetooth hardware capabilities. † Layers that implement non-Bluetooth specific protocols (OBEX, WAP, etc.) are used to enable high-layer application functionality. The profiles part of the specification is used to classify Bluetooth applications into nine application profiles, with each profile implementing only a certain set of the stack’s protocols. This approach has received some criticism, which supports that the Bluetooth specification is essentially a set of nine standards instead of one, with the number likely to rise as new application profiles are added. However, the existence of application profiles aims to ensure interoperability between Bluetooth devices. In order for a device to be certified for a specific Bluetooth application, it has to follow the corresponding profile. Furthermore, the production of devices for a specific application means that the device could support only some of the application profiles, thus reducing its overall cost. Apart from the nine application profiles, version 1.1 of the Bluetooth specification also supports four system profiles, which include functionality common to one or more application profiles. The thirteen profiles are summar- ized below. Some of the profiles can exist only if they implement other profiles, as shown in Figure 11.3. Personal Area Networks (PANs) 305 Figure 11.3 The Bluetooth profiles † Generic access profile. This system profile is responsible for link maintenance between devices. This profile is not useful for supporting any useful application by itself, however, it needs to be supported in every Bluetooth device since it includes the functionality needed to use all the other system profiles. † Service discovery application profile. This is another system profile that enables users to access the Service Discovery Protocol (SDP) in order to find out which applications are supported by a specific device. The support of the service discovery application profile is optional. If, however, this system profile is not supported, only applications can access the SDP, not users. † Intercom profile. This application profile supports direct voice communication between two Bluetooth devices within range of each other. † Cordless telephony profile. This application profile is designed in order to support the ‘3- in-1 phone’ concept, meaning that a Bluetooth-compliant telephone can be used either as an intercom (communicating directly with another Bluetooth device), cordless (fixed- location) or mobile phone. † Serial port profile. This system profile emulates RS232 and USB serial ports in order to allow applications to exchange data over a serial link. † Headset profile. This application profile uses the serial port profile to provide connections between Bluetooth-enabled computers or mobile phones and Bluetooth-enabled wireless headset microphones. † Dial-up networking profile. This application profile uses the serial port profile to provide dial-up connections via Bluetooth-enabled cellular phones. † Fax profile. This application profile uses the serial port profile to enable computers to send a fax via a Bluetooth-enabled cellular phone. † LAN access profile. This application profile enables Bluetooth devices either to form small IP networks among themselves or connect to traditional LANs through Access Points (APs). † Generic object exchange profile. This system profile defines the functionality needed for Bluetooth devices to support object exchanges. † Object push profile. This application profile defines the functionality needed to support ‘pushed’ data. Examples of such information are advertisements and news distribution. † File transfer profile. This application profile enables file transfers between Bluetooth devices. † Synchronization profile. This application profile enables automatic data synchronization between Bluetooth devices. For example, it can be used to synchronize address books between a desktop computer and a portable. 11.2.2 The Bluetooth Radio Channel The Bluetooth radio channel [7], enabled by the radio layer, provides the electrical interface for the transfer of Bluetooth packets over the wireless medium. The radio channel operates at the 2.4 GHz ISM band by performing frequency hopping through a set of 79 (US and Europe) or 23 (Spain, France and Japan) RF channels spaced 1 MHz apart. The wireless link comprises time slots of 0.625 ms length each, with each slot corresponding to a hop frequency. The nominal hop rate is 1600 hops/s. At each hop, the transmitted signal is modulated using GFSK with a binary one being represented by a positive frequency shift Wireless Networks306 and a binary zero by a negative frequency shift. Despite the fact that this configuration provides link speeds up to 1 Mbps, the effective data transfer speeds offered are lower. This is because different protocol layers use parts of the packet data payload to add header information for purposes of communication with peer layers. More efficient modulation schemes could obviously achieve higher speeds, however, the use of GFSK is preferred as it allows for low-cost device implementations. Depending on the transmitted power, Bluetooth devices can be classified into three classes, as shown in Figure 11.4. Power control mechanisms can be used to optimize the transmitter’s power output. This is done by measuring the received signal strength and relaying LMP commands to the respective transmitter indicating whether power should be increased or decreased. Power control is required for class 1 equipment, whereas it is optional for equip- ment of classes 2 and 3. Using power class 1 a range of 100 m can be achieved in a Bluetooth system [2]. 11.2.3 Piconets and Scatternets When two Bluetooth devices want to connect, the one requesting the connection, is known as the master, whereas the other is known as the slave. The master always controls the link created between the two devices. The master–slave relationship is good only for a specific link establishment, since any Bluetooth unit can be either master or slave. A given master can maintain up to seven connections to active slaves. As a result, several very small networks, called piconets, can be established. However, if the master wants to open connections to more than seven slaves it can instruct one or more active slaves to ‘sleep’ for a specified period of time by putting them in the low-power PARK mode (described in Section 11.2.7). Then the master can admit new slaves into the piconet for the period the old set of slaves were put to sleep. Thus, piconets of many devices can be formed. A piconet is shown in Figure 11.5. Devices inside a piconet hop together according to the master’s clock value and its 48-bit device ID. The way the hopping sequence is used and the starting point within that sequence is selected is shown in Figure 11.6. The first parameter defines the hopping sequence used for FHSS transmission inside the piconet. The second parameter is derived from the native clock of the master and defines the phase within that sequence. Slave to slave transmission is not supported inside a piconet. If two slaves need to communicate, they either have to form a separate piconet in which one of them is the master, or use a higher layer protocol, such as IP in order to relay messages through the piconet’s master. A number of piconets can coexist in the same area. This coexistence is enabled due to the use of FHSS transmission. Since the hopping sequences used in Bluetooth are pseudorandom, different coexisting piconets will use different hopping sequences, resulting in a low prob- Personal Area Networks (PANs) 307 Figure 11.4 Power classes for Bluetooth devices ability of hop collisions. Still, if such a case occurs, a Bluetooth device can recognize and thus ignore packets originating from collocated networks by checking the access code field on the received packets which is different for every piconet, as we explain later. However, when a large number of piconets coexist in the same area, this probability rises and the performance of each piconet degrades. A collection of overlapping piconets is called a scatternet. A scatternet will typically contain devices that participate in one or more piconets. Devices participating in two or more piconets are known as bridge devices and participate in each piconet in a time-sharing manner. After spending its time inside a piconet, a bridge device will change its hopping sequence to that of the new piconet in order to join it. Furthermore, it will select the starting point within that sequence based on the clock value of the master of the new piconet. By alternating among several piconets and buffering packets, bridge nodes can forward packets from one piconet to another. A bridge node that participates in several piconets can be either: † Slave in all the piconets. In this case, when leaving the old piconet, the slave has to inform the master for the duration of its absence. † Master in one piconet and slave in all others. In this case, all traffic in the old piconet is Wireless Networks308 Figure 11.6 Combination of the master’s device ID and native clock values to select the hopping sequence to be used and its starting point Figure 11.5 A piconet formed by six devices [...]... Zimmerman T G Personal Area Networks: Near-Field Intrabody Communication, IBM Systems Journal, 35, 1996, 609–617 [2] Schneiderman R Bluetooth’s Slow Dawn, IEEE Spectrum, November, 2000, 61–65 [3] Siep T M., Gifford I C., Braley R C and Heile R F Paving the Way for Personal Area Network Standards: an Overview of the IEEE P802.15 Working Group for Wireless Personal Area Networks, IEEE Personal Communications,... phone † Asynchronous nodes (A-nodes) A-nodes are the nodes that run applications exchanging data in an asynchronous manner Typical examples of A-nodes are mobile personal computers and Personal Digital Assistants (PDAs) Personal Area Networks (PANs) 317 † Combined asynchronous and isochronous nodes (AI-nodes) As in the case of IEEE 802.11, the way a HomeRF network is controlled depends on the presence... CRC mechanism and the sender is notified about the status of its transmission in the slot following its own transmission Assuming device A transmitted a packet to device B, the resulting ACK- Personal Area Networks (PANs) Figure 11.10 313 Capacity scenarios on the ACL link NAK notifications are piggybacked on the header of the packet transmitted by B, indicating successful or erroneous reception of A’s... link key must be present in both devices This can be done by the user through typing of a randomly chosen PIN number on both devices If, however, one or both devices do not have a keypad (e.g Personal Area Networks (PANs) Figure 11.13 315 The HomeRF protocol stack wireless headsets), the level of security decreases due to the fact that the chosen PIN, which is either entered by the user on one device.. .Personal Area Networks (PANs) Figure 11.7 309 A scatternet formed by four piconets suspended until the master returns to the piconet The suspension of traffic is achieved by putting the piconet’s slaves into the low-power... HomeRF MAC protocol uses a superframe structure Each superframe starts at a new hop and lasts one hop, which lasts either 10 ms or 20 ms, depending on the presence of isochronous connections The Personal Area Networks (PANs) Figure 11.15 319 CSMA/CA parameter values in HomeRF superframe comprises two Contention-Free Periods (CFPs) and one contention period The access methods used for isochronous (e.g voice)... beacon transmitted at the start of the superframe When such an ACK is not received, I-nodes assume a collision and perform a random backoff procedure to calculate the time to resend the request Personal Area Networks (PANs) 321 The voice coder of a HomeRF unit produces 32 kbps ADPCM voice data Using the CFPs within the superframe structure, up to eight simultaneous voice calls can be supported in a HomeRF... events take place: † For each packet, the sender produces a 32-bit Initialization Vector (IV) from the sequence number of the packet and a hash function of the sender’s 48-bit MAC address Personal Area Networks (PANs) 323 † The sender uses a 56-bit (128-bit in HomeRF version 2.0) secret key and the IV to convert the transmitted message into an encrypted one † Upon receipt of the message, the receiver... 802.11 Furthermore, control of CFP operation is a centralized procedure, as in IEEE 802.11 Finally, issues regarding system synchronization, power management and security are also discussed Personal Area Networks (PANs) 325 WWW Resources 1 www.ieee802.org/15: the web site of working Group 802.15 which deals with PAN standardization 2 www.bluetooth.com: the Bluetooth SIG web site includes detailed technical... contains information related to MAC addressing, packet type, flow control, Automatic Repeat Request (ARQ) and Header Error Correction (HEC) Figure 11.8 The format of a transmitted Bluetooth packet Personal Area Networks (PANs) Figure 11.9 311 The fields of a Bluetooth packet header MAC addresses are 3-bit fields, with address 000 specifying a broadcast packet The 3-bit MAC field is the reason for the fact that . 11 Personal Area Networks (PANs) 11.1 Introduction to PAN Technology and Applications 11.1.1 Historical Overview The concept of a Personal Area Network. it is within range of another Personal Area Networks (PANs) 317 ad hoc or managed network. In this case, the collocated networks can function without