Ad-hoc
IP Networks over Bluetooth Per Johansson, Johan Sörensen Ericsson Per.Johansson@ericsson.com Johan.Sorensen@ebt.ericsson.se Abstract The use of numerous portable devices, such as laptops, mobile phones, PDAs, game terminals, mp3 players and DVD players, is becoming more and more widespread in people's professional and private lives. For the most part, these devices are used separately, that is, their applications do not interact. Imagine, however, if they could interact directly: participants at a meeting could share documents or presentations; business cards would automatically find their way into the address register on a laptop and the number register on a mobile phone. Such small networks are often referred to as personal area networks (PANs). In the home environment the PAN devices may interact with appliances and home electronics for both information and control purposes. These examples of spontaneous, ad hoc wireless communication between devices is often referred to as ad hoc networking, which allows devices to establish communication, anytime and anywhere without the aid of a central infrastructure. With the introduction of the Bluetooth wireless technology, ad hoc networking will be brought into the consumer market in scenarios as those described above. In the context of short range ad-hoc networks, IP will play the role as the common denominator among different bearers and as the provider of (inter-) connectivity, spanning over personal-, local- and wide-area. In the emerging mobile Internet, Bluetooth will serve as the link between the personal mobile devices and the wide area 3G access networks, i.e. offering an Internet access to the PAN. However, in order to use IP for ad-hoc Bluetooth PANs, certain additions and enhancements to the protocol functionality are needed. This paper describes technical aspects of applying IP to an ad hoc Bluetooth PAN. Access to the mobile Internet via Bluetooth PANs will be exemplified with an interworking scenario between a Bluetooth PAN and a GPRS access network.
In the near future, the role and capabilities of short-range data transaction are expected to grow, serving as a complement to traditional large-scale communication. Most man-machine communication as well as oral communication between human beings occurs at distances of less than 10 meters and often, as a result of this communication, the two communicating parties have a need to exchange data. As an enabling factor, license-exempted frequency bands invite the use of developing radio technologies (such as Bluetooth) that admit effortless and inexpensive deployment of wireless communication. We often find ourselves carrying several handheld electronic devices, such as notebook computers, mobile phones, PDAs and mp3 players. For the most part, these devices are used separately and their applications do not interact, mainly because interconnection via wires
becomes tedious and time consuming. Consequently, one rather obvious application for short-range radio technologies is to replace cables between electronic devices. By the use of such a technology devices could interact directly and thus create a network where information may flow seamlessly between the applications hosted in the devices, i.e. a network of personal devices, often referred to as a personal area network (PAN). Locally in the PAN, newly received electronic business cards to a PDA would, e.g., automatically find their way into the address register on a notebook computer and into the number register on a mobile phone, all these devices being part of the PAN. Communication between PANs would, for instance, enable participants at a meeting to share documents or presentations. Access to the Internet via a (public) wireless LAN access point and/or via a 3G UMTS mobile phone would enable the devices in the PAN to be constantly on-line. For instance, commuters may have a public WLAN access point in a train to their notebook computers and when exiting the train their notebook computers could remain online via the UMTS phone, while incoming email could now be diverted to their PDAs through the PAN. Finally, as the user enters the office, the access could again, automatically, go through the notebook computer via a wireless access to the corporate campus network. A key component in the examples described above is the short-range radio technology that forms the PAN. The strongest candidate to enable such networks today is the Bluetooth wireless technology [8], where the first products have been presented quite recently. Even though Bluetooth will be used in various types of applications, PAN support is one with a very high priority since it will form a basis for generic Bluetooth networking. Seen from a networking perspective, a PAN could be expected to have participants, both of its "own" devices and "guest" devices from other PANs, continuously moving in and out of its coverage. To cope with this volatile nature of the network, the concept of ad-hoc networking could be applied to create a robust and flexible connectivity. Herein, ad-hoc networking is defined as a scheme, which allows devices to establish communication, anytime and anywhere without the aid of a central infrastructure. A major technical step is taken when the Bluetooth piconet network architecture, a strict star topology, is extended into a scatternet architecture, in which piconets are allowed to interconnect. The combinations of network topologies will increase dramatically and methods to create robust, but still efficient, scatternets become crucial. To create a good scatternet connectivity, bandwidth and delay requirements, among others, must be considered. In addition, many mobile phones and other electronic devices already are or will soon be Bluetooth-enabled. Consequently, the ground for building more complex ad hoc networks is being laid. In parallel with the development of the Bluetooth PAN technology the introduction of the third generation (3G) mobile networks are under way at a very rapid pace. The 3G systems, such as UMTS and cdma 2000 will move the Internet into the mobile world in a useful way, i.e. moving on to higher data rates in the order of hundreds of kbps instead of tenths of kbps. This development will create a push for mobile terminals that can offer high resolution images and high quality audio, requiring more computing capacity – the mobile phone will evolve from a pure voice service terminal to a multimedia platform. Perhaps the most widespread notion of a mobile ad hoc network is a network formed without any central administration, consisting of mobile nodes that use a wireless interface to send packet data. Since the nodes in a network of this kind can serve as both routers and hosts, they can forward packets on behalf of other nodes, but also run user applications [1]. An ad hoc network could be expected to operate in a network environment in which some or all the nodes are mobile, which contrasts to traditional wireline or wireless networks. In this dynamic environment, the network functions must run in a distributed fashion, since nodes might suddenly disappear from, or show up in, the network. In general, however, the same basic user requirements for connectivity and traffic delivery that apply to traditional networks will apply to ad hoc networks as well. Below, we discuss some typical operational characteristics and how they affect the requirements for related networking functions. To limit the scope of the discussion, we will examine the case of a PAN-oriented ad hoc network that involves a mix of notebook computers, cellular phones, and PDAs.
Given the operating conditions listed above, what can the user expect from an ad hoc PAN network? The support of multimedia services will most likely be required within and throughout the ad hoc PAN. As an example, the following four quality-of-service (QoS) classes would facilitate the use of multi-media applications including
These service classes have been identified for QoS support in the UMTS network and should also be supported in the PAN environment. However, the inherent stochastic communications quality in a wireless ad hoc network, as discussed above, makes it difficult to offer fixed guarantees on the services offered to a device. A reasonable approach is to offer QoS guarantees between devices in the PAN for the case they are not moving, or moving slowly, in relation to each other, i.e. the traffic uses the same paths in the PAN and are not redirected. As soon as paths need to be rerouted, applications could still work but without, or less, QoS guarantees and the network may resort to a best effort support only.
The issue of routing packets between any pair of nodes in an ad-hoc PAN, or network of PANs, becomes a challenging task because the nodes can move randomly within the network. A path that was considered optimal at a given point in time might not work at all a few moments later. Moreover, the stochastic properties of the wireless channels and operating environment add to the uncertainty of path quality. Traditional routing protocols are proactive in that they maintain routes to all nodes, including nodes to which no packets are being sent. They react to any change in the topology even if no traffic is affected by the change, and they require periodic control messages to maintain routes to every node in the network. The rate at which these control messages are sent must reflect the dynamics of the network in order to maintain valid routes. Thus, scarce resources such as power and link bandwidth will be used more frequently for control traffic as node mobility increases. An alternative approach involves establishing reactive routes, which dictates that routes between nodes are determined solely when they are explicitly needed to route packets. This prevents the nodes from updating every possible route in the network, and instead allows them to focus either on routes that are being used, or on routes that are in the process of being set up. In a simulation study, SwitchLab [2] (Ericsson Research) compared two reactive routing algorithms (ad hoc on-demand distance vector, AODV [3], and dynamic source routing, DSR [4] and one proactive routing algorithm (destination-sequenced distance vector, DSDV [5]). All these protocols are under development within the IETF MANET working group [1]. In every case tested, the reactive algorithms outperformed the proactive algorithm in terms of throughput and delay. Moreover, the reactive protocols behaved similarly in most of the simulated cases. The main conclusion drawn from this study is that a reactive approach might well be necessary in a mobile environment with, such as in a PAN or in interconnected PANs. The proactive approach depletes too many resources updating paths (if the route-update periods are to match the mobility of the nodes). If the update interval is too long, the network will simply contain a large amount of stale routes in the nodes, which results in a significant loss of packets.
Seen from the viewpoint of the traditional mobile network, a Bluetooth-based PAN opens up a new way of extending mobile networks into the user domain. Someone on a trip who has access to a Bluetooth PAN could use the GPRS/UMTS mobile phone as a gateway to the Internet or to a corporate IP network. In terms of traffic load in the network, the aggregate traffic of the PAN would typically exceed that of the mobile phone. In addition, if Bluetooth PANs could be interconnected with scatternets, this capacity would be increased. Figure 1 shows a scenario in which four Bluetooth PANs are used. The PANs are interconnected via laptop computers with Bluetooth links. In addition, two of the PANs are connected to an IP backbone network, one via a LAN access point and the other via a single GPRS/UMTS phone. Figure 1. Four interconnected Bluetooth PANs, with both a WLAN and a GPRS access running simultaneously. A PAN can also encompass several different access technologies—distributed among its member devices—which exploit the ad hoc functionality in the PAN. For instance, a notebook computer could have a wireless LAN (WLAN) interface (such as IEEE 802.11 [13] or HiperLAN/2 [14]) that provides network access when the computer is used indoors. Thus, the PAN would benefit from the total aggregate of all access technologies residing in the PAN devices. As the PAN concept matures, it will allow new devices and new access technologies to be incorporated into the PAN framework. It should also eliminate the need to create hybrid devices, such as a PDA-mobile phone combination, because the PAN network will instead allow for wireless integration. In other words, it will not be necessary to trade off form for function. In situations where two PAN Bluetooth nodes cannot communicate directly, intermediate forwarding nodes could be used to reach a destination several Bluetooth hops away. Hence, here Bluetooth networking functions may leverage from the large amount of radio multihop research being pursued at several academic institutions today, e.g. [17, 18]. In all the scenarios discussed above, it should be emphasized that the short-range radio technology, such as Bluetooth, is a key enabler for introducing the flexibility represented by the PAN concept. Thus, the PAN scenario enables the user to personalize his personal media environment, by allowing a free distribution of applications and functions within the PAN – a wider variety of terminals may be accepted to access, and take advantage of, the 3G networks. Worldwide, the industry has shown a tremendous interest in techniques that provide short-range wireless connectivity. In this context, the Bluetooth technology is seen as a key component [6-9] However, Bluetooth technology must be able to operate in ad hoc networks that can be stand-alone, part of the "IP-networked" world, or a combination of the two. Bluetooth must be able to carry IP efficiently in a PAN, since these will be connected to the Internet via UMTS or corporate LANs, and will contain IP-enabled hosts. Generally speaking, a good capacity for carrying IP would give Bluetooth networks a wider and more open interface, which would most certainly boost the development of new applications for Bluetooth. Bluetooth is a wireless communication technology that uses a frequency-hopping scheme in the unlicensed Industrial Scientific-Medical (ISM) band at 2.4 GHz. Two or more Bluetooth units that share the same channel form a piconet. Within a piconet, a Bluetooth unit can play either of two roles: master or slave. Each piconet may only contain one master (and there must always be one) and up to seven active slaves. Any Bluetooth unit can become a master in a piconet. Furthermore, two or more piconets can be interconnected, forming what is called a scatternet. The connection point between two piconets consists of a Bluetooth unit that is a member of both piconets. A Bluetooth unit can simultaneously be a slave member of multiple piconets, but only a master in one. Moreover, because a Bluetooth unit can only transmit and receive data in one piconet at a time, its participation in multiple piconets has to be on a time division multiplex basis. The Bluetooth system provides duplex transmission based on slotted time-division duplex (TDD), where the duration of each slot is 0.625 ms. There is no direct transmission between slaves in a Bluetooth piconet, only from master to slave and vice versa. Communication in a piconet is organized so that the master polls each slave according to a polling scheme. A slave is only allowed to transmit after having been polled by the master. The slave will start its transmission in the slave-to-master timeslot immediately after it has received a packet from the master. The master may or may not include data in the packet used to poll a slave. However, it is possible to send packets that cover multiple slots. These multislot packets may be either three or five slots long. When a PAN user wants to connect to other PANs, the scatternet capability in Bluetooth will serve as the foundation for the IP network. Similarly, if one or more PANs connect to an Internet access point on a LAN (LAN access point, LAP) a scatternet will provide the underlying Bluetooth infrastructure. Scatternets can also be rearranged to give better overall performance. For instance, if two slave nodes need to communicate, it might be wiser to create a new piconet that solely contains these two nodes. The nodes can still be part of their original piconets if traffic flows to or from them, or if they need to receive control information. Since the frequency-hopping spread-spectrum (FHSS) system makes Bluetooth very robust against interference, new piconets gain substantially more capacity than they lose as a result of increased interference between them. The master unit of a piconet controls the traffic within the piconet by means of polling. A polling algorithm determines how bandwidth capacity is to be distributed among the slave units. The polling algorithm assesses the capacity need of the units in the scatternet and ensures that capacity is shared fairly, or according to a weighted capacity-sharing policy. In a scatternet, at least one Bluetooth unit is member of more than one piconet. These interpiconet nodes might have a slave role in numerous piconets but can have the master role in only one of them. The main challenge is to schedule the presence of the interpiconet node in its different piconets, in order to facilitate the traffic flow both within and between piconets. Given that the interpiconet node is a single transceiver unit, only one of its entities (master or slaves) can be active at a time. To manage scatternet traffic efficiently, the intrapiconet scheduler must consider the interpiconet scheduler when it polls the slaves of a piconet. For instance, the intrapiconet scheduler in a master unit might not schedule to poll a slave node when the latter is active in another piconet. However, the interpiconet scheduler might schedule this node more often, after it is once again active in the piconet. Packet forwarding becomes necessary when packets must traverse multiple hops between the source and destination nodes. Given that IP will be commonplace in scatternet contexts, one might conclude that routing over the scatternet should be handled within the IP layer. However, there are good arguments for taking another course for Bluetooth scatternets of limited size, as is expected for PANs.
In summary, the best way of providing networking among the nodes in a Bluetooth scatternet would be to perform the packet forwarding on a Bluetooth network layer residing below IP. This approach is also pursued within the Bluetooth SIG PAN working group, where a networking protocol, referred to as the Bluetooth Network Encapsulation Protocol (BNEP), is being developed to provide an Ethernet like interface to IP. In Figure 2 BNEP provides a broadcast segment across a scatternet which enables ordinary IP hosts to be interconnected in a Bluetooth ad hoc scatternet. The scenario in the figure may be a case where several PANs are involved in an ad hoc meeting. Note that the piconets and PANs do not necessarily have to be mapped one to one, i.e. depending on the best topology several PANs may be in one piconet or a PAN may consist of multiple piconets (a scatternet). This independence allows for efficient and flexible ad hoc PANs since rearrangements may be done without changing the PAN memberships.
Figure 2. The Bluetooth Networking Encapsulation Protocol will offer a broadcast segment infrastructure to the IP layer, similar to Ethernet, potentially spanning over an entire scatternet. In the first release of the BNEP, the focus is to provide the broadcast segment within one piconet only, but BNEP hosts the potential to offer a scatternet wide broadcast segment. From a protocol point of view, BNEP will be placed on top of the link layer protocol of Bluetooth, the L2CAP (Logical Link and Control Adaptation Protocol). L2CAP comprises functions for segmentation and reassembling between L2CAP packets and Bluetooth baseband packets. Multiplexing of protocols apart from BNEP (e.g. OBEX, RFCOMM) over the Bluetooth radio link is also made possible in L2CAP. However, L2CAP is strictly link oriented and cannot forward packets beyond the link since there is no concept of network wide addressing within L2CAP. BNEP will add this networking functionality by utilizing the unique MAC address of each Bluetooth interface. The location of BNEP in the Bluetooth IP stack is depicted in Figure 3. Figure 3. Location of BNEP in the Bluetooth IP stack.
In the previous sections, network access via a 3G (e.g. UMTS) phone was pointed out as one of the most important scenarios to allow PANs to interact with the Internet. In order to further detail that scenario, this section will describe and discuss how a Bluetooth PAN may access a GPRS network. Mainly, since it is crucial to enable an efficient Internet access for PANs already with the GPRS network so as to allow a smooth and natural introduction of UMTS terminals into peoples PANs. As discussed earlier, the Bluetooth network will, through BNEP, operate on OSI layer two, i.e. all devices in a single piconet, or a scatternet appear to be connected to the same broadcast segment as seen from the IP level. The mechanisms that are normally used on broadcast segment infrastructures, such as Ethernet, may be used here as well, i.e. DHCP for dynamic host configuration (where applicable), ARP for address resolution, and address auto-configuration when no network to retrieve an IP address from can be found. However, the current way a terminal TE, e.g., a notebook computer, connects to the GPRS network is via a PPP (point-to-point protocol) set-up through the GPRS phone. This means that the broadcast nature of the PAN would not be utilized. To do so the PPP approach should be extended with a BNEP approach that is similar to how networking is done on an Ethernet LAN today. As a short introduction to how a GPRS access is done, a description is given below on how a GPRS terminal (the mobile station, MS) establishes a connection to the Internet via the GPRS network. Figure 4. A standard GPRS core network model with a MS being part of a Bluetooth PAN. More recent developments include defining the SGSN and GGSN as server functions instead of physical network nodes. As Figure 4 above implies, the user of the MS, or a mobile device connecting via the MS, may have a choice of which remote network to connect to. The MS is not, in general, providing access to "a Network", as a normal Bluetooth Network access point would, but may provide access to one network of choice among a set of provided networks. The choice is made when a session is set up towards a remote network. The session is manifested as a Packet Data Protocol (PDP) Context, which is a shared state between the MS, the Service GPRS Support Node (SGSN) and the Gateway GPRS Service Node (GGSN). The MS expresses the choice of remote network as an Access Point Name (APN), when it sends an Activate PDP Context Request to the SGSN. The SGSN then uses the APN to look up which GGSN that provides connectivity with the desired remote network. The SGSN then continues the session establishment by sending a Create PDP Context Request to the GGSN. The GGSN may then, after the user request has been authenticated, reply with any necessary configuration information, such as an IP address for the terminal, default router and DNS address. The difference between the MS and most other conceivable Bluetooth Network Access Points is that other types of access points will typically only provide access to one particular network. This may for instance be a corporate LAN built as a switched Ethernet mesh, an ISP Internet access through ADSL, cable modem, etc. Once a mobile device has connected to such an access point, there is no other fundamental choice to be made, it is just given access to whatever network (and services) that happen to be there. Using AT-commands and PPP (e.g. as in the current Bluetooth LAN access profile), the choice of network can today be expressed by including a PDP context identifier in the pseudo-phone number that is used in the initial dial command (ATD*99*N#, where N is the PDP context identifier). The phone needs to have more information pre-configured to set up a context based on the identifier.
How should the MS in the Bluetooth PAN authenticate and connect itself, and the PAN, to the GPRS network? Here BNEP will offer LAN-like ways to connect PAN devices to the GPRS network. One approach that fits very well with BNEP is to use IEEE 802.1X (Port Based Network Access Control), where user and domain name can be acquired by the MS from, say, the notebook computer (TE). This method is also supported by the Bluetooth SIG PAN WG for user based authentication in the profile for the Bluetooth PAN. When providing network access for an entire Bluetooth PAN or a single client device, an MS might operate either as an IP router, or it can do interworking between the IP bearer protocols on Bluetooth and GPRS respectively. Interworking is the simplest alternative, in which the MS is working as a transparent packet-pipe for whatever network protocol (e.g. IPv4 or IPv6) that is used for the end-to-end communication. The first router that the device in the PAN then sees is the GGSN, and the MS gives out the IP address that it receives at PDP Context activation to the TE. The MS may in this case work as a DHCP interworking unit and give out several IP addresses to the PAN devices based on several PDP contexts. Hence, the devices on the PAN will see a DHCP server and the GGSN router in the GPRS network will see an MS that sets up several PDP contexts. In case the MS is operating as a router, the PAN can be seen as an IP subnet where the MS still may hand out IP addresses via a DHCP server function. For the devices in the PAN, the MS would in this case be the first router they would see, but the GPRS network needs to, in general, hand out only one address (one PDP context) to the MS since it is operating as a router. However, this may imply that the MS needs to implement, for instance, Network Address Translation (NAT) routing to support communication from PAN devices. Generally, this is something one tries to avoid in a small device such as a mobile telephone. In an IPv6 case, one could play with the idea to let the GPRS network hand out a prefix, from which the MS could hand out addresses to devices in a PAN. Ad hoc networks have mostly been used in the military sector, where being able to establish ad hoc communication is often a necessity. On the other hand, in the commercial sector, successful examples of ad hoc radio networks are few so far, if any. However, instead of large-scale networks, small-scale personal area networks are emerging in response to the introduction of short-range radio technologies, such as Bluetooth. Here, ease of use and flexibility are fueling the demand for ad hoc operation. In addition, a centralized network architecture would have serious problems trying to control all PAN devices. In particular, ad hoc Bluetooth networks—scatternets—will give rise to a whole new set of business and consumer applications for small, battery-driven user devices, such as mobile phones, PDAs, and notebook computers. The combination of wide-area IP connectivity via UMTS (mobile phone) access, and personal area connectivity in the PAN presents new opportunities for the user on the go. End-to-end IP networking is a key component in this respect, providing the basis on which to develop applications for PAN products. Thus, the current development of IP support for Bluetooth networks in general and for UMTS access of Bluetooth PAN in particular, is crucial. The current work in the PAN WG of the Bluetooth SIG focuses on developing IP support based on a network layer on OSI level 2, denoted BNEP, that creates a broadcast segment similar to Ethernet. This will enable a straightforward reuse of a number of IP related protocols for configuration and address resolution (such as DHCP, ARP etc.) typically suited for LAN access environments, but also for standalone or interconnected PANs. For Bluetooth PAN access to GPRS (and later UMTS) networks, on the other hand, interworking functions between the PAN protocol and the GPRS terminal configuration protocols are needed. One remaining issue in this context is whether the GPRS mobile terminal will operate as a layer 2 interworking function or a layer 3 router on the border between the PAN and the GPRS network. This requires further study to more exactly define how standard IP mechanisms are used, and if there is any need for new standardization, either in the Bluetooth SIG or 3GPP. The use of BNEP will, as seen from upper protocol levels, be very similar to connecting devices together on an Ethernet segment. As an interesting parallel, one may consider how mobile phones would support laptops or other mobile devices to access the phone, or the Internet through the phone, if the phone was equipped with a physical Ethernet adapter. The Bluetooth wireless technology in, e.g., PANs will most likely change the future way how we handle and access information, similar to how the mobile phone has changed our behaviour in terms of information vs. independence of location over the past ten years. The actual impact of Bluetooth in general, and its use in PANs in particular, can of course only be speculated upon, but it is the first realistic attempt in large scale to solve the last meter problem we often encounter – simply to get our personal devices to "talk" to each other without a hassle. Moreover, the ad hoc Bluetooth PAN opens up a common ground for (IP) applications and devices that may have a very wide span with respect to both usage and price – from the cheap handheld game pads for teenagers to the high–end multimedia devices for the business segment.
|