Proposal:iNET-2008-ANTP

AeroNP and AeroTP: Aeronautical Network and Transport Protocols for iNET (ANTP)

Spectrum Efficient Technology (SET) Science & Technology (S&T) BAA W900KK-08-R-0019
Topic area and #: TCP protocol variants optimized for aero environment (Topic #2)
Project Reference #: KU-002

Deadline to send: 16 May 2008 (sent)
Submission deadline: 19 May 2008 (received)
Notification:

White paper as submitted: PDF MS-Word

Technology Overview

The iNET (Integrated Networked Enhanced Telemetry) program has identified a set of needs [NDR2004] for the T&E (test and evaluation) community that require a substantially enhanced networking capability for MRTFBs (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) [IWG2008]. 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 [TSR2004]. We propose to design, evaluate, simulate, prototype, and optionally field-test the upper layer protocols: AeroTP -- TCP-friendly transport protocol with multiple QoS modes for the TmNS (telemetry network system), AeroNP -- IP-compatible network protocol and dynamic routing for aeronautical T&E, and cross-layer optimizations with the iNET TDM-based MAC and physical layers under development.

As identified in the iNET Technology Shortfalls Report [TSR2004], the current Internet protocols are unsuitable for the specific constraints and requirements of the aeronautical T&E environments in a number of respects. At the same time, there is a need to be compatible with both TCP/IP-based devices located on TAs (test articles) as well as with the controlling HMI (human-machine interface) applications at the GS (ground station). Therefore we are proposing a new protocol suite that is both specific to the T&E environment, while fully interoperable with TCP/UDP/IP via a gateways at the TmNS edge to the GS and TA. It is important to note that while the TmNS 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. We emphasize that the design ideas presented for AeroTP and AeroNP are preliminary; phase one of the proposed effort will analyze the tradeoffs and determine the costs and benefits of various mechanisms as well as the detailed packet formats; phases two and three will simulate and prototype to finalize their design.

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 the mechanisms are unsuitable for wireless networks in general and T&E in particular. TCP congestion control assumes that all losses are due to congestion, and therefore makes the wrong decision when bit errors corrupt packets [KS2004], and 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) [DMT1996], from which we can draw some mechanisms. We propose a new domain-specific transport protocol AeroTP, which is designed for the aeronautical T&E environment while being TCP-friendly to allow seamless splicing with conventional TCP at the TmNS network edge in the GS and on the TA. Thus we will transport TCP and UDP through the TmNS, but in an efficient manner that meets the goals of the Needs Discernment Report [NDR2004]: dynamic resource sharing, QoS support for fairness and precedence, real-time data service, and bidirectional communication. 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 TmNS. The AeroTP header is designed to permit efficient translation between TCP/UDP and AeroTP at the gateway, as described in the Technical Approach Section below.

AeroNP: IP-Compatible Network Protocol and Routing for Highly Dynamic Aeronautical T&E

IP provides the packet format and addressing for the global Internet, with separate routing algorithms needed to determine the path (OSPF, ISIS, etc). There are have been many mobile ad hoc routing protocols [RS1996], some of which use trajectory information for highly dynamic networks [FT2001]. While none of these proposals are designed for the TmNS environment, there are a number of mechanisms that are candidates for AeroNP, which is designed for IP transparency, while providing a more efficient address encoding for bandwidth conservation that maps multiple devices within a TA to a single TA MAC address, contains explicit location information for highly dynamic nodes (to at least Mach 7 relative velocity), and provides explicit support for QoS with precedence (priority) and service type fields. The AeroNP routing protocol supports multihop routing with QoS as required in the Needs Discernment Document [NDR2004], using location information in both performance-optimized mode in which location information does not need to be secret, as well as a stealthy mode in which location information must be encrypted in signaling messages or is not available at all. AeroNP also provides support for broadcast and multicast in conjunction with the iNET MAC capabilities as described below. An address resolution function performs the translation between IP addresses and iNET MAC addresses and TA device IDs.

