a survey of protocols to support ip mobility in

IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION 1

A Survey of Protocols to Support IP Mobility inAeronautical Communications

Christian Bauer and Martina Zitterbart

Abstract—The aviation industry is currently at the beginningof a modernization phase regarding its communication systems.This involves a transition to IP-based networks for Air Traf-fic Control and Airline Operational Communications. Due tothe heterogeneous nature of the communication environment,support for mobility between different access technologies andaccess networks becomes necessary. We first introduce theaeronautical communications environment and present domainspecific requirements. The main part of this article is a surveyof different protocols that can be used to solve the IP mobilityproblem within the aeronautical environment. These protocolsare assessed with regard to the introduced requirements. Weconclude with the identification of a particular protocol as themost suited solution and also identify areas for further work.

Index Terms—Aircraft, Mobility, IPv6, Mobile IP, NEMO

I. INTRODUCTION

THE COMMUNICATION infrastructure currently usedfor civil aeronautical communications is based on an

analogue voice system that can neither cope with the expectedincrease in air traffic nor support the envisaged paradigm shifttowards data or packet oriented communications. The digital-ization effort is supposed to free-up the currently congestedanalogue voice based system and to increase operationalefficiency.For these reasons, a working group at the International Civil

Aviation Organization (ICAO) recently defined a standard [1]specifying the future IP-based Aeronautical Telecommuni-cations Network (ATN/IP). This global inter-network willbe based on IPv6 and will be deployed for ground-groundnetworks, air-ground access networks and on the airborne(on-board) network itself. The Internet Protocol IPv6 hasbeen chosen as the basis for the ATN as it (a) is a widelyused industry standard in telecommunications, (b) is activelymaintained and extended by the responsible standardizationorganization, the Internet Engineering Task Force (IETF),and (c) provides sufficient address space for a world-widedeployment in every national state and aircraft. In addition, itis also expected that IP provides a more cost-effective solutioncompared to proprietary protocol solutions.A typical ATN scenario, is an inter-continental flight from

Europe to Northern America. Throughout the complete flightduration from departure to destination airport, the aircrafthas 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: [email protected]).M. Zitterbart is with the Institute of Telematics, Karlsruhe Institute of

Technology (KIT) (e-mail: [email protected]).Digital Object Identifier 10.1109/SURV.2011.111510.00016

��

� �

��

��

��

��

� ��

Fig. 1. Scenario of aeronautical communications over different accesstechnologies and networks.

short-range terrestrial technologies at the airport, long-rangeterrestrial technologies while at cruise altitude and satellitetechnologies when over the Atlantic. A general picture ofthis situation is shown in Fig. 1. In addition, the velocityof an aircraft is larger than that of any other vehicle, withthe consequence, that complete continents and different accessnetworks can be passed in a matter of hours. Also, the com-munication peers are distributed among large geographical andtopological areas, starting in Europe and ending in NorthernAmerica. Despite these conditions, the routing path betweenthe aircraft and its ground-based communication peers shouldremain optimal, avoiding forwarding between different con-tinents in order to keep the end-to-end delay as short aspossible. Also, an aircraft is not only a single mobile host,but includes one or several on-board networks with numerousend-systems, establishing a need for the mobility of a completenetwork. The global system has to simultaneously support atleast hundred thousand of these mobile networks. Finally, themessages exchanged between the aircraft and its ground peersinclude air traffic control information. Availability and securityof these data flows 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 withInternet access.The remainder of this paper surveys the different solution

options on how to provide IP mobility within the aeronauticalenvironment.

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 andspecifies the mobility requirements that have to be satisfiedby a candidate mobility protocol. In Section III we investigatevarious protocols that can be used provide mobility andidentify their individual strengths and weaknesses. It becomesapparent that no solution can fulfill all requirements though.We identify a single mobility protocol family as the mostsuited one but realize that still one problem remains to besolved. In Section IV we therefore survey proposals thataddress the remaining problem of optimizing the overall end-to-end latency for that particular protocol family.We finally conclude with identifying the set of protocols that

can sufficiently fulfill all the requirements of the aeronauticalenvironment. Additionally, we identify areas for further workthat can help improve certain weaknesses and resolve openquestions.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, orforeseen 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 communicatingwith peers on the ground (Correspondent Nodes – CNs).

A. Difference To Other Communication Areas

Support for mobility of devices or networks is also requiredwithin other areas. In the following we will explain how theaeronautical environment differs from those other areas.Wireless personal communications based on mobile phones,

as defined by the 3rd Generation Partnership Project (3GPP),make use of IP mobility management as well [3]. The majordifferences are that mobile phones are only mobile hosts andnot mobile networks like an aircraft. Mobile phones also havea lower degree of mobility and a reduced level of security andavailability requirements.The Car2Car communications environment has to support

several end-systems within a car and thus acts as mobilenetwork. A major difference of the Car2Car protocol stack, es-pecially for car-safety applications, is the dual-stack approachthat not only consists of IP but also of dedicated Car2Carprotocols [4]. In addition, the degree of mobility and covereddistance is smaller than that of an aircraft - the inflicted delayis not as high as mobility is usually constrained to a singlecontinent.Summarized, the critical aspects within aeronautical com-

munications, in contrast to more conventional areas, are: ahigh degree of mobility that could cause delay problems dueto routing over large geographical distances, a need for highavailability and strong security.

B. Service Classes And Applications

There are four different service classes in the aeronauticalenvironment, each class covering different applications.

Air Traffic Services (ATS) covers all communication be-tween the cockpit (the mobile node) and the controller on theground (fixed node) for providing navigational support andair traffic control communications. The applications withinthis service class are critical to the safety of the flight. Thefixed ATS communication peer on the ground is called ATSCorrespondent Node (CN). The CN, the aircraft is currentlycommunicating with, changes over time depending on the ge-ographical position of the aircraft and the associated nationalairspace. Several CNs exist within each countries nationalborders, with responsibility dedicated either to airspace in andaround airports or for airspace at cruise altitude.Airline information systems include communication be-

tween an aircraft and the airline’s headquarter or operationscenter. This service class is separated into two classes: AirlineOperational Communications (AOC) and Airline Administra-tive Communications (AAC). AOC consists of services that areregarded as safety-related, e.g. flight status information (mal-function reports) or fuel reports. The non-safety related AACservices include messaging in respect to catering, baggagehandling or duty free sales. An AOC/AAC communicationpeer on the ground is called AOC/AAC CN. Usually up tothree such CNs occur during a flight: source and destinationairport 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. Thecorrespondent nodes are usually located in the public Internetand also include corporate Virtual Private Network (VPN)gateways. Providing a reasonable end-to-end delay to thesenodes is also highly desirable.At least for ATS and AOC, application requirements are

available. One document [5] provides numbers for bandwidthconsumption 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 340ms on average (one-way delay for a single application layermessage). The same document also mentions voice latencyrequirements that are usually 130 ms for ATS. At the time ofwriting it was not yet clear whether Voice Over IP will beused in the future IP-based ATN for mobile communication.In case yes, then this stringent requirement will have to bemet.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] includesensors whose data should be transmitted in real-time. Nospecific numbers are provided though.Apart from delay, another important aspect is availabil-

ity [5]: most ATS applications require 99.9%, while for someit is even 99.99%. This will also have to be supported by theunderlying 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


BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 3

carrying IP-based traffic that makes this network ”heavily”heterogenous.At airports standard IEEE 802.11 [7] (Wifi) equipment is

already in use for providing wireless connectivity for AACcommunications 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 severalMbit/sec per radio cell for ATS and AOC traffic. StandardWiMAX can be used to provide connectivity for AAC andAPC.Most of the ATS traffic over continental areas, as well as

