Laboratory Test-Bed for Concept Validation · 2015-07-03 · NEWSKY - Networking the Sky for...

Project co-funded by the European Commission within the 6th Framework Programme

www.newsky-fp6.eu

Laboratory Test-Bed for Concept Validation

Deliverable D17

PROJECT INFORMATION

Project Name NEWSKY – Networking the Sky for Aeronautical Communications

EC Instrument Specific Targeted Research Project (STREP) within FP6

Call AERO-2005-1.3.1.4G (Innovative ATM Research)

Contract Number 37160

Project Duration 26/02/2007 – 26/09/2009 (30 months)

Project Coordinator German Aerospace Center (DLR)

Project Partners Thales Alenia Space France (TASF), QinetiQ Ltd, University of Salzburg (UniSBG), Frequentis GmbH (FRQ), TriaGnoSys GmbH (TGS), Deutsche Flugsicherung GmbH (DFS)

DOCUMENT INFORMATION

Title Laboratory Test-Bed for Concept Validation

Version 1.1

Work Package WP4

Dissemination Level PU

DOCUMENT AUTHORS AND AUTHORIZATION

Document Responsible Eriza Fazli, TriaGnoSys GmbH [email protected] +49 8153 88678209

Contributors M. Ehammer (USBG), T. Gräupl (USBG), N. Riera (TGS), F. Hoffmann (DLR), F. Schreckenbach (DLR), K. Leconte (TAS)

Released by Frank Schreckenbach (DLR) Date: 08/12/08

NEWSKY - Networking the Sky for Aeronautical Communications

Laboratory Test-Bed for Concept Validation Page: I

DOCUMENT HISTORY

Version Date Modified Contents Implemented by

1.0 22/08/08 First issue E. Fazli

1.1 08/12/08 Revisions according to comments from EC and Eurocontrol

E. Fazli


Laboratory Test-Bed for Concept Validation Page: II

Contents

1 Executive Summary ..................................................................1-1

2 General...................................................................................2-1

2.1 Acronyms and Abbreviations ................................................................... 2-1

2.2 References ........................................................................................... 2-3

3 Introduction.............................................................................3-1

3.1 Overview of the NEWSKY Project ............................................................. 3-1

3.2 Scope of the Document and Validation Approach........................................ 3-2

3.3 Structure of the Document...................................................................... 3-3

4 Laboratory Demonstration Objectives ..........................................4-1

4.1 Network Functions Addressed.................................................................. 4-1

4.2 Technical Requirements to be Validated through Demonstration ................... 4-1

4.3 NEWSKY Benefits Addressed ................................................................... 4-5

4.4 Definition of Evaluation Parameters .......................................................... 4-6

4.5 Overview of Validation Objectives ............................................................ 4-7

5 Definition of Demonstration Scenarios .........................................5-1

5.1 Network Architecture to be Demonstrated ................................................. 5-1

5.2 Scenarios for Validation through Demonstration ......................................... 5-2

5.2.1 Scenario 1: MobileIPv6/NEMO Functionality ......................................... 5-3

5.2.2 Scenario 2: Handover Due to Link Unavailability................................... 5-4

5.2.3 Scenario 3: Handover Due to Flight Phases and Operational Preferences.. 5-4

5.3 Demonstration Strategy ......................................................................... 5-4

6 Scenarios Coverage ..................................................................6-1

7 Laboratory Network ..................................................................7-1

7.1 Laboratory Network Architecture.............................................................. 7-1

7.2 Laboratory Network Components ............................................................. 7-1


Laboratory Test-Bed for Concept Validation Page: III

7.2.1 Dual-Stack IPv4/IPv6 Router ............................................................. 7-1

7.2.2 Satellite Communications Modem....................................................... 7-2

7.2.3 Terrestrial Communication Links ........................................................ 7-5

7.2.3.1 B-AMC / L-DACS-1 ..................................................................... 7-5

7.2.3.2 WiMAX ..................................................................................... 7-6

7.3 Representative Applications .................................................................... 7-6

7.3.1 Short ATS/AOC Messages.................................................................. 7-6

7.3.2 Voice over IP (VoIP)......................................................................... 7-6

7.3.3 HTTP and FTP server ........................................................................ 7-7

7.4 Implementation Aspects ......................................................................... 7-8

7.4.1 Scenario 1 ...................................................................................... 7-8

7.4.2 Scenario 2 ...................................................................................... 7-8

7.4.3 Scenario 3 ...................................................................................... 7-8

Illustrations

Figure 3-1: WP4.5 relations to other work packages............................................... 3-2

Figure 3-2: Overview of tables mapping the different requirements, objectives, and scenarios presented in this document................................................................... 3-3

Figure 5-1: Network architecture......................................................................... 5-1

Figure 5-2: Categorisation of handover ................................................................ 5-3

Figure 7-1: Laboratory network architecture ......................................................... 7-1

Figure 7-2: Inmarsat I4 satellite coverage [6] ....................................................... 7-3

Figure 7-3: Thrane & Thrane Explorer 300 ............................................................ 7-3

Figure 7-4: Top view of the Thrane & Thrane Explorer 300, highlighting the configuration panel............................................................................................................... 7-4

Figure 7-5: Thrane & Thrane Explorer 300 LaunchPad user interface......................... 7-4

Figure 7-6: Thrane & Thrane Explorer 300 configuration via web interface [7]............ 7-5

Figure 7-7: SIP signalling ................................................................................... 7-7

Figure 7-8: Graphical user interface (GUI) illustrating a flight route and communication link handover ................................................................................................... 7-9


Laboratory Test-Bed for Concept Validation Page: IV

Tables

Table 4-1: Mapping of NEWSKY system requirements to be validated in the laboratory test-bed, with the corresponding user requirements ............................................... 4-4

Table 4-2: Technical requirements not addressed in the test-bed ............................. 4-5

Table 4-3: NEWSKY KPAs and benefits addressed in the Demonstration .................... 4-6

Table 4-4: Evaluation criteria .............................................................................. 4-7

Table 4-5: Test-bed demonstration objectives ....................................................... 4-8

Table 4-6: Mapping of Functionalities to Objectives ................................................ 4-8

Table 5-1: Mapping of scenarios to different types of handover................................ 5-3

Table 5-2: Demonstration strategy for the selected NEWSKY technical requirements... 5-5

Table 5-3: Demonstration strategy for the selected NEWSKY functionalities ............... 5-5

Table 5-4: Selected NEWSKY benefits and proposed validation method ..................... 5-6

Table 6-1: Mapping of scenarios to requirements ................................................... 6-1

Table 6-2: Mapping of scenarios to benefits .......................................................... 6-1

Table 6-3: Mapping of scenarios to objectives ....................................................... 6-1