Cross-Layer Optimizations Between AeroTP/AeroNP and the iNET MAC/PHY

While we propose new transport and network protocols, we intend to interface with the iNET MAC under development, and will continue to monitor the iNET working group to provide input and ensure that we are compatible. We expect however, that there will be significant benefits by employing cross-layer optimizations not only among AeroTP and AeroNP, but also with the iNET MAC and PHYs. Therefore, we will investigate the tradeoffs in type and strength of FEC at the PHY layer with respect to channel conditions and BER (bit error rate), as well as optimizing TDM parameters and slot assignment based on the transfer mode of AeroTP and QoS parameters (precedence and service type) of AeroNP. Furthermore, the quasi-reliable mode of Aero-TP erasure codes across multiple TA--GS paths when available, requiring coordination of GS and iNET MAC slot assignment with AeroNP routing and AeroTP transport. Finally, the support for multicast and broadcast requires coordination of AeroNP routing with the broadcast capabilities of the iNET MAC.

T&E Benefit

This proposal is specifically targeted to benefit the DoD test ranges and laboratories by providing new transport and network layer capabilities indicated by the Needs Discernment Report [NDR2004] and the Technology Shortfalls Report [TSR2004]. The iNET goal is to move from the 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 ("over-the-horizon"), and permit uplink control of TAs.

These new capabilities will be compatible with the emerging iNET TDM MAC and PHY layers, with cross-layer optimizations to maximize efficiency in the bandwidth-constrained TmNS environment. The TCP-friendly nature of AeroTP and IP-transparency of AeroNP meet the requirements for communication between TCP/IP-based TA peripherals and the gNET (ground network). The cross-layering effort will allow better choices to be made among the range of parameters of the iNET MAC and PHY, as well as permit the future incorporation of dynamic choices to parameters such as FEC strength.

The proposed effort will implement a simulation model of not only the AeroTP and AeroNP protocols, but of the overall TmNS network architecture and topology, iNET TDM MAC algorithm and protocol, and the physical environment including channel model and FEC. We will make these models and source code freely available to the iNET and broader research communities. This will provide a significant benefit to the iNET program by providing a platform on which other participants can try their ideas and understand the performance of iNET protocols and mechanisms under different scenarios Furthermore, the model can be used to assist in the evolution of iNET over the long term. This will also enhance the broader impact by allowing other researchers to understand and contribute to aeronautical T&E solutions.

S&T Technology Challenges

Two of the main challenges identified in this solicitation are loss of RF spectrum and the provision of reliable transmission to a number of simultaneous high-bit rate users. 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 at the network layer will permit more important traffic classes (e.g. command and control) and mission-driven higher priority traffic to be delivered when a tradeoff must be made. The cross-layering mechanisms will allow the routing algorithm to influence transmission power control 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 acknowledgements are needed, they are aggregated to reduce the chattiness of the protocol and conserve bandwidth. The packet formats will be 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 TmNS.

As indicated in the Technology Shortfalls Report Appendix [TSR2004] while networking technology is mature in general, a several key aspects have a TRL of 3 or 4 when applied to the iNET environment. In particular, the need to support mobility in a multihop network had a TRL of 3 and transport protocols in the wireless environment a TRL of 4. AeroTP and AeroNP are specifically intended to raise the TRL to 5 with the demonstration of the prototype implementation. Furthermore, we optionally propose field deployment and integration that would meet TRL 6.

Technical Approach Phase 1: Protocol Analysis and Design

Phase 1 begins at the entry TRLs of 3 and 4, and will compare and evaluate alternative mechanisms for suitability in the TmNS T&E environment, and produce a preliminary design for the upper layer protocols and cross-layered interaction with the lower layers. An analytical framework for the environment will be developed, including a mobility model, transmission range, contact interval, TA quantity and density, and multipath capabilities. This framework will be used to perform the initial tradeoffs and evaluation of alternatives, as well as drive the simulation model proposed for phase 2.

