vdl-2 FOR THE ATN/IPS
Tom McParland, BCI, Moorestown, NJ
Abstract
Activities have been initiated in ICAO and AEEC to further develop the Aeronautical Telecommunications Network/Internet Protocol Suite (ATN/IPS) rather than the ATN/Open System Interconnection (ATN/OSI) protocolsfor use by safety and regularity of flight applications.
VHF Digital Link Mode 2 (VDL-2)has until now been defined to support the ATN/OSI protocol stack in accordance with ARINC 631[4] and also to support ACARS by following the “ACARS over AVLC (AoA)” technique whereby the character-oriented ACARS protocol can run over the VDL-2 link layer in accordance with ARINC 618 [2]. The bit-oriented ATN ATC applications run natively over the ATN/OSI stack while bit-oriented FANS ATC applications run over the ACARS stack following ARINC 622 [3].
This paper investigates how ATN ATC and AOC applications may run over an ATN/IPS stack that is operating over VDL-2.
Introduction
This paper will first describe a framework for the ATN/IPS Mobile Network Architecture. The proposed architecture consists of terrestrial and satellite based air/ground access networks connected to the ATN/IPS internetwork, which is a collection of regional ground/ground sub-networks. For terrestrial air/ground access networks it is proposed that an air/ground access network be partitioned into one or more air/ground access sub-networks which may be operated by the same or different Air/Ground Communications Service Providers (ACSP).
After the general ATN/IPS Mobile Network Architecture is described, a description of Proxy Mobile IPv6 [1] is provided.
Next a description of the VDL-2 extensions to the AVLC protocol to carry IP traffic is provided.
Finally a description of the interaction between the extended AVLC and Proxy Mobile IPv6 (PMIPv6) is provided as an instance of the ATN/IPS Mobile Network Architecture.
ATN/IPS Mobile Network Architecture
Figure 1 depicts the key network components for the ATN/IPS Mobile Network Architecture. The ATN/IPS Mobile network architecture has one or more Air/Ground Access Sub-Networks (A/G AsN) which contain a group of Ground Stations connected to an Access Sub-Network Mobility Anchor. The Air/Ground Access Sub-Networks are part of the Air/Ground Access Network (A/G AN) and the Access Sub-Network Mobility Anchors are connected to the Air/Ground Access Network Mobility Anchor.
An Air/Ground Access Network is operated by a singleAir/Ground Communications Service Provider (ACSP). The ACSP may operate all of the Air/Ground Access Sub-Networks within its domain. Alternatively, the ACSP may contract with other ACSPs to operate one or more Air/Ground Access Sub-Networks.
The Air/Ground Access Networks are connected to the ATN/IPS Ground/Ground Internetwork which consists of multiple Regional Networks. As depicted in Figure 1 an ATC Correspondent Node typically connects to the local Regional Network; however an AOC Correspondent Node may connect to a remote Regional Network.
Figure 1. ATN/IPS Mobile Network Architecture
Note that the ATN/IPS Mobile Network does not include a global mobility anchor that might, for example, aggregate multiple Air/Ground Access Network mobility anchors. The assumption is that this would not be required for ATC traffic which would perform a Context Management Log In with the Air/Ground Access Network mobility anchor address and for AOC traffic the mobile node can contact the AOC correspondent node or use another mechanism such as updating a DNS server.
Proxy Mobile IPv6 (PMIPv6)
Proxy Mobile IPv6 (PMIPv6) is a type of network-based mobility management. PMIPv6 enables IP mobility for a mobile node without requiring its participation in any mobility-related signaling. Rather, the network is responsible for managing IP mobility on behalf of the mobile node. The mobility entities in the network are responsible for tracking the movements of the mobile node and initiating the required mobility signaling on its behalf. The following definitions and operation description of PMIPv6 is copied from RFC 5213 [1]:
PMIPv6 Definitions
Local Mobility Anchor (LMA) is the home agent for the mobile node in a Proxy Mobile IPv6 domain. It is the topological anchor point for the mobile node's home network prefix(es) and is the entity that manages the mobile node's binding state.
Mobile Access Gateway (MAG) is a function on an access router that manages the mobility-related signaling for a mobile node that is attached to its access link. It is responsible for tracking the mobile node's movements to and from the access link and for signaling the mobile node's local mobility anchor.
The term Mobile Node (MN) is used to refer to an IP host or router whose mobility is managed by the network.
A Proxy Binding Update (PBU) is a request message sent by a mobile access gateway to a mobile node's local mobility anchor for establishing a binding between the mobile node's home network prefix(es) assigned to a given interface of a mobile node and its current care-of address.
A Proxy Binding Acknowledgement (PBA) a reply message sent by a local mobility anchor in response to a Proxy Binding Update message that it received from a mobile access gateway.
Mobile Node Attachment – Proxy Mobile IPv6 Signaling Flow
PMIPv6 Operation
The core functional entities in the PMIPv6 infrastructure are the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The local mobility anchor is responsible for maintaining the mobile node's reachability state and is the topological anchor point for the mobile node's home network prefix(es). The mobile access gateway is the entity that performs the mobility management on behalf of a mobile node, and it resides on the access link where the mobile node is anchored. The mobile access gateway is responsible for detecting the mobile node's movements to and from the access link and for initiating binding registrations to the mobile node's local mobility anchor. There can be multiple local mobility anchors in a Proxy Mobile IPv6 domain each serving a different group of mobile nodes.
When a mobile node enters a Proxy Mobile IPv6 domain and attaches to an access link, the mobile access gateway on that access link, after identifying the mobile node and acquiring its identity, will determine if the mobile node is authorized for the network-based mobility management service.
If the network determines that the mobile node is authorized for network-based mobility service, the network will ensure that the mobile node using any of the address configuration mechanisms permitted by the network will be able to obtain the address configuration on the connected interface and move anywhere in that Proxy Mobile IPv6 domain. The obtained address configuration includes the addresses) from its home network prefix(es), the default-router address on the link, and other related configuration parameters. From the perspective of each mobile node, the entire Proxy Mobile IPv6 domain appears as a single link, the network ensures that the mobile node does not detect any change with respect to its layer-3 attachment even after changing its point of attachment in the network.
Figure 2 shows the signaling call flow when the mobile node enters the Proxy Mobile IPv6 domain. The Router Solicitation message from the mobile node may arrive at any time after the mobile node's attachment and has no strict ordering relation with the other messages in the call flow.
For updating the local mobility anchor about the current location of the mobile node, the mobile access gateway sends a Proxy Binding Update message to the mobile node's local mobility anchor. Upon accepting this Proxy Binding Update message, the local mobility anchor sends a Proxy Binding Acknowledgement message including the mobile node's home network prefixes. It also creates the Binding Cache entry and sets up its endpoint of the bi-directional tunnel to the mobile access gateway.
The mobile access gateway on receiving the Proxy Binding Acknowledgement message sets up its endpoint of the bi-directional tunnel to the local mobility anchor and also sets up the forwarding for the mobile node's traffic. At this point, the mobile access gateway has all the required information for emulating the mobile node's home link. It sends Router Advertisement messages to the mobile node on the access link advertising the mobile node's home network prefix(es) as the hosted on-link prefix(es).
The mobile node, on receiving these Router Advertisement messages on the access link, attempts to configure its interface using either stateful or stateless address configuration modes, based on the modes that are permitted on that access link as indicated in Router Advertisement messages. At the end of a successful address configuration procedure, the mobile node has one or more addresses from its home network prefix(es).
After address configuration, the mobile node has one or more valid addresses from its home network prefix(es) at the current point of attachment. The serving mobile access gateway and the local mobility anchor also have proper routing states for handling the traffic sent to and from the mobile node using any one or more of the addresses from its home network prefix(es).
The local mobility anchor, being the topological anchor point for the mobile node's home network prefix(es), receives any packets that are sent to the mobile node by any node in or outside the Proxy Mobile IPv6 domain. The local mobility anchor forwards these received packets to the mobile access gateway through the bi-directional tunnel. The mobile access gateway on other end of the tunnel, after receiving the packet, removes the outer header and forwards the packet on the access link to the mobile node. However, in some cases, the traffic sent from a correspondent node that is locally connected to the mobile access gateway may not be received by the local mobility anchor and may be routed locally by the mobile access gateway.
The mobile access gateway acts as the default router on the point-to-point link shared with the mobile node. Any packet that the mobile node sends to any correspondent node will be received by the mobile access gateway and will be sent to its local mobility anchor through the bi-directional tunnel. The local mobility anchor on the other end of the tunnel, after receiving the packet, removes the outer header and routes the packet to the destination. However, in some cases, the traffic sent to a correspondent node that is locally connected to the mobile access gateway may be locally routed by the mobile access gateway.
VDL-2 Extensions for IP Traffic
IP over AVLC (IoA)
The approach suggested in this paper to operate ATN/IPS over VDL-2 is to extend the VDL-2 data link layer, AVLC, in a way similar to ACARS over AVLC (AoA). The proposed approach is termed IP over AVLC (IoA). The obvious advantage of this approach is reuse of avionics and ground station hardware and software. The notion of running IP over AVLC is not new. It was proposed back in 2000 by MIT Lincoln Laboratory (MIT LL) under contract to NASA [5]. The same technique to encapsulate IP traffic is copied in this paper. The mobility approach however was different in [5]; there Mobile IP was proposed.
The VDL-2 data link protocol Aviation VHF Link Control (AVLC) is an extension to the High Level Data Link Control (HDLC) protocol. The extension is to support air/ground link establishment and handoff. The HDLC/AVLC frame format is as follows:
Flag | Address | Link Control |Information Field | Flag
For AoA there is already a technique to identify an ACARS packet versus an ATN/OSI 8208 packet carried in an AVLC I-frame. As described in [5] the technique is that the Information Field contains 2 bytes of information which indicate the type of information being carried, i.e., whether it is ACARS or 8208. The first byte is the Initial Protocol Identifier (IPI) field and the second byte is the Extended Protocol Identifier (EPI) field.
The Information Field format for AVLC frames is as follows:
Information Field = IPI | EPI | Data
ISO 9577 [6] assigns a value of the IPI field for IP traffic. The value 11001100 indicates IPv4 and the value 10001100 indicates IPv6 traffic.
VDL-2 ground stations broadcast a Ground Station Information Frame (GSIF). Aircraft listen to GSIF frames and determine when to connect to an initial ground station or handoff to a new ground station. Basically the aircraft listens for the periodic GSIFs and if an initial/new connection is needed the aircraft will issue an eXchange Identity (XID) frame commanding link establishment (XID_CMD_LE). If the ground station is able to support the connection, it sends a response frame (XID_RSP_LE).
IoA and PMIPv6 as an Instance of the ATN/IPS Mobile Network Architecture
Using IoA with PMIPv6 is proposed as an instance of the ATN/IPS Mobile Network Architecture. In this case the Air/Ground Access Network mobility anchor is an LMA and the Air/Ground Access Sub-Network mobility anchors are MAGs. The proposed approach is depicted in Figure 3. The aircraft communicates with a VDL ground station using AVLC. The ground stations communicate with their MAG by local means, e.g., IP encapsulation. The MAGs also communicate with the LMA by local means. The LMAs advertise their Mobile Network Prefix to the ATN/IPS Ground/Ground Internetwork using BGP.
Figure 4 depicts the IoA and PMIPv6 signaling flow for attachment to a new MAG.
Figure 3 – IoA/PMIPv6 Architecture
Figure 4 - IoA and PMIPv6 Signaling Flow
Summary and Future Work
This paper has proposed a general framework for network level mobility management and has described an instance of this framework using VDL-2 and PMIPv6. As noted in the paper the advantage of the proposed approach is re-use of AVLC and associated handoff procedures in the aircraft and ground station. An additional advantage is that PMIPv6 offloads any additional mobility signaling to the network.
It should be noted that the framework is supported by AeroMACs. Under the WiMAX architecture an ASN corresponds to an Air/Ground Access Sub-Network and a CSN corresponds to an Air/Ground Access Network.
It is recommended that future Air/Ground Access Networks such as those based on LDACS follow this framework.
This paper has not directly addressed “Multilink” considerations so this requires further investigation. One alternative is to use Stream Control Transmission Protocol (SCTP) [7].
References
[1] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, B. Patil, RFC 5213, Proxy Mobile IPv6, August 2008
[2] Supplement 7 to ARINC Specification 618, Air-Ground Character-Oriented Protocol, 12/06/2013
[3] ARINC Specification 622, ATS Data Link Applications over ACARS Air-Ground Network, 10/12/2001
[4] ARINC Specification 631, VHF Digital Link (VDL) Mode 2 Implementation Provisions, 11/15/2010
[5] R.D. Grappel, MIT Lincoln Laboratory, Internet over VDL-2 Subnetwork – the VDL-2/IP Aviation Datalink System, 10/20/2000
[6] ISO/IEC Technical Report 9577, “Information Technology - Protocol Identification inthe Network Layer”, Fourth Edition, December 1999.
[7] R. Steward, Ed., RFC 4960, Stream Control Transmission Protocol, September 2007
Email Address
34th Digital Aviation Systems Conference
September 13-17, 2015