Mobility In Heterogeneous Networks: Integration Process

Transcript

Mobility in Heterogeneous networks: Integration Process Justino Santos1 , Nuno S´enica1 , Susana Sargento1 and Rui Aguiar1 Instituto de Telecomunica¸c˜ oes Universidade de Aveiro jsantos|[email protected] ssargento|[email protected] WWW home page: http://www.av.it.pt/ Abstract. This paper presents the integration work carried out to develop a network architecture able to provide seamless communication mobility across multiple technologies, addressing quality of service and authentication, authorization and accounting services in order to support multimedia traffic in a 4G Network. The main focus of the paper is on the integration effort performed in the IST-Daidalos project framework, which comprises the integration steps that were taken, problems that appeared while integrating mobility modules, and solutions developed to overcome the problems. 1 Introduction Nowadays, operators feel the pressure to provide the best service they can to their customers. The deployment of heterogeneous networks is thus a pressing reality to them. Mobility needs to be in place in those heterogeneous networks and as a consequence of its heterogeneity, mobile nodes can potentially roam between different types of access network (e.g. Ethernet, WLAN, 3G, DVB). The Internet Protocol version 6 (IPv6) has a vital role in these heterogeneous environments for data traffic as well as for multimedia applications, providing a convergence layer for seamless mobility and Quality of Service. IPv6 already includes basic mobility support. However, in order to achieve fast, efficient and seamless mobility it is required that no packet loss is felt, no interruption or degradation should be noticed by the user or its corresponding nodes. With the growing number of wireless users, scalability is also an issue when designing new architectures since a large number of handovers may potentially occur at the same time. Daidalos architecture [7] proposes an enhanced IPv6 mobility platform that fulfills the requirements of seamless mobility in heterogeneous environments, through fast intra- and inter-technology handovers, considering both cases of handovers triggered by users (according to its preferences) or by the network (according to resource management strategies). In this paper we present this architecture, its modules and functionalities, and address the main issues and challenges faced in the integration of the developed modules in a real test-bed. Mobility in Heterogeneous networks: Integration Process 51 The next section addresses the network architecture and the mobility developed sub-system. Section 3 presents the mobility modules and their interaction to provide seamless mobility, and section 4 describes the main problems encountered in the integration process. Finally, section 5 presents the main conclusions. 2 Network Architecture This section presents the Daidalos overall network architecture and its mobility sub-system. 2.1 Architecture Overview Fig. 1. Daidalos Network Architecture The Daidalos network architecture is depicted in Fig. 1 and comprises a future operator architecture, incorporating access, service provisioning, and contentprovider aspects. The idea is to have multiple technologies available for access, and an Access Router that interoperates the operator network with the access technologies. This Access Router is responsible for mobility management, QoS functions, security, paging, A4C control, network metering and management. It may further operate as a multimedia gateway, providing both SIP facilities and content adaptation to specific users/services. Alternative, a service proxy may be located here, with these functions relocated to a server in the core of the network. The service platform has a A4C system, handling all contractual and personalization aspects of the user identity; a QoS Broker, for managing QoS aspects at 52 J. Santos, N. Sénica, S. Sargento, and R. Aguiar the network level; a security manager, defining privacy and confidentiality levels for different communications, and interfacing with external certificate authorities; a home agent, for performing user identification in function of the address provided by the network at contract establishment time; and network management functions (paging - PA, metering - CMS, control - PBNMS). Some of these functions are also supported at the access network level, for performance reasons. An independent Public Key Infrastructure will be also integrated in the network. Service Providers (which can be third-party) can access the Service Platform on behalf of an end-user. The user profiles in the Service Platform make sure the Service Providers do not get access to information that the user is not willing to share. The user terminal contains several functional blocks. Access authentication is done through pana [4]-based services and an A4C client. Mobile IPv6 [1] and heterogeneous mobility managers control the terminal movement in the network, while QoS requests and A4C functions are signalled to the network. A more detailed description of how the user terminal interacts with rest of the Daidalos framework is found in subsequent sections. 2.2 Mobility Sub-system The Terminal Mobility (TM) sub-system [7] comprises core network and access network physical components, which implement associated functions designed to support enhanced mobility management for mobile devices being connected directly to the network infrastructure. This mobility management focuses mainly on the preparation and the execution of mobile terminals handovers that can be initiated by the terminal, due to user preferences such as cost, quality and access technology (Mobile Terminal Initiated Handover, from now on referred to as MIHO), or by the network for load balancing and resources optimization reasons (Network Initiated Handover, referred to as NIHO). The NIHO decision takes into account the ”always best connected” paradigm. Main physical components implementing TM functional entities are the QoSBroker, the access network Access Routers (ARs), access points (APs) and the mobile terminals (MTs). Terminal Mobility sub-system supports heterogeneous access networks, as 802.11, TD-CDMA and Ethernet. DVB-T/H is also being addressed in this framework to provide an integrated sub-system. The TM independent sub-system is illustrated in Fig. 2. The functions of the modules implemented in the framework of the TM subsystem are the following: Performance Management The Performance Management functionality aims at optimizing the resources in the access networks of the mobile communication infrastructure. For this purpose, it collects information about the load of the different APs and reorganizes the wireless connections based on this information. Also the radio link quality between MT and AP is monitored and taken into Mobility in Heterogeneous networks: Integration Process 53 Fig. 2. Terminal Mobility independent sub-system consideration. This interface informs TM modules of the load in the different APs and will be used as a trigger for the NIHO mobility. Enhanced Handover preparation and execution The Enhanced Handover preparation functionality retrieves and processes the necessary information at the MT to take interface selection decisions. The MT can gather information of the load of the APs through the Candidate Access Router Discovery Protocol (CARD) [2]. The mobility modules in the MT interface with Qos modules (QoS-Client - QoSC) for handover notifications and for the content adaptation functions; they also interface with registration modules for security related control. The handover execution is supported by an extension of the Fast Handover (FHO) protocol [3] operation, which integrates QoS, security and authentication issues. Multi-Homing support The Multi-Homing function supports load balancing of the flows and is implemented by an extension of the Mobile IPv6 modules at the MT and Home Agent (HA). 3 Mobility Description This section presents the modules that make part of the mobility architecture, as well as the way they interact to provide seamless mobility in heterogeneous networks. 3.1 Mobility Modules In the following, we present a brief introduction of the different TM modules and their functionalities. These modules are depicted in Fig. 3. 54 J. Santos, N. Sénica, S. Sargento, and R. Aguiar Fig. 3. Terminal Mobility independent sub-system in-depth detail Performance Management The modules associated with this function optimize the access networks’ resources in a region controlled by a QoS Broker (QoSB). These decisions are taken by the Performance Management (PM) module in conjunction with the QoSB engine module. Available QoS at APs as well as data related to signal strength are sent to the PM, which informs the QoSB. This module also accounts for end-to-end QoS information to decide on the distribution of the MTs in the access networks and to trigger NIHO. Enhanced Handover preparation To enhance techniques for mobile terminal initiated handover preparation, parameters beyond the scope of a particular link signal quality are being taken to support an Intelligent Interface Selection (IIS) function on the mobile terminal. This implies previous discovery of local (access technology characteristics) and network parameters. This discovery is supported by the CARD protocol. The control of the mobility process in the MT is assigned to the Mobile Terminal Controller (MTC), which interfaces to a terminal various access technologies through the Interface Abstraction Layer (IAL) function. The associated modules are the Mobile Terminal Controller (MT-MTC), the Interface Abstraction Layer (MT-IAL), the handover candidate discovery module (MTCARD, AR-CARD), as well as the Intelligent Interface Selection function (MTIIS). The IAL function implements sub-components to handle wireless and wired access technologies. Control of wireless access technologies is being done with the Generic Radio Access Adaptation Layer (MT-GRAAL), which implements Radio Access Layer (RAL) components for each wireless technology, such as TD-CDMA (MT-RAL-TD-CDMA) and Wireless LAN (RAL-WLAN). The IIS Mobility in Heterogeneous networks: Integration Process 55 is the module in the MT that, through the information obtained from the several available access networks, decides on the network the MT will attach to. The MTC also interfaces with two external modules, which is the QoS-Client (QoSC) for handover notifications to the terminal content adaptation function, and the Registration module for security related control (SEND [5], PANA [4]). Enhanced Handover execution To perform an efficient handover, while targeting at a low latency handover operation and efficient means to re-establish an MT context on the handover target, a Fast Handover (FHO) operation collaborates together with a Duplicating and Merging (DM) function, as well as with a Context Transfer (CT) function. DM improves performance by duplicating the packets addressed to the MT at the old AR to avoid packet loss. CT is used to transfer the mobility related state (including security information). Multi-Homing support Within the framework of the TM activities, a MultiHoming concept, that supports load balancing of the flows, has been developed and realized based on the Mobile IPv6 (MIPv6) protocol and associated network entities. Multi-Homing (MuHo) functional entities are implemented with the mobile terminal and the MIPv6 HA. Integration with Security and QoS Advanced Router Mechanisms (ARM) and QoS Broker aid in the support of QoS and A4C integration. The ARM, located in the AR, provides functionality equivalent to a basic proxy without the need to change any of the legacy applications, and can be considered as a dedicated intelligent transparent proxy. Note that the ARM can also perform application to network level QoS mapping for multimedia services, issuing the resource reservation requests to the QoS Broker and filtering the QoS configurations in the application signaling messages. It also aggregates several other modules such as A4C and Fast Handover Attendant functions which exchange information between them and forwards it to their correspondent core network applications. The QoS Broker performs admission control and manages network resources; it controls the network routers according to the active sessions and their requirements. As previously referred, it also performs load balancing of users and sessions among the available networks (possibly with different access technologies) by setting off NIHOs. The interaction between QoS Broker, ARM and mobility modules aim at providing authorized handover process with QoS support. 3.2 Mobility Process Having all these functionalities in mind we describe the overall process for triggering the two kinds of handovers as referred above. Although a MIHO is triggered by MTC, several operations are performed previously to the handover trigger. According to periodic reports from the various technologies, IAL aggregates them and passes the information to MTC, 56 J. Santos, N. Sénica, S. Sargento, and R. Aguiar which triggers the IIS with the current data provided by IAL and retrieved from CARD. IIS selects the interface realizing the ”always best connected” paradigm according to the preferences set by the user. In terms of connection preferences, it takes into account the access technology, quality, cost and provider. Also, for the access technology, it is possible to set its order of preference, such as WLAN, TD-CDMA, DVB, Ethernet. Using all these preferences and the data provided by MTC, IIS selects the interface to handover, which reports to MTC. In case the selected interface is different from the current one, MTC prepares the handover informing the Registration Module to setup the security in the new link and to get the Care of Address to use in the new network. It then triggers the Fast Handover Protocol. The handover operation may not proceed without previous authorization from the network in order to guarantee that resources and authorizations are available at the new attachment point. Therefore, Fast Handover Protocol conveys the handover request to the QoS Broker by sending ICMPv6 messages to the Fast Handover Attendant at the current AR. This handover request is then forwarded to the QoS Broker in terms of COPS Messages as described in [6]. After checking resources and authorizations to connect to the requested AP/AR, the QoS Broker issues the decision to the new AR to make it aware of this handover. The new AR can then set QoS reservations to the flow(s). At this point in time, all traffic directed to the current Care of Address is duplicated at the current AR to the new Care of Address minimizing and/or avoiding any packet loss. Upon the reception of the handover decision at the terminal, if handover is allowed, the Fast Handover Client instructs IAL to change to the new AP. After this change, the terminal informs the new AR of its presence, finishing in this way the handover procedure. After handover has completed successfully, the QoS Broker informs the old AR to delete the QoS reservations and stopping the duplication of packets. In some situations, APs have more power than terminals causing loss of connectivity before the terminal realizes it: by monitoring the signal strength reaching the APs (from the MTs), it is possible to predict a loss of connectivity before it occurs. The amount of terminals attached to an access point can also cause degradation on the link quality for all users; also users starting a demanding application may leave no room for others. These are just examples when a NIHO makes sense and should be enforced by the network. The network realizes these situations which are reported to the Performance Manager module; with the information collected from the different APs and ARs, and after selecting the new point of attachment, the Performance Manager sends this information to the QoS Broker which then triggers the handover process. The handover execution then follows the same procedure as in MIHO. 4 Integration This section presents the integration process conducted to build the mobility sub-system and the problems faced during this process. Mobility in Heterogeneous networks: Integration Process 4.1 57 Integration Requirements and Goals Modeling After identifying all the functional entities and software modules to develop, the terminal mobility software was carefully modeled. This modeling process allowed for the correct definition of the interfaces between the modules to be deployed. After this procedure, the development of the modules was distributed by different partners involved in the IST-Daidalos project. Although modeling contributed for a well thought architecture and interface definition, this was not sufficient to avoid all integration problems. Development After the modules implementation, an initial and very basic integration step was taken to verify that the software was being developed according with the specification, carefully looking at inputs, outputs and internal data procedures. At this point in time, mainly dummies were used to perform this first integration step. Testing/Integration After the development phase, a testing/integration phase started to check how the real modules interacted between them. The main objective of this phase was to check the correct working of each module and its functionalities according to the specification. 4.2 Integration Process Fig. 4. Integration Process Flow Chart In order to efficiently run the integration process, we used the iterative approach depicted in Figure 4. We started by defining a set of tests and scenarios to which the software modules should respond in a strictly defined way. After this procedure, the method used considered on testing a real software module 58 J. Santos, N. Sénica, S. Sargento, and R. Aguiar interacting only with dummy software modules supplied by the developers. The next step was to incrementally start adding more functionalities to the tested modules. In this process we always verified the behavior against the set of tests defined and checked if the system was fully compliant with what was specified within the activity. 4.3 Integration Problems System Complexity One of the main problems with terminal mobility software integration was that it involved software from a large number of different partners with different knowledge, education, code style. This makes it very hard for the integration task force because it as to handle with a enormous software heterogenousity. In an integration process that involves such a large amount of software modules, it is sometimes difficult to identify the cause of a malfunction. To identify the cause of the problems, the use of dummy software provided the means to be able to control the inputs/outputs to the system and understand the problem. To ease the bootstrapping of all the modules to address the tests, several startup scripts were developed in order to simplify the procedure of starting, stopping and logging all the software modules. System Reliability Other main difficulty encountered during the integration effort was also understanding how robust was the modules’ software. If the software modules were not working in a compliant way in some specific cases, we needed to replicate the environment variables that trigger this specific situation, gather logs from all the software modules and report to the software developers to correct the code. This procedure is not easy and is time consuming, since the response time to correct these situations is large. Also replicating errors and gathering logs can also be a very time consuming task. Dependences on external software The IST Daidalos project has also several dependencies on external software. For instance, Mobile IP for Linux (MIPL) [8] implementation is used in Daidalos with some modifications to support QoS and enhanced multi-homing. During the integration, we ran into some critical problems regarding Moblie IP behavior such as instability, problems with route optimization and tunnel deletion. Several approaches were tried to figure out the reason for this odd behavior, such as changing MIPL versions and changing Linux kernel version. We also tried different combinations of Daidalos software that could be influencing this malfunctioning of MIPL. In the end, we figure out that the problem was related to the Linux distribution the testbed computers were running at the time being. This distribution was Mandrake 10.0 Linux, which used an old glibc package with buggy threads implementation. The upgrade of this package was only possible migrating the whole testbed to Ubuntu Linux distribution, which had an adequate glibc package. This task turned out to be very complicated and time consuming to ensure compatibility with all Mobility in Heterogeneous networks: Integration Process 59 the mobility software, and to re-initialize all the integration process. After this migration, the main problems had been solved. As can be observed from this process, the cause of the problems is not always trivial to find; therefore, the integration team must be ready to identify, isolate and eliminate the problems. Recommendations for a large network Integration The developed terminal mobility sub-system is not simple mainly due to its heterogeneous nature and software. In such a large integration effort, the development of efficient and simpler bootstrapping mechanisms is of large importance. Also, in real deployment, the developers need to have a very proactive role, all being part of the integration team. 4.4 Integration Results During the integration process we managed to retreive some results regarding the performance of the integrated architecture. The following results were taken using the following scenario: two MTs located in two different access networks communicating with each other while one of the MT performed handovers to a third access network. Traffic between the two MT was generated between the nodes using a simple tools like ping with a rate of 3.3(3) packets per second. The test was performed 10 times. In the end we obtained the results in Table 1. Mean FHO signalling (ms) L2 handover (ms) Efective FHO signalling time (ms) 171.2 77.8 93.2 Table 1. Mobility results with the proposed architecture The FHO signalling takes 171.0 ms, from which 77.8 ms are used to perform the L2 handover. This means that actually the FHO singalling takes 93.2 ms. This FHO Signaling time measured consists on the Mobile Terminal requesting an handover, which has to be analyzed and approved by the QoS Broker, getting the decision, informing the network that it is going to move, handover at Layer 2 and inform the new network about his presence there. All the signaling between Access Routers goes through the QoS Broker and is translated between COPS and FHO Protocol at each Access Router. 5 Conclusions In this paper we presented the integration process addressed to build a real demonstrator of heterogeneous and fast mobility, developed in the framework of the IST project Daidalos. The integration effort carried out to put together all 60 J. Santos, N. Sénica, S. Sargento, and R. Aguiar the mobility related modules was significant, and several issues appeared during this process, such as Mobile IPv6 instability and different programming styles. The demonstrator is currently working properly, with both mobile and network initiated handovers in place. Presently we are enhancing its functionalities to improve handover latency and minimize packet disruption. Future plans include the complete and integrated support of multi-homing and location privacy issues. References 1. D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6 In IETF Internet RFC 3775, June 2004. 2. M. Liesch, A. Singh, A. Caskar, D. Funato and E. Shim. Candidate Access Router Discovery In IETF Internet RFC 4066, July 2005. 3. R. Koodli. Fast Handovers for mobile IPv6 In IETF Internet RFC 4068, July 2005. 4. D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig and A. Yegin Protocol for Carrying Authentication for Network Access (PANA) In IETF Internet Draft, July 2005 (Work in Progress) 5. J. Arkko, J. Kempf, B. Sommerfeld, B. Zill and P. Nikander SEcure Neighbor Discovery SEND In IETF Internet Draft, July 2004 (Work in Progress) 6. N. S´enica, R. Aguiar and S. Sargento. QoS-Aware Fast Handover Optimization Supported by Multicast Networks In Rev. do Dep. de Electr´ onica e Telecomunica¸c˜ oes da Univ. Aveiro, Vol. 4 , No. 3, March 2005. 7. Internal Document from IST-Daidalos Consortium. Deliverable 221 In http://www.ist-daidalos.org/. 8. V. Nuorvala, A. Tuominen. Mobile IPv6 for Linux In http://www.mobile-ipv6.org/, March 2006.