Distributed Virtual Network Interfaces to support intra-pan and PAN-to-infrastructure Connectivity

Transcription

1 Distributed Virtual Network Interfaces to support intra-pan and PAN-to-infrastructure Connectivity Kaouthar Sethom, Mehdi Sabeur, Badii Jouaber, Hossam Afifi, Djamal Zeghlache Institut National des Télécommunications, Evry, France firstname.lastname@int-evry.fr Abstract In emerging Personal Area Networks (PANs), consisting of heterogeneous devices and nodes, dynamic Intra- PAN and PAN-to-infrastructure connectivity should be achieved transparently to end users and applications. This paper proposes a Distributed Virtual Network Interface (D) solution for PAN device discovery, seamless handover and routing. D is an extension of the concept designed for seamless vertical handover in the case of a single device with multiple interfaces. The D concept consists of making all PAN interfaces available via a common distributed virtual interface to mask changes in the PAN dynamics and connectivity. Keywords- Personal Area Network, Distributed Virtual Network Interface, seamless handover, L2 routing, device and gateway discovery. I. INTRODUCTION Even if for many years users have been promised seamless connectivity, any time and anywhere, wireless technologies are yet to offer this seamless environments to end users. Among wireless access technologies that have emerged, no particular access solution is appropriate for all applications, scenarios and contexts. For instance, Bluetooth is appropriate for short range communications and energy limited devices WiFi is well suited for wireless access for low mobility users on campuses and local area networks, while is able to manage large scale terminal mobility and provides higher security levels. This has lead to heterogeneous environments with multiple interfaces lacking embedded enablers for interoperability. For instance, current vertical handover solutions require end users to manually configure their terminal connectivity of their terminals (when switching from one access technology to another). This often causes the restarting of ongoing applications because of interactions between higher and lower protocol layers. The main objective for 4G and B3G networking solutions is to address these challenges to provide an Always Best Connected (ABC) solution [1] in heterogeneous environments. With ABC, users should be able to dynamically switch between different access networks in order to reach required or preferred security and QoS levels. ABC includes both horizontal and vertical handovers that should be performed seamlessly with minimum complexity and maximum transparency to users and applications. Virtual interfaces can be useful to alleviate IP address changes during mobility. Network applications and protocols consider IP addresses as non-volatile and use them as identifiers in data structures. When the IP address of a given terminal changes, applications fail and have to be restarted to take into account the new IP address. These impediments result in limited user friendliness and are in contrast to the open, easy-to-access and easy-to-use Internet paradigm. They are motivating this work Most ABC solutions assume stand alone mobile terminals switching between different access networks according to context and reaching external networks in one hop. In the PAN concept, users can rely on the availability of multiple networking interfaces to connect to external networks via other PAN devices using multiple hops. (c.f. Section II). This requires discovery, addressing and routing mechanisms within the PAN. The Virtual network Interface () is one promising ABC solution for stand-alone devices [2]. This paper extends the framework to the PAN context by introducing a distributed version considering the PAN as a unique logical network entity. The proposed solution called D (Distributed Virtual Network Interfaces) includes addressing (as in ), a discovery mechanism and a layer-2 routing solution. Section 2 of this paper presents PAN requirements and challenges for seamless mobility and routing. Section /05/$20.00 (C) 2005 IEEE

