APPLICATION OF DELAY TOLERANT NETWORKING (DTN) IN AIRBORNE NETWORKS

Thomas Jonson, Jonah Pezeshki, Victor Chao, Kristofer Smith, James Fazio Booz Allen Hamilton Herndon, VA ABSTRACT As Airborne Networks (ANs) evolve and become increasingly net-centric, it is critical that apt consideration is given to properly extend Internet Protocol (IP)-based networking services to the tactical assets. This is an effort to resolve current interoperability issues through the use of a standard protocol and provide IP connectivity between all Airborne Network platforms. However, large gaps exist between the current AN architecture and future envisioned net-centric capabilities. The dynamic nature of the AN topology, typically characterized by highly intermittent links and long link delays, limits the use and effectiveness of Internet-based standards and protocols. Developed separately, the Delay Tolerant Network (DTN) architecture has been designed to address the needs of networks characterized by link intermittency, lack of end-to-end connectivity between end users, and high latency. While originally developed for deep space networking and inter-planetary communications, DTNs are highly applicable for sensor-based networks, terrestrial wireless networks, satellite networks, underwater acoustic networks as well as airborne networks. This paper addresses the specific challenges of establishing and maintaining reliable communications within an IP-based AN environment. In addition, this paper provides an overview of DTN, and details how this technology may be integrated into to the AN infrastructure in order to address the current issues affecting AN performance. INTRODUCTION Airborne Networks (ANs) are rapidly becoming a significant area of interest within the Department of Defense (DoD). Airborne assets, including bombers, tankers, helicopters, fighter jets and unmanned aerial vehicles (UAVs), are key enablers of battlefield information superiority and play critical roles in intelligence, surveillance, and reconnaissance (ISR) sensing and communications. Although there is an increasing demand for collaborative Internet Protocol (IP)based communications between deployed airborne platforms in the Global Information Grid (GIG), many of these solutions are inadequate, given the mobile nature of 978-1-4244-2677-5/08/$25.00 2008 IEEE airborne networks. Large gaps exist between the current AN architecture and future envisioned net-centric capabilities. The current airborne network is composed of multiple platforms which communicate across numerous data links and protocols. In the interim timeframe, Objective Gateway (OG) platforms such as the Battlefield Airborne Communications Node (BACN) and Rapid Attack Information Dissemination Execution Relay (RAIDER) may provide interim interoperability solutions in the AN environment through waveform and media translation services, however widespread deployment has yet to be determined. This architecture is limited as it relates to net-centricity and the overarching end-to-end IPbased communications construct of the GIG. To meet the end state of true net-centric IP communications, long-term solutions which address the well-known challenges of the AN environment must be adopted. Numerous studies have shown the differences between characteristics of the Internet versus characteristics of the AN environment [1, 2, 3]. Intermittent links, high latency, low-bandwidth, and ad hoc connections are common characteristics associated with ANs. Adding to this challenge, there is not a single, mutually-recognized inter-Service organization which is ultimately responsible for migrating AN towards netcentricity. This paper addresses the specific challenges of establishing and maintaining reliable communications, despite the presence of intermittent links within an IPbased AN environment. The Delay Tolerant Network (DTN) architecture, advocated by the Delay-Tolerant Networking Research Group (DTNRG) of the Internet Research Task Force (IRTF), the National Aeronautics and Space Administration (NASA), and the Defense Advanced Research Projects Agency (DARPA), has been developed to address the needs of networks characterized by intermittency, lack of end-to-end connectivity between end users as well as high latency. Store-and-forward routing is touted as a primary solution within the DTN architecture. While originally developed for deep space networking and inter-planetary communications, DTNs can also be used for sensor-based networks, terrestrial wireless networks, satellite networks, underwater acoustic networks as well as airborne networks [4]. This paper will provide an overview of the current needs of ANs and detail how the DTN architecture can be

1 of 7

