Design and Implementation of IP over Bluetooth for IP Mobility Support in a Heterogeneous Environment Vrizlynn L. L. Thing, Henry C. J. Lee, Xiao Ni, Daqing Zhang Laboratories for Information Technology 21 Heng Mui Keng Terrace, Singapore 119613 Email: {vriz, hlee, nixiao, daqing}@lit.org.sg Abstract - Mobility support at the IP layer is proposed by the Internet Engineering Task Force Mobile IP Working Group to define media-independent procedures, whereby a mobile device can maintain existing transport and application-layer connections despite changing its point-of-attachment. Roaming between heterogeneous wireless networks, with different link layers, is therefore possible with this IP mobility support. However, problems arise when incompatible link layers, which could not integrate well with Mobile IP to support seamless handover, are used. In this paper, a Wireless LAN and Bluetooth heterogeneous environment was set up with Mobile IP to demonstrate the problems when the Point-to-Point Protocol is the Bluetooth’s link layer. The main reason is due to the intrinsic properties of the Point-to-Point Protocol. A new method to carry IP packets over Bluetooth, named IPoBT, is designed as a protocol layer between IP and L2CAP, and implemented in the form of a network driver in Linux. This solution is able to overcome the problems in the Point-to-Point Protocol, to integrate well with Mobil IP for providing a better support for seamless handover between the heterogenous networks. Keywords – Mobile IP, Heterogeneous Network, IP over Bluetooth, Wireless LAN, Bluetooth, Point-to-Point Protocol
I. INTRODUCTION With the increasing usage of mobile devices and the desire to maintain network connectivity on the move, the need for mobility support has prompted research into the network protocols [1]. As the Internet today is made up of different types of networks, each providing varying speeds and levels of coverage, the need to support mobility across these heterogeneous networks arises, so as to allow them to inter-operate with one another. Therefore, mobility support at the IP layer [2,3] is proposed by the Internet Engineering Task Force (IETF) Mobile IP Working Group to define media-independent procedures, whereby a mobile device can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet, and without changing its IP address. However, heterogeneous wireless network access technologies, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11b Wireless Local Area Network (WLAN) [4], Bluetooth (BT) [5], and General Packet Radio Service (GPRS) [6], using different data link layers (e.g. Ethernet [7] and Point-to-Point Protocol (PPP) [8]) could create problems during handover even though mobility support is at the IP layer. This is due to
the fact that the intrinsic properties of some data link layers might not integrate well with Mobile IP to provide seamless handover. This is the case for PPP. PPP provides a standard method for transporting multiprotocol packets over point-to-point links. However, due to its intrinsic properties such as restriction to point-to-point connection, compulsory configuration and testing of data link before link establishment, and requirement to obtain a new unique address upon each connection, problems arise during integration with Mobile IP. A problem caused by the last property, which only affects mobility support in IPv4, was solved by the Mobile-IPv4 Configuration Option for PPP IPCP [9], which defines a new option for IPCP [10], so that the mobile node (MN) and its peer could use this option to negotiate the appropriate use of Mobile IP over the PPP link. However, other problems relating to the other two PPP’s properties remain, which we will illustrate with providing IP mobility support in our WLAN and BT (using Ethernet and PPP as link layer respectively) heterogeneous environment. A solution, which introduces a new way of carrying IP packets over BT, replacing PPP, is proposed and implemented. This solution, which is IP version independent, solves the problems of Mobile IP integration to provide seamless handover. The rest of the paper is organised as follows. In Section II, we discussed a related work on a WLAN-GPRS trial setup [11] using Mobile IP to provide mobility support. In Section III, we present our set up of a WLAN-BT heterogeneous environment, using the Dynamics-HUT Mobile IPv4 solution [12] and the Axis OpenBT Stack [13]. The problems of using PPP as the link layer for supporting IP Mobility are then discussed. In Section IV, we present the design and implementation details of our IP over Bluetooth (IPoBT) solution to overcome these problems. Conclusions follow in Section V. II. RELATED WORK In [11], a WLAN-GPRS trial was set up to evaluate Mobile IP by conducting performance and functional tests. GPRS is using PPP as its link layer in this case. The two link layers are made to be active at all time (i.e. both the wlan interface for the WLAN connection and the ppp interface for the GPRS connection are up at the same time), such that the link layer handover is reduced to switching network interfaces in the MN. This is possible as the GPRS network
coverage area is much wider than that of WLAN and the overlapping of the coverage areas allow both interfaces to be active at the same time. Problems will arise when both coverage areas are not overlapping. This is due to the fact that the link layer of MN could not be activated if its peer is not within its coverage area, to support data link configuration and testing. These problems will be discussed in detail in the next section. III. WLAN-BT HETEROGENEOUS ENVIRONMENT SETUP WITH MOBILE IP The Dynamics-HUT Mobile IP is a Mobile IP solution for IPv4 networks, developed at Helsinki University of Technology. The software consists of three independent daemon executables, namely the Home Agent (HA), FA and MN. After MN moves to a foreign network, the mobility agents (i.e. HA and FA) automatically set up a tunnel between the foreign network and the home network. HA will redirect to MN packets whereby the latter is the intended recipient using the IP encapsulated tunnel [14]. Therefore, MN’s home IP address is retained.
Internet Access
eth0: 192.168.137.130
eth0: 192.168.136.190
Foreign Agent
Home Agent eth1: 10.0.1.1 eth0: 10.0.1.3
Mobile Node
Movement
ppp0: 10.0.2.1 ppp0: 10.0.1.3
Mobile Node Bluetooth Network
WLAN Network Figure 1: IP Mobility in WLAN-BT Heterogeneous Environment Setup
A WLAN-BT heterogeneous environment was set up as shown in Figure 1, using the Dynamics-HUT software for IP Mobility support to identify and analyze the problems with roaming between the two heterogeneous networks. The BT driver used was the Axis OpenBT Stack, which uses PPP over RFCOMM as a means of providing LAN Access [5] for BT devices. The protocol stack is shown in Figure 2. The Linux operating system [15] was used for this set up.
Applications TCP/UDP IP PPP RFCOMM L2CAP HCI Figure 2: Protocol Stack
HA and FA were configured as access routers. They were placed far apart to avoid overlapping of coverage areas. Initially, MN was at the Home Network, which in this case, is the WLAN Network. The link layers of the WLAN and BT (i.e. eth and ppp interfaces) on HA and FA respectively, and both interfaces on MN, should be activated. This is to reduce link layer handover to merely switching the network interfaces on MN. The Home IP Address should then be allocated to MN for both the eth and ppp interfaces. This is not a problem for WLAN, as the Ethernet interface could be activated even when MN is not connected to the Home Network and be allocated an IP address. However, this could not be achieved for BT when MN is not within the Foreign/BT network. This is due to the fact that PPP is used as the link layer for the BT driver. In order to establish communications over the point-to-point link, each end of the PPP link must first send Link Control Protocol (LCP) packets to configure and test the data link. After the link has been established, PPP can then send Network Control Protocol (NCP) packets to choose and configure one or more network layer protocols. Therefore, the BT interface could not be set up before it moves to the Foreign Network. In our case, the BT device has first to negotiate the configuration parameters with its peer to establish the link during connection establishment (i.e. after MN has moved to the Foreign Network), before being allocated an IP address. This will lead to a delay during handover when MN moves into a Foreign Network, as compared to the WLAN, which allows driver loading and resource allocation beforehand (even if MN is not within coverage area of the WLAN Access Router). Another problem with the BT network is that the BT Access Router only allows a single connection to it. This is due to PPP, which only allows a point-to-point connection. To support multiple MNs, the BT Access Router must have multiple BT devices (i.e. one for each MN) in it. This will not only increase the cost of setting up a BT network to support connections to multiple nodes, but is also not practical as it ends up with the situation that one node could communicate with only one other. These problems are overcome by introducing a new way of carrying IP packets over BT. The design and implementation of our solution is described in the following section. IV. IP OVER BLUETOOTH SOLUTION The design of the IPoBT between IP and L2CAP is aimed at creating an Ethernet-like interface as shown in Figure 3.
Applications TCP/UDP IP IPoBT L2CAP HCI Figure 3: Modified Protocol Stack
In this design, an Access Point can connect with seven slaves, establishing a Local Area Network (LAN), whereby each slave or Access Point has one IP address as shown in Figure 4. The Access Point will have the Access Router functionality incorporated.
positive acknowledgement for the previous packet sent. If the acknowledgement indicates an error, the sender will proceed to retransmit the previous packet until a positive acknowledgement is received. A positive acknowledgement is indicated by a Packet Type of 0xFF, and a negative acknowledgement is indicated by a Packet Type of 0x11. This transmission reliability is increased at the expense of the higher overhead. Packet Type (1 byte) Figure 6: IPoBT Acknowledgement Packet Format
B. IP-IPoBT Interface WAN
Access Point
End Point 1
End Point 2
End Point 7
Figure 4: Bluetooth Local Area Network
When an IP packet comes from the Wide Area Network (WAN), IPoBT in the Access Point analyses the destination IP address in this packet and sends it to the corresponding Bluetooth time slot. The End Point with that IP address will receive this packet. If an IP packet comes from the interior LAN, IPoBT in the Access Point will parse the packet for the destination IP address. In the case of the destination IP address being the LAN address, it will not send this packet to the IP layer, but will forward it directly to the appropriate End Point instead. This is the case of End Points sending data from peer to peer. If the packet contains a destination IP address not matching the LAN, this packet is an outgoing packet to WAN. IPoBT in the Access Point will send it to the IP layer, which forwards it to WAN. A. IPoBT Data Packet As the data transfer by BT device is not very reliable, packet loss occurs occasionally. Therefore, the IPoBT layer encapsulates the IP packet and adopts the connectionorientation data transfer. The format of the IPoBT data packet is shown in Figure 5. The Packet Type is 0 and the Checksum is computed for the IP Packet. Packet Type (1 byte)
Checksum (4 bytes)
IP Packet (1500 bytes)
Figure 5: IPoBT Data Packet Format
When the receiver receives this packet, it will perform a checksum computation on the IP Packet to check if the received data is without error. It will then send an IPoBT acknowledgement packet (as shown in Figure 6) to the sender regardless of the result of the checksum computation. The sender will not send the next packet until it receives a
IPoBT is implemented with L2CAP and HCI in the form of a device driver. In Linux [16], there is a structure, named device, which defines the network implementation functions and parameters, as shown in Figure 7. The explanation of the functions, which are developed, in our IPoBT implementation is given as follows. struct device { int (*open)(struct device *dev); int (*stop)(struct device *dev); int (*hard_start_xmit)(struct sk_buff *skb, struct device *dev); ... } Figure 7: Linux Network Device Structure
int (*open)(struct device *dev) This function opens the interface. It is activated when the ifconfig command is launched. The open method registers all the necessary system resource (e.g. I/O ports, IRQ, DMA, etc.), turns on the hardware, and increments the module usage count. int (*stop)(struct device *dev) This function closes the interface. Operations in the open method are reversed. int(*hard_start_xmit)(struct sk_buff *skb, struct device *dev) This function is in charge of the output of data to the hardware. The data to be sent is in the socket buffer (sk_buff) structure. In IPoBT, this function eventually invokes the bluetooth L2CAP function, int l2cap_send_data(bt_tx_buf *tx, l2cap_con *con). The bt_tx_buf structure contains the data to be sent and the l2cap_con structure is the corresponding L2CAP channel through which the data will be sent to air. After loading our IPoBT driver, the “ifconfig btnet0 up” is executed to invoke the int (*open)(struct device *dev) function. This initialises and allocates system resource to activate the BT ethernet-like interface. With the “ifconfig btnet0 down” command, the function, int (*stop)(struct device *dev), is invoked to reverse the procedures performed by the open function.
C. IPoBT-L2CAP Interface Apart from the above mentioned network driver functions, IPoBT also performs upper layer functionalities for the L2CAP layer. Figure 8 defines the BT related functions and parameters, some of which are for the connection and disconnection of the IPoBT layer with its remote peer. static protocal_layer ether_layer = { ETHER_LAYER, ether_connect_ind, ether_config_ind, ether_disconnect_ind, ether_connect_pnp, ether_connect_cfm, ether_config_cfm, ether_disconnect_cfm, ether_receive_data, NULL } Figure 8: Upper Layer Functions for L2CAP in IPoBT
ETHER_LAYER is the identifier number of this upper layer. Figure 9 demonstrates the sequence of connection, data transfer and disconnection between an End Point and the Access Point. The connection request can be issued, either by manually running the connection command, or be automatically invoked when Access Point scans its reachable area for End Points within its coverage. Initiator
L2CAP
L2CAP
Target
ether_connect_req l2ca_connect_req
l2ca_connect_ind
ether_connect_ind
l2ca_connect_rsp ether_connect_cfm
ether_config_cfm
D. Data Transfer Functions
l2ca_connect_cfm l2ca_config_req
l2ca_config_cfm
l2ca_config_ind
ether_config_ind
l2ca_config_rsp
Data Transfer ether_disconnect_req l2ca_disconnect_req l2ca_disconnect_ind ether_disconnect_cfm
l2ca_disconnect_cfm
which the indication arises. In the ether_connect_ind function, l2ca_connect_rsp(l2cap_con* con) is called to reply to the connection request. At the connection request site, l2ca_connect_cfm invokes the callback function, ether_connect_cfm, which is awaken to call l2ca_config_req(l2cap_con* con, unsigned short in_mtu, flow *outflow, unsigned short flush_timeout, unsigned short link_timeout). The parameters, in_mtu, outflow, flush_timeout and link_timeout, are then negotiated with the remote site. The remote site receives this configure request by alerting ether_config_ind(l2cap_con* l2cap) through l2ca_config_ind. It then calls l2ca_config_rsp(l2cap_con* con, unsigned int out_mtu, flow* in_flow, int ok). ok is the response to the target, sent by initiator, to indicate whether the target agrees with these parameters. out_mtu and in_flow are sent to the initiator to obtain approval. This awakes ether_config_cfm(l2cap_con* con) through l2ca_config_cfm to confirm the configuration. From then, both initiator and target will be connected. If there is any disagreement with the parameters, the negotiation process will be repeated until an agreement is reached. If the initiator intends to end this connection, it issues ether_disconnect_req(l2cap_con* con), which triggers l2ca_disconnect_req. The target receives this indication through ether_disconnect_ind(l2cap_con* con) from l2ca_disconnect_ind, and calls l2ca_disconnect_res(l2cap_con* con) to respond to the disconnection request. The initiator receives the response through ether_disconnect_cfm(l2cap_con* con), invoked by l2ca_disconnect_cfm, and ends the connection.
ether_disconnect_ind
l2ca_disconnect_res
Figure 9: IPoBT Connection, Data Transfer and Disconnection Sequence
When the initiator (either Access Point or End Point) needs to establish a connection with a target, it calls the ether_connect_req(unsigned char *bt_addr) function. bt_addr is the destination BT hardware address. This function then calls l2ca_connect_req(unsigned char *bt_addr). At the destination site, l2ca_connect_ind will invoke a callback function, ether_connect_ind(l2cap_con *l2cap), which indicates that there is a connection request coming in. Structure l2cap_con comprises the channel, from
In the IPoBT driver, there are two main functions serving as the interface between the driver and the hardware, i.e. the input and output data functions. When there is data input from the hardware, the interrupt will awake its interrupt routine. This routine is in charge of sending that data to the IP layer. Therefore, in the data input case, the hardware interrupter initiates all the relevant functions. This interrupt number is configured during the OS boot up phase. If bluetooth device is connected to the system via the serial port, the UART interrupter routine will call void ether_receive_data(l2cap_con *l2cap,u8 *data,u32 len). This function is registered as one of the upper layer functions of the L2CAP layer (Figure 8). The l2cap_con structure is the L2CAP channel, through which data will be received from air. The data pointer points to the received data and len is the length of the data. Received data should be a complete IP packet. When the IP layer has data to be sent to the hardware, it calls the hard_start_transmit method (Figure 7) to put the data on an outgoing queue. Therefore, all the output functions are activated by this hard_start_transmit function
There are two scenarios to be considered for the data transfer. 1. IP packet is sent from endpoint to endpoint For a standard network card, the card manufacturer defines the hardware address for each network card. In the case of IPoBT, this hardware address is the BT address. It is registered when initializing its Ethernet interface. Therefore, in the program point of view, there is no difference between the BT address and the Ethernet card address. Link layer transmits a packet to a destination only by its destination hardware address, rather than its IP address. It is the same for receiving data. The BT device only takes in the packet if the hardware address matches its own. However, we are mainly concern with the IP address in the programming point of view. Therefore, a table, which maps the IP address to its hardware address, is necessary. When the Access Point receives a packet, whose destination IP address points to the local network, it obtains the corresponding destination BT address by looking into the mapping table. The ether_receive_data function will then call the l2cap_send_data function and relay this packet to the correct End Point, rather than sending it to its upper layer, i.e. IP layer. 2. IP packet is sent from endpoint to external world If the destination IP address of the packet belongs to the external networks, the ether_receive_data function will call ether_type_trans (struct sk_buff *skb, struct device *dev), which is a Linux system call, for sending IP packets to the IP layer. Therefore, the Access Point must take both scenarios into consideration. To the End Points, IP packets need only be sent to the Access Point, regardless of its destination. With this IPoBT driver, it will then be possible to activate the BT link layer even before MN moves into the coverage area of the Access Point. Therefore, link layer handover is now reduced to merely switching the network interfaces (i.e. eth and btnet) on MN. This will lead to a better support for seamless handover since initialisation and system resource allocation for the BT device on MN and FA could be performed before the handover. This implementation also allows the simultaneous of seven nodes to the BT Access Point instead of the single point-to-point connection. Therefore, a total of eight BT devices is required for the seven links instead of the fourteen, which would be needed if PPP was to be used. V. CONCLUSIONS In this paper, a WLAN and BT heterogeneous environment was set up using Mobile IP to provide mobility support. This setup was used to demonstrate the problems
when wireless network access technologies use incompatible link layers (in this case, PPP), which could not integrate well with Mobile IP to support seamless handover. The reasons being 1) unable to initialise link layer before handover and 2) unable to support multiple nodes simultaneously with an Access Point, are mainly due to the intrinsic properties of PPP. A new method to carry IP packets over BT, named IPoBT, was designed as a protocol layer between IP and L2CAP, and implemented in the form of a network driver for the BT device in Linux. This IP version-independent solution enables the BT link layer to be ready before handover and therefore reduces the handover delay, which would be incurred if initialisation is performed during handover instead. A better support for seamless handover could then be achieved. The new driver could also supports up to seven simultaneous connections to the Access Point, instead of the single point-to-point connection by PPP. REFERENCES [1] C.E. Perkins, "Mobile networking in the Internet," ACM Mobile Networks and Applications Vol. 3, 1998 [2] C. Perkins, “IP Mobility Support for IPv4”, IETF RFC 3220, Jan. 2002 [3] D. B. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”, IETF Internet Draft (work in progress), May 2002 [4] IEEE 802.11b Wireless Local Area Network Standard, http://grouper.ieee.org/groups/802/11/index.html [5] Bluetooth Specifications, http://www.bluetooth.com [6] Third Generation Partnership Project Specifications, http://www.3gpp.org/specs/specs.htm [7] IEEE 802.3 100BASE-T Fast Ethernet Standard, http://grouper.ieee.org/groups/802/3/ [8] W. Simpson, “The Point-to-Point Protocol”, IETF RFC 1661, July 1994 [9] J. Soloman, S. Glass, “Mobile-IPv4 Configuration Option for PPP IPCP”, IETF RFC 2290, Feb. 1998 [10] G. McGregor, “The PPP Internet Protocol Control Protocol (IPCP)”, IETF RFC 1332, May 1992 [11] A. Sanmateu, L. Morand, E. Bustos, S. Tessier, F. Paint, A.M. Sollund, “Using mobile IP for provision of seamless handoff between heterogeneous access networks, or how a network can support the Always-On concept”, EURESCOM Summit 2001, Nov 2001 [12] Dynamics-HUT Mobile IP WWW site, http://www.cs.hut.fi/Research/Dynamics [13] Axis OpenBT Stack WWW Site, http://developer.axis.com/software/bluetooth [14] C. Perkins, “IP Encapsulation within IP”, IETF RFC 2003, Oct. 1996 [15] Linux WWW site, http://www.linux.org [16] A. Rubini, J. Corbet, “Linux Device Drivers”, 2nd Edition, June 2001