2 describes the virtual network interface concept as background for the proposed D solution, followed by the architecture of the proposed distributed virtual network interface in section 4. Performance studies are presented in section 5. II. PANS SPECIFIC REQUIREMENTS A PAN can be defined as the personal sphere composed of a set of interconnected devices moving with a given user. PAN devices may use heterogeneous technologies. Managing the PAN includes organizing and selecting intra-pan connectivity as well as PAN-to-Infrastructure connectivity. Depending on the context, some of the PAN devices may play the role of gateways to external networks (e.g. WLANs, GPRS, or wired networks), while others can only ensure Intra-PAN connectivity. PAN connectivity should be based on available networks, battery status, link layer conditions, mobility, security, requested QoS as well as user and application preferences. Since the PAN context may change dynamically, PAN connectivity need to be updated frequently. Appropriate addressing and routing mechanisms are also required. Such dynamic PAN configuration should be automated, transparent and induce minimum complexity to end users and applications. The aim is also to reduce computing and memory requirements. III. THE VIRTUAL NETWORK INTERFACE CONCEPT of access technologies is made transparent to higher-layer protocols even during vertical handovers. adds a new virtual MAC layer (Figure 1) so that a unique unicast IP address can be assigned over the virtual MAC entity. Applications receive/send flows from/to this single virtual MAC interface. The virtual MAC interface is responsible of spreading and redirecting received and sent flows to the in-use network interface. It stores information about network devices in a specific table that is dynamically updated. It periodically evaluates the status of these network interfaces and is able to selects the suitable one to use. For instance, the can use the carrier signal to check if a given interface is alive (information about the physical layers are available through its Netlink interface [3]). The virtual MAC is generally taken from the first active network device. It is then assigned to all following interfaces and remains Upper layers TCP IP, ICMP, ARP Virtual MAC address B Bluetooth G Virtual Interface The Virtual Network Interface () solution [2] is proposed as an ABC solution in the case of a unique device with multiple network interfaces. Its main concept is to add a specific adaptation interface within the protocol stack. This adaptation interface takes in charge interactions between the IP and the data link layers and allows the use of a unique IP address over different wireless technologies. IV. Adaptation plan FIG.1: VIRTUAL INTERFACE ARCHITECTURE THE DISTRIBUTED VIRTUAL NETWORK INTERFACE SOLUTION The concept achieves the following desirable goals: - Preserving communication: Once a session has been established between end points, from the application point of view, the connection is persistent even though the network interface changes. - Use of different network interfaces: from the host to the MAC layer (within the operating system) it should be possible to use different network interfaces for the physical connection to the network. - Transparency: applications are not disturbed by changes in network devices. - Minimal changes: to current network structure. - Efficient handoff: the delay during handoff should be minimized and avoided, if possible. assigns a unique virtual MAC address to all the link layers available on one terminal. Therefore, the heterogeneity The Distributed Virtual Network Interface solution consists of extending the concept to the entire PAN. The idea here is to pool together all available connectivity resources behind this distributed virtual interface (Figure 2). The interface used for ingress and egress traffic is selected according to device capabilities, application requirements and available access networks characteristics (c.f. section 2). As applications could run over any of the PAN devices, a path toward external networks should be established. With D, the PAN is considered as a unique logical network entity, where all network interfaces, available on any of the PAN devices, are shared in a common distributed pool of networking resources (Figure 2). This pool is made available for all applications running on any of the PAN devices.