AOC traffic, will be carried by the L-Band Digital Aero-nautical Communications System L-DACS, a technology thatis currently in development. L-DACS will provide typicalthroughput values up to 1.5 Mbit/sec per radio cell with delayvalues of 100 ms on the FL1 and 200 ms on the RL2. Insituations with medium congestion 300 ms on the FL and 600ms on the RL during high congestion phases [9] have to beexpected.Especially for oceanic, remote and polar regions low earth

orbit (LEO) and geostationary orbit (GEO) satellite systemswill complement the terrestrial technologies. GEO satellitesare 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 ofdedicated frequencies can be used for technologies carryingsafety-related data (ATS+AOC).

D. Network Model

The IPv6 based ATN will carry ATS and AOC data and willbe a closed network, not reachable from the public Internet.The non-safety related AAC and APC traffic is not supposedto be routed over the ATN – these service classes will insteaduse the public Internet. The networks and nodes within theATN are operated by three different interest groups that wewill introduce in the following. Routing between the differentnetworks is based on the Border Gateway Protocol (BGP),the Exterior Gateway Protocol (EGP) also used in the publicInternet. An exemplary figure illustrating the networks andinter-connections of the different stakeholders is shown inFig. 2.The first group are the Air Navigation Service Providers

(ANSPs), state owned authorities that are directly responsiblefor providing ATS within their national airspace. ANSPs areoperating both networks and end-systems in the ATN. Thoseend-systems are the ATS CNs on the ground that aircraft areexchanging air traffic control instructions with.ANSPs have the obligation to provide ATS communication

infrastructure within their country, meaning that in the futurethey have to provide IPv6 based access networks3 that aircraftcan attach to within the ANSPs national (airspace) boundaries.

1Forward Link: Base Station to Mobile Node.2Return Link: Mobile Node to Base Station.3An 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 beestablished:

• The ANSP owns and operates its own access networkthat topologically becomes a sub-network of the overallANSP network (e.g. ANSP #1 in Fig. 2).

• The ANSP can outsource the operation of the accessnetwork to a service provider. The access network isthen topologically a part of the service provider network.Traffic between this access network and the ANSP isrouted with help of an EGP (e.g. ANSP #2 in Fig. 2).

Aeronautical Communications Service Providers (ACSPs) arenetwork 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 independentlyfrom ATS dedicated networks for the purpose of providingtransit 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 airlineoperations network in Fig. 2). Airlines usually have a businesscontract with a communication service provider so that theiraircraft can attach to and send AOC traffic over the serviceproviders 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 airtraffic operators nor by the aforementioned ACSPs. Instead,this is similar to consumer communications where InternetService Providers offer connectivity to the public Internet.

E. The Need For Mobility Support

A typical example for ATS communications is an aircraftcommunicating 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 theL-DACS access network. Due to moving to a different IPsubnetwork, the IP address of the aircraft changes. In order topreserve the established session in the presence of handovers,a mobility protocol is necessary. That provides a fixed, staticIP address to the higher layers. This property is called session-continuity.Another example for the usefulness of session continuity are

low air traffic situations during nights in the future Europeanairspace, where all flights above France and Germany couldbe controlled by only a few controllers of either Germanyor France. This implies that, while performing handoversbetween the different access networks in Germany and France,aircraft always communicate with the same CN. This can alsobe the case in the future if a personal controller is assignedto an aircraft who is responsible for the large durations of aflight [10].Another issue is the availability of public IP address space

on the aircraft: on-board end-systems (MNNs) should becapable of obtaining a public IP address for allowing global



��

��

��

��

��

��

��

��

��

��

��

��

��

��

Fig. 2. Topology of the ATN. Correspondent Nodes (CNs) are the communication peers of the aircraft. Air Traffic Services (ATS) CNs are controlledby the Air Navigation Service Providers (ANSPs). The Air Communication Service Provider (ACSP) operates access networks. The Airline OperationalCommunication (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 addressesavailable at the airborne router among all end-systems, butcauses problems as discussed in [11], e.g. with end-to-endsecurity protocols. Apart from that, session continuity couldnot be provided anymore. The future aeronautical mobilityprotocol should therefore also provide public IP addresses toall on-board end-systems.In normal operations, ATS communication is always

aircraft-initiated. In the future it might become interestingto provide a controller with the means to contact an aircraftthat has entered controlled airspace but not yet established acommunication session. A fixed static IP address space forthe 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 (ANSPsand ACSPs), handovers between different networks will occur.This implies the need for providing an IP mobility protocolthat permits session continuity, provides public on-board IPaddress space and offers the possibility to allow for ground-initiated communications.

F. Mobility Requirements

In the following we specify inherent, primary and secondaryrequirements that have to be fulfilled by a mobility protocolused in the aeronautical environment. In the following, theword ”aircraft” refers to a complete mobile network, consist-ing of an airborne router and at least one network prefix.Several end-system (MNNs) are attached to this airbornerouter.The inherent requirements that must be completely fulfilled

by all candidates are as follows:

1) Session continuity: this property provides a constant IPaddress for use to higher layer protocols, even in caseof handovers.

2) Mobile Network support: mobility should not only beprovided for a single mobile host, but for a complete on-board network. More specifically, instead of providinga constant IP address (as the case for the previousrequirement) one or several constant network prefixesshould be provided.

”Session continuity” is automatically fulfilled by all mobilityprotocols investigated later. It is therefore not mentionedanymore in the final comparison.The primary requirements that should all be fulfilled 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 terrestrialnetwork). This requirement covers both load-balancingand fault-tolerance. The latter addresses the importantissue of reliability/availability: in case of failure ofone interface/path, packets can be routed over anotherinterface/path.

2) Security 1 (masquerading): an attacker must not be ableto claim the constant addresses/prefixes of an aircraft,e.g. by means of man-in-the-middle attacks.

3) Security 2 (DoS): the mobility protocol itself should notintroduce any new denial of service vulnerabilities.

4) End-to-end delay: the delay between the communicationpeers (end systems on the aircraft and the ground)should be kept minimal. Application specific delay re-quirements have been introduced in Section II-B.

5) (Routing) Scalability: the impact of the mobility proto-



col on the global routing infrastructure should be keptto a minimum, meaning that frequent route announce-ments/withdrawals for every individual aircraft shouldbe avoided.

6) Applicability to AAC/APC: specifies 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 modified in order to support mobil-ity. Especially for the APC domain it is unlikely thatpopular, frequently visited web servers in the publicInternet will upgrade their protocol stacks with mobilityextensions.

Secondary requirements are desirable and their fulfillment isa bonus:

1) Efficiency 1: the overhead incurred by the mobilityprotocol itself should be limited. The number of round-trip times (RTTs) needed for mobility-related signalingshould therefore be kept minimal.

2) Efficiency 2: the overhead imposed upon every individ-ual packet with payload from the MNNs or CNs shouldbe limited. The number of additional protocol headers,needed to support mobility, should therefore be keptminimal.

3) Convergence time: a new routing path to and from themobile network (e.g. because a new interface has beenactivated) should become usable for packet forwardingwithin the shortest possible amount of time. Whileconvergence time is also influenced by the number ofexchanged signaling messages as described by Efficiency1, this requirement is restricted to the time it takesto propagate the new mobility state throughout the(routing) system.

4) Support for ground-initiated communications: end-systems on the ground should be capable of sendingpackets to an aircraft they have not yet communicatedwith. This means that a routing path to the currentlocation of an aircraft has to be available for these nodes.