Laboratory Test-Bed for Concept Validation Page: 1-1

1 Executive Summary

The NEWSKY project is developing a concept of a global, mobile communication network for aeronautical communications.

NEWSKY pursues the vision of “Networking the Sky” by integrating different links (ground based, satellite-based, aircraft-to-aircraft, airport communications), different communication technologies and different application classes into a single, seamless network. The envisaged application classes comprise not only safety related services as Air Traffic Services (ATS) and Aeronautical Operation Control (AOC), but also non safety related services as Airline Administrative Communications (AAC) and passenger communications (APC). Cost savings, high reliability and an optimal alignment with the evolution of communication and security technologies is intended to be achieved by using Commercial-Off-The-Shelf (COTS) solutions based on IPv6 wherever possible.

The innovative networking approach of NEWSKY enables to achieve improved communication capabilities meeting the high efficiency, reliability and security requirements. Moreover, real air-ground integration is achieved and the information sharing concepts of Collaborative Decision Making (CDM) and System Wide Information Management (SWIM) are made available to the aircraft. As a consequence, the NEWSKY approach assists the realization of the Single European Sky (SES) concept and helps to create a future aeronautical communication system which can be operational from 2020 onwards.

This document is concerned with one part of WP4.1 “Simulation Scenarios and Test-Bed Definition”. The objectives of this WP are to produce two sets of scenario definitions. The first is a realistic definition of relevant simulation scenarios and the second is a representative laboratory test-bed. The main output of this WP is a list of objectives and scenarios for concept validation, and a mapping on how the scenarios proposed matched the targeted objective. This document focuses on the definition of laboratory test-bed for concept validation. The simulation framework is described in the other deliverable of WP4.1, D16 “Simulation Scenarios for Concept Validation” [24].

The aim of this document is to derive the scenarios, and to describe the components used in the laboratory demonstration. The demonstration scenarios will be derived taking into account NEWSKY system requirements, NEWSKY functionalities, and benefits of the NEWSKY system. In addition to these, the limitation of the laboratory environment should also be taken into account in deriving the demonstration scenario. Since the stated work for NEWSKY laboratory demonstration was to show handover between satellite and terrestrial-based access network, the scenarios will be built around a handover situation.

Based on those considerations, the following scenarios are envisaged:

basic tests of Mobile IPv6 (MIPv6) and Network Mobility (NEMO) protocol implementation in the context of aeronautical communications, as the underlying protocol for providing mobility support,

handover due to link unavailability, and

handover due to flight phases and operational preferences.

The proposed scenarios will then be mapped with the NEWSKY requirements, functionalities, and benefits. At the end, the components of the laboratory demonstration are shortly described.



2 General

2.1 Acronyms and Abbreviations

AH Authentication Header

AOC Airline Operational Control

APC Airline Passenger Communications

AR Access Router

ATC Air Traffic Control

ATM Air Traffic Management

ATS Air Traffic Service

BACK Binding Acknowledgment

BGAN Broadband Global Area Network

BU Binding Update

CDM Collaborative Decision Making

CN Corresponding Node

CoA Care-of Address

CoT Care-of Test

CoTI Care-of Test Init

COTS Commercial-Off-the-Shelves

ENR En Route

ESP Encapsulating Security Payload

FTP File Transfer Protocol

GEO Geostationary

GW Gateway

HA Home Agent

HO Handover

HoA Home Address

HoT Home Test

HoTI Home Test Init

HTTP Hypertext Transfer Protocol

IP Internet Protocol

IPSec IP Security

L2TP Layer 2 Tunneling Protocol

LDACS L-band Digital Aeronautical Communication System



MIPv6 Mobile IP version 6

MN Mobile Node

MNN Mobile Network Node

MR Mobile Router

NAT Network Address Translation

NEMO Network Mobility

ORP Oceanic Remote and Polar

PLMN Public Land Mobile Network

PSTN Public Switched Telephone Network

RR Return Routability

SIP Session Initiation Protocol

SWIM System Wide Information Management

TCP Transport Control Protocol

UA User Agent

UDP User Datagram Protocol

VoIP Voice over IP



2.2 References

[1] “Communications Operating Concept and Requirements for the Future Radio System”, COCR version 2.0, Eurocontrol/FAA Future Communication Study, May 2007.

[2] Johnson, D., Perkins, C., and Arkko, J., “Mobility Support in IPv6”, RFC 3775, June 2004.

[3] Devarapalli, V. et al., “Network Mobility (NEMO) Basic Support Protocol”, RFC 3963, January 2005.

[4] Simpson, W., “IP-in-IP Tunnelling”, RFC 1853, October 1995.

[5] Kent, S., “IP Encapsulating Security Payload (ESP)”, draft-ietf-ipsec-esp-v3-09.txt (work in progress), September 2004.

[6] WWW-Page. (last visited May 2008): http://www.inmarsat.com/Services/Land/BGAN/Coverage.aspx?language=EN&textonly=False.

[7] Thrane & Thrane EXPLORER 300 User Manual, can be found at http://www.thrane.com/Land%20Mobile/Products/~/media/PDFs/Manuals/Satcom%20manuals/LM/EXPLORER%20300/e300%20user%20manual%20tt%2098-123571-d.pdf.ashx.

[8] Rosenberg, J., “SIP: Session Initiation Protocol”, RFC 3261, June 2002.

[9] Apache web server, WWW-Page: http://httpd.apache.org/

[10] FTP server, WWW-Page: http://vsftpd.beasts.org/

[11] WWW-Page. (last visited May 2008): http://www.nautilus6.org.

[12] Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers”, draft-ietf-mext-nemo-v4traversal-04.txt, June 2008.

[13] WWW-Page (last visited June 2008): http://www.nautilus6.org/doc/tc-bmobile_l2tp-20041028-KuntzR.txt

[14] WWW-Page. (last visited June 2008): http://software.nautilus6.org/DSMIP/index.php

[15] B-AMC project, “System Specification Including Standardization and Certification Considerations,” report D-3, Issue 1.0, 08.08.2007. http://www.eurocontrol.int/communications/gallery/content/public/documents/B_AMC%20Project%20Deliverable_D3_V10.pdf

[16] B-AMC project, “Expected B-AMC System Performance, “ report D-5, Issue 1.1, 21.09.2007 http://www.eurocontrol.int/communications/gallery/content/public/documents/B_AMC%20Project%20Deliverable_D5_V11.pdf

[17] “Validation Strategy”, Deliverable D01.5 of the NEWSKY Project, December 2007.

[18] “NEWSKY Operational Requirements Document”, Deliverable D08 of the NEWSKY Project, January 2008.

[19] “Technology Screening and Characterization for Integration in NEWSKY Network”, Deliverable D09 of the NEWSKY Project, April 2007.