3 The path toward external networks is split into two segments. A first segment towards the selected gateway and a second segment from that gateway towards the destination. This results in specific issues related to Intra-PAN and PAN-toinfrastructure connectivity. In the following, we will describe how D solves these connectivity requirements by introducing new discovery, and layer-2 routing solutions in the PAN. A PAN has generally multiple gateways to connect to the global Internet and hence, multiple egress interfaces. Therefore, each device within the PAN can be considered as a multi-interface terminal when seen from the outside (see Figure 3). As said above, the selection of the PAN-to-Infrastructure interface to be used with a given context is subject to multicriteria optimization. We suppose here that user context and ambient networks related information is available to the application layers. The storage and the management of the context as well as the optimization algorithm and the selection criteria are out of the scope of this paper. Based on these assumptions, we propose a specific PAN s egress interfaces discovery mechanism (section IV.1) to update and maintain the needed context information. A. PAN s egress interfaces discovery mechanism Before packets from a PAN node hereafter referred to as source node - are routed to a destination node outside the PAN, one has to determine that the destination node is not present in the PAN. This information can be obtained by queering the Master node responsible for PAN formation and node discovery. If the destination IP address is not found inside the PAN, one of the available gateways must be selected. The proposed PAN's egress interface discovery mechanism works as follows: Gateways periodically announce their presence in the PAN by broadcasting hello messages. Each Hello message contains the list of gateways active egress interfaces, their MAC addresses and correspondent technologies, as well as the advertisement lifetime. When a PAN node receives a hello message, it records this information in a gateways local table (Figure 4). To prevent path loops, a unique broadcast ID and a hop counter are used with hello messages. These messages are also used to set up reverse routes to the gateways. My PAN BT My PDA Device 1 My PAN My Smart Phone Device 2 My PDA seen from the outside BT BT BT My PDA b Bluetooth D Bluetooth WLAN BT FIG.3: AN EXAMPLE OF PAN TO INFRASTRUCTURE CONNECTIVITY FIG.2: DISTRIBUTED VIRTUAL INTERFACE CONCEPT From inside the PAN and to reach an external peer, more than one gateway may be available. A node A may have multiple paths over which it can send packets to its peers. A first decision has to be made about path(s) selection. Let's denote this process as "remote interface selection process". Based on the information provided by the PAN s egress interfaces discovery protocol, the remote interface selection is done locally by the of node A. During this process, the remote interfaces are considered as available locally and make part of the (figure 1). Once the decision is made, packets are forwarded to the selected gateway through a Layer-2 routing mechanism (section IV.2). Reverse routes allow PAN nodes to update and refresh their routing tables. The broadcasting of hello packets is randomly delayed to prevent collisions. Note that each time a gateway detects a change in one of its egress interfaces, it notifies nodes of the PAN by sending a new "hello" message. PAN s egress interfaces Mac address Out local_interface route metric TTL 00: :A1 BT 5 1 WLAN 09:.:35 BT 9 1 BT B5: :C1 BT 1 2 FIG.4: PAN S EGRESS INTERFACES TABLE AT THE If a node on an established path fails, the links connected to the nodes become unavailable. When detecting a link failure, a node generates and broadcasts an "error packet" message. Nodes that receive "error packet" messages, have to disable

4 all paths beyond the failed link in their route cache tables. If available, an alternative route (for the global Internet) is selected in the route cache. Otherwise, when needed, the source node sends a route request message to find a new gateway. B. Layer-2 routing mechanism Routing protocols for mobile ad hoc networks have been studied for many years (MANETs [4]). However, these studies were mainly focusing on efficiency of routing algorithms in disconnected ad hoc networks. Interoperability with other networks (e.g., the Internet) has seen less attention. A novel robust forwarding strategy is then necessary to build Internet connectivity solutions for PANs. Because of possible restrictions on some PAN devices, it seems that operating at the link layer is more suitable than using ad hoc routing at the IP level. The underlay approach leads to immediate implementation benefit, as we do not have to interact with the IP layer. Moreover, the underlay discovery mechanisms inside D permit to add selfconfiguration elements and route updates in a very straightforward way. Routing to the gateway is done on a hop-by-hop basis. As explained in section IV.2.2 routing table are constructed and maintained using the PAN s egress interfaces discovery mechanism (i.e. Hello messages). As example, let s take the scenario shown on figure 5, where a source node A (with and Bluetooth interfaces) wants to send a packet to an Internet node. Using the layer, node A is able to send packets through both and Bluetooth interfaces without flow disruption. When packets arrive at node A, the consults the list of active gateways, constructed using the discovery mechanism, among the and Bluetooth interfaces. The available PAN egress interfaces are GSM, and WiFi. Let's consider that node A decides to access to the global Internet using the connection because of some applications requirements. It first filters the list of gateways with egress interfaces. Then, it selects one of them (G1 in figure 5) according to some routing metrics (shortest path, power consumption...). The "local_interface" colon (figure 5) indicates that, to reach gateway G1, node A need to use its local Bluetooth connection. Packets are then sent to the selected gateway, with the destination MAC address field set to that of G1. The destination IP address field set to the destination CN IP address. The source MAC address is set to the virtual MAC address and the source IP address to node A IP address. Each intermediary node inside the PAN will act as a wireless bridge by forwarding packets toward that gateway. Finally, when packets reach G1, it sends them to the CN using normal IP routing protocol. which de-encapsulates then forwards them to the PAN node using the described Layer-2 routing protocol. V. PERFORMANCE RESULTS In this section, performance results of the proposed D solution are presented and commented. Simulations were conducted using NS-2 simulator [6]. We mainly focused our first studies on the delay and jitter performances of the gateway switching and L2 routing process. Real time applications (e.g., voice over IP) are sensitive to packet delay and cannot typically tolerate important interruption time [ITU-T Recommendation Y.1541]. Simulation topology is shown on figure 6. The simulated PAN is composed of five nodes. Two of them are gateways. We first used a Constant Bit Rate (CBR) traffic source, which is the worst case traffic since it requires regular delivery of packets. In this scenario, node N2 sends packets of 512 bits every 15 ms to node CN. Initially, node N2 is connected to gateway GW0 via node N0. At time t 1 =19.4s, the route to GW0 is forced to fail. Node N2 has to find out a new gateway -GW1 in this scenario- to continue routing its packets. PAN Device A a BT Egress interface Device B BT b WiFi a G3 Egress technology G1 G a Local interface CN GSM WiFi a FIG.5: ROUTING IN THE D GSM D performances are compared to the AODV+ [7] scheme used for Ad hoc networks. AODV+ protocol is an extension of AODV protocol proposed to support gateway discovery and default route notion for ad hoc networks Packets destined for a node inside the PAN and arriving from nodes on the Internet are tunneled (using NEMO protocol [5] for example) from the home network to the current gateway,

