environments. Indeed, most of existing IP mobility protocols are still not deployed in any commercial network; they only exist on papers but are never used in a real context. Thus, the maturity of these mobile solutions still needs to be proven before being reused in an operational environment. Besides, coverage and high availability are very important requirements for data link communications, meaning that a massive implementation of ground stations supporting mobility has to be done.
The second issue concerns the transport layer. Service continuity is more or less supported by existing IP mobility protocols, since they have been designed to keep the Transport Control Protocol (TCP) sessions up during movement. However, routing-based and mapping-based protocols do not have the same complexity with regard to session continuity: while routing- based approaches do not need any further modification on the transport layer because of the use of fixed IP addresses, mobility has to be “hidden” somehow to the transport layer in mapping-based protocols by using a Home Address (HoA). Another possibility is to modify the used TCP protocol version on both ends so that end entities can switch from one IP address to another (when a handover occurs) to keep the session active.
Needless to say that this alternative is too expensive and in, some cases, could be unfeasible as not all existing systems (especially the ones on the ground) are approved for modification. Last but not least, security is not a built-in feature in IP mobility protocols. Authorization, Authentication, and Accounting (AAA) servers, such as Remote Authentication Dial In User Service (RADIUS) [DEK 13], can be interesting alternatives to start with as they have been designed to provide pillar services, such as entity authentication, data integrity and confidentiality.
3.4. Traffic segregation
use of satellite communications for safety services. Still, providing a dedicated satellite link for operational services seems to be an expensive and long-term solution.
All these reasons motivated research projects, such as NEWSKY, Airborne New Advanced Satellite Techniques and Technologies in a System Integrated Approach (ANASTASIA) or Seamless Aeronautical Network through integration of Data links, Radios, and Antennas (SANDRA), to study satellite solutions that merge both operational and non-operational services in the same heterogeneous network. Such solutions are assumed to sustain high availability and coverage needed for safety services while providing decent performances for passenger communications. It is worth underlining that these efforts focused on the airborne side, as ground access networks are physically separated, even if they are provided by the same Air Navigation Service Provider (ANSP).
Using a single satellite network for both operational and non-operational services therefore seems like an attractive and cost-effective solution; the main challenge is to guarantee a logical separation between ATS/AOC and Aeronautical Passenger Communication (APC) traffics.
3.4.2. Traffic segregation and priority management strategies
Currently, International Civil Aviation Organization (ICAO) and operational regulations strictly prohibit any physical aggregation between ATS, AOC and APC domains mainly for security and safety reasons.
However, for long-term airborne architectures where a physical separation is not provided, segregations mechanisms should be available. In such cases, priority and resource management schemes are essential in order to differentiate the services according to their domain and associated RTCPs.
Traffic separation and priority management can be handled at different layers of the protocol stack, depending on the meeting point where the operational and non-operational traffics merge (a router, a satellite terminal, a switch, etc). Methods and architectures of QoS provision are already specified in IETF RFCs. The most important architectures in the IP world are Differentiated Services (DiffServ), Integrated Services (IntServ), Multi Protocol Label Switching (MPLS) and Resource Reservation Protocol (RSVP). These techniques are totally reusable in an Aeronautical
Telecommunication Network/Internet Protocol Suite (ATN/IPS) network, provided that they do not impact the performances and RTCPs. Separation can be also provided using secure tunnels (e.g. IP Security (IPSec) and TLS).
In such a configuration, the tunnel carrying the operational traffic should have the highest priority for routing decisions, followed by passenger-related traffic. These tunneling techniques rely on cryptography in order to provide traffic segregation. For instance, cryptographic signatures can be used inside the tunnel, offering integrity of operational data traffic.
At the data link layer, and depending on the satellite access technology used in the system architecture, the resource management algorithm differs.
For instance, if the architecture is based on DVB-S2/DVB-RCS standards, the DVB-RCS link uses the Demand Assignment Multiple Access (DAMA) resource management process. On the airborne side, DAMA generates Capacity Requests (CRs) on a time-slot basis and sends them to the Network Control Center (NCC), which responds within Time Burst Time Plan (TBTP) containing the capacity assignments (one TBTP per frame). These CRs are associated with different QoS classes; each one will be relevant to a traffic domain.
Depending on the interconnection scenario, priority mapping can be done in order to associate packets with the CRs generated by the DAMA agent.
For instance, if the meeting point of all onboard traffics is an IP router as shown in Figure 3.5, the traffic will be classified (e.g. using DiffServ).
According to the Priority Identifier (PID) of each packet received from the router, a mapping between PIDs and Queuing Identifiers (QIDs) will be handled at the satellite terminal (each QID is associated with a traffic class).
Figure 3.5. A proposal for airborne traffic segregation and QoS management
The information relevant to each QID and PID can be used to estimate more accurately the capacities needed for each traffic class using a cross- layer scheme.
3.4.3. Certification issues for multiplexing solutions (from a safety point of view)
Currently, ATS communications have to be strictly separated from other types of communications, because of safety and regulatory reasons, as required by ICAO Standards and Recommended Practices (SARPs). ICAO SARPs define a set of end-to-end protocols and operational access procedures that permit both safety and non-safety aeronautical applications to use data link technologies independently of air–ground and ground–
ground subnetworks. In the perspective of network architecture that allows the coexistence of all aeronautical services in the same infrastructure, a new challenge from a safety and security point of view emerges. Indeed, the safety architecture should not only satisfy different safety requirements for each traffic class, but also provides a logical and efficient segregation of ATS services in order to be fully compliant with ICAO SARPs. Thus, not only does safety traffic management need to be provided but also secure multiplexing of these traffic flows.
We also have to design efficient QoS policies (e.g. traffic shaping and priority queuing) for a priority treatment of operational data over non- operational data. This is a key point to prevent excessive bandwidth consumption by non-operational applications when the network or system link capacity no longer provides enough resources for all the applications, which can be considered as a critical security issue.
From a design point of view, considering the certification process adopted by the aeronautical industry when new embedded systems have to be designed, it is important to keep in mind that several standards have to be met. We focus on the two most closely related to our topic: DO-178 C [DO 11a] and DO-331 [DO 11b]:
– DO-178 C (Software Considerations in Airborne Systems and Equipment Certification): in 2012, RTCA released the third version of the DO-178 document, which gives guidance for airborne system certification.
This new version takes into account the latest developments in terms of model-driven approaches for software system design. The emphasis is placed on model-driven approaches that are able to automatically generate software codes by taking as inputs only high-level models which represent the different features and behavior of the final system. The DO-178 C document introduces, in particular, the possibility of validating such a system by using formal methods in order to reduce the amount of testing for the validation of the final product. This is a major improvement for aeronautical engineers, which significantly changes the way aeronautical systems are designed and produced;
– DO-331 (Model-based Development and Verification): in addition to DO-178 C, this standard deals with tools and methods used to automatically generate software and to validate these high-level models in line with initial system specifications. In this document, advanced verification methodologies are introduced. RTCA recommends the use of three different technologies to ease the verification process: model checking, formal proofs and code assertions [GIG 12]. These three techniques have been used for a long time in different engineering fields and are developed enough to be introduced into complex environments, such as aeronautical certification and validation processes.