Laboratory Test-Bed for Concept Validation

Transcription

1 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 G (Innovative ATM Research) Contract Number Project Duration 26/02/ /09/2009 (30 months) Project Coordinator Project Partners German Aerospace Center (DLR) 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 Contributors Eriza Fazli, TriaGnoSys GmbH 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 Project co-funded by the European Commission within the 6th Framework Programme

2 DOCUMENT HISTORY Version Date Modified Contents Implemented by /08/08 First issue E. Fazli /12/08 Revisions according to comments from EC and Eurocontrol E. Fazli Laboratory Test-Bed for Concept Validation Page: I

3 Contents 1 Executive Summary General Acronyms and Abbreviations References Introduction Overview of the NEWSKY Project Scope of the Document and Validation Approach Structure of the Document Laboratory Demonstration Objectives Network Functions Addressed Technical Requirements to be Validated through Demonstration NEWSKY Benefits Addressed Definition of Evaluation Parameters Overview of Validation Objectives Definition of Demonstration Scenarios Network Architecture to be Demonstrated Scenarios for Validation through Demonstration Scenario 1: MobileIPv6/NEMO Functionality Scenario 2: Handover Due to Link Unavailability Scenario 3: Handover Due to Flight Phases and Operational Preferences Demonstration Strategy Scenarios Coverage Laboratory Network Laboratory Network Architecture Laboratory Network Components Laboratory Test-Bed for Concept Validation Page: II

4 7.2.1 Dual-Stack IPv4/IPv6 Router Satellite Communications Modem Terrestrial Communication Links B-AMC / L-DACS WiMAX Representative Applications Short ATS/AOC Messages Voice over IP (VoIP) HTTP and FTP server Implementation Aspects Scenario Scenario Scenario Illustrations Figure 3-1: WP4.5 relations to other work packages Figure 3-2: Overview of tables mapping the different requirements, objectives, and scenarios presented in this document Figure 5-1: Network architecture Figure 5-2: Categorisation of handover Figure 7-1: Laboratory network architecture Figure 7-2: Inmarsat I4 satellite coverage [6] Figure 7-3: Thrane & Thrane Explorer 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] Figure 7-7: SIP signalling Figure 7-8: Graphical user interface (GUI) illustrating a flight route and communication link handover Laboratory Test-Bed for Concept Validation Page: III

5 Tables Table 4-1: Mapping of NEWSKY system requirements to be validated in the laboratory test-bed, with the corresponding user requirements Table 4-2: Technical requirements not addressed in the test-bed Table 4-3: NEWSKY KPAs and benefits addressed in the Demonstration Table 4-4: Evaluation criteria Table 4-5: Test-bed demonstration objectives Table 4-6: Mapping of Functionalities to Objectives Table 5-1: Mapping of scenarios to different types of handover Table 5-2: Demonstration strategy for the selected NEWSKY technical requirements Table 5-3: Demonstration strategy for the selected NEWSKY functionalities Table 5-4: Selected NEWSKY benefits and proposed validation method Table 6-1: Mapping of scenarios to requirements Table 6-2: Mapping of scenarios to benefits Table 6-3: Mapping of scenarios to objectives Laboratory Test-Bed for Concept Validation Page: IV

6 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. Laboratory Test-Bed for Concept Validation Page: 1-1

7 2 General 2.1 Acronyms and Abbreviations AH AOC APC AR ATC ATM ATS BACK BGAN BU CDM CN CoA CoT CoTI COTS ENR ESP FTP GEO GW HA HO HoA HoT HoTI HTTP IP IPSec L2TP LDACS Authentication Header Airline Operational Control Airline Passenger Communications Access Router Air Traffic Control Air Traffic Management Air Traffic Service Binding Acknowledgment Broadband Global Area Network Binding Update Collaborative Decision Making Corresponding Node Care-of Address Care-of Test Care-of Test Init Commercial-Off-the-Shelves En Route Encapsulating Security Payload File Transfer Protocol Geostationary Gateway Home Agent Handover Home Address Home Test Home Test Init Hypertext Transfer Protocol Internet Protocol IP Security Layer 2 Tunneling Protocol L-band Digital Aeronautical Communication System Laboratory Test-Bed for Concept Validation Page: 2-1

8 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 Laboratory Test-Bed for Concept Validation Page: 2-2

9 2.2 References [1] Communications Operating Concept and Requirements for the Future Radio System, COCR version 2.0, Eurocontrol/FAA Future Communication Study, May [2] Johnson, D., Perkins, C., and Arkko, J., Mobility Support in IPv6, RFC 3775, June [3] Devarapalli, V. et al., Network Mobility (NEMO) Basic Support Protocol, RFC 3963, January [4] Simpson, W., IP-in-IP Tunnelling, RFC 1853, October [5] Kent, S., IP Encapsulating Security Payload (ESP), draft-ietf-ipsec-esp-v3-09.txt (work in progress), September [6] WWW-Page. (last visited May 2008): only=false. [7] Thrane & Thrane EXPLORER 300 User Manual, can be found at %20manuals/LM/EXPLORER%20300/e300%20user%20manual%20tt% d.pdf.ashx. [8] Rosenberg, J., SIP: Session Initiation Protocol, RFC 3261, June [9] Apache web server, WWW-Page: [10] FTP server, WWW-Page: [11] WWW-Page. (last visited May 2008): [12] Soliman, H., Mobile IPv6 Support for Dual Stack Hosts and Routers, draft-ietfmext-nemo-v4traversal-04.txt, June [13] WWW-Page (last visited June 2008): [14] WWW-Page. (last visited June 2008): [15] B-AMC project, System Specification Including Standardization and Certification Considerations, report D-3, Issue 1.0, MC%20Project%20Deliverable_D3_V10.pdf [16] B-AMC project, Expected B-AMC System Performance, report D-5, Issue 1.1, MC%20Project%20Deliverable_D5_V11.pdf [17] Validation Strategy, Deliverable D01.5 of the NEWSKY Project, December [18] NEWSKY Operational Requirements Document, Deliverable D08 of the NEWSKY Project, January [19] Technology Screening and Characterization for Integration in NEWSKY Network, Deliverable D09 of the NEWSKY Project, April Laboratory Test-Bed for Concept Validation Page: 2-3

10 [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 [25] NEWSKY Design Document, Deliverable D11 of the NEWSKY project, September Laboratory Test-Bed for Concept Validation Page: 2-4

11 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. Laboratory Test-Bed for Concept Validation Page: 3-1

12 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 realworld 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 Laboratory Test-Bed for Concept Validation Page: 3-2

13 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. Table 4.5 Validation Objectives Table 4.5 Functionalities Table 5.3 WP3 Network Functionalities Table 4.5 Parameter, Table 4.4 Table 6.3 Requirements Tables 4.1, 4.2, 5.2 WP2.3/D10 System Requirements all Scenarios Table 6.1 WP2.1/D08 Application Scenarios Table 6.2 Benefits, Tables 4.3, 5.4 WP0/D01.5 KPAs and high level NEWSKY benefits Figure 3-2: Overview of tables mapping the different requirements, objectives, and scenarios presented in this document Laboratory Test-Bed for Concept Validation Page: 3-3

14 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. Laboratory Test-Bed for Concept Validation Page: 4-1

15 System Requirement ID System Requirement Description User Requirement 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) - 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. [U106] [U29] The NEWSKY system shall allocate the highest class of service to network management services. [COCR2] (This is consequence of 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). 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). Laboratory Test-Bed for Concept Validation Page: 4-2

16 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]. n.a. (NEWSKY internal) - 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. [U25] [U26] The NEWSKY system shall implement different internal classes of services (CoS) corresponding to different QoS requirements. [NEWSKY-DOW] [COCR2] [UserMeeting ] The NEWSKY system shall allow to map the different applications services to the required CoS. [NEWSKY-DOW] [NASA] [COCR2] [UserMeeting ] Req-Mob-S70. The NEWSKY system shall support session continuity. n.a. (NEWSKY internal) - 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. [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] 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-toend services at the application layer, which is determined by the latency of all lower layers. Laboratory Test-Bed for Concept Validation Page: 4-3

17 Req-HO-S85. Req-Net-S109 The NEWSKY system shall provide the means to perform handovers as efficiently as possible. Consecutively, packet loss during a handover shall be minimized. The NEWSKY ATN/IP transport layer solution should provide reliable end-toend data transport between IP hosts (end-systems). Note: Not all IP end host may need E2E reliable transport. n.a. (NEWSKY internal) n.a. - - Table 4-1: Mapping of NEWSKY system requirements to be validated in the laboratory test-bed, with the corresponding user requirements Laboratory Test-Bed for Concept Validation Page: 4-4

18 Requirement Id. Requirement Description Why is not addressed Req-Flex-S31 Req-QoS-S46 Req-QoS-S57 Req-QoS-S58 Req-Mob-S79 Req-HO-S80 The NEWSKY system shall provide mechanisms to allocate the resources from different subnetwork efficiently in order to optimise capacity and effective performance. The NEWSKY network shall always select the link technology CoS that can provide the QoS required by this service or a higher QoS. 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. 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 subnetworks). 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 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-beforebreak handover strategies and for simultaneous packet transmission over different paths. Not demonstrated because it is more suitable for simulation Automatic link selection based on QoS is more appropriate for simulation and will not be demonstrated (no scenario is proposed to show this). QoS figures are more appropriate to be measured in simulation as they would require many tests to generate sufficient statistics. Same as Req-QoS-S57 Same as Req-QoS-S57 As currently there is no stable implementation to support simultaneous connection to many access networks, this requirement will not be validated in the lab testbed. 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]: Laboratory Test-Bed for Concept Validation Page: 4-5