[20] “NEWSKY System Requirements Document”, Deliverable D10 of the NEWSKY Project, to be released

[21] “Seamless Handover Strategies for NEWSKY”, Deliverable D14 of the NEWSKY project, to be released

[22] Townsley, W., “Layer 2 Tunneling Protocol ‘L2TP’”, RFC 2661, August 1999

[23] “Manual for the ATN using IPS Standards and Protocols” (Doc 9896), Version 16, November 2008

[24] “Simulation Scenarios for Concept Validation”, Deliverable D16 of the NEWSKY project, August 2008.

[25] “NEWSKY Design Document”, Deliverable D11 of the NEWSKY project, September 2008.



3 Introduction

3.1 Overview of the NEWSKY Project

Global situation awareness will be a result of improved information availability and sharing, which is one of the key enablers for future aeronautical systems. To achieve this goal, the NEWSKY project aims to develop a concept for a global communication network for aeronautics.

Efficient and reliable communication systems are required to support the expected sustainable growth of European air transport. However, aeronautical communication technologies are already running at their maximum capabilities today. Moreover, the expected air-traffic management (ATM) paradigm shifts towards less voice and more data communications enabling more strategic planning of flight routes requires additional communication capabilities which are not provided by current aeronautical communication systems.

Currently, several European research activities are being undertaken with the goal to develop improved communication technologies for aeronautical communication. These activities comprise ground-based, satellite-based, aircraft-to-aircraft and airport communication for all different application classes, like air-traffic services, airline operational and administrative communication, and aeronautical passenger communication. However, an initiative which aims at the integration of existing and emerging communication technologies into a global network has been missing so far. NEWSKY fills this important gap by conducting upstream research activities focussed on a global aeronautical network design. Whereas System Wide Information Management (SWIM) provides a conceptual framework for global information sharing, NEWSKY is a technical enabler for the implementation of such an approach.

The NEWSKY project does not work on the design new data links. Rather, NEWSKY focuses on the network and transport layer of the protocol stack and pursues the vision of “Networking the Sky” by integrating a range of data links based on different communication technologies (ground based, satellite-based, aircraft-to-aircraft) as well as different application classes into a seamless network. These applications classes comprise: Air Traffic Services (ATS), Airline Operation Communications (AOC), Airline Administrative Correspondence (AAC), and Aeronautical Passenger Communications (APC).

With regards to the evolution of the aeronautical network where IP is being considered as a possible solution, the use of the Internet Protocol (IP) will be investigated in particular. Cost savings, high reliability and an optimal alignment with the evolution of communication and security technologies is intended by using Commercial-Off-The-Shelf (COTS) solutions. Therefore, NEWSKY is involved both in IETF (Internet Engineering Task Force) and ICAO (International Civil Aviation Organisation) activities, in particular in the definition of the Aeronautical Telecommunication Network based on the Internet Protocol Suite (ATN/IPS) in WG-I.

Only IPv6 option is considered within the project. Therefore, the NEWSKY project will consider transition issues from the current Aeronautical Telecommunication Network based on OSI technologies (ATN/OSI) and IPv4 networks towards the NEWSKY IPv6-based network. NEWSKY is targeting 2020 for operation of the integrated system, with IP networking capabilities of the ATN/IPS being implemented earlier.



NEWSKY activities are coordinated with SESAR to ensure the alignment and consistency. The innovative networking approach of NEWSKY enables improved communication capabilities supporting the realisation of SESAR Concepts of Operations.

3.2 Scope of the Document and Validation Approach

This document is the deliverable D17 “NEWSKY Laboratory Test-Bed for Concept Validation” of the NEWSKY project and is one of the outputs of WP4.1 “Simulation Scenarios and Test-Bed Definition”.

In parallel to the simulation activities, laboratory tests will be carried out in WP 4.5 to demonstrate selected functionalities of the NEWSKY network, based on the test-bed scenarios defined in Deliverable D17 of WP 4.1.

The main focus of the scenarios defined for the laboratory test-bed is the validation of a single handover event between a satellite link and a terrestrial link. For this purpose, routers in the laboratory environment will run real implementations of the required protocols, and data will be transmitted over wireless links such as an Inmarsat satellite link or a terrestrial WiMAX link. In this environment, the impact of a handover on real-world applications such as a Voice Over IP call will be determined, considering both technical criteria, such as the delay, as well as the actual user perceived quality of service.

In contrast, the simulation scenarios allow functionalities to be validated in a larger environment involving thousands of aircraft, but using a more abstract protocol implementation and a simplified model of the wireless links. In the simulations, the focus is on the overall network behaviour.

The objective of this document is to define the environment and the required components for the laboratory test-bed of NEWSKY. The demonstration environment is largely derived from the NEWSKY system requirements [20]. This document defines the objectives of the NEWSKY demonstration and the scenarios developed to achieve them, together with the corresponding validation parameters.

Figure 3-1 shows the relationship of WP 4.5 to other NEWSKY work packages.

Figure 3-1: WP4.5 relations to other work packages



3.3 Structure of the Document

This document is structured as follows. Sections 2 and 3 provide a summary and introduction of the NEWSKY project, and the scope of this document. The objectives and lab demonstration evaluation criteria will be described in detail in Section 4. The objectives are mainly derived from NEWSKY statement of work, and NEWSKY technical requirements. Section 5 deals with the different scenarios that are foreseen to be demonstrated in the lab environment and Section 6 contains a number of tables showing the mapping between the test-bed scenarios and all addressed requirements, objectives and benefits. Finally Section 7 gives a detailed description of the components of the laboratory test-bed, which includes the satellite and terrestrial communication terminal, the mobility protocol software implementation, and the application servers intended to run over the test network. Figure 3-2 presents an overview of the tables mapping the different requirements, objectives, and scenarios to be presented in this document.

Scenarios

Validation Objectives Table 4.5

Requirements Tables 4.1, 4.2, 5.2

Parameter, Table 4.4

WP0/D01.5 KPAs and high level NEWSKY benefits

WP2.3/D10System

Requirements

WP2.1/D08Application Scenarios

WP3Network

Functionalities

Table 4.5

Table 6.3

Table 6.1 all

Table 4.5

Benefits, Tables 4.3, 5.4

Table 6.2

FunctionalitiesTable 5.3

Figure 3-2: Overview of tables mapping the different requirements, objectives, and scenarios presented in this document



4 Laboratory Demonstration Objectives

4.1 Network Functions Addressed

Important networking concepts in particular Quality of Service (QoS) management, mobility, handover, and security, have been or are being developed within NEWSKY. The lab demonstration will attempt at showing a subset of the NEWSKY network functions in particular the ones related to the NEWSKY Mobility functionality as defined in D11 [25].

The objective of the lab demonstration includes showing the feasibility of the mobility concept in a laboratory test-bed tailored to emulate real aeronautical communications environment.

Mobile IPv6 (MIPv6) and its extensions have been selected as the protocol to support mobility in ATN/IPS. Selected routing and mobility tasks in relation to NEWSKY WP3.2 that will be addressed in the laboratory test-bed, corresponding to the MIPv6 functions, are:

Home Agent (HA) registration

Correspondent Node (CN) registration, including signalling involved in Return Routability (RR) procedure

Basic network mobility with NEMO Basic Support

4.2 Technical Requirements to be Validated through Demonstration

The laboratory demonstration will attempt to demonstrate a subset of NEWSKY system requirements defined in NEWSKY Deliverable D10 [20]. D10 indicates for each requirement if it will be validated by design inspection or by demonstration, meaning “by demonstration” that they will be validated with the simulator, with the test-bed or both.

This section aims to recall the requirements which stated demonstration as the intended validation method and clarify which will actually be validated in the test-bed. The requirements to be validated in the test-bed are listed in Table 4-1, extracted from [20], along with the user requirement [18] from which each of the system requirements is derived. In addition, Table 4-2 justifies why a set of technical requirements are not validated in the laboratory demonstrations.



System Requirement ID

System Requirement Description User Require-ment ID

User Requirement Description

Req-Flex-S32. The NEWSKY system shall support backup scenarios by sending the traffic over a new sub-network in case the first one fails.

n.a. (NEWSKY internal)

-

[U106] The NEWSKY system shall allocate the highest class of service to network management services. [COCR2] (This is consequence of U29)

[U29] The NEWSKY system shall provide higher priority for network messages over ATS services and higher priority for ATS services o AOC services. [COCR2]

Comment: AAC services and APC services will have the lowest priority (this is a consequence of the previous requirement).

Req-QoS-S38 The NEWSKY system shall provide mechanisms to prioritise the different service categories (Network management, ATS, AOC, AAC, APC). When different service categories compete for the NEWSKY services, the priority rules are statically defined as:

Network Management >> ATS >> AOC >> AAC >> APC where A>>B indicates that A has higher priority than B.

Note: These static priority rules apply only in case all of these services share the same infrastructure, which may not be feasible due to security considerations. In case separate infrastructure is used by operational and non-operational traffic, this requirement reduces to “Network Management >> ATS >> AOC and Network Management >> AAC >> APC, where A >> B indicates that A has higher priority than B.”

[U18] The NEWSKY system shall be able to prioritise different services (ATS, AOC, AAC, APC).

Req-QoS-S39. The NEWSKY system shall be able to prioritise different services/applications within each service category (Network Management, ATS, AOC, AAC, APC).

[U18] The NEWSKY system shall be able to prioritise different services (ATS, AOC, AAC, APC).



Req-QoS-S40. The NEWSKY ATN/IPS solution shall operate in accordance with the communication priorities for the different messages of the different ATN/IPS services as defined in [23].


-

[U25] The NEWSKY system shall implement different internal classes of services (CoS) corresponding to different QoS requirements. [NEWSKY-DOW] [COCR2] [UserMeeting27042007]

Req-QoS-S43 The NEWSKY network shall support mapping of QoS requirements of operational services onto the different classes of service (CoS) at network layer. [U26] The NEWSKY system shall allow to map the different applications

services to the required CoS. [NEWSKY-DOW] [NASA] [COCR2] [UserMeeting27042007]

Req-Mob-S70. The NEWSKY system shall support session continuity.

Note: Session continuity allows to keep current active sessions alive during a handover between different technologies or access networks.


-

Req-Mob-S78. When supporting ATS, AOC, AAC and APC data communications, the NEWSKY system shall minimize latency during establishment of initial paths to an aircraft, during handover and during transfer of individual data packets.

When moving between different access networks, the mobility related signalling should be as efficient as possible to minimize delay and reduce packet loss.

Note: The “establishment of initial paths” refers to the establishment of end-to-end services at the application layer, which is determined by the latency of all lower layers.

[U58] The NEWSKY system shall minimize latency during establishment of initial paths to an aircraft, during handover, and during transfer of individual data packets. [ICAO-SWGN1-5 WP506] [ICAO-SWG1-6 WP605] [ICAO-SWGN1-7 WP715]



Req-HO-S85. The NEWSKY system shall provide the means to perform handovers as efficiently as possible. Consecutively, packet loss during a handover shall be minimized.


-

Req-Net-S109 The NEWSKY ATN/IP transport layer solution should provide reliable end-to-end data transport between IP hosts (end-systems).

Note: Not all IP end host may need E2E reliable transport.

n.a. -

Table 4-1: Mapping of NEWSKY system requirements to be validated in the laboratory test-bed, with the corresponding user requirements



Requirement Id. Requirement Description Why is not addressed

Req-Flex-S31 The NEWSKY system shall provide mechanisms to allocate the resources from different sub-network efficiently in order to optimise capacity and effective performance.

Not demonstrated because it is more suitable for simulation

Req-QoS-S46 The NEWSKY network shall always select the link technology CoS that can provide the QoS required by this service or a higher QoS.

Automatic link selection based on QoS is more appropriate for simulation and will not be demonstrated (no scenario is proposed to show this).

Req-QoS-S57 When providing ATS and AOC services, the NEWSKY network shall provide the COCR [1] QoS figures (availability, continuity, integrity, latency) that can be attributed to the NEWSKY system.

QoS figures are more appropriate to be measured in simulation as they would require many tests to generate sufficient statistics.

Req-QoS-S58 When providing AAC and APC services, the NEWSKY system shall offer the QoS figures (availability, continuity, integrity, latency) that can be attributed to the NEWSKY functions (excluding the external hosts and mobile sub-networks).

Same as Req-QoS-S57

Req-Mob-S79 The NEWSKY mobility solution for ATS and AOC shall be capable of providing the means to meet the service requirements and expiration times as defined in [1], assuming that the underlying link technology is fulfilling the FRS requirements as specified

Same as Req-QoS-S57

Req-HO-S80 The NEWSKY system supporting ATS, AOC, AAC and APC data communications shall enable an aircraft to be simultaneously connected to and roam between multiple independent access networks.

In order to meet the availability requirements of applications, the airborne router shall be capable of supporting multiple concurrent attachments to access networks. This allows for make-before-break handover strategies and for simultaneous packet transmission over different paths.

As currently there is no stable implementation to support simultaneous connection to many access networks, this requirement will not be validated in the lab test-bed.

Table 4-2: Technical requirements not addressed in the test-bed

4.3 NEWSKY Benefits Addressed

Reference [17] defines the key performance areas (KPAs) and high level benefits of NEWSKY system and their alignment with SESAR KPAs. The following table extracts from [17] the benefits of NEWSKY that are addressed in the laboratory test-bed demonstration keeping the numbering used in [17]:



Benefit Id. Benefit Description KPA

B01 The different communication links within NEWSKY cover the whole available Aeronautical Mobile (Route) Services (AM(R)S) and Aeronautical Mobile Satellite (Route) Services (AMS(R)S) spectrum and may address preliminary usability considerations of higher frequency bands. As global integrated network NEWSKY realizes the most flexible and efficient use of the available aeronautical spectrum allocations.

Capacity

B02 NEWSKY integrates several communication links which are specially adapted to different environments, e.g., WiMAX (802.16) for airport communication and satellite-based communication for remote and oceanic areas. This enables globally optimized network utilization and performance.

Capacity

B03 Compared to a single communication link an integrated network inherently achieves increased redundancy which in turn increases availability and reliability of the overall communications system.

Safety

B04 The coverage of the overall system is increased since different communication systems with different application areas are combined, hence improving the safety.

Safety

B06 Commercial off-the-shelf (COTS) IP-based networking protocols are used whenever possible for a cost efficient realization. IPv6 is considered as baseline.

Cost Effectiveness

B10 The seamless communication possibilities of NEWSKY are a key enabler to improve efficiency, predictability and flexibility. NEWSKY promotes globally situation awareness that helps to optimize flight trajectories and airport surface movements to reduce delays, to enable a more strategic decision making, and to be able to respond to short notice changes in demand and capacity.

Efficiency, predictability, and flexibility

B11 The integrated NEWSKY approach ensures interoperability between different communication links and, thus, provides a seamless ATM system which is fully transparent to the end users.

Interoperability

Table 4-3: NEWSKY KPAs and benefits addressed in the Demonstration

The mechanisms of how the benefits are going to be demonstrated are depicted in Table 5-4.

4.4 Definition of Evaluation Parameters

Some initial (high level) validation parameters have been defined in deliverable D01.5 “Validation Strategy” [17] and in D08 “Operational Requirements Document” [18]. The current document defines a list of parameters, based on the referred documents, which allow performance assessment in a laboratory test-bed, in particular the ones which will be affected by a handover. The foreseen evaluation parameters are described in Table 4-4:



Parameter Id. Parameter Parameter Description

Par_1 Total throughput Total amount of user data that successfully arrives at its intended receiver in a given period of time, measured in bits per second.

Par_2 Handover delay Time that elapses beginning when the mobile node is no longer able to transmit an IP packet due to a handover and ending when the mobile node is again able to transmit an IP packet, measured in seconds.

Par_3 Packet loss Percentage of all IP packets that are created that are not received correctly.

Par_4 End-to-end delay for Layer 3 IP packets

Time that elapses from the creation of an IP packet until its correct reception at the network layer of the receiver, measured in seconds.

Table 4-4: Evaluation criteria

These parameters are not going to be strictly validated against performance requirement figures such as the ones in COCR [1] because within the NEWSKY project, the focus is on the mobile network component only. A comparison with some COCR values will be made, but a strict validation of these numbers would require a true end-to-end test-bed that depends (among others) on the data link technologies and their associated radio frequency resources, which are out-of-scope of NEWSKY’s design.

Neverthless, the parameters listed in Table 4-4 will be measured and analysed to allow a comparison of different network configurations and first results on the performance ranges that can be achieved.

4.5 Overview of Validation Objectives

An overview of the validation objectives derived in the preceding sections is given below in Table 4-5. Demonstration scenarios to validate each of these objectives are defined in section 5.

Objective Id.

Description Parameters to Measure

Requirements Addressed

Obj_1 Demonstrate the ability of the NEWSKY network to handle failure of a terrestrial base station.

Par_2 Par_3 Par_4

Req-Flex-S32 Req-Flex-S38 Req-Flex-S39

Obj_2 Demonstrate the ability of the NEWSKY network to handle priority among different service categories and services/applications within each service category.

Par_4 Req-Flex-S38 Req-Flex-S39 Req-QoS-S40 Req-QoS-S43



Obj_3 The relative performance achieved by the different traffic classes shall reflect the QoS requirements as defined in D10

Par_1 Par_3 Par_4

Req-QoS-S38 Req-QoS-S39 Req-QoS-S40 Req-QoS-S43

Obj_4 Demonstrate session continuity for APC Par_2 Par_3

Req-Mob-S70 Req-Mob-S78

Obj_5 Validate the performance of TCP Par_1 Par_3 Par_4

Req-Net-S109

Table 4-5: Test-bed demonstration objectives

Table 4-6 shows the mapping of WP3 network functionalities to objectives both for the simulation (D16) and laboratory (D17) trials to highlight the correspondence. A functionality is not addressed by simulation and/or laboratory trials if the corresponding field is left empty.

Functionality D16 objectives addressed

D17 objectives addressed

QoS and traffic management: QoS architecture, scheduling, queuing, congestion control

Sim_Obj_06 Obj_2, Obj_3

Link selection Sim_Obj_07, Sim_Obj_10

Obj_1

Transport layer design and optimisation (PEPs) Sim_Obj_08 Obj_5

Load balancing Sim_Obj_09

Route optimisation for network mobility (NEMO RO) Sim_Obj_05

Local, network based mobility (NEMO) and/or global, node based mobility (NETLMM)

Sim_Obj_01, Sim_Obj_02, Sim_Obj_04, Sim_Obj_10

Obj_4

Multihoming

Inter Satellite Link (ISL) routing

Aeronautical mobile ad-hoc networks (Aeronautical MANETs)

Adaptation of IEEE 802.21 for media independent handover signalling between data links and network entities

Sim_Obj_03, Sim_Obj_10

Node vs. network initiated handover

Security: Thread analysis and risk assessment, Security objectives, requirements and architecture, Security service options, mechanisms and solutions

Table 4-6: Mapping of Functionalities to Objectives



5 Definition of Demonstration Scenarios

5.1 Network Architecture to be Demonstrated

The network architecture that NEWSKY laboratory trials will emulate is depicted in Figure 5-1. The actual test-bed network architecture is defined in section 7. In terms of access link, the network comprises two different link types, namely a satellite link and one or two terrestrial link technologies. To represent an architecture that could realistically be implemented today, the picture also captures the dual network (IPv6 and IPv4) situation, as the satellite network is based on IPv4; there is currently no IPv6 based satellite network working available for the test-bed.

Figure 5-1: Network architecture

Figure 5-1 shows the basic nodes based on their functionality from mobility perspective, and the location where they are located in the network. In the laboratory, however, some of the functionalities are implemented in virtual environment to reduce the need for real physical computer deployment. For simplicity, however, here we will stick to the conceptual representation of the network, and omit the discussion on how it is actually implemented.