Task 1: AeroTP: TCP Friendly Transport Protocol for Aeronautical Test and Evaluation

AeroTP performs end-to-end data transfer between the edges of the TmNS and splices to TCP connections or UDP flows at the gateways. Transport-layer functions that must be performed by AeroTP include connection setup and management, transmission control, and error control.

Transport Layer Mechanism Tradeoffs

Function	Mechanisms	Comments
Connection Setup	Explicit (Handshake) Implicit	Requires E2E Path Saves time
Error Control	FEC Erasure Code ARQ	Used at link layer Allows distribution over multiple paths Needed for delivery confirmation
Rate Control	Closed loop Open loop

Connection Management and Rate-Based Transmission Control

AeroTP will use connection management paradigms suited to the iNET environment. An alternative to the overhead of the three-way handshake is an opportunistic connection establishment in which data can begin to flow with the setup message (SYN). Closed-loop window-based flow and congestion control with slow start is not appropriate to the highly dynamic wireless environment of iNET. Therefore we propose to use an open-loop rate-based transmission control with instrumentation from the network layer and test plan to determine an initial rate, with backpressure to control congestion, as described below for AeroNP. Error control is fully decoupled from rate control, and is service specific as described below.

Segment Structure and Gateway Functionality

AeroTP is TCP-friendly, meaning it is designed to efficiently interoperate with TCP and UDP at the TmNS edge. To support this we will design the gateway functionality for the gNET interface element [GSA2007] and the TA vNET element [TAA2007] that does IP--AeroNP translation (see below) and TCP/UDP--AeroTP splicing. A preliminary design of the AeroTP segment is shown in Figure 2. Since bandwidth efficiency is critical, AeroTP does not encapsulate the entire TCP/UDP and IP headers, but rather the gateway converts between TCP/UDP and AeroTP headers. Some fields not needed for AeroTP operation but needed for proper end-to-end semantics are passed through, such as the source and destination port number, TCP flags, and the timestamp.

AeroTP Packet Structure

Source Port				Destination Port
Sequence Number
Timestamp
Mode	TCP Flags		reserved	HEC
PAYLOAD
CRC 32

The sequence number allows reordering of packets due to erasure coding over multiple paths or TA mobility, and is either the TCP byte sequence number or a segment number, depending on the transfer mode described below. The HEC field is a strong CRC check on the integrity of the header in the case of bit errors in the wireless channel. A CRC protects the integrity of the data edge-to-edge across the TmNS since there is not a separate AeroNP or link layer frame CRC, and allows measurement of the bit-error-rate for erasure code adaptation depending on the transfer mode.

Error Control and QoS-Based Transfer Modes

The Needs Discernment Report [NDR2004] specifies that there will be a number a classes of data being transmitted over the TmNS. For this reason we plan to investigate multiple transfer modes that will be mapped to different traffic classes:

1. reliable connection: end-to-end acknowledgements using ACK passthrough or custody transfer
2. near-reliable connection: split ARQ; gateway immediately returns TCP ACKs with no buffering for TCP side
3. quasi-reliable connection: transport layer erasure coding, either sequential or multipath
4. unreliable connection: best effort over FECed links
5. unreliable datagram: stateless best effort for UDP compatibility

Reliable mode must preserve end-to-end acknowledgement semantics from source to destination as the only way to guarantee delivery. Two possible mechanisms are ACK passthrough, which has the disadvantage of imposing TCP window and ACK timing onto the AeroTP realm, or custody transfer [SB2007] that splits the TCP ACK loop at the gateway, at the cost of buffering AeroTP segments in the gateway until fully acknowledged.

Near-reliable mode is highly reliable, but does not guarantee delivery since the gateway immediately returns TCP ACKs to the source on the assumption that AeroTPs reliable ARQ-based delivery will succeed using SNACKs (selective negative acknowledgements) [DMT1996] supplemented by a limited number of (positive) ACKs. This still requires that the gateway buffer segments until acknowledged across the TmNS by AeroTP, but is more bandwidth-efficient than full source--destination reliability. However, the possibility exists of confirming delivery of data that the gateway cannot actually deliver to its final destination.

