Optimized Support of Multiple Wireless Interfaces within an IPv6 End-Terminal1 Françoise André1, Jean-Marie Bonnin2, Bruno Deniaud3, Karine Guillouard4, Nicolas Montavont5, Thomas Noël5, Lucian Suciu2 1
IRISA – Université de RENNES 1
[email protected]
2
ENST Bretagne
{jm.bonnin,lucian.suciu}@enst-bretagne.fr 3
IRISA – INRIA Rennes
[email protected]
Abstract In future mobile systems, the end-terminals will be considerably more diverse than nowadays, and the users will have a greater choice of access technologies, offering different QoS, cost, security and so on. However, delivering advanced services, preferably seamlessly, over these various access technologies will require, not only enhanced networks, but also much more functionality i n the end-terminals. This paper describes the add-on adaptation techniques envisaged for an IPv6 end-terminal with several wireless interfaces. The adaptation mechanisms at different layers are detailed and the tight interactions amongst the layers are explained.
1. Introduction In order to access the IP network, end-users may use today various access technologies, like cellular networks (GSM, GPRS…), fixed access networks (PSDN, ADSL) as well as wired or radio local access networks (Ethernet, IEEE 802.11 or Bluetooth). These technologies offer different quality of service characteristics in term of range (e.g. global or local coverage), bandwidth, delay, error rate, security, etc. Moreover, an end-user may be provided with private or public access through different IP networks t o achieve various kinds of communication services like phone, mailing, web, video, etc. And, according to the user profile, these applications are differently characterised i n term of data rates, priority, etc. Furthermore, thanks to the wide development of the wireless technologies in particular, the user terminal may be of different types (mobile PC, smartphones, PDA, etc.) allowing a mobile end-user to be permanently connected to the IP network. This will be especially true in the near future, where single end-user terminals may more and more integrate various access interfaces, including multiple radio interfaces (e.g. Bluetooth and IEEE 802.11). However, this also means that a mobile end-user undergoes a very changing environment. Adaptation mechanisms are then strongly required to manage and optimize various possible transitions of the mobile terminal (e.g. between different 1
4
France Télécom R&D DMR/DDH Laboratory
[email protected] 5
LSIIT – ULP Strasbourg – France
{montavont,noel}@dpt-info.u-strasbg.fr
access technologies, between different IP networks), and t o make these transitions as transparent as possible for the user. Several adaptation techniques have been proposed at different levels (i.e. application, transport, IP and link layers) to optimize handovers and to better support varying characteristics of wireless links. Some proposals specify adaptive and context sensitive applications [1]. Other proposals aim to improve transport layer protocols, such as TCP over wireless links [2][3], or to specify IP protocols for the support of the terminal mobility, for example Mobile IPv6 [4]. Finally, wireless link layer protocols may integrate specific mechanisms, such as link adaptation, to optimize data transmissions over the wireless links with fluctuating quality. In order to allow the user to take advantage of the different available access technologies, this paper proposes specific adaptation techniques that will be implemented within an end-user IPv6 terminal supporting several access network interfaces. Particularly, these techniques will first allow the mobile terminal to have simultaneous or successive connections to several access technologies. Secondly, the mobile terminal will be able to automatically select the best access network according to the user and application’s preferences. Finally, it will be able to switch from one access interface to another one while minimising the impact for the user. The interest of the proposed terminal architecture relies on tight interactions amongst the different layers, spanning from the application layer till the data link layer. The following use case will be referenced in the remaining sections of the paper in order to illustrate the proposed mechanisms: an employee attends a videoconference in his office using the Ethernet connection; during the meeting, he needs to leave his office and join a colleague in another room; so, the employee continues the videoconference using the IEEE 802.11 wireless LAN access deployed in the enterprise. Finally, as he has to leave the company’s buildings t o catch the train before the end of the meeting, his video connection is interrupted and the user continues only with the audio communication over the cellular GPRS network.
This work is supported in part by the French Ministry of Industry, in the context of the French RNRT (Réseau National de Recherche en Télécommunications) cooperative project CYBERTE (http//www.telecom.gouv.fr/rnrt)
The first two parts of the paper concentrate on the existing mobility management solutions, and on the multiple interfaces manager which optimizes the handover from one interface to another. The next part focuses on the definition and the handling of profiles that are used on the one hand, to indicate user preferences and application requirements and on the other hand, to describe the characteristics of the access interfaces. Finally, the last part describes a generic model, which makes possible the adaptation of different kinds of applications, b y interacting with the various profiles.
2. Mobility management Mobile IPv6 [4] is designed to manage mobile terminals movements between wireless IPv6 networks (L3 handovers). While a mobile terminal remains in its home network, it communicates with its correspondents like any other IPv6 node. When the mobile terminal moves to a new point of attachment in another subnet, it needs to acquire a new IPv6 valid address (called Care-of address) and t o register it. Thus, the packets will be redirected to its current location. Nevertheless, a mobile terminal can not receive IP packets on its new point of attachment until the complete handover procedure finishes. Therefore, there are many extensions of Mobile IPv6 which try to improve the IP connectivity of mobile terminals, e.g. Fast Mobile IPv6 [5]. Many of these extensions use an anticipation of the mobile terminal movements to set up services for the mobile terminal in advance. This anticipation is done b y the L2 triggers [6]. A L2 trigger is an information based o n the link layer protocol in order to begin the L3 handover before the L2 handover ends. Although these triggers depend on the underlying information, they must be independent from the technology used, so that the fast handovers can be performed over all technologies.
3. Multiple Interfaces Management Multiple Interfaces Management Protocol (MIMP) is a new architecture of an IPv6 terminal (see Figure 1), split into three modules to optimize the use of multiple interfaces.
Application Technology Access Profile Profile Profile
Profile Manager
User Profile
Application Profile
Application Control API
Flow Specification Module
Communication Deamon
Interfaces Manager
Mobile IPv6
Generic Extraction Protocol Extraction
802.3
Applications
Extraction
Bluetooth
Extraction
802.11a
Modified Binding Cache L2 Triggers Extraction
802.11b
Figure 1: MIMP These modules allow the modification in real time of the flows spreading on the different available interfaces, according to the network configuration, the user
preferences and the applications needs. Moreover, MIMP aims to enhance the mobile terminal connectivity b y implementing the L2 triggers and performing smooth horizontal and vertical handovers. 3.1. Extraction Module This module extracts network information from each underlying technology. The Extraction Module is split into two parts: a specific module per technology which extracts the specific information related to that technology such as the interface availability (up or down), the measured throughput, the power consumption, etc. This information is converted into a generic format and then is sent to a generic module. The generic module allows to compare the capabilities of all interfaces and t o periodically forward them to the Interfaces Manager. When some values cross a determined threshold, the generic module triggers an unsolicited notification to the Interfaces Manager. This module also allows to anticipate the mobile terminal movement from the L2 triggers, which are implemented by each specific module. 3.2. Interfaces Manager The Interfaces Manager aims to spread and redirect flows on the available interfaces. This module groups all information from the interfaces and from the user preferences to calculate the best spreading of flows on the interfaces. This module communicates with the Extraction Module to evaluate the current characteristics of the different interfaces, and with the Profile Manager (see section 4) to determine the flows characteristics cached i n the Flow Specification Module. The flow redirection i s based on Mobile IPv6 and Fast Mobile IPv6 mechanisms extended to multiple interfaces [7]. The Interfaces Manager periodically re-evaluates the mappings between flows and interfaces to take into account the quality changes on the different interfaces. Typically, the useful bandwidth changes during time, and the network connectivity may strongly vary if the terminal is mobile, as our employee moves between his office, a colleague’s office and the train station. At any time, the Interfaces Manager must manage these changes. Moreover, this re-evaluation is immediately done after specific events, e.g. a new interface is available for communication or a new flow starts. The Interfaces Manager can also temporarily redirect a flow to other interface during handovers, thus minimizing the impact of the handover latency. In addition, the Interfaces Manager forwards the network capabilities to the upper layers. This allows the Profile Manager and the Application API to assist the applications when they adapt to the current network capacities (see sections 4 and 5). 3.3. Flow Specification Module This module establishes IPv6 flows characteristics such as: • Transmission mode (connected or not connected) • Priority policy: transmission speed, real time application, packet order, packet loss minimization, etc. • Quality of service required
• Indication to split a flow into micro-flows • This specification allows the Interfaces Manager t o determine the most adapted interface.
4. Profiles Management As we already saw, a mobile terminal will have in the future multiple network interfaces, and the “best” decision to select an interface and an access network from other possible combinations has to be taken. This decision will depend on several things such as: user preferences, requirements from applications, device capabilities, available network interface cards (NIC) and their performances, available access networks and their capabilities, etc. Nowadays, it is usually the user who supervises a communication after initialisation, and if several access possibilities exist, the user decides which one to employ. As an alternative, our approach is to study the various network interfaces (i.e., technologies), the access networks and the applications, and also to interact with the users for obtaining their preferences. At the end, we must be able t o extract in a structured way all these capabilities, requirements, and preferences in profiles. Then, the profiles are used as input by a Selection Algorithm i n order to produce a list of “suggested interfaces” which can be employed by a communication flow to pass through. It can be pointed out that the Selection Algorithm only offers middle-term (few seconds) adaptations. Finally, the Flow Specification Module will use the information supplied by the Selection Algorithm to guide the Interfaces Manager. The Interfaces Manager is the one which actually map the communication flows to appropriate interfaces, thus providing short-term (milliseconds) adaptations when needed. As it can be seen from Figure 1, an important part of the proposed terminal architecture will be dedicated to the definition and the management of the profiles. The profiles are files stored in a database, and they summarize key information about the components of the system and its interactions with the environment. More specifically, the profiles mechanism serves the following purposes: • to automatize the selection of an interface and access network by maintaining all the necessary information in the Profiles Database; • to assist the Interfaces Manager when it makes the choice of the “best” access option, by taken into consideration the applications requirements and users preferences; • to inform the adaptive applications about the unsteady capabilities of the interfaces and access networks; • to set forth a solution which works properly for the applications unaware of the modifications done to the underlying layers. Two kinds of profiles exist in the Profiles Database: generic profiles and specific profiles. The generic profiles describe which information could be stored in these types of profiles (i.e., they can be seen as patterns). The four generic profile types existing in the Profiles Database are: • Preferences and Resources Profile (PRP): it specifies how the system resources should be used. The information contained in this profile is provided b y
many sources: the administrator of the system, the users, and the applications; • Flow Description Profile (FDP): it mainly contains the QoS parameters. One part of this profile comprises the application QoS requirements and the other part contains the values of the QoS parameters monitored by the system; • Access Network Profile (ANP): it specifies the necessary information (both Layer 2 and Layer 3) t o access the network; • Network Interface Profile (NIP): it comprises the network interface card technical specifications, as well as statistics obtained during runtime. The administrator, users, or applications can instantiate these generic profiles to build specific profiles corresponding to specific cases. In the following paragraphs, we will give such an example of how the profiles are used in the scenario mentioned in the introductory part of this paper. When the employee powers-up his terminal, the Profiles Manager (PM), after consulting the PRP, instructs the Interfaces Manager (IM) to connect the terminal to the Ethernet and 802.11b WLAN. The PM also makes use of the data stored in the ANPs and it provides the IM with all information needed to accomplish its task. Next, the adaptive videoconference application is started and the PM employs now the FDP and the NIPs to produce an ordered list of preferred interfaces. This list is transmitted to the IM which maps the application flow to the Ethernet interface for the time being. Moreover, the PRP indicates to the PM that other wireless interfaces should be prepared for use in the case of videoconference application. So, the PM asks the IM to connect to the GPRS access network, yet the information from the PRP also tells that the GPRS interface should be used only for the audio communication. When the employee leaves his office, the IM automatically switches the communication from the Ethernet to the 802.11b WLAN interface. The IM chooses this option because the 802.11b interface was on the second place in the list of the preferred interfaces provided by the PM. After noticing the variations within the NIPs, the PM informs the application about the changes, thus the application can adapt itself to the scarce bandwidth resources. Finally, when the communication with the 802.11b Access Point is lost, the IM has only one choice, i.e. to use the GPRS interface. The video flow i s interrupted, the IM only redirects the audio flow to the GPRS interface, and the PM informs the application about this drastic change.
5. Adaptive applications In order to optimize the resources usage and make use of the add-on capabilities of the underlying layers, it is necessary to use adaptive applications on the platform. Because of the fluctuating resources provided by wireless network interfaces compared to wired ones, the classical adaptation for application (i.e. adaptation inside the application when starting it or setting it up) is not enough. In order to cope with continuous fluctuations of resources, a dynamic adaptation is necessary.
5.1. Dynamic adaptation In order to help the implementation of dynamic adaptation for application designers, we have developed a generic model, called ACEEL [8]. This model uses object-oriented features such as the reflexion and the Strategy Design Pattern. This design pattern is used to provide multiple behaviors for a component. Each behavior will use different resources to provide the same actions. The reflexion is used to provide dynamic adaptation b y allowing the change of behavior during the execution. Finally, to generate a state change of the component, a monitoring system is provided. This system notifies the component about the resource state changes (for the resources that are needed by the component). For each notification of the monitoring system, the component may change its behavior according to an adaptation policy, which is a script written separately and which can be modified at runtime. 5.2. Adaptive videoconference Figure 2 shows the architecture of the adaptive videoconference [9] application mentioned in section 1. At the beginning of the conference, we use the H263 codec to encode the video with a low compression rate. When the terminal loses its Ethernet connection, the bandwidth monitor from the client side notifies, through the Adapter object, the encoder located at the server side of the application. This one, according to the adaptation policy, asks the Context object to switch to the H261 encoder with a high compression rate. All these steps are realized automatically at runtime, without user's participation. 5.3. Interests of the model The ACEEL model avoids the burden of programming the adaptation for the application designer, who has only t o provide the different behaviors and to specify the adaptation policy. Moreover, these elements may be easily extended or modified. The model is generic and can be used for any type of application.
Figure 2: Adaptive videoconference
6. Conclusion A new architecture of IPv6 end-user terminals supporting multiple access network interfaces has been presented i n this paper. The main objective is to facilitate and optimize the IP network access of a mobile end-user roaming from one access network to another one of different technologies (e.g. between IEEE 802.11 WLAN and GPRS network). The proposed architecture includes specific adaptation mechanisms and relies on tight interactions amongst the different layers, from the application layer t o the link layer. First, it mainly consists of a multiple Interfaces Manager with interface Extraction and Flow Specification Modules. Secondly, the architecture includes a Profile Manager which monitors the user and the application preferences, as well as the access network interface parameters. All these are used by the Interfaces Manager to spread the various communications flows of the end-terminal over its different interfaces. Finally, the architecture proposes a generic application component model in order to provide dynamic adaptation to every kind of applications.
7. References [1] P. M. Ruiz, E. Garcia, "Improving user-perceived QoS in mobile and wireless IP networks using real-time adaptive multimedia applications", PIMRC 2002, September 2002, Lisbon [2] A. Bakre, and B. Badrinath, “I-TCP: Indirect TCP for mobile hosts," Proc. 15th International Conference o n Distributed Computing Systems (ICDCS), May 1995 [3] K. Wang, and S. K. Tripathi, “Mobile-end transport protocol: An alternative to TCP/IP over wireless links", IEEE Infocom, March 1998 [4] D. Jonhson and C. Perkins and J. Arkko, “Mobility support in I P v 6 ” , Work in Progress, Internet Engineering Task Force draft-mobileip-ipv6-19.txt, October 2002 [5] R. Koodli, “Fast Handovers for Mobile IPv6”, Work i n Progress, Internet Engineering Task Force draft-ietfmobileip-fast-hdv-05.txt", September 2002 [6] J. Kempf et al., "Supporting Optimized Handover for IP Mobility - Requirements for Underlying Systems”, Work in Progress, Internet Engineering Task Force, draft-manyfolks-l2-mobilereq-02.txt", June 2002 [7] N. Montavont, T. Noel, M. Kassi-Lahlou, “Mobile IPv6 for Multiple Interfaces (MMI)”, Work in Progress, Internet Engineering Task Force, draft-montavontmobileip-mmi-00.txt", July 2002 [ 8 ] D. Chefrour and F. André, " D é v e l o p p e m e n t d'applications en environnements mobiles à l'aide d u modèle de composant adaptatif ACEEL", Revue des Sciences et Technologies de l'Information (RSTI), série L'objet n°9. LMO conference. Vannes, France. February 2003. [ 9 ] F. André and B. Deniaud, "Multimedia systems adaptation in mobile environements", IASTED International Multi-Conference. Applied Informatics (AI 2003). Parallel and Distributed Computing and Networks (PDCN'2003). Innsbruck, Austria. February 2003.
