Aviation industry is at the beginning of a modernization phase regarding its communication systems. Support for mobility between different access technologies and access networks becomes necessary. A working group at the ICAO recently defined a standard specifying the future IP-based aeronautical telecommunications network (ATN / IP)
Aviation industry is at the beginning of a modernization phase regarding its communication systems. Support for mobility between different access technologies and access networks becomes necessary. A working group at the ICAO recently defined a standard specifying the future IP-based aeronautical telecommunications network (ATN / IP)
Direitos autorais:
Attribution Non-Commercial (BY-NC)
Formatos disponíveis
Baixe no formato PDF, TXT ou leia online no Scribd
Aviation industry is at the beginning of a modernization phase regarding its communication systems. Support for mobility between different access technologies and access networks becomes necessary. A working group at the ICAO recently defined a standard specifying the future IP-based aeronautical telecommunications network (ATN / IP)
Direitos autorais:
Attribution Non-Commercial (BY-NC)
Formatos disponíveis
Baixe no formato PDF, TXT ou leia online no Scribd
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION 1
A Survey of Protocols to Support IP Mobility in
Aeronautical Communications Christian Bauer and Martina Zitterbart AbstractThe aviation industry is currently at the beginning of a modernization phase regarding its communication systems. This involves a transition to IP-based networks for Air Traf- c Control and Airline Operational Communications. Due to the heterogeneous nature of the communication environment, support for mobility between different access technologies and access networks becomes necessary. We rst introduce the aeronautical communications environment and present domain specic requirements. The main part of this article is a survey of different protocols that can be used to solve the IP mobility problem within the aeronautical environment. These protocols are assessed with regard to the introduced requirements. We conclude with the identication of a particular protocol as the most suited solution and also identify areas for further work. Index TermsAircraft, Mobility, IPv6, Mobile IP, NEMO I. INTRODUCTION T HE COMMUNICATION infrastructure currently used for civil aeronautical communications is based on an analogue voice system that can neither cope with the expected increase in air trafc nor support the envisaged paradigm shift towards data or packet oriented communications. The digital- ization effort is supposed to free-up the currently congested analogue voice based system and to increase operational efciency. For these reasons, a working group at the International Civil Aviation Organization (ICAO) recently dened a standard [1] specifying the future IP-based Aeronautical Telecommuni- cations Network (ATN/IP). This global inter-network will be based on IPv6 and will be deployed for ground-ground networks, air-ground access networks and on the airborne (on-board) network itself. The Internet Protocol IPv6 has been chosen as the basis for the ATN as it (a) is a widely used industry standard in telecommunications, (b) is actively maintained and extended by the responsible standardization organization, the Internet Engineering Task Force (IETF), and (c) provides sufcient address space for a world-wide deployment in every national state and aircraft. In addition, it is also expected that IP provides a more cost-effective solution compared to proprietary protocol solutions. A typical ATN scenario, is an inter-continental ight from Europe to Northern America. Throughout the complete ight duration from departure to destination airport, the aircraft has to perform handovers among different access networks: Manuscript received 25 May 2010. C. Bauer is with the Institute of Communications and Navigation, German Aerospace Center (DLR) (e-mail: christian.bauer@dlr.de). M. Zitterbart is with the Institute of Telematics, Karlsruhe Institute of Technology (KIT) (e-mail: martina.zitterbart@kit.edu). Digital Object Identier 10.1109/SURV.2011.111510.00016 Communication Peer Communication Path Short-range tech. Long-range tech. Satellite tech. Fig. 1. Scenario of aeronautical communications over different access technologies and networks. short-range terrestrial technologies at the airport, long-range terrestrial technologies while at cruise altitude and satellite technologies when over the Atlantic. A general picture of this situation is shown in Fig. 1. In addition, the velocity of an aircraft is larger than that of any other vehicle, with the consequence, that complete continents and different access networks can be passed in a matter of hours. Also, the com- munication peers are distributed among large geographical and topological areas, starting in Europe and ending in Northern America. Despite these conditions, the routing path between the aircraft and its ground-based communication peers should remain optimal, avoiding forwarding between different con- tinents in order to keep the end-to-end delay as short as possible. Also, an aircraft is not only a single mobile host, but includes one or several on-board networks with numerous end-systems, establishing a need for the mobility of a complete network. The global system has to simultaneously support at least hundred thousand of these mobile networks. Finally, the messages exchanged between the aircraft and its ground peers include air trafc control information. Availability and security of these data ows are highly critical. At the same time, aircraft will not only be a part of the ATN but also of the public Internet, e.g. to provide passengers with Internet access. The remainder of this paper surveys the different solution options on how to provide IP mobility within the aeronautical environment. 1553-877X/10/$25.00 c 2010 IEEE This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. 2 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION Section II provides an overview of the aeronautical en- vironment, explains why mobility is actually needed and species the mobility requirements that have to be satised by a candidate mobility protocol. In Section III we investigate various protocols that can be used provide mobility and identify their individual strengths and weaknesses. It becomes apparent that no solution can fulll all requirements though. We identify a single mobility protocol family as the most suited one but realize that still one problem remains to be solved. In Section IV we therefore survey proposals that address the remaining problem of optimizing the overall end- to-end latency for that particular protocol family. We nally conclude with identifying the set of protocols that can sufciently fulll all the requirements of the aeronautical environment. Additionally, we identify areas for further work that can help improve certain weaknesses and resolve open questions. According to the aeronautical community [2], the future (IP-based) ATN should be introduced by the year 2020. II. THE AERONAUTICAL ENVIRONMENT We describe the aeronautical communications environment, the involved stakeholders and the access technologies used, or foreseen to be used, within the community. In general, we regard an aircraft as a mobile network consisting of the airborne router and several end-systems (Mobile Network Nodes MNNs) that are communicating with peers on the ground (Correspondent Nodes CNs). A. Difference To Other Communication Areas Support for mobility of devices or networks is also required within other areas. In the following we will explain how the aeronautical environment differs from those other areas. Wireless personal communications based on mobile phones, as dened by the 3rd Generation Partnership Project (3GPP), make use of IP mobility management as well [3]. The major differences are that mobile phones are only mobile hosts and not mobile networks like an aircraft. Mobile phones also have a lower degree of mobility and a reduced level of security and availability requirements. The Car2Car communications environment has to support several end-systems within a car and thus acts as mobile network. A major difference of the Car2Car protocol stack, es- pecially for car-safety applications, is the dual-stack approach that not only consists of IP but also of dedicated Car2Car protocols [4]. In addition, the degree of mobility and covered distance is smaller than that of an aircraft - the inicted delay is not as high as mobility is usually constrained to a single continent. Summarized, the critical aspects within aeronautical com- munications, in contrast to more conventional areas, are: a high degree of mobility that could cause delay problems due to routing over large geographical distances, a need for high availability and strong security. B. Service Classes And Applications There are four different service classes in the aeronautical environment, each class covering different applications. Air Trafc Services (ATS) covers all communication be- tween the cockpit (the mobile node) and the controller on the ground (xed node) for providing navigational support and air trafc control communications. The applications within this service class are critical to the safety of the ight. The xed ATS communication peer on the ground is called ATS Correspondent Node (CN). The CN, the aircraft is currently communicating with, changes over time depending on the ge- ographical position of the aircraft and the associated national airspace. Several CNs exist within each countries national borders, with responsibility dedicated either to airspace in and around airports or for airspace at cruise altitude. Airline information systems include communication be- tween an aircraft and the airlines headquarter or operations center. This service class is separated into two classes: Airline Operational Communications (AOC) and Airline Administra- tive Communications (AAC). AOC consists of services that are regarded as safety-related, e.g. ight status information (mal- function reports) or fuel reports. The non-safety related AAC services include messaging in respect to catering, baggage handling or duty free sales. An AOC/AAC communication peer on the ground is called AOC/AAC CN. Usually up to three such CNs occur during a ight: source and destination airport as well as the airline operations center. Finally, Aeronautical Passenger Communications (APC) is dedicated to passenger communications and entertainment. The devices within this domain can be administratively con- trolled by the airline itself (e.g. devices mounted within seats) or, alternatively, can also be passenger-owned devices. The correspondent nodes are usually located in the public Internet and also include corporate Virtual Private Network (VPN) gateways. Providing a reasonable end-to-end delay to these nodes is also highly desirable. At least for ATS and AOC, application requirements are available. One document [5] provides numbers for bandwidth consumption and latency requirements for these applications. Those are quite relaxed though, with the most stringent re- quirement for routing in the ground network being roughly 340 ms on average (one-way delay for a single application layer message). The same document also mentions voice latency requirements that are usually 130 ms for ATS. At the time of writing it was not yet clear whether Voice Over IP will be used in the future IP-based ATN for mobile communication. In case yes, then this stringent requirement will have to be met. Collecting and routing on-board sensor data to ground- based processing systems will also become increasingly im- portant in the future. Related requirements listed in [6] include sensors whose data should be transmitted in real-time. No specic numbers are provided though. Apart from delay, another important aspect is availabil- ity [5]: most ATS applications require 99.9%, while for some it is even 99.99%. This will also have to be supported by the underlying network infrastructure and associated protocols. C. Aeronautical Access Technologies The future ATN will employ different access technologies (comprising the physical and link layer of the OSI stack) for This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 3 carrying IP-based trafc that makes this network heavily heterogenous. At airports standard IEEE 802.11 [7] (Wi) equipment is already in use for providing wireless connectivity for AAC communications when the aircraft is standing at the gate. Also for communications in the airport area an adapted version of the well known IEEE 802.16e [8] (Mobile WiMAX) standard will be used. This technology will provide several Mbit/sec per radio cell for ATS and AOC trafc. Standard WiMAX can be used to provide connectivity for AAC and APC. Most of the ATS trafc over continental areas, as well as AOC trafc, will be carried by the L-Band Digital Aero- nautical Communications System L-DACS, a technology that is currently in development. L-DACS will provide typical throughput values up to 1.5 Mbit/sec per radio cell with delay values of 100 ms on the FL 1 and 200 ms on the RL 2 . In situations with medium congestion 300 ms on the FL and 600 ms on the RL during high congestion phases [9] have to be expected. Especially for oceanic, remote and polar regions low earth orbit (LEO) and geostationary orbit (GEO) satellite systems will complement the terrestrial technologies. GEO satellites are known for one-way delay values of 250-300 ms. The main reason why the provided bandwidth (in terms of bits/sec) is small compared to personal mobile commu- nications systems is that only a relatively small amount of dedicated frequencies can be used for technologies carrying safety-related data (ATS+AOC). D. Network Model The IPv6 based ATN will carry ATS and AOC data and will be a closed network, not reachable from the public Internet. The non-safety related AAC and APC trafc is not supposed to be routed over the ATN these service classes will instead use the public Internet. The networks and nodes within the ATN are operated by three different interest groups that we will introduce in the following. Routing between the different networks is based on the Border Gateway Protocol (BGP), the Exterior Gateway Protocol (EGP) also used in the public Internet. An exemplary gure illustrating the networks and inter-connections of the different stakeholders is shown in Fig. 2. The rst group are the Air Navigation Service Providers (ANSPs), state owned authorities that are directly responsible for providing ATS within their national airspace. ANSPs are operating both networks and end-systems in the ATN. Those end-systems are the ATS CNs on the ground that aircraft are exchanging air trafc control instructions with. ANSPs have the obligation to provide ATS communication infrastructure within their country, meaning that in the future they have to provide IPv6 based access networks 3 that aircraft can attach to within the ANSPs national (airspace) boundaries. 1 Forward Link: Base Station to Mobile Node. 2 Return Link: Mobile Node to Base Station. 3 An access network is an IP network which includes one or more Access Network Routers that are connected to one or more base sta- tions/gateways/access points. There are two possibilities how these access networks can be established: The ANSP owns and operates its own access network that topologically becomes a sub-network of the overall ANSP network (e.g. ANSP #1 in Fig. 2). The ANSP can outsource the operation of the access network to a service provider. The access network is then topologically a part of the service provider network. Trafc between this access network and the ANSP is routed with help of an EGP (e.g. ANSP #2 in Fig. 2). Aeronautical Communications Service Providers (ACSPs) are network operators that offer communication services to air- lines and ANSPs. These service providers can operate the ac- cess networks for the national ANSPs (e.g, ACSP #1 in Fig. 2). In addition, they also deploy access networks independently from ATS dedicated networks for the purpose of providing transit services for AOC data (e.g. ACSP #2 in Fig. 2). The third stakeholder are airlines. They are operating aircraft and AOC/AAC CNs (e.g. AOC CN in the airline operations network in Fig. 2). Airlines usually have a business contract with a communication service provider so that their aircraft can attach to and send AOC trafc over the service providers access network. The network and user/operator model explained above refers to the ATN that only carries safety-related services (ATS, AOC). The model for non-safety related services, es- pecially for APC, is different as it is not based on the ATN these access networks are not provided by the national air trafc operators nor by the aforementioned ACSPs. Instead, this is similar to consumer communications where Internet Service Providers offer connectivity to the public Internet. E. The Need For Mobility Support A typical example for ATS communications is an aircraft communicating with the ATS CN at the airport tower before, during and after takeoff. The communication session is estab- lished while connected to the WiMAX-based access network. While this session remains active between the on-board end- system and the CN, the aircraft performs a handover to the L-DACS access network. Due to moving to a different IP subnetwork, the IP address of the aircraft changes. In order to preserve the established session in the presence of handovers, a mobility protocol is necessary. That provides a xed, static IP address to the higher layers. This property is called session- continuity. Another example for the usefulness of session continuity are low air trafc situations during nights in the future European airspace, where all ights above France and Germany could be controlled by only a few controllers of either Germany or France. This implies that, while performing handovers between the different access networks in Germany and France, aircraft always communicate with the same CN. This can also be the case in the future if a personal controller is assigned to an aircraft who is responsible for the large durations of a ight [10]. Another issue is the availability of public IP address space on the aircraft: on-board end-systems (MNNs) should be capable of obtaining a public IP address for allowing global This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. 4 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION ANSP #2 w/o access network ATS CN ACSP #1 network ANSP #1 w/ access network ATS CN Airline Operations AOC CN AOC Communications ATS Communications ACSP #2 network Fig. 2. Topology of the ATN. Correspondent Nodes (CNs) are the communication peers of the aircraft. Air Trafc Services (ATS) CNs are controlled by the Air Navigation Service Providers (ANSPs). The Air Communication Service Provider (ACSP) operates access networks. The Airline Operational Communication (AOC) CN is the communication end-point for airline related information exchanges. end-to-end communication. A Network Address Translator (NAT) would allow sharing the access network addresses available at the airborne router among all end-systems, but causes problems as discussed in [11], e.g. with end-to-end security protocols. Apart from that, session continuity could not be provided anymore. The future aeronautical mobility protocol should therefore also provide public IP addresses to all on-board end-systems. In normal operations, ATS communication is always aircraft-initiated. In the future it might become interesting to provide a controller with the means to contact an aircraft that has entered controlled airspace but not yet established a communication session. A xed static IP address space for the aircraft, independent of the current topological location, would allow for ground-initiated communications. Summarized, due to the heterogenous access technology environment and the different administrative domains (ANSPs and ACSPs), handovers between different networks will occur. This implies the need for providing an IP mobility protocol that permits session continuity, provides public on-board IP address space and offers the possibility to allow for ground- initiated communications. F. Mobility Requirements In the following we specify inherent, primary and secondary requirements that have to be fullled by a mobility protocol used in the aeronautical environment. In the following, the word aircraft refers to a complete mobile network, consist- ing of an airborne router and at least one network prex. Several end-system (MNNs) are attached to this airborne router. The inherent requirements that must be completely fullled by all candidates are as follows: 1) Session continuity: this property provides a constant IP address for use to higher layer protocols, even in case of handovers. 2) Mobile Network support: mobility should not only be provided for a single mobile host, but for a complete on- board network. More specically, instead of providing a constant IP address (as the case for the previous requirement) one or several constant network prexes should be provided. Session continuity is automatically fullled by all mobility protocols investigated later. It is therefore not mentioned anymore in the nal comparison. The primary requirements that should all be fullled by the candidate protocols are as follows: 1) (Mobile) Multihoming: the aircraft should be capa- ble of routing data simultaneously over different in- terfaces/paths from the aircraft to the ground (e.g. stream X via a satellite and stream Y via a terrestrial network). This requirement covers both load-balancing and fault-tolerance. The latter addresses the important issue of reliability/availability: in case of failure of one interface/path, packets can be routed over another interface/path. 2) Security 1 (masquerading): an attacker must not be able to claim the constant addresses/prexes of an aircraft, e.g. by means of man-in-the-middle attacks. 3) Security 2 (DoS): the mobility protocol itself should not introduce any new denial of service vulnerabilities. 4) End-to-end delay: the delay between the communication peers (end systems on the aircraft and the ground) should be kept minimal. Application specic delay re- quirements have been introduced in Section II-B. 5) (Routing) Scalability: the impact of the mobility proto- This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 5 col on the global routing infrastructure should be kept to a minimum, meaning that frequent route announce- ments/withdrawals for every individual aircraft should be avoided. 6) Applicability to AAC/APC: species whether the so- lution is also applicable to non-safety related services. This indicates whether the protocol stack on the end- systems has to be modied in order to support mobil- ity. Especially for the APC domain it is unlikely that popular, frequently visited web servers in the public Internet will upgrade their protocol stacks with mobility extensions. Secondary requirements are desirable and their fulllment is a bonus: 1) Efciency 1: the overhead incurred by the mobility protocol itself should be limited. The number of round- trip times (RTTs) needed for mobility-related signaling should therefore be kept minimal. 2) Efciency 2: the overhead imposed upon every individ- ual packet with payload from the MNNs or CNs should be limited. The number of additional protocol headers, needed to support mobility, should therefore be kept minimal. 3) Convergence time: a new routing path to and from the mobile network (e.g. because a new interface has been activated) should become usable for packet forwarding within the shortest possible amount of time. While convergence time is also inuenced by the number of exchanged signaling messages as described by Efciency 1, this requirement is restricted to the time it takes to propagate the new mobility state throughout the (routing) system. 4) Support for ground-initiated communications: end- systems on the ground should be capable of sending packets to an aircraft they have not yet communicated with. This means that a routing path to the current location of an aircraft has to be available for these nodes. It is preferable to have a single protocol (family) as a solution for all domains, ATS/AOC/AAC/APC. This is taken into account by the primary requirement Applicability to AAC/APC. The reason for this requirement is that, apart from cost reasons, in the long term, the safety and non-safety related domains might be handled by a single airborne router. III. MOBILITY OPTIONS Protocols for providing IP mobility are also discussed in [12], [13], with a focus on the aeronautical environment in [14]. Our investigation is different from the previous ones by (a) having introduced numerous requirements and (b) by assessing the protocols based on those requirements. While the work performed in [14] also species certain requirements, many of them are high level. In general, we investigate the protocols and perform our analysis with a higher degree of detail. Also, the second part of our survey, starting in Section IV, addresses an important optimization problem that is not covered at all by [14]. From a general perspective, the mobility problem can be solved by a solution that is located on the link, network, transport or application layer. A solution on the link layer is access technology specic. As explained in Section II-C, the ATN is a heterogenous envi- ronment with different technologies. This requires providing mobility among different technologies, therefore ruling out the link layer approach and raising the need for a solution located at least on the network layer. Application layer solutions require that applications are made mobility-aware. Apart from the burden imposed on application developers, another serious problem is with non- safety related services. All existing airline information systems would have to be updated. Also, applications on passenger- owned devices as well as in the public Internet would have to be modied as well. This rules out the application layer approach for very practical reasons. We therefore focussed on protocols between the network and transport layer for our investigation. We identied ve different protocols that can be categorized as follows: Routing protocol based approach (network layer), with the example of the Border Gateway Protocol. Tunneling based approaches (network layer), with the examples of the IPsec and Mobile IP protocol families. A transport protocol approach, with the example of the Stream Control Transmission Protocol. Locater-identier split (between network and transport layer), with the example of the Host Identity Protocol. These protocols are investigated in the following. Their suit- ability to provide routing in the mobile ATN is assessed with regard to the previously specied requirements. A. Border Gateway Protocol While routing protocols are not classical IP mobility proto- cols, they can nevertheless solve the problem of routing in a mobile environment. The Border Gateway Protocol Version 4 (BGPv4) [15] is the inter-domain routing protocol mainly used in the Internet. BGP is used between autonomous systems for exchanging information on routing paths to specic destination prexes. Routing information is distributed to neighboring routers that update their routing tables and forward the routing information to other selected routers. BGP has already been used in the past for providing (IPv4) Internet Connectivity to the APC domain via GEO satellites. This solution approach is presented in [16] and is based on dynamic homing, in opposite to the more common static homing used in the Internet. The operation of this solution is shown in Fig. 3. Each aircraft receives a /24 prex that is announced via BGP by the ground station the aircraft is currently attached to. Each ground station is an autonomous system (AS) with its own AS number and its own BGP router/speaker. When the aircraft moves and performs a handover to a different ground station, the old ground station withdraws the /24 prex of that aircraft while the new ground station will start announcing the aircraft prex from its own AS. Packets destined to the aircraft are then routed to the new AS/ground station. This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. 6 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION BGP Update X.Y.Z/24 Autonomous System B Internet Autonomous System A Handover 1 BGP Withdraw X.Y.Z/24 2 3 Fig. 3. BGP route announcements by ground stations. Frequent route announcements and withdrawals lead to route dampening, causing the route in question to not be accepted anymore nor advertised to neighbors by other BGP routers. With a handover occurring only once every 4-8 hours for an aircraft, dampening did not become a problem according to [16]. However, tests showed that with shorter time intervals dampening does occur. As handovers between terrestrial technologies of the ATN are supposed to occur more frequently then with satellites, this might become a problem. Another critical aspect of BGP is convergence time. As mentioned in [16], it took about one minute for the major backbone networks in the Internet to update their routing tables according to the new route. The duration for smaller outlying networks to converge was 30-60 minutes. Analysis: Session continuity (inherent): the aircraft re- ceives a constant prex (for example an IPv4-based /24 as in [16]) that is always announced by the current base station of the aircraft. This requirement is therefore fullled, as end- systems receive their addresses from this stable prex. Mobile Network support (inherent): fullled since the aircraft receives a complete mobile network prex instead of a single IP address. Multihoming (primary): BGP multihoming is an estab- lished technique in the xed Internet. However, this form of multihoming is usually restricted to either simple load- balancing or to destination-based routing decisions. While there are possibilities to include at least the source address of packets into the routing decision [17], the problem of routing specic trafc ows (e.g. based on the used transport protocol and port numbers) still remains unsolved. Security 1 (primary): the problems of BGP with respect to security have been thoroughly investigated [18]. One of the key problems is that BGP routers can advertise prexes that do not even belong to them an attacker can advertise a prex owned by someone else and therefore attract the trafc belonging to the other entity. Secure BGP (S-BGP) [19] is one proposal that provides a solution to this problem, although at the expense of an increase in convergence time [18]. S-BGP relies on a Public Key Infrastructure (PKI) and certicates that authorize the owner to manage a certain IP address space. An- nounced BGP information is then signed by a private key that can be veried by the recipient based on the public key in the certicate, therefore ensuring the authenticity of announced routes. To secure the full routing system, all BGP speakers have to implement S-BGP. Also, further investigations are needed to identify whether S-BGP has to be adapted to work with dynamic homing. Security 2 (primary): The only aspect of S-BGP that might be regarded as problematic is the increase in CPU and memory consumption. There is not enough experience with S-BGP available to properly assess this aspect though. End-to-end delay (primary): BGP always provides a shortest-path route from the end-systems on the ground to the aircraft as routes are calculated via the current base station, which currently advertises the aircraft prexes. The exact meaning of shortest-path is dened by the metric of the routing protocol. Scalability (primary): an inherent property of BGP are frequent route announcements and withdrawals from the new and old points of attachment of an aircraft. As the ATN will be separated from the public Internet and has its own BGP routing core, scalability might not become a problem within this environment. However, the AAC/APC domains are routed over the public Internet and the use of BGP would therefore cause negative impacts upon the routing tables. Scalability is linear with the number of mobile nodes, with regard to the number of route announcements and withdrawals. Applicability to AAC/APC (primary): the protocol stack on end-systems remains unaffected as BGP exchanges are performed by either the airborne router or the ground station. Convergence time (secondary) within the ATN is not as much an issue as it is for the AAC/APC domains, due to the smaller number of autonomous systems and routes compared to the public Internet. Efciency 1 (secondary): in [16] BGP route updates were announced by the ground stations. In this case, the aircraft only has to provide its identity and its prex to the ground station, which then performs BGP announcements on behalf of the aircraft. Another option, different from [16], would be to put the BGP speaker on-board the aircraft. The signaling, that is based on TCP, then has to be performed over the wireless link. This implies 1.5 RTTs for establishing the TCP connection and at least additional 1.5 RTTs for the BGP signaling. Efciency 2 (secondary): the size of payload packets remains unchanged. Support for ground-initiated communications (sec- ondary): as soon as a base station starts advertising the aircraft prex, a route to the aircraft becomes available and trafc would be properly routed to the aircraft. B. IPsec IPsec [20] is a well known protocol providing conden- tiality, data integrity and data source authentication. These services are provided by maintaining a shared state between the two communication peers, also called Security Association (SA). The SA consists of information related to IP address of the two communication peers, cryptographic algorithm iden- tiers and keys, etc. Establishing such a SA manually would not be scalable, hence the Internet Key Exchange (IKEv2) protocol [21] provides the means to create and manage them dynamically. IKE mutually authenticates the two peers, based This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 7 Home Network Access Network B Access Network A Handover Security Gateway (MOB)IKE Signalling (MOB)IKE Signalling new IPsec tunneI oId IPsec tunneI 1 2 3 CN New Path for Payload Traffic Airborne Router 4 Fig. 4. Signaling between airborne router and IPsec security gateway. on either pre-shared secrets, certicates or the Extensible Authentication Protocol (EAP) [22]. In case of a VPN-like approach where an IP-in-IP tunnel is established, if one of the two IPsec peers moves to a different network and congures a new IP address, the established SAs would not be usable anymore. For this reason, the IKEv2 Mobility and Multihoming protocol (MOBIKE) [23] extends IKEv2, allowing one peer (the mobile node) to change the IP address of a SA and to signal this change to the security gateway. In addition, the peer can also transparently move all trafc ows from one interface/IP address to another one. MOBIKE is usually used between a mobile node and its (xed) security gateway that assigns a constant IP address to the mobile node from its own address pool, as shown in Fig. 4. Analysis: Session continuity: in the process of setting up the initial SA via IKE, the airborne router can request the assignment of a static, xed IP address from the gateway. Trafc destined to or originating from the mobile network will therefore always be routed via this gateway, with whom the mobile node establishes an IPsec tunnel. In case the mobile node moves to a different access network, a MOBIKE message exchange updates the SA(s) and ensures that the gateway forwards trafc via the IPsec tunnel to the mobile nodes new location, the care-of address (CoA). The CoA is the IP address that the airborne router congures in the new access network (in Fig. 4 the CoA is rst from Access Network A and after the handover from Access Network B). Mobile Network support: instead of acquiring a single address during the initial SA establishment with IKE, the airborne router could request a network prex from the gateway (e.g. a /24 as it was the case for BGP). This way, the mobility of a complete mobile network could be supported. Multihoming: while MOBIKE provides the means to use different network interfaces, it is limited to using them in a sequential way. Using several interfaces simultaneously to route different data ows over different interfaces is not supported. Security 1: a mutual authentication within IKE is per- formed between the gateway and the airborne router, based on pre-shared secrets, certicates or EAP. This ensures that the gateway forwards trafc to the correct airborne router. Security 2: a vulnerability of IKE are CPU-exhaustion attacks. The protocol denes a cookie-based mechanism that can be activated if necessary and reduces the threat to an acceptable level. End-to-end delay: the security gateway is a pivotal node that is always traversed by packets exchanged between the mobile network and its communication peers on the ground. If the distance between airborne router and gateway increases, the overall end-to-end latency will also increase. Scalability: mobility events are only signalled to the Se- curity Gateway; the routing tables in the core infrastructure therefore remain unchanged. The gateway or another BGP speaker in the gateway network only has to advertise a single aggregated prex via BGP that includes the addresses of all its registered airborne routers (this is called an aggregate). Scalability is therefore linear with the number of aggregates, with regard to the entries in the routing tables. Applicability to AAC/APC: the protocol stack on end- systems remains unaffected as the airborne router transparently tunnels all trafc to the security gateway. Convergence time: when the airborne router moves to a different network, it noties the gateway of its new address. As data is always routed via the security gateway, the successful completion of this notication ensures that data is immediately routed to the new location. This is achieved with help of the static, xed IP address or prex. Efciency 1: when moving to a different network, the airborne router needs 1 RTT of signaling with MOBIKE to inform the gateway of its new location. Efciency 2: the use of IPsec usually implies integrity protection and allows for additional encryption. Even if no cryptographic algorithms are specied, the additional headers increase the overhead for every payload packet. In addition to that, the overhead of a complete IP header is added to every payload packet as an IPsec tunnel is used. The IPsec transport mode, while eliminating the additional header, would not be able to provide mobility. Support for ground-initiated communications: as data is always routed via the security gateway that is always notied by the airborne router of its current location, trafc can be immediately forwarded to the mobile node. C. NEMO The Network Mobility (NEMO) protocol [24] is an exten- sion to Mobile IPv6 (MIPv6) [25]. NEMO extends the concept of a mobile node to that of a Mobile Router (MR) with one or several mobile network prexes. As soon as the MR attaches to a foreign network it registers the new CoA with its Home Agent (HA) in the home network and creates a bi-directional tunnel for forwarding trafc between the nodes of the mobile network and the communication peers on the ground via the HA. Analysis: Session continuity: similar to the IPsec solution (cf. Section III-B), the home agent provides the airborne router with a constant IP address called the Home Address (HoA) from its own network. Trafc is therefore always routed via the HA that forwards it to the current location of the MN. Mobile Network support: NEMO extends MIPv6 by intro- ducing a mobile router that has one or several Mobile Network This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. 8 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION Home Network Access Network B Access Network A Handover Home Agent NEMO Signalling NEMO Signalling new NEMO tunneI oId NEMO tunneI 1 2 3 CN New Path for Payload Traffic 4 Fig. 5. Signaling between mobile router and home agent. Prexes (MNPs). These prexes belong topologically to the home network. End-systems that attach to the MR congure their addresses based on the MNP advertised by the MR and can therefore remain mobility agnostic. Multihoming: the possibility to register several care-of addresses with the home agent is specied in [26]. In ad- dition, [27] species a policy exchange protocol that can be used to setup forwarding rules for certain trafc ows, taking into account the additional care-of addresses. Detailed trafc selectors can be used to identify a ow, based on IP or higher layer protocol elds such as source/destination address, port numbers, etc. The MR sends its current policy to the HA which sets up forwarding to the MR accordingly. This allows for simultaneously routing trafc ows over different interface, on the routing path from the MR to the HA as well as on the path from the HA to the MR. Security 1: MR and HA perform a mutual authentication between each other based on IKEv2 [28]. This ensures that the HA forwards packets only to the valid MR. Security 2: with the authentication between MR and HA being based on IKEv2, the problem of CPU-exhaustion attacks as already discussed for IKE in Section III-B applies here as well. End-to-end delay: NEMO causes sub-optimal routing where trafc always traverses the HA. If the distance between MR and HA increases, the overall end-to-end latency also increases. Scalability: the MR signals its current location to the HA that updates its routing state accordingly. BGP routing tables remain unchanged as the Home Network is always advertising an aggregated prex via BGP that includes all the MNPs. Scalability is therefore linear with the number of aggregates, with regard to the number of announced prexes. Applicability to AAC/APC: the protocol stack on end- systems remains unaffected as trafc is transparently tunneled between MR and HA. Convergence time is equal to the time it takes the MR to signal the new location to the HA, who will then immediately forward trafc to the MNs new CoA. Efciency 1: it takes the MR 1 RTT to signal the new location/care-of address to the HA. Efciency 2: the tunnel between the MR and the HA inicts an overhead of a full IP header upon every payload packet. Support for ground-initiated communications: as it was the case for the IPsec-based approach, payload trafc is always routed via the home agent. As the MR signals its care-of address(es) to the HA, this trafc can be forwarded to the MRs current location. D. SCTP The problem of mobility is directly impacting the transport layer, where active sessions break due to the usage of the IP address as an identier. One might therefore regard the transport layer as a more proper location for a solution to the mobility problem [29]. An approach that is different for the previous ones is solving the problem on the transport layer itself. There are proposals for adding mobility extensions to the appropriate protocols, such as TCP-R [30] or M-UDP [31]. In the following we will take a close look at the Stream Control Transmission Protocol (SCTP) [32]. We chose SCTP over other protocols such as TCP-R or M-UDP, because of the additional features it provides. SCTP is a connection-oriented transport layer protocol comparable to TCP, but with additional features such as mul- tihoming. The original SCTP specication allows specifying several IP addresses during connection setup time only. This limitation has been removed with [33] where newly cong- ured IP addresses can be dynamically added to or deleted from an SCTP association by one of the two communication peers. This is particularly useful for a mobile node where IP addresses appear and disappear due to handovers between different access networks. Analysis: Session continuity: in case the MN moves to a different network where it congures a new IP address, it can dynamically add this new address to the SCTP connection performing a failover. Afterwards, data can be exchanged using the new association. Mobile Network support: SCTP, as a transport layer protocol, is running on the end hosts and as such is not able to support network mobility. Multihoming: while dynamically adding or removing IP addresses can be used for mobility, its original intention was to provide multihoming functionality to SCTP. The SCTP multihoming however supports only redundancy but not load- balancing. While several IP addresses can be associated to a single SCTP association, only one address (the primary address) can be used to transmit packets. Security 1: SCTP is vulnerable with regard to an attacker hijacking an already established association between two communication peers [34]. This enables an attacker to hijack trafc of a mobile node. Security 2: there do exist vulnerabilities within SCTP that can be exploited to send large volumes of unwanted trafc to a victim. E.g., this can be achieved by providing an additional false address to the SCTP association. The attacker can later force the other SCTP peer to use this address and send all trafc to it. These attacks can be either mitigated or the probability to successfully mount an attack at least be This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 9 minimized. This can be achieved by properly implementing SCTP or choosing proper protocol parameters. [34]. End-to-end delay: SCTP associations are bound to the addresses that are locally available on the two communication peers, including the care-of addresses at the mobile node. The end-to-end delay therefore corresponds to the shortest route between the IP addresses of the two peers. Scalability: adding or deleting IP addresses to or from SCTP associations is only signalled between the end systems. There is, therefore, no impact on the routing infrastructure. Applicability to AAC/APC: end-systems have to imple- ment SCTP and applications also have to use this protocol in order to have mobility support. Convergence time is equal to the time the respective SCTP messages need to signal the availability of a new IP address to the communication peer. Efciency 1: signaling consumes 1 RTT to add a new IP address to the SCTP association. Efciency 2: by solving the problem on the transport layer, SCTP does not incur any additional overhead to payload packets. Support for ground-initiated communications: the at- tempt of a communication peer on the ground to establish a SCTP connection to a mobile node will fail due to the unknown current location (care-of address) of the mobile node. E. HIP Another, more radical, approach for supporting mobility is the locator-identier split, where a new shim layer between the network and the transport layer is introduced. This layer also introduces a new namespace on top of the IP address space. The identiers within this namespace are globally unique and associated to a mobile node. Higher layers (e.g. TCP) are not binding anymore to an IP address (the locator), but instead to the new identier. Several different approaches exist based on these identiers, for example LIN6 [35] or the Host Identity Protocol (HIP) [36]. In HIP, Host Identity Tags (HITs - the identiers) are mapped to the available IP addresses (locators) with the help of IPsec. The HITs are generated from the public key and therefore cryptographically bound to it. Only the owner of the corresponding private key can make use of the related HIT in the HIP protocol exchanges. If the HIP-enabled mobile node attempts to communicate with a HIP correspondent node, it initiates a message exchange to establish a common session based on the HITs of the two nodes and the IP addresses they want to use for message exchange. In case one peer moves to a new location, it signals the new IP address to the other peer. The HIP modules on both nodes can then update their state and map the HIT to the new IP address. In case the mobile node is multihomed, the HIT can have a mapping to several IP addresses. HIP also provides Rendezvous Servers (RVS). Mobile nodes register with an arbitrary RVS and then update their entries in the Domain Name System (DNS) to (mn.example.org, IP RVS). A correspondent node attempting to contact the MN performs a DNS lookup and thereby retrieves the address of the RVS. The contact initiation from the correspondent node TCP IPsec ESP HIP IP Mobility & Multihoming (bound to HIT) (HIT_s, HIT_d) SPI (HIT_s, HIT_d, SPI) (IP_s, IP_d, SPI) Fig. 6. Host Identity Protocol with mapping to lower and higher layers at mobile node and correspondent node. A Host Identity Tag (HIT) is present for both source (HIT s) and destination (HIT d). The Security Parameters Index (SPI) uniquely identies an IPsec Encapsulated Security Payload (ESP) security association. IP s and IP d refer to source and destination IP address respectively. to the RVS can then be forwarded by the RVS to the current location of the mobile node. The relationship of HIP to other layers of the protocol stack is shown in Fig. 6. Analysis: Session continuity: As soon as the mobile node moves and congures a new IP address, HIP updates its (HIT, IP address) mappings and signals this change to the corre- spondent node. The upper layers are not negatively affected as they are bound to the HIT, which remains unchanged. Mobile Network support: a solution for network mobility support in HIP is proposed in [37]. There, mobile network nodes are required to have a HIP stack and delegate rights to a HIP-enabled airborne router that performs HIP signaling on behalf of the mobile network nodes. Multihoming: the multihoming support in HIP is focused on providing failover functionality. Simultaneous usage of different interfaces, e.g. for load-balancing, has not been investigated at the time of writing. HIP can therefore not fully meet this requirement. Security 1: HIP relies on authentication and authorization schemes to protect the HIP message exchanges, including sig- natures. If these mechanisms are used, an attacker including man-in-the-middle can not impersonate a node or claim trafc of a node. Security 2: There is a limited vulnerability to memory and computational exhaustion attacks where an attacker oods a HIP-enabled node with a large amount of HIP signaling messages. End-to-end delay: trafc is exchanged directly between communication peers. End-to-end delay therefore corresponds to the shortest route between the two peers. Scalability: HIP does not modify the routing system but instead introduces a new identier space. Scalability issues are therefore not related to the routing infrastructure, but to the rendezvous servers (RVS). Applicability to AAC/APC: end-systems must have HIP implemented in their network stack. In addition they must delegate rights to the airborne router in case of mobile network support. This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. 10 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION TABLE I MOBILITY REQUIREMENTS FULFILLMENT OF ALL CANDIDATE APPROACHES. GRADING CAN BE EITHER COMPLETELY FULFILLED/OPTIMAL (), BASICALLY FULFILLED/FAIR (), WITH LIMITATIONS/AVERAGE () OR UNSUPPORTED/POOR (). Protocol BGP IPsec NEMO SCTP HIP Session Continuity Mobile Network Support Multihoming Security 1 Security 2 / End-to-end delay Scalability (for DNS) Applicability to AAC/APC Convergence time Efciency 1 Efciency 2 Ground-initiated comms. Convergence time is equal to the time it takes the mobile node to perform the HIP signaling exchange that updates the (HIT, IP address) mapping at the correspondent node. The only disadvantage is that the signaling has to be performed every time communication of a new (mobile node, correspondent node) pair is initiated. Efciency 1: establishing a common HIP state between a mobile node and a correspondent node takes 2 RTTs; updating this state after movement of the mobile node consumes 1.5 RTTs. Efciency 2: as HIP uses IPsec to exchange trafc between its two communication peers, overhead is present for every payload packet. However, HIP does not use a VPN-like IP- in-IP tunnel, but instead relies on IPsec transport mode. This only adds a small IPsec related header instead of an additional IP(v6) header. Support for ground-initiated communications: the initial reachability of a mobile node within HIP can only be provided with the help of the rendezvous server. Scalability, with regard to number of DNS entries, is linear with the number of mobile nodes. F. Summary The discussion of all the various protocols shows that there is no optimal solution that is capable of fullling all requirements out of the box. In the following, we provide a summary of how the requirements are graded and discuss how they are fullled by each protocol. In addition Table I shows the comparison of all protocols in a more compact manner. 1) Grading Of Mobility Requirements: The grading of the property Multihoming is either completely fullled (), fullled with limitations (/) or not fullled (). The latter is applied if load-balancing is not supported. Security 1 is either completely fullled () or not fullled (). Security 2 has the additional grading levels (/) and () that indicate that vulnerabilities exist but the probability for an attacker to exploit them is very small, given that certain precautions are taken. The end-to-end delay can be either optimal () or sub- optimal (). The latter being the case if packets are routed via a xed node on the ground, instead of routing on the direct path between the two communication peers. Scalability always refers to the entries in the BGP routing tables, except for HIP that only creates entries in the DNS. () indicates linear scalability with number of mobile nodes and () indicates linear scalability with number of aggregated prexes. Finally, () for HIP is scalability with number of mobile nodes, but graded better because it only impacts the DNS. More precisely, the DNS entry of a mobile node is only stored at a single DNS server. This is in contrast to individual entries for mobile nodes in BGP tables that have to be present in every BGP router in the routing core. Applicability to AAC/APC is either possible () or not possible (). Convergence time is either limited to the time it takes to signal the new location to a single node (), inuenced by DNS lookup and forwarding of the initial packet by a rendez- vous server () or depending on the convergence time of the global routing tables () for an inter-network of limited size, such as the ATN. The gradings of the individual protocols for Efciency 1 and Efciency 2 are relative to each other. Ground-initiated communications is either fully supported (), supported with a dependency on the DNS () or not supported at all (). 2) Conclusion: With respect to the primary requirements, a major issue is the need to implement HIP within the end- system protocol stacks. This causes difculties for already existing AAC systems and makes them infeasible for de- ployment within the APC domain, where public well-known web servers in the Internet would have to be upgraded. Also, the multihoming capability of HIP would have to be further investigated. HIP is therefore unable to fulll one primary requirement. SCTP, while being an interesting approach, does not provide full multihoming support. Another critical aspect though the fact that it is only sufcient for a mobile host and unable to provide mobility support for a complete mobile network. While it might be possible to add mobile network support to this solution approach, the fact that both TCP and UDP without any mobility extensions are the most frequently used protocols in the public Internet makes the transport-layer approach infeasible for the AAC/APC domains. Summarized, SCTP is unable to fulll one inherent, three primary and one secondary requirement. BGP has problems with providing multihoming on a per- ow granularity level. While S-BGP raises security to an acceptable level, there might be reasons for concern with This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 11 the increase in CPU and memory consumption. The major problem of BGP scalability becomes problematic for AAC and APC which are both based on the public Internet. The operation of BGP as a mobility protocol [16] even caused concerns in the Internet Engineering Task Force (IETF). In total, BGP is unable to completely fulll one and only partially fullls another primary requirement. The last two options are IPsec and Mobile IPv6/NEMO that are in fact very similar to each other. A VPN-like approach, as provided by IPsec, suffers from problems with end-to-end latency, overhead inicted on payload trafc as well as the lack of multihoming capabilities with respect to simultaneous usage of several interfaces. An advantage of IPsec would be the implicitly provided security for the higher layers. Unfor- tunately, this feature can not be exploited within a mobile network architecture where the airborne router establishes a VPN with a security gateway: the IPsec security association would not provide end-to-end security. On the other hand, the Mobile IP-based NEMO protocol is a generic mobility protocol providing a multitude of features, but also suffers from problems with payload trafc overhead and end-to-end delay. A one-to-one comparison between IPsec and NEMO shows that the latter has advantages over the former in two properties: multihoming and, albeit only on a minor level, overhead. IPsec and NEMO fail to meet two and one primary requirement respectively. A close look at Table I shows that, taking into account all gradings, Mobile IP/NEMO is the highest rated solution. We therefore argue that it is the most feasible solution for the aeronautical environment. Despite this conclusion, it might nevertheless be possible to extend some of the other solutions to such an extend that they are capable of fullling all requirements. We argue though that it is more meaningful to start with the protocol that already fullls most of the requirements and then address the remaining issues of this protocol. IV. NETWORK MOBILITY ROUTE OPTIMIZATION NEMO fullls most of the requirements, but lacks an acceptable end-to-end latency as of now. In the following we provide a more detailed overview of the NEMO protocol and discuss why a solution to this problem is required. A. Network Mobility (NEMO) The NEMO protocol [24] extends the Mobile IPv6 concept of a mobile host having a static, xed (publicly routable) home address with having a mobile router with mobile network prexes. A mobile network consists of a Mobile Router (MR) with at least one Mobile Network Prex (MNP) and Mobile Network Nodes (MNNs) that are attached to the MR and form their ad- dresses based on the advertised MNP. The mobility signaling that will be explained in the following is also shown in Fig. 7. While the MR is attached to the home network, packets addressed to the mobile network prexes are routed to the MR by means of normal routing. As soon as the MR moves away from the home network and attaches to a foreign network, MNN MR CN BU BA Signalling User Data Tunnel HA Fig. 7. NEMO mobility signaling and forwarding of user trafc over bi- directional tunnel. Binding Update (BU) and Binding Acknowledgement (BA) are exchanged between Mobile Router (MR) and Home Agent (HA). User trafc is exchanged between the Mobile Network Node (MNN) and the Correspondent Node (CN). it becomes addressable via a Care-of Address (CoA) that topologically belongs to the foreign network. The MR sends a Binding Update (BU) to the Home Agent (HA) in the home network. The HA creates an entry in its Binding Cache linking the MNPs and the CoA. The home agent creates a bi-directional tunnel to the MR after having responded with a Binding Acknowledgement (BA). IKE/IPsec is used to authenticate and protect the mobility signaling between mobile router and home agent [28]. Packets of arbitrary Correspondent Nodes (CNs) communi- cating with the MNNs are routed to the home network, where the home agent intercepts these packets and tunnels them to the current CoA of the mobile router, who will decapsulate and forward them to the MNN. Packets from MNNs destined to CNs are rst tunneled by the mobile router to the home agent from where they are routed to the CN. If the distance between mobile router and home agent grows, the delay imposed upon MNN-CN communication will increase due to routing all trafc via the home agent. For this reason Mobile IPv6 provides a Route Optimization (RO) mechanism that allows to route packets on a direct path between mobile node and correspondent node, bypassing the home agent. For the NEMO protocol no RO mechanism is available up to now. B. The Need For Route Optimization (RO) For the aeronautical application of the NEMO protocol, the delay imposed by routing all trafc via the home agent can be signicant. As one of the worst case scenarios, we can assume an aircraft ying above Europe and communicating with a near ATS correspondent node while using a home agent in Asia. This is a typical example for an Asian airline, where a latency of about 300 ms is imposed upon every single packet exchanged between MNN and CN (based on the service- level agreement of a commercial backbone operator [38] guaranteeing a 150 ms one-way delay between Europe and Asia). Apart from delay, the sub-optimal routing of packets over different continents is also inefcient. In addition, the home network in general and the home agent in particular become a single point of failure. In case of problems with one of these, routing between the communication peers becomes impossible. This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. 12 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION Summarized, the benets of Route Optimization (RO) are: Lower end-to-end delay Less susceptibility to problems along the routing path A NEMO RO procedure can extend the basic NEMO protocol and provide these properties. In the following, the second part of this paper, we will perform an analysis of different NEMO RO protocols. For this purpose we introduce specic NEMO RO requirements. Afterwards the different protocols are analyzed with regard to these requirements. First however, we will provide an overview of the Mobile IPv6 Route Optimization procedure that is applicable for mobile hosts only. It will help show the general problems associated with performing route optimization. C. Mobile IPv6 Route Optimization (MIPv6 RO) Mobile IPv6 RO allows routing packets on a direct path between Mobile Node (MN) and correspondent node. The design of this mechanism was driven by security requirements and based on the limitation that it should be applicable to nodes in the public Internet where no pre-existing trust relationships could be assumed. More information on the background of the MIPv6 RO mechanisms is available in [39], [40]. The signaling is explained in the following. The exchanged messages are also shown in Fig. 8. The MN attaches to a foreign network and exchanges a Binding Update (BU) with its home agent to bind its local Care-of Address (CoA) to the Home Address (HoA). The MN receives a Binding Acknowledgement (BA) from the home agent and establishes a bi-directional tunnel with the home agent. Home Registration is now nished and the MN can also initiate RO to the CN(s) now. RO starts with the Return Routability procedure that provides proof that the MN is reachable and therefore the owner of both the CoA and the HoA. The MN sends a Care-of Test Init (CoTI) message directly to the CN. An additional Home Test Init (HoTI) message is sent by the MN via the home agent to the CN. The CN responds with each a Care-of Test (CoT) and Home Test (HoT) message, the latter routed via the home agent. Both responses contain cryptographic keys for the MN. The RR procedure is nished as soon as the MN receives both care-of test and home test message. The keys from the two messages are combined into a single shared secret key. This shared key is then used to generate a hash-based message authentication code (HMAC) that is calculated over and attached to the BU to the CN. The CN, upon reception of the BU, validates the HMAC and responds with a BA. As soon as the MN receives the BA from the CN, the RO procedure is completed and trafc can be directly exchanged between MN and CN, therefore avoiding routing via the HA. The Return Routability procedure does not protect against on- path attackers that reside on the path between the HA and the CN. This attacker must have the capability of eavesdropping BU BA H o m e R e g i s t r a t i o n HoTI HoT[Key_2] C o r r e s p o n d e n t
R e g i s t r a t i o n R e t u r n
R o u t a b i l i t y CoTI CoT[Key_1] MN HA CN BU[HMAC] BA[HMAC] Fig. 8. MIPv6 Home Registration and Route Optimization signaling. on packets exchanged over this path. He can therefore get in possession of the cryptographic key included in the home test message and use it in various attacks [39], [40]. D. Requirements For Aeronautical NEMO RO In the following we are specifying the critical requirements that have to be fullled by a candidate NEMO RO solu- tion. This list builds on the already available requirements from [41]. The requirements are as follows: 1) Separability: it should be possible to apply RO only to ows that really require it. For example, RO should only be activated for all trafc originating from one specic MNN, whereas trafc from other MNNs is routed over the home agent. 2) Multihoming: the RO mechanism must be fully usable if several interfaces are present. More precisely, it should be possible to forward a route-optimized trafc ow via a particular interface/path. 3) Efcient Signaling: both the size and number of indi- vidual RO signaling messages should be kept small. 4) Security: the mobility entity on the ground receiving the BU must be able to validate the aircraft as proper owner of both the claimed care-of address and mobile network prex. Vulnerability to on-path attackers as in MIPv6 RO must be avoided (cf. Section IV-C). 5) Adaptability: the RO scheme should not break applica- tions using new transport protocols or IPsec. E. NEMO RO Options The RO procedure can be initiated and performed by dif- ferent entities. Consecutively, we establish four RO categories that are dened by the entities participating in RO signaling. These categories are also shown in Fig. 9: Mobile Network Node to Correspondent Node Mobile Router to Correspondent Node Mobile Router to Correspondent Router Mobile Router to Home Agent This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 13 MR MNN CN Data traffic RO Signaling (a) MNN to CN MR MNN CN RO Signaling Data traffic (b) MR to CN MR MNN CR RO Signaling Data traffic CN (c) MR to CR MR MNN HA RO Signaling Data traffic CN (d) MR to HA Fig. 9. The four different route optimization classes. We will only give a short overview on these categories in the following. A more thorough discussion on the advantages and disadvantages of the four individual solution classes can be found in [42] or [43]. Our main contribution is the assessment of these solutions with regard to the requirements specied in Section IV-D. Mobile Network Node to Correspondent Node: an exam- ple for this approach is [44]. The mobile router exposes the prexes advertised by its own access router(s) to the MNNs. The end-systems then form their own care-of addresses and perform RO in the standard MIPv6 fashion themselves. The problems with this approach is overhead, as signaling takes place between every (MNN, CN) pair. Another problem is how MNNs can make use of multiple paths off the mobile network from the MR (multihoming). Also, the access network has to accept every MNN address as source address for packets, something that may not be supported if the outgoing interface at the MR supports having only a single IP address. Security problems are also present as standard MIPv6 RO is used (cf. Section IV-C). Obviously, it would also be necessary to upgrade the MNN protocol stack with mobility extensions. An advantage of this category is that the RO path is the optimal one with direct routing between MNN and CN. Mobile Router to Correspondent Node: within this class, the mobile router performs all mobility signaling on behalf of the MNN. Several proposals exist [45], [46]. The signaling overhead is reduced to (MR,CN) pairs when compared to the previous category. An issue of this approach though are problems related to reusing standard MIPv6 RO signaling between MR and CN, which suffers from the on-path attacker problems (cf. Section IV-C). Problems arise with end-to-end integrity: if the MR performs actions on behalf of the MNN and modies user packets, it could be regarded as man-in-the- middle attacker by end-to-end security protocols used between MNN and CN (e.g. IPsec). The advantage is that the routing path is also optimal: the MNN will be directly attached to the MR, from where packets are routed to the CN on the direct path. Mobile Router to Correspondent Router was proposed in [47]. A new entity called Correspondent Router (CR), that is located within the CN network, is introduced. The mobile router performs mobility signaling with the CR and establishes a bi-directional tunnel that is used to exchange trafc between the mobile network and the network served by the CR. Signaling overhead is limited to (MR, CR) pairs, but the signaling itself is based on standard MIPv6 RO with its security limitations. The advantage is a good scalability as several CNs can be served by a single CR. Also, multihoming with the CR could be easily accommodated. Mobile Router to Home Agent: here, the concept of hav- ing only a single home agent for a mobile node is extended to having multiple, geographically and topologically distributed home agents. The proposal is called Global HA-to-HA [48]. While multihoming can be supported with [26], [27], the MR always binds with a single HA. Simultaneously routing different ows via different HAs is therefore not possible. The advantages are that both signaling overhead (efciency) and security are very similar to the basic NEMO protocol, which have been graded as completely fullled (cf. Table I). F. Grading Of RO Requirements The property Separability is completely fullled () by the MNN-to-CN class and sufciently fullled () by the other approaches. The reason for the reduced grading is the inability of the MR to perform trafc ow identication in case an end-to-end security protocol with condentiality is used, as protocol header elds are not readable anymore for the MR. The property Multihoming is either completely (), suf- ciently () or not fullled at all (). Sufciently refers to the fact that trafc can be routed via different interfaces at the MR, but that data still converges at and gets forwarded by the same home agent. This requirement can not be fullled without problems by MNN-based RO approaches because of problems related to sharing the care-of address: in case only one care-of address is available on an outgoing interface at the MR, this address would have to be shared among the MR and the MNNs. This requires NAT-like behavior, posing problems as described in [11]. Efcient signaling ranges from very bad () up to very good (), depending on the number of nodes involved in mobility signaling. The security requirement has been either fullled () or not fullled (). The grading of the property adaptability is as follows: it is either not fullled () because of problems with preserving end-to-end integrity or completely fullled () because the original payload is preserved due to tunneling encapsulation. It is also possible to sufciently fulll () this requirement in case end-to-end trafc is modied but no problems should be caused because the end-systems are performing RO them- selves. This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. 14 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION TABLE II OVERVIEW OF THE CHARACTERISTICS OF THE INDIVIDUAL SOLUTION CLASSES. REQUIREMENTS CAN BE EITHER FULFILLED (), PARTIALLY FULFILLED (), PARTIALLY PROBLEMATIC () OR PROBLEMATIC (). Requirement MNN to CN MR to CN MR to CR MR to HA Separability Multihoming Efcient Signaling Security Adaptability G. Conclusion A summary of the individual pros and cons is provided in Table II. It shows the problems of the rst two approaches and the strengths of the latter two, especially for the MR-to-HA class. The rst two approaches suffer from several problems, most notably security and also efciency since signaling is performed individually either for every CN or MNN. The third solution class, MR-to-CR, suffers from security problems. On the other hand, the Global HA-to-HA protocol (a MR- to-HA approach) manages to fulll all requirements. This identies it as the most promising approach among all the studied RO protocols. Fig. 10 shows how the Global HA-to-HA protocol could be used to extend NEMO for the ATN mobility architecture. Home Agents of the same home network are globally dis- tributed in the ATN and inter-connected to each other via tunnels. A problem with the deployment of this architecture is that the aeronautical communications service provider (ACSP cf. Section II-D) operating the home agents must have a world- wide network presence. If home agents are not available in close distance to the mobile router, a binding with a distant home agent would again have to be performed. Another problem is the routing to the distributed home network and its home agents in case of natural disasters, etc. If the routing path between the ANSP access network, where aircraft will often attach to, and the home network fails, communication would completely fail. An advantage of the MR-to-HA approach though is the applicability to the AAC and APC domains where passenger- owned devices have to be supported and data is routed over the public Internet. As mobility signaling is only performed between mobile router and home agent, both MNNs and CNs remain unaffected. In fact, the mobility protocol is completely transparent to these end-systems and they do not require any mobility extensions. V. SUMMARY We provided an overview of the peculiarities of the aero- nautical communications environment with its different service classes and discussed why a protocol to support mobility is actually needed. The focus of our survey was on supporting safety-related services (ATS/AOC) within the ATN, although we also introduced a requirement to cover the applicability to non-safety related services (AAC/APC). We investigated a number of protocols that can be used to provide IP mobility and assessed them with regard to the specic aeronautical requirements that we introduced. The conclusion was that NEMO is capable of fullling more requirements out of the box than any other protocol. The only problem of NEMO is the provision of a small end-to-end latency, as all trafc between the aircraft and the ground communication peers is routed via the home agent. We therefore surveyed a number of protocols that extend NEMO to solve the Route Optimization problem. Having assessed the individual protocols with regard to a dedicated set of RO requirements, it turned out that the Global HA-to-HA protocol fullls all requirements. An IP mobility architecture based on NEMO in conjunction with Global HA-to-HA could not only provide mobility for the safety-related ATS and AOC services within the ATN, but is also applicable to the AAC and APC domains in the public Internet. With Global HA-to-HA, mobility extensions only have to be implemented in the network stacks of the mobile router and within the home agents. The end-systems, both on the aircraft and on the ground, can have standard IP stacks and therefore remain mobility agnostic. VI. OUTLOOK While appealing from many aspects, there still remains an open issue with regard to the Global HA-to-HA protocol: the location information of mobile nodes has to be synchronized between all home agents. As also mentioned in [49], it remains to be claried how well this scales with an increased number of mobile nodes and home agents. As already mentioned in Section IV-G, the Global HA-to- HA protocol is not addressing all problems: in case routing to the home network and its home agents is broken, the end-systems on-board the aircraft are unable to communi- cate anymore. Furthermore, if not sufcient home agents are distributed all over the world, route optimization is not properly addressed anymore. The end-to-end latency problem then reemerges. In the future, additional work should therefore focus on an additional route optimization component that addresses this problem. Table II shows that a correspondent router-based approach can fulll most of the requirements. The protocol has to be improved by addressing the weak aspect of security though. In the course of modifying the correspondent router protocol it should be properly designed to provide route optimization without any home agent interaction. The approach would therefore have to be different from Mobile IPv6 RO where the home agent is an integral part of the signaling (cf. Sec- tion IV-C). Removing this dependency (exchange of signaling messages via the home agent) will make the RO component independent from the home network. As a consequence, RO This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 15 ANSP Network ATSCN HA In Asia HA in US HA in Europe ATN & Distributed Home Network MNN-ATS CN communication path AirIine network AOC CN MNN-AOC CN communication path HA-HA Tunnel MR-HA Tunnel Fig. 10. Mobility architecture for the ATS/AOC domains. can be performed and retained in the presence of home agent or home network failures. From a more general perspective that is independent of the used protocol, another issue is handover delay. As soon as (near) real-time data has to be exchanged, it becomes imper- ative to minimize delay and resulting packet loss during the handover. This can become necessary with the transmission of on-board sensor data to the ground or the usage of Voice over IP (cf. Section II-B). This issue has been well studied for host mobility [50], es- pecially for cellular networks [51]. Even more packet loss has to be expected for network mobility as the the large number of on-board end-systems also produce a larger number of data ows. While it has been shown that signicant improvements can be achieved [52], more investigations will be needed. ACKNOWLEDGMENT The authors would like to thank Thomas Gamer and Serkan Ayaz for related discussions and comments that helped to improve the quality of this manuscript. REFERENCES [1] International Civil Aviation Organization, Manual for the ATN using IPS Standards and Protocols (Doc 9896), February 2009, 1st edition, Unedited Advance version. [2] Single European Sky ATM Research (SESAR), European Air Trafc Management Master Plan, March 2009, edition 1. [3] I. Guardini, E. Demaria, and M. L. Monaca, Mobile IPv6 deployment opportunities in next generation 3GPP networks, in 16th IST Mobile and Wireless Communications Summit 2007, Proceedings of, 2007. [4] R. Baldessari, A. Festag, and J. Abeille, NEMO meets VANET: A De- ployability Analysis of Network Mobility in Vehicular Communication, in Proc. 7th International Conference on ITS Telecommunications (ITST 2007), Sophia Antipolis, France, Jun. 2007, pp. 375389. [5] Eurocontrol/FAA Future Communication Study, Communications Op- erating Concept and Requirements for the Future Radio System, May 2007, COCR version 2.0. [6] ICAO Aeronautical Communications Panel, WG F, Off- Board Communications for Vehicle Health Management, http://www.icao.int/anb/panels/acp/wgdoclist.cfm?MeetingID=266, December 2009, 21st meeting of the working group F, Bangkok, Thailand. [7] IEEE Standard for Local and metropolitan area networks. Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specications, IEEE Std 802.11-2007, pp. C11184, 2007. [8] IEEE Standard for Local and metropolitan area networks. Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands, IEEE Std 802.16e-2005, pp. 1822, 2006. [9] DLR, Expected B-AMC System Performance, September 2007, report D5. [10] B. Korn, C. Edinger, D. K ugler, T. P utz, O. Hassa, and B. Mohrhard, Is Sectorization Really Required For Efcient En-Route Air Trafc Control? in CEAS 2009 European Air and Space Conference, October 2009. [11] A. M uller, G. Carle, and A. Klenk, Behavior and classication of NAT devices and implications for NAT traversal, IEEE Network, vol. 22, no. 5, pp. 1419, 2008. [12] D. Le, X. Fu, and D. Hogrefe, A review of mobility support paradigms for the Internet, IEEE Commun. Surveys and Tutorials, vol. 8, no. 1-4, pp. 3851, 2006. [13] E. Perera, V. Sivaraman, and A. Seneviratne, Survey on network mobility support, SIGMOBILE Mob. Comput. Commun. Rev., vol. 8, no. 2, pp. 719, 2004. [14] ICAO Aeronautical Communications Panel, WG I, Analysis of Candi- date Mobility Solutions, 13th meeting of the working group N-SWG1, Montreal, Canada. [15] Y. Rekhter, T. Li, and S. Hares, A Border Gateway Protocol 4 (BGP- 4), RFC 4271, Jan. 2006. [16] A. L. Dul, Global ip network mobility using border gateway protocol, www.quark.net/docs/Global IP Network Mobility using BGP.pdf, Mar. 2006, Boeing White Paper. [17] M. Bagnulo, A. Garca-Martnez, J. Rodrguez, and A. Azcorra, The case for source address dependent routing in multihoming, in Quality of Service in the Emerging Networking Panorama: Fifth International Workshop on Quality of Future Internet Services (QofIS), 2004, pp. 237246. [18] K. Butler, T. Farley, P. McDaniel, and J. Rexford, A survey of BGP security issues and solutions, Proc. IEEE, vol. 98, no. 1, pp. 100122, January 2010. [19] S. Kent, C. Lynn, and K. Seo, Secure Border Gateway Protocol (S- BGP), IEEE J. Sel. Areas Commun., vol. 18, no. 4, pp. 582592, April 2000. This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. 16 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION [20] S. Kent and K. Seo, Security Architecture for the Internet Protocol, RFC 4301, Dec. 2005. [21] C. Kaufman, Internet Key Exchange (IKEv2) Protocol, RFC 4306, Dec. 2005. [22] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz, Extensible Authentication Protocol (EAP), RFC 3748, Jun. 2004. [23] P. Eronen, IKEv2 Mobility and Multihoming Protocol (MOBIKE), RFC 4555, Jun. 2006. [24] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert, Network Mobility (NEMO) Basic Support Protocol, RFC 3963, Jan. 2005. [25] D. Johnson, C. Perkins, and J. Arkko, Mobility Support in IPv6, RFC 3775, Jun. 2004. [26] R. Wakikawa, V. Devarapalli, G. Tsirtsis, T. Ernst, and K. Nagami, Multiple Care-of Addresses Registration, RFC 5648, Oct. 2009. [27] H. Soliman, G. Tsirtsis, N. Montavont, G. Giaretta, and K. Kuladinithi, Flow Bindings in Mobile IPv6 and NEMO Basic Support, Internet-Draft (work in progress) draft-ietf-mext-ow-binding-04, Nov. 2009. [Online]. Available: http://tools.ietf.org/html/draft-ietf-mext-ow- binding-04 [28] V. Devarapalli and F. Dupont, Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture, RFC 4877, Apr. 2007. [29] W. Eddy, At what layer does mobility belong? IEEE Commun. Mag., vol. 42, no. 10, pp. 155 159, October 2004. [30] D. Funato, K. Yasuda, and H. Tokuda, TCP-R: TCP mobility support for continuous operation, in Proc. the International Conference on Network Protocols (ICNP). Washington, DC, USA: IEEE Computer Society, 1997, p. 229. [31] K. Brown and S. Singh, M-UDP: UDP for Mobile Networks, in ACM Computer Communication Review, 1996, pp. 6078. [32] R. Stewart, Stream Control Transmission Protocol, RFC 4960, Sep. 2007. [33] R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, and M. Kozuka, Stream Control Transmission Protocol (SCTP) Dynamic Address Recongura- tion, RFC 5061, Sep. 2007. [34] R. Stewart, M. Tuexen, and G. Camarillo, Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures, RFC 5062, Sep. 2007. [35] A. Matsumoto, K. Fujikawa, Y. Okabe, F. Teraoka, M. Kunishi, M. Ohta, and M. Ishiyama, Multihoming Support based on Mobile Node Proto- col LIN6, in SAINT-W 03: Proc. the 2003 Symposium on Applications and the Internet Workshops (SAINT03 Workshops). Washington, DC, USA: IEEE Computer Society, 2003, p. 204. [36] P. Nikander, A. Gurtov, and T. R. Henderson, Host Identity Protocol (HIP): Connectivity, Mobility, Multi-homing, Security, and Privacy over IPv4 and IPv6 Networks, IEEE Commun. Surveys Tutorials, vol. 12, no. 1, pp. 24 38, second 2010. [37] S. Novaczki, L. Bokor, G. Jeney, and S. Imre, Design and Evaluation of a Novel HIP-Based Network Mobility Protocol, Journal of Networks (JNW), vol. 3, no. 1, pp. 1024, 2008. [38] NTT Communications Europe Website, Performance Statistics, Tech. Rep., Feb. 2009. [Online]. Available: http://www.ntt.net/english/ service/sla ps.cfm [39] P. Nikander, J. Arkko, T. Aura, and G. Montenegro, Mobile ip version 6 (mipv6) route optimization security design, in Vehicular Technology Conference. IEEE VTC Fall., vol. 3, October 2003, pp. 2004 2008. [40] P. Nikander, J. Arkko, T. Aura, G. Montenegro, and E. Nordmark, Mobile IP Version 6 Route Optimization Security Design Background, RFC 4225, Dec. 2005. [41] W. Eddy, W. Ivancic, and T. Davis, Network Mobility Route Opti- mization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks, RFC 5522, Oct. 2009. [42] A. Shahriar, M. Atiquzzaman, and W. Ivancic, Route optimization in network mobility: Solutions, classication, comparison, and future research directions, IEEE Commun. Surveys Tutorials, vol. 12, no. 1, pp. 24 38, rst 2010. [43] H.-J. Lim, M. Kim, J.-H. Lee, and T.-M. Chung, Route Optimization in Nested NEMO: Classication, Evaluation, and Analysis from NEMO Fringe Stub Perspective, IEEE Trans. Mobile Comput., vol. 8, no. 11, pp. 15541572, 2009. [44] C. Ng and J. Hirano, Securing Nested Tunnels Optimization with Access Router Option, Internet-Draft (work in progress) draft-ng-nemo-access-router-option-01, Jul. 2004. [Online]. Available: http://tools.ietf.org/html/draft-ng-nemo-access-router-option-01 [45] M. Calderon, C. Bernardos, M. Bagnulo, I. Soto, and A. de la Oliva, MIRON: Mobile IPv6 Route Optimization for NEMO, IEEE J. Sel. Areas Commun., issue on Mobile Routers and Network Mobility, vol. 24, no. 9, pp. 17021716, 2006. [46] C. Kim, Ed., S-RO: Simple Route Optimization Scheme with NEMO Transparency, ser. Lecture Notes in Computer Science, vol. 3391. Springer, 2005. [47] R. Wakikawa., S. Koshiba, K. Uehara, and J. Murai, ORC: Optimized Route Cache Management Protocol for Network Mobility, in IEEE 10th International Conference on Telecommunication (ICT), 2003, pp. 119126. [48] R. Wakikawa, G. Valadon, and J. Murai, Migrating home agents towards internet-scale mobility deployments, in CoNEXT 06: Proc. 2006 ACM CoNEXT conference. New York, NY, USA: ACM, 2006, pp. 110. [49] L. Zhang, R. Wakikawa, and Z. Zhu, Support mobility in the global internet, in MICNET 09: Proc. the 1st ACM workshop on Mobile internet through cellular networks. New York, NY, USA: ACM, 2009, pp. 16. [50] G. Xie, J. Chen, H. Zheng, J. Yang, and Y. Zhang, Handover Latency of MIPv6 Implementation in Linux, in Global Telecommunications Conference. IEEE GLOBECOM., 2007, pp. 17801785. [51] M.-J. Yang, K.-Y. Cheon, A.-S. Park, Y.-H. Choi, and S.-H. Kim, Seamless Handover Using FMIPv6 with Effective Tunnel Management Scheme, in Global Telecommunications Conference. IEEE GLOBE- COM., November 2008, pp. 1 5. [52] H. Petander and E. Perera, Measuring and improving the performance of network mobility management in IPv6 networks, IEEE J. Sel. Areas Commun., vol. 24, pp. 16711681, 2006. Christian Bauer received the BS and MS degrees in computer science from the University of Innsbruck, Austria, in 2004 and 2006 respectively. Currently he is a a researcher at the Institute of Communications and Navigation at the German Aerospace Center (DLR). His research interests are in the area of networking protocols and their application in the area of aeronautical communications, with a special emphasis on IPv6, mobility and handover management as well as security. Martina Zitterbart is full professor in computer science at Universit at Karlsruhe (TH). From 1987 to 1995 she was research assistant in Karlsruhe, receiving her doctoral degree in 1990. From 1991-1992 she was on leave of absence as a Visiting Scientist at the IBM T.J. Watson Research Center, Yorktown-Height, NY. She was Visiting Professor at the University of Magde- burg and the University of Mannheim and full professor at the Technical University of Braunschweig (1995-2001). Her primary research interests are in the areas of multimedia communication systems, mobile and ubiquituous computing, ambient technologies as well as wireless sensor networks. She is member of the IEEE, ACM and the German Gesellschaft f ur Informatik. In 2002, Martina Zitterbart received the Alcatel SEL research award on technical communication. In 2003, she was General Co-Chair of the ACM SIGCOMM conference which was held in Karlsruhe. This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.