The entities in the network are defined in detail in [2], some of which are explained in the following:

Mobile Router (MR): manages the mobility (all MIPv6 related signalling) for all nodes inside the airborne mobile network,



Home Agent (HA): a router on the home link with which the MR registers its current care-of-address, intercepts packets destined to MR’s home address while it is away from home,

Access Routers (AR): the default router in the visited/foreign network, provides care-of-address to the MR,

Correspondent Node (CN): the peer node with which the node inside the mobile network is communicating.

5.2 Scenarios for Validation through Demonstration

As explained in section 4, the laboratory demonstration will address the NEWSKY mobility functionality (see 4.1), a number of benefits of the NEWSKY system (see 4.2) and will validate the technical requirements listed in 4.3. This will be achieved through three scenarios:

Scenario 1: MobileIPv6/NEMO Functionality

Scenario 2: Handover Due to Link Unavailability

Scenario 3: Handover Due to Flight Phases and Operational Preferences

Even if NEWSKY deliverable D14 [21] identifies four different types of handovers they could be grouped into two general cases, represented in scenarios 2 and 3. This will be explained in more detail in subsections 5.2.2 and 5.2.3. The different types of HOs identified in D14 are shown in Figure 5-2 and recalled in the following:

1. Intra-Access Network (AN) Handover (especially for continental flights)

2. Intra-technology/Inter-AN Handover due to limitation of an access network to a certain country

3. Inter-technology/Inter-AN Handover due to link deterioration (could either be due to coverage limitation or link failure) for inter-continental flights

4. Inter-technology/Inter-AN Handover due to airline preferences and unavailability of preferred links in certain regions



Intr

aIn

ter

Figure 5-2: Categorisation of handover

As the focus of NEWSKY is on layer 3 and 4 of the protocol stack, the trials will mainly address layer 3 HO, with emphasis to global mobility solution, i.e., Mobile IPv6 and its extensions. Table 5-1 maps the relationship between the HO types of D14 and the scenario proposed in this document.

Scenario

Type of HO 1 2 3

1

2

3 x x

4 x x

Table 5-1: Mapping of scenarios to different types of handover

5.2.1 Scenario 1: MobileIPv6/NEMO Functionality

First of all, the basic functionalities of MIPv6 and NEMO as the chosen protocol to provide mobility will be tested in the context of aeronautical communications. In this scenario, HO will be performed in a generic way without considering any specific criteria. The main objective is to understand and explore the features of implementation of MIPv6 and NEMO basic support, and that they are installed and configured properly.



Network traces will be collected to analyze the signalling processes that take place, e.g.:

Binding Update (BU) and Binding Acknowledgment (BACK)

IPSec to secure signalling and data messages

MIPv6 return routability procedure for route optimization in the case of node (instead of network) mobility (HoTI, CoTI, HoT, CoT)

5.2.2 Scenario 2: Handover Due to Link Unavailability

This scenario is representative of an inter-access network handover, due to either limitation of an access network in a certain country or because of link deterioration. In this scenario, link availability is considered as the sole factor to trigger HO. As an example, consider an aircraft flying to ORP from ENR domain, and needs to handover to satellite due to unavailability of other links. The link unavailability may be either due to:

move in the coverage (e.g. ENR to ORP), or

link failure (e.g. base station failure), all traffic is switched to another link.

In both cases, IPv6 protocol will produce the same indication (access router can not be reached via router discovery protocol, or there is no router advertisement received), and thus both cases will not be further differentiated.

5.2.3 Scenario 3: Handover Due to Flight Phases and Operational Preferences

When entering TMA domain from ENR/ORP as example, most likely the satellite link will still be available. Yet for some other reasons (cost, QoS, etc.) it might be preferable to switch to terrestrial link.

Due to the simultaneous availability of several networks, a selection algorithm is needed to choose the best link according to some criteria. This problem is addressed in NEWSKY WP3.1. In the lab demonstration the module and interface to execute HO will be provided. This would require some modifications to the NEMO implementation code, in particular at the point where the movement detection and handover decision is made. According to some link selection algorithms, a trigger will be set to perform the desired handover.

As alternative to the HO decision module, without introducing the complexity of HO decision making process, a HO scheme based on geographical location is taken for demonstration purpose. A flight route will be simulated, and at a specified geographical position a HO event is triggered.

5.3 Demonstration Strategy

Table 5-2 to Table 5-4 map the requirements, functionalities, and benefits of NEWSKY system with the methods to address them in a lab environment.



Requirement Id. How it is addressed

Req-Flex-S32 A link failure will be simulated by switching off one access router, and leave another router on. For instance the WiMAX AR is turned off, whereas the LDACS AR is left on. MIPv6/NEMO mechanism enables the re-routing of the traffic transparently to the application.

Req-QoS-S38 A typical basic Linux mechanism (e.g., netem-based link emulation) to prioritize and queue traffic will be employed at the emulated airborne router (mobile router).

Req-QoS-S39 Same as above

Req-QoS-S40 The message priorities will be mapped to the Linux kernel priority map. Linux kernel reads Type of Service (ToS) field of an IP packet and put the packet in a priority-queue scheduler before sending it to the network. A rule can be setup to map the ToS value to the kernel queue class.

Req-QoS-S43 Same as above

Req-Mob-S70 Session continuity is guaranteed through MIPv6/NEMO protocol.

Req-Mob-S78 The baseline for signalling latency is determined by basic MIPv6 mechanism. Extensions to improve the HO delay will not be demonstrated as it requires a stable protocol implementation which at this point is not yet available.

Req-HO-S85 MIPv6/NEMO is the baseline for handover performance.

Req-Net-S109 End-to-end data transport is provided via TCP protocol.

Table 5-2: Demonstration strategy for the selected NEWSKY technical requirements

Functionalities How is it addressed

HA registration Make one of the access routers (AR) send router advertisements (RA), and inhibit the RA from the other AR. This way the MR will assume that the network has changed, construct new CoA using stateless auto-configuration mechanism, and send Binding Update (BU) to the HA. The HA will then reply with a Binding Acknowledgment (BACK) message. Collect traffic traces in both MR and HA.

CN registration and RR procedure

The CN needs to have MIPv6 support. Enable the MIPv6 Route Optimization option in both MR and CN. In this case the MR does not manage the mobility of all nodes inside the mobile network.

Network mobility Show that it is sufficient to have only the MR manages the mobility of all MNN in the mobile network.

Table 5-3: Demonstration strategy for the selected NEWSKY functionalities



Benefit Id. Validation method

B01 Show that WiMAX (currently working in 3.4-3.6/5.8 GHz band, potentially modified to work at AM(R)S band), L-DACS-1, and BGAN which works in L-band can be flexibly integrated. And in principle there is no limitation on which frequency band the underlying link technology works, therefore the overall communication capacity of the system is increased.