applied to enable reliable IP-based communications. This paper begins by conveying the current state and future vision of ANs. The document then overviews the current considerations associated with the AN architecture and details their impact on network performance. A sample AN-based use case scenario employing store-and-forward routing is shown, to illustrate the applicability of this technology. Finally, this paper discusses requirements of the store-and-forward solution as well as next steps in the goal of achieving net-centricity within ANs. OVERVIEW OF CURRENT AND FUTURE AIRBORNE NETWORKING ARCHITECTURES An AN is defined to be an infrastructure that provides communication transport services through at least one node that is on a platform capable of flight. [5] Examples of platforms are Air Force Command and Control planes, Army UAVs, Navy Interceptors, and long range weapons. Typical data exchanged within the AN may include voice commands, mission updates, tactical imagery and video, weather information, weapons tracking, automated air refueling data or air traffic control information. Originally, ANs provided voice-only radio communications between air-to-air and air-to-ground platforms. As ANs evolved to include a new set of platforms, new capabilities arose. For instance, digital communications over the Tactical Digital Information Links (TADIL) Link-4C, used by F-14s, could allow two fighters to share data; however, the data could only be shared amongst the F-14s which used the Link 4C waveform [6]. As new AN-based platforms were developed, the corresponding waveform for these platforms were selected without consideration of existing waveforms. As such it cannot be guaranteed that two AN platforms will be using the same set of waveforms. According to the recently developed Joint Airborne Network Services Suite (JANSS) Functional Description Document (FDD), efforts are underway to extend Internet Protocol (IP)-based networking services to tactical assets [7]. This is an effort to resolve current interoperability issues through the use of a standard protocol and provide IP connectivity between all AN assets. Since the use of applications, particularly real-time voice and video, are becoming increasingly prevalent over IP-based networks, it makes sense to transition noninteroperable links and waveforms to a standards based solution which is interoperable with the rest of the GIG. Different platforms, including Coalition-based platforms, would be able to communicate and share resources using a common network layer.

The development of everything-over-IP (EoIP) follows closely with the evolving AN architecture, illustrated in Figure 1 below.

Figure 1. Evolution of Airborne Networks Originally analog radios broadcasted voice communications to the ground or other planes (Figure 1a). Subsequently, with the development of TADILs, small groups of planes became capable of digital communications, including voice and data, together in a logical hub-and-spoke architecture (Figure 1b) [8]. The introduction of more point-to-point wideband links led to a partial mesh network where some assets would network together directly and others would stilly rely on the TADIL for communications (Figure 1c). Certain nodes would act as gateways, translating one technology to another for limited interoperability. A full mesh network will be achieved when all airborne assets will be able to directly communicate with each other, given some limitations such as proximity and mission objectives (Figure 1d).

Figure 2. AN Topologies [5]

2 of 7

While there will be the capability to form a full mesh network with all other airborne assets, the AN will be flexible enough to meet a given missions objectives and communication needs. Particular topologies may include Space/Air/Ground Tether (Figure 2a), Flat Ad-hoc (Figure 2b), Tiered Ad-hoc (Figure 2c), and Persistent Backbone (Figure 2d) [5]. However, the migration towards these topologies faces several hurdles, which are further described in the next section. OPERATIONAL CONSIDERATIONS OF AIRBORNE NETWORKS Similar to other radio-based communications within the DoD, the interoperability of links and communications waveforms is perhaps the greatest challenge of enabling IP-based Airborne Networking today. Platforms that implement multiple waveforms to enable interoperable communications (e.g. within a joint Service environment) unnecessarily increase system complexity. In order to enable communication between the AN platforms, the DoD introduced an Interim Capability for AN (ICAN) as a short term fix. Two solutions derived from this initiative, BACN and RAIDER, provide translation and retransmission between existing waveforms to provide an end-to-end solution. Complications with this type of interim solution are vast. For example, an OG may service multiple communities of interest (COI) within a given mission. In the translation process, the data may be susceptible to corruption, the data may cross into another COI inadvertently, the data may need to traverse a sophisticated guard device, or it may need to decrypt an encrypted stream. In the later case, the solution becomes very complex as keys and red gateways factor into the equation. While these solutions are critical in enabling end-to-end communications between differing waveforms for the warfighter today, BACN and RAIDER do not serve as long-term solutions. In addition to interoperability, the dynamic nature of the AN topology, which is different than todays terrestrial Internet, limits the use and effectiveness of Internet-based standards and protocols. The dynamic mobile nature of ANs are characterized by highly intermittent links (commonly caused by blockage of line of sight (LoS) signals, jamming, and/or communication difficulties between fast and slow moving nodes) and high latency. Today, airborne platforms are implementing systems, specific to the needs of the individual platform, without sufficient consideration for interoperability or intermittency concerns. An architectural alternative, which solves the problems associated with interoperability