Quasi-reliable mode eliminates ACKs and ARQ entirely, using only open-loop error recovery mechanisms such as erasure coding, across multiple paths if available [M1990]. In this mode the strength of the coding can be tuned using cross-layer optimizations based on the quality of the wireless channel being traversed, available bandwidth, and the sensitivity of the data to loss. This mode provides an arbitrary level of statistical reliability but without absolute delivery guarantees.

Unreliable mode relies exclusively on the FEC of the link layer to preserve data integrity and does not use any error correction mechanism at the transport layer. While we may eventually use cross-layering to vary the strength link FEC, we cannot assume this capability.

Unreliable datagram mode is intended to transparently pass UDP traffic, and no AeroTP connection state is established at all.

All modes except unreliable datagram are connection-oriented for TCP-friendliness and will use byte sequence numbers for easy translation to TCP at the gateway, so that packets may follow varying or multiple paths and be reordered at the receiver.

Task 2: AeroNP: IP Compatible Network Protocol and Dynamic Routing for Aeronautical Test and Evaluation

AeroNP is designed for the iNET environment and includes the packet format and a dynamic location-aware multihop routing protocol. Table x. shows the link stability analysis based on the characteristics of the TmNS [NDR2004] and an assumed TA--Ta transmission range of 10--15 nmi. It is seen that in the worst-case scenario the contact duration between two TAs can be as low as 10-15 sec, which this indicates the need for intelligent multihop routing protocol for reliable communication over a highly dynamic physical topology.

Header Format, Addressing, and IP Transparency

AeroNP is an IP-compatible network layer with the additional functionality needed for iNET. A preliminary design of the AeroNP packet is shown in Figure x; we will further investigate the various fields needed with the objective to minimize the total overhead. Since the iNET MAC is based on TDM, an AeroNP packet is inserted directly into a TDM slot, and thus contains the iNET MAC addresses: source, destination, and next hop. Significant efficiency can be gained if the AeroNP header doesn't carry the 32 bit source and destination IP addresses (or the even worse 128 bit addresses for IPv6). By performing and ARP-like address translation process, the IP address can be mapped between iNET MAC addresses in the gateway. However, each TA can have multiple peripherals, each of which has an IP address. Therefore, we include a device id field in the header, and the <MAC-address, device-id> tuple is mapped to IP address at the gateway. While dynamic mapping procedures are possible, it will be more efficient to preload the translation table at the beginning of each test. Optionally, source and destination location is included, which can be the GPS coordinates that are used in location aware routing.

AeroNP Packet Structure

Version	CI	Type	Priority	Protocol		TOS/DSCP
Source TA MAC address				Destination TA MAC address
Next Hop TA MAC address				Source Dev ID		Dest Dev ID
Source TA Location (optional)				Destination TA Location (optional)
Length				HEC
PAYLOAD

The type and priority are used for AeroNP QoS, while CI is used to indicate the congestion level at a given node within the TmNS. The demuxing protocol id and the TOS/DSCP (diffserv code point/type of service) fields are carried over from the IP header. HEC is a strong check on the integrity of the header to protect against bit errors. The need for a length field requires further study.

Dynamic Routing Protocol

Existing routing protocol mechanisms are not directly applicable to the TmNS for T&E purposes. Reactive routing protocols such as AODV and DSR are not suitable because of the delay involved in finding paths on-demand and such paths may not be valid for a long duration on a highly dynamic network. On the other hand, proactive routing protocols such as DSDV and OLSR incur excessive overhead due to frequent route updates and is not suitable for a bandwidth constrained telemetry network. We propose a develop a proactive routing protocol that leverages location information combined with limited updates to build a next-hop routing table. However, we are aware of the security concerns in disseminating location information and hence propose several alternatives.

