End-to-End Disruption-Tolerant Transport Protocol Issues and Design for Airborne Telemetry Networks

Networks of airborne nodes provide unique challenges to end-to-end communication, in particular due to the highly dynamic topology and time-varying connectivity of high velocity nodes, and unreliability of the wireless communication channel. This paper explores the issues and presents a design for a domainspecific transport protocol targeted to multihop network that interconnects high-velocity airborne nodes with the telemetry application of returning sensor data with high reliability. INTRODUCTION AND MOTIVATION Transport protocols provide end-to-end communication across the network to applications. The service they offer is to provide a unified interface for information transfer from one end system to the other. In an ideal world this service would be characterized by negligible delay, zero errors, and an unlimited bit rate. Unfortunately the characteristics of the underlying network and lower layers place limitations on the performance of the transport layer. The transport layer then has to adapt to the lower level limitations (delay, limited bandwidth, errors), while meeting the service requirement parameters of applications. In this work we are concerned with the transmission of telemetry data from airborne test articles to ground stations. The iNET (Integrated Networked Enhanced Telemetry) program has identified a set of needs [1] for the T&E (test and evaluation) community that require a substantially enhanced networking capability for Major Range and Test Facility Bases. There is currently a significant effort underway in the iNET community to design the physical layer communications and MAC (medium access control) [2]. The current effort targets only the lower layers of the networking stack (PHY and MAC), however a number of issues remain to be solved at the network and transport layers [3]. This paper presents the design of AeroTP, a TCP-friendly transport protocol with multiple QoS modes for the TmNS (telemetry network system). The current Internet protocols are unsuitable for the specific constraints and requirements of the aeronautical telemetry network environments in a number of respects [3]. At the same time, there is a need to be compatible with both TCP/IP-based devices located on test articles (TAs) as well as with the controlInternational Telemetering Conference (ITC 2008) ling applications at the ground station (GS). Therefore we are designing a new protocol suite that is both specific to the telemetry network environment, while fully interoperable with TCP/UDP/IP via gateways at the telemetry network edge to the GS and TA. It is important to note that while the telemetry network constrains some aspects of network operations, there are also aspects that can be exploited by domain specific protocols, such as the knowledge of TA location and trajectory by the GS. A. AeroTP: TCP-Friendly Transport Protocol for Aeronautical T&E TCP provides a connection-oriented reliable data-transfer service, with congestion control but no explicit support for precedence or QoS. Many of these mechanisms are unsuitable for wireless networks in general and telemetry networks in particular. TCP congestion control assumes that all losses are due to congestion, and therefore makes the wrong decision when bit errors corrupt packets [4]. Furthermore, TCP requires a reliable ACK stream for self-clocking that is unsuitable for highly dynamic and asymmetric networks. A number of these problems have been researched, and a few alternative protocols exist, such as SCPS-TP (space communications protocol standards – transport protocol) [5], from which we can draw some mechanisms. We present a new domain-specific transport protocol AeroTP, which is designed for the aeronautical telemetry network environment while being TCP-friendly1 to allow seamless splicing with conventional TCP at the telemetry network network edge in the GS and on the TA. Thus we transport TCP and UDP through the telemetry network, but in an efficient manner that meets the goals of this environment. AeroTP has several operational modes that support different service classes: reliable, nearly-reliable, quasi-reliable, best-effort connections, and best-effort datagrams. The first of these is fully TCP compatible, the last fully UDP compatible, and the others TCP-friendly with reliability semantics matching the needs of the mission and capabilities of the telemetry network. All but he last mode are connection oriented, but do not use a three-way handshake for connection establishment. In designing this protocol, we are specifically concerned with DoD test ranges. The goal is to move from the current point-to-point unidirectional SST (serial-streaming telemetry) to a networked environment of bidirectional links to enable scalability, provide multihop TA–TA communication beyond TA–GS range, and to permit uplink control of TAs. While physical layer solutions are necessary to maximize spectral efficiency, the network and transport layers provide a key piece of the solution. The ability to multihop provides spatial reuse since the TA–TA link range is shorter than TA–GS, providing greater aggregate throughput within the same spectrum. The QoS mechanisms of AeroNP [7] permit more important traffic classes (e.g. command and control) and mission-driven higher priority traffic to be delivered when a trade-off must be made. The cross-layering mechanisms allow the routing algorithm to influence transmission power of the TA–TA links to minimize interference. AeroTP supports multiple reliability modes to permit more efficient use of the resources based on the needs of traffic. Furthermore, in reliable and nearly-reliable mode when acknowledgments are needed, they are aggregated to reduce the chattiness of the protocol and conserve bandwidth. The packet formats are designed to reduce overhead as much as practical, for example by performing address translation so that IP addresses and unnecessary TCP and IP header fields are not transported through the telemetry network. The AeroTP header is designed to permit efficient translation between TCP/UDP and AeroTP at the gateway, as described in the Gateway Functionality Section below. 1Note that we use the term ”TCP-friendly” in a more general sense than the established term ”TCP-friendly rate control (TFRC) [6]