and intermittency in the AN environment, needs to be adopted. OVERVIEW OF DELAY TOLERANT NETWORKS The DTN architecture has been designed for networks with any or all of the following characteristics: intermittent connectivity, long and/or variable delay, asymmetric data rates, and high error rates [4]. To mitigate the problems associated with these characteristics, DTNs rely on store-and-forward message switching. Specifically, each DTN node locally stores each transmitted message (or a fragment thereof) before transmitting the message along a route to its intended destination. It should be noted that the storage duration of each DTN node is significantly longer than what is normally associated with IP routers (i.e., on the order of the queuing and transmission delay). As such, all DTN nodes employ some form of non-volatile storage (e.g. hard disk, flash memory) to store transmitted messages [4]. The DTN architecture implements store-andforward message switching by creating an overlay on top of the given network structure. This end-to-end overlay, known as the "bundle layer", may exist anywhere between the transport and application layers of the OSI model (Figure 3). A single bundle-layer protocol is used across all networks encompassed by the DTN.

Figure 3. Placement of Bundle Layer within OSI Layers Messages that are stored and forwarded by each DTN node are also known as bundles. These bundles contain three types of information: a source-application's user data, control information that is provided by the source-application for the destination application (this control information describes how to handle the user data), and a bundle header that is inserted by the bundle layer. These bundles are transmitted between DTN nodes, via sessions characterized by minimal round trip times, in order to marginalize the impact of link delay [9]. Due to link-intermittency within a network, DTNs support node-to-node retransmission of lost and/or corrupted data at the transport and/or bundle layer. Node-

3 of 7

to-node retransmission at the bundle layer may be accomplished via "custody transfers" (Figure 4). The purpose of custody transfers is to move the retransmission point closer to the destination in order to minimize the number of potential retransmission hops, thereby reducing network load and total transmission delay (Figure 5).

Figure 4. Custody Transfers

Figure 5. Advancement of Retransmission Points Custody transfers are implemented between the bundle layers of intermediary nodes, at the request of the source application. Specifically, when a given intermediary bundle layer sends a bundle to the next intermediary node in a given path, it will also request a custody transfer. This custody transfer is also associated with a time-to-acknowledge retransmission timer. If the next-hop bundle layer accepts custody within the time specified by the retransmission timer, the next-hop bundle layer returns an acknowledgement to the sender. Otherwise, the sender attempts to re-transmit the bundle. Thus, each intermediary node will store each bundle until another node accepts custody or the bundle's time-to-live expires (the time-to-live is typically much longer than the intermediary's time-to-acknowledge). In order to guarantee end-to-end reliability, the source node must request both custody transfer and return receipt (i.e. the

source maintains a copy of the bundle until a return receipt is received, and retransmits if the receipt is not received). DTNs ensure interoperability between DTN enabled networks by utilizing a flexible naming scheme, as specified in [10]. Specifically, each DTN node has a twopart name that consists of a "region ID" and an "entity ID". Inter-region routing is based on the region IDs, while intraregion routing is based on the entity IDs. As such, each region uses entity ID maps that are unrelated to entity ID maps of other regions. As such, no additional bandwidth is required to share entity IDs between regions. This naming scheme allows various naming and addressing schemes associated with a regional network to be encapsulated using a naming syntax defined by the DTN architecture. This allows for proprietary network systems to remain interoperable through a common encapsulation scheme. The current DTN specification [4] is being developed by the DTNRG, whose primary objective is to "address the architectural and protocol design principles arising from the need to provide interoperable communications with and among extreme and performance-challenged environments where continuous end-to-end connectivity cannot be assumed" [11]. Examples of such environments include spacecraft, military/tactical units, and many ad-hoc sensor/actuator networks. Among the challenges to be addressed are: large delay for transmissions resulting from either physical link properties or extended periods of network partitioning, routing capable of operating efficiently with frequentlydisconnected, pre-scheduled, or opportunistic link availability, high per-link error rates making end-to-end reliability difficult, heterogeneous underlying network technologies (including non-IP-based internets), and application structure and security mechanisms capable of limiting network access prior to data transit in an environment where round-trip-times may be very large [12]. USING DTN WITHIN THE AN ARCHITECTURE Previously, this paper discussed the issues associated with the current and future vision of the AN architecture. These issues include interoperability concerns, as well as the need to transmit data across links characterized by high delays and/or high intermittency. Since DTN is implemented as a network overlay, the integration of DTN into the AN infrastructure will effectively enable end-to-end connectivity between various nodes, as long as the physical infrastructure is implemented (e.g. some AN nodes are capable of translating between waveforms.) In addition, the ability of DTNs to maintain efficient network connectivity of high delay and highly intermittent links make this integration