The basic operation of the proposed routing protocol is to maintain a table of available neighbors at any given point of time. The primary mechanism used to by the TA to determine its neighbors is eavesdropping or snooping. Since TmNS is a wireless TDMA network, a TA, if not transmitting itself, listens to all transmissions on the wireless channel. In the proposed scheme, when a TA hears a data packet over the air interface, it adds the source MAC address of the decoded packet to the neighbors table. This implies that if a TA can hear transmissions from a node, it can also communicate with that node. Stale entries are removed from the neighbor table if no transmissions from a TA are heard for a predetermined interval of time (that relates to the anticipated contact duration).

The second part of the protocol is to find the appropriate next hop to forward the data packets. In order to to forward the packets towards a specific destination, additional information such as location data or route updates are required. Below is a list of mechanisms,in the order of their stealthiness, through which such an information can be obtained.

1. TAs include state vector explicitly as a field in the header of AeroNP protocol
2. TAs include only their GPS location as a field in the network packet header
3. The GS periodically broadcasts (optionally on a encrypted channel) the state vector of all the TAs so that each TA can predict its connectivity ahead of time
4. No location information is made available; instead TAs exchange their neighbor table upon contact

In the first two cases, TAs discover both the neighbors and their locations by snooping the network packets. In lightly loaded network conditions, a periodic hello message is sent by a TA to inform other TAs of its presence. TAs forward data packets to the node that is nearest to the destination as calculated from GPS coordinates. We assume that the all TAs are preprogrammed with the location of GSs. However, there would be a time lag during which the TA would snoop out its neighbors. In the third case, the GS broadcasts the information on topology ahead of time so that the each TA can predict its neighbors ahead of time based on the trajectory and forward the data packets to the appropriate nodes. In the last scenario, we assume that no location or trajectory information is made available due to security reasons. Instead, when two TAs are in transmission range, they exchange their neighbor table. Thus each TA can build a partial routing table. Since the network is assumed to be connected, after some initial learning phase, each TA will have the complete routing table. However, this approach could generate significant overhead due to dynamic nature of the TmNS and may have low efficiency due to the delay involved in learning the routes.

Ground Stations are special nodes in this network. They listen to all the transmissions and forward packets that are destined to other GSs. In other words, GSs are universal sinks and may have same MAC address. For uplink data, GS forward data to the TA that is closest to the destination TA. The GS is aware of the location of all TA either from mission planning or learns it in the same manner as other TAs.

We will investigate the tradeoffs in security and performance for the above mentioned approaches. Given the varied nature of the T&E at the MTRBF, it is likely that the routing protocol would have to support multiple modes for both open and secure scenarios.

Quality of Service

The wireless links in the TmNS are bandwidth constrained and are under-provisioned for the telemetry traffic generated during a field test. Hence, it is essential to implement a quality of service mechanism in this network to ensure that high priority data such as command and control can be reliably delivered. The AeroNP protocol uses two fields in the header to specify the quality of service of data packets in the TmNS: data type (e.g command and control, telemetry) and priority with in a given type. The application requirements determine the type and priority for a given data flow and is passed to the network layer through the transport layer (AeroTP) via out-of-band signaling. All nodes in the TmNS implement a scheduling algorithm such as weighted fair queueing based on type and priority. We will investigate various scheduling mechanism to determine the most efficient one for the T&E environment.

Broadcast and Multicast

The AeroNP protocol will support both broadcast and multicast natively. A unique TA MAC address is chosen as the broadcast address. Similarly, a range of MAC addresses are assigned to sub-groups in the TmNS. These multicast address groups are pre-programmed in the TAs and GS. Given the highly dynamic nature of the TmNS, we will investigate if any multicast achieves any efficiency over a simple broadcast. Further, we will coordinate with the iNET MAC group to develop an efficient and scalable multicast solution.

Congestion Control