5 CN cases (D and AODV+), TCP go into Slow Start mode [8] due to timeout, which increases the disruption time. Router GW0 GW1 PAN N0 N2 N1 FIG.6: SIMULATION TOPOLOGY With the proposed D approach: As soon as the route failure is detected, node N2 focuses on its local gateway table and selects a new route to the CN (GW1). With AODV+, a request is sent to all the gateways in the PAN in order to find a route to CN. Until the reception of a reply, traffic from node N2 can not be resumed. Figure 7 shows the packet sequence number received by node CN for UDP traffic. As it can be seen, the switching process between gateways is faster when using D compared to the case where AODV+ is used. In the simulated scenario, a first gain of about 30ms is observed. In fact, in AODV+ the route establishment process needs more time because of the requests send by the protocol to find new gateways. FIG.8: TCP PACKET SEQUENCE NUMBER Concerning the overhead, and in contrast to AODV+ and other existing solutions where new signaling packets are needed to rediscover gateways, the proposed D solution behaves better. In fact, the D does not introduce new signaling packets, and hence reduces signaling overhead. IV. CONCLUSION The proposed D solution provides PAN connectivity over heterogeneous devices and interfaces. D combines virtual network interface, L2 routing and a gateway discovery mechanism to achieve an ABC solution for the PAN context. Performance results indicate that D reduces packet losses induced by gateway changes within the PAN. D outperforms AODV+ used in Ad hoc networks in terms of packet losses, handoff latency and signaling overhead. REFERENCES FIG.7: UDP PACKET SEQUENCE NUMBER Moreover, packets arriving during this period are queued and retransmitted later (between t 2 and t 3 ) which increase the jitter and disturbs the transmission of the remaining data. It s only after 240 ms from the failure of the used route, that the AODV+ traffic can find its regularity and join the D traffic behavior. The same remarks can be drawn from figure 8 for TCP traffic. In this case, the gain in terms of delay is more important and is about 264ms. The D solution prevents better packet losses during the re-rerouting process. In both [1] Gosta Leijonhufvud, Multi access networks and Always Best Connected ABC MMC, Berlin 2001 [2] K. Sethom, H. Afifi, Requirements and Adaptation Solutions for transparent Handover, IEEE ICC, June 2004 [3] R. Stevens, TCP/IP illustrated, 1994, Addison-Wesley. [4] RFC 2501, [5] T. J. Kniveton, J. Malinen, V. Devarapalli, C. Perkins, Mobile Tunneling Protocol,<draft-kniveton-mobrtr-03.txt>, work in progress, November [6] Network Simulator-NS-2 notes, documentation and source codes: ww.isi.edu/nsnam/ns [7] AODV+, RFC TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms.