a survey of protocols to support ip mobility in aeronautical ommunications

8/3/2019 A Survey of Protocols to Support IP Mobility in Aeronautical Ommunications

1/16

642 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 13, NO. 4, FOURTH QUARTER 2011

A Survey of Protocols to Support IP Mobility inAeronautical Communications

Christian Bauer and Martina Zitterbart

AbstractThe 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 TermsAircraft, Mobility, IPv6, Mobile IP, NEMO

I. INTRODUCTION

THE COMMUNICATION infrastructure currently usedfor civil aeronautical communications is based on ananalogue voice system that can neither cope with the expected

increase in air traffic nor support the envisaged paradigm shift

towards data or packet oriented communications. The digital-

ization effort is supposed to free-up the currently congestedanalogue voice based system and to increase operational

efficiency.

For these reasons, a working group at the International CivilAviation Organization (ICAO) recently defined 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-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 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 sufficient 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 solutioncompared to proprietary protocol solutions.

A typical ATN scenario, is an inter-continental flight from

Europe to Northern America. Throughout the complete flight

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: [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 satellite

technologies when over the Atlantic. A general picture of

this situation is shown in Fig. 1. In addition, the velocityof 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 traffic control information. Availability and security

of 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 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/11/$25.00 c 2011 IEEE


2/16

BAUER a nd ZITT ERBART: A SURV EY OF PROTOCOLS TO SUPPORT IP MOB IL IT Y IN AERONAUTICAL C OMMUNICATIONS 64 3

Section II provides an overview of the aeronautical en-

vironment, explains why mobility is actually needed and

specifies the mobility requirements that have to be satisfied

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 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 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 finally conclude with identifying the set of protocols that

can sufficiently fulfill all the requirements of the aeronauticalenvironment. 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 defined 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 covereddistance is smaller than that of an aircraft - the inflicted delay

is 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: 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 Traffic Services (ATS) covers all communication be-

tween the cockpit (the mobile node) and the controller on the

ground (fixed node) for providing navigational support and

air traffic control communications. The applications within

this service class are critical to the safety of the flight. The

fixed ATS communication peer on the ground is called ATSCorrespondent 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: AirlineOperational Communications (AOC) and Airline Administra-

tive Communications (AAC). AOC consists of services that are

regarded as safety-related, e.g. flight 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 communicationpeer on the ground is called AOC/AAC CN. Usually up to

three 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. The

correspondent nodes are usually located in the public Internetand 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 areavailable. 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 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

specific 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


3/16


4/16


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 addresses

available at the airborne router among all end-systems, but

causes problems as discussed in [11], e.g. with end-to-endsecurity 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 fixed 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 technologyenvironment 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 fulfilled 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 prefix.Several end-system (MNNs) are attached to this airborne

router.The inherent requirements that must be completely fulfilled

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 beprovided for a single mobile host, but for a complete on-

board network. More specifically, instead of providing

a constant IP address (as the case for the previous

requirement) one or several constant network prefixes

should be provided.

Session continuity is automatically fulfilled by all mobilityprotocols investigated later. It is therefore not mentioned

anymore 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 terrestrial

network). This requirement covers both load-balancing

and fault-tolerance. The latter addresses the important

issue of reliability/availability: in case of failure ofone 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/prefixes 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 specific delay re-quirements have been introduced in Section II-B.

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


5/16


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: 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 that

popular, frequently visited web servers in the public

Internet will upgrade their protocol stacks with mobility

extensions.

Secondary requirements are desirable and their fulfillment is

a bonus:

1) Efficiency 1: the overhead incurred by the mobility

protocol 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 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 influenced by the number of

exchanged signaling messages as described by Efficiency

1, 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 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 specifies 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, addressesan 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 specific.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 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 five

different 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 the

examples 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 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 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 a

mobile environment.

The Border Gateway Protocol Version 4 (BGPv4) [15] isthe inter-domain routing protocol mainly used in the Internet.

BGP is used between autonomous systems for exchanging

information on routing paths to specific destination prefixes.

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 ondynamic 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 prefix 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 prefix of that aircraft

while the new ground station will start announcing the aircraftprefix from its own AS. Packets destined to the aircraft are

then routed to the new AS/ground station.


6/16


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 to

route dampening, causing the route in question to not be

accepted anymore nor advertised to neighbors by other BGProuters. 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 shortertime intervals dampening does occur. As handovers between

terrestrial 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 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 prefix (for example an IPv4-based /24 asin [16]) that is always announced by the current base station

of the aircraft. This requirement is therefore fulfi

lled, 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 of

a single IP address.

Multihoming (primary): BGP multihoming is an estab-

lished technique in the fixed Internet. However, this form

of 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 of

packets into the routing decision [17], the problem of routing

specific traffic flows (e.g. based on the used transport protocol

and port numbers) still remains unsolved.

Security 1 (primary): the problems of BGP with respectto security have been thoroughly investigated [18]. One of

