Vous êtes sur la page 1sur 16

IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION 1

A Survey of Protocols to Support IP Mobility in


Aeronautical Communications
Christian Bauer and Martina Zitterbart
AbstractThe aviation industry is currently at the beginning
of a modernization phase regarding its communication systems.
This involves a transition to IP-based networks for Air Traf-
c Control and Airline Operational Communications. Due to
the heterogeneous nature of the communication environment,
support for mobility between different access technologies and
access networks becomes necessary. We rst introduce the
aeronautical communications environment and present domain
specic requirements. The main part of this article is a survey
of different protocols that can be used to solve the IP mobility
problem within the aeronautical environment. These protocols
are assessed with regard to the introduced requirements. We
conclude with the identication of a particular protocol as the
most suited solution and also identify areas for further work.
Index TermsAircraft, Mobility, IPv6, Mobile IP, NEMO
I. INTRODUCTION
T
HE COMMUNICATION infrastructure currently used
for civil aeronautical communications is based on an
analogue voice system that can neither cope with the expected
increase in air trafc nor support the envisaged paradigm shift
towards data or packet oriented communications. The digital-
ization effort is supposed to free-up the currently congested
analogue voice based system and to increase operational
efciency.
For these reasons, a working group at the International Civil
Aviation Organization (ICAO) recently dened a standard [1]
specifying the future IP-based Aeronautical Telecommuni-
cations Network (ATN/IP). This global inter-network will
be based on IPv6 and will be deployed for ground-ground
networks, air-ground access networks and on the airborne
(on-board) network itself. The Internet Protocol IPv6 has
been chosen as the basis for the ATN as it (a) is a widely
used industry standard in telecommunications, (b) is actively
maintained and extended by the responsible standardization
organization, the Internet Engineering Task Force (IETF),
and (c) provides sufcient address space for a world-wide
deployment in every national state and aircraft. In addition, it
is also expected that IP provides a more cost-effective solution
compared to proprietary protocol solutions.
A typical ATN scenario, is an inter-continental ight from
Europe to Northern America. Throughout the complete ight
duration from departure to destination airport, the aircraft
has to perform handovers among different access networks:
Manuscript received 25 May 2010.
C. Bauer is with the Institute of Communications and Navigation, German
Aerospace Center (DLR) (e-mail: christian.bauer@dlr.de).
M. Zitterbart is with the Institute of Telematics, Karlsruhe Institute of
Technology (KIT) (e-mail: martina.zitterbart@kit.edu).
Digital Object Identier 10.1109/SURV.2011.111510.00016
Communication
Peer
Communication Path
Short-range tech.
Long-range
tech.
Satellite tech.
Fig. 1. Scenario of aeronautical communications over different access
technologies and networks.
short-range terrestrial technologies at the airport, long-range
terrestrial technologies while at cruise altitude and satellite
technologies when over the Atlantic. A general picture of
this situation is shown in Fig. 1. In addition, the velocity
of an aircraft is larger than that of any other vehicle, with
the consequence, that complete continents and different access
networks can be passed in a matter of hours. Also, the com-
munication peers are distributed among large geographical and
topological areas, starting in Europe and ending in Northern
America. Despite these conditions, the routing path between
the aircraft and its ground-based communication peers should
remain optimal, avoiding forwarding between different con-
tinents in order to keep the end-to-end delay as short as
possible. Also, an aircraft is not only a single mobile host,
but includes one or several on-board networks with numerous
end-systems, establishing a need for the mobility of a complete
network. The global system has to simultaneously support at
least hundred thousand of these mobile networks. Finally, the
messages exchanged between the aircraft and its ground peers
include air trafc control information. Availability and security
of these data ows are highly critical.
At the same time, aircraft will not only be a part of the ATN
but also of the public Internet, e.g. to provide passengers with
Internet access.
The remainder of this paper surveys the different solution
options on how to provide IP mobility within the aeronautical
environment.
1553-877X/10/$25.00 c 2010 IEEE
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
2 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION
Section II provides an overview of the aeronautical en-
vironment, explains why mobility is actually needed and
species the mobility requirements that have to be satised
by a candidate mobility protocol. In Section III we investigate
various protocols that can be used provide mobility and
identify their individual strengths and weaknesses. It becomes
apparent that no solution can fulll all requirements though.
We identify a single mobility protocol family as the most
suited one but realize that still one problem remains to be
solved. In Section IV we therefore survey proposals that
address the remaining problem of optimizing the overall end-
to-end latency for that particular protocol family.
We nally conclude with identifying the set of protocols that
can sufciently fulll all the requirements of the aeronautical
environment. Additionally, we identify areas for further work
that can help improve certain weaknesses and resolve open
questions.
According to the aeronautical community [2], the future
(IP-based) ATN should be introduced by the year 2020.
II. THE AERONAUTICAL ENVIRONMENT
We describe the aeronautical communications environment,
the involved stakeholders and the access technologies used, or
foreseen to be used, within the community.
In general, we regard an aircraft as a mobile network
consisting of the airborne router and several end-systems
(Mobile Network Nodes MNNs) that are communicating
with peers on the ground (Correspondent Nodes CNs).
A. Difference To Other Communication Areas
Support for mobility of devices or networks is also required
within other areas. In the following we will explain how the
aeronautical environment differs from those other areas.
Wireless personal communications based on mobile phones,
as dened by the 3rd Generation Partnership Project (3GPP),
make use of IP mobility management as well [3]. The major
differences are that mobile phones are only mobile hosts and
not mobile networks like an aircraft. Mobile phones also have
a lower degree of mobility and a reduced level of security and
availability requirements.
The Car2Car communications environment has to support
several end-systems within a car and thus acts as mobile
network. A major difference of the Car2Car protocol stack, es-
pecially for car-safety applications, is the dual-stack approach
that not only consists of IP but also of dedicated Car2Car
protocols [4]. In addition, the degree of mobility and covered
distance is smaller than that of an aircraft - the inicted delay
is not as high as mobility is usually constrained to a single
continent.
Summarized, the critical aspects within aeronautical com-
munications, in contrast to more conventional areas, are: a
high degree of mobility that could cause delay problems due
to routing over large geographical distances, a need for high
availability and strong security.
B. Service Classes And Applications
There are four different service classes in the aeronautical
environment, each class covering different applications.
Air Trafc Services (ATS) covers all communication be-
tween the cockpit (the mobile node) and the controller on the
ground (xed node) for providing navigational support and
air trafc control communications. The applications within
this service class are critical to the safety of the ight. The
xed ATS communication peer on the ground is called ATS
Correspondent Node (CN). The CN, the aircraft is currently
communicating with, changes over time depending on the ge-
ographical position of the aircraft and the associated national
airspace. Several CNs exist within each countries national
borders, with responsibility dedicated either to airspace in and
around airports or for airspace at cruise altitude.
Airline information systems include communication be-
tween an aircraft and the airlines headquarter or operations
center. This service class is separated into two classes: Airline
Operational Communications (AOC) and Airline Administra-
tive Communications (AAC). AOC consists of services that are
regarded as safety-related, e.g. ight status information (mal-
function reports) or fuel reports. The non-safety related AAC
services include messaging in respect to catering, baggage
handling or duty free sales. An AOC/AAC communication
peer on the ground is called AOC/AAC CN. Usually up to
three such CNs occur during a ight: source and destination
airport as well as the airline operations center.
Finally, Aeronautical Passenger Communications (APC) is
dedicated to passenger communications and entertainment.
The devices within this domain can be administratively con-
trolled by the airline itself (e.g. devices mounted within seats)
or, alternatively, can also be passenger-owned devices. The
correspondent nodes are usually located in the public Internet
and also include corporate Virtual Private Network (VPN)
gateways. Providing a reasonable end-to-end delay to these
nodes is also highly desirable.
At least for ATS and AOC, application requirements are
available. One document [5] provides numbers for bandwidth
consumption and latency requirements for these applications.
Those are quite relaxed though, with the most stringent re-
quirement for routing in the ground network being roughly 340
ms on average (one-way delay for a single application layer
message). The same document also mentions voice latency
requirements that are usually 130 ms for ATS. At the time of
writing it was not yet clear whether Voice Over IP will be
used in the future IP-based ATN for mobile communication.
In case yes, then this stringent requirement will have to be
met.
Collecting and routing on-board sensor data to ground-
based processing systems will also become increasingly im-
portant in the future. Related requirements listed in [6] include
sensors whose data should be transmitted in real-time. No
specic numbers are provided though.
Apart from delay, another important aspect is availabil-
ity [5]: most ATS applications require 99.9%, while for some
it is even 99.99%. This will also have to be supported by the
underlying network infrastructure and associated protocols.
C. Aeronautical Access Technologies
The future ATN will employ different access technologies
(comprising the physical and link layer of the OSI stack) for
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 3
carrying IP-based trafc that makes this network heavily
heterogenous.
At airports standard IEEE 802.11 [7] (Wi) equipment is
already in use for providing wireless connectivity for AAC
communications when the aircraft is standing at the gate.
Also for communications in the airport area an adapted
version of the well known IEEE 802.16e [8] (Mobile WiMAX)
standard will be used. This technology will provide several
Mbit/sec per radio cell for ATS and AOC trafc. Standard
WiMAX can be used to provide connectivity for AAC and
APC.
Most of the ATS trafc over continental areas, as well as
AOC trafc, will be carried by the L-Band Digital Aero-
nautical Communications System L-DACS, a technology that
is currently in development. L-DACS will provide typical
throughput values up to 1.5 Mbit/sec per radio cell with delay
values of 100 ms on the FL
1
and 200 ms on the RL
2
. In
situations with medium congestion 300 ms on the FL and 600
ms on the RL during high congestion phases [9] have to be
expected.
Especially for oceanic, remote and polar regions low earth
orbit (LEO) and geostationary orbit (GEO) satellite systems
will complement the terrestrial technologies. GEO satellites
are known for one-way delay values of 250-300 ms.
The main reason why the provided bandwidth (in terms
of bits/sec) is small compared to personal mobile commu-
nications systems is that only a relatively small amount of
dedicated frequencies can be used for technologies carrying
safety-related data (ATS+AOC).
D. Network Model
The IPv6 based ATN will carry ATS and AOC data and will
be a closed network, not reachable from the public Internet.
The non-safety related AAC and APC trafc is not supposed
to be routed over the ATN these service classes will instead
use the public Internet. The networks and nodes within the
ATN are operated by three different interest groups that we
will introduce in the following. Routing between the different
networks is based on the Border Gateway Protocol (BGP),
the Exterior Gateway Protocol (EGP) also used in the public
Internet. An exemplary gure illustrating the networks and
inter-connections of the different stakeholders is shown in
Fig. 2.
The rst group are the Air Navigation Service Providers
(ANSPs), state owned authorities that are directly responsible
for providing ATS within their national airspace. ANSPs are
operating both networks and end-systems in the ATN. Those
end-systems are the ATS CNs on the ground that aircraft are
exchanging air trafc control instructions with.
ANSPs have the obligation to provide ATS communication
infrastructure within their country, meaning that in the future
they have to provide IPv6 based access networks
3
that aircraft
can attach to within the ANSPs national (airspace) boundaries.
1
Forward Link: Base Station to Mobile Node.
2
Return Link: Mobile Node to Base Station.
3
An access network is an IP network which includes one or more
Access Network Routers that are connected to one or more base sta-
tions/gateways/access points.
There are two possibilities how these access networks can be
established:
The ANSP owns and operates its own access network
that topologically becomes a sub-network of the overall
ANSP network (e.g. ANSP #1 in Fig. 2).
The ANSP can outsource the operation of the access
network to a service provider. The access network is
then topologically a part of the service provider network.
Trafc between this access network and the ANSP is
routed with help of an EGP (e.g. ANSP #2 in Fig. 2).
Aeronautical Communications Service Providers (ACSPs) are
network operators that offer communication services to air-
lines and ANSPs. These service providers can operate the ac-
cess networks for the national ANSPs (e.g, ACSP #1 in Fig. 2).
In addition, they also deploy access networks independently
from ATS dedicated networks for the purpose of providing
transit services for AOC data (e.g. ACSP #2 in Fig. 2).
The third stakeholder are airlines. They are operating
aircraft and AOC/AAC CNs (e.g. AOC CN in the airline
operations network in Fig. 2). Airlines usually have a business
contract with a communication service provider so that their
aircraft can attach to and send AOC trafc over the service
providers access network.
The network and user/operator model explained above
refers to the ATN that only carries safety-related services
(ATS, AOC). The model for non-safety related services, es-
pecially for APC, is different as it is not based on the ATN
these access networks are not provided by the national air
trafc operators nor by the aforementioned ACSPs. Instead,
this is similar to consumer communications where Internet
Service Providers offer connectivity to the public Internet.
E. The Need For Mobility Support
A typical example for ATS communications is an aircraft
communicating with the ATS CN at the airport tower before,
during and after takeoff. The communication session is estab-
lished while connected to the WiMAX-based access network.
While this session remains active between the on-board end-
system and the CN, the aircraft performs a handover to the
L-DACS access network. Due to moving to a different IP
subnetwork, the IP address of the aircraft changes. In order to
preserve the established session in the presence of handovers,
a mobility protocol is necessary. That provides a xed, static
IP address to the higher layers. This property is called session-
continuity.
Another example for the usefulness of session continuity are
low air trafc situations during nights in the future European
airspace, where all ights above France and Germany could
be controlled by only a few controllers of either Germany
or France. This implies that, while performing handovers
between the different access networks in Germany and France,
aircraft always communicate with the same CN. This can also
be the case in the future if a personal controller is assigned
to an aircraft who is responsible for the large durations of a
ight [10].
Another issue is the availability of public IP address space
on the aircraft: on-board end-systems (MNNs) should be
capable of obtaining a public IP address for allowing global
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
4 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION
ANSP #2
w/o access
network
ATS CN
ACSP #1
network
ANSP #1
w/ access
network
ATS CN
Airline
Operations
AOC CN
AOC Communications ATS Communications
ACSP #2
network
Fig. 2. Topology of the ATN. Correspondent Nodes (CNs) are the communication peers of the aircraft. Air Trafc Services (ATS) CNs are controlled
by the Air Navigation Service Providers (ANSPs). The Air Communication Service Provider (ACSP) operates access networks. The Airline Operational
Communication (AOC) CN is the communication end-point for airline related information exchanges.
end-to-end communication. A Network Address Translator
(NAT) would allow sharing the access network addresses
available at the airborne router among all end-systems, but
causes problems as discussed in [11], e.g. with end-to-end
security protocols. Apart from that, session continuity could
not be provided anymore. The future aeronautical mobility
protocol should therefore also provide public IP addresses to
all on-board end-systems.
In normal operations, ATS communication is always
aircraft-initiated. In the future it might become interesting
to provide a controller with the means to contact an aircraft
that has entered controlled airspace but not yet established a
communication session. A xed static IP address space for
the aircraft, independent of the current topological location,
would allow for ground-initiated communications.
Summarized, due to the heterogenous access technology
environment and the different administrative domains (ANSPs
and ACSPs), handovers between different networks will occur.
This implies the need for providing an IP mobility protocol
that permits session continuity, provides public on-board IP
address space and offers the possibility to allow for ground-
initiated communications.
F. Mobility Requirements
In the following we specify inherent, primary and secondary
requirements that have to be fullled by a mobility protocol
used in the aeronautical environment. In the following, the
word aircraft refers to a complete mobile network, consist-
ing of an airborne router and at least one network prex.
Several end-system (MNNs) are attached to this airborne
router.
The inherent requirements that must be completely fullled
by all candidates are as follows:
1) Session continuity: this property provides a constant IP
address for use to higher layer protocols, even in case
of handovers.
2) Mobile Network support: mobility should not only be
provided for a single mobile host, but for a complete on-
board network. More specically, instead of providing
a constant IP address (as the case for the previous
requirement) one or several constant network prexes
should be provided.
Session continuity is automatically fullled by all mobility
protocols investigated later. It is therefore not mentioned
anymore in the nal comparison.
The primary requirements that should all be fullled by the
candidate protocols are as follows:
1) (Mobile) Multihoming: the aircraft should be capa-
ble of routing data simultaneously over different in-
terfaces/paths from the aircraft to the ground (e.g.
stream X via a satellite and stream Y via a terrestrial
network). This requirement covers both load-balancing
and fault-tolerance. The latter addresses the important
issue of reliability/availability: in case of failure of
one interface/path, packets can be routed over another
interface/path.
2) Security 1 (masquerading): an attacker must not be able
to claim the constant addresses/prexes of an aircraft,
e.g. by means of man-in-the-middle attacks.
3) Security 2 (DoS): the mobility protocol itself should not
introduce any new denial of service vulnerabilities.
4) End-to-end delay: the delay between the communication
peers (end systems on the aircraft and the ground)
should be kept minimal. Application specic delay re-
quirements have been introduced in Section II-B.
5) (Routing) Scalability: the impact of the mobility proto-
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 5
col on the global routing infrastructure should be kept
to a minimum, meaning that frequent route announce-
ments/withdrawals for every individual aircraft should
be avoided.
6) Applicability to AAC/APC: species whether the so-
lution is also applicable to non-safety related services.
This indicates whether the protocol stack on the end-
systems has to be modied in order to support mobil-
ity. Especially for the APC domain it is unlikely that
popular, frequently visited web servers in the public
Internet will upgrade their protocol stacks with mobility
extensions.
Secondary requirements are desirable and their fulllment is
a bonus:
1) Efciency 1: the overhead incurred by the mobility
protocol itself should be limited. The number of round-
trip times (RTTs) needed for mobility-related signaling
should therefore be kept minimal.
2) Efciency 2: the overhead imposed upon every individ-
ual packet with payload from the MNNs or CNs should
be limited. The number of additional protocol headers,
needed to support mobility, should therefore be kept
minimal.
3) Convergence time: a new routing path to and from the
mobile network (e.g. because a new interface has been
activated) should become usable for packet forwarding
within the shortest possible amount of time. While
convergence time is also inuenced by the number of
exchanged signaling messages as described by Efciency
1, this requirement is restricted to the time it takes
to propagate the new mobility state throughout the
(routing) system.
4) Support for ground-initiated communications: end-
systems on the ground should be capable of sending
packets to an aircraft they have not yet communicated
with. This means that a routing path to the current
location of an aircraft has to be available for these nodes.
It is preferable to have a single protocol (family) as a
solution for all domains, ATS/AOC/AAC/APC. This is taken
into account by the primary requirement Applicability to
AAC/APC. The reason for this requirement is that, apart from
cost reasons, in the long term, the safety and non-safety related
domains might be handled by a single airborne router.
III. MOBILITY OPTIONS
Protocols for providing IP mobility are also discussed
in [12], [13], with a focus on the aeronautical environment
in [14].
Our investigation is different from the previous ones by (a)
having introduced numerous requirements and (b) by assessing
the protocols based on those requirements. While the work
performed in [14] also species certain requirements, many of
them are high level. In general, we investigate the protocols
and perform our analysis with a higher degree of detail. Also,
the second part of our survey, starting in Section IV, addresses
an important optimization problem that is not covered at all
by [14].
From a general perspective, the mobility problem can be
solved by a solution that is located on the link, network,
transport or application layer.
A solution on the link layer is access technology specic.
As explained in Section II-C, the ATN is a heterogenous envi-
ronment with different technologies. This requires providing
mobility among different technologies, therefore ruling out the
link layer approach and raising the need for a solution located
at least on the network layer.
Application layer solutions require that applications are
made mobility-aware. Apart from the burden imposed on
application developers, another serious problem is with non-
safety related services. All existing airline information systems
would have to be updated. Also, applications on passenger-
owned devices as well as in the public Internet would have
to be modied as well. This rules out the application layer
approach for very practical reasons.
We therefore focussed on protocols between the network
and transport layer for our investigation. We identied ve
different protocols that can be categorized as follows:
Routing protocol based approach (network layer), with
the example of the Border Gateway Protocol.
Tunneling based approaches (network layer), with the
examples of the IPsec and Mobile IP protocol families.
A transport protocol approach, with the example of the
Stream Control Transmission Protocol.
Locater-identier split (between network and transport
layer), with the example of the Host Identity Protocol.
These protocols are investigated in the following. Their suit-
ability to provide routing in the mobile ATN is assessed with
regard to the previously specied requirements.
A. Border Gateway Protocol
While routing protocols are not classical IP mobility proto-
cols, they can nevertheless solve the problem of routing in a
mobile environment.
The Border Gateway Protocol Version 4 (BGPv4) [15] is
the inter-domain routing protocol mainly used in the Internet.
BGP is used between autonomous systems for exchanging
information on routing paths to specic destination prexes.
Routing information is distributed to neighboring routers that
update their routing tables and forward the routing information
to other selected routers.
BGP has already been used in the past for providing (IPv4)
Internet Connectivity to the APC domain via GEO satellites.
This solution approach is presented in [16] and is based on
dynamic homing, in opposite to the more common static
homing used in the Internet.
The operation of this solution is shown in Fig. 3. Each
aircraft receives a /24 prex that is announced via BGP by
the ground station the aircraft is currently attached to. Each
ground station is an autonomous system (AS) with its own
AS number and its own BGP router/speaker. When the aircraft
moves and performs a handover to a different ground station,
the old ground station withdraws the /24 prex of that aircraft
while the new ground station will start announcing the aircraft
prex from its own AS. Packets destined to the aircraft are
then routed to the new AS/ground station.
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
6 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION
BGP Update
X.Y.Z/24
Autonomous
System B
Internet
Autonomous
System A
Handover 1
BGP Withdraw
X.Y.Z/24 2
3
Fig. 3. BGP route announcements by ground stations.
Frequent route announcements and withdrawals lead to
route dampening, causing the route in question to not be
accepted anymore nor advertised to neighbors by other BGP
routers. With a handover occurring only once every 4-8
hours for an aircraft, dampening did not become a problem
according to [16]. However, tests showed that with shorter
time intervals dampening does occur. As handovers between
terrestrial technologies of the ATN are supposed to occur more
frequently then with satellites, this might become a problem.
Another critical aspect of BGP is convergence time. As
mentioned in [16], it took about one minute for the major
backbone networks in the Internet to update their routing
tables according to the new route. The duration for smaller
outlying networks to converge was 30-60 minutes.
Analysis: Session continuity (inherent): the aircraft re-
ceives a constant prex (for example an IPv4-based /24 as
in [16]) that is always announced by the current base station
of the aircraft. This requirement is therefore fullled, as end-
systems receive their addresses from this stable prex.
Mobile Network support (inherent): fullled since the
aircraft receives a complete mobile network prex instead of
a single IP address.
Multihoming (primary): BGP multihoming is an estab-
lished technique in the xed Internet. However, this form
of multihoming is usually restricted to either simple load-
balancing or to destination-based routing decisions. While
there are possibilities to include at least the source address of
packets into the routing decision [17], the problem of routing
specic trafc ows (e.g. based on the used transport protocol
and port numbers) still remains unsolved.
Security 1 (primary): the problems of BGP with respect
to security have been thoroughly investigated [18]. One of
the key problems is that BGP routers can advertise prexes
that do not even belong to them an attacker can advertise a
prex owned by someone else and therefore attract the trafc
belonging to the other entity. Secure BGP (S-BGP) [19] is one
proposal that provides a solution to this problem, although at
the expense of an increase in convergence time [18]. S-BGP
relies on a Public Key Infrastructure (PKI) and certicates that
authorize the owner to manage a certain IP address space. An-
nounced BGP information is then signed by a private key that
can be veried by the recipient based on the public key in the
certicate, therefore ensuring the authenticity of announced
routes. To secure the full routing system, all BGP speakers
have to implement S-BGP. Also, further investigations are
needed to identify whether S-BGP has to be adapted to work
with dynamic homing.
Security 2 (primary): The only aspect of S-BGP that might
be regarded as problematic is the increase in CPU and memory
consumption. There is not enough experience with S-BGP
available to properly assess this aspect though.
End-to-end delay (primary): BGP always provides a
shortest-path route from the end-systems on the ground to the
aircraft as routes are calculated via the current base station,
which currently advertises the aircraft prexes. The exact
meaning of shortest-path is dened by the metric of the
routing protocol.
Scalability (primary): an inherent property of BGP are
frequent route announcements and withdrawals from the new
and old points of attachment of an aircraft. As the ATN will
be separated from the public Internet and has its own BGP
routing core, scalability might not become a problem within
this environment. However, the AAC/APC domains are routed
over the public Internet and the use of BGP would therefore
cause negative impacts upon the routing tables. Scalability is
linear with the number of mobile nodes, with regard to the
number of route announcements and withdrawals.
Applicability to AAC/APC (primary): the protocol stack
on end-systems remains unaffected as BGP exchanges are
performed by either the airborne router or the ground station.
Convergence time (secondary) within the ATN is not as
much an issue as it is for the AAC/APC domains, due to the
smaller number of autonomous systems and routes compared
to the public Internet.
Efciency 1 (secondary): in [16] BGP route updates were
announced by the ground stations. In this case, the aircraft only
has to provide its identity and its prex to the ground station,
which then performs BGP announcements on behalf of the
aircraft. Another option, different from [16], would be to put
the BGP speaker on-board the aircraft. The signaling, that is
based on TCP, then has to be performed over the wireless link.
This implies 1.5 RTTs for establishing the TCP connection and
at least additional 1.5 RTTs for the BGP signaling.
Efciency 2 (secondary): the size of payload packets
remains unchanged.
Support for ground-initiated communications (sec-
ondary): as soon as a base station starts advertising the aircraft
prex, a route to the aircraft becomes available and trafc
would be properly routed to the aircraft.
B. IPsec
IPsec [20] is a well known protocol providing conden-
tiality, data integrity and data source authentication. These
services are provided by maintaining a shared state between
the two communication peers, also called Security Association
(SA). The SA consists of information related to IP address of
the two communication peers, cryptographic algorithm iden-
tiers and keys, etc. Establishing such a SA manually would
not be scalable, hence the Internet Key Exchange (IKEv2)
protocol [21] provides the means to create and manage them
dynamically. IKE mutually authenticates the two peers, based
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 7
Home Network
Access
Network B
Access
Network A
Handover
Security
Gateway
(MOB)IKE
Signalling
(MOB)IKE
Signalling
new IPsec
tunneI
oId IPsec
tunneI
1
2
3
CN
New Path for
Payload Traffic
Airborne
Router
4
Fig. 4. Signaling between airborne router and IPsec security gateway.
on either pre-shared secrets, certicates or the Extensible
Authentication Protocol (EAP) [22].
In case of a VPN-like approach where an IP-in-IP tunnel is
established, if one of the two IPsec peers moves to a different
network and congures a new IP address, the established SAs
would not be usable anymore. For this reason, the IKEv2
Mobility and Multihoming protocol (MOBIKE) [23] extends
IKEv2, allowing one peer (the mobile node) to change the
IP address of a SA and to signal this change to the security
gateway. In addition, the peer can also transparently move all
trafc ows from one interface/IP address to another one.
MOBIKE is usually used between a mobile node and its
(xed) security gateway that assigns a constant IP address to
the mobile node from its own address pool, as shown in Fig. 4.
Analysis: Session continuity: in the process of setting up
the initial SA via IKE, the airborne router can request the
assignment of a static, xed IP address from the gateway.
Trafc destined to or originating from the mobile network will
therefore always be routed via this gateway, with whom the
mobile node establishes an IPsec tunnel. In case the mobile
node moves to a different access network, a MOBIKE message
exchange updates the SA(s) and ensures that the gateway
forwards trafc via the IPsec tunnel to the mobile nodes new
location, the care-of address (CoA). The CoA is the IP address
that the airborne router congures in the new access network
(in Fig. 4 the CoA is rst from Access Network A and after
the handover from Access Network B).
Mobile Network support: instead of acquiring a single
address during the initial SA establishment with IKE, the
airborne router could request a network prex from the
gateway (e.g. a /24 as it was the case for BGP). This way, the
mobility of a complete mobile network could be supported.
Multihoming: while MOBIKE provides the means to use
different network interfaces, it is limited to using them in
a sequential way. Using several interfaces simultaneously to
route different data ows over different interfaces is not
supported.
Security 1: a mutual authentication within IKE is per-
formed between the gateway and the airborne router, based
on pre-shared secrets, certicates or EAP. This ensures that
the gateway forwards trafc to the correct airborne router.
Security 2: a vulnerability of IKE are CPU-exhaustion
attacks. The protocol denes a cookie-based mechanism that
can be activated if necessary and reduces the threat to an
acceptable level.
End-to-end delay: the security gateway is a pivotal node
that is always traversed by packets exchanged between the
mobile network and its communication peers on the ground.
If the distance between airborne router and gateway increases,
the overall end-to-end latency will also increase.
Scalability: mobility events are only signalled to the Se-
curity Gateway; the routing tables in the core infrastructure
therefore remain unchanged. The gateway or another BGP
speaker in the gateway network only has to advertise a single
aggregated prex via BGP that includes the addresses of all
its registered airborne routers (this is called an aggregate).
Scalability is therefore linear with the number of aggregates,
with regard to the entries in the routing tables.
Applicability to AAC/APC: the protocol stack on end-
systems remains unaffected as the airborne router transparently
tunnels all trafc to the security gateway.
Convergence time: when the airborne router moves to a
different network, it noties the gateway of its new address. As
data is always routed via the security gateway, the successful
completion of this notication ensures that data is immediately
routed to the new location. This is achieved with help of the
static, xed IP address or prex.
Efciency 1: when moving to a different network, the
airborne router needs 1 RTT of signaling with MOBIKE to
inform the gateway of its new location.
Efciency 2: the use of IPsec usually implies integrity
protection and allows for additional encryption. Even if no
cryptographic algorithms are specied, the additional headers
increase the overhead for every payload packet. In addition to
that, the overhead of a complete IP header is added to every
payload packet as an IPsec tunnel is used. The IPsec transport
mode, while eliminating the additional header, would not be
able to provide mobility.
Support for ground-initiated communications: as data is
always routed via the security gateway that is always notied
by the airborne router of its current location, trafc can be
immediately forwarded to the mobile node.
C. NEMO
The Network Mobility (NEMO) protocol [24] is an exten-
sion to Mobile IPv6 (MIPv6) [25]. NEMO extends the concept
of a mobile node to that of a Mobile Router (MR) with one or
several mobile network prexes. As soon as the MR attaches
to a foreign network it registers the new CoA with its Home
Agent (HA) in the home network and creates a bi-directional
tunnel for forwarding trafc between the nodes of the mobile
network and the communication peers on the ground via the
HA.
Analysis: Session continuity: similar to the IPsec solution
(cf. Section III-B), the home agent provides the airborne router
with a constant IP address called the Home Address (HoA)
from its own network. Trafc is therefore always routed via
the HA that forwards it to the current location of the MN.
Mobile Network support: NEMO extends MIPv6 by intro-
ducing a mobile router that has one or several Mobile Network
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
8 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION
Home Network
Access
Network B
Access
Network A
Handover
Home Agent
NEMO
Signalling
NEMO
Signalling
new NEMO
tunneI
oId NEMO
tunneI
1
2
3
CN
New Path for
Payload Traffic
4
Fig. 5. Signaling between mobile router and home agent.
Prexes (MNPs). These prexes belong topologically to the
home network. End-systems that attach to the MR congure
their addresses based on the MNP advertised by the MR and
can therefore remain mobility agnostic.
Multihoming: the possibility to register several care-of
addresses with the home agent is specied in [26]. In ad-
dition, [27] species a policy exchange protocol that can be
used to setup forwarding rules for certain trafc ows, taking
into account the additional care-of addresses. Detailed trafc
selectors can be used to identify a ow, based on IP or higher
layer protocol elds such as source/destination address, port
numbers, etc. The MR sends its current policy to the HA
which sets up forwarding to the MR accordingly. This allows
for simultaneously routing trafc ows over different interface,
on the routing path from the MR to the HA as well as on the
path from the HA to the MR.
Security 1: MR and HA perform a mutual authentication
between each other based on IKEv2 [28]. This ensures that
the HA forwards packets only to the valid MR.
Security 2: with the authentication between MR and HA
being based on IKEv2, the problem of CPU-exhaustion attacks
as already discussed for IKE in Section III-B applies here as
well.
End-to-end delay: NEMO causes sub-optimal routing
where trafc always traverses the HA. If the distance between
MR and HA increases, the overall end-to-end latency also
increases.
Scalability: the MR signals its current location to the HA
that updates its routing state accordingly. BGP routing tables
remain unchanged as the Home Network is always advertising
an aggregated prex via BGP that includes all the MNPs.
Scalability is therefore linear with the number of aggregates,
with regard to the number of announced prexes.
Applicability to AAC/APC: the protocol stack on end-
systems remains unaffected as trafc is transparently tunneled
between MR and HA.
Convergence time is equal to the time it takes the MR to
signal the new location to the HA, who will then immediately
forward trafc to the MNs new CoA.
Efciency 1: it takes the MR 1 RTT to signal the new
location/care-of address to the HA.
Efciency 2: the tunnel between the MR and the HA inicts
an overhead of a full IP header upon every payload packet.
Support for ground-initiated communications: as it was
the case for the IPsec-based approach, payload trafc is always
routed via the home agent. As the MR signals its care-of
address(es) to the HA, this trafc can be forwarded to the
MRs current location.
D. SCTP
The problem of mobility is directly impacting the transport
layer, where active sessions break due to the usage of the
IP address as an identier. One might therefore regard the
transport layer as a more proper location for a solution to the
mobility problem [29].
An approach that is different for the previous ones is solving
the problem on the transport layer itself. There are proposals
for adding mobility extensions to the appropriate protocols,
such as TCP-R [30] or M-UDP [31].
In the following we will take a close look at the Stream
Control Transmission Protocol (SCTP) [32]. We chose SCTP
over other protocols such as TCP-R or M-UDP, because of
the additional features it provides.
SCTP is a connection-oriented transport layer protocol
comparable to TCP, but with additional features such as mul-
tihoming. The original SCTP specication allows specifying
several IP addresses during connection setup time only. This
limitation has been removed with [33] where newly cong-
ured IP addresses can be dynamically added to or deleted
from an SCTP association by one of the two communication
peers. This is particularly useful for a mobile node where
IP addresses appear and disappear due to handovers between
different access networks.
Analysis: Session continuity: in case the MN moves to a
different network where it congures a new IP address, it can
dynamically add this new address to the SCTP connection
performing a failover. Afterwards, data can be exchanged
using the new association.
Mobile Network support: SCTP, as a transport layer
protocol, is running on the end hosts and as such is not able
to support network mobility.
Multihoming: while dynamically adding or removing IP
addresses can be used for mobility, its original intention was
to provide multihoming functionality to SCTP. The SCTP
multihoming however supports only redundancy but not load-
balancing. While several IP addresses can be associated to
a single SCTP association, only one address (the primary
address) can be used to transmit packets.
Security 1: SCTP is vulnerable with regard to an attacker
hijacking an already established association between two
communication peers [34]. This enables an attacker to hijack
trafc of a mobile node.
Security 2: there do exist vulnerabilities within SCTP
that can be exploited to send large volumes of unwanted
trafc to a victim. E.g., this can be achieved by providing an
additional false address to the SCTP association. The attacker
can later force the other SCTP peer to use this address and
send all trafc to it. These attacks can be either mitigated
or the probability to successfully mount an attack at least be
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 9
minimized. This can be achieved by properly implementing
SCTP or choosing proper protocol parameters. [34].
End-to-end delay: SCTP associations are bound to the
addresses that are locally available on the two communication
peers, including the care-of addresses at the mobile node. The
end-to-end delay therefore corresponds to the shortest route
between the IP addresses of the two peers.
Scalability: adding or deleting IP addresses to or from
SCTP associations is only signalled between the end systems.
There is, therefore, no impact on the routing infrastructure.
Applicability to AAC/APC: end-systems have to imple-
ment SCTP and applications also have to use this protocol in
order to have mobility support.
Convergence time is equal to the time the respective SCTP
messages need to signal the availability of a new IP address
to the communication peer.
Efciency 1: signaling consumes 1 RTT to add a new IP
address to the SCTP association.
Efciency 2: by solving the problem on the transport layer,
SCTP does not incur any additional overhead to payload
packets.
Support for ground-initiated communications: the at-
tempt of a communication peer on the ground to establish
a SCTP connection to a mobile node will fail due to the
unknown current location (care-of address) of the mobile node.
E. HIP
Another, more radical, approach for supporting mobility is
the locator-identier split, where a new shim layer between the
network and the transport layer is introduced. This layer also
introduces a new namespace on top of the IP address space.
The identiers within this namespace are globally unique and
associated to a mobile node. Higher layers (e.g. TCP) are not
binding anymore to an IP address (the locator), but instead to
the new identier. Several different approaches exist based on
these identiers, for example LIN6 [35] or the Host Identity
Protocol (HIP) [36].
In HIP, Host Identity Tags (HITs - the identiers) are
mapped to the available IP addresses (locators) with the help
of IPsec. The HITs are generated from the public key and
therefore cryptographically bound to it. Only the owner of the
corresponding private key can make use of the related HIT in
the HIP protocol exchanges. If the HIP-enabled mobile node
attempts to communicate with a HIP correspondent node, it
initiates a message exchange to establish a common session
based on the HITs of the two nodes and the IP addresses they
want to use for message exchange. In case one peer moves to
a new location, it signals the new IP address to the other peer.
The HIP modules on both nodes can then update their state
and map the HIT to the new IP address. In case the mobile
node is multihomed, the HIT can have a mapping to several
IP addresses.
HIP also provides Rendezvous Servers (RVS). Mobile nodes
register with an arbitrary RVS and then update their entries
in the Domain Name System (DNS) to (mn.example.org,
IP RVS). A correspondent node attempting to contact the MN
performs a DNS lookup and thereby retrieves the address of
the RVS. The contact initiation from the correspondent node
TCP
IPsec
ESP
HIP
IP
Mobility &
Multihoming
(bound to HIT)
(HIT_s, HIT_d) SPI
(HIT_s, HIT_d, SPI)
(IP_s, IP_d, SPI)
Fig. 6. Host Identity Protocol with mapping to lower and higher layers at
mobile node and correspondent node. A Host Identity Tag (HIT) is present for
both source (HIT s) and destination (HIT d). The Security Parameters
Index (SPI) uniquely identies an IPsec Encapsulated Security Payload (ESP)
security association. IP s and IP d refer to source and destination IP
address respectively.
to the RVS can then be forwarded by the RVS to the current
location of the mobile node.
The relationship of HIP to other layers of the protocol stack
is shown in Fig. 6.
Analysis: Session continuity: As soon as the mobile node
moves and congures a new IP address, HIP updates its (HIT,
IP address) mappings and signals this change to the corre-
spondent node. The upper layers are not negatively affected
as they are bound to the HIT, which remains unchanged.
Mobile Network support: a solution for network mobility
support in HIP is proposed in [37]. There, mobile network
nodes are required to have a HIP stack and delegate rights to
a HIP-enabled airborne router that performs HIP signaling on
behalf of the mobile network nodes.
Multihoming: the multihoming support in HIP is focused
on providing failover functionality. Simultaneous usage of
different interfaces, e.g. for load-balancing, has not been
investigated at the time of writing. HIP can therefore not fully
meet this requirement.
Security 1: HIP relies on authentication and authorization
schemes to protect the HIP message exchanges, including sig-
natures. If these mechanisms are used, an attacker including
man-in-the-middle can not impersonate a node or claim
trafc of a node.
Security 2: There is a limited vulnerability to memory
and computational exhaustion attacks where an attacker oods
a HIP-enabled node with a large amount of HIP signaling
messages.
End-to-end delay: trafc is exchanged directly between
communication peers. End-to-end delay therefore corresponds
to the shortest route between the two peers.
Scalability: HIP does not modify the routing system but
instead introduces a new identier space. Scalability issues
are therefore not related to the routing infrastructure, but to
the rendezvous servers (RVS).
Applicability to AAC/APC: end-systems must have HIP
implemented in their network stack. In addition they must
delegate rights to the airborne router in case of mobile network
support.
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
10 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION
TABLE I
MOBILITY REQUIREMENTS FULFILLMENT OF ALL CANDIDATE APPROACHES. GRADING CAN BE EITHER COMPLETELY FULFILLED/OPTIMAL (),
BASICALLY FULFILLED/FAIR (), WITH LIMITATIONS/AVERAGE () OR UNSUPPORTED/POOR ().
Protocol BGP IPsec NEMO SCTP HIP
Session Continuity
Mobile Network Support
Multihoming
Security 1
Security 2 /
End-to-end delay
Scalability (for DNS)
Applicability to AAC/APC
Convergence time
Efciency 1
Efciency 2
Ground-initiated comms.
Convergence time is equal to the time it takes the mobile
node to perform the HIP signaling exchange that updates the
(HIT, IP address) mapping at the correspondent node. The only
disadvantage is that the signaling has to be performed every
time communication of a new (mobile node, correspondent
node) pair is initiated.
Efciency 1: establishing a common HIP state between a
mobile node and a correspondent node takes 2 RTTs; updating
this state after movement of the mobile node consumes 1.5
RTTs.
Efciency 2: as HIP uses IPsec to exchange trafc between
its two communication peers, overhead is present for every
payload packet. However, HIP does not use a VPN-like IP-
in-IP tunnel, but instead relies on IPsec transport mode. This
only adds a small IPsec related header instead of an additional
IP(v6) header.
Support for ground-initiated communications: the initial
reachability of a mobile node within HIP can only be provided
with the help of the rendezvous server. Scalability, with regard
to number of DNS entries, is linear with the number of mobile
nodes.
F. Summary
The discussion of all the various protocols shows that
there is no optimal solution that is capable of fullling all
requirements out of the box. In the following, we provide a
summary of how the requirements are graded and discuss how
they are fullled by each protocol. In addition Table I shows
the comparison of all protocols in a more compact manner.
1) Grading Of Mobility Requirements: The grading of the
property Multihoming is either completely fullled (),
fullled with limitations (/) or not fullled (). The latter
is applied if load-balancing is not supported.
Security 1 is either completely fullled () or not fullled
(). Security 2 has the additional grading levels (/) and ()
that indicate that vulnerabilities exist but the probability for
an attacker to exploit them is very small, given that certain
precautions are taken.
The end-to-end delay can be either optimal () or sub-
optimal (). The latter being the case if packets are routed via
a xed node on the ground, instead of routing on the direct
path between the two communication peers.
Scalability always refers to the entries in the BGP routing
tables, except for HIP that only creates entries in the DNS.
() indicates linear scalability with number of mobile nodes
and () indicates linear scalability with number of aggregated
prexes. Finally, () for HIP is scalability with number of
mobile nodes, but graded better because it only impacts the
DNS. More precisely, the DNS entry of a mobile node is only
stored at a single DNS server. This is in contrast to individual
entries for mobile nodes in BGP tables that have to be present
in every BGP router in the routing core.
Applicability to AAC/APC is either possible () or not
possible ().
Convergence time is either limited to the time it takes to
signal the new location to a single node (), inuenced by
DNS lookup and forwarding of the initial packet by a rendez-
vous server () or depending on the convergence time of the
global routing tables () for an inter-network of limited size,
such as the ATN.
The gradings of the individual protocols for Efciency 1 and
Efciency 2 are relative to each other.
Ground-initiated communications is either fully supported
(), supported with a dependency on the DNS () or not
supported at all ().
2) Conclusion: With respect to the primary requirements,
a major issue is the need to implement HIP within the end-
system protocol stacks. This causes difculties for already
existing AAC systems and makes them infeasible for de-
ployment within the APC domain, where public well-known
web servers in the Internet would have to be upgraded. Also,
the multihoming capability of HIP would have to be further
investigated. HIP is therefore unable to fulll one primary
requirement.
SCTP, while being an interesting approach, does not provide
full multihoming support. Another critical aspect though the
fact that it is only sufcient for a mobile host and unable
to provide mobility support for a complete mobile network.
While it might be possible to add mobile network support
to this solution approach, the fact that both TCP and UDP
without any mobility extensions are the most frequently used
protocols in the public Internet makes the transport-layer
approach infeasible for the AAC/APC domains. Summarized,
SCTP is unable to fulll one inherent, three primary and one
secondary requirement.
BGP has problems with providing multihoming on a per-
ow granularity level. While S-BGP raises security to an
acceptable level, there might be reasons for concern with
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 11
the increase in CPU and memory consumption. The major
problem of BGP scalability becomes problematic for AAC
and APC which are both based on the public Internet. The
operation of BGP as a mobility protocol [16] even caused
concerns in the Internet Engineering Task Force (IETF). In
total, BGP is unable to completely fulll one and only partially
fullls another primary requirement.
The last two options are IPsec and Mobile IPv6/NEMO that
are in fact very similar to each other. A VPN-like approach,
as provided by IPsec, suffers from problems with end-to-end
latency, overhead inicted on payload trafc as well as the
lack of multihoming capabilities with respect to simultaneous
usage of several interfaces. An advantage of IPsec would be
the implicitly provided security for the higher layers. Unfor-
tunately, this feature can not be exploited within a mobile
network architecture where the airborne router establishes a
VPN with a security gateway: the IPsec security association
would not provide end-to-end security. On the other hand,
the Mobile IP-based NEMO protocol is a generic mobility
protocol providing a multitude of features, but also suffers
from problems with payload trafc overhead and end-to-end
delay.
A one-to-one comparison between IPsec and NEMO shows
that the latter has advantages over the former in two properties:
multihoming and, albeit only on a minor level, overhead. IPsec
and NEMO fail to meet two and one primary requirement
respectively.
A close look at Table I shows that, taking into account all
gradings, Mobile IP/NEMO is the highest rated solution. We
therefore argue that it is the most feasible solution for the
aeronautical environment.
Despite this conclusion, it might nevertheless be possible to
extend some of the other solutions to such an extend that they
are capable of fullling all requirements. We argue though
that it is more meaningful to start with the protocol that
already fullls most of the requirements and then address the
remaining issues of this protocol.
IV. NETWORK MOBILITY ROUTE OPTIMIZATION
NEMO fullls most of the requirements, but lacks an
acceptable end-to-end latency as of now. In the following we
provide a more detailed overview of the NEMO protocol and
discuss why a solution to this problem is required.
A. Network Mobility (NEMO)
The NEMO protocol [24] extends the Mobile IPv6 concept
of a mobile host having a static, xed (publicly routable) home
address with having a mobile router with mobile network
prexes.
A mobile network consists of a Mobile Router (MR) with at
least one Mobile Network Prex (MNP) and Mobile Network
Nodes (MNNs) that are attached to the MR and form their ad-
dresses based on the advertised MNP. The mobility signaling
that will be explained in the following is also shown in Fig. 7.
While the MR is attached to the home network, packets
addressed to the mobile network prexes are routed to the MR
by means of normal routing. As soon as the MR moves away
from the home network and attaches to a foreign network,
MNN MR CN
BU
BA
Signalling User Data Tunnel
HA
Fig. 7. NEMO mobility signaling and forwarding of user trafc over bi-
directional tunnel. Binding Update (BU) and Binding Acknowledgement (BA)
are exchanged between Mobile Router (MR) and Home Agent (HA). User
trafc is exchanged between the Mobile Network Node (MNN) and the
Correspondent Node (CN).
it becomes addressable via a Care-of Address (CoA) that
topologically belongs to the foreign network. The MR sends
a Binding Update (BU) to the Home Agent (HA) in the
home network. The HA creates an entry in its Binding Cache
linking the MNPs and the CoA. The home agent creates
a bi-directional tunnel to the MR after having responded
with a Binding Acknowledgement (BA). IKE/IPsec is used to
authenticate and protect the mobility signaling between mobile
router and home agent [28].
Packets of arbitrary Correspondent Nodes (CNs) communi-
cating with the MNNs are routed to the home network, where
the home agent intercepts these packets and tunnels them to
the current CoA of the mobile router, who will decapsulate
and forward them to the MNN. Packets from MNNs destined
to CNs are rst tunneled by the mobile router to the home
agent from where they are routed to the CN.
If the distance between mobile router and home agent
grows, the delay imposed upon MNN-CN communication
will increase due to routing all trafc via the home agent.
For this reason Mobile IPv6 provides a Route Optimization
(RO) mechanism that allows to route packets on a direct path
between mobile node and correspondent node, bypassing the
home agent. For the NEMO protocol no RO mechanism is
available up to now.
B. The Need For Route Optimization (RO)
For the aeronautical application of the NEMO protocol, the
delay imposed by routing all trafc via the home agent can be
signicant. As one of the worst case scenarios, we can assume
an aircraft ying above Europe and communicating with a
near ATS correspondent node while using a home agent in
Asia. This is a typical example for an Asian airline, where a
latency of about 300 ms is imposed upon every single packet
exchanged between MNN and CN (based on the service-
level agreement of a commercial backbone operator [38]
guaranteeing a 150 ms one-way delay between Europe and
Asia).
Apart from delay, the sub-optimal routing of packets over
different continents is also inefcient. In addition, the home
network in general and the home agent in particular become
a single point of failure. In case of problems with one of
these, routing between the communication peers becomes
impossible.
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
12 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION
Summarized, the benets of Route Optimization (RO) are:
Lower end-to-end delay
Less susceptibility to problems along the routing path
A NEMO RO procedure can extend the basic NEMO protocol
and provide these properties.
In the following, the second part of this paper, we will
perform an analysis of different NEMO RO protocols. For
this purpose we introduce specic NEMO RO requirements.
Afterwards the different protocols are analyzed with regard to
these requirements.
First however, we will provide an overview of the Mobile
IPv6 Route Optimization procedure that is applicable for
mobile hosts only. It will help show the general problems
associated with performing route optimization.
C. Mobile IPv6 Route Optimization (MIPv6 RO)
Mobile IPv6 RO allows routing packets on a direct path
between Mobile Node (MN) and correspondent node. The
design of this mechanism was driven by security requirements
and based on the limitation that it should be applicable
to nodes in the public Internet where no pre-existing trust
relationships could be assumed. More information on the
background of the MIPv6 RO mechanisms is available in [39],
[40].
The signaling is explained in the following. The exchanged
messages are also shown in Fig. 8.
The MN attaches to a foreign network and exchanges a
Binding Update (BU) with its home agent to bind its local
Care-of Address (CoA) to the Home Address (HoA).
The MN receives a Binding Acknowledgement (BA)
from the home agent and establishes a bi-directional
tunnel with the home agent. Home Registration is now
nished and the MN can also initiate RO to the CN(s)
now.
RO starts with the Return Routability procedure that
provides proof that the MN is reachable and therefore
the owner of both the CoA and the HoA. The MN sends
a Care-of Test Init (CoTI) message directly to the CN.
An additional Home Test Init (HoTI) message is sent
by the MN via the home agent to the CN. The CN
responds with each a Care-of Test (CoT) and Home Test
(HoT) message, the latter routed via the home agent. Both
responses contain cryptographic keys for the MN.
The RR procedure is nished as soon as the MN receives
both care-of test and home test message. The keys from
the two messages are combined into a single shared secret
key. This shared key is then used to generate a hash-based
message authentication code (HMAC) that is calculated
over and attached to the BU to the CN. The CN, upon
reception of the BU, validates the HMAC and responds
with a BA.
As soon as the MN receives the BA from the CN, the
RO procedure is completed and trafc can be directly
exchanged between MN and CN, therefore avoiding
routing via the HA.
The Return Routability procedure does not protect against on-
path attackers that reside on the path between the HA and the
CN. This attacker must have the capability of eavesdropping
BU
BA
H
o
m
e
R
e
g
i
s
t
r
a
t
i
o
n
HoTI
HoT[Key_2]
C
o
r
r
e
s
p
o
n
d
e
n
t