It is preferable to have a single protocol (family) as asolution for all domains, ATS/AOC/AAC/APC. This is takeninto account by the primary requirement ”Applicability toAAC/APC”. The reason for this requirement is that, apart fromcost reasons, in the long term, the safety and non-safety relateddomains might be handled by a single airborne router.

III. MOBILITY OPTIONS

Protocols for providing IP mobility are also discussedin [12], [13], with a focus on the aeronautical environmentin [14].Our investigation is different from the previous ones by (a)

having introduced numerous requirements and (b) by assessingthe protocols based on those requirements. While the workperformed in [14] also specifies certain requirements, many ofthem are high level. In general, we investigate the protocolsand perform our analysis with a higher degree of detail. Also,the second part of our survey, starting in Section IV, addressesan important optimization problem that is not covered at allby [14].

From a general perspective, the mobility problem can besolved by a solution that is located on the link, network,transport or application layer.A solution on the link layer is access technology specific.

As explained in Section II-C, the ATN is a heterogenous envi-ronment with different technologies. This requires providingmobility among different technologies, therefore ruling out thelink layer approach and raising the need for a solution locatedat least on the network layer.Application layer solutions require that applications are

made mobility-aware. Apart from the burden imposed onapplication developers, another serious problem is with non-safety related services. All existing airline information systemswould have to be updated. Also, applications on passenger-owned devices as well as in the public Internet would haveto be modified as well. This rules out the application layerapproach for very practical reasons.We therefore focussed on protocols between the network

and transport layer for our investigation. We identified fivedifferent protocols that can be categorized as follows:

• Routing protocol based approach (network layer), withthe example of the Border Gateway Protocol.

• Tunneling based approaches (network layer), with theexamples of the IPsec and Mobile IP protocol families.

• A transport protocol approach, with the example of theStream Control Transmission Protocol.

• Locater-identifier split (between network and transportlayer), 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 withregard to the previously specified requirements.

A. Border Gateway Protocol

While routing protocols are not classical IP mobility proto-cols, they can nevertheless solve the problem of routing in amobile 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 exchanginginformation on routing paths to specific destination prefixes.Routing information is distributed to neighboring routers thatupdate their routing tables and forward the routing informationto 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 ondynamic homing, in opposite to the more common statichoming used in the Internet.The operation of this solution is shown in Fig. 3. Each

aircraft receives a /24 prefix that is announced via BGP bythe ground station the aircraft is currently attached to. Eachground station is an autonomous system (AS) with its ownAS number and its own BGP router/speaker. When the aircraftmoves and performs a handover to a different ground station,the old ground station withdraws the /24 prefix of that aircraftwhile the new ground station will start announcing the aircraftprefix from its own AS. Packets destined to the aircraft arethen routed to the new AS/ground station.



BGP Update X.Y.Z/24

Autonomous System B

Internet

Autonomous System A

Handover1

BGP Withdraw X.Y.Z/24 2

3

Fig. 3. BGP route announcements by ground stations.

Frequent route announcements and withdrawals lead toroute dampening, causing the route in question to not beaccepted anymore nor advertised to neighbors by other BGProuters. With a handover occurring only once every 4-8hours for an aircraft, dampening did not become a problemaccording to [16]. However, tests showed that with shortertime intervals dampening does occur. As handovers betweenterrestrial technologies of the ATN are supposed to occur morefrequently 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 majorbackbone networks in the Internet to update their routingtables 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 prefix (for example an IPv4-based /24 asin [16]) that is always announced by the current base stationof the aircraft. This requirement is therefore fulfilled, as end-systems receive their addresses from this stable prefix.Mobile Network support (inherent): fulfilled since the

aircraft receives a complete mobile network prefix instead ofa single IP address.Multihoming (primary): BGP multihoming is an estab-

lished technique in the fixed Internet. However, this formof multihoming is usually restricted to either ”simple” load-balancing or to destination-based routing decisions. Whilethere are possibilities to include at least the source address ofpackets into the routing decision [17], the problem of routingspecific traffic flows (e.g. based on the used transport protocoland port numbers) still remains unsolved.Security 1 (primary): the problems of BGP with respect

to security have been thoroughly investigated [18]. One ofthe key problems is that BGP routers can advertise prefixesthat do not even belong to them – an attacker can advertise aprefix owned by someone else and therefore attract the trafficbelonging to the other entity. Secure BGP (S-BGP) [19] is oneproposal that provides a solution to this problem, although atthe expense of an increase in convergence time [18]. S-BGPrelies on a Public Key Infrastructure (PKI) and certificates thatauthorize the owner to manage a certain IP address space. An-nounced BGP information is then signed by a private key thatcan be verified by the recipient based on the public key in thecertificate, therefore ensuring the authenticity of announced

routes. To secure the full routing system, all BGP speakershave to implement S-BGP. Also, further investigations areneeded to identify whether S-BGP has to be adapted to workwith dynamic homing.Security 2 (primary): The only aspect of S-BGP that might

be regarded as problematic is the increase in CPU and memoryconsumption. There is not enough experience with S-BGPavailable 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 theaircraft as routes are calculated via the current base station,which currently advertises the aircraft prefixes. The exactmeaning of ”shortest-path” is defined by the metric of therouting protocol.Scalability (primary): an inherent property of BGP are

frequent route announcements and withdrawals from the newand old points of attachment of an aircraft. As the ATN willbe separated from the public Internet and has its own BGProuting core, scalability might not become a problem withinthis environment. However, the AAC/APC domains are routedover the public Internet and the use of BGP would thereforecause negative impacts upon the routing tables. Scalability islinear with the number of mobile nodes, with regard to thenumber of route announcements and withdrawals.Applicability to AAC/APC (primary): the protocol stack

on end-systems remains unaffected as BGP exchanges areperformed 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 thesmaller number of autonomous systems and routes comparedto the public Internet.Efficiency 1 (secondary): in [16] BGP route updates were

announced by the ground stations. In this case, the aircraft onlyhas to provide its identity and its prefix to the ground station,which then performs BGP announcements on behalf of theaircraft. Another option, different from [16], would be to putthe BGP speaker on-board the aircraft. The signaling, that isbased on TCP, then has to be performed over the wireless link.This implies 1.5 RTTs for establishing the TCP connection andat least additional 1.5 RTTs for the BGP signaling.Efficiency 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 aircraftprefix, a route to the aircraft becomes available and trafficwould be properly routed to the aircraft.

B. IPsec

IPsec [20] is a well known protocol providing confiden-tiality, data integrity and data source authentication. Theseservices are provided by maintaining a shared state betweenthe two communication peers, also called Security Association(SA). The SA consists of information related to IP address ofthe two communication peers, cryptographic algorithm iden-tifiers and keys, etc. Establishing such a SA manually wouldnot be scalable, hence the Internet Key Exchange (IKEv2)protocol [21] provides the means to create and manage themdynamically. IKE mutually authenticates the two peers, based



��

� ��

��

� ��

��

��

��

��

��

��

��

��

��

�

�

�

��

�� !��

��!"�#� ��

$��%!��

&!��

'

Fig. 4. Signaling between airborne router and IPsec security gateway.

on either pre-shared secrets, certificates or the ExtensibleAuthentication 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 differentnetwork and configures a new IP address, the established SAswould not be usable anymore. For this reason, the IKEv2Mobility and Multihoming protocol (MOBIKE) [23] extendsIKEv2, allowing one peer (the mobile node) to change theIP address of a SA and to signal this change to the securitygateway. In addition, the peer can also transparently move alltraffic flows from one interface/IP address to another one.MOBIKE is usually used between a mobile node and its

(fixed) security gateway that assigns a constant IP address tothe 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 theassignment of a static, fixed IP address from the gateway.Traffic destined to or originating from the mobile network willtherefore always be routed via this gateway, with whom themobile node establishes an IPsec tunnel. In case the mobilenode moves to a different access network, a MOBIKE messageexchange updates the SA(s) and ensures that the gatewayforwards traffic via the IPsec tunnel to the mobile nodes newlocation, the care-of address (CoA). The CoA is the IP addressthat the airborne router configures in the new access network(in Fig. 4 the CoA is first from Access Network A and afterthe handover from Access Network B).Mobile Network support: instead of acquiring a single

address during the initial SA establishment with IKE, theairborne router could request a network prefix from thegateway (e.g. a /24 as it was the case for BGP). This way, themobility 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 ina sequential way. Using several interfaces simultaneously toroute different data flows over different interfaces is notsupported.Security 1: a mutual authentication within IKE is per-

formed between the gateway and the airborne router, basedon pre-shared secrets, certificates or EAP. This ensures thatthe gateway forwards traffic to the correct airborne router.

Security 2: a vulnerability of IKE are CPU-exhaustionattacks. The protocol defines a cookie-based mechanism thatcan be activated if necessary and reduces the threat to anacceptable level.End-to-end delay: the security gateway is a pivotal node

that is always traversed by packets exchanged between themobile 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 infrastructuretherefore remain unchanged. The gateway or another BGPspeaker in the gateway network only has to advertise a singleaggregated prefix via BGP that includes the addresses of allits 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 transparentlytunnels all traffic to the security gateway.Convergence time: when the airborne router moves to a

different network, it notifies the gateway of its new address. Asdata is always routed via the security gateway, the successfulcompletion of this notification ensures that data is immediatelyrouted to the new location. This is achieved with help of thestatic, fixed IP address or prefix.Efficiency 1: when moving to a different network, the

airborne router needs 1 RTT of signaling with MOBIKE toinform the gateway of its new location.Efficiency 2: the use of IPsec usually implies integrity

protection and allows for additional encryption. Even if nocryptographic algorithms are specified, the additional headersincrease the overhead for every payload packet. In addition tothat, the overhead of a complete IP header is added to everypayload packet as an IPsec tunnel is used. The IPsec transportmode, while eliminating the additional header, would not beable to provide mobility.Support for ground-initiated communications: as data is

always routed via the security gateway that is always notifiedby the airborne router of its current location, traffic can beimmediately 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 conceptof a mobile node to that of a Mobile Router (MR) with one orseveral mobile network prefixes. As soon as the MR attachesto a foreign network it registers the new CoA with its HomeAgent (HA) in the home network and creates a bi-directionaltunnel for forwarding traffic between the nodes of the mobilenetwork and the communication peers on the ground via theHA.Analysis: Session continuity: similar to the IPsec solution

(cf. Section III-B), the home agent provides the airborne routerwith a constant IP address – called the Home Address (HoA)– from its own network. Traffic is therefore always routed viathe 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



��

� ��

��

� ��

��

��

��

��

� ��

� ��

��

��

��

�

�

�

��

��

��

�

Fig. 5. Signaling between mobile router and home agent.

Prefixes (MNPs). These prefixes belong topologically to thehome network. End-systems that attach to the MR configuretheir addresses based on the MNP advertised by the MR andcan therefore remain mobility agnostic.Multihoming: the possibility to register several care-of

addresses with the home agent is specified in [26]. In ad-dition, [27] specifies a policy exchange protocol that can beused to setup forwarding rules for certain traffic flows, takinginto account the additional care-of addresses. Detailed trafficselectors can be used to identify a flow, based on IP or higherlayer protocol fields such as source/destination address, portnumbers, etc. The MR sends its current policy to the HAwhich sets up forwarding to the MR accordingly. This allowsfor simultaneously routing traffic flows over different interface,on the routing path from the MR to the HA as well as on thepath from the HA to the MR.Security 1: MR and HA perform a mutual authentication

between each other based on IKEv2 [28]. This ensures thatthe 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 attacksas already discussed for IKE in Section III-B applies here aswell.End-to-end delay: NEMO causes sub-optimal routing

where traffic always traverses the HA. If the distance betweenMR and HA increases, the overall end-to-end latency alsoincreases.Scalability: the MR signals its current location to the HA

that updates its routing state accordingly. BGP routing tablesremain unchanged as the Home Network is always advertisingan aggregated prefix via BGP that includes all the MNPs.Scalability is therefore linear with the number of aggregates,with regard to the number of announced prefixes.Applicability to AAC/APC: the protocol stack on end-

systems remains unaffected as traffic is transparently tunneledbetween 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 immediatelyforward traffic to the MNs new CoA.Efficiency 1: it takes the MR 1 RTT to signal the new

location/care-of address to the HA.

Efficiency 2: the tunnel between the MR and the HA inflictsan 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 traffic is alwaysrouted via the home agent. As the MR signals its care-ofaddress(es) to the HA, this traffic can be forwarded to theMRs current location.

D. SCTP

The problem of mobility is directly impacting the transportlayer, where active sessions break due to the usage of theIP address as an identifier. One might therefore regard thetransport layer as a more proper location for a solution to themobility problem [29].An approach that is different for the previous ones is solving

the problem on the transport layer itself. There are proposalsfor 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 SCTPover other protocols such as TCP-R or M-UDP, because ofthe 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 specification allows specifyingseveral IP addresses during connection setup time only. Thislimitation has been removed with [33] where newly config-ured IP addresses can be dynamically added to or deletedfrom an SCTP association by one of the two communicationpeers. This is particularly useful for a mobile node whereIP addresses appear and disappear due to handovers betweendifferent access networks.Analysis: Session continuity: in case the MN moves to a

different network where it configures a new IP address, it candynamically add this new address to the SCTP connectionperforming a ”failover”. Afterwards, data can be exchangedusing the new association.Mobile Network support: SCTP, as a transport layer

protocol, is running on the end hosts and as such is not ableto support network mobility.Multihoming: while dynamically adding or removing IP

addresses can be used for mobility, its original intention wasto provide multihoming functionality to SCTP. The SCTPmultihoming however supports only redundancy but not load-balancing. While several IP addresses can be associated toa single SCTP association, only one address (the primaryaddress) can be used to transmit packets.Security 1: SCTP is vulnerable with regard to an attacker

hijacking an already established association between twocommunication peers [34]. This enables an attacker to hijacktraffic of a mobile node.Security 2: there do exist vulnerabilities within SCTP

that can be exploited to send large volumes of unwantedtraffic to a victim. E.g., this can be achieved by providing anadditional false address to the SCTP association. The attackercan later force the other SCTP peer to use this address andsend all traffic to it. These attacks can be either mitigatedor the probability to successfully mount an attack at least be



minimized. This can be achieved by properly implementingSCTP or choosing proper protocol parameters. [34].End-to-end delay: SCTP associations are bound to the

addresses that are locally available on the two communicationpeers, including the care-of addresses at the mobile node. Theend-to-end delay therefore corresponds to the shortest routebetween 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 inorder to have mobility support.Convergence time is equal to the time the respective SCTP

messages need to signal the availability of a new IP addressto the communication peer.Efficiency 1: signaling consumes 1 RTT to add a new IP

address to the SCTP association.Efficiency 2: by solving the problem on the transport layer,

SCTP does not incur any additional overhead to payloadpackets.Support for ground-initiated communications: the at-

tempt of a communication peer on the ground to establisha SCTP connection to a mobile node will fail due to theunknown current location (care-of address) of the mobile node.

E. HIP