the key problems is that BGP routers can advertise prefixes

that do not even belong to them an attacker can advertise a

prefix owned by someone else and therefore attract the traffic

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 certificates that

authorize 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 the

certificate, 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 memoryconsumption. 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 prefixes. The exact

meaning of shortest-path is defined 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 BGProuting 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 thereforecause 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.

Efficiency 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 prefix to the ground station,which then performs BGP announcements on behalf of the

aircraft. Another option, different from [16], would be to putthe 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.

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 aircraft

prefix, a route to the aircraft becomes available and traffic

would be properly routed to the aircraft.

B. IPsec

IPsec [20] is a well known protocol providing confiden-

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-

tifiers 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


7/16


!"

#$

%

&

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

on either pre-shared secrets, certificates 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 differentnetwork and configures 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 theIP address of a SA and to signal this change to the security

gateway. 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 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 theassignment of a static, fixed IP address from the gateway.Traffic 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 traffic via the IPsec tunnel to the mobile nodes newlocation, the care-of address (CoA). The CoA is the IP address

that the airborne router configures in the new access network(in Fig. 4 the CoA is first 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, theairborne router could request a network prefix from the

gateway (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 usedifferent network interfaces, it is limited to using them in

a sequential way. Using several interfaces simultaneously to

route different data flows over different interfaces is not

supported.

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 that

the gateway forwards traffic to the correct airborne router.

Security 2: a vulnerability of IKE are CPU-exhaustion

attacks. The protocol defines 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 infrastructuretherefore remain unchanged. The gateway or another BGP

speaker in the gateway network only has to advertise a singleaggregated prefix 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 transparentlytunnels all traffic to the security gateway.

Convergence time: when the airborne router moves to adifferent network, it notifies the gateway of its new address. As

data is always routed via the security gateway, the successful

completion of this notification ensures that data is immediately

routed to the new location. This is achieved with help of the

static, fixed IP address or prefix.Efficiency 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.Efficiency 2: the use of IPsec usually implies integrity

protection and allows for additional encryption. Even if no

cryptographic algorithms are specified, the additional headersincrease the overhead for every payload packet. In addition to

that, the overhead of a complete IP header is added to everypayload 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 notified

by 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 concept

of a mobile node to that of a Mobile Router (MR) with one or

several mobile network prefixes. As soon as the MR attachesto 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 traffic 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. Traffic 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


8/16


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 configure

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 specified in [26]. In ad-

dition, [27] specifies a policy exchange protocol that can beused to setup forwarding rules for certain traffic flows, taking

into account the additional care-of addresses. Detailed traffic

selectors can be used to identify a flow, based on IP or higher

layer protocol fields 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 traffic flows 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 traffic 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 tablesremain unchanged as the Home Network is always advertising

an 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 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 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 inflicts

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 traffic is always

routed via the home agent. As the MR signals its care-of

address(es) to the HA, this traffic can be forwarded to theMRs current location.

D. SCTP

The problem of mobility is directly impacting the transport

layer, where active sessions break due to the usage of theIP address as an identifier. 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 specification allows specifying

several IP addresses during connection setup time only. This

limitation 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 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 adifferent network where it configures 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 wasto 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 primaryaddress) 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

traffic of a mobile node.

Security 2: there do exist vulnerabilities within SCTP

that can be exploited to send large volumes of unwanted

traffic 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 andsend all traffic to it. These attacks can be either mitigated

or the probability to successfully mount an attack at least be


9/16


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 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 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.

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 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 theunknown current location (care-of address) of the mobile node.

E. HIP

Another, more radical, approach for supporting mobility is

the locator-identifier 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 identifiers within this namespace are globally unique and

associated 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 on

these 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 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 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 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 MNperforms a DNS lookup and thereby retrieves the address of

the 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 stackis 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 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

traffic of a node.

Security 2: There is a limited vulnerability to memory

and computational exhaustion attacks where an attacker floods

a HIP-enabled node with a large amount of HIP signalingmessages.

End-to-end delay: traffic is exchanged directly betweencommunication peers. End-to-end delay therefore corresponds

to the shortest route between the two peers.

Scalability: HIP does not modify the routing system butinstead introduces a new identifier space. Scalability issues

are 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 network

support.


10/16


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 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.Efficiency 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.Efficiency 2: as HIP uses IPsec to exchange traffic 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. Thisonly 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 regardto number of DNS entries, is linear with the number of mobilenodes.

F. Summary

The discussion of all the various protocols shows that

there is no optimal solution that is capable of fulfilling all

requirements out of the box. In the following, we provide a

summary of how the requirements are graded and discuss how

they are fulfilled 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 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 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 fixed 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

prefixes. 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 individualentries for mobile nodes in BGP tables that have to be present

in every BGP router in the routing core.

Applicability to AAC/APCis 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 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 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 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 difficulties for alreadyexisting 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 fulfill one primary

requirement.

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 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 fulfill one inherent, three primary and one

secondary requirement.

BGP has problems with providing multihoming on a per-flow granularity level. While S-BGP raises security to an

acceptable level, there might be reasons for concern with


11/16


12/16


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 protocol

and provide these properties.

In the following, the second part of this paper, we willperform an analysis of different NEMO RO protocols. For

this purpose we introduce specifi

c 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

finished 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 finished as soon as the MN receivesboth care-of test and home test message. The keys from

the two messages are combined into a single shared secretkey. 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, theRO procedure is completed and traffic can be directly

exchanged 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 the

CN. This attacker must have the capability of eavesdropping

BU

BA

Home

Registration

HoTI

HoT[Key_2]Correspondent

Registration

R

eturn

Ro

utability

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 requirementsthat have to be fulfilled 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 toflows that really require it. For example, RO should only

be activated for all traffic originating from one specific

MNN, 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 should

be possible to forward a route-optimized traffic flow via

a 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 the

BU must be able to validate the aircraft as proper owner

of both the claimed care-of address and mobile network

prefix. 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 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


13/16


(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 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 specified inSection IV-D.

Mobile Network Node to Correspondent Node: an exam-

ple for this approach is [44]. The mobile router exposes the

prefixes 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 takes

place between every (MNN, CN) pair. Another problem is howMNNs 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. Anadvantage 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 modifies 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 exchangetraffic 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 tohaving 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 flows via different HAs is therefore not possible. Theadvantages are that both signaling overhead (efficiency) andsecurity are very similar to the basic NEMO protocol, which

have been graded as completely fulfilled (cf. Table I).

F. Grading Of RO Requirements

The property Separability is completely fulfilled () by

the MNN-to-CN class and sufficiently fulfilled () by theother approaches. The reason for the reduced grading is the

inability of the MR to perform traffic flow identification in

case an end-to-end security protocol with confidentiality is

used, as protocol header fields are not readable anymore for

the MR.

The property Multihoming is either completely (), suf-

ficiently () or not fulfilled at all (). Sufficiently refers to

the fact that traffic can be routed via different interfaces atthe MR, but that data still converges at and gets forwarded by

the same home agent. This requirement can not be fulfilled

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].

Efficient signaling ranges from very bad () up to verygood (), depending on the number of nodes involved in

mobility 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 preserving

end-to-end integrity or completely fulfilled () because the

original payload is preserved due to tunneling encapsulation.

It is also possible to sufficiently fulfill () this requirement

in case end-to-end traffic is modified but no problems shouldbe caused because the end-systems are performing RO them-

selves.


14/16


TABLE IIOVERVIEW OF THE CHARACTERISTICS OF THE INDIVI DUAL SOLUTION CLASSES. R EQUIREMENTS CAN BE EITHER F ULFILLED (), 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 in

Table II. It shows the problems of the first two approaches and

the strengths of the latter two, especially for the MR-to-HA

class. The first two approaches suffer from several problems,most notably security and also efficiency since signaling is

performed 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. This

identifies 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 homenetwork 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 theapplicability 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 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, althoughwe also introduced a requirement to cover the applicability to

non-safety related services (AAC/APC).

We investigated a number of protocols that can be usedto provide IP mobility and assessed them with regard to the

specific aeronautical requirements that we introduced. The

conclusion was that NEMO is capable of fulfilling 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 traffic between the aircraft and theground communication peers is routed via the home agent. We

therefore surveyed a number of protocols that extend NEMOto 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

fulfills 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 the

public Internet. With Global HA-to-HA, mobility extensionsonly 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 synchronizedbetween all home agents. As also mentioned in [49], it remainsto be clarified 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 routingto 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 sufficient 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 thisproblem. Table II shows that a correspondent router-basedapproach can fulfill most of the requirements. The protocol

has 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 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 signalingmessages via the home agent) will make the RO component

independent from the home network. As a consequence, RO


15/16


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 theused 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 dataflows. While it has been shown that significant 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 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. 375389.

[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. C11184, 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. 1822, 2006.

[9] DLR, Expected B-AMC System Performance, September 2007, report

D5.[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. 1419, 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. 3851, 2006.

[13] E. Perera, V. Sivaraman, and A. Seneviratne, Survey on networkmobility 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-Mart nez, J. Rodrguez, and A. Azcorra, Thecase for source address dependent routing in multihoming, in Qualityof 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 BGPsecurity 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, April2000.


16/16


[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 on

Network 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. 6078.

[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 (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 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. 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 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 Space

Exploration 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. 15541572, 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. 17021716, 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.119126.

[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. 110.

[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. 16.

[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. 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 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. 16711681, 2006.

Christian Bauer received the BS and MS degrees in computer science fromthe University of Innsbruck, Austria, in 2004 and 2006 respectively. Currently

he 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 ubiquituous

computing, 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 aeronautical ommunications

Documents