The link capacities from TA to TA and from TA to GS are provisioned only for the traffic generated during a test. SInce there is no bandwidth to spare on each link between the TA and the GS multi-hop routing could induce severe congestion in the network. A MAC level solution would be to assign more slots to the forwarding nodes than the non-forwarding nodes. Since this is too complex in the highly dynamic environment, we propose a simple congestion control mechanism at the network layer using congestion indicators or back pressure.

In the first mechanism, the TA uses the CI (Congestion Indicator) field to indicate its own congestion level. All packet transmissions from a TA carry the CI field along with the type and priority of the data. Neighboring TAs eavesdrops on the transmission and are made aware of the congestion at a given TA. If a node is congested, the neighbors back off if the data that they have is of equal or lesser priority; higher priority data is nevertheless forwarded to a congested node.

The second mechanism through which congestion control is achieved in the TmNS is back pressure. Each TA again eavesdrops on the neighboring nodes and knows when one of its neighbor is congested and has stopped forwarding its packets. This is possible because, the source MAC address is carried in the header field. Barring malicious nodes, the TA then backs-off. Similarly, in a multi-hop scenario, if a bottleneck is encountered, each intermediate hop either stops or slows down its transmissions to the congested node successively until the source of the traffic is reached.

Task 3: Cross-Layering with iNET MAC and Physical Layers

Cross-layer optimizations are particularly important in wireless networks. In addition to using the service description to assign MAC parameters and TDM slots, the ability for AeroTP to erasure code over multiple paths requires coordination between AeroTP, AeroNP routing, and the iNET MAC. In-band and out-of-band techniques will be applied that will be compatible with the iNET MAC and PHYs.

Deliverable: architecture and design document, publications

Phase 2: Simulation and Evaluation of Protocol Tradeoffs [0.5 page]

Phase 2 will evaluate the suitability and performance of the alternatives designed in phase 1 by simulation. The ns-2 simulation tool will be used and we will leverage a larger simulation framework already under development for the evaluation of resilient transport protocols and cross-layer optimizations. This framework will be incorporated into the AeroSIM ns-2 model. We will use simulations to evaluate the theoretical algorithms developed in Phase 1 and to compare the relative effectiveness of different algorithms, as well as performance relative to unaltered Internet protocols. This will also allow us to verify the effectiveness of the proposed mechanisms over a wide range of network scenarios.

Task 1: AeroTP Simulation and Evaluation

We will simulate various transport mechanisms to evaluate the performance of the data transfer in the face of the challenges and disruptions presented by the TmNS environment. These include data corruption, packet loss, frequrent link-state changes, packet duplication and reordering, and delay caused by network partitioning. It will also allow us to understand what metrics are the most important to have supplied by the routing layer. We intend to simulate multiple data flows and types on TmNS scenarios of various sizes to observe the interaction and congestion behavior both in the context of individual data or control connections and many simultaneous connections. The results of these simulations we will indicate which mechanisms are the most effective, as well as what tradeoffs to expect when we move to the implementation phase.

Task 2: AeroNP Simulation and Evaluation

We will simulate the AeroNP protocol developed earlier in ns-2 simulation environment. The objective, besides functional validations, is to analyze the effect of different choices in mechanism on the overall performance of the protocol. Various parameters that will be considered in this performance analysis include efficiency, delivery ratio, overhead and end-to-end delays. Further, we would analyze the tradeoff between performance optimized mode where location information is available and stealthy mode where either very little or no location information is available. We will compare the various modes of AeroNP against standard MANET routing protocols for varying speeds, density and test scenarios. Finally, we will also evaluate the efficiency of the proposed broadcast and multicast mechanisms and if there is significant difference between them especially in a sparse highly dynamic case.

Task 3: Cross-Layer Simulation with MAC and Channel Model

Develop channel model and model of Eriks FEC; leverage xlayer model

Phase 2 deliverables

Updated design document with simulation results, simulation models and source code, paper(s) submitted to conference or journal.

Because ns-2 is widely used and open source, using this platform will facilitate sharing the AeroSIM ns-2 model with the iNET community and provide a usefull tool both for future research and for simulating communication requirements prior to running actual T&E exercises.