B02 Show that network handover can be done when moving from oceanic (where only satellite is available) to TMA where at the same time both L-DACS-1 and satellite are available. Network performance can be optimized since lower-delay, higher-bandwidth L-DACS-1 link can be used whenever it is available.

B03 Show there is no interruption of service when L-DACS-1/WiMAX link fails (base station failure) and all traffic is re-directed to satellite link, or vice versa.

Compare packet delivery in one situation with 2 or 3 links available for handover (not all used simultaneously) for one type of message with respect to one situation with only one link available when one links is temporarily not available or fails.

B04 Simulate geographical coverage of L-DACS-1, WiMAX, and satellite link, where L-DACS-1 and WiMAX is limited to some distance near landmass, and satellite is available everywhere including oceanic areas.

Show that when moving outside L-DACS-1 coverage, there is no interruption of service since the traffic can be handed over to satellite.

B06 Cost effectiveness is not shown explicitly, however the use of COTS component is, in particular the use of Mobile IPv6 as the underlying protocol to enable Layer 3 Handover.

B10 Show that one particular service (e.g., VoIP or file transfer) can be run on top of both satellite and terrestrial links without interruption of service, even when the link changes during one call session.

B11 Show that traffic from one particular service (e.g., VoIP or file transfer) can be handed over through different link technologies transparently to the user.

Table 5-4: Selected NEWSKY benefits and proposed validation method



6 Scenarios Coverage

To make sure that all requirements, benefits and objectives are actually addressed as indicated in Section 4, we provide a mapping between all of them and the demonstration scenarios in the three tables below.

Scenario

Requirement Id. 1 2 3

Req-Flex-S32 x

Req-QoS-S38 x x

Req-QoS-S39 x x

Req-QoS-S40 x x

Req-QoS-S43 x x

Req-Mob-S70 x x x

Req-Mob-S78 x x x

Req-HO-S85 x x x

Req-Net-S109 x x x

Table 6-1: Mapping of scenarios to requirements

Scenario

Benefit Id. 1 2 3

B01 x

B02 x

B03 x

B04 x

B06 x x x

B10 x x

B11 x x

Table 6-2: Mapping of scenarios to benefits

Scenario

Objective Id. 1 2 3

Obj_1 x

Obj_2 x x

Obj_3 x x

Obj_4 x x x

Obj_5 x X

Table 6-3: Mapping of scenarios to objectives



7 Laboratory Network

The goal of this section is to define network architecture of the laboratory test-bed and its components. This architecture will allow running the necessary demonstrations to show the scenarios defined in the previous section.

7.1 Laboratory Network Architecture

Figure 7-1 shows the laboratory network architecture. It is the “laboratory version” of Figure 5-1, in particular to show the different components involved in the lab network.

The satellite link will be based on Inmarsat BGAN system; the terrestrial link will be an emulated B-AMC/L-DACS-1 link and potentially, a WiMAX link will also be used.

The descriptions of each of the components are given in the following subsections.

Figure 7-1: Laboratory network architecture

7.2 Laboratory Network Components

7.2.1 Dual-Stack IPv4/IPv6 Router

The de facto standard used in the Internet at the moment is still IPv4. The Inmarsat network as the chosen satellite technology for lab demonstration is, in fact, an IPv4 network. Thus we need a mechanism to transport IPv6 packets, in particular the ones related to MIPv6 and NEMO signalling, through IPv4 network.



Several approaches exist for IPv4 network traversal in MIPv6. An IETF draft has been proposed to extend MIPv6/NEMO to allow IPv4 Care-of Address (CoA) registration [12]. Another approach is to use tunnelling or address translation between the MR and a dual-stack IPv6/IPv4 router which acts as an interconnection point between the two networks.

The first approach requires modification of the basic MIPv6/NEMO implementation, and the implementation available from [14] is relatively new and thus unstable. The second approach is more stable from implementation point of view, although it is less efficient in terms of message header overhead.

Feasibility tests of the second approach using Layer 2 Tunnelling Protocol (L2TP) in UMTS network has been carried out and documentation exists for instance in [13] and will therefore be the preferred implementation way for the test-bed.

Several implementation possibilities can be considered1:

Implementation possibility 1: A/C moves from IPv6 to another IPv6 network. For this a dual stack IPv4/IPv6 router is not needed, and MIPv6/NEMO protocol will run with its default procedure.

Implementation possibility 2: A/C moves from IPv6 to IPv4 network. For the MIPv6/NEMO signalling to work, we propose the use of a node in the Internet to act as an endpoint for IPv6-in-IPv4 tunnel. We refer this node as the AR2 in Figure 5-1. When the MR detects that it moves to an IPv4 network, it tries to establish a tunnel to this node. AR2 has a pool of IPv6 address subnet that it advertises in the tunnel interface such that the MR may perform IPv6 stateless autoconfiguration to construct IPv6 CoA. Once the tunnel is established, the MIPv6/NEMO signalling can then run as in the normal, complete IPv6 network, case. Currently a solution based on Layer 2 Tunnelling Protocol (L2TP) [22] is deployed, as it is the only tunnel interface supported by Nautilus6 MIPv6 implementation.

Implementation possibility 3: A/C moves from IPv4 to IPv6 network. With this scenario, the MR is able to construct IPv6 CoA and register the address to the HA. Thus it is quite similar to the first scenario, with an exception that the MR needs to release the IPv6-in-IPv4 tunnel that it created when it entered the IPv4 network.

Implementation possibility 4: A/C moves from IPv4 to IPv4 network. Since the old and new access networks are both IPv4, we will consider this type of mobility as out of the scope of the lab test-bed and thus will not be discussed further.

7.2.2 Satellite Communications Modem

In the lab test-bed real satellite link will be used based on Inmarsat BGAN (Broadband Global Area Network). BGAN is a service launched by Inmarsat beginning in 2005 via the fleet of its 4th generation I4 satellites. The coverage of the geostationary (GEO) satellite constellation is illustrated in Figure 7-2.

1 The possibilities mentioned here are implementations related. They are applicable to all scenarios mentioned in Section 5.2, e.g., the available links mentioned in scenario 3 from Section 5.2 may be both IPv4, both IPv6, or one of them is IPv4 and the other is IPv6.



Figure 7-2: Inmarsat I4 satellite coverage [6]

The satellite terminal to be used in the demo is the Thrane&Thrane Explorer 300.

Figure 7-3: Thrane & Thrane Explorer 300

The terminal can be configured either using the small panel at the top of the terminal, using an application software from Inmarsat called BGAN LaunchPad (Microsoft® Windows® only), or via the web interface. The terminal also provides a set of AT-commands to enable users to develop their own software to perform automatic configuration.



