stakeholders who have been involved, logically from the start by European actors (through the Single European Sky for ATM Research (SESAR) project) in the development of the SWIM requirements, prototypes, roadmaps and implementation plans.
Figure 3.3. Net centric information viewpoint (source: www.sesarju.eu)
the Future Radio System document provides a comprehensive description for each service [EUR 07a].
When multilink functionality is available, switching between data link systems in order to send operational data depends on several criteria. First, the capabilities and performances offered by a given data link system in order to fulfill the required QoS for an ATS service have to be considered. The second criterion is the need for load balancing in some scenarios. For instance, if a link becomes congested, it may be necessary to share the packet load with another link in order to minimize end-to-end latency and increase service availability. The flight airspace, where data link is operational, is also an important parameter to be taken into account. Table 3.1 illustrates the applicability of the MLOC according to the flight phase and corresponding airspace. The scope of the MLOC is applicable to all airspace areas except Oceanic Remote Polar (ORP) regions where only satellite is available. Also, transitions between airspaces are also considered inside the scope of the MLOC (i.e. when an aircraft is moving from one airspace to another).
Considering the heterogeneity of the criteria mentioned above, the link selection procedure could be a tedious task. Several studies have been conducted in order to match these criteria together and select the best data link system. For instance, multiple attribute decision-making methods and fuzzy logic have been used quite often in the literature, as in [CHR 09].
However, the process of switching between the available data links, known as Vertical Handover (VHO), has not yet been addressed. VHO issues in the MLOC and potential solutions are described in section 3.2.2.
Flight phase Departure Flight operation Arrival
Airspace APT TMA ENR ORP TMA APT
Available data links
AeroMACS L-DACS Satellite
L-DACS Satellite
L-DACS Satellite
Satellite L-DACS Satellite
AeroMACS L-DACS Satellite Table 3.1. Multilink concept applicability
3.2.2. Vertical handover in MLOC
In wireless communications, two types of handover procedures usually exist: horizontal and vertical handover. Horizontal handover (HHO) refers to
the process of transferring data from one cell to another, inside the same access core network (i.e. intrasystem handover). Vertical handover (VHO) involves handover between different access technologies when they are available, but the objective remains the same: transparently guarantee the session continuity from a final user point of view. While HHO decisions are usually based on performance parameters specific to one access technology, such as the Received Signal Strength (RSS), they are no longer sufficient in a network composed of several access subnetworks. Due to the heterogeneity of the Future Communication Infrastructure (FCI), VHO is simultaneously the solution and the next big challenge, as it requires comprehensive standards to make seamless handover between these different access networks a reality. Needless to say that HHO remains a requisite inside the same access networks (i.e. L-band Digital Aeronautical Communication System (L-DACS), Aeronautical Mobile Airport Communication System (AeroMACS) and Satellite), while a mobile node is moving from one base station coverage area to another.
A typical VHO scenario derived from the MLOC is composed of three different steps. First step is data link log-on, where each available data link system is contacted by the multilink system in order to establish a connection. When a data link equipment receives a log-on request, it responds by informing the multilink system of its link status. The second step is data link selection: the multilink system selects a data link that satisfies the required QoS level and the criteria discussed in section 3.2.1.
Then, data transmission begins using the selected data link. After a certain time, a VHO to another available data link could be required. VHO can be triggered in several cases under circumstances such as degradation or failure of the used data link. A set of potential VHO scenarios have been discussed in the scope of SESAR WP 15.2.4 ETs, details can be found in [SES 11].
VHO has already been considered for the upcoming generation of wireless mobile networks that integrate different access technologies, such as WiFi, WiMAX, Universal Mobile Telecommunications System (UMTS) and recently Long-Term Evolution (LTE). The IEEE 802.21 working group has been created to address VHO-related issues by providing a Media Independent Handover (MIH) framework that provides a generic and unified interface between the link layers and upper layers. This middleware allows the exchange of information and commands between different devices involved in the handover decision and execution procedures. In order to manage the specifications of each technology, MIH maps this generic
interface to a set of media independent Service Access Points (SAPs). The role of these SAPs is to collect information and control the data links behaviors during VHO. The standard categorizes them as the following:
– MIH_SAPs for communication between the MIH users and MIH function (MIHF);
– MIH_LINK_SAPs for communications between the MIHF and link layer technologies;
– MIH_NET_SAPs for communications between two different MIHF entities (i.e. a local and remote MIHF, each one relevant to a different network node).
The MIH framework defines three main services through MIH_SAPs:
MIH Event, Command, and Information Services (respectively, MIES, MICS and MIIS). MIES indicates link state changes. The notifications provided by MIES can be predictive (e.g. LINK_GOING_DOWN is a predictive event) or reactive (e.g. LINK_UP). MICS allows higher layers to control the physical and data link layers. GET_LINK_PARAMETERS is an example of a command issued by handover management modules at higher layers in order to gather information required for the handover process.
Finally MIIS provides information about the available networks, operators, and Point of Attachments (PoAs), such as access points or base stations.
These information are gathered and stored into an Information Server (IS), usually connected to both home and visited access networks.
Using the IEEE 802.21 MIH framework as a COTS product within the scope of the FCI is technically feasible and could resolve VHO issues related to the future data link systems, however, several considerations have to be taken into account beforehand. First, MIH_LINK_SAP implies that technology-specific SAPs have to be implemented within the protocol stack of a link layer technology in order to allow the MIHF to control it.
Consequently, these SAPs have to be developed separately for L-DACS, AeroMACS and Satellite. The second challenge is to adapt the layer 2 triggers and event notifications with the link selection criteria discussed in section 3.2.1. Indeed, besides link state events that are usually expressed in MIES, regulatory aspects imposed in a given airspace should be integrated, which means that communication with mobility upper layers has to be integrated in the MIHF function. Security has to be built in the MIH functions, as it was not originally integrated in the IEEE 802.21 standard.
Nevertheless, the security task group has developed security extensions and mechanisms under the IEEE 802.21a amendment in order to provide confidentiality for MIH messages and authentication to the neighboring network before handover initiation. The next challenge that rises here is how to reduce the impact of such operations (which are based on asymmetric cryptography), especially that of the latency of media access authentication and key establishment during handover. Indeed, considering the stringent latencies and availabilities of the RCPs discussed in Chapter 2, a trade-off between security and QoS has to be found.
Figure 3.4 illustrates a potential protocol stack of a node employing the MIH framework in the scope of the FCI. The MIHF provides services to MIH users through a single MIH_SAP and obtains services from the lower layers through three MIH_LINK_SAPs, where each one is dedicated to a data link system. The exchanges between the local MIHF and a remote MIHF occur using the MIH_NET_SAP interface, which provides transport services over the data plane on the local node. For all transport services over layer 2, the MIH_NET_SAP uses the primitives specified by the MIH_LINK_SAP.
Figure 3.4. MIHF architecture model and MIH services for the FCI