Another, more radical, approach for supporting mobility isthe locator-identifier split, where a new shim layer between thenetwork and the transport layer is introduced. This layer alsointroduces a new namespace on top of the IP address space.The identifiers within this namespace are globally unique andassociated to a mobile node. Higher layers (e.g. TCP) are notbinding anymore to an IP address (the locator), but instead tothe new identifier. Several different approaches exist based onthese identifiers, for example LIN6 [35] or the Host IdentityProtocol (HIP) [36].In HIP, Host Identity Tags (HITs - the identifiers) are

mapped to the available IP addresses (locators) with the helpof IPsec. The HITs are generated from the public key andtherefore cryptographically bound to it. Only the owner of thecorresponding private key can make use of the related HIT inthe HIP protocol exchanges. If the HIP-enabled mobile nodeattempts to communicate with a HIP correspondent node, itinitiates a message exchange to establish a common sessionbased on the HITs of the two nodes and the IP addresses theywant to use for message exchange. In case one peer moves toa new location, it signals the new IP address to the other peer.The HIP modules on both nodes can then update their stateand map the HIT to the new IP address. In case the mobilenode is multihomed, the HIT can have a mapping to severalIP addresses.HIP also provides Rendezvous Servers (RVS). Mobile nodes

register with an arbitrary RVS and then update their entriesin the Domain Name System (DNS) to (mn.example.org,IP RVS). A correspondent node attempting to contact the MNperforms a DNS lookup and thereby retrieves the address ofthe RVS. The contact initiation from the correspondent node

��

��

��

��

��

��

��

� ��

��

��

��

Fig. 6. Host Identity Protocol with mapping to lower and higher layers atmobile node and correspondent node. A Host Identity Tag (HIT) is present forboth source (”HIT s”) and destination (”HIT d”). The Security ParametersIndex (SPI) uniquely identifies an IPsec Encapsulated Security Payload (ESP)security association. ”IP s” and ”IP d” refer to source and destination IPaddress respectively.

to the RVS can then be forwarded by the RVS to the currentlocation 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 configures 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 affectedas 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 networknodes are required to have a HIP stack and delegate rights toa HIP-enabled airborne router that performs HIP signaling onbehalf of the mobile network nodes.Multihoming: the multihoming support in HIP is focused

on providing failover functionality. Simultaneous usage ofdifferent interfaces, e.g. for load-balancing, has not beeninvestigated at the time of writing. HIP can therefore not fullymeet 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 – includingman-in-the-middle – can not impersonate a node or claimtraffic of a node.Security 2: There is a limited vulnerability to memory

and computational exhaustion attacks where an attacker floodsa HIP-enabled node with a large amount of HIP signalingmessages.End-to-end delay: traffic is exchanged directly between

communication peers. End-to-end delay therefore correspondsto the shortest route between the two peers.Scalability: HIP does not modify the routing system but

instead introduces a new identifier space. Scalability issuesare therefore not related to the routing infrastructure, but tothe rendezvous servers (RVS).Applicability to AAC/APC: end-systems must have HIP

implemented in their network stack. In addition they mustdelegate rights to the airborne router in case of mobile networksupport.



TABLE IMOBILITY 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 � ⊕⊕ ⊕⊕ ⊕⊕ ⊕Efficiency 1 � ⊕ ⊕ ⊕ �Efficiency 2 ⊕ �� ⊕ �Ground-initiated comms. ⊕⊕ ⊕⊕ ⊕⊕ � ⊕

Convergence time is equal to the time it takes the mobilenode to perform the HIP signaling exchange that updates the(HIT, IP address) mapping at the correspondent node. The onlydisadvantage is that the signaling has to be performed everytime communication of a new (mobile node, correspondentnode) pair is initiated.Efficiency 1: establishing a common HIP state between a

mobile node and a correspondent node takes 2 RTTs; updatingthis state after movement of the mobile node consumes 1.5RTTs.Efficiency 2: as HIP uses IPsec to exchange traffic between

its two communication peers, overhead is present for everypayload packet. However, HIP does not use a VPN-like IP-in-IP tunnel, but instead relies on IPsec transport mode. Thisonly adds a small IPsec related header instead of an additionalIP(v6) header.Support for ground-initiated communications: the initial

reachability of a mobile node within HIP can only be providedwith the help of the rendezvous server. Scalability, with regardto number of DNS entries, is linear with the number of mobilenodes.

F. Summary

The discussion of all the various protocols shows thatthere is no optimal solution that is capable of fulfilling allrequirements ”out of the box”. In the following, we provide asummary of how the requirements are graded and discuss howthey are fulfilled by each protocol. In addition Table I showsthe comparison of all protocols in a more compact manner.1) Grading Of Mobility Requirements: The grading of the

property Multihoming is either completely fulfilled (⊕⊕),fulfilled with limitations (⊕/�) or not fulfilled (�). The latteris applied if load-balancing is not supported.Security 1 is either completely fulfilled (⊕⊕) or not fulfilled

(�). Security 2 has the additional grading levels (⊕/�) and (�)that indicate that vulnerabilities exist but the probability foran attacker to exploit them is very small, given that certainprecautions are taken.The end-to-end delay can be either optimal (⊕⊕) or sub-

optimal (�). The latter being the case if packets are routed viaa fixed node on the ground, instead of routing on the directpath 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 nodesand (⊕) indicates linear scalability with number of aggregatedprefixes. Finally, (�) for HIP is scalability with number ofmobile nodes, but graded better because it only impacts theDNS. More precisely, the DNS entry of a mobile node is onlystored at a single DNS server. This is in contrast to individualentries for mobile nodes in BGP tables that have to be presentin 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 (⊕⊕), influenced byDNS lookup and forwarding of the initial packet by a rendez-vous server (⊕) or depending on the convergence time of theglobal routing tables (�) for an inter-network of limited size,such as the ATN.The gradings of the individual protocols for Efficiency 1 and

Efficiency 2 are relative to each other.Ground-initiated communications is either fully supported

(⊕⊕), supported with a dependency on the DNS (⊕) or notsupported 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 difficulties for alreadyexisting AAC systems and makes them infeasible for de-ployment within the APC domain, where public well-knownweb servers in the Internet would have to be upgraded. Also,the multihoming capability of HIP would have to be furtherinvestigated. HIP is therefore unable to fulfill one primaryrequirement.SCTP, while being an interesting approach, does not provide

full multihoming support. Another critical aspect though thefact that it is only sufficient for a mobile host and unableto provide mobility support for a complete mobile network.While it might be possible to add mobile network supportto this solution approach, the fact that both TCP and UDPwithout any mobility extensions are the most frequently usedprotocols in the public Internet makes the transport-layerapproach infeasible for the AAC/APC domains. Summarized,SCTP is unable to fulfill one inherent, three primary and onesecondary requirement.BGP has problems with providing multihoming on a per-

flow granularity level. While S-BGP raises security to anacceptable level, there might be reasons for concern with



the increase in CPU and memory consumption. The majorproblem of BGP – scalability – becomes problematic for AACand APC which are both based on the public Internet. Theoperation of BGP as a mobility protocol [16] even causedconcerns in the Internet Engineering Task Force (IETF). Intotal, BGP is unable to completely fulfill one and only partiallyfulfills 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-endlatency, overhead inflicted on payload traffic as well as thelack of multihoming capabilities with respect to simultaneoususage of several interfaces. An advantage of IPsec would bethe implicitly provided security for the higher layers. Unfor-tunately, this feature can not be exploited within a mobilenetwork architecture where the airborne router establishes aVPN with a security gateway: the IPsec security associationwould not provide end-to-end security. On the other hand,the Mobile IP-based NEMO protocol is a generic mobilityprotocol providing a multitude of features, but also suffersfrom problems with payload traffic overhead and end-to-enddelay.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. IPsecand NEMO fail to meet two and one primary requirementrespectively.A close look at Table I shows that, taking into account all

