Mobility and Radio Resource Management in Future ... · Buffering Methode näher untersucht. Diese...
122
Mobility and Radio Resource Management in Future Aeronautical Mobile Networks — Mobilität und Radio Resource Management in zukünftigen aeronautischen Kommunikationsnetzen Der Technischen Fakultät der Universität Erlangen-Nürnberg zur Erlangung des Grades DOKTOR-INGENIEUR vorgelegt von Serkan Ayaz Erlangen – 2013
Transcript of Mobility and Radio Resource Management in Future ... · Buffering Methode näher untersucht. Diese...
Mobility and Radio Resource Management in FutureAeronautical Mobile Networks
—
Mobilität und Radio Resource Management inzukünftigen aeronautischen Kommunikationsnetzen
Der Technischen Fakultät der
Universität Erlangen-Nürnberg
zur Erlangung des Grades
D O K T O R - I N G E N I E U R
vorgelegt von
Serkan Ayaz
Erlangen – 2013
Als Dissertation genehmigt von
der Technischen Fakultät der
Universität Erlangen-Nürnberg
Tag der Einreichung: 10.08.2012
Tag der Promotion: 08.02.2013
Dekan: Prof. Dr.-Ing. habil. Marion Merklein
Berichterstatter: Prof. Dr.-Ing. Reinhard German
Prof. Dr.-Ing. habil. Falko Dressler
Prof. Dr.-Ing. Wolfgang Gerstacker
Abstract
The aviation community is currently working on the standardization of data communication
systems for the future air traffic management (ATM). The standardization effort has two main
streams, namely, standardization of future radio access technologies in the L-band (i.e., LDACS)
and standardization of a future IPv6-based aeronautical telecommunications network (ATN/IPS).
In this thesis, different handover and radio resource management algorithms are developed for
the most promising future radio access technology for the aviation, L-band digital aeronautical
communications system option 1 (LDACS1) in conjunction with realistic IPv6-based network
layer functionality (ATN/IPS).
In the first part of this work, handover performance of network mobility (NEMO) is in-
vestigated and different cross-layer approaches are proposed in order to improve handover
latency and signaling overhead. These improvements mainly use media independent handover
functionality proposed by the IEEE 802.21 standard and are important due to the following
reasons:
• One of the main system requirements of LDACS is to deliver certain ATS messages in
a timely manner (i.e., low latency) with minimum service disruption (i.e., high service
availability).
• In parallel, future services like VoIP and transmission of sensor data for the aircraft health
management also require “real-time” and “near-real-time” transmission of certain informa-
tion with low latency and high availability.
• According to STATFOR statistics, number of flights in Europe will be around 17 million
in 2030 annually, which is 1.8 times more than in 2009. Since LDACS is planned for the
time frame of 2020-2030, it should be capable of handling the data traffic demands of the
future ATM. From this perspective, reducing the signaling overhead over the wireless link
should be one of the design criterion for future radio access technologies that will be used
in the ATM domain.
With our proposals, total handover latency (i.e., layer 2 and layer 3) is reduced from 3 s
to around 0.4 s and signaling overhead due to router advertisement messages is reduced from
17 kbit/s to around 0.1 kbit/s.In the second part, the effect of handover event on transmission control protocol (TCP)
performance is analyzed. In the first step, different TCP handover optimizations related to
iii
iv
Mobile IPv6 protocol are presented. In the next step, the applicability of these proposals to
different handover scenarios is investigated and the most promising proposal (home agent
buffering method) is integrated with LDACS1 handover functionality. Finally, the performance
of home agent buffering method is analyzed in terms of TCP transmission completion time. With
the help of this method, total transmission completion time of a session is reduced by at least
10% for a download of 110 kB of information.
In the third part, different radio resource management (RRM) algorithms are analyzed for the
LDACS1 since the resources should be distributed evenly among different users. This is not only
important from fairness perspective but also from “expiration time” and “latency” requirements
of ATS/AOS messages. Here, we analyzed different RRM algorithms in terms of bandwidth and
end-to-end delay fairness. We also proposed a new modified deficit round robin algorithm which
could be used for both links (i.e., forward and return link) and satisfies almost perfect fairness
among different number of users.
In the last part, different NEMO route optimization (RO) techniques are analyzed due to
triangular routing problem of NEMO. With the help of NEMO RO, packets follow shorter paths
(in terms of number of hops) between the end nodes so that the measured end-to-end delay is
reduced. Most of these NEMO RO methods are published as Internet Engineering Task Force
(IETF) drafts. Among those proposals, we have realized that some of them require mobility
related functionalities to the end nodes and some others do not. In addition, some proposals try
to solve nested NEMO problem without working on the main route optimization problem. In
addition, since most of those protocols are published as IETF draft, some proposals lack protocol
design and maturity in terms of implementation. Considering these issues, we mainly analyzed
infrastructure based NEMO RO techniques; namely global home agent to home agent (global
HAHA) and correspondent router (CR) protocols from ATN/IPS perspective in the first part.
Later on, we proposed two new approaches for the global HAHA protocol in order to decrease
end-to-end delay and mobility signaling overhead.
Kurzfassung
Die Luftfahrt Community arbeitet derzeit an der Standardisierung von Kommunikationssystemen
für die Zukunft des Flugverkehrsmanagements. Diese Standardisierungsaktivitäten haben zwei
wesentliche Ziele. Zum einen sollen künftige Funktechnologien definiert werden (d.h. LDACS),
zum anderen wird ein IPv6 basiertes aeronautisches Telekommunikationsnetz (ATN/IPS) spe-
zifiziert. In dieser Arbeit werden verschiedene Handover und Radio Resource Management
Algorithmen für das aussichtsreichste potentielle künftiges Funksystem für die Luftfahrt, L-band
Aeronautical Communications System Option 1 (LDACS1), in Verbindung mit der Funktionalität
von IPv6 auf der Netzwerkschicht untersucht. IPv6 wird von dem IP-basierten aeronautischen
Telekommunikationsnetz ATN/IPS vorgesehen.
Im ersten Teil dieser Arbeit wird das Handover Verhalten des Network Mobility (NEMO)
Protokolls untersucht und verschiedene Cross-Layer Ansätze vorgeschlagen, um die Handover
Latenz zu verringern und der Signalisierungs Overhead zu reduzieren. Diese Vorschläge nut-
zen vor allem die Media Independent Handover Funktionalität, die im IEEE 802.21 Standard
spezifiziert ist. Diese Verbesserungen sind aus mehreren Gründen von großer Bedeutung:
• Eine der wichtigsten Anforderungen an das LDACS System ist es, Nachrichten für die
Flugverkehrskontrolle innerhalb der vorgegebenen Latenzzeiten und mit ausreichender
Verfügbarkeit zu übertragen.
• Außerdem verlangen einige Dienste wie VoIP oder die laufende Überwachung des Zustands
des Flugzeugs durch Sensoren nach einer Datenübertragung in Echtzeit oder nahezu in
Echtzeit, d.h. mit minimaler Latenz und ebenfalls mit hoher Verfügbarkeit.
• Laut STATFOR, dem Statistikdienst der europäischen Flugsicherungsbehörde, wird die
jährliche Zahl der Flüge in Europa bis 2030 auf rund 17 Millionen steigen, was einem
Faktor von 1,8 gegenüber dem Jahr 2009 entspricht. Da LDACS in dem Zeitraum von
2020-2030 eingesetzt werden soll, muss es in der Lage sein, die künftigen Anforderungen
an das Flugverkehrsmanagement zu bewältigen. Daher sollte es ein Hauptziel bei der Ent-
wicklung künftiger Funktechnologien für die Luftfahrt sein, den Signalisierungs Overhead
zu minimieren, damit Kapazität nicht unnötig verschenkt wird.
Mit unseren Vorschlägen kann die gesamte Latenzzeit eines Handovers (d.h. Layer 2 und
Layer 3) von rund 3 s auf rund 0.4 s reduziert werden, und der Signalisierungs-Overhead durch
IP Router Advertisements wird von rund 17 kbit/s auf nur 0.1 kbit/s reduziert.
v
vi
Im zweiten Teil dieser Arbeit werden die Auswirkungen eines Handovers auf das Trans-
mission Control Protocol (TCP) untersucht. Zunächst werden verschiedene TCP Handover
Optimierungen im Zusammenhang mit dem Mobile IPv6 Protokoll vorgestellt. Im zweiten Schritt
wird die Eignung dieser Verfahren für verschiedene Handover Szenarien untersucht, und der
vielversprechendste Vorschlag (die sog. Home Agent Buffering Methode) wird mit der Handover-
Funktionalität von LDACS1 integriert. Schließlich wird die Leistungsfähigkeit der Home Agent
Buffering Methode näher untersucht. Diese wird gemessen an der Zeit, die für eine vollständige
Dateiübertragung über eine TCP Verbindung benötigten wird. Durch diese Methode wird die
erforderliche Zeit für die Übertragung einer Datei von 110 kB um mindestens 10% reduziert.
Im dritten Teil werden verschiedene Radio Resource Management (RRM) Algorithmen für
LDACS1 analysiert, da die Ressourcen möglichst gleichmäßig auf die verschiedenen Nutzer
verteilt werden sollen. Dies ist nicht nur aus Gründen der Fairness wichtig, sondern auch für die
Einhaltung der Anforderungen der ATS/AOS Nachrichten bzgl. Expiration Time und Latenzzeit.
Hierzu untersuchen wir verschiedene RRM Algorithmen in Bezug auf Bandbreite und Fairness der
end-to-end Verzögerung. Wir schlagen außerdem einen neuen, modifizierten Deficit Round Robin
Algorithmus vor, der für die Übertragung in beide Richtungen (d.h. Forward und Return Link)
verwendet werden kann und nahezu perfekte Fairness zwischen den verschiedenen Nutzern
garantiert.
Im letzten Teil der Arbeit werden verschiedene Verfahren zur NEMO Routenoptimierung
(RO) analysiert, die das Problem des Dreieck-Routings bei NEMO lösen sollen. Durch NEMO RO
wählen die Datenpakete einen kürzeren Pfad zwischen den Endpunkten einer Verbindung, so
dass die gemessene end-to-end Verzögerung und die Länge des Pfades reduziert werden. Die
meisten dieser NEMO RO Methoden wurden als Internet Engineering Task Force (IETF) drafts
veröffentlicht. Wir stellen fest, dass manche dieser Vorschläge zusätzliche Funktionalität für die
Lösung des Mobilitätsproblems den Endknoten erfordern, andere hingegen nicht. Darüber hinaus
versuchen einige Vorschläge, das Nested NEMO Problem zu lösen, ohne dabei das Problem der
Routenoptimierung anzugehen. Außerdem mangelt es einigen der vorgeschlagenen Protokolle,
da sie in der Regel nur als IETF drafts veröffentlicht werden, an der erforderlichen Reife und
Erfahrungen mit praktischen Implementierungen. Angesichts dieser Probleme untersuchen wir
vor allem infrastrukturbasierte NEMO RO Lösungen, nämlich die Home Agent to Home Agent
(global HAHA) und Correspondent Router (CR) Protokolle, aus der Perspektive des ATN/IPS,
das im ersten Teil der Arbeit vorgestellt wurde. Danach schlagen wir zwei neue Ansätze für das
globale HAHA Protokoll vor, um die end-to-end Verzögerung und den Signalisierungs Overhead
durch die Lösung für das Mobilitätsproblem zu verringern.
Contents
Abstract iii
Kurzfassung v
1 Introduction 1
1.1 Main Challenges in the ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Services in the ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Airspace Domains in the ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Stake Holders in the ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 Air/Ground Communications Service Provider . . . . . . . . . . . . . . . . . 3
1.4.2 Air Navigation Service Provider . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.3 Airlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Future Communication Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.1 Aeronautical Telecommunications Network . . . . . . . . . . . . . . . . . . 4
1.5.2 New Radio Access Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Goal of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7 Structure of Thesis and Main Contributions . . . . . . . . . . . . . . . . . . . . . . . 7
2 Fundamentals 9
2.1 LDACS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 LDACS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 LDACS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Detailed Explanation of LDACS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Message Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Resource Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.4 ARQ Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.5 Handover Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.6 Handling of Control Message Losses . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 Dynamic Home Agent Address Discovery . . . . . . . . . . . . . . . . . . . . 16
2.4 Network Mobility (NEMO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
vii
Contents viii
2.5 Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.1 Address Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.2 Duplicate Address Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.3 Neighbor Unreachability Detection . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 IEEE 802.21 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7 Reliable Transport with TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.1 TCP Reno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.2 TCP NewReno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8 Simulation Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8.1 LDACS1 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8.2 Network Layer Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Handover Optimizations 25
3.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Performance Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Considered Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2 Handover Performance with ARQ Mechanism . . . . . . . . . . . . . . . . . 27
3.2.2.1 High BER Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2.2 Low BER Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Reducing Router Advertisement Overhead . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.1 Proposal 1 - Using IEEE 802.21 Event Services . . . . . . . . . . . . . . . . 28
3.3.2 Proposal 2 - Transmission of Stored Router Advertisement Message . . . . 30
3.3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.4 Overhead Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Proposal 3 - Removing Duplicate Address Detection . . . . . . . . . . . . . . . . . . 32
3.5 Proposal 4 - Speeding Up Handovers in Congested Cells . . . . . . . . . . . . . . . 33
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 TCP Analysis with LDACS1 35
4.1 TCP Optimizations for Mobile IPv6 Handovers . . . . . . . . . . . . . . . . . . . . . 35
4.1.1 Access Router Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.2 Base Station Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.3 Home Agent Bi-casting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.4 Analysis of Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Home Agent Buffering for Inter Access Network Handovers . . . . . . . . . . . . . 38
4.3 Performance Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Received Power and Wireless Channel Errors . . . . . . . . . . . . . . . . . 39
4.3.2 Network Layer Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.3 Transport and Application Layer Considerations . . . . . . . . . . . . . . . . 41
4.3.4 Further Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.5 Simulation Results and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.5.1 Unlimited LDACS1 Buffer Size . . . . . . . . . . . . . . . . . . . . . 43
Contents ix
4.3.5.2 Limited LDACS1 Buffer Size . . . . . . . . . . . . . . . . . . . . . . 45
4.3.6 Relation Between Handover Completion Time and TCP RTO Expiry Time 47
4.3.7 Mobility Signaling Message Loss Conditions in Home Agent Buffering
Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.8 Impact of Signaling Message Losses on the Handover Performance . . . . 48
4.3.9 Home Agent Buffering Load Considerations . . . . . . . . . . . . . . . . . . 49
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5 Radio Resource Management 51
5.1 Scheduling Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1.1 QoS Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.2 Time Complexity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Modified Deficit Round Robin with Fragmentation . . . . . . . . . . . . . . . . . . . 53
5.3 Fair-Share Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4 Randomized User Selection Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.5 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.5.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.5.2 Considered Topology and Simulation Parameters . . . . . . . . . . . . . . . 58
5.5.3 File Transfer Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.5.3.1 Modified Deficit Round Robin Scheduling . . . . . . . . . . . . . . 59
5.5.3.2 Fair-Share Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.5.3.3 Randomized User Selection Scheduling . . . . . . . . . . . . . . . 60
5.5.4 Real-time Service Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.5.4.1 Underloaded Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.5.4.2 Overloaded Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6 NEMO Route Optimization Analysis 66
6.1 NEMO Route Optimization Classification . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2 Global HAHA Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2.1 New Mobility Header Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2.2 Inter HAHA Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2.3 Multihoming Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2.3.1 Multiple CoA Registration . . . . . . . . . . . . . . . . . . . . . . . 69
6.2.3.2 Flow Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.3 Correspondent Router Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.3.1 New Mobility Header Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.3.2 New ICMPv6 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.4 Analysis of Infrastructure Based NEMO RO Methods . . . . . . . . . . . . . . . . . 72
6.5 Network Attachment Scenarios and NEMO RO Usage . . . . . . . . . . . . . . . . . 74
6.5.1 Global HAHA Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.5.2 Correspondent Router Configurations . . . . . . . . . . . . . . . . . . . . . . 74
Contents x
6.6 Home Agent Selection Methods in Global HAHA Networks . . . . . . . . . . . . . 75
6.6.1 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.6.2 Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.6.2.1 Static Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.6.2.2 Dynamic Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.6.3 Example Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.6.4 Multiple Home Agent Usage in Global HAHA Networks . . . . . . . . . . . 80
6.7 Context Transfer in Global HAHA Networks . . . . . . . . . . . . . . . . . . . . . . . 83
6.7.1 Internet Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.7.2 Context Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.7.3 Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.7.3.1 Node Initiated Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.7.3.2 Network Initiated Proposal . . . . . . . . . . . . . . . . . . . . . . . 85
6.7.4 Overhead and Delay Comparisons . . . . . . . . . . . . . . . . . . . . . . . . 86
6.7.5 Further Discussions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.7.5.1 SPI Collision Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.7.5.2 Authorization Token Generation . . . . . . . . . . . . . . . . . . . 88
6.7.5.3 Number of Home Agent Switches . . . . . . . . . . . . . . . . . . . 89
6.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7 Conclusions 90
A Mobile IPv6 Overhead Analysis 92
B LDACS1 Physical Layer Configurations 94
List of Acronyms 96
Bibliography 105
Chapter 1
Introduction
Air Traffic Management (ATM) can be defined as the process, procedures and resources that are
used to make sure that aircraft are safely guided in the skies and on the ground1. It is composed
of different systems such as airspace management, air traffic flow, capacity management and
air traffic control. In 2003, EUROCONTROL and the Federal Aviation Administration agreed to
undertake a joint study called Future Communications Study in order to investigate possible
radio access technologies that will be used for ATM operations in the time frame of 2020-2030.
The study consists of mainly two activities:
• Identification of future communication requirements to support the future ATM concepts.
The results are published in the Communication Operating Concept Requirements (COCR)
document [1] in May 2007.
• Assessment of different radio access technologies based on the requirements in COCR.
The results are published in the technology assessment document [2] in October 2007.
Following the technology assessment report, an action plan [3] is published in November
2007.
1.1 Main Challenges in the ATM
The COCR document considers two phases of communications to support the ATM as shown
in Fig. 1.1. In phase 1, voice communication is the primary means of communication for the
provision of ATM, whereas in phase 2, data communication is the primary means of communica-
tion and voice is only used for exceptional circumstances. The document provides two sets of
requirements for phase 1 and phase 2 for different ATM services. These requirements are mainly
latency, “expiration time”, integrity, continuity, “availability of provision” and “availability of
use” that will be used as a basis for selecting the Future Communications Infrastructure (FCI)
including the future radio access technologies.
Furthermore, some new future services like Voice over IP (VoIP) and sensor data transmission
for the aircraft health management also add additional requirements since these services require1see http://www.eurocontrol.int/articles/what-air-traffic-management.
1
1.1 Main Challenges in the ATM 2
COCR Version 2.0
16
provision of ATM. Figure 1-1 illustrates the expected timeframe of Phase 1 and Phase 2.
In Phase 1, voice communications capabilities remain central to the provision of ATM. In Phase 2, voice is only used for exceptional circumstances or for areas that do not require/have data communications implementation. In Phase 2, the ATM paradigm shifts from a tactical “Management by Intervention” to a strategic “Management by Planning and Intervention by Exception.”
The FRS should, at a minimum, support the required air-ground and air-air data communications. The data communications may be broadcast, multicast, and/or addressed. Voice communication may be supported provided the FRS meets the voice requirements in the document.
Figure 1-1: Phase 1 and Phase 2 Concept Evolution Over Time
In some regions of the world, Phase 1 data communications services are already being introduced through trials or implementation programmes. Other regions may begin Phase 1 implementation at any time, or not at all, based on their ATM needs. Similarly, the more advanced services described in Phase 2 may never be implemented in some regions for various reasons such as lower traffic density or lack of an adequate business case. This is depicted in Figure 1-1 by the dashed lines showing continued use of Phase 1 concepts in some regions while others have implemented those defined under Phase 2.
The performance requirements provided in this document are a “snapshot” of what demands a full set of Phase 1 services anticipated to be in place in some regions around 2020 would place on the communications system. The performance requirements for Phase 2 represent the same for a fully matured set of services anticipated to be in place in some regions in the 2030 timeframe.
A particular aircraft or ground system is not required to implement any of the services contained in this document. Coordination between the regional stakeholders will determine the operational services that benefit the local environment as part of a global infrastructure.
1.2 Scope The scope of the COCR document is to identify concepts, requirements, and trends that will be the basis for selecting the FRS. Air Navigation Service Providers (ANSPs) and industry are in the formative stages of determining many of the
Phase 1
2025 2020 2015 2010 2030 2035
Phase 2
2005
Figure 1.1 – Phase 1 and Phase 2 concept evolution over time [1].
“real-time” and “near-real-time” transmission of certain information with low latency and high
availability.
In addition to the low latency and high availability requirements, there is another important
requirement in terms of data capacity. As mentioned above, when the data communication
is used as a primary means of communication in phase 2, there will be strong demand for
high capacity radio access technologies since the state of the art technologies like VHF Data
Link Mode 2 (VDLm2) will go to saturation. In parallel, according to STATFOR statistics, the
number of flights in Europe will be around 17 million in 2030 annually, which is 1.8 times more
than in 2009 [4]. For these reasons, new radio access technologies (such as L-Band Digital
Aeronautical Communications System Option 1 (LDACS1)) that are developed for the time frame
of 2020-2030 should be capable of handling the data traffic demands of the future ATM.
1.2 Services in the ATM
In today’s ATM, there are mainly two communication services available, namely Air Traffic
Services (ATSs) and Airline Operations Services (AOSs) [5]. ATS is used to provide navigation,
control, and situational awareness services to the aircraft and AOS is used for business operations
of airline companies. Currently, these services are primarily performed by using analogue voice
communication technologies. However, it is already known that digital data communication
utilizes the bandwidth more efficiently and overall is much less error-prone than analogue
voice communication. In addition, only with data communications new ATM concepts like 4D-
trajectory exchange and graphical weather information transmission is possible. Furthermore,
two new services are also under discussion which are VoIP traffic [6] and transmission of sensor
data for the aircraft health management [7] for the future ATM.
1.3 Airspace Domains in the ATM
As defined in the COCR document [1], different ATS and AOS communication services are used
by an aircraft depending on its position. According to the COCR [1] airspace is divided into four
separate domains, namely, Airport (APT), Terminal Manoeuvring Area (TMA), En-Route (ENR)
and Oceanic, Remote, Polar (ORP) as shown in Table 1.1.
1.4 Stake Holders in the ATM 3
Airspace Domain COCR Definition [1]
APT Consists of an airspace of 10 miles in diameter andup to 5000 feet. It also includes airport surfaceand immediate vicinity of the airport.
TMA Consists of an airspace surrounding an airport,starting at 5000 feet up to Flight Level 245. The TMAdomain radiates out 50 Nautical Mile (NM) fromthe center of an airport.
ENR Consists of an airspace that surrounds TMAdomain starting at Flight Level 245 to Flight Level 600.It is the continental or domestic airspace. COCRassumes ENR has a horizontal limit extending300 NM by 500 NM.
ORP This is the same as ENR domain, except it isassociated with geographical areas outside ofdomestic airspace. COCR assumes ORPhave a horizontal limit extending 1000 NMby 2000 NM.
Table 1.1 – Airspace domain definitions [1].
1.4 Stake Holders in the ATM
This section provides a general description about main stake holders in the ATM that are relevant
for this thesis.
1.4.1 Air/Ground Communications Service Provider
An Air/Ground Communications Service Provider (ACSP) operates an access network that in-
cludes different radio access technologies. Global ACSPs utilize terrestrial and satellite link
technologies to provide ATS/AOS services that have a world-wide network and they are compa-
rable to the tier 1 service providers in the Internet. Each global ACSP operates VDLm2 as the
state of the art radio access technology for TMA and ENR stages of flight. The VDLm2 provides
a nominal throughput of 31.5 kbit/s for all aircraft within a single cell. In addition global ACSPs
utilizes different satellite technologies for ORP regions. In the future, it is also foreseen that
there will be local ACSPs that operate in the local domains such as only in airport domain.
1.4.2 Air Navigation Service Provider
An Air Navigation Service Provider (ANSP) manages the air traffic within a country or geographic
region. Generally each ANSP has its own sub-network. An ANSP might also be a local ACSP
within that geographical region by operating its own radio access technology, which might be
due to security or cost motivations. Although International Civil Aviation Organization (ICAO)
has an influence on ANSPs, these organizations also have their own network policies.
1.4 Stake Holders in the ATM 4
1.4.3 Airlines
Airline Operations (AOs) is used for managing the business operations of the aircraft that belong
to a certain airline. Generally each AO has its own sub-network on the ground.
1.5 Future Communication Infrastructure
Fig. 1.2 shows the Future Communications Infrastructure (FCI) of the ATM which is composed
of different components from end-to-end communication perspective. This infrastructure is used
by ANSPs and airlines in order to communicate with the aircraft.
1.5.1 Aeronautical Telecommunications Network
The Aeronautical Telecommunications Network (ATN) is one of the main components of the FCI
which is composed of different networking elements. The existing ATN standard is published by
ICAO as Standards and Recommended Practices (SARPS) [8] document that defines the ATN
based on the International Organization for Standardization (ISO) Open Systems Interconnection
(OSI) reference model. The standard covers the definition of the protocol stack from layer 3 to
layer 7. The specification adapts the Inter Domain Routing Protocol (IDRP) at the network layer
not only for routing on the ground network but also to support mobility of aircraft. This version
of the ATN is only partially deployed at the present time.
ICAO recently produced a new ATN standard based on IPv6 protocol suite called Aeronautical
Telecommunications Network using Internet Protocol Suite (ATN/IPS) [9] as shown in Fig. 1.3.
COCR Version 2.0
18
processors, applications, and networks) needed for the ANSP, AOC, and aircraft to communicate with each other.
Figure 1-2: Scope of the Future Radio System (FRS) as part of the FCI
1.4 Approach To determine the overall context for future communications, numerous concepts of operations, vision statements, and plans being developed and circulated by ANSPs around the world were reviewed. These are identified in the document reference list in Section 1.6.
The following steps describe the approach adopted in producing the communication operating concepts and requirements for the FRS.
1. Develop notional vision and universal operating concepts for air traffic management.
2. Identify and define the ATS and AOC required services.
3. Define the operating environment, in which these services would be provided, to ensure all implications of each service were addressed.
4. Perform safety, information security, and performance assessments for the air traffic services.
Figure 1.2 – Future communications infrastructure [1].
1.5 Future Communication Infrastructure 5
ATN/IPS mandates Mobile IPv6 (MIPv6) protocol as the main mobility management protocol
and mentions Network Mobility (NEMO) as an optional protocol for air-ground communications.
Network Components in ATN/IPS
There are different networking components inside the ATN/IPS. Here, four main components
that are relevant for this thesis are defined.
Mobile Network Nodes
Mobile Network Node (MNN) is a node located within a mobile network, either permanently or
temporarily. An MNN might be either a Local Fixed Node (LFN) or a Local Mobile Node (LMN)
[10]. ATS and AOS domains have MNNs that are primarily LFNs, though potentially there could
be some LMNs [5]. They are operated by and are under control of the airline, although ICAO
regulations and standards affect ATS MNNs.
Mobile Router
Mobile Router (MR) is a router onboard which is also called “airborne router” in the aviation
environment. It is reasonable to assume that in the future there will be one IPv6-based MR on
each aircraft that handles both ATS and AOS traffic, as the radio access technologies provide
support for both services. Additional MRs may be on board for fault tolerance reasons or for
passenger communication services.
Home Agent
A Home Agent (HA) is a router in mobile node’s home network that maintains reachability
information about the current point of attachment of mobile node in the network [11]. We
assume each HA serves both ATS and AOS domains.
Application Layer
Transport Layer (TCP, UDP)
Network Layer (IPv6)
Link Layer
Application Layer
Transport Layer (TCP, UDP)
Network Layer (IPv6)
Link Layer
Local or intra-domain
subnetwork
Network Layer (IPv6, BGP-4)
Link Layer
Network Layer (IPv6, BGP-4)
Link Layer
Inter-domain subnetwork
Local or intra-domain
subnetwork
Figure 1.3 – ATN/IPS protocol architecture [9].
1.5 Future Communication Infrastructure 6
Correspondent Nodes
ATS Correspondent Nodes (CNs) are ATS units that refer to air traffic controllers managing
a certain air space, along with some non-controlling CNs that may provide weather or air-
traffic flow-control information. These nodes are located within ANSP networks and generally
dynamic; as the aircraft traverses different regions of the world, the responsible ATS unit changes.
Generally ATS CNs are geographically close to the aircraft, whereas AOS CNs are located in an
AO network that might be distant from the aircraft. Within the AO network, AOS CNs could be
at airline headquarters/operations center or at the arrival or destination airport. These nodes
are relatively static throughout a flight [5].
1.5.2 New Radio Access Technologies
Another main component of the FCI is the radio access technologies. The main motivation
for considering new radio access technologies in the ATM is due to more data capacity need
since with the usage of data communication links as a primary means of communication, the
state of the art technologies will reach to saturation. For this purpose, EUROCONTROL and the
Federal Aviation Administration concluded a study with selected radio access technologies [3] for
different airspace domains as shown in Table 1.2. Chapter 2 will provide further details related
to the LDACS1 technology which this thesis considers as a baseline radio access technology.
Airspace Domain Applicable Technology
APT Surface IEEE 802.16e,LDACS may be possible in some areas
APT, TMA, ENR LDACS,Satellite-based may be possible in some areas
ORP Satellite-basedAir/Air LDACS
Table 1.2 – Airspace domains with selected technologies.
1.6 Goal of the Thesis
There are two main goals of the thesis considering the requirements mentioned in Section 1.1.
The first goal is to design novel mobility and handover management algorithms that improve
the performance of state-of-art mechanisms so that aircraft perform layer 2 and layer 3 handovers
as fast as possible in order not to affect any service which requires low-latency and high service
availability. In addition, these methods should minimize packet drops during handover by some
means (e.g., packet buffering) so that packets can be delivered to the end systems before their
expiration times are exceeded [1]. Another part of improvements is to reduce signaling overhead
in the wireless link since it is the main bottleneck between communicating end nodes and as
mentioned in Section 1.1, future radio access technologies should be capable of handling the
data traffic demands of future ATM considering air traffic growth mentioned by the STATFOR [4].
1.6 Goal of the Thesis 7
The second goal is to design a radio resource management architecture including design
of different algorithms for LDACS1 in order to distribute available resources evenly among
different number of users (especially in case LDACS1 is highly loaded with many users). This is
also important to comply with the “expiration time” and “latency” requirements of ATS/AOS
messages [1].
1.7 Structure of Thesis and Main Contributions
In the second chapter, we will present some important aspects of LDACS1 and IPv6-based mobile
networking principles that are required for understanding and analyzing the contributions of
the thesis. In chapter 3, different handover optimization techniques are explained in order to
reduce handover delay and handover signaling overhead in LDACS1. The main contributions of
this work are published in:
• Ayaz, Serkan; Hoffmann, Felix; Sommer, Christoph; German, Reinhard; Dressler, Falko
“Performance Evaluation of Network Mobility Handover over Future Aeronautical Data Link.”GLOBECOM 2010, Miami, Florida USA, December, 2010 [12].
• Bauer, Christian; Ayaz, Serkan “A Thorough Investigation of Mobile IPv6 for the AeronauticalEnvironment.” VTC Fall 2008, IEEE Vehicular Technology Conference, Calgary, Canada,
2008 [13].
In chapter 4, different TCP handover optimizations related to Mobile IPv6 protocol are investi-
gated and the most promising approach (home agent buffering) is integrated with LDACS1. This
technique is mainly used for reducing the transmission completion time of on-going Transmission
Control Protocol (TCP) sessions during the handover process. The main contribution of this
work is published in:
• Ayaz, Serkan; Hoffmann, Felix; Epple, Ulrich; German, Reinhard; Dressler, Falko “Per-formance Evaluation of Network Mobility Handover over Future Aeronautical Data Link.”Computer Communications (Elsevier), February, 2012 [14].
Chapter 5 considers Radio Resource Management (RRM) topic for LDACS1. Three differ-
ent RRM algorithms are analyzed and a new Deficit Round Robin (DRR) with fragmentation
algorithm is developed. The new algorithm can be used not only in forward link but also in the
return link. The main contribution of this work is published in:
• Ayaz, Serkan; Hoffmann, Felix; German, Reinhard; Dressler, Falko “Analysis of DeficitRound Robin Scheduling for Future Aeronautical Data Link.” PIMRC 2011, Toronto, Canada,
September, 2011 [15].
In chapter 6, different NEMO route optimization protocols are investigated. Two new
approaches are proposed which optimize the global Home Agent to Home Agent (HAHA)
protocol in terms of end-to-end delay performance and mobility signaling overhead. The main
contributions of this work are published in:
1.7 Structure of Thesis and Main Contributions 8
• Ayaz, Serkan; Bauer, Christian; Ehammer, Max. “Applying IKE/IPsec Context Transfer toAeronautical Networks.” Mobiwac 2009, Teneriffe, Spain, October, 2009 [16].
• Ayaz, Serkan; Bauer, Christian; Arnal, Fabrice. “Minimizing End-to-End Delay in GlobalHAHA Networks Considering Aeronautical Scenarios.” Mobiwac 2009, Teneriffe, Spain,
October, 2009 [17].
• Ayaz, Serkan; Bauer, Christian; Eddy, Wesley M.; Arnal, Fabrice. “NEMO Route OptimizationSolution Space Analysis and Evaluation Criteria for Aviation.” 8th Conference on Intelligent
Transport System Telecommunications (ITST), Phuket, Thailand, October 2008 [18].
• Ayaz, Serkan; Bauer, Christian; Ehammer, Max; Gräupl, Thomas; Arnal, Fabrice. “MobilityOptions in the IP-based Aeronautical Telecommunication Network.” ICT MobileSummit 2008,
Stockholm, Sweden, 2008 [19].
Chapter 2
Fundamentals
This chapter provides some important aspects of future aeronautical mobile networks that are re-
quired for understanding and analyzing the main contributions of this thesis in the following chap-
ters. These aspects are mainly L-Band Digital Aeronautical Communications System (LDACS),
mobility management based on MIPv6, IEEE 802.21 specification and TCP. The last section also
provides information about our simulation platform.
2.1 LDACS
EUROCONTROL and the Federal Aviation Administration are currently considering two candidate
radio access technologies for the future provision of ATS and AOS services in the L-band2. These
technologies are referred to as LDACS option 1 [20] and option 2 [21]. Initial specifications for
both technologies have been published by EUROCONTROL, and it is planned that one of these
two systems will become operational in the time frame of 2020-2030.
As mentioned in [22], one of the main system requirements of LDACS is to deliver certain
ATS and AOS information in a timely manner with minimized service disruption. Furthermore,
it shall also support multiple QoS offerings, such as priority and preemption capabilities. As
mentioned in chapter 1, some new future services like VoIP and sensor data transmission for the
aircraft health management requires “real-time” and “near-real-time” transmission of certain
information with low latency and high availability. For these reasons, it is important for LDACS
has not only advanced RRM techniques for different Class of Service (CoS) applications but also
advanced handover mechanisms for seamless mobility across different access networks.
2.1.1 LDACS1
LDACS1 has originated from the “Broadband-Aeronautical Multi-Carrier Communications (B-AMC)”
system and the “Project 34 standard of the Association of Public Safety Communications Officials”.
It is designed for the transmission of both digital voice and data. In LDACS1, Return Link (RL)
and Forward Link (FL) are separated by means of Frequency Division Duplex (FDD). In the RL,
a combination of Orthogonal Frequency-Division Multiple-Access (OFDMA) and Time-Division2see http://www.eurocontrol.int/communications/.
9
2.1 LDACS 10
Multiple-Access (TDMA) is used, whereas in the FL, Orthogonal Frequency-Division Multiplex-
ing (OFDM) is applied. The TDMA component in the RL is selected in order to minimize the
possibility of interference with legacy systems which are operating on board on aircraft in the
L-band, e.g. the distance measuring equipment. This is important since an LDACS1 transmitter
operates close to other receivers on board, so it should only be active for a short time, reducing
these receivers’ exposure to interference. The modulation and coding scheme of LDACS1 can be
adapted to the channel state and, thus, implements adaptive coding and modulation. With that,
the throughput varies between 291 kbit/s . . . 1318 kbit/s in the FL (assuming 24 data channel
physical layer Protocol Datagram Units (PDUs) and 3 common control channel physical layer
PDUs per multiframe (MF)) and 220.3 kbit/s . . . 1038.4 kbit/s in the RL (assuming average ded-
icated control channel duration of 15.84 ms per MF) [20]. Section 2.2 will provide detailed
information about LDACS1 features.
2.1.2 LDACS2
L-Band Digital Aeronautical Communications System Option 2 (LDACS2) has originated from
the “L-Band Digital Link” and “All purpose Multi-channel Aviation Communication System”
technologies. It is designed for transmission of digital data only. RL and FL are separated
by means of Time-Division Duplex (TDD) and Gaussian minimum shift keying is the only
supported modulation type. The available spectrum is in the range of 960 MHz . . . 975 MHz
and is partitioned into a number of channels of 200 kHz bandwidth each. A gross data rate of
270 kbit/s is offered by LDACS2. It is a TDMA system applying a 1 s of frame length as shown in
Fig. 2.1. The forward link sub-frames (UP1 & UP2) are used by the base station to send messages
to aircraft. These messages contain user data, acknowledgements, Clear-To-Send and framing
messages. UP1 also contains a broadcast region which notifies the aircraft about the transmit
and receive opportunities. The return link sub-frames (CoS1 & CoS2) carry information about
user data, Request-To-Send, acknowledgements and Keep-Alive messages and login sub-frame is
used to transmit the login request.
UP1 UP2
Forward Link
Return Link
Forward Link
Return Link
Login(Return Link)
Figure 2.1 – LDACS2 frame structure.
2.2 Detailed Explanation of LDACS1
This section provides the main features of LDACS1 considering frame structure, resource alloca-
tion procedures, Automatic Repeat Request (ARQ) mechanism and handover types.
2.2 Detailed Explanation of LDACS1 11
2.2.1 Message Abbreviations
Table 2.1 provides LDACS1 specific messages with their corresponding channel types and abbre-
viations that are used in this thesis.
2.2.2 Frame Structure
The frame structure is shown in Fig. 2.2. Time is divided into superframes with a duration
of 240 ms. At the beginning of each superframe, aircraft have the opportunity to log onto the
network using a Random Access Channel (RACH), whereas the Base Station (BS) transmits
general cell information in the Broadcast Channel (BCCH). The rest of the superframe consists of
four multiframes, each with a duration of 58.32 ms and consisting of both data and control frames.
In the FL, the BS transmits control information, such as resource allocations, i.e., FL mapping
and RL mapping, and acknowledgments on the Common Control Channel (CCCH). In the RL,
each aircraft is assigned one slot per multiframe within the Dedicated Control Channel (DCCH)
for the transmission of control data. At most, 52 aircraft can be accommodated within the DCCH.
If more than 52 aircraft are registered with a single BS, not all aircraft will receive a DCCH slot
in every multiframe. Both the CCCH and DCCH are of variable length to allow efficient use of
the wireless resources.
2.2.3 Resource Allocation
Before any transmission can take place, either in the RL or the FL, resources must be requested
from the BS. At the beginning of a CCCH slot, the BS considers all received resource requests (sent
via an RSRC_RQST message) since the last CCCH slot and distributes the FL and RL resources. For
the FL transmissions, Data Link Service (DLS) module inside the BS sends the resource requests
to Link Management Entity (LME) module and for the RL transmissions, each aircraft sends its
Abbreviation Message Name Channel Type
POW_REP Power Report Dedicated ControlKEEP_ALIVE Keep Alive Dedicated ControlCELL_EXIT Cell Exit Dedicated ControlRSRC_RQST Resource Request Dedicated ControlCELL_RQST Cell Request Random AccessHO_COM Handover Command Common ControlCELL_RESP Cell Response Common ControlSLOT_DESC Slot Descriptor Common ControlFL_ALLOC Forward Link Allocation Common ControlRL_ALLOC Return Link Allocation Common ControlADJ_CELL_BC Adjacent Cell Broadcast Broadcast ControlSC_TABLE_BC Scanning Table Broadcast Broadcast ControlSYS_ID_BC System Identification Broadcast Broadcast Control
Table 2.1 – LDACS1 message types and corresponding abbreviations.
2.2 Detailed Explanation of LDACS1 12
RA(6.72 ms)
Multi-Frame 1(58.32 ms)
Multi-Frame 2(58.32 ms)
Multi-Frame 3(58.32 ms)
Multi-Frame 4(58.32 ms)
BC(6.72 ms)
Multi-Frame 1(58.32 ms)
Multi-Frame 2(58.32 ms)
Multi-Frame 3(58.32 ms)
Multi-Frame 4(58.32 ms)
variable
variable
Figure 2.2 – LDACS1 frame structure.
resource request via RSRC_RQST message in a DCCH slot. After the BS allocates resources for the
FL and RL, i.e., TDMA slots and OFDMA subchannels, for the aircraft, it informs each aircraft
about the FL and RL allocations via FL_ALLOC and RL_ALLOC messages in the CCCH slot. With
FL_ALLOC message, each aircraft knows which part of the multiframe that will be received in
the next FL data slot belong to itself and with RL_ALLOC message, each aircraft knows when
it is allowed to transmit and on which subchannels in the next RL data slot. The scope of this
resource allocation is shown in Fig. 2.3. The exact scheduling algorithm to be used by the BS is
left open by the LDACS1 specification. In chapter 5, we propose a scheduling architecture for
LDACS1 and analyze the performance of different scheduling algorithms.
variable variable
variable variableScope of FL MAP Scope of RL MAP
Figure 2.3 – LDACS1 resource allocation structure.
2.2.4 ARQ Mechanism
LDACS1 supports both unacknowledged and acknowledged data transfer modes. Due to the
rigid frame structure of the LDACS1 protocol, a sender knows when it should expect an acknowl-
edgment for data that it has transmitted. After one missed acknowledgment opportunity, a packet
is retransmitted. After a certain number of subsequent retransmissions, the entire transmission
is aborted and the packet is discarded at the transmitter. Note that the entire process of resource
request and allocation must again be performed before the lost packet can be retransmitted.
2.2 Detailed Explanation of LDACS1 13
2.2.5 Handover Types
Two different types of handover are foreseen by the LDACS1 specification. In both handover
types, the BS polls the aircraft to provide power reports of their received signal strength.
Polling of neighboring cells’ received signal strength is requested by transmitting the SC_-
TABLE_BC message in the BCCH channel. In the upcoming BCCH channel, the aircraft switches
to the next BS frequency and measures the received power by listening the SYS_ID_BC message
from neighboring BS. It then sends a POW_REP message to the current BS. If the adjacent cell’s
received power level is higher than that of the current cell, the current BS triggers a HO_COM
message to the new cell.
In the case of a type 1 handover, the aircraft simply confirms the handover, sends a CELL_EXIT
message to the current BS, and switches to the channel of the next BS, where it registers via
the new base station’s RACH by sending a CELL_RQST message. If no collision has occurred on
the RACH, the BS will respond with a CELL_RESP on the CCCH and assign a subscriber access
code and a DCCH slot to the aircraft. In the case of a collision on the RACH, the aircraft does
not receive this response and will perform an exponential backoff, attempting to access the
RACH again later. In this thesis, we only consider type 1 handover since it does not require any
signaling between BSs and is more suitable for inter-access network handovers. The details of
type 2 handover can be found in LDACS1 specification [20].
2.2.6 Handling of Control Message Losses
In this section, we will summarize how the system reacts if one of the LDACS1 control messages
is lost during the transmission.
An aircraft sends a KEEP_ALIVE message in order to inform the BS that it is still connected.
After a certain amount of KEEP_ALIVE messages is not received by the BS, it de-registers the
aircraft from its connected aircraft list. If a POW_REP is lost, the BS continues to use the last
measured value if it is available. If no information is available (which is the case during the first
scanning request of the neighboring cell), the BS should wait for the next POW_REP message in
order to decide whether a handover is needed. If a HO_COM is lost, the BS will not receive any
CELL_EXIT in the upcoming DCCH slot and will send another HO_COM in the next CCCH slot.
If a CELL_RQST is lost, the aircraft sends another CELL_RQST in the upcoming random access
slot, which is at the beginning of the next superframe (i.e., after 240 ms). If a CELL_RESP is lost,
the aircraft again sends another CELL_RQST and thus causes another CELL_RESP to be sent from
the BS. If a CELL_EXIT is lost, the BS will consequently not receive any more KEEP_ALIVE messages
from that aircraft, so eventually the system will react as outlined above. If an RSRC_RQST is
lost, the aircraft sends another request in the upcoming DCCH slot. If an FL_ALLOC is lost, the
allocated portion in the upcoming FL multiframe is not known by the aircraft and the associated
packets are not received by the aircraft. If an RL_ALLOC is lost, the allocated slot information in
the upcoming RL multiframe is not known by the aircraft and the associated packets are not
sent by the aircraft. If an SC_TABLE_BC carrying a scanning request of the next BS is lost, the
aircraft will not start scanning of the next BS and can not send the POW_REP of the next BS to the
2.2 Detailed Explanation of LDACS1 14
current BS in the upcoming DCCH slot. The BS should again send another SC_TABLE_BC in the
upcoming BCCH slot. Similarly, if an SYS_ID_BC is lost during the scanning of the neighboring
BS, the aircraft can not send the POW_REP of the next BS to the current BS in the upcoming
DCCH slot. The BS should again send another SC_TABLE_BC in the upcoming BCCH slot. Finally,
if a SLOT_DESC is lost, the aircraft cannot identify the length of the current CCCH slot and the
upcoming DCCH slot. So, it does not receive FL data and does not send a resource request for
the upcoming RL multiframe. In general, the aircraft needs to wait for the next multiframe in
order to receive and send data.
2.3 Mobile IPv6
MIPv6 [11] is a mobility management protocol which allows mobile nodes to remain reachable
while moving around in the IPv6 network. Each mobile node is always identified by its Home
Address (HoA), regardless of its current point of attachment to the network. While located
away from its home, a mobile node is also associated with a Care-of Address (CoA), which is
configured from the attached network and provides information about the mobile node’s current
location.
2.3.1 Modes of Operation
In MIPv6, there are two modes of operations; namely bidirectional tunneling and route optimiza-
tion (RO). The bidirectional tunneling mode is the basic operation of MIPv6 such that the Mobile
Node (MN) performs home registration when it is attached to the visiting domain as shown in
Fig. 2.4. With this home registration procedure, the HA is informed about the current point of
network attachment of the MN. MN and HA use a pre-established IPsec security association (SA)
in order to protect the integrity and authenticity of the signaling messages [23]. This mode of
operation does not require any MIPv6 specific operation in the CN. Packets sent from the CN
are first routed to HA and then tunnelled to the MN by the HA. In the reverse direction (i.e.,
from MN to CN) packets are first tunnelled to the HA and then forwarded to the CN by the HA.
RO is the second mode of operation which requires MIPv6 specific operation at the CN since
the MN performs CN registration as shown in Fig. 2.5. The RO mode can be initiated upon
completion of the home registration procedure. The MN first completes Return Routability (RR)
procedure in order to provide a reasonable assurance to the CN that it is addressable at its
claimed CoA as well as at its HoA. After RR procedure completion, the MN exchanges Binding
Update (BU) and Binding Acknowledgment (BA) messages with CN. These messages contain a
keyed message authentication code that is generated by using the binding management key.
There are two main concerns of this procedure from ATN perspective which are security
weaknesses and signaling overhead. Detailed threat analysis of MIPv6 and how the selected RO
solution (i.e., RR procedure) mitigates those threats are presented in [24]. One of the main
vulnerability of RR procedure is its lack of protection against on-path attackers (i.e., attacker is
on the path between HA and CN). As stated in [24], MIPv6 RO design was never intended to be
2.3 Mobile IPv6 15
Figure 2.4 – MIPv6 operation without route optimization.
Figure 2.5 – MIPv6 operation with route optimization.
fully secure, instead, the goal is to have a IPv6 mobility which is “as secure as the (non-mobile)
IPv4 Internet”. Another issue is the overhead due to maximum binding lifetime which is 7
minutes. This means, the procedure should be repeated every 7 minutes which brings certain
overhead considering different aircraft numbers based on cell sizes as shown in Table 2.2. Here,
we assumed that the certain number of aircraft stay around 14 minutes inside the cell and
perform the RR procedure twice. In addition, IPsec overhead, which is applicable to all signaling
messages that are routed over the MR-HA tunnel, is not taken into account. The details of the
message overhead can be found in the Appendix A.
2.3 Mobile IPv6 16
Peak Instantaneous Aircraft Count (PIAC) 200 350 500
Overhead FL (kbps) 1.8 3.15 4.5Overhead RL (kbps) 1.86 3.25 4.65
Total (kbps) 3.66 6.4 9.15
Table 2.2 – MIPv6 RO signaling overhead depend on different PIAC values.
2.3.2 Dynamic Home Agent Address Discovery
In some cases MN may not know the home agent address in advance that it wants to send
binding update message as mentioned in [11]. In such a case, MN uses Dynamic Home Agent
Address Discovery (DHAAD) procedure in order to discover the address of HA that is used. This
procedure defines two new Internet Control Message Protocol for the IPv6 (ICMPv6) messages
which are;
• ICMPv6 Home Agent Address Discovery Request.
• ICMPv6 Home Agent Address Discovery Response.
From operational perspective, the MN sends the request message to the HAs anycast address
for its home subnet prefix. In return, the HA that receives the request message sends a reply
message that includes HA addresses.
2.4 Network Mobility (NEMO)
Internet Engineering Task Force (IETF) standardized a NEMO protocol [25] that provides mobility
support to the end nodes that are located in the mobile network accessed through the MR. The
MR extends mobile host functionality [11] in a way that it provides IP addresses to the connected
end hosts from the assigned Mobile Network Prefix (MNP). In parallel, the HA provides a prefix
table for the home registration of an MR which contains:
• MR HoA used as the key for searching the pre-configured prefix table.
• MNP associated with the MR HoA.
From the operational perspective, NEMO is working the same as MIPv6 bidirectional tun-
neling mode with the same home registration procedure except an additional information (i.e.,
mobile network prefix option) which is carried inside binding update message.
2.5 Neighbor Discovery
The main purpose of the neighbor discovery protocol [26] is to facilitate node-to-node commu-
nication on a link. The protocol defines five different ICMPv6 packet type:
2.5 Neighbor Discovery 17
• A pair of Router Advertisement (RA) and Router Solicitation (RS) messages.
• A pair of Neighbor Advertisement (NA) and Neighbor Solicitation (NS) messages.
• A Redirect message.
Table 2.3 summarizes main functionalities of the protocol that are performed by the nodes
attached to the same link. Among those functionalities, three of them require more attention in
this thesis since these functionalities are related to handover performance. These functionalities
are address autoconfiguration, duplicate address detection and neighbor unreachability detection.
2.5.1 Address Autoconfiguration
When the mobile performs layer 3 handover, it has to configure a new IPv6 address from the
newly attached link in order to continue communication with the other nodes. Generally, IPv6
address autoconfiguration is performed in two ways: stateful or stateless. The dynamic host
configuration protocol allows nodes to configure IP addresses in a stateful manner by maintaining
a IP address pool in dedicated servers. On the other hand, [27] provides nodes to configure the
IPv6 addresses in a stateless way. In this thesis, we consider stateless autoconfiguration as a
baseline approach for globally routable IPv6 address autoconfiguration for mobile nodes. Main
procedures of stateless address autoconfiguration are as follows:
1. Host sends RS message in order to trigger a solicited RA message transmission from the
router.
2. After host receives solicited RA message, it generates a tentative globally routable IPv6
address.
3. Generated address passes Duplicate Address Detection (DAD) procedure and becomes
globally routable IPv6 address for the host.
Normally, RSs are sent to All-Routers multicast address (ff01::2). Instead of sending a RS
message (cf. step 1) in order to receive solicited RA message (cf. step 2), the host can also receive
unsolicited RA message in order to create a globally routable IPv6 address. According to [26],
Neighbor Discovery Functions
Router & Prefix DiscoveryParameter DiscoveryAddress AutoconfigurationLink-layer Address ResolutionNext-hop DeterminationNeighbor Unreachability DetectionDuplicate Address DetectionRedirects
Table 2.3 – Neighbor discovery functions.
2.5 Neighbor Discovery 18
unsolicited RAs are not strictly periodic (i.e., the interval between subsequent transmissions is
randomized). After an RA is sent (to All-Nodes multicast address (ff01::1)), the timer is reset to
a uniformly distributed random value between {MinRtrAdvInterval, MaxRtrAdvInterval}seconds. MaxRtrAdvInterval must be no less than 4 s and no greater than 1800 s. It is
set to 600 s by default. MinRtrAdvInterval must be no less than 3 s and no greater than
{MaxRtrAdvInterval · 0.75}.However, as mentioned in [11], above mentioned values for unsolicited router advertisement
frequency are quite large numbers and not suitable to provide timely movement detection
for mobile nodes. For this reason, [11] specifies smaller MinRtrAdvInterval =0.03 s and
MaxRtrAdvInterval =0.07 s values for routers that support mobility.
2.5.2 Duplicate Address Detection
When the mobile node configures a new IPv6 address from the attached network, this address
is first called “tentative” since its uniqueness is not checked yet. The DAD procedure guaran-
tees the uniqueness of the configured IPv6 on a link by using multicast capability. Normally,
it must be performed on all unicast addresses before they are assigned to an interface. Be-
fore starting the DAD procedure, host must join to the all-nodes multicast address and the
solicited-node multicast address of the tentative address. In order to join solicited-node multi-
cast address, the host should send a Multicast Listener Discovery (MLD) report [28] which is
randomly delayed between 0 and 1 s (i.e., MAX_RTR_SOLICITATION_DELAY) [26]. Afterwards,
it sends DupAddrDetectTransmits times NS messages with source address is unspecified, des-
tination address is set to the solicited-node multicast address of the target address and the
target address is set to the address being checked and waits NA message. If the host sends
DupAddrDetectTransmits time NS message, each separated by Ret ransT imer milliseconds
and receives no NA until the timer expiry, then the host concludes that the address is unique
and assigns it to an interface as a “permanent” address.
2.5.3 Neighbor Unreachability Detection
In general, any node on the end-to-end communication path may fail at any time and the
neighbor unreachability detection mechanism is used to detect such communication failures on
the path [26]. Failures might occur due to many reasons and in our case we focus on the case of
failure due to handover.
Neighbor unreachability detection is a part of movement detection mechanism which is
primarily used for detecting layer 3 handovers [29, 30]. When a mobile changes its point
of attachment, it is important to know whether the network change occurs at layer 2 or at
layer 3. In the case of layer 2 handover, there is not any need to perform above mentioned
procedures since the IPv6 address is still valid. However, in case it is a layer 3 handover, then
above mentioned IP address configuration procedures should be completed. As defined in [26],neighbor unreachability detection generally can use two different information from two sources.
In the first case, upper layer protocols inform the network layer about the status of delivery of
2.5 Neighbor Discovery 19
recently transmitted data (e.g., recently received acknowledgements) which means the neighbor
is still reachable. In the second case, the mobile sends a certain amount of unicast NS messages
each separated by Ret ransT imer milliseconds and waits for NA messages in order to confirm
the reachability of the next hop neighbor. In case mobile does not receive any solicited NA
message, it decides that the neighbor is not reachable and deletes the neighbor cache entry. If it
receives a solicited NA before timer expiry, it changes the state of the entry to “reachable” from
“stale” in the neighbor cache.
2.6 IEEE 802.21 Specification
IEEE 802.21 [31] defines media independent handover services for the mobile nodes that
perform handovers over different radio access technologies. Fig. 2.6 denotes the interaction
between Media Independent Handover Function (MIHF) and radio access technologies and
Media Independent Handover (MIH) users (i.e., upper layers). In the standard, different Service
Access Points (SAPs) are defined such as media independent handover service access point
(MIH_SAP), media independent handover link service access point (MIH_LINK_SAP), logical link
control service access point (LLC_SAP), media independent handover network service access
point (MIH_NET_SAP) which are used for the following purposed;
• MIH_SAP is used to exchange information between MIH users (the upper layer) and MIHF.
• MIH_LINK_SAP is used to exchange information between lower layers of media specific
protocol stacks and MIHF.
• LLC_SAP is used to exchange information between control portion of logical link control
and MIH users for mobility management purposes.
• MIH_NET_SAP is used to carry handover related information either inside the local node
or between local MIHF and remote MIHF as shown in Fig. 2.7. Normally, layer 2 transport
is used to exchange information with remote MIHF located in the same type of network
and layer 3 transport is used when remote MIHF is located in a different type of network.
MIH_LINK_S
AP
MIH_SAP
MIH_LINK_S
AP
MIH_LINK_S
AP
MIH_NET
_SAP
Figure 2.6 – MIH services and their interaction.
Generally, IEEE 802.21 defines the following services:
2.6 IEEE 802.21 Specification 20
MIH_SAP
MIH_NET
_SAP
MIH_NET
_SAP
Figure 2.7 – MIH_NET_SAP service interaction.
• Event Services: Provide general information about Radio Access Technology (RAT) prop-
erties and inform MIH Users about link activities via triggering certain events such as
LINK_GOING_DOWN , LINK_DOWN , LINK_UP , etc.
• Command Services: Provide a set of commands for the MIH users to control the activity
of RATs and perform handover and switch between RATs.
• Information Services: Provide the information about neighboring networks and provided
services like QoS parameters via those access networks thus used for better handover
decisions between different access networks.
In this thesis, we mainly used event services of IEEE 802.21 specification in order to inform
network layer about link layer activities such as LINK_GOING_DOWN , LINK_DOWN and LINK_UP
so that network layer takes required actions in order to perform efficient handovers.
2.7 Reliable Transport with TCP
TCP [32] is adopted by ATN/IPS as the main transmission control protocol for connection-
oriented services at the transport layer. TCP provides a reliable delivery service of application
datagrams between communicating hosts. The main principle of TCP is based on the reception
of acknowledgment segments by the sender for the delivered data segments to the receiver.
The sender records the sending time of each data segment, and retransmit the relevant data
segments in case the timer expires. It also uses sliding window mechanism in order to control
the transmission rate (i.e., flow control). The base protocol [32] mainly specifies TCP states,
state transitions, connection setup and teardown procedures (i.e., 3-way handshake) and data
structures. It is updated by RFCs 5681 [33], 3782 [34] and 2018 [35].
2.7.1 TCP Reno
RFC 2581 [36] is an extension to base TCP specification which is also called “TCP Reno”. In TCP
Reno, four different congestion control mechanisms are defined; namely slow start, congestion
avoidance, fast retransmit and fast recovery. During the slow start phase, the TCP sender in-
creases the congestion window (cwnd) exponentially; meaning that for every acknowledged data
segment, the cwnd is increased by one Maximum Segment Size (MSS). When the cwnd exceeds
the slow start threshold (ssthresh), the congestion avoidance phase starts in the TCP sender. In
this phase, TCP sender increase the cwnd linearly, meaning that for every acknowledged data
segment, the cwnd is increased by MSS2/cwnd as shown in Algorithm 1. In case an in-flight
2.7 Reliable Transport with TCP 21
data segment is lost, TCP receiver asks for the lost segment by sending the sequence number of
the last correctly received (i.e., in-order) data segment in the acknowledgement segment (which
is called duplicate acknowledgements (dupACKs)). In case the sender receives three dupACKs
(i.e., four ACKs acknowledging the same data segment), it enters the fast recovery phase. In this
phase the TCP sender
• Recalculates ssthresh and cwnd as shown in Algorithm 2.
• Performs fast retransmit of the lost data segment.
• Increments cwnd by MSS for each additional dupACK received.
• Transmits a new segment if the newly calculated cwnd and receiver window size (rwnd)
allow.
• Sets cwnd to ssthresh when the next ACK arrives that acknowledges new data.
The last step refers to the case when the received ACK acknowledges all intermediate
segments sent between the lost segment and the receipt of the third dupACK. When the TCP
sender performs the last step, it enters the congestion avoidance phase. Otherwise retransmission
timeout occurs and the sender goes to slow-start phase and reduces the cwnd to one MSS. TCP
Reno is updated by RFC 5681 [33] with minor modifications.
input : Current congestion window cwndcur rentoutput : Next congestion window cwndnex t
1 if cwndcur rent < ssthresh then /* Slow start */2 cwndnex t = cwndcur rent +MSS3 else /* Congestion avoidance */4 cwndnex t = cwndcur rent +MSS2/cwndcur rent5 end
Algorithm 1: TCP Reno – cwnd increase.
input : Current flight size f l i ghtsizecur rent , MSSoutput : Next congestion window cwndnex t , Next slow start threshold ssthreshnex t
6 if Fast Recovery then7 ssthreshnex t = max( f l i ghtSizecur rent/2,2 ∗MSS)8 cwndnex t = ssthreshnex t + 3 ∗MSS9 end
Algorithm 2: TCP Reno – fast recovery.
2.7.2 TCP NewReno
TCP NewReno [34] improves the TCP Reno performance by modifying the fast recovery mecha-
nism. Normally, TCP Reno recovers only a single loss in the transmission window, however with
2.7 Reliable Transport with TCP 22
TCP NewReno, the TCP sender recovers from multiple segment losses in the same transmission
window and avoids multiple retransmission timeout events [34].In this thesis, the TCP Reno and NewReno variants are considered in order to show the
performance of TCP-based applications in Chapters 4 and 5.
2.8 Simulation Platform
The OMNeT++ simulator [37], an open-source discrete event simulation platform, is the main
platform that is used to model the protocols in this thesis. It is based on object oriented
programming structure and modules are defined in a hierarchical structure. There are two main
module types; namely simple and compound modules. The compound module is a composition
of multiple simple modules. In addition, different modules are connected to each other via input
and output gates which are used to exchange information. The research community provided
different extensions to the OMNeT++ platform such as INET framework, MiXiM framework.
In this work, INET framework is mainly used to define LDACS1 specific link layer, IPv6-based
network layer and transport layer functionalities. Fig. 2.8 shows an example of a mobile node
that is composed of a complete protocol stack, namely, from link layer to application layer
modules.
2.8.1 LDACS1 Module
The LDACS1 compound module consists of the following 5 simple modules as shown in Fig. 2.9a.
• Radio module: Responsible for transmission of the LDACS1 frames over the wireless
channel that is characterized with certain Bit Error Rate (BER) or Frame Error Rate (FER)
values. It is also responsible for the scanning of neighboring radio channels when the
aircraft initially power up or perform handover.
Figure 2.8 – Mobile node compound module in OMNeT++.
2.8 Simulation Platform 23
• Medium Access Control (MAC) module: Responsible for the transmission time calcula-
tions of the LDACS1 frames including the starting and ending of frame, multiframe and
superframe.
• LME Module: Responsible for the link attachment procedures including LDACS1 specific
(i.e., layer 2) handovers. It also takes care of insertion and deletion of the connected
aircraft list depending on their connectivity at the base station LME. LDACS1 scheduling
algorithm is also running in this block.
• DLS Module: Responsible for the enqueuing of LDACS1 frames when they are received
from the Sub Network Dependent Convergence Function (SNDCF) module, performing
resource requests for enqueued frames from the LME and dequeuing frames from DLS
buffer depending on the resource allocations. This module supports transmission of
fragmented data and reliable data transmission via an ARQ mechanism.
• SNDCF Module: Responsible for the conversion of IPv6 packets into LDACS1 specific
frames and vice versa including addition and removal of LDACS1 control messages.
(a) LDACS1 Compound Mod-ule
(b) Network Layer Compound Module
Figure 2.9 – Module representations in OMNeT++.
2.8.2 Network Layer Module
The network layer compound module consists of the following 5 simple modules as shown in
Fig. 2.9b.
• IPv6 Module: Responsible for forwarding of IPv6 packets.
• IP Tunneling module: Responsible for tunneling and detunneling of IPv6 packets when
they are sent between mobile node and its home agent.
2.8 Simulation Platform 24
• Neighbor Discovery Module: Responsible for the functionalities described in Section 2.5.
• MobileIPv6 Module: Responsible for the functionalities mentioned in Section 2.3.
• ICMPv6 Module: Responsible for error reporting (e.g., destination unreachable, packet
too big) and diagnostic functions (e.g., ping).
Chapter 3
Handover Optimizations
This chapter mainly considers handover signaling overhead and handover delay optimizations.
While the former considers reduction of signaling overhead due to router advertisement message
transmissions over wireless link, the latter mainly deals with the handover delay optimizations
caused by layer 3 handover procedures.
3.1 Related Work
MIPv6 and its extensions are very well studied protocols by the research community. Previous
studies mainly considered link technologies from the domain of consumer electronics. For
example, a simulation study of MIPv6 on IEEE 802.11b provides a performance evaluation of
different smart handover extensions including link layer triggers for MIPv6 [38]. Another work
presents testbed experiments related to the use of MIPv6 with IEEE 802.11g technology [39].Similar results have been presented in [40]. Here, MIPv6 has been studied in an experimental
testbed using WiMAX and Wi-Fi as underlying link layer technologies. In [41], NEMO is used
as a base protocol in a testbed where two different 802.11 interface cards are used in order
to perform make-before-break handovers. Although having multiple interfaces from the same
technology provides better handover delay performance, it is not realistic in aeronautical domain
due to cost, space and weight.
In the aeronautical domain different radio access technologies are considered, which mainly
differ due to their data rate, cell size and number of mobile users inside cell. Currently deployed
technologies provide data rates in the range of 3 kbit/s . . . 30 kbit/s per cell. However, future
radio access technologies like LDACS1, which this thesis focuses on, provide data rates in the
range of 291 kbit/s . . . 1318 kbit/s in the FL and 220.3 kbit/s . . . 1038.4 kbit/s in the RL per cell
depending on selected modulation and coding scheme. Although LDACS1 increases the data
rate beyond that provided by current radio technologies, the link capacity is still far behind that
of consumer electronics. Other differences are the cell size and the number of mobile users.
Typical LDACS1 cell radius is in the range of 150 km . . . 250 km and provides services up to a few
hundred of aircraft if we assume multiple TMA and En Route service volumes [1] are covered
by one cell (cf. Fig. 3.1).
25
3.2 Performance Assessment 26
Figure 3.1 – Airspace organization.
3.2 Performance Assessment
In order to assess the performance of LDACS1 integrated with IPv6 network layer functionality,
we modeled the protocols using an OMNeT++ simulator [37]. LDACS1 offering type 1 handover
is implemented and integrated with the NEMO protocol at the network layer in order to provide
seamless mobility to the aircraft. Table 3.1 shows the parameters used at the network layer. The
first five parameters are related to the neighbor discovery protocol where the first two values
define the RA interval sent by the Access Router (AR) [11,26] and the next three parameters
are related to the DAD and MLD procedures. The last three parameters are specific to the
MIPv6/NEMO protocols and related to home registration.
In our simulations, when the aircraft receives a new RA message with different prefix infor-
mation, it assumes the RA is coming from a different access network and immediately starts CoA
configuration based on the received RA – however, in reality different prefixes can be advertised
by the same access network and more advanced movement detection mechanisms can be needed
as described in [42–44].In addition, we also assume a certain BER after decoding in our simulations (BER= 10−3
and BER= 10−5) in order to reflect packet losses due to wireless channel errors.
Parameter Value
MIN_RTR_ADV_INTERVAL 0.03 sMAX_RTR_ADV_INTERVAL 0.07 sIPv6_DEFAULT_DUPADDRDETECTTRANSMITS 1IPv6_DEFAULT_RETRANS_TIMER 1 sIPv6_MAX_RTR_SOLICITATION_DELAY 1 sMIPv6_INITIAL_BINDACK_TIMEOUT 1 sMIPv6_INITIAL_BINDACK_TIMEOUT_FIRST 1.5 sMIPv6_MAX_BINDACK_TIMEOUT 32 s
Table 3.1 – Layer 3 parameters related to handover.
3.2 Performance Assessment 27
3.2.1 Considered Topology
The main topological considerations for the ATN/IPS are provided in [45]. In our analysis, the
European scenario shown in Fig. 3.2 is considered, where the aircraft is communicating with an
ATS controller located in Maastricht. An aircraft starts communication when it is located in the
home domain, performs handover during communication, and moves to the foreign domain.
This is a kind of inter-access network (Inter-AN) handover so that the aircraft should complete
layer 2 and layer 3 handover procedures in order to continue communication. Within the ground
network, the fixed delay values shown in the figure were used. In the aeronautical domain, the
cell radius is generally between 150 km and 250 km and the cell overlapping regions are quite
large so that the handover performance does not degrade due to high speed of an aircraft.
3.2.2 Handover Performance with ARQ Mechanism
In this section, we analyze the benefit of the ARQ mechanism for handover delay performance
under different channel conditions.
3.2.2.1 High BER Scenario
In this first scenario, we assume a BER of 10−3. We calculate the corresponding packet error rate
as PER= 1− (1− BER)n, with n denoting the packet length. Table 3.2 shows the average delay
values for an aircraft performing layer 2 and layer 3 handovers. These values are taken from 25
simulation runs where each run simulates 20 aircraft handover instances. In particular, Table 3.2
shows the delay values of each step contributing to the total handover delay. As can be seen
the main difference between both scenarios is the delay incurred by home registration, i.e., the
BU–BA exchange. MLD-DAD completion time is around 1.5 s which is the same in both scenarios.
BS - A1 BS - A2 BS – B1
MR: Mobile RouterBS: Base StationAR: Access Router
AR – B1
L-DACS 1 Home
Domain
Inter-AN with layer 3 handover
MR MR
Maastricht CN
5 ms 5 ms 5 ms
15 ms15 ms
BR15 ms
Core Network CN Subnetwork
L-DACS 1 Foreign Domain
BR: Backbone RouterHA: Home AgentCN: Correspondent Node
HA
Figure 3.2 – Example topology for the European scenario.
3.2 Performance Assessment 28
Here, average delay of 0.5 s is assumed for the MLD report message for joining the solicited-node
multicast group since it should be sent with a random delay between 0 and 1 s according to
RFC 4861 [26]. In the case where ARQ is not used, due to more frequent loss of either BU
or BA messages the handover takes much longer. Use of ARQ with single retransmission can
thus improve the total handover delay performance by around 80 %. Detailed plots of the delay
distribution can be seen in Figs. 3.3a and 3.3b.
3.2.2.2 Low BER Scenario
In the second scenario, the same simulation settings have been used for BER = 10−5. Due to the
low BER, the system experiences less packet losses and the benefit of ARQ becomes negligible.
Again, detailed plots of the delay distribution can be seen in Fig. 3.3c and Fig. 3.3d. The average
delay stays around 2.85 s . . . 2.9 s in both cases.
3.3 Reducing Router Advertisement Overhead
MIPv6 specifies RA transmission intervals of 30 ms . . . 70 ms in order to minimize the handover
delay. If a RA message of around 100 B is sent every 50 ms on the average, the overhead
corresponds to around 6 % of the LDACS1 FL capacity with lowest modulation and coding
scheme. This could be problematic in high density cells where there could be around a few
hundred aircraft. For this reason, we proposed two methods in order to decrease the unsolicited
RA overhead without degrading the handover delay performance. In this section, we used the
same simulation settings of low BER scenario without considering ARQ mechanism as a baseline
scenario with different router advertisement transmission intervals starting from 70 ms to 6 s.
The results of the baseline scenario is shown in Fig. 3.4 with the label “base-X” where X shows
the RA transmission interval.
3.3.1 Proposal 1 - Using IEEE 802.21 Event Services
In our first proposal, we utilize the LINK_DOWN and LINK_UP event services of IEEE 802.21 [31]to improve handover performance. When the aircraft sends a CELL_EXIT message to the current
BS, LDACS1 in the aircraft triggers a LINK_DOWN event. When the new link becomes available
after the layer 2 handover is completed, a LINK_UP event is triggered by LDACS1. Upon reception
no ARQ one retransmission
L2 Handover Completion Time in s 0.09 0.09RA Reception Time in s 0.03 0.027MLD-DAD Completion Time in s 1.5 1.5Home Registration Time in s 33.17 5.68
Total Time in s 34.8 7.3
Table 3.2 – Average handover delay values for layers 2 and 3.
3.3 Reducing Router Advertisement Overhead 29
0 100 200 3000
0.01
0.02
0.03
0.04
0.05
Data (seconds)
Den
sity
HO Delay HistogramLognormal Distribution Fitting
Min=2.37Max=367.95Mean=34.79Std Dev=60.2
Lognormal Mean=2.57Lognormal Variance=1.3
(a) without ARQ, high BER
0 50 100 1500
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
Data (seconds)
Den
sity
HO Delay HistogramLognormal Distribution Fitting
Min=2.37Max=114.81Mean=7.3Std Dev=9.49
Lognormal Mean=1.7Lognormal Variance=0.64
(b) with ARQ (one re-tx), high BER
2.5 3 3.5 4 4.50
0.2
0.4
0.6
0.8
1
1.2
1.4
Data (seconds)
Den
sity
HO Delay HistogramLognormal Distribution Fitting
Min=2.37Max=4.77Mean=2.9Std Dev=0.36
Lognormal Mean=1.05Lognormal Variance=0.12
(c) without ARQ, low BER
2.5 3 3.5 40
0.2
0.4
0.6
0.8
1
1.2
1.4
Data (seconds)
Den
sity
HO Delay HistogramLognormal Distribution Fitting
Min=2.37Max=4.29Mean=2.85Std Dev=0.29
Lognormal Mean=1.04Lognormal Variance=0.1
(d) with ARQ (one re-tx), low BER
Figure 3.3 – Delay density for Layer 2 and 3 handover with and without ARQ and for twodifferent BER scenarios.
of the LINK_UP event, the network layer transmits a RS and waits for the RA message. According
to [26], a host should transmit up to MAX_RTR_SOLICITATIONS RS messages, at intervals of at
least RTR_SOLICITATION_INTERVAL seconds. In our case, when the network layer receives a
LINK_UP event, it sends an RS immediately, ignoring this delay, in order to complete the handover
in a shorter time. However, if the first RS or the respective solicited RA message is lost due to
channel errors, the aircraft delays the second RS according to the specification.
Fig. 3.4 shows the resulting performance of proposal 1 (denoted as “p1” in the figure)
compared with the baseline scenario where only unsolicited RA messages are transmitted with
different transmission intervals. With this proposal, handover delay performance becomes
independent of the unsolicited RA transmission interval since in this case aircraft sends a RS
message instead of waiting for unsolicited RAs. If we consider unsolicited RAs with 6 s intervals,
the overhead decreases significantly to a level of few hundred bit/s.
3.3 Reducing Router Advertisement Overhead 30
base-0.07 base-0.5 base-1 base-3 base-6 p1 p2
3
4
5
6
7
8
Router Advertisement Interval (0.07 sec. --> 6 sec.)
Han
dove
r Del
ay (s
ec.)
Figure 3.4 – Handover delay comparison: unsolicited RA vs. proposals 1 and proposal 2.
3.3.2 Proposal 2 - Transmission of Stored Router Advertisement Message
The second proposal for increasing handover performance requires modifications to BS. When
BS receives an unsolicited RA message from the connected AR, it now does not only send the
message but also stores a copy in its local RA cache. The local copy is always updated with the
most recent RA message. During the handover, when an aircraft sends a CELL_RQST to the BS,
the BS does not only send a CELL_RESP message, but it also sends stored local copy of the RA
message in the upcoming FL data slot. If the local copy is lost due to channel errors, the aircraft
should wait for a regular unsolicited RA message. Fig. 3.4 also shows the performance of this
proposal (denoted as “p2” in the figure). On average, it performs even better than proposal 1,
further decreasing delays by about 0.4 s.
3.3.3 Discussion
In both proposals, we noticed a few outliers since ARQ component at the link layer is not used.
While in proposal 1, the possible outliers occur either due to loss of RS and RA messages or loss
of home registration messages (i.e., either BU or BA), in proposal 2, possible outliers occur either
due to loss of local RA copy or due to the loss of home registration messages. In case the mobile
does not receive solicited RA or local copy of RA message, then it has to wait for unsolicited RA
and in case it does not perform first home registration successfully, after the retransmission timer
expires, another BU is sent by the MR. For both cases, if we use ARQ component of LDACS1 then
the loss probabilities of RS and RA messages and home registration messages will be significantly
smaller due to retransmission possibilities at the link layer.
Although the achieved handover delay stays within a certain range in both discussed proposals,
due to long service disruption time (around 3 s) both proposals can not satisfy the specific
3.3 Reducing Router Advertisement Overhead 31
application demands of, e.g., voice over IP. Similarly, considering TCP applications, packet losses
during the handover will be considered as a sign of congestion by the TCP sender, which will
result in unnecessary timeouts and retransmissions. In general, there are three main sources
of the achieved layer 3 handover delay, namely: DAD time for the care-of address generation,
home registration procedure, and DAD time for the home address. The DAD time for the home
address is not very critical since it occurs only during the first handover from home domain
to foreign domain, however DAD time for care-of address generation occurs at every layer 3
handover, so different approaches have been proposed to reduce this delay [46,47]. Section 3.4
will provide two new methods to remove the DAD procedure for CoA and HoA configuration.
Ignoring the DAD procedure, the only remaining components are layer 2 handover and home
registration delays.
3.3.4 Overhead Analysis
In order to compare the performance of two proposals with baseline scenario in terms of overhead,
we use certain generation rate of aircraft from different airports located in Europe based on
realistic flight data and look at the number of aircraft entering a cell located at Brussels airport
with different cell sizes as shown in Fig. 3.5a. The traffic generation rate is selected based on the
information from realistic flight data within Europe from 11:00 am to 12:00 pm. Statistics have
been extracted from this data to model the rate at which aircraft are generated for each pair
of source and destination airports. In the simulation environment, aircraft are created at each
airport according to a Poisson process (i.e., interarrival times are exponentially distributed) with
destinations and generation rates as derived from the flight data. The simulated flights follow the
path between source and destination airport by considering the way points based on great circle.
This results in a distribution of aircraft in European airspace that is representative of current air
traffic. Fig. 3.5b denotes the total number of aircraft during the 12 hours of simulation time.
Fig. 3.6a denotes the hourly measurements of number of aircraft entering a cell with different
radii and Fig.3.6b shows the overhead due to two proposals mentioned above. As expected,
(a) Snapshot of aircraft entering cell with differ-ent sizes
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5x 104
0
200
400
600
800
1000
1200
1400
1600
1800
2000
Simulation Time (sec.)
Num
ber o
f Airc
raft
on A
ir
(b) Number of aircraft during simulation
Figure 3.5 – Usage of realistic flight data for analysis.
3.3 Reducing Router Advertisement Overhead 32
proposal 1 causes more overhead due to the exchange of two messages (i.e., RS and RA)
compared to proposal 2. In proposal 2, only single message (i.e., RA) is sent by LDACS1 BS
to the aircraft. In the worst case, the overhead stays around 0.18 kbit/s level with proposal 1.
Table 3.3 shows the overhead comparison of the two proposals with the baseline scenario where
unsolicited RA messages are sent with different frequencies (i.e., 50 ms, 1 s and 6 s).
0 1 2 3 4 5x 104
100
150
200
250
300
350
400
450
500
550
Simulation Time (sec.)
Num
ber o
f A/C
Ent
erin
g C
ell /
Hou
r
Radius = 50 kmRadius = 100 kmRadius = 150 kmRadius = 200 km
(a) Number of aircraft entering a cell with different radius
0 1 2 3 4x 104
20
40
60
80
100
120
140
160
180
Simulation Time (sec.)
Ove
rhea
d (b
ps)
R = 50 km - P2R = 100 km - P2R = 150 km - P2R = 200 km - P2R = 50 km - P1R = 100 km - P1R = 150 km - P1R = 200 km - P1
(b) Overhead due to two proposals
Figure 3.6 – Overhead analysis with realistic flight data.
Regular Case Regular Case Regular Case P1: RS+RA P2:RA50 msec. 1 sec. 6 sec. 150 Byte 100 Byte
16.5 kbps 1 kbps 0.14 kbps 0.18 kbps 0.1 kbps
Table 3.3 – Overhead comparison of different approaches.
3.4 Proposal 3 - Removing Duplicate Address Detection
As mentioned above, DAD time for HoA and CoA during the handover increases the handover
completion time. Two different approaches are considered in order to guarantee the uniqueness
of the generated HoA and CoA so that the DAD procedure can be removed from the handover
process.
Reference [9] provides /32 IPv6 address prefix format for the mobile nodes, however it does
not provide information how an interface identifier (corresponds to the least 64 bits) can be
configured. In aeronautical domain, each aircraft has a unique 24-bit ICAO address and we
propose to use this address when aircraft is configuring its interface identifier field for the CoA.
As defined in Appendix A of [48], a modified 64-bit extended unique identifier (EUI-64) format
can be created by taking the 24-bit ICAO address and zero fill it to the left as shown in Fig. 3.7.
In addition, a unique Home Network Prefix (HNP) can be assigned to each MR during the
initial network connection phase (i.e., bootstrapping phase) similar to [49] or via Internet Key
Exchange version 2 (IKEv2) as specified in [50] so that the generated HoA from unique HNP is
implicitly unique.
3.4 Proposal 3 - Removing Duplicate Address Detection 33
|0 1|1 3|3 4|4 6||0 5|6 1|2 7|8 3|+----------------+----------------+----------------+----------------+|0000000000000000|0000000000000000|00000000mmmmmmmm|mmmmmmmmmmmmmmmm|+----------------+----------------+----------------+----------------+
Figure 3.7 – Creating modified EUI-64 format interface identifier.
In this section, same simulation settings are considered as in Section 3.3 with local RA
transmission. With this proposal, average handover delay reduces from 3 s to around 0.4 s as
shown in Fig. 3.8 since in this case the total handover latency decreases to only home registration
and layer 2 handover procedures (denoted as “p3” in the figure). Similarly, we also notice a
few outliers (due to loss of local RA copy or due to the loss of first home registration messages),
however with the usage of ARQ component of LDACS1, the loss probability of these messages
will significantly reduce.
p1 p2 p3
1
2
3
4
5
6
7
Han
dove
r D
elay
(se
c.)
Figure 3.8 – Handover delay comparison: proposal 1 vs. proposal 2 vs. proposal 3.
3.5 Proposal 4 - Speeding Up Handovers in Congested Cells
Normally, a BS provides a resource request slot to each registered aircraft within the cell – no
matter if those aircraft will have some data to transmit or not. Using a CCCH slot, the BS notifies
the aircraft that have a right to send a resource request in the next upcoming DCCH slot. In
Sections 3.2.2, 3.3 and 3.4, we assumed the number of aircraft in the next BS is always less than
52. However, if more than 52 aircraft are attached to the BS, not all aircraft are able to send
their resource requests in every DCCH slot due to its limited size. For example, if we consider
416 aircraft within a cell, each aircraft will only get one resource request opportunity for every 8
multiframes (i.e., every 467 ms). From a layer 3 handover perspective, this constitutes the worst
case delay that a binding update transmission will suffer if an aircraft enters such a congested
cell.
In order to decrease the BU transmission delay in congested cells, we proposed that the BS
will allocate consecutive DCCH slots to the newly attached aircraft for a certain duration. In our
simulations, we used 16 superframes (around 3.8 s) since most of the handovers are completed
3.5 Proposal 4 - Speeding Up Handovers in Congested Cells 34
in less than 4 s for low BER cases as mentioned in Section 3.2.2.2. By doing this, the BS allows
the aircraft to send its resource request immediately when the BU message arrives at the LDACS1
queue. Fig. 3.9 shows the handover delay values for different numbers of aircraft in the next cell.
In the figure, baseline scenario is the same as in Section 3.3 with router advertisement interval
of 70 ms and is labeled as “base-Y” where Y shows the number of aircraft attached to the next
BS. With our proposal (denoted as “p4” in the figure), handover delay stays constant no matter
how many aircraft are attached to next cell. If 500 aircraft are attached to next BS, our proposal
can thus reduce handover delay by around 0.7 s.
base-1 p4 base-100 p4 base-200 p4 base-300 p4 base-400 p4 base-500 p4
2.5
3
3.5
4
4.5
5
5.5
6
6.5
Han
dove
r Del
ay (s
ec.)
Number of aircraft in the next BS
Figure 3.9 – Handover delay comparison: baseline vs. proposal 4.
Our proposal requires modification to the CCCH slot structure which affects the DCCH slot
allocations so that a BS is capable of assigning a DCCH slot to a desired aircraft on demand
within the cell. In the regular case, a BS assigns aircraft to each DCCH slot based on the ordered
subscriber access code. In addition, if we consider an aircraft performing handover for certain
duration, during this time, one less aircraft will gain access to the DCCH slot. This is not very
critical since that aircraft will only be affected at most one multiframe duration, i.e., 58.32 ms.
3.6 Conclusion
In this chapter, we proposed different strategies in order to improve handover delay and signaling
overhead performance over LDACS1 data link with IPv6 networking functionality. With the help
of these strategies, we achieved to reduce the total handover delay to the range of a few hundred
milliseconds and RA signaling overhead to the range of a few hundred bit per second level.
Chapter 4
TCP Analysis with LDACS1
In this chapter, we extend our work for improving the TCP performance during the handover.
In the first section, different TCP handover optimizations related to Mobile IPv6 protocol are
presented. In the second section, home agent buffering method for improving TCP performance
during inter-access network handovers is analyzed in detail. In this chapter, as in the previous
chapter, single interface inter-access network handover scenario with the NEMO protocol is
considered. In addition, realistic FER values received from the LDACS1 physical layer simulator
[51] is used in our simulations.
4.1 TCP Optimizations for Mobile IPv6 Handovers
In order to optimize the TCP performance during handovers, four different approaches are
proposed, which are related to MIPv6/NEMO protocols. These approaches are, namely HA
buffering [52,53], HA bi-casting [54], BS buffering [55,56] and AR buffering [57,58]. Note
that, there are also cross layer approaches, which are not studied since they require certain
modifications either on the TCP sender and/or the receiver side [59–61].
4.1.1 Access Router Buffering
Fast Mobile IPv6 (FMIPv6) [47,57] and the proposal by [58] are the main solutions belonging
to this group. The main idea of the proposals is to let previous and next ARs exchange signaling
information related to a certain mobile node and perform a buffering operation of the packets in
the next AR that is tunneled by the previous AR during the handover process. After the handover
is completed, the next AR delivers the buffered packets to the mobile node. In addition, in
FMIPv6, new CoA (nCoA) address configuration is also performed in advance (i.e., when the
mobile is connected to Previous Access Router (PAR)) in order to complete the layer 3 handover
in a shorter time. FMIPv6 defines three different message types as shown in Table 4.1.
FMIPv6 defines two modes of operation, namely a predictive and a reactive modes depending
on whether the FBack is received via PAR or Next Access Router (NAR), respectively. The
predictive mode shown in Fig. 4.1 is the main method that the mobile node can benefit from
all FMIPv6 functionality. This mode requires the anticipation of handover start time by another
35
4.1 TCP Optimizations for Mobile IPv6 Handovers 36
Name Message Type
Router Solicitation for Proxy Advertisement (RtSolPr) Neighbor DiscoveryProxy Router Advertisement (RtRtAdv) Neighbor DiscoveryHandover Initiate (HI) Inter - Access RouterHandover Acknowledge (HAck) Inter - Access RouterFast Binding Update (FBU) Mobility HeaderFast Binding Acknowledgment (FBack) Mobility Header
Table 4.1 – FMIPv6 specific message formats.
mean such as link layer triggers via IEEE 802.21. The reactive mode shown in Fig.4.2 is a kind of
fall-back solution such that the mobile node can not anticipate the handover start time correctly
and loose the connection unexpectedly. In this mode of operation, packet losses are inevitable
since it is not possible for PAR to forward packets (and in turn not possible to buffer packets at
NAR) until it receives FBU [62].
4.1.2 Base Station Buffering
The main idea of BS buffering is similar to AR buffering in the sense that the previous BS starts
to forward the packets to the next BS during the mobile node performs handover and the next
BS delivers the buffered packets to the mobile when the handover is completed [55,56]. Authors
of [55, 56] consider Mobile IPv4 (MIPv4) as the mobility management protocol and propose
a packet forwarding controller implemented in BS in order to avoid re-ordering of packets.
In addition, they propose an extension to MIPv4 so that BU message includes random early
detection state information of the congested router on the path. Based on random early detection
state information, previous BS either forwards the packets to the next BS or drops them.
4.1.3 Home Agent Bi-casting
A modified NEMO management scheme for mobile networks suitable for trains or buses moving
on the predetermined path is proposed in [54]. In this scheme, each MR maintains a database
Link Going Down
RtSolPrPrRtAdv
FBU HIHAckFBack
UNA
Link Down
Link UpDisconnection
Time
Forwarding Starts
Buffering StopsDelivery Starts
Buffering Starts
Figure 4.1 – FMIPv6 - predictive handover scenario
4.1 TCP Optimizations for Mobile IPv6 Handovers 37
RtSolPrPrRtAdv
FBU
HIHAck
FBack
UNA
Link Down
Link UpDisconnection Time
Forwarding Starts
Buffering Starts
Buffering StopsDelivery Starts
Figure 4.2 – FMIPv6 - reactive handover scenario.
about the list of ARs, their network prefixes, and cell radii on the moving path. The MR therefore
knows in advance the network prefixes and the CoAs of all subnetworks. Using this database,
the MR can prepare a layer 3 handover with Predictive Binding Update (PBU) before a layer
2 handover occurs, so that the service disruption time due to handover will be reduced to the
link layer handover latency. After the HA receives the PBU message, it bi-casts data packets to
the MR through the next AR and the previous AR simultaneously, until handover completion as
shown in Fig. 4.3. The new AR can buffer the packets to minimize the packet loss.
Predictive Binding Update
CN Traffic / Predictive BU Ack.
CN Traffic
Router Advertisement
(Packet Buffering)
Forwarding Request
Forwarding Buffered Traffic
Link Going Down
Link Down
Link Up
CoA Configuration
- Pre-Registration- Bicasting
Stop Bicasting
Stop Bicasting
Figure 4.3 – HA bi-casting scenario.
4.1.4 Analysis of Proposals
Table 4.2 summarizes the suitability of these approaches to two main handover scenarios,
namely intra access network (intra-AN) and inter-access network (inter-AN). BS buffering
and AR buffering methods are only suitable for intra-access network handovers, since they
require signaling between access routers or base stations and such kind of collaboration and trust
relationship may not be possible between different access network service providers. In addition,
these approaches require major modifications on the existing access network infrastructure
4.1 TCP Optimizations for Mobile IPv6 Handovers 38
(i.e., software update and configuration of all BSs and ARs). Furthermore, these protocols only
support host mobility (MIPv4 or MIPv6) and not NEMO. Another approach, HA bi-casting, works
for intra and inter-access network handovers. However, it has three main drawbacks. One is
the static configuration of a mobility database on the mobile router, which stores the list of
access routers, their network prefixes, and possible CoAs for each candidate access network.
Furthermore, the bi-casting of the traffic causes two times more traffic load on the ground
network. Finally, in case the bi-casted packets are not stored in the access network during
the handover, packet losses are inevitable during the handover. The last approach is the HA
buffering, which is not only suitable for single-interface inter access network handovers but also
intra-access network handovers. It does not require any static configuration on the aircraft as
opposed to HA bi-casting and it does not require any major modification on the access network
as opposed to BS buffering and AR buffering methods. The following section will investigate HA
buffering approach in more detail.
HA buffering HA bi-casting BS buffering AR buffering[52,53] [54] [55,56] [57,58]
Inter-AN Handover 3 3 7 7
Intra-AN Handover 3 3 3 3
Table 4.2 – Layer 3 TCP optimizations during handover.
4.2 Home Agent Buffering for Inter Access Network Handovers
Our contribution to the HA buffering protocol proposed in [52] is the analysis of its applicability to
ATN/IPS and its integration with LDACS1 data link. We modify the LDACS1 handover mechanism
and show its applicability with HA buffering through simulations.
Fig. 4.4 depicts the scenario where an aircraft is communicating with a CN over BS1. The
aircraft is sending the received power level of the FL (PBS1) to BS1 with POW_REP messages.
Whenever PBS1 drops below a certain threshold Th1, BS1 requests the scanning of the neighboring
BSs. The aircraft reports the received power levels back to BS1. This procedure continues until
the received power level PBS2 of a certain BS (in our example BS2) is better compared to the
current one. Thus, when PBS2 is higher than PBS1, BS1 sends a modified HO_COM message
to the aircraft. When the aircraft receives HO_COM with P-bit set3, it triggers a LINK_GOING_-
DOWN message to the network layer, which, in turn, sends a BU with packet buffering option4
(mentioned as “Modified Binding Update (MBU)” in the rest of this chapter) to the HA in order to
inform not to forward any packets to the currently attached access router and buffer those packets
in its queue. In return, the HA sends a BA message with packet buffering option (mentioned as “
Modified Binding Acknowledgement (MBA)” in the rest of this chapter) to the aircraft. After
3A new bit, the P-bit, is used from the reserved bit-field in the HO_COM message. If it is set, the LDACS1 BSinforms the aircraft that it has some packets waiting for transmission in its queue. Thus, if the P-bit is not set, nomore packets are waiting for the aircraft.
4This mobility option is 4 B long as defined in [52].
4.2 Home Agent Buffering for Inter Access Network Handovers 39
BS1 delivers all packets in its queue to the mobile, it sends a HO_COM message with the P-bit set
to zero in order to trigger the layer 2 handover. After the mobile completes layer 2 handover
and configures the new CoA, it sends a regular BU message to the HA, which replies with a BA
message and forwards all the buffered packets to the newly attached AR.
4.3 Performance Assessment
In our analysis, we again considered the European scenario shown in Fig. 3.2, where the aircraft
are communicating with an AOS CN and assumed the same fixed delay values on the ground
network. Our assessments are mainly based on the scenario that the aircraft is downloading
Graphical Weather Information (WXGRAPH) from a CN by using the TCP protocol during the
handover.
4.3.1 Received Power and Wireless Channel Errors
In our simulation experiments, we consider a free-space path loss model for the wireless channel
since we mainly focus on the En Route service volume in which the line-of-sight component is
very strong [63]. The received power Pr x is the main parameter that is used for the handover
process as defined in Eq. 4.1. It depends on the transmit power Pt x , the receiver and transmitter
antenna gains Gr x and Gt x , cable and diplexer losses in the transmitter as well as in the receiver
.
.
HO_COM [CCCH] P=0
ACB & STB [BCCH]
SIB [BCCH]
POW_REP [DCCH]
HO_COM [CCCH] P=1
CELL_EXIT [DCCH]
CELL_RQST [RACH]
CELL_RESP [CCCH]
POW_REP [DCCH - 1]
POW_REP [DCCH - n]
1 1BSP Th<
2 1BS BSP P>
Figure 4.4 – LDACS1 handover scenario.
4.3 Performance Assessment 40
(i.e., Ltx, Lrx), the transmit center frequency ft x , and on the distance d between transmitter and
receiver. The particular values are summarized in Table 4.3 for both, FL and RL transmission,
adopted from the LDACS1 link budget calculation in [20].Given these values, the received power is obtained by
Pr x = Ptx + Grx + Grx − Ltx − Lrx + 20 log
�
c
4 ·π · d · ftx
�
(4.1)
with c = 3 · 108 m/s; power, gain, and loss values given in dB.
In order to reflect the user data losses in the wireless channel during the handover (i.e.,
when the aircraft is close to the boundary of the cell), we consider realistic FER values that
are obtained from the LDACS1 physical layer simulator [51]. The physical layer simulations
use a realistic ENR channel model as well as interference, induced by the distance measuring
equipment, which operates in the same frequency range, into account. The interference scenario
and the applied interference mitigation technique were adopted from [64]. For estimating the
transmission channel, a pilot based linear interpolation was implemented. In Fig. 4.5, FER and
BER curves are plotted versus the Signal to Noise Ratio (SNR). Regarding coding and modulation,
LDACS1 supports adaptive coding and modulation. The proper coding and modulation choice is
based on the current channel condition that aims to maximize the throughput. In our physical
layer simulations, we choose the most robust setup of quadrature phase shift keying and a
concatenation of a rate 1/2 convolutional code and a rate 0.9 Reed-Solomon code since aircraft
is flying near to the cell boundary. For an LDACS1 transmission, target BER of 1 · 10−6 in the
FL data frames is required according to [20]. As depicted in Fig. 4.5, this rate is achieved at
SNR= 8.7 dB.
This leads to FER values of 6.28 · 10−2 for the RL and 6.31 · 10−5 for the FL data slots at the
considered SNR of 8.7 dB as shown in Fig. 4.5. Each FL and RL data frame (i.e., physical layer
PDU) carries 91 byte and 14 byte of information data, respectively. Note that, these FER values
are the main input values for the radio channel module in our simulations in Section 4.3.5.
Link budget calculations, given in Table 4.4, indicate that for a cell size of 225km and
exemplary chosen transmit frequencies of ftx,FL = 993.5 MHz in the FL and ftx,RL = 1056.5 MHz
in the RL, the SNR working point of 8.7 dB leads to a positive link budget, indicated by a positive
system operating marging, Om. In the table, thermal noise density (N0) is calculated as 10 log(kT )where k = 1.381 · 10−23J/K (Boltzmann constant) and T = 290K (Temperature).
Parameter FL RL
Tx power, Ptx 41dBm 41dBmTx antenna gain, Gtx 8 dBi 0 dBiTx cable & duplexer loss, Ltx 2 dB 3.5 dBTx center frequency, ftx [985.5-1008.5]MHz [1048.5-1071.5]MHzTx-Rx distance, d 225km 225kmRx antenna gain, Grx 0 dBi 8 dBiRx cable & duplexer loss, Lrx 3.5 dB 2 dB
Table 4.3 – Values of LDACS1 transmission.
4.3 Performance Assessment 41
2 4 6 8 1010
-6
10-5
10-4
10-3
10-2
10-1
100
SNR [dB]
Err
or R
ate
BER, FLFER, FLFER, RL
Figure 4.5 – Error rates versus SNR for LDACS1 transmission.
Parameter FL RL Formula
Rx power, Prx -95.26 dBm -95.80 dBm see Eq. 4.1Safety margin, Ms 6 dB 6 dBThermal noise density, N0 -174 dBm/Hz -174 dBm/Hz 10 log(kT )Tx bandwidth , B 498.05 kHz 498.05 kHzThermal noise power, PN0 -117.03 dBm -117.03 dBm N0 + 10 log(B)Rx noise figure, NF 6 dBm 5 dBmRx noise power, PN,rx -111.03 dBm -112.03 dBm PN0 +NFTarget SNR 8.7 dB 8.7 dBRx sensitivity, S0 -102.33 dB -103.33 dB PN,rx + SNRRx operation point, S1 -96.33 dB -97.33 dB S0 + MsSystem operating marging, Om 1.07 dB 1.53 dB Prx - S1
Table 4.4 – Link budget for LDACS1.
4.3.2 Network Layer Considerations
In this chapter, same network layer parameters as in Chapter 3 are used (cf. Table 3.1).
4.3.3 Transport and Application Layer Considerations
In future ATM, two main application types are foreseen, namely, short message exchanges, and
file transfers. In addition, two additional applications are under discussion which are VoIP
traffic [6] and transmission of sensor data for the aircraft health management [7]. In this chapter,
we focus on file transfer. Especially, Graphical Weather Information transmission on the forward
link is considered [1], since it is the main application which generates 80% of the total data
4.3 Performance Assessment 42
traffic [65,66] (excluding VoIP traffic). This service requires reliable transmission of 110 kB of
information to an aircraft.
The main TCP standard (RFC 793 [32]) is mandated by ATN/IPS [9] for the reliable transport,
however, no additional TCP variant is mandated or proposed. In order to run TCP effectively over
a certain wireless link technology, it is important to know the Bandwidth Delay Product (BDP) of
the communication path and to set suitable TCP parameters. In this part, we provide preliminary
analysis of TCP in order to find suitable parameters that will be used in HA buffering performance
simulations in Section 4.3.5. Table 4.5 shows the measured round-trip time (RTT) values for
different MSS values considering the network topology shown in Fig. 3.2. In order to measure the
RTT values, we consider a simple ping application with a sending rate equal to the LDACS1 data
rate assigned to the user. The calculated BDP values are around 2 kB and 7 kB for 31.5 kbit/s and
158 kbit/s data rates, respectively. With those BDP values, LDACS1 can be classified as a “Long
Thin Network” [67]. The table also shows the protocol overhead for TCP (20 B), IPv6 (40 B), and
LDACS1 (7 B) for different MSS values. In case the aircraft is in a foreign network, additional
40 B is added due to IPv6 tunneling between the mobile node and its HA. In our analysis, we
consider a MSS value of 1024 B, since it has less overhead and the measured RTT value is only
0.1 s worse compared to a MSS value of 261 B. This increase is not that critical considering the
delay requirement for the WXGRAPH service which is 30 s as one-way latency [1]. As overhead
is the more critical issue than RTT values in this case (LDACS1 provides limited data rate to
users), we consider a MSS of 1024 B in Section 4.3.5.
4.3.4 Further Assumptions
Wireless channel losses (i.e., the FER) are modeled as i.i.d. with the values shown in Section 4.3.1.
The standard TCP ACK scheme is considered, i.e., no delayed TCP ACKs.
We also assume that the allocated user data rate in both cells is the same (i.e., 31.5 kbit/s)and that all LDACS1 specific messages are transmitted without any channel error. ARQ is enabled
with at most five retransmission opportunities for the user data.
4.3.5 Simulation Results and Analysis
Our analysis are differentiated based on unlimited and limited LDACS1 buffer sizes. Similar
to Chapter 3, three different scenarios are defined, namely, baseline, proposal 1, and proposal
2. The baseline scenario refers to the proposal 2 in Section 3.3.2, which is mainly using a link
MSS RTT Overhead Overheadhome domain foreign domain
256 B 0.27 s 20.7% 29.5%512 B 0.295 s 11.6% 17.3%1024 B 0.375 s 6.1% 9.5%
Table 4.5 – RTT and overhead for different MSS values for a 31.5 kbit/s link.
4.3 Performance Assessment 43
layer trigger (IEEE 802.21 functionality) in the BS to send a RA message to the aircraft after the
layer 2 handover is completed. Proposal 1 refers to the proposal 3 in Section 3.3.2, which is an
addition of DAD modifications. Finally, proposal 2 which relies on the addition of HA buffering
method introduced in Section 4.2.
4.3.5.1 Unlimited LDACS1 Buffer Size
In this case, buffer size of the LDACS1 BS is set large enough so that no TCP packet drops occur
at the BS due to buffer overflow and the only reason of TCP packet losses are due to wireless
channel. Due to aggressive behavior of TCP during slow start phase, if the receiver window size
(rwnd) of TCP is chosen so high (e.g., 64 kB), then the retransmission timeout (RTO) inflation
occurs which makes TCP sender less reactive in case a handover event occurs. For this reason,
the transmission rate of TCP is limited by setting the rwnd to a reasonable value. The selection
of rwnd is explained in the following section.
Receiver Window Size Analysis
Receiver window size (rwnd) is an important parameter of the TCP. Fig. 4.6 shows the actual
RTT values measured when TCP is running with different advertised rwnd values. Looking at
Fig. 4.6a, 2 kB, 4 kB, and 8 kB rwnd values lead to reasonable RTT values. In the case of 16 kB
rwnd, the RTT value reaches up to 4 s, which can be classified as an RTT inflation [68]. RTT
inflation is mainly due to LDACS1’s excessive queuing delay. This is also causing RTO inflation
as shown in Fig. 4.7, so that the TCP sender becomes less reactive due to higher recovery time,
which, in turn, causes worse TCP recovery in case a handover event. Here, RTO is calculated via
smoothed round-trip time (SRTT) and round-trip time variation (RTTVAR) parameters, which
are calculated based on the Jacobson’s algorithm [69].On the other hand, when rwnd is set to 2 kB and the user data rate is 158 kbit/s, the link is
under utilized so that the transmission is completed around 7 s later compared to the 8 kB rwnd
as shown in Fig. 4.6b. In this case, 8 kB and 16 kB rwnd provide reasonable RTT values.
In our case, we paid attention not to set the advertised window size too low since it creates
an upper-bound on the transmission rate and may cause under utilization of the link as shown in
2 kB case of Fig. 4.6b. Therefore, in order to set the reasonable advertised window size, mobile
user should have the knowledge of the BDP of the link. One approach is to consider cross layer
information such that link technology measures the RTT and instantaneous throughput and
sends this information to TCP in order to adjust the advertised window size [70,71]. Another
approach is to set the receiver window size dynamically by measuring the bandwidth and the
RTT of the TCP connection as proposed by [72,73].In this section, TCP Reno with the settings shown in Table 4.6 is considered in order to show
the performance gain of the HA buffering method in Section 4.3.5.
4.3 Performance Assessment 44
60 65 70 75 80 85 90 950
1
2
3
4
5
6
7
Time (sec.)
Mea
sure
d R
TT (s
ec.)
Max window = 2 KByteMax window = 4 KByteMax window = 8 KByteMax window = 16 KByte
(a) RTT with different advertised window sizes, datarate/user = 31.5 kbps,MSS=1024.
60 65 70 750.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Time (sec.)
Mea
sure
d R
TT (s
ec.)
Max window = 2KbyteMax window = 4KbyteMax window = 8KbyteMax window = 16Kbyte
(b) RTT with different advertised window sizes, datarate/user = 158 kbps,MSS=1024.
Figure 4.6 – RTT analysis with different advertised window sizes and LDACS1 data ratesduring 110 kB file transfer.
Results
Fig. 4.8 shows the TCP transmission completion duration of 110 kB of file transfer for the three
scenarios. These values are taken from 20 simulation runs where each run simulates one
aircraft handover instance. Both the baseline and proposal 1 show similar performance as both
approaches wait for the TCP sender timeout (i.e., the RTO timer expiry) so that the new packets
will be sent to the new link. In a few cases, the TCP sender goes to two timeouts in baseline,
because the handover is completed after the first timeout occurrence at the TCP sender. In this
4.3 Performance Assessment 45
485 490 495 500 505 510 515 5201
2
3
4
5
6
7
8
9
10
Time (sec.)
Ret
rans
mis
sion
Tim
eout
- R
TO (s
ec.)
Max window = 4 KbyteMax window = 6 KbyteMax window = 8 KbyteMax window = 16 Kbyte
Figure 4.7 – TCP RTO analysis with different maximum window sizes (file transfer of 110 kB,data rate per user of 31.5 kbit/s, MSS of 1024 B.
Parameter Value
Algorithm RenoMaximum Segment Size 1024 BReceiver Advertised Window 6 kBSlow Start Threshold 64 kB
Table 4.6 – TCP Reno parameters used in our simulations.
case, the transmission completion time increases for about 8 s since the retransmission timer
value increases exponentially in every timeout. In proposal 2, since HA forwards the buffered
traffic after the handover is completed, the TCP receiver continues to send ACKs to the TCP
sender, which, in turn, causes transmission of new packets by the TCP sender. In this case, the
transmission is completed almost 4 s earlier on average compared to proposal 1.
Fig. 4.9 plots the received TCP sequence numbers over time for all three scenarios considering
a single simulation run. In baseline and proposal 1, the handover starts at around t1 (at 500.2 s).
However, in proposal 2, it starts about 1.9 s later (t4). This is due to the fact that in proposal
2, the currently attached BS continues to deliver the packets in its buffer before it initiates the
handover process. In this figure, t2, t3, and t5 show the handover completion time of proposal 1,
baseline and proposal 2, respectively. It is also good to mention that due to the ARQ component,
all TCP packets are delivered to the aircraft without any loss due to wireless channel affects in
normal situation (i.e., from TCP session establishment to TCP session closure) except handover
duration.
4.3.5.2 Limited LDACS1 Buffer Size
In this case, LDACS1 buffer size is set to a limited value (so that TCP packet losses occur not
only due to wireless channel losses but also due to buffer overflow at the link layer) and TCP
4.3 Performance Assessment 46
Baseline Proposal 1 Proposal 230
32
34
36
38
40
42
44
46
48
50
Tran
smis
sion
Com
plet
ion
Tim
e (s
ec.)
Figure 4.8 – TCP Reno transmission completion time.
470 480 490 500 510 5200
2
4
6
8
10
12
14 x 104
Time (Sec.)
Seq
uenc
e N
umbe
r
500 502 504 506
5
5.2
5.4
5.6
5.8x 104
BaselineProposal 1Proposal 2
t1 t2 t5t3t4
Figure 4.9 – Received TCP sequence number.
rwnd size is set to a large value (i.e., 64 kB). In general, TCP congestion window management
and loss recovery mechanisms will determine the overall performance. Since there might be
multiple losses in a single window of data, TCP NewReno is considered for the simulations of
this section with the settings shown in Table 4.7.
Results
Fig. 4.10 shows the TCP transmission completion duration of 110 kB of file transfer for the
proposal 1 and 2 with LDACS1 buffer size of 8 packets and 16 packets. These values are taken
from 50 simulation runs where each run simulates one aircraft handover instance. Similar to
4.3 Performance Assessment 47
Parameter Value
Algorithm NewRenoMaximum Segment Size 1024 BReceiver Advertised Window 64 kBSlow Start Threshold 64 kB
Table 4.7 – TCP NewReno parameters used in our simulations.
the previous section results, TCP session completion time is reduced by 10% for a download of
110 kB of data in HA buffering compared to the proposal 1.
pro1-buf8 pro1-buf16 pro2-buf8 pro2-buf1628
30
32
34
36
38
40
42
44
46
48
Tra
nsm
issi
on C
ompl
etio
n T
ime
(sec
.)
Figure 4.10 – TCP NewReno transmission completion time.
4.3.6 Relation Between Handover Completion Time and TCP RTO Expiry Time
In case that the handover completion time is larger than the TCP RTO expiry time, the HA will
also buffer all the retransmitted packets. If such a case occurs, the HA should drop the TCP
packets with the same sequence number in order not to overload the LDACS1 BS by sending
multiple copies of the same packet. However, if those packets are IPSec protected, it is not
possible to check the sequence numbers – other solutions are required. In our case, the situation
is completely different since handover completion time in proposal 2 is significantly shorter than
the TCP RTO expiry time (about 4 s when advertised rwnd is 6 kB, cf. Fig. 4.7), so that HA only
buffers the packets that are sent by TCP sender for the first time.
4.3.7 Mobility Signaling Message Loss Conditions in Home Agent Buffering Method
In this section, we discuss possible scenarios when a mobility signaling message is lost due to
mainly wireless channel errors. Normally, the loss probability of a MBU in the RL and MBA
message in the FL are 0.322 and 6.31× 10−5, respectively. However, due to the ARQ component
4.3 Performance Assessment 48
of LDACS1, the loss probabilities get reduced to about 1.1× 10−3 for the MBU in the RL and to
6.25× 10−26 for the MBA in the FL with five retransmission possibilities. Here we assumed that
the each retransmission is an independent event.
After the first release of LDACS1 specification, high Packet Error Rate (PER) values in the RL
were noticed when the mobile sends a message with multiple physical layer PDUs in a multiframe.
For this reason, an updated specification is developed (as explained in Appendix B) which results
significantly reduced PER. In the considered case, the loss probability of MBU message becomes
1× 10−5 instead of 0.322 for a single transmission.
4.3.8 Impact of Signaling Message Losses on the Handover Performance
We have identified four important cases related to mobility signaling message losses, which
we discuss in the following. The first two conditions are related to loss of MBU messages and
loss of MBA messages, respectively followed by successful regular home registration procedure.
The other two conditions are specifically tied to the loss of MBA message followed by delayed
regular home registration procedure which is due to either loss of regular BU or loss of regular
BA message.
First case – loss of all MBU messages before handover with regular home registration after
handover:
When the mobile sends a MBU, it starts a timer which is initially set to 1 s. In case it does
not receive a MBA within 1 s, it retransmits another MBU. After three retransmission, it stops
the retransmission and waits for the HO_COM message (with P-bit not set) to perform regular
handover. Note that, if the MBA message is not received by the mobile, it is not aware whether
the MBU or the MBA was dropped.
In case all MBU messages are dropped, i.e., not received by the HA, the HA will continue
the normal forwarding operation for incoming packets to the currently attached LDACS1 BS. In
the meanwhile, the BS informs the mobile that it still has some packets by sending a HO_COM
(with P-bit set). In parallel, the BS continues to check the received power level and, when the
received power drops below a certain threshold Th2, it initiates the handover by sending a
HO_COM message (with P-bit not set). So that mobile starts layer 2 handover followed by regular
home registration procedure. This condition is more like a forced handover. In such a case,
the performance of the HA buffering (proposal 2) will be the same as with proposal 1. The
only difference is that the handover will start later (in the order of a few seconds) compared to
proposal 1.
Second case – loss of all MBA messages before handover with regular home registration
after handover:
If a MBA message is lost, the mobile sends another MBU after the timer expires, which, in turn,
triggers the transmission of another MBA. In case all MBA messages are not received by the
mobile, it does not affect the performance of the protocol since the HA already received the
4.3 Performance Assessment 49
MBU and starts buffering the traffic. Similar to the first condition, the mobile has no information
whether the MBU or the MBA got lost.
The HA stops forwarding the traffic to the current LDACS1 BS when it receives MBU message.
Afterwards, when the BS queue becomes empty, BS will send a HO_COM (with P-bit not set)
to the mobile, which starts layer 2 handover followed by regular home registration procedure.
So, there is no negative outcome of this condition and the aircraft still uses the HA buffering
functionality.
Third case – loss of regular BU message after handover with loss of all MBA messages
before handover:
In this case, the HA continues to buffer the traffic until it receives the regular BU message. If the
regular BU reception is delayed due to losses, then the handover completion time and in parallel
the reception of the first packet over the new link is also delayed. In case the TCP sender receives
the first ACK from the new link before TCP RTO timer expiry, then the TCP sender will not go
to timeout and will continue its regular operation. Otherwise (i.e., the reception of first ACK
after TCP RTO expiry) the TCP sender will go to timeout and will retransmit unacknowledged
packets. In this case, HA should do the operation defined in Section 4.3.6.
We will again observe the same TCP retransmission behavior in baseline and proposal 1
scenario due to TCP RTO timer expiry. However in the HA buffering case, if the HA does not
drop the packets with the same sequence number, it will cause additional traffic on the newly
attached LDACS1 BS.
Fourth case – loss of first regular BA message after handover with loss of all MBA messages
before handover:
In this case, the HA receives regular BU message and creates an entry in the binding cache and
forwards the buffered packets to the mobile. However, since the mobile cannot receive the first
regular BA message, it does not create an entry in its binding update list. Thus, the mobile
drops the forwarded packets and waits until MIPv6_INITIAL_BINDACK_TIMEOUT timer expiry
in order to retransmit a new BU.
As the HA forwards the buffered packets to the LDACS1 BS, those packets consume a certain
amount of resources on the FL although they will be dropped by the aircraft due to the loss of
regular BA message. Similar to the first case, handover will start later compared to proposal 1
and the performance of HA buffering will be the same as proposal 1.
4.3.9 Home Agent Buffering Load Considerations
As mentioned in Chapter 1, when an aircraft is flying in TMA/ENR service volumes, it normally
communicates with two CNs. One CN is for the air traffic services and one for the airline
operations. WXGRAPH information is received from AOS CN and normally represent 80% of
the total traffic. Another message type is Common Trajectory Coordination (COTRAC), which
requires transmission of about 6 kB in the forward link and 5 kB in the return link. The remaining
4.3 Performance Assessment 50
network traffic consists of small message exchanges of a few 100 B per message. This means,
mostly WXGRAPH traffic will be affected by the handover events due to higher load and longer
transmission time. Therefore, we can say the number of flows running in parallel in aeronautical
domain is quite limited per aircraft, which, in turn, can be handled using the HA buffering
method. However, assuming the use of consumer electronics, multiple long-lasting flows can be
expected. Another important criteria is the number of mobile users (i.e., aircraft), which is in
the order of a several thousand in the aeronautical environment [5]. This can easily be handled
by HA buffering. Again, assuming the presence of consumer electronics, this number could be in
the order of a few million.
4.4 Conclusion
In this chapter, we first analyzed different layer 3 approaches for improving the performance
of on-going TCP sessions during the handover. In the second step, we further studied and
investigated the performance of HA buffering method through network simulations considering
LDACS1 as an underlying link technology with TCP Reno and NewReno as the transport protocol.
The proposed method improves the total transmission completion time of a session by at least 10%
for a download of 110 kB of information. Finally, we analyzed its applicability to aeronautical
domain considering network load considerations.
Chapter 5
Radio Resource Management
This chapter consists of two main sections. In the first section, we propose a scheduling architec-
ture in a hierarchical structure similar to [74]. While strict priority scheduling mechanism or
weighted fair queueing can be applied among different service classes at the first level, another
scheduling algorithm is used for each service class at the second level.
In the second section, we will look at the performance of different scheduling algorithms
considering two different ATM applications. We restrict our work to scheduling algorithms
running at the second level and focus on two different service classes separately. In the first class
of service, we consider file transfer of graphical weather information (i.e., WXGRAPH service).
In the second class, we consider VoIP as an example for real-time service. Using our integrated
LDACS1 model [12], we thoroughly analyzed the performance of three different scheduling
algorithms for each service class in terms of delay and bandwidth fairness.
5.1 Scheduling Architecture
Fig. 5.1 shows the main LDACS1 scheduling architecture for the forward and return link in
LDACS1. The scheduling algorithm for forward and return link is running in the LME block and
packets are queued in the DLS block. In the RL, LDACS1 only supports one type of bandwidth
request mechanism: explicit contention-free bandwidth request and response. In this mechanism,
each aircraft explicitly sends its bandwidth request in the DCCH slot in order to receive resources
for the RL transmission to the BS in the upcoming data slot (i.e., RL Data). After the BS receives
the bandwidth requests of all aircraft, the scheduling algorithm distributes the resources that
correspond to the data slots of an upcoming MF (i.e., duration of 58.32 ms) for both links (i.e.,
RL and FL) as shown in Fig. 2.3.
As mentioned above, strict priority scheduling or weighted fair queueing mechanisms can
be used at the first stage depending on the usage of application types. If currently defined
ATM applications (cf. Chapter 1) are only used in the network then strict priority scheduling
is enough since high priority message volume is significantly smaller compared to low priority
message volume [66]. In this case, we do not expect any bandwidth starvation problem for
low priority messages. However, if VoIP with high priority is accepted to be used in the future
51
5.1 Scheduling Architecture 52
CoS-1
….
Classification
CoS-2 CoS-8CoS-1
….
Classification
CoS-2 CoS-8
Figure 5.1 – LDACS1 link scheduling architecture.
ATM then it might cause bandwidth starvation problem. In this case, usage of weighted fair
queueing scheduling mechanism is more acceptable since it allocates a certain portion to all
services classes from available bandwidth depending on its priority level [75].
5.1.1 QoS Mapping
QoS mapping between applications and link technology service classes is one of the consideration
for the scheduling mechanism. In our case, on the one side LDACS1 supports eight different
service classes and on the other side, twelve different application level class of services are
defined [1]. The mapping between application CoS and LDACS1 service classes are not studied
in this thesis. In our work, we assume two different application CoSs are mapped to two different
LDACS1 service classes.
5.1.2 Time Complexity Analysis
There are two components that affect the complexity of the scheduling process independent
from the scheduling algorithm. The first one is the transmission of resource request messages
from DLS to LME, which will be processed by the scheduling algorithm. If we consider N users
requesting resources then the preparation of the resource request message takes a complexity of
order O(N) since we have to go through resource requests of all users.
The second one is the dequeuing operation when the scheduling algorithm running in LME
gives the output of resource allocations to the DLS. If only M users (out of N user requests)
receive allocations according to the result of the scheduling algorithm, then the dequeuing
operation searches for the packets of the M users in the DLS queue. For each user, we have to
search the packets in the DLS queue where the data of N user is located. In our implementation,
“find” function of a C++ STL multimap is used for searching each user data with the O(log N)
5.1 Scheduling Architecture 53
complexity. So the total complexity for M number of users is O(M)×O(log N) where M ≤ N . In
case M � N , the total complexity becomes max(O(M), O(log N)). In case M ∼ N , the complexity
becomes O(N log N). In the following sections, three different algorithms are presented for the
FL and the RL. Resource allocations are performed in terms of byte and PDU for the FL and the
RL, respectively.
5.2 Modified Deficit Round Robin with Fragmentation
According to the original DRR algorithm [76], when a packet arrives to the queues, its flow
number is checked first. In case the flow number is in the list (i.e., activelist), the packet is just
enqueued corresponding to the specified flow number. In case the flow number is not in the list,
it is inserted in the active list and the packet is enqueued corresponding to the specified flow
number. In our case, when the LME module receives resource requests of all users, it performs
similar operation for the insertion of the user to active list and setting Deficit Counter (DC) to
zero as shown in Algorithm 3 (i.e., lines 1-7).
Afterwards, the dequeuing operation of packets takes place while the algorithm is running
according to the original algorithm [76] such that it first checks whether the DC is greater or equal
to the size of the head-of-line packet. If this is the case, the algorithm performs the dequeuing
operation, sends the packet, and decreases the DC by packet size. In the other case, the algorithm
just increases the DC by a quantum size (Qsize) and does not send the packet. Since the algorithm
needs to know the size of the head-of-line packet, it requires certain modification for LDACS1.
The reason is that, in LDACS1 queues and scheduler are located in separate compartments. In
LDACS1, normally in every MF, the DLS entity where the queues are located sends bandwidth
requests for every user to the LME entity where the scheduler is running. For this reason, we
had modified the DRR in a way that it operates on the bandwidth request of each user (sent
by DLS) and not based on the size of the head-of-line packet as shown in the Algorithm 4 (i.e.,
lines 11-51). In our implementation, we select the quantum size (Qsize) equal to the packet size.
The modified algorithm is able to run for both links (i.e., FL and RL) separately.
It also needs to be mentioned that the quantum size Qsize is selected in terms of bytes on the
FL and in terms of PDUs on the RL according to the bandwidth requests from DLS in BS and
DLS in aircraft, respectively. For real-time services (e.g., VoIP), the quantum size is selected as
103 B on the FL and 8 PDUs (which makes 112 B for lowest coding modulation scheme) on the
RL. For file transfer on the FL, we select a quantum size of 1091 B. Since the resource requests
of different CoSs are sent separately, it is possible to differentiate which quantum size is used
for which CoS traffic.
Time Complexity Analysis
If the quantum size is large (e.g., 1091 B) and each user requests large number of resources in
every MF compared to the available resources (i.e., ReqMapi >> (W/N)), then only limited
users (i.e., M << N) will get resources in every MF so that the time complexity becomes O(M)
5.2 Modified Deficit Round Robin with Fragmentation 54
input : Total bytes available for allocation W , requesting number of users N , a map ofrequests ReqMap of size N , minimum allocation Wmin byte, packet size ofpktsize byte, list of active users act ivel ist
output : A map of allocations AllocMap of size M1 for n← 1 to N do2 if (n is not in the act ivel ist) then /* Addition of a user to active list */3 activelist.pushback(n);4 DCn = 0;5 end6 Reqi = ReqMapn;7 total reqb y tes+ = ReqMapn;8 end9 if (total reqb y tes <W ) then /* Underloaded case */
10 W = total reqb y tes;11 end
Algorithm 3: DRR with fragmentation – resource allocation - part 1.
where M << N . If the quantum size is small (e.g., 103 B), then each user will get a portion
from the available resources in every MF (assuming each user at least requests resources equal
to quantum size (ReqMapi >=Qsize) ) so that the time complexity will be in the range of O(N).
5.3 Fair-Share Scheduling
Fair-Share Scheduling (FSS) is designed to allocate resources equally to all users [77] as shown
in Algorithm 5. In our case, when the LME receives resource requests of all active users, it directly
divides the total available bandwidth by the number of users and assigns the corresponding
portion to each user. There are two important considerations for the algorithm:
• In case the resource request of a user is less than the available bandwidth for a single
user then the remaining resources are uniformly distributed among the other resource
requesting users.
• Similarly, in case there are some remaining bytes or PDUs left due to division of total
available resources to the number of resource requesting users, then these remaining bytes
or PDUs are also uniformly distributed among the resource requesting users.
Time Complexity Analysis
In this case, the algorithm distributes resources depending on the number of users. As mentioned
above, each user at most can get its fair share. If each user requests at least its fair share in every
MF (i.e., ReqMapi ≈ (W/N)) then the time complexity of the algorithm is O(N). If some users
request resources smaller than the fair share, the remaining resources are equally distributed
among the other resource requesting users which also adds additional complexity of O(N) in
the worst case. In general, the total time complexity is in the range of O(N).
5.3 Fair-Share Scheduling 55
12 while W >Wmin do13 Remove head of activelist (useri → f lowi)14 DCi = DCi + pktsize;15 f ragmenteddata = f alse16 while (DCi > 0 and ReqMapi > 0) do17 if (W >= pktsize and DCi >= pktsize) then18 if (ReqMapi >= pktsize) then /* Give full packet size data */19 AllocMapi+ = pktsize;20 ReqMapi−= pktsize;21 DCi−= pktsize;22 W−= pktsize;23 else if (ReqMapi < pktsize) then /* Give requested data */24 AllocMapi+ = ReqMapi;25 ReqMapi = 0;26 DCi−= ReqMapi;27 W−= ReqMapi;28 end29 else if (W < pktsize and W >Wmin and DCi >= pktsize) then /* Give less
than full packet size data */30 if (ReqMapi >=W ) then /* Give remaining data */31 AllocMapi+ =W ;32 ReqMapi−=W ;33 DCi−=W ;34 W = 0;35 f ragmenteddata = t rue;36 else if (ReqMapi <W ) then /* Give requested data */37 AllocMapi+ = ReqMapi;38 ReqMapi = 0;39 DCi−= ReqMapi;40 W−= ReqMapi;41 end42 else43 break;44 end45 end46 if (AllocMapi == Reqi) then /* User gets all requested data */47 DCi = 048 else if ( f ragmenteddata == t rue) then /* Let user stay at the top */49 activelist.pushfront(i);50 else /* Put user to the end */51 activelist.pushback(i);52 end53 end54 for (i← AllocMap.begin() to AllocMap.end()) do55 Send AllocMapi;56 end
Algorithm 4: DRR with fragmentation – resource allocation - part 2.
5.3 Fair-Share Scheduling 56
input : Total bytes available for allocation W , requesting number of users N , a map ofrequests ReqMap of size N , a vector of users UserVector of size N , minimumallocation Wmin byte
output : A map of allocations AllocMap of size M1 le f tover = 0;2 RandUser List = random_su f f le(UserVector);3 while (W >Wmin and ReqMap.size()> 0) do4 b y tesuser =W/ReqMap.size();5 if (b y tesuser == 0) then /* Not enough resources for all users */6 le f tover+ =W ;7 break;8 end9 if ((b y tesuser ∗ ReqMap.size())<W ) then /* Store the remaining bytes */
10 le f tover+ =W − (b y tesuser ∗ ReqMap.size());11 W−= le f tover;12 end13 for (i← ReqMap.begin() to ReqMap.end()) do14 if (ReqMapi >= b y tesuser and W > 0) then /* Give what is available */15 AllocMapi+ = b y tesuser ;16 W−= b y tesuser ;17 ReqMapi−= b y tesuser ;18 else if (ReqMapi < b y tesuser and W > 0) then /* Give what is requested */19 AllocMapi+ = ReqMapi;20 W−= ReqMapi;21 ReqMap.erase(i);22 end23 end24 end25 for (i← RandUser List.begin() to RandUser List.end()) do26 if (le f tover!= 0) and (le f tover!= 0) then /* Add remaining resource to a
user */27 AllocMapi+ = 1;28 le f tover−= 1;29 end30 Send AllocMapi;31 end
Algorithm 5: FSS – resource allocation.
5.4 Randomized User Selection Scheduling 57
5.4 Randomized User Selection Scheduling
The idea of the Randomized User Selection (RANDUS) algorithm is to assign resources to users
randomly considering uniform distribution in every MF as shown in Algorithm 6. It is a basic
scheduler that does not consider any fairness criteria when distributing resources among different
users. In our implementation, random_shuffle function of C++ STL algorithms library is used
for randomizing the resource requesting users.
input : Total bytes available for allocation W , a map of requests ReqMap of size N ,vector of users UserVector of size N , minimum allocation Wmin byte
output : A map of allocations AllocMap of size M1 RandUser List = random_su f f le(UserVector)2 while (W >Wmin and RandUser List.size()> 0) do3 AllocMapi = min(ReqMapRandUser List i
, W );4 W−= AllocMapi;5 Remove RandUser List i from ReqMap and RandUser List;6 Send AllocMapi;7 end
Algorithm 6: RANDUS – resource allocation.
Time Complexity Analysis
In every turn (i.e., multiframe), user vector of size N is randomized which is O(N) time complexity.
In case each user requests large number of resources compared to the available resources
(i.e., ReqMapi >> (W/N)), RANDUS only provides resources to limited number of users (i.e.,
M << N) since it does not check any fairness criteria among users. In this case, the time
complexity of the algorithm is still O(N) due to the randomization. In the other case, when each
user only requests a portion of the available resources (i.e., ReqMapi ≈ (W/N)), all users will
get a portion from the available resources so that the time complexity becomes O(N).
5.5 Performance Evaluation
This section analyzes the performance of three scheduling algorithms explained above. The
analysis are based on two application types, namely file transfer and VoIP, and consider average
throughput and delay fairness as main performance parameters. Boxplot representations are
mainly used for showing the results of each algorithm.
5.5.1 Assumptions
Similar to [78], we assume that packets are sent over ideal wireless channel conditions, so that
no packets are dropped due to wireless channel impairments. We also consider finite drop-tail
First-In-First-Out (FIFO) queues at the BS and the mobile. For VoIP analysis, we consider buffer
size of 5 packets per user in FL and 5 packets in RL. Since LDACS1 has a contention free access
5.5 Performance Evaluation 58
scheme, we also consider overloaded scenario for VoIP in order to analyze the delay fairness of
the scheduling algorithm. We select smaller buffer size for VoIP traffic due to its delay sensitive
characteristic. For the file transfer (i.e., the TCP analysis), we consider buffer size of 15 packets
(each packet has 1 kB) per user in FL, which is slightly larger than the advertised receiver window
size (14 kB).
5.5.2 Considered Topology and Simulation Parameters
In our analysis, we use the same European scenario where different number of aircraft are
communicating with an ATS or AOS CN. We also assume the same configuration for the ground
network delay values as shown in Fig. 3.2. We consider different scenarios based on different
number of active users and collect the data of 5 different simulation runs for each scenario.
For each simulation run, we calculate mean and standard deviation of the main performance
parameters (i.e., average throughput per user and one way end-to-end delay per user).
5.5.3 File Transfer Analysis
For file transfer analysis, the TCP Reno variant is used in the simulations with the settings shown
in Table 5.1. We again considered a file transfer of WXGRAPH data of size 110 kB on the FL [1]with four different scenarios with 5, 10, 15, 20 users, respectively.
In our analysis, we used the Jain’s fairness index (F j) as the primary performance measure,
which is calculated as [79]
F j =(∑N
i=1 x i)2
N ·∑N
i=1 x2i
, (5.1)
where N is the number of active users and x i is the normalized throughput of useri which is
defined as
x i =Oi
Ti, (5.2)
where Oi is the measured throughput of useri during simulations and Ti is the fair throughput
of useri which is the ratio of total available throughput to the number of active users.
Parameter Value
TCP algorithm RenoMaximum Segment Size 1024 BReceiver Advertised Window 14 kBSlow Start Threshold 64 kB
Table 5.1 – TCP Parameters.
5.5 Performance Evaluation 59
5.5.3.1 Modified Deficit Round Robin Scheduling
Table 5.2 shows the calculated fairness indexes for different number of users. It is clearly visible
that the algorithm shows almost perfect fairness among all active users. In all scenarios, we did
not observe any packet loss due to LDACS1 queue overflow as well.
Number of Users F j
5 0.999710 0.999715 0.999720 0.9998
Table 5.2 – DRR-fairness indexes for different number of users.
5 User 10 User 15 User 20 User
15
20
25
30
35
40
45
50
55
60
Ave
rage
Thr
ough
put p
er U
ser
(kbp
s)
Mean = 57.72Mean(StdDev) = 1.16
Mean = 14.23Mean(StdDev) = 0.22
Mean = 19.01Mean(StdDev) = 0.31
Mean = 28.52Mean(StdDev) = 0.54
Figure 5.2 – DRR-average throughput per user on the forward link.
Fig. 5.2 shows the measured average throughput of each user on the FL with different
numbers of users. As expected, the average throughput decreases gradually as the number of
active users increases. As the number of users increases, the scheduling algorithm continues
to deliver resources fairly among all users and the mean of standard deviation of measured
throughput changes from 1.16 kbit/s to 0.22 kbit/s for different active users. Fig. 5.3 denotes
the number of fragmented and complete transmitted packets for DRR scheduling mechanism.
5.5.3.2 Fair-Share Scheduling
The fairness index of FSS is higher than that of DRR scheduling as shown in Table 5.3. This
is mainly due to the equal distribution of resources among resource requesting users for each
scheduling process.
As shown in Fig. 5.4, the average throughput distribution of FSS is better than the DRR
and the mean of standard deviation of measured throughput changes between 0.42 kbit/s and
5.5 Performance Evaluation 60
200
400
600
800
1000
1200
1400
1600
1800
2000
2200
2400
2600
Tra
nsm
itted
Pac
kets
(F
ull &
Fra
gmen
t)
5-UserFrag
15-UserFrag
5-UserFull
10-UserFull
10-UserFrag
15-UserFull
20-UserFull
20-UserFrag
Figure 5.3 – DRR-number of transmitted packets on the forward link (full & fragment).
Number of Users F j
5 110 115 120 1
Table 5.3 – FSS-fairness indexes for different number of users.
0.09 kbit/s depending on the number of active users. Similar to DRR, TCP transmission timeouts
are not observed in all scenarios. However, since this algorithm causes more fragmentation
compared to the DRR algorithm (cf. Fig. 5.5), the average throughput is slightly smaller than the
DRR algorithm which can be seen by comparing Fig. 5.2 and Fig. 5.4. The difference increases
proportionally with the number of active users since more users cause transmission of more
fragmented packets. In Fig. 5.5, only fragmented packet numbers are presented since full packet
transmissions are negligible compared to fragmented packet transmissions in the FSS.
5.5.3.3 Randomized User Selection Scheduling
The fairness index of the RANDUS algorithm is lower than the FSS and DRR algorithms as
shown in Table 5.4. This is mainly due to the random selection of the users. In this case,
some users get more resources at the beginning of the session which in turn cause more packet
transmissions from the TCP sender due to the aggressive behavior of TCP. When more packets
are transmitted from the TCP sender, those packets are queued in the LDACS1 BS buffer and
demanding resources in order to be transmitted. Since the RANDUS algorithm distributes
resources mainly based on requests and does not follow any fairness criteria among users, the
user who requests more resources gets more transmission opportunities.
5.5 Performance Evaluation 61
5 User 10 User 15 User 20 User
15
20
25
30
35
40
45
50
55
60
Ave
rage
Thr
ough
put p
er U
ser
(kbp
s)Mean = 57.21Mean(StdDev) = 0.42
Mean = 27.32Mean(StdDev) = 0.2
Mean = 17.77Mean(StdDev) = 0.09
Mean = 12.92Mean(StdDev) = 0.09
Figure 5.4 – FSS-average throughput per user on the forward link.
2000
4000
6000
8000
10000
12000
14000
16000
Tra
nsm
itted
Pac
kets
(F
ragm
ent)
10-UserFrag
15-UserFrag
20-UserFrag
5-UserFrag
Figure 5.5 – FSS-number of transmitted packets on the forward link (only fragment).
Number of Users F j
5 0.985110 0.986815 0.968420 0.9714
Table 5.4 – RANDUS-fairness indexes for different number of users.
As shown in Fig. 5.6, average throughput distribution among users changes significantly
compared to FSS (cf. Fig. 5.4) and DRR (cf. Fig. 5.2) algorithms. Mean of standard deviation
changes between 8.02 kbit/s and 2.44 kbit/s depending on the number of active users. However,
as can be seen in Fig. 5.6, the average throughput is higher in RANDUS compared to FSS and
DRR algorithms for the 5 user case since FSS and DRR cause more fragmentation compared
5.5 Performance Evaluation 62
to RANDUS which can be seen by comparing full and fragmented packets transmissions in
Fig. 5.3, Fig. 5.5 and Fig. 5.7. In general, the RANDUS algorithm assigns the requested resource
in case there are enough resource without any upper bound however, in DRR for example,
resources are only assigned to the users in case their deficit counter is equal to or larger than
the packet size. More fragmentation causes slight degradation in the throughput performance
due to fragmentation overhead. In 5 user case, TCP transmission timeout is not observed
for the RANDUS algorithm as well. However, RANDUS looses overhead advantage when we
increase the number of active users (i.e., 10, 15 and 20) since some users start to get TCP
transmission timeouts due to the unfair behavior of RANDUS. These timeouts cause unnecessary
retransmissions (since the original packets are still waiting in BS buffer for transmissions). This
causes a throughput degradation in RANDUS compared to the other algorithms which can be
seen by comparing Fig. 5.6, Fig. 5.4 and Fig. 5.2. We also observed buffer overflows in the BS
due to TCP retransmissions for the RANDUS algorithm since we have limited the transmission
buffer of BS to 15 packets per user as mentioned in Section 5.5.1.
5 User 10 User 15 User 20 User
10
20
30
40
50
60
70
80
90
Ave
rage
Thr
ough
put p
er U
ser
(kbp
s) Mean = 58.51Mean(StdDev) = 8.02
Mean = 28.79Mean(StdDev) = 3.51
Mean = 18.85Mean(StdDev) = 3.51
Mean = 13.95Mean(StdDev) = 2.44
Figure 5.6 – RANDUS-average throughput per user on the forward link.
5.5.4 Real-time Service Analysis
In this section, VoIP is analyzed as an example for a real-time service. We consider one minute
of VoIP session since it is the highest measured value based on current voice communication
between controller and pilot [80]. We simulate different number of users, cf. Table 5.5, for
underloaded and overloaded scenarios. For each scenario, we collect the data of 5 different
simulation runs.
The LDACS1 specification already specified advanced multiband excitation vocoder, version
AMBE-ATC-10B, as a default algorithm for voice coding and decoding. The AMBE-ATC-10B
vocoder produces a voice frame with 96 bit length every 20 ms, which corresponds to a data
rate of 4.8 kbit/s. According to the LDACS1 specification, three voice frames are aggregated and
transmitted together so that the overhead due to lower layers is reduced and the capacity of the
wireless link is better utilized [81].
5.5 Performance Evaluation 63
200
400
600
800
1000
1200
1400
Tra
nsm
itted
Pac
kets
(F
ull &
Fra
gmen
t)
5-UserFull
20-UserFrag
20-UserFull
15-UserFrag
15-UserFull
10-UserFull
5-UserFrag
10-UserFrag
Figure 5.7 – RANDUS-number of transmitted packets on the forward link (full & fragment).
Parameter Value
Number of users (underloaded) Forward: 15; Return: 15Number of users (overloaded) Forward: 25; Return: 25
Table 5.5 – Number of VoIP Users.
Figure 5.8 – Application level VoIP aggregation.
Fig. 5.8 shows the application layer voice frame aggregation. In addition, due to the rigid
timing structure of LDACS1, each mobile has transmit possibilities only once in every MF, i.e.,
every 58.32 ms. So in case that no aggregation is used, the VoIP frames produced every 20 ms
will enter the LDACS1 DLS queue and wait for a transmission opportunity. The overall data rate
with three frame aggregation and lower layer overhead (RTP 12 B, UDP 8 B, IPv6 40 B, LDACS1
7 B) becomes 13.73 kbit/s. With this configuration, the overhead due to lower layers is about
65 %. This actually shows the need for header compression for LDACS1 in order to decrease
the overhead to an acceptable range. However, the current specification only refers to two
International Telecommunication Union (ITU) specifications, V.42 and V.44, without providing
5.5 Performance Evaluation 64
detailed information. Therefore, we have not considered the effect of header compression in
our analysis. Furthermore, we consider one-way delay attributable to codec-related processing
Tcodec in IP networks as (N is denoting the number of frames) [82]:
Tcodec = (N + 1)× T f ramesize + Tlook−ahead . (5.3)
In our case, we consider N = 3 with T f ramesize = 20 ms and Tlook−ahead = 10 ms, thus, a total
delay of Tcodec = 90ms.
The ITU specifies different quality levels for voice services, where 200 ms one-way end-to-end
delay performance is required for a “very satisfied user” [82].
5.5.4.1 Underloaded Case
As shown in Fig. 5.9, in case the system is underloaded, the average one-way delay stays around
190 ms in the FL and 220 ms in the RL for all scheduling algorithms. Two main components of
the wireless link delay are
• the delay between the packet arrival time to DLS queue and service time for the packet in
the next upcoming data frame and
• the transmission delay based on the transmission speed.
0.15
0.2
0.25
0.3
0.35
0.4
One
-way
End
-to-
End
Del
ay (
sec.
)
FL-15UserRANDUS
FL-15UserFSS
RL-15UserRANDUS
RL-15UserFSS
RL-15UserDRR
FL-15UserDRR
Mean ~ 0.19Mean(StdDev) ~ 0.024
Mean ~ 0.22Mean(StdDev) ~ 0.028
Figure 5.9 – Forward and return link one-way end-to-end delay.
In the underloaded case, FL delay values are in the range of “very satisfied user” according
to the ITU specification. However, on the RL delay values are around 0.22 s and correspond
to highest part of “satisfied user”. The main reason for this result is the bandwidth request
mechanism in the RL. In case the cell in not highly populated in terms of number of aircraft
(i.e., the number of aircraft is less than 52), each user has a bandwidth request slot in every
DCCH slot that causes an additional delay of around 60 ms in the RL, including the time for
the reception of bandwidth response in the next CCCH slot. In this case, all algorithms fairly
distribute resources, so that the mean of standard deviation of the delay is less than 0.028 s as
shown in Fig. 5.9.
5.5 Performance Evaluation 65
5.5.4.2 Overloaded Case
In the overloaded case (i.e., 25 users on the FL and on the RL), packet drops due to buffer
overflow in the DLS queues are observed for all scheduling algorithms since the DLS queue
buffers at most 5 packets for each user. As shown in Fig. 5.10, DRR and FSS perform similar
whereas RANDUS shows slightly better average delay performance. Similar to the TCP analysis,
the main reason of the better performance of RANDUS is due to creation of less fragmented
packets which in turn causes less overhead compared to the other algorithms. While the average
delay values increase up to around 0.5 s for DRR and FSS algorithms, it is around 0.38 s for the
RANDUS in the RL. Those delay values with the packet drops are not acceptable for VoIP traffic.
In general, DRR and FSS treat all users again equally so that the mean of standard deviation of
delay stays below 0.05 s. However, for the RANDUS algorithm the mean of standard deviation
increases to 0.18 s in the RL. Since VoIP traffic is affected severely in the overloaded case, it is
recommended to use a call-admission control mechanism.
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
One
-way
End
-to-
End
Del
ay (
sec.
)
FL-25UserFSS
RL-25UserFSS
RL-25UserDRR
FL-25UserRANDUS
RL-25UserRANDUS
FL-25UserDRR
Mean = 0.52Mean(StdDev) = 0.05
Mean = 0.49Mean(StdDev) = 0.05
Mean = 0.51Mean(StdDev) = 0.04
Mean = 0.31Mean(StdDev) = 0.14
Mean = 0.38Mean(StdDev) = 0.18
Mean = 0.49Mean(StdDev) = 0.05
Figure 5.10 – Forward and return link one-way end-to-end delay.
5.6 Conclusion
In this chapter, three different scheduling mechanisms are investigated for LDACS1. We realized
the tradeoff between fragmented packet transmissions (which is directly proportional to the
overhead) and fairness among different users. On the one side, FSS provided best fairness
results while causing the highest number of fragmented packet transmissions, on the other side
RANDUS provided worst fairness results with the least fragmented packet transmissions. From
this perspective, DRR provided a good balance between these two criteria.
Chapter 6
NEMO Route Optimization Analysis
NEMO functionality is one of the main components of the ATN/IPS. NEMO [25] handles the
mobility of all hosts located in aircraft data network as a whole (i.e., moving network) rather
than separate moving hosts. The main drawback of the NEMO protocol is that it does not support
route optimization (RO), a feature which provides better end-to-end delay and path length (in
terms of number of hops) [83]. In the first section, two different NEMO RO proposals published
as IETF drafts are analyzed in terms of protocol operation and required modifications to the
network nodes. This part also provides the usage scenarios of these two protocols in the ATN/IPS.
In the second section, two new modifications are proposed for one of the NEMO RO proposal in
order to provide a better end-to-end delay and less signaling overhead.
6.1 NEMO Route Optimization Classification
Research community proposed different NEMO RO proposals [84], however none of them has
been accepted as a standard by IETF until now. In general, NEMO RO proposals can be grouped
into three main parts considering different networking entities that perform mobility signaling:
1. NEMO RO Proposals from MR to HA [85,86].
2. NEMO RO Proposals from MR to Correspondent Router (CR) [87,88].
3. NEMO RO Proposals from MNN, MR to CN [89–92].
Among these proposals, we have realized that some of them require mobility related func-
tionalities to the end nodes (i.e., MNNs and CNs) and some others do not. In addition, some
proposals try to solve nested NEMO problem [10] without working on the main route optimiza-
tion problem and these proposals are not the main focus of our work. In addition, since most of
these protocols are published as IETF draft, they lack of protocol design and maturity in terms of
implementation. From this perspective, we have considered mainly infrastructure based NEMO
RO proposals in this chapter; namely, global HAHA [85] and correspondent router (CR) [87].
66
6.2 Global HAHA Protocol 67
6.2 Global HAHA Protocol
In NEMO, the HA is the main convergence point on the ground network independent from the
topological locations of the communicating peers. This approach introduces a lack of efficiency
in terms of end-to-end delay and path length (in terms of number of hops) [83] when the
communicating peers are far distant from the HA. The main idea of global HAHA is to distribute
multiple HAs over topologically distant sites so that the MR can select the topologically closest
one to be attached to [85]. Other benefits of this approach can be to avoid single point of
failure (in case one of the HAs fails, others can handle the traffic) and to provide load balancing
among multiple HAs in case one HA is highly loaded. More precisely, new entities called proxy
HAs are introduced in addition to primary HA functionality. Communication between HAs is
performed over pre-established HA-to-HA tunnels to transport packets [93]. According to [85],MR discovers the closest HA by means of DHAAD procedure of MIPv6.
Fig. 6.1 shows an example global HAHA network architecture where each HA is connected
to another via virtual private network tunnels (i.e., HAHA Tunnel) and announce their common
/32 prefix (i.e., Extended Home Network [10]) via an Exterior Gateway Protocol (EGP) to the
global Internetwork. Each HA works as either a primary HA (pri_HA) or a proxy HA (pro_HA)
for an MR and each MR has a HoA configured either from its HNP or MNP depending on the
deployment. From operational perspective, for example when a packet is sent from any CN to
a MR whose primary HA is HA-A, the packet is first routed to the topologically closest HA. In
case the closest HA that intercepted the packet is HA-A, it directly tunnels the packet to MR via
MR-HA tunnel. Otherwise (i.e., the packet is intercepted by proxy HA, HA-B), the proxy HA
tunnels the packet to HA-A over HAHA tunnel and HA-A tunnels the packet to MR via MR-HA
tunnel. In this network, two different bindings could be defined [85], namely primary (pri_HA)
and secondary or proxy (pro_HA) bindings:
- Primary Binding: In general, each MR has a unicast routable address called HoA, used as a
permanent address of MR. This address is configured from a prefix which belong to a certain HA
which is called primary HA in the global HAHA network. When the MR binds with the primary
HA, the binding is called primary binding.
- Secondary/Proxy Binding: In case MR binds with a HA which is not primary, the binding is
called secondary or proxy binding.
6.2.1 New Mobility Header Messages
Global HAHA [85] introduces the following new mobility header messages in order to be used
smoothly with the NEMO protocol.
• Home Agent HELLO Message: It is used to inform other Home Agents about the
activeness of the sender home agent.
• Binding Information Request (BIR) Message: It is used to request binding cache
information corresponding to a particular MR. It is sent only between HAs.
6.2 Global HAHA Protocol 68
HA – HA Tunnel
2001:123:1::/36
Extended Home Network2001:123::/32
/ 32/ 32
HA in Subnet C2001:123:2::/36
/ 32
2001:123:0::/36
EGP Advertisement
Global Internetwork
CN in Network Y
HA in Subnet A
HA in Subnet B
MR in Network X
MR: Mobile RouterCN: Correspondent NodeHA: Home Agent
Figure 6.1 – Global HAHA network architecture.
• Binding Information Update (BIU) Message: It is used by the HAs to exchange binding
cache information.
• Binding Information Acknowledgment (BIA) Message: It is used by the HAs to confirm
recipient of a BIU message.
• Home Agent Switch Request Message: It is used by the HA to request the MR to change to
another HA.
6.2.2 Inter HAHA Operation
In global HAHA network, HAs are using inter-HAHA protocol [93] for communication with each
other. HAs have three new functionalities in addition to the basic NEMO support. These are:
• Binding Synchronization.
• Triggering HA switch.
• HELLO Message Exchange.
Binding synchronization is used to synchronize the binding information of all MRs served by
HAs within the network. This procedure uses BIR, BIU, BIA messages as mentioned above. As
shown in Fig. 6.2, after primary HA (Pri_HA) creates a binding cache in its local, it notifies other
proxy HAs (Pro_HAs) about the binding. After binding synchronization is completed, any HA
can intercept and forward the packets meant for the MR according to the synchronized binding
cache information.
6.2 Global HAHA Protocol 69
HA switching is defined as a new mobility header message in RFC 5142 [94] in order to
notify the MR about a new home agent assignment. This message includes the list of possible
HA addresses and MR selects one from the list. When the MR receives HA switch request, it
checks the Home Address field in the request. If this field has a global scope address and is
recorded in the HA list of the MR, then MR switches to the requested HA by performing proxy HA
registration procedure. Otherwise (i.e., if this field is empty), the MR starts DHAAD procedure
(cf. Fig. 6.2) defined in the MIPv6 [11] in order to find the topologically closest HA and performs
proxy HA registration. NEMO [25] extends the DHAAD (with a new flag (R) in request/reply
message) so that the procedure is used by the MR. One important consideration is that HA
switch message must be protected by IPsec Encapsulating Security Payload (ESP). After the MN
receives the HA switch message, it should also re-establish the necessary SA with the new HA
before sending the new BU.
“HELLO” message is used by the HAs on different links but serving to the same home prefix.
This message is exchanged periodically in order to inform other HAs about its local information
such as preferences, lifetime, and registration status. It is also good to mention that each HA
must know other HAs which are configured in different links beforehand. This is manually
configured on each HA.
Fig. 6.3 denotes the usage of HAHA tunnel where MR communicates with a CN which is
topologically close to the Pro_HA_1. In that case when CN sends a packet to the MR, the packet
is intercepted by the topologically closest HA (i.e., Pro_HA_1) and tunnelled to the Pri_HA since
the MR has a binding with Pri_HA.
6.2.3 Multihoming Support
NEMO allows registration of only one CoA as primary CoA in the binding cache of HA. However
in case a MR simultaneously attaches to multiple access networks, it is able to configure multiple
CoAs which could be used for different purposes (e.g., load balancing, make-before break
handovers, etc.). Multihoming support allows MR to configure several addresses from either a
single interface or multiple interfaces and to use these addresses simultaneously. As specified
in [95], there are different configurations in which a mobile network can be multihomed. The
following sections will explain the main functionalities needed by MR and HA in order to support
multihoming feature in the mobile network.
6.2.3.1 Multiple CoA Registration
The base specification of multiple CoA registration [96] defines a new identifier, called Binding
Identification (BID) number which is generated by the MR for each new CoA it wants to register
to the HA with the binding update message. Generally, BID is an additional reference used for
any operations related to this binding and supported through a new Binding Identifier Mobility
option to be included in Binding Updates and Binding Acknowledgements.
6.2 Global HAHA Protocol 70
Data Transmission via Pri_HA
Initial L2 & L3 Attachment Pri_HA Registration
Pri_HA Binding Update
Pri_HA Binding Ack.
CN(ATS Center)
S: LFN, D: CN, DATA
S: MR_CoA, D: Pri_HA [S: LFN, D: CN, DATA]
S: LFN, D: CN, DATA
S: LFN, D: CN, DATA
S: Pri_HA, D: MR_CoA [S: CN, D: LFN, DATA]
S: CN, D: LFN, DATA
HA Switch Request
Start DHAAD Procedure
DHAAD RequestDHAAD Reply
Pro_HA_1 Binding Update
Binding Info. Ack.
Binding Info. Update
Pro_HA_1 Binding Update
Data Transmission via Pro_HA
Binding Info. Update Binding Info. Ack.
Binding Synchronization
Figure 6.2 – Inter - HAHA operation - 1.
Data Transmission via Pri_HA & Pro_HA_1
Initial L2 & L3 Attachment
Pri_HA Registration
Pri_HA Binding UpdatePri_HA Binding Ack.
S: LFN, D: CN, DATA
S: MR_CoA, D: Pri_HA [S: LFN, D: CN, DATA]
S: LFN, D: CN, DATA
S: Pri_HA, D: MR_CoA [S: CN, D: LFN, DATA]
S: CN, D: LFN, DATA
Binding Info. Update Binding Info. Ack.
Binding Synchronization
Mobility Signalling
Payload (Untunneled)
Payload (MR-HA Tunneled)
S: LFN, D: CN, DATA
S: Pro_HA_1 D: Pri_HA [S: CN, D: LFN, DATA]
Payload (HA-HA Tunneled)
Figure 6.3 – Inter - HAHA operation - 2.
6.2 Global HAHA Protocol 71
6.2.3.2 Flow Binding
The preliminary mechanism to bind flows with the available CoAs is to identify them. Two byte
Flow Identifier (FID) is suggested for this purpose in reference [97]. Flow identification option
is used to identify the flows and to perform routing actions for them. A flow can be identified by
many ways (e.g., (source,destination) IP addresses, (source,destination) port numbers).
6.3 Correspondent Router Protocol
Instead of making the HA main convergence point for a MR, a new entity called Correspondent
Routers (CR) [87] is introduced to perform route optimization. These entities are located inside
a network that is topologically close to the CNs. Fig. 6.4 shows an example configuration of
the CR protocol where CR is placed in subnet-4. Practically, the CR should be placed on the
path between MR and the expected networks where CNs exist. For example, as soon as one
of the CNs inside subnet-4 communicates with the mobile network, MR performs a binding
registration to the CR in subnet-4. Before registration, MR should discover the CR by sending a
CR discovery request to the CR anycast address. After the registration, any packet meant for the
mobile network from subnet-4 is always intercepted by the CR and tunnelled to the MR. On the
return path, MR tunnels the packets, that are sent to subnet-4, to the CR. In this protocol, RR
procedure defined in MIPv6 (cf. Section 2.3) is used between MR and CR for building the route
optimized path as shown in Fig. 6.5.
Figure 6.4 – Correspondent router configuration.
6.3 Correspondent Router Protocol 72
CR: Correspondent RouterCN: Correspondent NodeHA: Home AgentMR: Mobile RouterLFN: Local Fixed NodeHOTI: Home-Test InitHOT: Home-TestCOTI: Care-of Test InitCOT: Care-of Test
CR Discovery Procedure
Initial L2 & L3 Attachment HA Registration
Binding UpdateBinding Ack.
Data Transmission via HA
CR Discovery requestCR Discovery reply
Return Routability ProcedureHOTI/HOT
COTI/COT
Data Transmission via CR
Mobility SignallingPayload (Untunneled)
Payload (MR-HA Tunneled)Payload (MR-CR Tunneled)
Figure 6.5 – Correspondent router operation.
6.3.1 New Mobility Header Messages
CR protocol requires the following modifications in order to be used smoothly with the NEMO
protocol. Among others listed below, it requires forwarding table data structure maintained by
each MR that contains CR address and prefix list (which is notified by the CR).
• Binding Update: The BU has an O flag in order to show that the BU is sent for CR.
• Binding Acknowledgment: The BA has an O flag in order to show that the BA is sent by
CR.
• Managed Prefix Lists sub-option: It is valid only in the BA showing which prefixes are
managed by the CR.
6.3.2 New ICMPv6 Messages
Two new ICMPv6 messages are defined for the discovery of the CR. They have similar structure
of DHAAD request and reply messages defined in MIPv6.
• CR Discovery Request: It used by a MR to discover a CR where correspondent nodes are
located.
• CR Discovery Reply: It is used by a CR to send lists of CRs configured in the network.
6.4 Analysis of Infrastructure Based NEMO RO Methods
Our conclusions for these NEMO RO methods are summarized in Table 6.1. Furthermore,
Table 6.2 provides information about the required modifications to the entities considering
NEMO protocol as baseline.
6.4 Analysis of Infrastructure Based NEMO RO Methods 73
Advantages Disadvantages
Global HAHA
• Not require any modificationsto end nodes(on board and onthe ground)
• Not require end to end PublicKey Infrastructure (PKI)
• Scalable signaling
• Strong security between MRand HA
• Better resilience compared toNEMO [98]
• Semi-RO proposal(performance depends onthe topological closeness ofHA to MR and CN)
• Addition of newfunctionality to the HA
CorrespondentRouter
• Not require any modificationsto end nodes(on board and onthe ground)
• Signaling scalability (canserve several CN)
• Better resilience compared toNEMO
• Semi-RO proposal(performance depends onthe topological closeness ofCR to MR and CN)
• New network entity
• Signaling overhead due toRR procedure
• RR security problems
Table 6.1 – NEMO RO analysis.
New Functionalities
Global HAHA
• Signaling between HAs (i.e., inter HAHA protocol)
• Signaling from HA to MR (i.e., HA switch message)
CorrespondentRouter
• Signaling between MR and CR (i.e., CR registration)
• CR discovery
Table 6.2 – NEMO RO new functionalities.
6.5 Network Attachment Scenarios and NEMO RO Usage 74
6.5 Network Attachment Scenarios and NEMO RO Usage
In the future ATN, two different configurations, based on the aircraft network attachment can
be considered. These configurations are:
• Aircraft attaching to global ACSP network (Configuration 1).
• Aircraft attaching to ANSP or local ACSP network (Configuration 2).
The first configuration is more general compared to the second one since global ACSP
network is the main access network for aircraft within the ATN. In the second configuration,
ANSP operates its own access network (e.g., Deutsche Flugsicherung) where aircraft attaches to
this network.
6.5.1 Global HAHA Configurations
Fig. 6.6 shows two configurations considering ATS and AOS services and global HAHA proto-
col used in global ACSP network. In the first configuration, after the aircraft attaches to the
global ACSP network, it finds the topologically closest HA and builds a mobility tunnel with
it. Afterwards it starts data transmission with the ground entities (e.g., ATS/AOS CNs) via the
corresponding HA. In the second configuration, aircraft attaches to the ANSP access network and
uses the HAs in the global ACSP network and performs the same operations explained above.
6.5.2 Correspondent Router Configurations
The same configurations can be used for explaining the CR approach as well. Generally, CRs are
deployed in the boundaries between global ACSP and ANSP and/or AO networks in order to
provide a better RO since they are topologically closer to ATS and AOS CNs compared to the
HAs located in global ACSPs. As shown in Fig. 6.7, MR builds a tunnel with the CR located in
ANSP and AO networks. Fig. 6.7 shows possible configurations for ATS and AOS services.
AO – in Europe
AOS CN-1
ANSP- Europewith access
network
HAin US
GACSP network
HAin Asia
HA in Europe
ANSP- Europewith access
network
ATS CN-1
HAin Asia
HA in US
HA in Europe
GACSP network
ANSP- Europewithout access
network
ATS CN-2
Configuration 1
LFN - CN Communication PathHA - HA TunnelMR - HA Tunnel
MR: Mobile RouterHA: Home AgentCN: Correspondent NodeANSP: Airline Navigation Service Provider
ATS Configurations AOS ConfigurationsMR
ATS LFN
Configuration 2
MRATS LFN
MRAOS LFN
MRAOS LFN
Configuration 1
Configuration 2
LFN: Local Fixed NodeATS: Air Traffic ServicesAOS: Airline Operations ServicesAO: Airline Operations
Figure 6.6 – Global HAHA usage for ATS and AOS services.
6.6 Home Agent Selection Methods in Global HAHA Networks 75
AO – in Europe
AOS CN-1
ANSP- Europewith access
network
GACSP network
Configuration 2
LFN - CN Communication Path
HA in Europe
MR - CR Tunnel
ANSP- Europewith access
network
ATS CN-1
HA in Europe
GACSP network
ANSP- Europewithout access
network
ATS CN-2
Configuration 1
ATS Configurations AOS Configurations
CRCR
CR
BR
MR: Mobile RouterHA: Home AgentCR: Correspondent RouterLFN: Local Fixed NodeANSP: Air Navigation Service Provider
MR
BR: Border RouterCN: Correspondent NodeATS: Air Traffic ServicesAOS: Airline Operations ServicesAO: Airline Operations
BR
ATS LFN
Configuration 2
MRATS LFN
MRAOSLFN
Configuration 1
MRAOS LFN
Figure 6.7 – CR usage for ATS and AOS services.
6.6 Home Agent Selection Methods in Global HAHA Networks
Considering the analysis of [18], we investigate further global HAHA protocol [85] as a NEMO
RO solution in aeronautical environment and propose end-to-end delay optimizations in this
network. As mentioned above, DHAAD is defined as one way of finding the topologically closest
HA by the MR. However, it only considers the topologically closeness of MR and HA which is
not optimum if we consider end-to-end communication. End-to-end communication delay can
be defined as5;
TTotal−Onewa y = TMNN−MR + TWireless + TBS−AR + TAR−HA + THA−CN (6.1)
In eqn. 6.1:
TMNN−MR: Mobile Network Node to Mobile Router Delay
TWireless: Mobile Router to Base Station Delay
TBS−AR: Base Station to Access Router Delay
TAR−HA: Access Router to Home Agent Delay
THA−CN : Home Agent to Correspondent Node Delay
For time critical applications, it is better to consider new HA selection methods that take into
account not only MR-HA communication path but also HA-CN communication path in order to
minimize end-to-end communication delay.
6.6.1 Scenarios
Considering Fig. 6.8 where MR is attached to an AR in network B and communicating with a
AOS CN in network C, it has the possibility of using one of two HAs in two different networks.
5Here the processing delays are neglected.
6.6 Home Agent Selection Methods in Global HAHA Networks 76
SubnetworkA
Subnetwork B Subnetwork
C
AOS CN
HAin A
HAin C
ARin B
HA - HA TunnelMR - HA Tunnel
MR CN pathCN MR path
AOS CN
HAin A
HAin C
ARin B
HA - HA TunnelMR - HA Tunnel
MR CN path
Scenario 1
Scenario 2
MR
MR
SubnetworkA
Subnetwork B
Subnetwork C
Figure 6.8 – Traffic flows between MR and different HAs.
In this scenario, two different end-to-end delay values via two different HAs are computed
as follows:TTotal−Onewa y−HAA
= TMNN−MR + TWireless + TBS−AR + TAR−HAA+ THAA−CNAOS
(6.2)
TTotal−Onewa y−HAC= TMNN−MR + TWireless + TBS−AR + TAR−HAC
+ THAC−CNAOS(6.3)
Let us assume that:TAR−HAA
< TAR−HAC(6.4)
TTotal−HAA> TTotal−HAC
(6.5)
Under these conditions, HAA will be used by the MR as an outcome of DHAAD procedure
according to eqn. 6.4. However, in this case total end-to-end delay is not minimized according
to eqn. 6.5.
6.6.2 Proposals
In this section, we will consider two different methods; namely static and dynamic, in order to
select an HA that optimizes end-to-end delay. In static method, we are assuming that each HA
has the knowledge of IP addresses of access routers and CNs in the network. Although this may
not be a reasonable assumption for consumer electronics where each MR can connect to large
number of CNs, we believe this could work in aviation scenario considering the limited number
ARs and CNs on the ground. In dynamic method, we do not make any assumption about the
knowledge of ARs and CNs from HA side. HAs perform delay calculations when they receive
binding update with a new mobility option (i.e., Access Router Address Option).
6.6 Home Agent Selection Methods in Global HAHA Networks 77
6.6.2.1 Static Method
In this method, each HA calculates the delay values to each AR and CN in the network (e.g., by
using ping) and creates a delay table. After each HA completes the delay table, it exchanges this
information with other HAs in the network. These exchanges are performed via special HELLO
message defined in inter-HAHA protocol. There are two important points to mention;
- These tables are not very frequently updated since the ground network is quite stable and
topology changes are rare.
- The networking entities (i.e., AR, HA, CN) are limited compared to public Internet so that
the overhead generated due to delay calculation is not very critical.
Fig. 6.9 shows a possible signaling exchange such that HAs first create delay tables and
exchange these tables via HELLO messages. Later on, MR attaches to a network and sends a
DHAAD request. It is responded by the topologically closest HA (i.e., HA-1) and MR performs
home registration with HA-1. When HA-1 receives the first user data from MR, it searches the
optimum HA for the MR by checking the currently attached AR (here AR information is known by
HA via the configured CoA) and the CN addresses from the delay table. If another HA provides
MR HA-2 CN-1HA-1
Network Attachment and DHAAD Procedure
Data Tranmission with CN-1 via HA-1
DHAAD Request
DHAAD Reply
BU
BA
HA Registration with HA-1
LFN
HA Switch MessageHA Switch request
BUBA
HA Registration with HA-2
Data Tranmission with CN – 1 via HA-2
LFN: Local Fixed NodeMR: Mobile RouterHA: Home AgentCN: Correspondent NodeAR: Access RouterBU: Binding UpdateBA: Binding Acknowledgement
Signalling TrafficPayload Traffic
MR - HA Tunnel
AR-1 AR-2 CN-2
HA-1 Delay Table Creation – Ping HA-1
HA-2 Delay Table Creation – Ping HA-2
Inter HAHA – Delay Table ExchangeHELLO
RA
Figure 6.9 – DHAAD procedure with HA switch message - static method.
6.6 Home Agent Selection Methods in Global HAHA Networks 78
a better delay performance, HA-1 sends a HA switch request message [94] to the MR including
the other HA address (e.g., HA-2), and MR performs home registration with it.
6.6.2.2 Dynamic Method
In this method, MR first learns the AR IP address. MR can use two different methods for learning
AR IP address. In the first case, ARs send RA messages with a new option (Access Router Address
Option) and MR checks this option when it receives the RA message (i.e., during the network
attachment) as shown in Fig. 6.10. In the second method, if MR and access network is capable of
using MIH information server services of IEEE 802.21 [31], then MR learns about the attached
AR IP address from information server. In our analysis, we assumed the first method since IEEE
802.21 can not be supported by all attached networks.
After MR learns about AR IP address during network attachment, it performs DHAAD in
order to find the topologically closest HA (i.e., HA-1). Then MR performs HA registration by
sending BU that includes a new mobility option6 carrying the AR IP address. When HA receives
the BU, it stores the AR IP address (with MR HoA, CoA and MNPs) and performs a ping to
AR in order to measure delay. Later on, when it receives the first data packet from any MNN
attached to the MR, it detunnels the packet and forward the traffic to the CN. In parallel, since
HA also learned CN address at that stage (i.e., CN address is the destination address of the
decapsulated user data), it performs a ping to CN and measure the delay. Afterwards, HA passes
delay information (with AR and CN IP addresses) to other HAs and they also measure these
values and exchange with other HAs. These exchanges are also managed by HELLO messages
similar to static method. After these exchanges are completed, the assigned HA checks from the
table whether there is another HA which provides better performance. If the assigned HA finds
a better one, it sends a HA switch message to MR which notifies the candidate HA address and
MR performs home registration with the new HA.
6.6.3 Example Comparison
In this section, we show one example considering realistic delay values for the LDACS1 radio
link and for the ground network (learned via ping application) covering different regions of
the world. The delay values inside the backbone network are taken from the sprint network7.
In addition, we calculated number of hops on the ground network by assuming transmission
and processing delay of 5 ms for each hop. As shown in Fig. 6.11, the aircraft is attaching the
network while flying around middle-east region and communicating with a CN in Asia. In our
configuration, we are assuming two HAs, one in Europe and one in Asia. In a regular situation,
MR sends a DHAAD request and receives a reply from HA in Europe and starts using that HA.
However, according to our proposal, the aircraft will use HA in Asia instead of HA in Europe due
to the smaller end-to-end delay. Table 6.3 shows the corresponding end-to-end delay values
between MR and CN for the two methods assuming that;
6Similar to the alternate CoA Option.7see https://www.sprint.net/lg/lg_start.php.
6.6 Home Agent Selection Methods in Global HAHA Networks 79
MR HA-2 CN-1HA-1
Network Attachment and DHAAD Procedure
Data Tranmission with CN-1 via HA-1
DHAAD RequestDHAAD Reply
BU [AR IP Address Option]BA
HA Registration with HA-1
LFN
HA Switch Message
HA Switch request
BU
BA
HA Registration with HA-2
Data Tranmission with CN-1 via HA-2
LFN: Local Fixed NodeMR: Mobile RouterHA: Home AgentCN: Correspondent NodeBU: Binding UpdateBA: Binding AcknowledgementAR: Access Router
Signalling TrafficPayload TrafficMR - HA Tunnel
HA-1 Delay Table Entry for {HA-1, AR-1, CN-1} – Ping HA-1
Inter HAHA – Delay Table Exchange – HA-2 Delay Table Entry for (HA-1, AR-1, CN-1)
HELLO
HA-2 Delay Table Entry for {HA-2, AR-1, CN-1} – Ping HA-2
Inter HAHA – Delay Table Exchange – HA-1 Delay Table Entry for (HA-2, AR-1, CN-1)
HELLO
AR-1
RA [AR IP Address Option]
Figure 6.10 – DHAAD procedure with HA switch message - dynamic method.
• Transmission and processing delay of 5 ms for each number of hops on the ground network.
• LDACS1 BS and AR are collocated so that no additional delay is incurred between them.
• Channel access delay values of LDACS1 are considered as 35 ms and 95 ms for the FL and
RL, respectively.
• Transmission delay over LDACS1 is considered as 10 ms.
• Transmission delay within the onboard network is ignored since it is negligible compared
to other values.
Our proposal improves the RTT delay by around 40% compared to the regular case when
two topologically separated HAs are used in ground network.
6.6 Home Agent Selection Methods in Global HAHA Networks 80
MR
Access Network in
Middle-East
Backbone in Europe
Backbone in Middle-East
Backbone in Asia
AR
CN
MR CN via HA in EuropeCN MR via HA in Europe
MR CN via HA in Asia
HA in Europe
HA in Asia
LDACS1 BS
Figure 6.11 – Example scenario.
DHAAD Result
Path Delay (msec.)
MR->CN via HA in Europe 365
CN->MR via HA in Europe 335
Round Trip Time 700
Proposed Solution Result
Path Delay (msec.)
MR->CN via HA in Asia 235
CN->MR via HA in Asia 175
Round Trip Time 410
Table 6.3 – DHAAD vs. proposed solution results.
6.6.4 Multiple Home Agent Usage in Global HAHA Networks
In aeronautical communications, the aircraft is communicating with two different correspondent
nodes in general; namely ATS and AOS. Based on the correspondent node type the optimum
HA is different considering the fact that there is not any direct relation between ATS CNs and
AOS CNs. In this case, it is reasonable to consider multiple simultaneous bindings with different
HAs in the global HAHA network.
Scenarios
Considering Fig. 6.12, scenario 1 denotes a regular global HAHA scenario where MR is allowed to
register to only one HA. However in scenario 2, the MR is capable of registering simultaneously
with multiple HAs, thanks to multihoming extensions. In scenario 2, the MR is notified by
the above mentioned procedure about the optimum HAs for different flows. It is also good to
mention that, since we are considering binding to multiple HAs, the HA switch message sent
6.6 Home Agent Selection Methods in Global HAHA Networks 81
from the already registered HA carry not only candidate HA IP address but also FID, so that the
MR knows for which flows the candidate HA will be used.
In this section we focus on scenario 2 and consider two different sub-scenarios which are
aligned with two cases, namely (1,n,1) and (1,n,n) mentioned in [95]. The values inside
parenthesis denotes number of MRs, number of HAs and number of MNPs respectively.
MR
Scenario 1
Scenario 2
MR
Figure 6.12 – Traffic flows with one and multiple HAs.
(1,n,n) Sub-scenario
In this scenario ATS and AOS flows will have different MNPs and make use of different HAs in
the network based on their optimality. Similar to basic NEMO protocol, MR uses only one HoA
for ATS and AOS flows. Here we are also assuming that the aircraft attaches to only one access
network and configure only one CoA that is used for each (HoA, CoA, MNP) 3-tuple. For each
3-tuple, MR performs home registration to the optimum HA.
Similar to Section 6.6.2, MR finds the topologically closest HA by using DHAAD procedure,
sends two binding registrations for two MNPs 8 (i.e., (HoA, CoA, MNP-1), (HoA, CoA, MNP-
2)) to the topologically closest HA. When MR sends the user data for each flow (here flow
differentiation is based on MNP), HA checks whether it is the optimum HA, if not, then it sends
a HA switch message to MR for the corresponding flow. Fig. 6.13 shows an example where
HA-1 is optimum for ATS flows and HA-2 is optimum for AOS flows. After MR sends the binding
registration to HA-1 and HA-2, these HAs exchange binding information with each other by
using BIU message [93] in order to synchronize their binding caches for the corresponding MNP.
8One binding registration can also be used for registering multiple MNPs.
6.6 Home Agent Selection Methods in Global HAHA Networks 82
HoA, CoA
ATS Flows AOS FlowsMNP1, FID1
MNP2, FID2
3-tuple {HoA, CoA, Flow Desc: MNP1 with FID1}
3-tuple {HoA, CoA, Flow Desc: MNP2 with FID2}
HA1 (optimum for ATS Flows)
HA1 Pair1 {HoA, CoA, Flow Desc: MNP1 with FID1}HA2 Pair2 {HoA, CoA, Flow Desc: MNP2 with FID2}
Synchronized HA1/HA2 Binding Cache
HA2 (optimum for AOS flows)
BIU
Figure 6.13 – Binding registration with multiple MNPs.
(1,n,1) Sub-scenario
In this scenario, MR has two different (HoA, CoA, MNP¸ , Port#) 4-tuple, and uses port numbers
for FID [97] where each flow is differentiated with different bindings as shown in Fig. 6.14. The
procedures mentioned in the above section is also valid for this scenario.
HoA, CoA, MNP
ATS Flows AOS Flows
4-tuple {HoA, CoA, MNP, Flow Desc: Port #1 with FID1}
4-tuple {HoA, CoA, MNP, Flow Desc: Port #2 with FID2}
HA1 (optimum for ATS Flows)
Synchronized HA1/HA2 Binding Cache
HA2 (optimum for AOS flows)
Port #1, FID1
Port #2, FID2
HA1 Pair1 {HoA, CoA, MNP,Flow Desc: Port #1 with FID1}HA2 Pair2 {HoA, CoA, MNP, Flow Desc: Port #2 with FID2}
BIU
Figure 6.14 – Binding registration using multiple port numbers as FID.
6.7 Context Transfer in Global HAHA Networks 83
6.7 Context Transfer in Global HAHA Networks
As mentioned in Chapter 1, one of the main focus of this thesis is to reduce signaling overhead
in the wireless link since it is the main bottleneck between communicating end nodes. For
this reason, Context Transfer Protocol (CXTP) is considered in order to minimize the signaling
overhead created due to establishing a new IKEv2/IPsec SA in case the MR switches from one
HA to another one. First, main procedures and signaling overhead of a new IKEv2/IPsec SA
establishment is explained followed by the description of CXTP and new proposal based on CXTP.
Afterwards overhead and delay comparison of the new proposal with the standard method are
provided. Finally, a few additional issues related to the usage of CXTP protocol are discussed.
6.7.1 Internet Key Exchange
In order to secure mobility signaling between a MN and a HA, IPsec is mandated in [23]. IPsec
provides numerous possibilities for confidentiality, data integrity, access control, and data source
authentication. These services are provided by maintaining a shared state between the source
and the sink of IP datagrams. Establishing such a state manually is not only error prone and
tedious, but also not scalable. IKEv2 protocol [99] is used to create this state dynamically which
performs mutual authentication and establishes a SA. A SA offers security services to the traffic
passed through the SA and needs at least two message exchanges for a successful establishment.
The first exchange, IKE_SA_INIT, is responsible for the initialization and negotiates cryptographic
algorithms, exchanges nonces and does a Diffie-Hellman (D-H) exchange. With the D-H exchange
a shared secret key between the source and the sink is established. Based on this secret, keys
for encryption and integrity algorithms are derived. From now on all messages that follow are
encrypted and integrity protected (except the outer header). In the following, the second message
exchange, IKE_AUTH, is performed. This message authenticates the previous communication,
exchanges identities and possibly certificates, and creates an IKE_SA and a first CHILD_SA.
CHILD_SAs are created for IPsec ESP and/or Authentication Header (AH).
In order to approximate the overhead caused by IKEv2/IPsec, an example configuration is
assumed, including the IKEv2 (28 B), UDP (8 B), and IPv6 (40 B) headers. For the IKE_SA_INIT,
the Diffie-Hellman group 2 (144 B), a nonce length of 136 B, a proposal of three encryption
variants (56 B), a single proposal for the pseudo random function (20 B), and a single proposal
for the integrity check (20 B) are assumed. For the IKE_AUTH, a fully qualified domain name
string for identification (30 B), proposals for encryption and integrity (68 B), three proposals for
a traffic selector initiator range (272 B), three proposals for a traffic selector responder range
(272 B), and an authentication signature (100 B) are assumed. Furthermore, AES-CBC 256
(cyclic block cipher, which has a 16 B initialization vector and a 16 B aligned payload length)
and HMAC_SHA_96 (12 B integrity check) were selected from the proposal. For the CHILD_SA,
no new D-H value and one additional proposal for encryption and integrity are assumed. Hence,
the overhead shown in Table 6.4 for the IKEv2 initialization phase is derived.
6.7 Context Transfer in Global HAHA Networks 84
Message Size (Byte)IKE_SA_INIT Request 452
IKE_SA_INIT Response 428IKE_AUTH Request 1648
IKE_AUTH Response 1600Total IKEv2 Exchange 4128
Table 6.4 – IKEv2 overhead.
IPsec Context
The data of interest is stored in the Security Policy Database (SPD) and in the Security Association
Database (SAD) [100]. SPD contains entries (i.e., general policies) which need to be maintained
by the operator of the network. Note that these entries need to be the same in all HAs within the
network. Additionally, SPD contains selector values in order to support SA management. The
selectors used to define the SA must be context transferred [101]. Selector fields are, among
others, source and destination address, source and destination port, transport layer protocol,
etc. Treatment fields such as sequence numbers, sequence overflow flag, antireplay window,
ESP encryption algorithm, etc. are used by the IPsec stack in order to process the incoming
data packets properly. All these fields, necessary for the SA, need to be context transferred.
The second database is the SAD that contains parameters associated with each (active) security
association. Each entry in the SAD is uniquely identified by three parameters: Security Parameter
Index (SPI), destination IP address and ESP/AH mode information. It is of upmost importance
that the context transfer of an IPsec SA is secured (i.e., assuming already established security
tunnels between the previous and the next HA).
6.7.2 Context Transfer Protocol
In this section CXTP protocol [102] is explained for the purpose of IKEv2/IPsec context transfer
between HAs in the global HAHA network. The protocol defines the following messages:
• Context Transfer Activate Request (CTAR): It is sent by the MN to the target HA (i.e.,
next HA) for requesting the context transfer activation. It carries an authorization token
which authorizes the sender (i.e., MR) to request this operation. In order to calculate the
authorization token, the MR and HAs should share a secret key.
• Context Transfer Activate Acknowledge (CTAA): It is sent by the HA to the MR to acknowl-
edge the CTAR message.
• Context Transfer Data (CTD): It is sent by previous HA (abbreviated as “pHA” in the rest of
the chapter) to next HA (abbreviated as “nHA” in the rest of the chapter) that carries the
context data. An acknowledgement flag, ‘A’, included in this message, indicates whether a
reply is required by pHA. This message requires IPsec protection.
6.7 Context Transfer in Global HAHA Networks 85
• Context Transfer Request (CTREQ): This message is sent by nHA to pHA in order to
request the start of context transfer (if needed). This message is sent after CTAR message
is received.
6.7.3 Proposals
In this section, we will provide two different context transfer methods: namely node-initiated
and network-initiated.
6.7.3.1 Node Initiated Proposal
As shown in Fig. 6.15, the MR configures a new CoA from a newly attached network, and performs
a binding registration with the pHA. In the BU message, the K bit is set (Key Management Mobility
Capability) in order to move the SA to the new CoA [11]. In parallel, MR starts the DHAAD
procedure in order to know whether there is another, topologically closer HA. In case the MR
receives a DHAAD response from another HA (i.e., nHA), it initiates context transfer operations
by sending a CTAR message to the nHA. This CTAR message is used to trigger the context transfer
from the pHA to the nHA. When nHA receives the CTAR, it checks two address fields which are
pHA address and MR HoA. Afterwards, it requests the corresponding context and the binding
information from pHA via CTREQ and Binding Information Request messages, respectively. pHA
responds with two messages: CTD message which includes the context and BIU message which
includes corresponding MNP information. When context transfer is completed, nHA sends a BIU
to other HAs in order to inform them about the newly established binding information and a
CTAA message to MR. When MR receives CTAA, it starts MOBIKE SA address update procedure
in order to change the HA address information (from pHA to nHA) inside the SPD entry.
6.7.3.2 Network Initiated Proposal
As shown in Fig. 6.16, MR performs a layer 3 handover and sends a BU to the pHA. Similar to
the node initiated proposal, K bit is set for moving the SA. Since we are assuming that the nHA
is topologically closer to the MR, the nHA will intercept the BU and tunnel it to the pHA via
HAHA tunnel. When pHA receives the encapsulated packet, it checks source address of the outer
header (i.e., nHA IP address), and realizes that the packet is coming from another HA. In that
case, pHA sends a home agent switch message to the MR including nHA address inside it. In
parallel, pHA sends the context to nHA via CTD message. When the MR receives the HA switch
message, it sends a CTAR message to nHA in order to activate the context. Since nHA already
received the CTD message, it does not send a CTREQ message and it immediately responds with
CTAA message to acknowledge the CTAR message. In parallel, nHA sends BIU to other HAs in
order to update the binding information. Finally, MR performs a MOBIKE SA Address update in
order to update the SPD entry related to HA information.
6.7 Context Transfer in Global HAHA Networks 86
Mobile Router (MR)
Previous HA (pHA)
Next HA (nHA)
DHAAD Request
CTAA
Perform DHAAD with the nCoA
MN decides on nHA
Existing MR-HA Tunnel(pCoA, HoA, pHA)
Layer 3 Handover ( new CoA)
DHAAD Response
CTAR (IPsec)
CTD (SPD+SAD+PAD)
transferred MR-HA Tunnel (nCoA, HoA, pHA)
Start Context Transfer
MOBIKE SA Address Update
SA Address Update Response (nHA nCoA)SA Address Update Request (nCoA nHA)
update MR-HA Tunnel (nCoA, HoA, nHA)
Network Attachment and HA Registration
Binding AcknowledgementBinding Update [K bit is set]
CT-REQ(IPsec)
Existing MR-HA Tunnel(nCoA, HoA, pHA)
Binding Information Request
Binding Information Update
Figure 6.15 – Node initiated context transfer.
6.7.4 Overhead and Delay Comparisons
In order to approximate the overhead caused by context transfer, an example configuration is
assumed, including the UDP (8 B), and IPv6 (40 B) headers. As can be seen from Table 6.5,
context transfer overhead on the wireless link is negligible compared to the new IKEv2/IPsec SA
establishment shown in Table 6.3. In the next step, total capacity gain of the proposed scheme is
investigated considering a European air traffic simulation scenario mentioned in Section 3.3.4.
We consider two different cell sizes (i.e., 150 km and 200 km) and assume that each aircraft
entering the cell performs HA switching with one of the two methods mentioned above. Table 6.6
shows the overhead comparison of the new SA establishment and proposed context transfer
procedure considering forward and return link capacities of LDACS1. While the overhead due
to context transfer is around a few 100 bit/s level, it is approaching to a few kbit/s range for the
new SA establishment case.
Message Size (Byte)CTAR Message to nHA 92CTAA Message to MR 72
SA Address Update Request 124SA Address Update Response 124
Total Exchange 412
Table 6.5 – Context transfer overhead.
6.7 Context Transfer in Global HAHA Networks 87
Mobile Router (MR)
Previous HA (pHA)
Next HA (nHA)
CTAA
HA Switch with Context Transfer
Existing MR-HA Tunnel(pCoA, HoA, pHA)
HA Switch Request CTD (SPD+SAD+PAD)
CTAR (IPsec)
transferred MR-HA Tunnel (nCoA, HoA, pHA)
MOBIKE SA Address Update
SA Address Update Response (nHA nCoA)SA Address Update Request (nCoA nHA)
update MR-HA Tunnel (nCoA, HoA, nHA)
Layer 3 Handover ( new CoA) Network Attachment and
Home Registration
Binding AcknowledgementBinding Update [K bit is set]
MR switches to nHA
Existing MR-HA Tunnel(nCoA, HoA, pHA)
Binding Information Update
Figure 6.16 – Network initiated context transfer.
Cell Radius Cell Radius150 km 200 km
PIAC 380 520
Capacity Forward Link (Kbps) 291 291Overhead due to SA establishment(Kbps) 1.72 2.36
Ratio of Overhead to Capacity in % 0.6 0.8Overhead due to Context Transfer(Kbps) 0.17 0.23
Ratio of Overhead to Capacity in % 0.06 0.08
Capacity Return Link (Kbps) 220.3 220.3Overhead due to SA establishment(Kbps) 1.79 2.45
Ratio of Overhead to Capacity in % 0.81 1.11Overhead due to Context Transfer(Kbps) 0.18 0.25
Ratio of Overhead to Capacity in % 0.08 0.11
Table 6.6 – Overhead comparison depending on PIAC and link capacity.
Considering delay analysis, both approaches (i.e., node and network initiated) require two
RTT: one RTT for context transfer exchange and one RTT for MOBIKE SA address update which
is the same as the new IKEv2/IPsec SA establishment.
6.7.5 Further Discussions
In this section, we discuss three different issues related to the usage of CXTP. These issues
are the SPI collision problem, authorization token generation and the number of home agent
switches in a global HAHA network.
6.7 Context Transfer in Global HAHA Networks 88
6.7.5.1 SPI Collision Problem
In order to transfer the IKEv2/IPsec context from pHA to nHA, it is necessary to examine all
the states concerning the current SA. For each IKEv2 SA, initiator (i.e., mobile node) and
responder (i.e., home agent) have a unique SPI used for mapping between SPI and IKEv2 SA.
The authors of [103] identified a SPI collision problem for IKEv2 SAs which occurs in case the
SA is transferred to a target access router which already uses the same SPIs for another user
(i.e., mobile node). In our case, SPI collisions might occur when the context is transferred from
pHA to nHA such that nHA is already using the same SPIs for another mobile node. For this
reason, two approaches could be thought in order to prevent SPI collision. The first approach
is to use a new notification message by extending notify IKEv2 payload. In this case, when
the responder receives a IKE_INIT_SA request, it checks the uniqueness of the SPIs with other
HAs via “HELLO” message (with a new option in order to carry SPI) defined by inter-HAHA
protocol [104]. In case SPI is unique, then it sends the IKE_INIT_SA response as normal. In case
the SPI is not unique, then the responder sends an informational message which includes a notify
payload with a new CHANGE_IKE_SPI notification message. Upon reception of this message, the
initiator sends another IKE_INIT_SA request with a new SPI value. This procedure will continue
until a unique SPI is found. In aeronautical domain, considering the limited number of mobile
nodes, the probability of proposing a non-unique 64-bit length SPI is quite low. In addition,
since this process is done at the initial stage of the communication, once unique SPI is assigned,
HA context transfer will not be affected negatively in terms of additional signaling overhead
and delay. In the second approach, initiator (mobile node) sends the IKE_INIT_SA request with
randomly generated SPI value as in normal case. When responder (HA) receives this request, it
checks the uniqueness of the SPI like the first approach. In case the SPI is unique, then it sends
the IKE_INIT_SA response as normal. In case initiator SPI is not unique, HA will not send the
IKE_INIT_SA response and let the initiator goes to timeout. When initiator retransmission timer
timeout, it sends another request with a new SPI value and HA will check its uniqueness with
other HAs again. This will continue until a unique SPI is found for the initiator. Similar to the
first approach, this option will not affect HA context transfer performance negatively since it is
performed at the initial stage of the communication.
6.7.5.2 Authorization Token Generation
As mentioned in [102], CTAR message requires MN and HA to have a shared secret key to
generate the authorization token. In our scenario, we assume that the currently registered HA
generates the shared secret and sends it to the MR inside binding acknowledgement message
as an option9. It is also good to mention that the binding registration is IPsec protected, hence
the shared secret key can be transferred safely. In addition, during the context transfer, the
pHA transfers the shared secret to nHA inside CTD message, so that the nHA can generate the
authorization token as well.9Similar to binding authorization data option in [11].
6.7 Context Transfer in Global HAHA Networks 89
6.7.5.3 Number of Home Agent Switches
In a global HAHA network, one question is how many times a mobile node perform HA switch
while it is on the move. In aeronautical environment, if we assume each ICAO region has its
own HA which means there will be 22 HAs deployed around the world. Among those 22, there
will be 2 HAs in Europe; one in Northern Europe and one in Southern Europe. In this case,
continental flight aircraft in Europe will have, at most, only one HA switching. On the other
hand, another assumption would be to distribute HAs considering air traffic data volume. Then
it is probably reasonable to consider more than 2 HAs in Europe, since it is one of the densest
air traffic regions in the world. In this case, depending on the location and the number of HAs
deployed, continental flight aircraft in Europe might experience more than one HA switching.
6.8 Conclusion
In this chapter, we first classified different NEMO RO techniques and focused on infrastructure
based methods, namely global HAHA and CR protocols. Afterwards, we analyzed these protocols
from ATN/IPS perspective and required modifications are identified in order to use them in the
network. We also provided possible configuration scenarios for these protocols in the ATN/IPS.
In the last section, two new approaches for the global HAHA protocol were proposed. The
first approach was about a new HA selection mechanism that provides 40% better RTT delay
compared to the DHAAD approach assuming two topologically separated HAs in the ground
network. The second approach proposed to use CXTP protocol for carrying the security context
from old HA to the new one instead of establishing a new IKEv2/IPsec SA with the new HA.
With our proposal the signaling overhead is reduced to a few 100 bit/s level from a few kbit/sfor a densely populated LDACS1 BS.
Chapter 7
Conclusions
The aviation community is currently working on the standardization of data communication
systems for the future air traffic management that is needed in order to handle the data traffic
demands of 2020 and beyond time frame. The standardization effort has two main streams,
namely, standardization of future radio access technologies and standardization of a future IPv6-
based ATN/IPS. In this thesis, different handover and radio resource management algorithms
were analyzed for the LDACS1 with realistic IPv6-based network layer functionality.
In the first part of this work, handover performance of NEMO was investigated and different
cross-layer approaches based on IEEE 802.21 standard were proposed in order to improve
handover latency and signaling overhead. With our proposals, total handover latency (i.e., layer
2 and layer 3) is reduced to around 0.4 s from around 3 s and signaling overhead due to router
advertisement messages is reduced to around 0.1 kbit/s from around 17 kbit/s.In the second part, the effect of handover event on TCP performance was analyzed. In the first
step, different TCP handover optimizations related to Mobile IPv6 protocol are presented. In the
second step, home agent buffering method for improving TCP performance during inter-access
network handovers is analyzed in detail. With our proposal, total transmission completion
time of a TCP session is reduced by at least 10% for a download of 110 kB of information. One
future work item can be to study the performance of HA-buffering on TCP in case the aircraft
performs handover between BSs which provide different bandwidth allocations to the aircraft
(i.e., handover from low bandwidth to high bandwidth data link or vice versa). In this case, it is
important to set the TCP window size dynamically as proposed by [70,71]. Another interesting
work could be to investigate the performance gain of HA-buffering with different TCP options like
selective acknowledgment option [35], timestamps option [105] and some other TCP variants.
In the third part, three different RRM algorithms were analyzed in terms of bandwidth and
end-to-end delay fairness for the LDACS1. Our conclusion was that modified DRR algorithm
which is used for both links (i.e., forward and return link) provides almost perfect fairness (with
limited fragmentation overhead) among different number of users based on Jain’s fairness index
considering ideal wireless channel conditions. We also recognized the need for a new bandwidth
request mechanism in the RL for the VoIP service and input to the LDACS1 specification update
which is currently developed within Single European Sky ATM Research (SESAR) project [106].
90
7 Conclusions 91
The new design will let the aircraft request permanent allocations in the RL. Additionally,
we noticed the overhead problem in the VoIP case, where the overhead reaches around 65 %
and recognized the need of an effective header compression techniques in LDACS1 in order
to decrease the higher layer overhead. Another interesting topic would be to analyze the
performance of DRR under lossy channel conditions with different packet types (i.e., real-time
and non real-time) in one DLS queue.
In the last part, different NEMO RO techniques were analyzed due to triangular routing
problem of NEMO. With the help of NEMO RO, end-to-end delay and path length (in terms
of number of hops) between communicating end nodes are reduced. In the first part, infra-
structure based NEMO RO techniques; namely global HAHA and CR protocols were analyzed
from ATN/IPS perspective and required modifications are identified in order to use them in
the network. Later on, two new approaches for the global HAHA protocol were proposed. The
first approach proposed a new HA selection mechanism that provides 40% better RTT delay
compared to the DHAAD approach assuming two topologically separated HAs are used in ground
network. The second approach proposed to use CXTP protocol instead of new IKEv2/IPsec SA
establishment and signaling overhead is reduced from a few kbit/s range to a few 100 bit/s level
in a densely populated LDACS1 BS. One remaining activity in this part is the evaluation of these
conceptual design works in terms of either simulation or test-bed implementations.
Appendix A
Mobile IPv6 Overhead Analysis
In MIPv6, there are three main procedures [11] that are summarized as follows:
• Home Agent Registration
• Return Routability (RR) Procedure
• Correspondent Node (CN) Registration
Home registration is needed in order to inform the home agent about the current point of
network attachment. Once it is completed, MN and CN can start communication via HA. In
order to have a direct communication between MN and CN, RR procedure and CN registration
should be completed. All messages in each procedure are carried in IPv6 header with 40 byte of
size. Reference [11] provides mobility related signaling types as shown in Table A.1.
Message Type Size (Byte)
Mobility Header 6Binding Update 6HoA Option 20Binding Acknowledgement 6Home Test Init 10Care-of Test Init 10Home Test 18Care-of Test 18Binding Authorization Data 14Nonce Indices 6
Table A.1 – Mobility Related Signaling Types.
Table A.2 provides overall overhead values without IPsec considerations. Here, RR procedure
and CN registration must be repeated by the MN every 7 minutes at the latest due to the maximum
lifetime (MAX_RR_BINDING_LIFETIME = 420 s in [11]) of the binding between MN and CN.
The signaling overhead can be reduced by considering enhanced RO mechanism [107]. This
mechanism uses cryptographically generated address as home address which provides a strong
92
A Mobile IPv6 Overhead Analysis 93
Modes of Message IPv6 HoA Mobility Total w/oOperation Type Header Option Headers IPsec (Bytes)
Home Binding Update 40 20 6+6 72Registration Binding Acknowledgement 40 0 6+6 52
Total 124
Return Home Test Init 40+40 0 6+10 96Routability Care-of Test Init 40 0 6+10 56
Home Test 40+40 0 6+18 104Care-of Test 40 0 6+18 64
CN Binding Update to CN 40 20 6+6+14+6 92Registration Binding Ack. from CN 40 0 6+6+14+2 68
Total 480 bytesper 7 minutes
Table A.2 – MIPv6 procedures and signaling overhead.
cryptographic binding between the interface identifier of the home address and its public key.
With this approach, the binding lifetime at the CN is increased to 24 hours instead of 7 minutes,
so that the signaling overhead reduces significantly.
Appendix B
LDACS1 Physical Layer Configurations
The first release of LDACS1 specification considers the physical layer processing for the RL such
that each physical layer PDU (carrying 14 B length of information data with lowest modulation
and coding) is coded and interleaved separately. One example configuration is shown in Fig. B.1a
for Reed-Solomon coding of (16,14,1). In this figure, higher layer packet (i.e., DLS service
datagram unit (SDU)) of size 77 B is inserted into a DLS PDU with LDACS1 header and a frame
check sequence (FCS) field. Then it is divided into multiple DLS physical layer PDUs and each
physical layer PDU is coded and modulated separately. With this configuration high PER values
in the RL were noticed when the mobile sends a message with multiple physical layer PDUs
in a multiframe. Recently, an update of the LDACS1 specification has been developed within
the SESAR project P15.2.4 [106], which deals among others with the LDACS development. In
the updated specification, coding and interleaving is performed jointly up to the maximum
Reed-Solomon codeword length (i.e., 255 B) for all physical layer PDUs transmitted within one
multiframe by an aircraft. One example configuration is shown in Fig. B.1b for Reed-Solomon
coding of (98,84,7) for 6 physical layer PDUs. In this figure, same as in the first release, higher
layer packet (i.e., DLS service datagram unit (SDU)) of size 77 B is inserted into a DLS PDU
with LDACS1 header and a frame check sequence (FCS) field. Afterwards, the DLS PDU is
jointly coded and modulated instead of being divided into smaller segments. With this new
configuration, due to joint coding, LDACS1 provides more robust error correction capability
with significantly reduced PER in the RL. Fig. B.2 shows the FER of the new RL physical layer
design compared to the old one.
94
B LDACS1 Physical Layer Configurations 95
DLS SDU (Higher Layer Packet) = 77 byte
Fragment 1 = 77 byte
1 Phy-PDU – 14 byte
LDACS1 Header –
5 byte
DLS PDU 1
FCS –2 byte
1 Phy-PDU – 14 byte
1 Phy-PDU – 14 byte
Phy PDU 1 Phy PDU 2 Phy PDU 6
RS(16,14,1) RS(16,14,1) RS(16,14,1)
Conv Coding (1/2)
Conv Coding (1/2)
Conv Coding (1/2)
Interleaving Interleaving Interleaving
(a) LDACS1 RL user data processing -release 1.0.
Fragment 1 = 77 byte
LDACS1 Header – 5 byte
DLS PDU 1
FCS –2 byte
DLS SDU (Higher Layer Packet) = 77 byte
1 Phy-PDU –14 byte
1 Phy-PDU – 14 byte
1 Phy-PDU –14 byte
Phy PDU 1 Phy PDU 2 Phy PDU 6
RS(98,84,7)
Conv Coding (1/2)
Interleaving
(b) LDACS1 RL user data processing -release 1.1.
Figure B.1 – LDACS1 RL user data processing at the mobile side.
2 4 6 8 1010
-6
10-5
10-4
10-3
10-2
10-1
100
SNR [dB]
FE
R
Old Coding, FER, RL, Frame Size = 14 ByteNew Coding, FER, RL, Frame Size = 84 Byte
Figure B.2 – Frame error rates versus SNR for LDACS1 transmission in the RL.
List of Acronyms
ACSP Air/Ground Communications Service Provider
AH Authentication Header
ANSP Air Navigation Service Provider
AO Airline Operation
APT Airport
AR Access Router
ARQ Automatic Repeat Request
ATM Air Traffic Management
ATN Aeronautical Telecommunications Network
ATN/IPS Aeronautical Telecommunications Network using Internet Protocol Suite
ATS Air Traffic Service
AOS Airline Operations Service
B-AMC Broadband-Aeronautical Multi-Carrier Communications
BA Binding Acknowledgment
BCCH Broadcast Channel
BDP Bandwidth Delay Product
BER Bit Error Rate
BIA Binding Information Acknowledgment
BID Binding Identification
BIR Binding Information Request
96
List of Acronyms 97
BIU Binding Information Update
BS Base Station
BU Binding Update
CCCH Common Control Channel
CN Correspondent Node
CoA Care-of Address
COCR Communication Operating Concept Requirements
CoS Class of Service
COTRAC Common Trajectory Coordination
CR Correspondent Router
CTAA Context Transfer Activate Acknowledge
CTAR Context Transfer Activate Request
CTD Context Transfer Data
CTREQ Context Transfer Request
cwnd congestion window
CXTP Context Transfer Protocol
D-H Diffie-Hellman
DAD Duplicate Address Detection
DC Deficit Counter
DCCH Dedicated Control Channel
DHAAD Dynamic Home Agent Address Discovery
DLS Data Link Service
DRR Deficit Round Robin
EGP Exterior Gateway Protocol
ENR En-Route
ESP Encapsulating Security Payload
EUI-64 64-bit extended unique identifier
List of Acronyms 98
FBack Fast Binding Acknowledgment
FBU Fast Binding Update
FCI Future Communications Infrastructure
FDD Frequency Division Duplex
FER Frame Error Rate
FID Flow Identifier
FIFO First-In-First-Out
FL Forward Link
FMIPv6 Fast Mobile IPv6
FSS Fair-Share Scheduling
HA Home Agent
HAck Handover Acknowledge
HAHA Home Agent to Home Agent
HI Handover Initiate
HNP Home Network Prefix
HoA Home Address
ICAO International Civil Aviation Organization
ICMPv6 Internet Control Message Protocol for the IPv6
IDRP Inter Domain Routing Protocol
IETF Internet Engineering Task Force
IKEv2 Internet Key Exchange version 2
ISO International Organization for Standardization
ITU International Telecommunication Union
LDACS L-Band Digital Aeronautical Communications System
LDACS1 L-Band Digital Aeronautical Communications System Option 1
LDACS2 L-Band Digital Aeronautical Communications System Option 2
LFN Local Fixed Node
List of Acronyms 99
LME Link Management Entity
LMN Local Mobile Node
MAC Medium Access Control
MBA Modified Binding Acknowledgement
MBU Modified Binding Update
MF multiframe
MIPv4 Mobile IPv4
MIPv6 Mobile IPv6
MLD Multicast Listener Discovery
MIH Media Independent Handover
MIHF Media Independent Handover Function
MN Mobile Node
MNN Mobile Network Node
MNP Mobile Network Prefix
MR Mobile Router
MSS Maximum Segment Size
NA Neighbor Advertisement
NAR Next Access Router
nCoA new CoA
NM Nautical Mile
NS Neighbor Solicitation
NEMO Network Mobility
OFDM Orthogonal Frequency-Division Multiplexing
OFDMA Orthogonal Frequency-Division Multiple-Access
ORP Oceanic, Remote, Polar
OSI Open Systems Interconnection
PAR Previous Access Router
List of Acronyms 100
PBU Predictive Binding Update
PDU Protocol Datagram Unit
PER Packet Error Rate
PIAC Peak Instantaneous Aircraft Count
PKI Public Key Infrastructure
RA Router Advertisement
RACH Random Access Channel
RANDUS Randomized User Selection
RAT Radio Access Technology
RL Return Link
RO route optimization
RR Return Routability
RRM Radio Resource Management
RS Router Solicitation
RTO retransmission timeout
RtRtAdv Proxy Router Advertisement
RtSolPr Router Solicitation for Proxy Advertisement
RTT round-trip time
RTTVAR round-trip time variation
rwnd receiver window size
SA security association
SAD Security Association Database
SAP Service Access Point
SARPS Standards and Recommended Practices
SESAR Single European Sky ATM Research
SNDCF Sub Network Dependent Convergence Function
SNR Signal to Noise Ratio
List of Acronyms 101
SPD Security Policy Database
SPI Security Parameter Index
SRTT smoothed round-trip time
ssthresh slow start threshold
TCP Transmission Control Protocol
TDD Time-Division Duplex
TDMA Time-Division Multiple-Access
TMA Terminal Manoeuvring Area
VDLm2 VHF Data Link Mode 2
VoIP Voice over IP
WXGRAPH Graphical Weather Information
List of Figures
1.1 Phase 1 and Phase 2 concept evolution over time [1]. . . . . . . . . . . . . . . . . . 2
1.2 Future communications infrastructure [1]. . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 ATN/IPS protocol architecture [9]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 LDACS2 frame structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 LDACS1 frame structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 LDACS1 resource allocation structure. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 MIPv6 operation without route optimization. . . . . . . . . . . . . . . . . . . . . . . 15
2.5 MIPv6 operation with route optimization. . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 MIH services and their interaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7 MIH_NET_SAP service interaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 Mobile node compound module in OMNeT++. . . . . . . . . . . . . . . . . . . . . . 22
2.9 Module representations in OMNeT++. . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Airspace organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Example topology for the European scenario. . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Delay density for Layer 2 and 3 handover with and without ARQ and for two
different BER scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Handover delay comparison: unsolicited RA vs. proposals 1 and proposal 2. . . . 30
3.5 Usage of realistic flight data for analysis. . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 Overhead analysis with realistic flight data. . . . . . . . . . . . . . . . . . . . . . . . 32
3.7 Creating modified EUI-64 format interface identifier. . . . . . . . . . . . . . . . . . 33
3.8 Handover delay comparison: proposal 1 vs. proposal 2 vs. proposal 3. . . . . . . 33
3.9 Handover delay comparison: baseline vs. proposal 4. . . . . . . . . . . . . . . . . . 34
4.1 FMIPv6 - predictive handover scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 FMIPv6 - reactive handover scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 HA bi-casting scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 LDACS1 handover scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5 Error rates versus SNR for LDACS1 transmission. . . . . . . . . . . . . . . . . . . . 41
4.6 RTT analysis with different advertised window sizes and LDACS1 data rates during
110 kB file transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
102
List of Figures 103
4.7 TCP RTO analysis with different maximum window sizes (file transfer of 110 kB,
data rate per user of 31.5 kbit/s, MSS of 1024 B. . . . . . . . . . . . . . . . . . . . . 45
4.8 TCP Reno transmission completion time. . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.9 Received TCP sequence number. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.10 TCP NewReno transmission completion time. . . . . . . . . . . . . . . . . . . . . . . 47
5.1 LDACS1 link scheduling architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 DRR-average throughput per user on the forward link. . . . . . . . . . . . . . . . . 59
5.3 DRR-number of transmitted packets on the forward link (full & fragment). . . . 60
5.4 FSS-average throughput per user on the forward link. . . . . . . . . . . . . . . . . 61
5.5 FSS-number of transmitted packets on the forward link (only fragment). . . . . . 61
5.6 RANDUS-average throughput per user on the forward link. . . . . . . . . . . . . . 62
5.7 RANDUS-number of transmitted packets on the forward link (full & fragment). . 63
5.8 Application level VoIP aggregation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.9 Forward and return link one-way end-to-end delay. . . . . . . . . . . . . . . . . . . 64
5.10 Forward and return link one-way end-to-end delay. . . . . . . . . . . . . . . . . . . 65
6.1 Global HAHA network architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2 Inter - HAHA operation - 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.3 Inter - HAHA operation - 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.4 Correspondent router configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.5 Correspondent router operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.6 Global HAHA usage for ATS and AOS services. . . . . . . . . . . . . . . . . . . . . . 74
6.7 CR usage for ATS and AOS services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.8 Traffic flows between MR and different HAs. . . . . . . . . . . . . . . . . . . . . . . 76
6.9 DHAAD procedure with HA switch message - static method. . . . . . . . . . . . . . 77
6.10 DHAAD procedure with HA switch message - dynamic method. . . . . . . . . . . . 79
6.11 Example scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.12 Traffic flows with one and multiple HAs. . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.13 Binding registration with multiple MNPs. . . . . . . . . . . . . . . . . . . . . . . . . 82
6.14 Binding registration using multiple port numbers as FID. . . . . . . . . . . . . . . . 82
6.15 Node initiated context transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.16 Network initiated context transfer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
B.1 LDACS1 RL user data processing at the mobile side. . . . . . . . . . . . . . . . . . . 95
B.2 Frame error rates versus SNR for LDACS1 transmission in the RL. . . . . . . . . . 95
List of Tables
1.1 Airspace domain definitions [1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Airspace domains with selected technologies. . . . . . . . . . . . . . . . . . . . . . . 6
2.1 LDACS1 message types and corresponding abbreviations. . . . . . . . . . . . . . . 11
2.2 MIPv6 RO signaling overhead depend on different PIAC values. . . . . . . . . . . 16
2.3 Neighbor discovery functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Layer 3 parameters related to handover. . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Average handover delay values for layers 2 and 3. . . . . . . . . . . . . . . . . . . . 28
3.3 Overhead comparison of different approaches. . . . . . . . . . . . . . . . . . . . . . 32
4.1 FMIPv6 specific message formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Layer 3 TCP optimizations during handover. . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Values of LDACS1 transmission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Link budget for LDACS1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5 RTT and overhead for different MSS values for a 31.5 kbit/s link. . . . . . . . . . 42
4.6 TCP Reno parameters used in our simulations. . . . . . . . . . . . . . . . . . . . . . 45
4.7 TCP NewReno parameters used in our simulations. . . . . . . . . . . . . . . . . . . 47
5.1 TCP Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 DRR-fairness indexes for different number of users. . . . . . . . . . . . . . . . . . . 59
5.3 FSS-fairness indexes for different number of users. . . . . . . . . . . . . . . . . . . 60
5.4 RANDUS-fairness indexes for different number of users. . . . . . . . . . . . . . . . 61
5.5 Number of VoIP Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.1 NEMO RO analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2 NEMO RO new functionalities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.3 DHAAD vs. proposed solution results. . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.4 IKEv2 overhead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.5 Context transfer overhead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.6 Overhead comparison depending on PIAC and link capacity. . . . . . . . . . . . . . 87
A.1 Mobility Related Signaling Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
A.2 MIPv6 procedures and signaling overhead. . . . . . . . . . . . . . . . . . . . . . . . 93
104
Bibliography
[1] “Communications Operating Concepts and Requirements for the Future Radio System,”
Eurocontrol/FAA, Tech. Rep., May 2007.
[2] “Future Communications Infrastructure - Step 2 Technology Assessment Results,” Euro-
control/FAA, Tech. Rep., October 2007.
[3] “Action Plan 17 - Final Conclusions and Recommendations Report,” Eurocontrol/FAA,
Tech. Rep., November 2007.
[4] “EUROCONTROL Long-Term Forecast: IFR Flight Movements 2010-2030,” Eurocontrol,
Tech. Rep. 10/11/22-134, December 2010.
[5] W. M. Eddy, W. Ivancic, and T. Davis, “NEMO Route Optimization Requirements for
Operational Use in Aeronautics and Space Exploration Mobile Networks,” IETF, RFC 5522,
October 2009.
[6] W. Kampichler and D. Eier, “Satellite based voice communication for air traffic manage-
ment and airline operation,” in Integrated Communications, Navigation and SurveilanceConference (ICNS), 2011, may 2011, pp. B6–1 –B6–10.
[7] “Off-Board Communications for Vehicle Health Management,” ICAO, Tech. Rep. ACP-
WGF21/WP-23, December 2009.
[8] “Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN),”
ICAO, Tech. Rep. ICAO DOC 9705/AN956, October 2001.
[9] “Manual for the ATN using IPS Standards and Protocols,” ICAO, Tech. Rep. Doc 9896-
AN/469, 2009.
[10] T. Ernst and H.-Y. Lach, “Network Mobility Support Terminology,” IETF, RFC 4885, July
2007.
[11] C. E. Perkins, D. B. Johnson, and J. Arkko, “Mobility Support in IPv6,” IETF, RFC 6275,
July 2011.
[12] S. Ayaz, F. Hoffmann, C. Sommer, R. German, and F. Dressler, “Performance Evalua-
tion of Network Mobility Handover over Future Aeronautical Data Link,” in IEEE GlobalTelecommunications Conference (GLOBECOM 2010). Miami, FL: IEEE, December 2010.
105
Bibliography 106
[13] C. Bauer and S. Ayaz, “A Thorough Investigation of Mobile IPv6 for the Aeronautical
Environment,” in 68th IEEE Vehicular Technology Conference (VTC2008-Fall). Calgary,
BC, Canada: IEEE, September 2008, pp. 1–5.
[14] S. Ayaz, F. Hoffmann, U. Epple, R. German, and F. Dressler, “Performance Evaluation
of Network Mobility Handover over Future Aeronautical Data Link,” ComputerCommunications, vol. 35, no. 3, pp. 334 – 343, 2012. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S014036641100329X
[15] S. Ayaz, F. Hoffmann, R. German, and F. Dressler, “Analysis of Deficit Round Robin
Scheduling for Future Aeronautical Data Link,” in 22nd IEEE International Symposium onPersonal, Indoor and Mobile Radio Communications (PIMRC 2011). Toronto, Canada:
IEEE, September 2011.
[16] S. Ayaz, C. Bauer, and E. Max, “Applying IKE/IPsec Context Transfer to Aeronautical
Networks,” in Mobiwac 2009. Teneriffe, Spain: ACM, October 2009.
[17] S. Ayaz, C. Bauer, and A. Fabrice, “Minimizing End-to-End Delay in Global HAHA Networks
Considering Aeronautical Scenarios,” in Mobiwac 2009. Teneriffe, Spain: ACM, October
2009.
[18] S. Ayaz, C. Bauer, W. Eddy, and F. Arnal, “NEMO route optimization solution space analysis
and evaluation criteria for aviation,” in ITS Telecommunications, 2008. ITST 2008. 8thInternational Conference on, October 2008, pp. 139 –145.
[19] S. Ayaz, C. Bauer, M. Ehammer, T. Gräupl, and F. Arnal, “Mobility Options in the IP-
based Aeronautical Telecommunication Network,” in ICT MobileSummit 2008, Stockholm,
Sweden, June 2008.
[20] “L-DACS1 System Definition Proposal: Deliverable D2,” Eurocontrol, Tech. Rep., February
2009.
[21] “L-DACS2 System Definition Proposal: Deliverable D2,” Eurocontrol, Tech. Rep., May
2009.
[22] N. Zelkin and S. Henriksen, “L-Band Digital Aeronautical Communications System Engi-
neering, Concepts of Use, Systems Performance, Requirements, and Architecture,” NASA,
Tech. Rep. CR 2010 216326, September 2010.
[23] V. Devarapalli and F. Dupont, “Mobile IPv6 Operation with IKEv2 and the Revised IPsec
Architecture,” IETF, RFC 4877, April 2007.
[24] P. Nikander, J. Arkko, T. Aura, G. Montenegro, and E. Nordmark, “Mobile IP Version 6
Route Optimization Security Design Background,” IETF, RFC 4225, December 2005.
[25] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert, “Network Mobility (NEMO)
Basic Support Protocol,” IETF, RFC 3963, January 2005.
Bibliography 107
[26] T. Narten, E. Nordmark, W. A. Simpson, and H. Soliman, “Neighbor Discovery for IP
version 6 (IPv6),” IETF, RFC 4861, September 2007.
[27] S. Thomson, T. Narten, and T. Jinmei, “IPv6 Stateless Address Autoconfiguration,” IETF,
RFC 4862, September 2007.
[28] R. Vida and L. H. M. K. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,”
IETF, RFC 3810, June 2004.
[29] C. Vogt and M. Zitterbart, “Efficient and scalable, end-to-end mobility support for reactive
and proactive handoffs in IPv6,” Communications Magazine, IEEE, vol. 44, no. 6, pp. 74
–82, june 2006.
[30] J. Korhonen, “IP Mobility in Wireless Operator Networks,” University of Helsinki, PhD
Thesis A-2008-4, November 2008.
[31] “Standard for Local and Metropolitan Area Networks: Media Independent Handover
Services,” IEEE, IEEE Standard 802.21, 2008.
[32] J. Postel, “Transmission Control Protocol,” IETF, RFC 793, September 1981.
[33] M. Allman, V. Paxson, and E. Blanton, “TCP Congestion Control,” IETF, RFC 5681, Septem-
ber 2009.
[34] S. Floyd, T. Henderson, and A. Gurtov, “The NewReno Modification to TCP’s Fast Recovery
Algorithm,” IETF, RFC 3782, April 2004.
[35] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, “TCP Selective Acknowledgment
Options,” IETF, RFC 2018, October 1996.
[36] M. Allman, V. Paxson, and W. R. Stevens, “TCP Congestion Control,” IETF, RFC 2581,
April 1999.
[37] A. Varga, “The OMNeT++ Discrete Event Simulation System,” in European SimulationMulticonference (ESM 2001), Prague, Czech Republic, June 2001.
[38] J. Lai, Y. A. Sekercioglu, N. Jordan, and A. Pitsillides, “Performance Evaluation of Mobile
IPv6 Handover Extensions in an IEEE 802.11b Wireless Network Environment,” in 11thIEEE Symposium on Computers and Communications (ISCC 2006). Sardinia, Italy: IEEE,
June 2006, pp. 161–166.
[39] G. Xie, J. Chen, H. Zheng, J. Yang, and Y. Zhang, “Handover Latency of MIPv6 Implemen-
tation in Linux,” in IEEE Global Telecommunications Conference (IEEE GLOBECOM 2007).
Washington, DC: IEEE, November 2007, pp. 1780–1785.
[40] J. Pinola and K. Pentikousis, “IPTV over WiMAX with MIPv6 Handovers,” in 69th IEEEVehicular Technology Conference (VTC2009-Spring). Barcelona, Spain: IEEE, April 2009,
pp. 1–5.
Bibliography 108
[41] H. Petander, E. Perera, and K.-C. L. A. Seneviratne, “Measuring and Improving the
Performance of Network Mobility Management in IPv6 Networks,” IEEE Journal on SelectedAreas in Communications (JSAC), vol. 24, no. 9, pp. 1671–1681, 2006.
[42] C. Vogt, “A Comprehensive Delay Analysis for Reactive and Proactive Handoffs with
Mobile IPv6 Route Optimization,” TU Karlsruhe, Institute of Telematics, Technical Report
TM-2006-1, January 2006.
[43] N. A. Fikouras and C. Görg, “Performance comparison of hinted- and advertisement-
based movement detection methods for mobile IP hand-offs,” Elsevier Computer Networks,vol. 37, no. 1, pp. 55–62, 2001.
[44] Y.-G. Hong, M.-K. Shin, and H.-J. Kim, “Fast Handover for Mobile IPv6 using Access Router
Based Movement Detection and CoA Configuration,” in 59th IEEE Vehicular TechnologyConference (VTC2004-Spring). Milan, Italy: IEEE, May 2004, pp. 2442–2446.
[45] C. Bauer and S. Ayaz, “ATN Topology Considerations for Aeronautical NEMO RO,” IETF,
Internet-Draft (work in progress) draft-bauer-mext-aero-topology-01.txt, September 2009.
[46] N. Moore, “Optimistic Duplicate Address Detection (DAD) for IPv6,” IETF, RFC 4429,
April 2006.
[47] R. Koodli, “Mobile IPv6 Fast Handovers,” IETF, RFC 5268, June 2008.
[48] R. M. Hinden and S. E. Deering, “IP Version 6 Addressing Architecture,” IETF, RFC 4291,
February 2006.
[49] “Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS),” 3GPP, Technical
Specification TS 24.301 V10.0.0, October 2010.
[50] “Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks,” 3GPP,
Technical Specification TS 24.302 V10.2.0, December 2010.
[51] S. Brandes, U. Epple, S. Gligorevic, M. Schnell, B. Haindl, and M. Sajatovic, “Physical layer
specification of the L-band Digital Aeronautical Communications System (L-DACS1),” in
Integrated Communications, Navigation and Surveillance Conference, ICNS ’09., May 2009,
pp. 1 –12.
[52] F. Xia, B. Sarikaya, and B. Patil, “Mobile IPv6 Handover Using Home Agent Buffering,”
IETF, I-D draft-xia-mipshop-ha-buffering-01, November 2008.
[53] P. S. Henry and H. Luo, “Buffering packets destined for a mobile device while the mobile
device moves from one network to another network to prevent handoff packet loss,”
Patent 7600040, October 2009.
[54] H.-D. Park, Y.-H. Kwon, K.-W. Lee, Y.-S. Choi, S.-H. Lee, and Y. Z. Cho, “Network
Mobility Management Using Predictive Binding Update,” in 7th International Workshop
Bibliography 109
on Distributed Computing (IWDC 2005), vol. LNCS 3741. Kharagpur, India: Springer,
December 2005.
[55] K. Hur, K. H. Tchah, and D. S. Eom, “TCP Performance Analysis of Packet Buffering in
Mobile IP Based Networks,” IEICE Transactions on Communications, vol. E87-B, no. 11,
pp. 3361–3369, 2004.
[56] S. B. Lee, K. Hur, J. Park, and D.-S. Eom, “A packet forwarding controller for mobile
IP-based networks with packet buffering,” IEEE Transactions on Consumer Electronics,vol. 55, no. 3, pp. 1344–1350, August 2009.
[57] Y.-S. Kim, D.-H. Kwon, and Y.-J. Suh, “Seamless handover support over heterogeneous
networks using FMIPv6 with definitive L2 triggers,” Wireless Personal Communications,vol. 43, pp. 919–932, 2007.
[58] D. S. Eom, M. Sugano, M. Murata, and H. Miyahara, “Performance Improvement by
Packet Buffering in Mobile IP Based Networks,” IEICE Transactions on Communications,vol. E83-B, no. 11, pp. 2501–2512, 2000.
[59] D. Le, X. Fu, and D. Hogrefe, “A Cross-Layer Approach for Improving TCP Performance in
Mobile Environments,” Wireless Personal Communications, vol. 52, pp. 669–692, 2010.
[60] L. Daniel and M. Kojo, “Employing cross-layer assisted TCP algorithms to improve TCP
performance with vertical handoffs,” Int. J. Commun. Netw. Distrib. Syst., vol. 1, pp.
433–465, November 2008.
[61] D. Lee and J. Kim, “TCP Performance Enhancement Incorporating Handoff Analysis in
Mobile IPv6 Networks,” in High Speed Networks and Multimedia Communications, ser.
Lecture Notes in Computer Science. Springer Berlin / Heidelberg, 2004, vol. 3079, pp.
512–523.
[62] E. Ivov, J. Montavont, and T. Noel, “Thorough empirical analysis of the IETF FMIPv6
protocol over IEEE 802.11 networks,” Wireless Communications, IEEE, vol. 15, no. 2, pp.
65 –72, april 2008.
[63] E. Haas, “Aeronautical channel modeling,” Vehicular Technology, IEEE Transactions on,
vol. 51, no. 2, pp. 254 –264, March 2002.
[64] S. Brandes, U. Epple, and M. Schnell, “Compensation of the Impact of Interference
Mitigation by Pulse Blanking in OFDM Systems,” in IEEE Global TelecommunicationsConference (GLOBECOM 2009), Honolulu, HI, December 2009, pp. 1–6.
[65] E. Allaix and T. Azzarelli, “Estimation of Information Volume Requirements for ATM under
AI 1.7,” ICAO, Working Paper WP17, April 2009.
[66] M. Ehammer, T. Graupl, and C.-H. Rokitansky, “TCP/IP over aeronautical communication
systems - Effects on bandwidth consumption,” in Digital Avionics Systems Conference, 2009.DASC ’09. IEEE/AIAA 28th, October 2009, pp. 4.A.3–1 –4.A.3–9.
Bibliography 110
[67] G. E. Montenegro, S. Dawkins, M. Kojo, V. Magret, and N. Vaidya, “Long Thin Networks,”
IETF, RFC 2757, January 2000.
[68] R. Chakravorty, J. Cartwright, and I. Pratt, “Practical experience with TCP over GPRS,”
in Global Telecommunications Conference, 2002. GLOBECOM ’02. IEEE, vol. 2, November
2002, pp. 1678 – 1682 vol.2.
[69] V. Jacobson, “Congestion avoidance and control,” SIGCOMM Comput. Commun. Rev.,vol. 18, pp. 314–329, August 1988.
[70] Y. Gou, D. Pearce, and P. Mitchell, “A receiver-based vertical handover mechanism for
TCP congestion control,” Wireless Communications, IEEE Transactions on, vol. 5, no. 10,
pp. 2824 –2833, October 2006.
[71] N. Kirschnick, F. Steuer, P. Vidales, and S. Albayrak, “Adaptive window size to reduce the
influence of heterogeneous mobility on TCP performance,” in Computers and Communica-tions, 2008. ISCC 2008. IEEE Symposium on, July 2008, pp. 149 –156.
[72] M. E. Fisk and W. Feng, “Dynamic Right-Sizing in TCP,” in 2nd Annual Los AlamosComputer Science Institute Symposium, Santa Fe, MX, October 2001.
[73] E. Weigle and W.-c. Feng, “A Comparison of TCP Automatic Tuning Techniques for
Distributed Computing,” in 11th IEEE International Symposium on High PerformanceDistributed Computing (HPDC 2002). Washington, DC: IEEE, 2002, p. 265.
[74] K. Wongthavarawat and A. Ganz, “Packet scheduling for QoS support in IEEE 802.16
broadband wireless access systems,” International Journal of Communication Systems,vol. 16, no. 1, pp. 81–96, 2003.
[75] A. Demers, S. Keshav, and S. Shenker, “Analysis and simulation of a fair queueing
algorithm,” in Symposium proceedings on Communications architectures & protocols, ser.
SIGCOMM ’89. New York, NY, USA: ACM, 1989, pp. 1–12. [Online]. Available:
http://doi.acm.org/10.1145/75246.75248
[76] M. Shreedhar and G. Varghese, “Efficient fair queuing using deficit round-robin,” IEEE/ACMTransactions on Networking, vol. 4, no. 3, pp. 375–385, June 1996.
[77] C. So-In, R. Jain, and A.-K. Tamimi, “A Deficit Round Robin with Fragmentation scheduler
for IEEE 802.16e Mobile WiMAX,” in Sarnoff Symposium, 2009. SARNOFF ’09. IEEE, April
2009, pp. 1 –7.
[78] C. Cicconetti, A. Erta, L. Lenzini, and E. Mingozzi, “Performance Evaluation of the IEEE
802.16 MAC for QoS Support,” IEEE Transactions on Mobile Computing, vol. 6, no. 1, pp.
26–38, January 2007.
[79] R. Jain, D. Chiu, and W. Hawe, “A Quantitative Measure Of Fairness And Discrimination
For Resource Allocation In Shared Computer Systems,” DEC, Research Report TR-301,
September 1984.
Bibliography 111
[80] N. Fistas and J. Micallef, “An Investigation into the Aircraft VHF Voice Transmissions
(Aircraft DSB-AM Voice Usage Profile),” Eurocontrol, Tech. Rep., April 2004.
[81] K. Pentikousis, E. Piri, J. Pinola, F. Fitzek, T. Nissilä, and I. Harjula, “Empirical evaluation
of VoIP aggregation over a fixed WiMAX testbed,” in TridentCom’08. Innsbruck, Austria:
ICST, 2008, pp. 19:1–19:10.
[82] “General Recommendations on the transmission quality for an entire international tele-
phone connection,” ITU, Recommend. G.114, May 2003.
[83] X. Hu, L. Li, Z. Mao, and Y. Yang, “Wide-Area IP Network Mobility,” in INFOCOM 2008.The 27th Conference on Computer Communications. IEEE. IEEE, April 2008, pp. 951
–959.
[84] C.-W. Ng, F. Zhao, M. Watari, and P. Thubert, “Network Mobility Route Optimization
Solution Space Analysis,” IETF, RFC 4889, July 2007.
[85] P. Thubert, R. Wakikawa, and V. Devarapalli, “Global HA to HA protocol,” IETF, Internet-
Draft (work in progress) draft-thubert-mext-global-haha-01.txt, July 2009.
[86] H. Kang, K. Kim, S. Han, K.-J. Lee, and J.-S. Park, “Route Optimization for Mobile
Network by Using Bi-directional Between Home Agent and Top Level Mobile Router,”
IETF, Internet-Draft (work in progress) draft-hkang-nemo-ro-tlmr-00, June 2003.
[87] R. Wakikawa, “Optimized Route Cache Protocol (ORC),” IETF, Internet-Draft (work in
progress) draft-wakikawa-nemo-orc-01, October 2004.
[88] J. Na, S. Cho, C. Kim, S. Lee, H. Kang, and C. Koo, “Route Optimization Scheme based
on Path Control Header,” IETF, Internet-Draft (work in progress) draft-na-nemo-path-
control-header-00, April 2004.
[89] C. J. Bernardos, M. Bagnulo, M. Calderon, and I. Soto, “Mobile IPv6 Route Optimisation
for Network Mobility (MIRON),” IETF, Internet-Draft (work in progress) draft-bernardos-
nemo-miron-01, July 2007.
[90] E. Perera, R. Hsieh, and A. Seneviratne, “Extended Network Mobility Support,” IETF,
Internet-Draft (work in progress) draft-perera-nemo-extended-00, July 2003.
[91] P. Thubert and M. Molteni, “IPv6 Reverse Routing Header and its application to Mobile
Networks,” IETF, Internet-Draft (work in progress) draft-thubert-nemo-reverse-routing-
header-07, February 2004.
[92] C.-W. Ng and J. Hirano, “Securing Nested Tunnels Optimization with Access Router
Option,” IETF, Internet-Draft (work in progress) draft-ng-nemo-access-router-option-01,
July 2004.
Bibliography 112
[93] R. Wakikawa, P. Thubert, and V. Devarapalli, “Inter Home Agents Protocol Specification,”
IETF, Internet-Draft (work in progress) draft-wakikawa-mip6-nemo-haha-spec-01.txt,
March 2006.
[94] B. Haley, V. Devarapalli, J. Kempf, and H. Deng, “Mobility Header Home Agent Switch
Message,” IETF, RFC 5142, January 2008.
[95] C.-W. Ng, T. Ernst, E. K. Paik, and M. Bagnulo, “Analysis of Multihoming in Network
Mobility Support,” IETF, RFC 4980, October 2007.
[96] R. Wakikawa, V. Devarapalli, G. Tsirtsis, T. Ernst, and K. Nagami, “Multiple Care-of
Addresses Registration,” IETF, RFC 5648, October 2009.
[97] G. Tsirtsis, H. Soliman, N. Montavont, G. Giaretta, and K. Kuladinithi, “Flow Bindings
in Mobile IPv6 and Network Mobility (NEMO) Basic Support,” IETF, RFC 6089, January
2011.
[98] Y. Zhang and H. Zhang, “A Mobile Agent Fault-Tolerant Method Based on the Ring
Detection & Backup Chain for Mobile IPv6 Networks,” in IEEE International Conference onCommunications (ICC). IEEE, June 2011, pp. 1–5.
[99] C. Kaufman, P. Hoffman, Y. Nir, and P. Eronen, “Internet Key Exchange Protocol Version 2
(IKEv2),” IETF, RFC 5996, September 2010.
[100] P. Hoffman, “Cryptographic Suites for IPsec,” IETF, RFC 4308, December 2005.
[101] L.-N. Hamer and B. Kosinski, “IPSec Context Transfer,” IETF, Internet-Draft (work in
progress) draft-hk-seamoby-ct-ipsec-00.txt, May 2001.
[102] R. Koodli, J. Loughney, M. F. Nakhjiri, and C. E. Perkins, “Context Transfer Protocol
(CXTP),” IETF, RFC 4067, July 2005.
[103] F. Allard, J.-M. Combes, J.-M. Bonnin, and J. Bournelle, “IKE context transfer in an IPv6
mobility environment,” in Proceedings of the 3rd international workshop on Mobility in theevolving internet architecture, ser. MobiArch ’08. New York, NY, USA: ACM, 2008, pp.
55–60. [Online]. Available: http://doi.acm.org/10.1145/1403007.1403020
[104] R. Wakikawa, V. Devarapalli, and P. Thubert, “Inter Home Agents Protocol (HAHA),”
IETF, Internet-Draft (work in progress) draft-wakikawa-mip6-nemo-haha-01.txt, February
2004.
[105] V. Jacobson, B. Braden, and D. Borman, “TCP Extensions for High Performance,” IETF,
RFC 1323, May 1992.
[106] “WP15 - Non Avionic CNS System,” SESAR Joint Undertaking, Description of Work,
December 2008.
[107] J. Arkko, C. Vogt, and W. Haddad, “Enhanced Route Optimization for Mobile IPv6,” IETF,
RFC 4866, May 2007.