R
e
g
i
s
t
r
a
t
i
o
n
R
e
t
u
r
n

R
o
u
t
a
b
i
l
i
t
y
CoTI
CoT[Key_1]
MN HA CN
BU[HMAC]
BA[HMAC]
Fig. 8. MIPv6 Home Registration and Route Optimization signaling.
on packets exchanged over this path. He can therefore get in
possession of the cryptographic key included in the home test
message and use it in various attacks [39], [40].
D. Requirements For Aeronautical NEMO RO
In the following we are specifying the critical requirements
that have to be fullled by a candidate NEMO RO solu-
tion. This list builds on the already available requirements
from [41].
The requirements are as follows:
1) Separability: it should be possible to apply RO only to
ows that really require it. For example, RO should only
be activated for all trafc originating from one specic
MNN, whereas trafc from other MNNs is routed over
the home agent.
2) Multihoming: the RO mechanism must be fully usable if
several interfaces are present. More precisely, it should
be possible to forward a route-optimized trafc ow via
a particular interface/path.
3) Efcient Signaling: both the size and number of indi-
vidual RO signaling messages should be kept small.
4) Security: the mobility entity on the ground receiving the
BU must be able to validate the aircraft as proper owner
of both the claimed care-of address and mobile network
prex. Vulnerability to on-path attackers as in MIPv6
RO must be avoided (cf. Section IV-C).
5) Adaptability: the RO scheme should not break applica-
tions using new transport protocols or IPsec.
E. NEMO RO Options
The RO procedure can be initiated and performed by dif-
ferent entities. Consecutively, we establish four RO categories
that are dened by the entities participating in RO signaling.
These categories are also shown in Fig. 9:
Mobile Network Node to Correspondent Node
Mobile Router to Correspondent Node
Mobile Router to Correspondent Router
Mobile Router to Home Agent
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 13
MR
MNN
CN
Data traffic
RO Signaling
(a) MNN to CN
MR
MNN
CN
RO Signaling
Data traffic
(b) MR to CN
MR
MNN
CR
RO Signaling
Data traffic
CN
(c) MR to CR
MR
MNN
HA
RO Signaling
Data traffic
CN
(d) MR to HA
Fig. 9. The four different route optimization classes.
We will only give a short overview on these categories in the
following. A more thorough discussion on the advantages and
disadvantages of the four individual solution classes can be
found in [42] or [43]. Our main contribution is the assessment
of these solutions with regard to the requirements specied in
Section IV-D.
Mobile Network Node to Correspondent Node: an exam-
ple for this approach is [44]. The mobile router exposes the
prexes advertised by its own access router(s) to the MNNs.
The end-systems then form their own care-of addresses and
perform RO in the standard MIPv6 fashion themselves. The
problems with this approach is overhead, as signaling takes
place between every (MNN, CN) pair. Another problem is how
MNNs can make use of multiple paths off the mobile network
from the MR (multihoming). Also, the access network has
to accept every MNN address as source address for packets,
something that may not be supported if the outgoing interface
at the MR supports having only a single IP address. Security
problems are also present as standard MIPv6 RO is used
(cf. Section IV-C). Obviously, it would also be necessary to
upgrade the MNN protocol stack with mobility extensions. An
advantage of this category is that the RO path is the optimal
one with direct routing between MNN and CN.
Mobile Router to Correspondent Node: within this class,
the mobile router performs all mobility signaling on behalf of
the MNN. Several proposals exist [45], [46]. The signaling
overhead is reduced to (MR,CN) pairs when compared to
the previous category. An issue of this approach though are
problems related to reusing standard MIPv6 RO signaling
between MR and CN, which suffers from the on-path attacker
problems (cf. Section IV-C). Problems arise with end-to-end
integrity: if the MR performs actions on behalf of the MNN
and modies user packets, it could be regarded as man-in-the-
middle attacker by end-to-end security protocols used between
MNN and CN (e.g. IPsec). The advantage is that the routing
path is also optimal: the MNN will be directly attached to the
MR, from where packets are routed to the CN on the direct
path.
Mobile Router to Correspondent Router was proposed
in [47]. A new entity called Correspondent Router (CR),
that is located within the CN network, is introduced. The
mobile router performs mobility signaling with the CR and
establishes a bi-directional tunnel that is used to exchange
trafc between the mobile network and the network served
by the CR. Signaling overhead is limited to (MR, CR) pairs,
but the signaling itself is based on standard MIPv6 RO with
its security limitations. The advantage is a good scalability as
several CNs can be served by a single CR. Also, multihoming
with the CR could be easily accommodated.
Mobile Router to Home Agent: here, the concept of hav-
ing only a single home agent for a mobile node is extended to
having multiple, geographically and topologically distributed
home agents. The proposal is called Global HA-to-HA [48].
While multihoming can be supported with [26], [27], the
MR always binds with a single HA. Simultaneously routing
different ows via different HAs is therefore not possible. The
advantages are that both signaling overhead (efciency) and
security are very similar to the basic NEMO protocol, which
have been graded as completely fullled (cf. Table I).
F. Grading Of RO Requirements
The property Separability is completely fullled () by
the MNN-to-CN class and sufciently fullled () by the
other approaches. The reason for the reduced grading is the
inability of the MR to perform trafc ow identication in
case an end-to-end security protocol with condentiality is
used, as protocol header elds are not readable anymore for
the MR.
The property Multihoming is either completely (), suf-
ciently () or not fullled at all (). Sufciently refers to
the fact that trafc can be routed via different interfaces at
the MR, but that data still converges at and gets forwarded by
the same home agent. This requirement can not be fullled
without problems by MNN-based RO approaches because of
problems related to sharing the care-of address: in case only
one care-of address is available on an outgoing interface at the
MR, this address would have to be shared among the MR and
the MNNs. This requires NAT-like behavior, posing problems
as described in [11].
Efcient signaling ranges from very bad () up to very
good (), depending on the number of nodes involved in
mobility signaling.
The security requirement has been either fullled () or
not fullled ().
The grading of the property adaptability is as follows: it is
either not fullled () because of problems with preserving
end-to-end integrity or completely fullled () because the
original payload is preserved due to tunneling encapsulation.
It is also possible to sufciently fulll () this requirement
in case end-to-end trafc is modied but no problems should
be caused because the end-systems are performing RO them-
selves.
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
14 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION
TABLE II
OVERVIEW OF THE CHARACTERISTICS OF THE INDIVIDUAL SOLUTION CLASSES. REQUIREMENTS CAN BE EITHER FULFILLED (), PARTIALLY
FULFILLED (), PARTIALLY PROBLEMATIC () OR PROBLEMATIC ().
Requirement MNN to CN MR to CN MR to CR MR to HA
Separability
Multihoming
Efcient Signaling
Security
Adaptability
G. Conclusion
A summary of the individual pros and cons is provided in
Table II. It shows the problems of the rst two approaches and
the strengths of the latter two, especially for the MR-to-HA
class. The rst two approaches suffer from several problems,
most notably security and also efciency since signaling is
performed individually either for every CN or MNN. The third
solution class, MR-to-CR, suffers from security problems.
On the other hand, the Global HA-to-HA protocol (a MR-
to-HA approach) manages to fulll all requirements. This
identies it as the most promising approach among all the
studied RO protocols.
Fig. 10 shows how the Global HA-to-HA protocol could
be used to extend NEMO for the ATN mobility architecture.
Home Agents of the same home network are globally dis-
tributed in the ATN and inter-connected to each other via
tunnels.
A problem with the deployment of this architecture is that
the aeronautical communications service provider (ACSP cf.
Section II-D) operating the home agents must have a world-
wide network presence. If home agents are not available in
close distance to the mobile router, a binding with a distant
home agent would again have to be performed.
Another problem is the routing to the distributed home
network and its home agents in case of natural disasters,
etc. If the routing path between the ANSP access network,
where aircraft will often attach to, and the home network fails,
communication would completely fail.
An advantage of the MR-to-HA approach though is the
applicability to the AAC and APC domains where passenger-
owned devices have to be supported and data is routed over
the public Internet. As mobility signaling is only performed
between mobile router and home agent, both MNNs and CNs
remain unaffected. In fact, the mobility protocol is completely
transparent to these end-systems and they do not require any
mobility extensions.
V. SUMMARY
We provided an overview of the peculiarities of the aero-
nautical communications environment with its different service
classes and discussed why a protocol to support mobility is
actually needed. The focus of our survey was on supporting
safety-related services (ATS/AOC) within the ATN, although
we also introduced a requirement to cover the applicability to
non-safety related services (AAC/APC).
We investigated a number of protocols that can be used
to provide IP mobility and assessed them with regard to the
specic aeronautical requirements that we introduced. The
conclusion was that NEMO is capable of fullling more
requirements out of the box than any other protocol.
The only problem of NEMO is the provision of a small
end-to-end latency, as all trafc between the aircraft and the
ground communication peers is routed via the home agent. We
therefore surveyed a number of protocols that extend NEMO
to solve the Route Optimization problem. Having assessed
the individual protocols with regard to a dedicated set of RO
requirements, it turned out that the Global HA-to-HA protocol
fullls all requirements.
An IP mobility architecture based on NEMO in conjunction
with Global HA-to-HA could not only provide mobility for
the safety-related ATS and AOC services within the ATN,
but is also applicable to the AAC and APC domains in the
public Internet. With Global HA-to-HA, mobility extensions
only have to be implemented in the network stacks of the
mobile router and within the home agents. The end-systems,
both on the aircraft and on the ground, can have standard IP
stacks and therefore remain mobility agnostic.
VI. OUTLOOK
While appealing from many aspects, there still remains an
open issue with regard to the Global HA-to-HA protocol: the
location information of mobile nodes has to be synchronized
between all home agents. As also mentioned in [49], it remains
to be claried how well this scales with an increased number
of mobile nodes and home agents.
As already mentioned in Section IV-G, the Global HA-to-
HA protocol is not addressing all problems: in case routing
to the home network and its home agents is broken, the
end-systems on-board the aircraft are unable to communi-
cate anymore. Furthermore, if not sufcient home agents
are distributed all over the world, route optimization is not
properly addressed anymore. The end-to-end latency problem
then reemerges.
In the future, additional work should therefore focus on an
additional route optimization component that addresses this
problem. Table II shows that a correspondent router-based
approach can fulll most of the requirements. The protocol
has to be improved by addressing the weak aspect of security
though.
In the course of modifying the correspondent router protocol
it should be properly designed to provide route optimization
without any home agent interaction. The approach would
therefore have to be different from Mobile IPv6 RO where
the home agent is an integral part of the signaling (cf. Sec-
tion IV-C). Removing this dependency (exchange of signaling
messages via the home agent) will make the RO component
independent from the home network. As a consequence, RO
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
BAUER and ZITTERBART: A SURVEY OF PROTOCOLS TO SUPPORT IP MOBILITY IN AERONAUTICAL COMMUNICATIONS 15
ANSP
Network
ATSCN
HA
In Asia
HA
in US
HA
in Europe
ATN &
Distributed
Home Network
MNN-ATS CN communication path
AirIine
network
AOC CN
MNN-AOC CN communication path
HA-HA Tunnel MR-HA Tunnel
Fig. 10. Mobility architecture for the ATS/AOC domains.
can be performed and retained in the presence of home agent
or home network failures.
From a more general perspective that is independent of the
used protocol, another issue is handover delay. As soon as
(near) real-time data has to be exchanged, it becomes imper-
ative to minimize delay and resulting packet loss during the
handover. This can become necessary with the transmission
of on-board sensor data to the ground or the usage of Voice
over IP (cf. Section II-B).
This issue has been well studied for host mobility [50], es-
pecially for cellular networks [51]. Even more packet loss has
to be expected for network mobility as the the large number
of on-board end-systems also produce a larger number of data
ows. While it has been shown that signicant improvements
can be achieved [52], more investigations will be needed.
ACKNOWLEDGMENT
The authors would like to thank Thomas Gamer and Serkan
Ayaz for related discussions and comments that helped to
improve the quality of this manuscript.
REFERENCES
[1] International Civil Aviation Organization, Manual for the ATN using
IPS Standards and Protocols (Doc 9896), February 2009, 1st edition,
Unedited Advance version.
[2] Single European Sky ATM Research (SESAR), European Air Trafc
Management Master Plan, March 2009, edition 1.
[3] I. Guardini, E. Demaria, and M. L. Monaca, Mobile IPv6 deployment
opportunities in next generation 3GPP networks, in 16th IST Mobile
and Wireless Communications Summit 2007, Proceedings of, 2007.
[4] R. Baldessari, A. Festag, and J. Abeille, NEMO meets VANET: A De-
ployability Analysis of Network Mobility in Vehicular Communication,
in Proc. 7th International Conference on ITS Telecommunications (ITST
2007), Sophia Antipolis, France, Jun. 2007, pp. 375389.
[5] Eurocontrol/FAA Future Communication Study, Communications Op-
erating Concept and Requirements for the Future Radio System, May
2007, COCR version 2.0.
[6] ICAO Aeronautical Communications Panel, WG F, Off-
Board Communications for Vehicle Health Management,
http://www.icao.int/anb/panels/acp/wgdoclist.cfm?MeetingID=266,
December 2009, 21st meeting of the working group F, Bangkok,
Thailand.
[7] IEEE Standard for Local and metropolitan area networks. Wireless
LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specications, IEEE Std 802.11-2007, pp. C11184, 2007.
[8] IEEE Standard for Local and metropolitan area networks. Physical
and Medium Access Control Layers for Combined Fixed and Mobile
Operation in Licensed Bands, IEEE Std 802.16e-2005, pp. 1822, 2006.
[9] DLR, Expected B-AMC System Performance, September 2007, report
D5.
[10] B. Korn, C. Edinger, D. K ugler, T. P utz, O. Hassa, and B. Mohrhard,
Is Sectorization Really Required For Efcient En-Route Air Trafc
Control? in CEAS 2009 European Air and Space Conference, October
2009.
[11] A. M uller, G. Carle, and A. Klenk, Behavior and classication of NAT
devices and implications for NAT traversal, IEEE Network, vol. 22,
no. 5, pp. 1419, 2008.
[12] D. Le, X. Fu, and D. Hogrefe, A review of mobility support paradigms
for the Internet, IEEE Commun. Surveys and Tutorials, vol. 8, no. 1-4,
pp. 3851, 2006.
[13] E. Perera, V. Sivaraman, and A. Seneviratne, Survey on network
mobility support, SIGMOBILE Mob. Comput. Commun. Rev., vol. 8,
no. 2, pp. 719, 2004.
[14] ICAO Aeronautical Communications Panel, WG I, Analysis of Candi-
date Mobility Solutions, 13th meeting of the working group N-SWG1,
Montreal, Canada.
[15] Y. Rekhter, T. Li, and S. Hares, A Border Gateway Protocol 4 (BGP-
4), RFC 4271, Jan. 2006.
[16] A. L. Dul, Global ip network mobility using border gateway protocol,
www.quark.net/docs/Global IP Network Mobility using BGP.pdf,
Mar. 2006, Boeing White Paper.
[17] M. Bagnulo, A. Garca-Martnez, J. Rodrguez, and A. Azcorra, The
case for source address dependent routing in multihoming, in Quality
of Service in the Emerging Networking Panorama: Fifth International
Workshop on Quality of Future Internet Services (QofIS), 2004, pp.
237246.
[18] K. Butler, T. Farley, P. McDaniel, and J. Rexford, A survey of BGP
security issues and solutions, Proc. IEEE, vol. 98, no. 1, pp. 100122,
January 2010.
[19] S. Kent, C. Lynn, and K. Seo, Secure Border Gateway Protocol (S-
BGP), IEEE J. Sel. Areas Commun., vol. 18, no. 4, pp. 582592, April
2000.
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
16 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION
[20] S. Kent and K. Seo, Security Architecture for the Internet Protocol,
RFC 4301, Dec. 2005.
[21] C. Kaufman, Internet Key Exchange (IKEv2) Protocol, RFC 4306,
Dec. 2005.
[22] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz,
Extensible Authentication Protocol (EAP), RFC 3748, Jun. 2004.
[23] P. Eronen, IKEv2 Mobility and Multihoming Protocol (MOBIKE),
RFC 4555, Jun. 2006.
[24] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert, Network
Mobility (NEMO) Basic Support Protocol, RFC 3963, Jan. 2005.
[25] D. Johnson, C. Perkins, and J. Arkko, Mobility Support in IPv6, RFC
3775, Jun. 2004.
[26] R. Wakikawa, V. Devarapalli, G. Tsirtsis, T. Ernst, and K. Nagami,
Multiple Care-of Addresses Registration, RFC 5648, Oct. 2009.
[27] H. Soliman, G. Tsirtsis, N. Montavont, G. Giaretta, and K. Kuladinithi,
Flow Bindings in Mobile IPv6 and NEMO Basic Support,
Internet-Draft (work in progress) draft-ietf-mext-ow-binding-04, Nov.
2009. [Online]. Available: http://tools.ietf.org/html/draft-ietf-mext-ow-
binding-04
[28] V. Devarapalli and F. Dupont, Mobile IPv6 Operation with IKEv2 and
the Revised IPsec Architecture, RFC 4877, Apr. 2007.
[29] W. Eddy, At what layer does mobility belong? IEEE Commun. Mag.,
vol. 42, no. 10, pp. 155 159, October 2004.
[30] D. Funato, K. Yasuda, and H. Tokuda, TCP-R: TCP mobility support
for continuous operation, in Proc. the International Conference on
Network Protocols (ICNP). Washington, DC, USA: IEEE Computer
Society, 1997, p. 229.
[31] K. Brown and S. Singh, M-UDP: UDP for Mobile Networks, in ACM
Computer Communication Review, 1996, pp. 6078.
[32] R. Stewart, Stream Control Transmission Protocol, RFC 4960, Sep.
2007.
[33] R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, and M. Kozuka, Stream
Control Transmission Protocol (SCTP) Dynamic Address Recongura-
tion, RFC 5061, Sep. 2007.
[34] R. Stewart, M. Tuexen, and G. Camarillo, Security Attacks Found
Against the Stream Control Transmission Protocol (SCTP) and Current
Countermeasures, RFC 5062, Sep. 2007.
[35] A. Matsumoto, K. Fujikawa, Y. Okabe, F. Teraoka, M. Kunishi, M. Ohta,
and M. Ishiyama, Multihoming Support based on Mobile Node Proto-
col LIN6, in SAINT-W 03: Proc. the 2003 Symposium on Applications
and the Internet Workshops (SAINT03 Workshops). Washington, DC,
USA: IEEE Computer Society, 2003, p. 204.
[36] P. Nikander, A. Gurtov, and T. R. Henderson, Host Identity Protocol
(HIP): Connectivity, Mobility, Multi-homing, Security, and Privacy over
IPv4 and IPv6 Networks, IEEE Commun. Surveys Tutorials, vol. 12,
no. 1, pp. 24 38, second 2010.
[37] S. Novaczki, L. Bokor, G. Jeney, and S. Imre, Design and Evaluation
of a Novel HIP-Based Network Mobility Protocol, Journal of Networks
(JNW), vol. 3, no. 1, pp. 1024, 2008.
[38] NTT Communications Europe Website, Performance Statistics,
Tech. Rep., Feb. 2009. [Online]. Available: http://www.ntt.net/english/
service/sla ps.cfm
[39] P. Nikander, J. Arkko, T. Aura, and G. Montenegro, Mobile ip version
6 (mipv6) route optimization security design, in Vehicular Technology
Conference. IEEE VTC Fall., vol. 3, October 2003, pp. 2004 2008.
[40] P. Nikander, J. Arkko, T. Aura, G. Montenegro, and E. Nordmark,
Mobile IP Version 6 Route Optimization Security Design Background,
RFC 4225, Dec. 2005.
[41] W. Eddy, W. Ivancic, and T. Davis, Network Mobility Route Opti-
mization Requirements for Operational Use in Aeronautics and Space
Exploration Mobile Networks, RFC 5522, Oct. 2009.
[42] A. Shahriar, M. Atiquzzaman, and W. Ivancic, Route optimization
in network mobility: Solutions, classication, comparison, and future
research directions, IEEE Commun. Surveys Tutorials, vol. 12, no. 1,
pp. 24 38, rst 2010.
[43] H.-J. Lim, M. Kim, J.-H. Lee, and T.-M. Chung, Route Optimization
in Nested NEMO: Classication, Evaluation, and Analysis from NEMO
Fringe Stub Perspective, IEEE Trans. Mobile Comput., vol. 8, no. 11,
pp. 15541572, 2009.
[44] C. Ng and J. Hirano, Securing Nested Tunnels Optimization
with Access Router Option, Internet-Draft (work in progress)
draft-ng-nemo-access-router-option-01, Jul. 2004. [Online]. Available:
http://tools.ietf.org/html/draft-ng-nemo-access-router-option-01
[45] M. Calderon, C. Bernardos, M. Bagnulo, I. Soto, and A. de la Oliva,
MIRON: Mobile IPv6 Route Optimization for NEMO, IEEE J. Sel.
Areas Commun., issue on Mobile Routers and Network Mobility, vol. 24,
no. 9, pp. 17021716, 2006.
[46] C. Kim, Ed., S-RO: Simple Route Optimization Scheme with NEMO
Transparency, ser. Lecture Notes in Computer Science, vol. 3391.
Springer, 2005.
[47] R. Wakikawa., S. Koshiba, K. Uehara, and J. Murai, ORC: Optimized
Route Cache Management Protocol for Network Mobility, in IEEE
10th International Conference on Telecommunication (ICT), 2003, pp.
119126.
[48] R. Wakikawa, G. Valadon, and J. Murai, Migrating home agents
towards internet-scale mobility deployments, in CoNEXT 06: Proc.
2006 ACM CoNEXT conference. New York, NY, USA: ACM, 2006,
pp. 110.
[49] L. Zhang, R. Wakikawa, and Z. Zhu, Support mobility in the global
internet, in MICNET 09: Proc. the 1st ACM workshop on Mobile
internet through cellular networks. New York, NY, USA: ACM, 2009,
pp. 16.
[50] G. Xie, J. Chen, H. Zheng, J. Yang, and Y. Zhang, Handover Latency
of MIPv6 Implementation in Linux, in Global Telecommunications
Conference. IEEE GLOBECOM., 2007, pp. 17801785.
[51] M.-J. Yang, K.-Y. Cheon, A.-S. Park, Y.-H. Choi, and S.-H. Kim,
Seamless Handover Using FMIPv6 with Effective Tunnel Management
Scheme, in Global Telecommunications Conference. IEEE GLOBE-
COM., November 2008, pp. 1 5.
[52] H. Petander and E. Perera, Measuring and improving the performance
of network mobility management in IPv6 networks, IEEE J. Sel. Areas
Commun., vol. 24, pp. 16711681, 2006.
Christian Bauer received the BS and MS degrees in computer science from
the University of Innsbruck, Austria, in 2004 and 2006 respectively. Currently
he is a a researcher at the Institute of Communications and Navigation at
the German Aerospace Center (DLR). His research interests are in the area
of networking protocols and their application in the area of aeronautical
communications, with a special emphasis on IPv6, mobility and handover
management as well as security.
Martina Zitterbart is full professor in computer science at Universit at
Karlsruhe (TH). From 1987 to 1995 she was research assistant in Karlsruhe,
receiving her doctoral degree in 1990. From 1991-1992 she was on leave
of absence as a Visiting Scientist at the IBM T.J. Watson Research Center,
Yorktown-Height, NY. She was Visiting Professor at the University of Magde-
burg and the University of Mannheim and full professor at the Technical
University of Braunschweig (1995-2001). Her primary research interests are
in the areas of multimedia communication systems, mobile and ubiquituous
computing, ambient technologies as well as wireless sensor networks. She is
member of the IEEE, ACM and the German Gesellschaft f ur Informatik. In
2002, Martina Zitterbart received the Alcatel SEL research award on technical
communication. In 2003, she was General Co-Chair of the ACM SIGCOMM
conference which was held in Karlsruhe.
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

Vous aimerez peut-être aussi