gradings, Mobile IP/NEMO is the highest rated solution. Wetherefore argue that it is the most feasible solution for theaeronautical environment.Despite this conclusion, it might nevertheless be possible to

extend some of the other solutions to such an extend that theyare capable of fulfilling all requirements. We argue thoughthat it is more meaningful to start with the protocol thatalready fulfills most of the requirements and then address theremaining issues of this protocol.

IV. NETWORK MOBILITY ROUTE OPTIMIZATION

NEMO fulfills most of the requirements, but lacks anacceptable end-to-end latency as of now. In the following weprovide a more detailed overview of the NEMO protocol anddiscuss why a solution to this problem is required.

A. Network Mobility (NEMO)

The NEMO protocol [24] extends the Mobile IPv6 conceptof a mobile host having a static, fixed (publicly routable) homeaddress with having a mobile router with mobile networkprefixes.A mobile network consists of a Mobile Router (MR) with at

least one Mobile Network Prefix (MNP) and Mobile NetworkNodes (MNNs) that are attached to the MR and form their ad-dresses based on the advertised MNP. The mobility signalingthat 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 prefixes are routed to the MRby means of normal routing. As soon as the MR moves awayfrom the home network and attaches to a foreign network,

MNN MR CN

BUBA

Signalling User Data Tunnel

HA

Fig. 7. NEMO mobility signaling and forwarding of user traffic over bi-directional tunnel. Binding Update (BU) and Binding Acknowledgement (BA)are exchanged between Mobile Router (MR) and Home Agent (HA). Usertraffic is exchanged between the Mobile Network Node (MNN) and theCorrespondent Node (CN).

it becomes addressable via a Care-of Address (CoA) thattopologically belongs to the foreign network. The MR sendsa Binding Update (BU) to the Home Agent (HA) in thehome network. The HA creates an entry in its Binding Cachelinking the MNPs and the CoA. The home agent createsa bi-directional tunnel to the MR after having respondedwith a Binding Acknowledgement (BA). IKE/IPsec is used toauthenticate and protect the mobility signaling between mobilerouter and home agent [28].Packets of arbitrary Correspondent Nodes (CNs) communi-

cating with the MNNs are routed to the home network, wherethe home agent intercepts these packets and tunnels them tothe current CoA of the mobile router, who will decapsulateand forward them to the MNN. Packets from MNNs destinedto CNs are first tunneled by the mobile router to the homeagent from where they are routed to the CN.If the distance between mobile router and home agent

grows, the delay imposed upon MNN-CN communicationwill increase due to routing all traffic via the home agent.For this reason Mobile IPv6 provides a Route Optimization(RO) mechanism that allows to route packets on a direct pathbetween mobile node and correspondent node, bypassing thehome agent. For the NEMO protocol no RO mechanism isavailable up to now.

B. The Need For Route Optimization (RO)

For the aeronautical application of the NEMO protocol, thedelay imposed by routing all traffic via the home agent can besignificant. As one of the worst case scenarios, we can assumean aircraft flying above Europe and communicating with anear ATS correspondent node while using a home agent inAsia. This is a typical example for an Asian airline, where alatency of about 300 ms is imposed upon every single packetexchanged 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 andAsia).Apart from delay, the sub-optimal routing of packets over

different continents is also inefficient. In addition, the homenetwork in general and the home agent in particular becomea single point of failure. In case of problems with one ofthese, routing between the communication peers becomesimpossible.



Summarized, the benefits 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 protocoland provide these properties.In the following, the second part of this paper, we will

perform an analysis of different NEMO RO protocols. Forthis purpose we introduce specific NEMO RO requirements.Afterwards the different protocols are analyzed with regard tothese requirements.First however, we will provide an overview of the Mobile

IPv6 Route Optimization procedure that is applicable formobile hosts only. It will help show the general problemsassociated with performing route optimization.

C. Mobile IPv6 Route Optimization (MIPv6 RO)

Mobile IPv6 RO allows routing packets on a direct pathbetween Mobile Node (MN) and correspondent node. Thedesign of this mechanism was driven by security requirementsand based on the limitation that it should be applicableto nodes in the public Internet where no pre-existing trustrelationships could be assumed. More information on thebackground 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 aBinding Update (BU) with its home agent to bind its localCare-of Address (CoA) to the Home Address (HoA).

• The MN receives a Binding Acknowledgement (BA)from the home agent and establishes a bi-directionaltunnel with the home agent. Home Registration is nowfinished and the MN can also initiate RO to the CN(s)now.

• RO starts with the Return Routability procedure thatprovides proof that the MN is reachable and thereforethe owner of both the CoA and the HoA. The MN sendsa Care-of Test Init (CoTI) message directly to the CN.An additional Home Test Init (HoTI) message is sentby the MN via the home agent to the CN. The CNresponds with each a Care-of Test (CoT) and Home Test(HoT) message, the latter routed via the home agent. Bothresponses contain cryptographic keys for the MN.

• The RR procedure is finished as soon as the MN receivesboth care-of test and home test message. The keys fromthe two messages are combined into a single shared secretkey. This shared key is then used to generate a hash-basedmessage authentication code (HMAC) that is calculatedover and attached to the BU to the CN. The CN, uponreception of the BU, validates the HMAC and respondswith a BA.

• As soon as the MN receives the BA from the CN, theRO procedure is completed and traffic can be directlyexchanged between MN and CN, therefore avoidingrouting via the HA.

The Return Routability procedure does not protect against ”on-path attackers” that reside on the path between the HA and theCN. This attacker must have the capability of eavesdropping

BUBA

Hom

eR

egistration

HoTI

HoT[Key_2]

Correspondent R

egistrationR

eturn R

outability

CoTICoT[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 inpossession of the cryptographic key included in the home testmessage and use it in various attacks [39], [40].

D. Requirements For Aeronautical NEMO RO

In the following we are specifying the critical requirementsthat have to be fulfilled by a candidate NEMO RO solu-tion. This list builds on the already available requirementsfrom [41].The requirements are as follows:

1) Separability: it should be possible to apply RO only toflows that really require it. For example, RO should onlybe activated for all traffic originating from one specificMNN, whereas traffic from other MNNs is routed overthe home agent.

2) Multihoming: the RO mechanism must be fully usable ifseveral interfaces are present. More precisely, it shouldbe possible to forward a route-optimized traffic flow viaa particular interface/path.

3) Efficient 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 theBU must be able to validate the aircraft as proper ownerof both the claimed care-of address and mobile networkprefix. Vulnerability to on-path attackers as in MIPv6RO 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 categoriesthat are defined 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



��

��

��

��

��

(a) MNN to CN

��

��

��

��

��

(b) MR to CN

��

��

��

��

��

��

(c) MR to CR

��

��

��

��

� � ��

��

(d) MR to HA

Fig. 9. The four different route optimization classes.

We will only give a short overview on these categories in thefollowing. A more thorough discussion on the advantages anddisadvantages of the four individual solution classes can befound in [42] or [43]. Our main contribution is the assessmentof these solutions with regard to the requirements specified inSection IV-D.Mobile Network Node to Correspondent Node: an exam-