4 of 7

the ideal solution to the current difficulties with widespread AN implementation. USE CASE SCENARIO: APPLYING STORE AND FORWARDING WITHIN A TACTICAL RELAY BETWEEN TWO ARMY BRIGADES In this scenario, illustrated in Figure 6, a loworbiting airborne platform is used to bridge two geographically disparate brigades while flying over uneven terrain in the remote areas of Afghanistan. These two brigades have been commanded to converge on a target and take out any insurgents. The airborne platform is able to serve two primary purposes: 1) to provide connectivity between both brigades and 2) to take an ISR feed from a nearby UAV and send it down to a few handheld devices within the brigade. The ISR feed shows the enemy locations and potential danger zones.

the data on to both brigades. The low-orbiting airborne platform delivers the bundle(s) to the second brigade once the link is reestablished. Once this transfer is complete the airborne platform ceases to store the bundle(s). APPLICATION OF DTNS WITHIN CURRENT DOD PROGRAMS The Marine Corps is already utilizing DTN technology within their Command and Control On-themove Network Digital Over-the-horizon Relay (CONDOR) project [13]. While early in development, this effort equips mobile land vehicles (HMMWVs) with a prototype payload of equipment to store traffic and relay it over available links using DTN bundling technology. Three types of CONDOR vehicles are defined: a Gateway, Point of Presence and Jump C2 vehicle. The Gateway vehicle is used to extend communications by bridging the Enhanced Position and Location Reporting System (EPLRS) networks with a satellite. The Point of Presence vehicle connects older technology radios to the EPLRS or satellite systems by acting as a translator and repeater. The Jump C2 vehicle acts as a mobile command post by keeping continuous satellite communications and connecting nearby command vehicles using wireless technology. A mobile Cisco router is augmented with a linuxbased computer to support the DTN bundle layer protocol based on the DTNRG. The primary means of data communication between the HMMWV and the Tactical Operations Center (TOC) is the EPLRS, which has a LoS limitation. When the HMMWV travels beyond LoS and loses connectivity, an operator can manually switch communications to a satellite link. During this manual adjustment, traffic is stored at the router and, once satellite communications have been established, is forwarded along. The DTN bundling can also be used if the satellite link is temporarily blocked by terrain or urban buildings. In this implementation a Space Communication Protocol Standard Transport Protocol (SCPS-TP) performance enhancing proxy (PEP) is also implemented to improve the performance of the satellite link. REQUIREMENTS OF DTNS IN AIRBORNE NETWORKS There are several fundamental requirements for DTNs, when attempting to integrate them into ANs. In general, these requirements can be broken into three distinct categories: network requirements, storage requirements, and AN specific requirements. DTN network requirements include the ability to maintain data flow in networks with consistent disconnects and reconnects, to accept traffic without a reliable end-to-

Figure 6. Tactical Relay Between Brigades After capturing some detailed imagery of the topography and calculating the coordinates of the insurgent stronghold, the airborne platform relays the ISR feed to the ground units; however, while the airborne platform flies over a mountainside, it experiences an intermittent link signal due to an outage in connectivity to one of the two brigades. Essentially, the LoS connection to one of the brigades was temporarily blocked by the mountainous terrain. Momentarily, the UAV is called off to provide air support to another critical mission. The UAV flies out of range of the low-orbiting airborne platform. Although the airborne platform was able to send the data to one of the brigades, a completed transmission to the second brigade was not successfully completed. Before the UAV flew off to serve the other mission, it successfully passed the bundle(s) that includes the mission data to the airborne platform. Each bundle is stored on the airborne platform until it successfully passes

5 of 7