Phase 3: Prototype Implementation of AeroTP and AeroNP [0.5 page]

Phase 3 will prototype the proposed protocols on a testbed of...

Simulations are useful tools for protocol developments, however they do not recreate all the complexities of real systems. For this reason the third phase of this research is to implement our resilient transport protocol and test it over a real network. This phase will validate the simulation model by allowing us to compare the results from the simulation phase with the results from our real-world implementation.

NEED TO DISCUSS...  PCs? KUARs?

Task 3: Cross-Layer Simulation and Evaluation

Develop channel model and model of Eriks FEC; how much do we want to claim about MAC model?

1. Linux with emulated channel conditions and mobility 2. Wireless mobile devices (motes, PDAs) with time-scaled velocity

Phase 3 deliverables

Prototype evaluation report, demonstration, open source code, paper(s) submitted to conference or journal.

Option 1: Field Testing

We propose move the propotype developed to field testing.

Transition [0.5 page]

Transition – Offeror should provide a description of effort’s potential for transitioning to DoD test ranges/laboratories/agencies or insertion into full DE T&E capabilities/systems. Offeror should also indicate which, if any, DoD agencies will be leveraged for effort and their desire to utilize the developed technology.

[TO DISCUSSS]: Are we proposing to implement these protocols or just study, develop and simulate? If we only propose simulations and not actual implementation, it would mean that this cannot be used in the iNET project without significant work.

References [0.5 page]

[NDR2004] iNET Needs Discernment Report, version 1.0, May 2004

[IWG2008] iNET Working Group, www.inetprogram.org

[TSR2004] iNET Technology Shortfalls Report, version 1.0, July 2004

[ISA2007] iNET System Architecture, version 2007.1, Jul. 2007

[GSA2007] iNET TmNS Ground Segment Architecture, version 2007, Jul. 2007

[TAA2007] iNET TmNS Test Article Segment Architecture, version 2007, Jul. 2007

[SB2007] K. Scott and S. Burleigh, "Bundle Protocol Specification", RFC 5050 (Experimental), November 2007

[DMT1996] Robert C. Durst, Gregory J. Miller, and Eric J. Travis, "TCP Extensions for Space Communications", Proc. ACM MobiCom 1996, pp.15–26, 1996

[KS2004] Rajesh Krishnan, James P. G. Sterbenz, Wesley M. Eddy, Craig Partridge, and Mark Allman, "Explicit Transport Error Notification (ETEN) for Error-prone Wireless and Satellite Networks", Computer Networks, 46(3):343–362, 2004

[FT2001] Fabrice Tchakountio and Ram Ramanathan, "Tracking Highly Mobile Endpoints", Proc. ACM WOWMOM 2001, pp. 83–94, 2001

[MB1999] David A. Maltz and Pravin Bhagwat, "TCP Splice for application layer proxy performance", Journal of High Speed Networks, 8(3):225–240, 1999

[BKGMS2001] J. Border, M. Kojo, J. Griner, G. Montenegro, and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135 (Informational), June 2001

[BPK1999] Hari Balakrishnan, Venkata Padmanabhan, and Randy H. Katz, "The Effects of Asymmetry on TCP Performance", ACM Mobile Networks and Applications (MONET), 4(3), 1999

[RS1996] S. Ramanathan and M. Steenstrup, "A survey of Routing Techniques for Mobile Communication Networks", ACM/Baltzer Mobile Networks and Applications, pp. 89–104, 1996

[N2006] M.J. Neely, "Optimal backpressure routing for wireless networks with multi-receiver diversity", Proceedings of Conference on Information Sciences and Systems (CISS), Invited paper on Optimization of Communication Networks, March 2006

[M1990] A. J. McAuley, "Reliable broadband communication using a burst erasure correcting code", Proceedings of the ACM symposium on Communications architectures & protocols, p.297–306, September 26-28, 1990, Philadelphia, Pennsylvania, United States

Need to refer the SNOOP PROTOCOL