ple for this approach is [44]. The mobile router exposes theprefixes advertised by its own access router(s) to the MNNs.The end-systems then form their own care-of addresses andperform RO in the standard MIPv6 fashion themselves. Theproblems with this approach is overhead, as signaling takesplace between every (MNN, CN) pair. Another problem is howMNNs can make use of multiple paths off the mobile networkfrom the MR (multihoming). Also, the access network hasto accept every MNN address as source address for packets,something that may not be supported if the outgoing interfaceat the MR supports having only a single IP address. Securityproblems are also present as standard MIPv6 RO is used(cf. Section IV-C). Obviously, it would also be necessary toupgrade the MNN protocol stack with mobility extensions. Anadvantage of this category is that the RO path is the optimalone with direct routing between MNN and CN.Mobile Router to Correspondent Node: within this class,

the mobile router performs all mobility signaling on behalf ofthe MNN. Several proposals exist [45], [46]. The signalingoverhead is reduced to (MR,CN) pairs when compared tothe previous category. An issue of this approach though areproblems related to reusing standard MIPv6 RO signalingbetween MR and CN, which suffers from the on-path attackerproblems (cf. Section IV-C). Problems arise with end-to-endintegrity: if the MR performs actions on behalf of the MNNand modifies user packets, it could be regarded as man-in-the-middle attacker by end-to-end security protocols used betweenMNN and CN (e.g. IPsec). The advantage is that the routing

path is also optimal: the MNN will be directly attached to theMR, from where packets are routed to the CN on the directpath.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. Themobile router performs mobility signaling with the CR andestablishes a bi-directional tunnel that is used to exchangetraffic between the mobile network and the network servedby the CR. Signaling overhead is limited to (MR, CR) pairs,but the signaling itself is based on standard MIPv6 RO withits security limitations. The advantage is a good scalability asseveral CNs can be served by a single CR. Also, multihomingwith 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 tohaving multiple, geographically and topologically distributedhome agents. The proposal is called Global HA-to-HA [48].While multihoming can be supported with [26], [27], theMR always binds with a single HA. Simultaneously routingdifferent flows via different HAs is therefore not possible. Theadvantages are that both signaling overhead (efficiency) andsecurity are very similar to the basic NEMO protocol, whichhave been graded as completely fulfilled (cf. Table I).

F. Grading Of RO Requirements

The property Separability is completely fulfilled (⊕⊕) bythe MNN-to-CN class and sufficiently fulfilled (⊕) by theother approaches. The reason for the reduced grading is theinability of the MR to perform traffic flow identification incase an end-to-end security protocol with confidentiality isused, as protocol header fields are not readable anymore forthe MR.The property Multihoming is either completely (⊕⊕), suf-

ficiently (⊕) or not fulfilled at all (�). Sufficiently refers tothe fact that traffic can be routed via different interfaces atthe MR, but that data still converges at and gets forwarded bythe same home agent. This requirement can not be fulfilledwithout problems by MNN-based RO approaches because ofproblems related to sharing the care-of address: in case onlyone care-of address is available on an outgoing interface at theMR, this address would have to be shared among the MR andthe MNNs. This requires NAT-like behavior, posing problemsas described in [11].Efficient signaling ranges from very bad (��) up to very

good (⊕⊕), depending on the number of nodes involved inmobility signaling.The security requirement has been either fulfilled (⊕⊕) or

not fulfilled (�).The grading of the property adaptability is as follows: it is

either not fulfilled (�) because of problems with preservingend-to-end integrity or completely fulfilled (⊕⊕) because theoriginal payload is preserved due to tunneling encapsulation.It is also possible to sufficiently fulfill (⊕) this requirementin case end-to-end traffic is modified but no problems shouldbe caused because the end-systems are performing RO them-selves.



TABLE IIOVERVIEW 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 HASeparability ⊕⊕ ⊕ ⊕ ⊕Multihoming � ⊕⊕ ⊕⊕ ⊕Efficient Signaling �� ⊕ ⊕⊕Security � � � ⊕⊕Adaptability ⊕ � ⊕⊕ ⊕⊕

G. Conclusion

A summary of the individual pros and cons is provided inTable II. It shows the problems of the first two approaches andthe strengths of the latter two, especially for the MR-to-HAclass. The first two approaches suffer from several problems,most notably security and also efficiency since signaling isperformed individually either for every CN or MNN. The thirdsolution 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 fulfill all requirements. Thisidentifies it as the most promising approach among all thestudied 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 viatunnels.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 inclose distance to the mobile router, a binding with a distanthome 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 overthe public Internet. As mobility signaling is only performedbetween mobile router and home agent, both MNNs and CNsremain unaffected. In fact, the mobility protocol is completelytransparent to these end-systems and they do not require anymobility extensions.

V. SUMMARY

We provided an overview of the peculiarities of the aero-nautical communications environment with its different serviceclasses and discussed why a protocol to support mobility isactually needed. The focus of our survey was on supportingsafety-related services (ATS/AOC) within the ATN, althoughwe also introduced a requirement to cover the applicability tonon-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 thespecific aeronautical requirements that we introduced. The

conclusion was that NEMO is capable of fulfilling morerequirements ”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 traffic between the aircraft and theground communication peers is routed via the home agent. Wetherefore surveyed a number of protocols that extend NEMOto solve the Route Optimization problem. Having assessedthe individual protocols with regard to a dedicated set of ROrequirements, it turned out that the Global HA-to-HA protocolfulfills all requirements.An IP mobility architecture based on NEMO in conjunction

with Global HA-to-HA could not only provide mobility forthe safety-related ATS and AOC services within the ATN,but is also applicable to the AAC and APC domains in thepublic Internet. With Global HA-to-HA, mobility extensionsonly have to be implemented in the network stacks of themobile router and within the home agents. The end-systems,both on the aircraft and on the ground, can have standard IPstacks and therefore remain mobility agnostic.

VI. OUTLOOK

While appealing from many aspects, there still remains anopen issue with regard to the Global HA-to-HA protocol: thelocation information of mobile nodes has to be synchronizedbetween all home agents. As also mentioned in [49], it remainsto be clarified how well this scales with an increased numberof 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 routingto the home network and its home agents is broken, theend-systems on-board the aircraft are unable to communi-cate anymore. Furthermore, if not sufficient home agentsare distributed all over the world, route optimization is notproperly addressed anymore. The end-to-end latency problemthen reemerges.In the future, additional work should therefore focus on an

additional route optimization component that addresses thisproblem. Table II shows that a correspondent router-basedapproach can fulfill most of the requirements. The protocolhas to be improved by addressing the weak aspect of securitythough.In the course of modifying the correspondent router protocol

it should be properly designed to provide route optimizationwithout any home agent interaction. The approach wouldtherefore have to be different from Mobile IPv6 RO wherethe home agent is an integral part of the signaling (cf. Sec-tion IV-C). Removing this dependency (exchange of signalingmessages via the home agent) will make the RO componentindependent from the home network. As a consequence, RO



��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Fig. 10. Mobility architecture for the ATS/AOC domains.

can be performed and retained in the presence of home agentor 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 thehandover. This can become necessary with the transmissionof on-board sensor data to the ground or the usage of Voiceover 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 hasto be expected for network mobility as the the large numberof on-board end-systems also produce a larger number of dataflows. While it has been shown that significant improvementscan be achieved [52], more investigations will be needed.

ACKNOWLEDGMENT

The authors would like to thank Thomas Gamer and SerkanAyaz for related discussions and comments that helped toimprove the quality of this manuscript.

REFERENCES

[1] International Civil Aviation Organization, “Manual for the ATN usingIPS Standards and Protocols (Doc 9896),” February 2009, 1st edition,Unedited Advance version.

[2] Single European Sky ATM Research (SESAR), “European Air TrafficManagement Master Plan,” March 2009, edition 1.