end path, to be tolerant of poor communication performance, and to maintain multiple routes that can be used to communicate between the sender and receiver throughout a session. Furthermore, the network must be capable of actively looking for users and/or intermediary nodes (i.e. for the purpose of DTN custody transfers) when attempting to forward DTN bundles throughout the network. Storage requirements are based on two fundamental factors: timers (e.g. the "time to live" of a packet), and available storage. For example, a given DTN node must be capable of storing a given bundle when the designated destination is unreachable. However, this node may only retain this bundle for a period of time that is less than its preset storage duration, and may only store a total number of bundles whose total size does not exceed the maximum allocated storage size for that node. In addition, a given DTN node must be capable of maintaining each bundle until either it receives an acknowledgement from the receiver, or the storage duration for that bundle expires. Additional AN specific requirements also exist for DTNs. These requirements stem from the high speed nature of AN networks, the network delay associated with the distance between AN nodes, and the requirement of each AN platform to be capable of connecting to other platforms via a wide variety of network nodes (e.g. satellites, ground based, ground vehicles, airborne platforms, etc). DTNs in ANs must be able to quickly establish network connections (e.g. a plane flying past a base may only have a few minutes or even seconds of connectivity), work with a wide variety of nodes and over many different communications paths. CHALLENGES OF IMPLEMENTING A STORE AND FORWARD-BASED SOLUTION While DTNs are a promising solution to most of the current AN considerations, significant work must still be done prior to widespread deployment. Specifically, steps must be taken to ensure that the deployed network operates well within a single classification level, and that the addition of store and forward routing does not adversely affect network performance. Also, given that the National Security Agency (NSA) will likely require data-at-rest protection mechanisms to be employed, local storage devices (used to support the store-and-forward functionality) must be developed so that a compromised device cannot be tampered with (i.e. will not allow unauthorized access to stored data). Since ANs are currently deployed, special consideration must be given to an implementation plan to integrate DTN. This integration plan must enable the

transition to DTN over AN, without substantially disrupting currently deployed AN services. In addition, since some traffic types (e.g. VOIP) cannot be used reliably over DTN, this DTN over AN implementation must allow some applications to be capable of bypassing the DTN overlay. CONCLUSION Although IP-based ANs have become a significant area of interest within the DoD, large gaps still exist between the current the AN architecture and future envisioned net-centric capabilities. To address these gaps, this paper has proposed the adoption of the DTN architecture within the current AN infrastructure. The implementation of DTN within the AN architecture is expected to mitigate the impact of link intermittency, high latency, and AN platform non-interoperability; which are all characteristics of current ANs. In addition, this paper has also provided a sample AN-based use case scenario, which has illustrated the applicability of DTN technology to the current gaps in the AN infrastructure. REFERENCES [1] Bosner, Wayne, Stranc, Ken, LaBarre, Lee, and Eyestone, David, Internet Versus Airborne Network, USAF Special Interest Group, February 2008. [2] Fisher, Lt. Col. Tryon, Need for Common ANI GIG Entry Points, USAF Special Interest Group, March 2008. [3] Stranc, Ken, Airborne Network Gap Analysis, USAF Special Interest Group, March 2008. [4] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, DelayTolerant Networking Architecture, RFC 4838, April 2007. [5] Airborne Network Architecture System Communication Description & Technical Architecture Profile Version 1.1, USAF Airborne Network Special Interest Group, 7 October 2004 [6] Pike, John, Tactical Digital Information Links (TADIL) 23 April 200. 12 March 2008 <http://www.fas.org/irp/program/disseminate/tadil.htm> [7] Trafton, Pizzi, The Joint Airborne Network Services Suite, MILCOM 2006. [8] Stranc, Kenneth, Airborne Networking, USAF Special Interest Group, September 2004. [9] Warthman, Forrest, "Delay-Tolerant Networks (DTNs): A Tutorial v1.1," Wartham Associates, 2003. Available from http://www.dtnrg.org. [10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax," STD 66, RFC 3986, January 2005.

6 of 7

[11] Delay Tolerant Networking Research Group, 2008. <http://www.dtnrg.org> [12] Delay Tolerant Networking Research Group: About, 2005. <http://www.dtnrg.org/wiki/About> [13] Parikh, Salil, Durst, Robert, Disruption Tolerant Networking for Marine Corps CONDOR, MILCOM 2005. [14] Delay Tolerant Networking Research Group: Code, 2008. <http://www.dtnrg.org/wiki/Code>

7 of 7