19 Benefit Id. Benefit Description KPA B01 The different communication links within NEWSKY cover Capacity 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. B02 B03 B04 B06 B10 B11 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. 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. The coverage of the overall system is increased since different communication systems with different application areas are combined, hence improving the safety. Commercial off-the-shelf (COTS) IP-based networking protocols are used whenever possible for a cost efficient realization. IPv6 is considered as baseline. 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. 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. Capacity Safety Safety Cost Effectiveness Efficiency, predictability, and flexibility 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 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: Laboratory Test-Bed for Concept Validation Page: 4-6

20 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. Obj_1 Description Demonstrate the ability of the NEWSKY network to handle failure of a terrestrial base station. Parameters to Measure Par_2 Par_3 Par_4 Requirements Addressed 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 Laboratory Test-Bed for Concept Validation Page: 4-7

21 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 Obj_4 Demonstrate session continuity for APC Par_2 Par_3 Obj_5 Validate the performance of TCP Par_1 Par_3 Par_4 Req-QoS-S38 Req-QoS-S39 Req-QoS-S40 Req-QoS-S43 Req-Mob-S70 Req-Mob-S78 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 QoS and traffic management: QoS architecture, scheduling, queuing, congestion control Link selection D16 objectives addressed Sim_Obj_06 Sim_Obj_07, Sim_Obj_10 D17 objectives addressed Obj_2, Obj_3 Obj_1 Transport layer design and optimisation (PEPs) Sim_Obj_08 Obj_5 Load balancing Route optimisation for network mobility (NEMO RO) Local, network based mobility (NEMO) and/or global, node based mobility (NETLMM) Multihoming Inter Satellite Link (ISL) routing Aeronautical mobile ad-hoc networks (Aeronautical MANETs) Adaptation of IEEE for media independent handover signalling between data links and network entities Node vs. network initiated handover Security: Thread analysis and risk assessment, Security objectives, requirements and architecture, Security service options, mechanisms and solutions Sim_Obj_09 Sim_Obj_05 Sim_Obj_01, Sim_Obj_02, Sim_Obj_04, Sim_Obj_10 Sim_Obj_03, Sim_Obj_10 Table 4-6: Mapping of Functionalities to Objectives Obj_4 Laboratory Test-Bed for Concept Validation Page: 4-8

22 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, Laboratory Test-Bed for Concept Validation Page: 5-1

23 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 and 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 Laboratory Test-Bed for Concept Validation Page: 5-2

24 Intra Inter 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 x x 4 x x Table 5-1: Mapping of scenarios to different types of handover 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. Laboratory Test-Bed for Concept Validation Page: 5-3

25 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) 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 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. Laboratory Test-Bed for Concept Validation Page: 5-4

26 Requirement Id. Req-Flex-S32 Req-QoS-S38 Req-QoS-S39 Req-QoS-S40 Req-QoS-S43 Req-Mob-S70 Req-Mob-S78 Req-HO-S85 Req-Net-S109 How it is addressed 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. 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). Same as above 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. Same as above Session continuity is guaranteed through MIPv6/NEMO protocol. 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. MIPv6/NEMO is the baseline for handover performance. End-to-end data transport is provided via TCP protocol. Table 5-2: Demonstration strategy for the selected NEWSKY technical requirements Functionalities HA registration CN registration and RR procedure Network mobility How is it addressed 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. 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. 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 Laboratory Test-Bed for Concept Validation Page: 5-5

27 Benefit Id. B01 B02 B03 B04 B06 B10 B11 Validation method Show that WiMAX (currently working in /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. 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, higherbandwidth L-DACS-1 link can be used whenever it is available. 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. 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. 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. 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. 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 Laboratory Test-Bed for Concept Validation Page: 5-6

28 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 Req-Flex-S32 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 x Scenario Benefit Id B01 B02 B03 B04 B06 x x x B10 x x B11 x x Table 6-2: Mapping of scenarios to benefits x x x Scenario Objective Id Obj_1 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 x x Laboratory Test-Bed for Concept Validation Page: 6-1

29 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 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. Laboratory Test-Bed for Concept Validation Page: 7-1

30 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 dualstack 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 considered 1 : 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 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 4 th generation I4 satellites. The coverage of the geostationary (GEO) satellite constellation is illustrated in Figure 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. Laboratory Test-Bed for Concept Validation Page: 7-2

31 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 ATcommands to enable users to develop their own software to perform automatic configuration. Laboratory Test-Bed for Concept Validation Page: 7-3

32 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 Laboratory Test-Bed for Concept Validation Page: 7-4

33 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 loggedon 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 Terrestrial Communication Links 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 Laboratory Test-Bed for Concept Validation Page: 7-5

34 (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] WiMAX In addition to the B-AMC emulator, DLR also intends to purchase IEEE 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 ( 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 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 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 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. Laboratory Test-Bed for Concept Validation Page: 7-6

35 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] 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]. Laboratory Test-Bed for Concept Validation Page: 7-7

36 7.4 Implementation Aspects 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 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 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. Laboratory Test-Bed for Concept Validation Page: 7-8

37 NEWSKY - Networking the Sky for Aeronautical Communications Figure 7-8: Graphical user interface (GUI) illustrating a flight route and communication link handover END OF DOCUMENT Laboratory Test-Bed for Concept Validation Page: 7-9