[3] I. Guardini, E. Demaria, and M. L. Monaca, “Mobile IPv6 deploymentopportunities in next generation 3GPP networks,” in 16th IST Mobileand 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 (ITST2007), Sophia Antipolis, France, Jun. 2007, pp. 375–389.

[5] Eurocontrol/FAA Future Communication Study, “Communications Op-erating Concept and Requirements for the Future Radio System,” May2007, 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. WirelessLAN Medium Access Control (MAC) and Physical Layer (PHY)Specifications,” IEEE Std 802.11-2007, pp. C1–1184, 2007.

[8] “IEEE Standard for Local and metropolitan area networks. Physicaland Medium Access Control Layers for Combined Fixed and MobileOperation in Licensed Bands,” IEEE Std 802.16e-2005, pp. 1–822, 2006.

[9] DLR, “Expected B-AMC System Performance,” September 2007, reportD5.

[10] B. Korn, C. Edinger, D. Kugler, T. Putz, O. Hassa, and B. Mohrhard,“Is Sectorization Really Required For Efficient En-Route Air TrafficControl?” in CEAS 2009 European Air and Space Conference, October2009.

[11] A. Muller, G. Carle, and A. Klenk, “Behavior and classification of NATdevices and implications for NAT traversal,” IEEE Network, vol. 22,no. 5, pp. 14–19, 2008.

[12] D. Le, X. Fu, and D. Hogrefe, “A review of mobility support paradigmsfor the Internet,” IEEE Commun. Surveys and Tutorials, vol. 8, no. 1-4,pp. 38–51, 2006.

[13] E. Perera, V. Sivaraman, and A. Seneviratne, “Survey on networkmobility support,” SIGMOBILE Mob. Comput. Commun. Rev., vol. 8,no. 2, pp. 7–19, 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. Garcıa-Martınez, J. Rodrıguez, and A. Azcorra, “Thecase for source address dependent routing in multihoming,” in Qualityof Service in the Emerging Networking Panorama: Fifth InternationalWorkshop on Quality of Future Internet Services (QofIS), 2004, pp.237–246.

[18] K. Butler, T. Farley, P. McDaniel, and J. Rexford, “A survey of BGPsecurity issues and solutions,” Proc. IEEE, vol. 98, no. 1, pp. 100–122,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. 582–592, April2000.



[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, “NetworkMobility (NEMO) Basic Support Protocol,” RFC 3963, Jan. 2005.

[25] D. Johnson, C. Perkins, and J. Arkko, “Mobility Support in IPv6,” RFC3775, 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-flow-binding-04, Nov.2009. [Online]. Available: http://tools.ietf.org/html/draft-ietf-mext-flow-binding-04

[28] V. Devarapalli and F. Dupont, “Mobile IPv6 Operation with IKEv2 andthe 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 supportfor continuous operation,” in Proc. the International Conference onNetwork Protocols (ICNP). Washington, DC, USA: IEEE ComputerSociety, 1997, p. 229.

[31] K. Brown and S. Singh, “M-UDP: UDP for Mobile Networks,” in ACMComputer Communication Review, 1996, pp. 60–78.

[32] R. Stewart, “Stream Control Transmission Protocol,” RFC 4960, Sep.2007.

[33] R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, and M. Kozuka, “StreamControl Transmission Protocol (SCTP) Dynamic Address Reconfigura-tion,” RFC 5061, Sep. 2007.

[34] R. Stewart, M. Tuexen, and G. Camarillo, “Security Attacks FoundAgainst the Stream Control Transmission Protocol (SCTP) and CurrentCountermeasures,” 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 Applicationsand the Internet Workshops (SAINT’03 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 overIPv4 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 Evaluationof a Novel HIP-Based Network Mobility Protocol,” Journal of Networks(JNW), vol. 3, no. 1, pp. 10–24, 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 version6 (mipv6) route optimization security design,” in Vehicular TechnologyConference. 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 SpaceExploration Mobile Networks,” RFC 5522, Oct. 2009.

[42] A. Shahriar, M. Atiquzzaman, and W. Ivancic, “Route optimizationin network mobility: Solutions, classification, comparison, and futureresearch directions,” IEEE Commun. Surveys Tutorials, vol. 12, no. 1,pp. 24 –38, first 2010.

[43] H.-J. Lim, M. Kim, J.-H. Lee, and T.-M. Chung, “Route Optimizationin Nested NEMO: Classification, Evaluation, and Analysis from NEMOFringe Stub Perspective,” IEEE Trans. Mobile Comput., vol. 8, no. 11,pp. 1554–1572, 2009.

[44] C. Ng and J. Hirano, “Securing Nested Tunnels Optimizationwith 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. 1702–1716, 2006.

[46] C. Kim, Ed., S-RO: Simple Route Optimization Scheme with NEMOTransparency, ser. Lecture Notes in Computer Science, vol. 3391.Springer, 2005.

[47] R. Wakikawa., S. Koshiba, K. Uehara, and J. Murai, “ORC: OptimizedRoute Cache Management Protocol for Network Mobility,” in IEEE10th International Conference on Telecommunication (ICT), 2003, pp.119–126.

[48] R. Wakikawa, G. Valadon, and J. Murai, “Migrating home agentstowards internet-scale mobility deployments,” in CoNEXT ’06: Proc.2006 ACM CoNEXT conference. New York, NY, USA: ACM, 2006,pp. 1–10.

[49] L. Zhang, R. Wakikawa, and Z. Zhu, “Support mobility in the globalinternet,” in MICNET ’09: Proc. the 1st ACM workshop on Mobileinternet through cellular networks. New York, NY, USA: ACM, 2009,pp. 1–6.

[50] G. Xie, J. Chen, H. Zheng, J. Yang, and Y. Zhang, “Handover Latencyof MIPv6 Implementation in Linux,” in Global TelecommunicationsConference. IEEE GLOBECOM., 2007, pp. 1780–1785.

[51] M.-J. Yang, K.-Y. Cheon, A.-S. Park, Y.-H. Choi, and S.-H. Kim,“Seamless Handover Using FMIPv6 with Effective Tunnel ManagementScheme,” in Global Telecommunications Conference. IEEE GLOBE-COM., November 2008, pp. 1 –5.

[52] H. Petander and E. Perera, “Measuring and improving the performanceof network mobility management in IPv6 networks,” IEEE J. Sel. AreasCommun., vol. 24, pp. 1671–1681, 2006.

Christian Bauer received the BS and MS degrees in computer science fromthe University of Innsbruck, Austria, in 2004 and 2006 respectively. Currentlyhe is a a researcher at the Institute of Communications and Navigation atthe German Aerospace Center (DLR). His research interests are in the areaof networking protocols and their application in the area of aeronauticalcommunications, with a special emphasis on IPv6, mobility and handovermanagement as well as security.

Martina Zitterbart is full professor in computer science at UniversitatKarlsruhe (TH). From 1987 to 1995 she was research assistant in Karlsruhe,receiving her doctoral degree in 1990. From 1991-1992 she was on leaveof 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 TechnicalUniversity of Braunschweig (1995-2001). Her primary research interests arein the areas of multimedia communication systems, mobile and ubiquituouscomputing, ambient technologies as well as wireless sensor networks. She ismember of the IEEE, ACM and the German Gesellschaft fur Informatik. In2002, Martina Zitterbart received the Alcatel SEL research award on technicalcommunication. In 2003, she was General Co-Chair of the ACM SIGCOMMconference which was held in Karlsruhe.


a survey of protocols to support ip mobility in

Documents

streamcontrol

remain mobility

host identity

single mobile

border gateway

metropolitan

ip address

internet key