Figure 7-4: Top view of the Thrane & Thrane Explorer 300, highlighting the configuration panel.

Figure 7-5: Thrane & Thrane Explorer 300 LaunchPad user interface



Figure 7-6: Thrane & Thrane Explorer 300 configuration via web interface [7]

For data communication the terminal uses Ethernet (RJ-45) interface to connect to the PC, and can be configured either in modem or router mode. Once the terminal is logged-on it will get a public IPv4 address from the network. When modem mode is selected, the connected PC behind the satellite terminal will use the public IPv4 assigned from the network, whereas when router mode is selected it gets a private IPv4 address assigned by the terminal (NAT mode).

The usage of the satellite bandwidth is managed through different traffic classes. There are two types of class that could be opened for data communication: streaming and background class. The streaming class gets higher priority and ensures that constant data rate is available to the user. The Explorer 300 terminal is capable of providing streaming class connections up to 64 kbps. Users are charged based on the time spent on the connection. The rest of the satellite channel capacity is assigned to the background class. Here the available bit rate may vary, and the user is charged based on the volume of data transferred on the satellite link.

7.2.3 Terrestrial Communication Links

7.2.3.1 B-AMC / L-DACS-1

A promising candidate for future long range air-ground communications is an evolution of B-AMC (Broadband Aeronautical Multi-Carrier Communication System) towards L-DACS-1



(L-band Data-link Aeronautical Communications System), as described in NEWSKY Deliverable D09, “Technology Screening and Characterization for Integration in the NEWSKY Network” [19]. A protocol emulator will represent the characteristics of B-AMC for both Physical Layer (in terms of Bit Error Rate) and Data Link Layer (in terms of delay and throughput) for the test-bed. As the B-AMC protocol emulator has to act as access router, it will advertise a unique local unicast IPv6 address prefixes as well. In such a way stateless address auto-configuration becomes possible. The emulation of the wireless link will take place via a common Ethernet connection.

The B-AMC emulator itself connects to the dual stack IPv4/IPv6 Mobile Router on the (emulated) airborne side and to the TGS Local Area Network (LAN) on the Ground Station side. Based on this, both routers are able to decide whether they are going to use the (real) satellite communication link or the (emulated) terrestrial communication link.

Details about the B-AMC Physical Layer and Data Link Layer can be found in [15], whereas performance characteristics are published in [16].

7.2.3.2 WiMAX

In addition to the B-AMC emulator, DLR also intends to purchase IEEE 802.16 WiMAX equipment that can be integrated into the laboratory test bed as a real wireless link. Since WiMAX is a likely candidate for a future aeronautical data link in the airport domain, its integration in the test bed would allow the NEWSKY protocols to be tested in a very realistic environment.

WiMAX base stations and terminals are available as COTS equipment and can be connected to the test bed routers via Ethernet. The base station is attached to the TGS network lab, and the terminal is attached to the mobile router, similarly to the Inmarsat BGAN terminal. Products such as the Airspan MicroMax support both IPv4 and IPv6 and operate both in licensed (3.4 - 3.6 GHz) and unlicensed (5.8 GHz) spectrum.

Currently, DLR is searching for suitable products and intends to buy the selected equipment before the end of 2008.

7.3 Representative Applications

This section describes the applications which will run on top of the lab network environment. ATS and AOC services will be emulated using a custom IP packet generator to generate messages similar to the ones in COCR [1], whereas APC services will be emulated using common APC applications such as voice call using VoIP, and web browsing or file download.

7.3.1 Short ATS/AOC Messages

The aim of the message generator is to have a generic way to generate application layer messages based on specification of different future ATM messages in COCR [1]. The generator will basically specify the message sizes, frequency of delivery, if a message should run over TCP or UDP, etc.

7.3.2 Voice over IP (VoIP)

VoIP services implementation will be based on Session Initiation Protocol (SIP). The user uses SIP user agents (UA), which may be in the form of software running in a PC (soft phone), or a dedicated IP phone.



Direct end-to-end voice call between two VoIP clients will be demonstrated. To simulate to some extent a real VoIP system and to enable access to normal PSTN/PLMN telephone numbers, not only between SIP UAs, a SIP proxy server (and eventually a gateway for interconnection with PSTN/PLMN) will be implemented. A simplified sequence of SIP signalling between two end users mediated by a proxy server is illustrated in Figure 7-7.

Figure 7-7: SIP signalling

The details of SIP operation can be found in [8].

7.3.3 HTTP and FTP server

In addition to the short COCR messages as in Section 7.3.1, an FTP server will be set up to emulate TCP-based file transfer corresponding to potential future ATS/AOC/APC services that require larger data transfer. Running these services over the test-bed has the impact that the temporary interruption due to handover can be more easily observed compared to when only short messages are transferred.

An HTTP server will be used to emulate web-based applications, for instance a web portal for APC service. Alternatively, any website in the Internet could be used to simulate web access.

In the lab demo open source Linux-based FTP and HTTP servers will be used, for instance Apache HTTP server [9] and vsftpd [10].



7.4 Implementation Aspects

7.4.1 Scenario 1

The demo will use implementation of MobileIPv6 and NEMO basic support protocol from the Nautilus6 project [11]. The lab demonstration will not attempt to demonstrate extensions of NEMO for route optimization, as there is currently no generally acceptable solution (and thus implementation) for this. The main effort in the demo preparation will be concentrated on integrating the protocol implementation, which mainly involves setting up the computers and virtual machines, installing and configuring other software needed to support the protocol, kernel compilation, and feature testing, and not on implementing or adding features to the protocol implementation itself.

7.4.2 Scenario 2

In the lab demonstration this situation can be created by switching off the L-DACS/WiMAX link, and keep the satellite link on, or vice versa. Alternatively, one access router (AR) could be setup not to send any router advertisement, and if the MR gets router advertisements from the other AR, it will assume that the network has changed and perform MIPv6/NEMO procedure.

7.4.3 Scenario 3

Figure 7-8 depicts the graphical user interface (GUI) showing a simulated flight from Paris to Atlanta, assuming great circle route for simplicity. For demonstration purpose, two circles are drawn to emulate coverage of L-DACS-1 link. It is assumed that satellite is available everywhere. A handover from satellite to L-DACS-1 can be triggered when at a pre-determined geographical coordinate near continental US, where both satellite and L-DACS-1 are available.



Figure 7-8: Graphical user interface (GUI) illustrating a flight route and communication link handover

----------- END OF DOCUMENT -----------

Laboratory Test-Bed for Concept Validation · 2015-07-03 · NEWSKY - Networking the Sky for...

Documents

Transcript of Laboratory Test-Bed for Concept Validation · 2015-07-03 · NEWSKY - Networking the Sky for...