A Cross-Layer Communications Substrate forTactical Information Management Systems

Marco Carvalho andAdrian Granados

Institute for Human & Machine CognitionPensacola, FL, USA

Waseem Naqvi andAlfred Brothers

Raytheon CompanyFort Wayne, IN, USA

James P. Hanna andKurt Turck

Air Force Research LaboratoryRome, NY, USA

ABSTRACT

In this paper we introduce XLayer, a cross-layercommunications substrate for tactical InformationManagement Systems which enable nodes on a radionetwork to seamlessly communicate with nodes ondifferent heterogeneous networks. While conventionalcross-layer strategies for tactical environments tend tofocus on the localized optimization between neighborlayers of the communications stack, our approach focuseson the interface between middleware and the underlyingcommunications infrastructure.

The XLayer communications substrate leverages nativeinformation and services available at the tacticalcommunications infrastructure to improve the functionallyand capabilities of overlay applications and middleware.The XLayer also provides the necessary interfaces andmechanisms to enable application-driven requirements toparameterize and regulate the operation ofthe underlyingcommunications infrastructure.

After a brief description of the target environment andsystem requirements we will introduce the proposeddesign for the cross-layer communications substrate,highlighting specialized controllers and adaptors forcommunication interfaces and tactical radios. We willthen introduce new cross-layer strategies for discovery,routing and transport targeted to InformationManagement System (IMS)-support, followed by our NS-2simulation results, analysis, and conclusions.

INTRODUCTION AND BACKGROUND

The Air Force Scientific Advisory Board (SAB)completed a Summer Study in 1999 [1, 2] where thecritical need for a comprehensive combat informationmanagement system was identified. This InformationManagement System (IMS) concept was titled the JointBattlespace Infosphere (JBI). The vision of JBI was an

978-1-4244-2677-5/08/$25.00 ©2008 IEEE

IMS that could integrate information from a wide anddiverse variety of sources, as well as aggregate thisinformation and disseminate it in the proper format andgranularity to the appropriate consumers. The mantra forJBI became: " ... provide the warfighter access to the rightinformation in the right format and at the right time."

Subsequent to the publication of the SAB findings,scientists and engineers at the Air Force ResearchLaboratory's Information Directorate (AFRL/RI) beganresearching technologies and techniques that could bebrought to bear in solving these challenges. The results ofthis in-house research and development initiative havebeen realized in a comprehensive IMS referenceimplementation known as Apollo that addresses many ofthe deficiencies identified by the SAB. Further, theefficacy of Apollo has been demonstrated in operationalsituations [3]. The JBI vision embodied in Apollo is thesubject of continuing research [4], specifically in the areasof Quality of Service (QoS) provisioning and federation ofmultiple IMS instances across information and securitydomains.

With the proliferation of Unmanned Aerial Systems(UAS) and the emergence of Micro Unmanned AerialVehicles (MUAVs) there is a growing interest and need tomanage the information produced by these sensorplatforms at the point of origin. The decreasing cost andthe increasing processing, memory, and storage capacityof computing payloads that can be integrated onboardthese systems will enable tactical informationmanagement capabilities that will revolutionize the abilityof warfighter to share information and real-timesituational awareness (SA).

However, the nature of the underlying wirelesscommunications infrastructure of these platforms, coupledwith their characteristic multi-hop and dynamic networktopologies, presents a new and complex set of researchchallenges that must be addressed if we are to achieve the

lof7

vision of information management in tactical battlefieldenvironments.

The tactical JBI ConOps calls for an InformationManagement System (IMS) that enables data providersand consumers to publish and subscribe to informationobjects on demand. Information objects are thenseamlessly matched, aggregated and properlydisseminated, regardless of the underlying complexitiesand dynamic nature of the communications infrastructure.

New methods and approaches are necessary to facilitatethe adoption of current tactical middleware and tools forInformation Management (1M). To be effective, thesolution must be cross-layer in nature, considering boththe requirements and capabilities of the InformationManagement Systems and the underlying communicationsinfrastructure.

In this paper we introduce XLayer, a cross-layercommunications substrate designed to provide a two-wayinterface between applications or tactical middleware andthe underlying communications infrastructure.

In support to the application, the XLayer substratemonitors, abstracts and represents the characteristics andcapabilities of the underlying communicationsinfrastructure so applications can better adapt and allocateresources for a given task.

For the communications infrastructure, applications mayprovide information about resource requirements (bothcomputation and communications) or utilization patterns.This information can be used by the underlyingcommunications infrastructure to better allocate resourcesand capabilities in response to changes in demand orproactively, based on explicit application requirementpatterns.

The cross-layer nature of our proposed strategy refers tothe interaction between middleware and the differentlevels of the communications substrate, and not solely tothe conventional view of direct information sharing andinteractions between neighboring layers in thecommunications stack.

RELATED WORK

Basic communications and computation tasks such asplatform discovery, resource allocation, and efficientrouting and transport are often more challenging indynamic tactical environments. Furthermore, tacticalnetworks are required to seamlessly and efficientlyinterface and inter-operate with fixed (or 'wired') supportnetworks.

Traditionally, cross-layer strategies for tactical andMobile Ad hoc Networks have primarily focused on short­term adaptation (and state reporting) between neighboringprotocol layers.

In general, most implementations are based on variationsof QoS protocols inherited from the wired networks andstill utilize some of the notions of signaling andcoordination for resource reservation. The basic goal ofmost traditional cross-layer strategies is to monitor anddetect short term changes in channel conditions (orcompeting traffic) to notify upper layers about new QoSconditions. In most cases applications are generallyexpected to adjust data rates accordingly when notified bya neighboring layer that current service expectations arenot longer available.

As illustrated by Goldsmith [5], the actual adaptation andreporting between layers is generally done after local layeradaptations are no longer possible (or cost effective). Thedifferent time-scales at each layer usually imply that localadaptation within each layer generally occurs first (andmore frequently) than adaptation between layers.

Protocols like dRSVP [6], for instance, provide per-flowend-to-end bandwidth guarantees for a range ofrequirements (as opposed to a specific requirement like inRSVP). In dRSVP 'routers' exchange bandwidthreservation details through a signaling protocol and theflow is either denied access or dropped if channelavailability becomes insufficient. Once bandwidthresources are allocated, the application is responsible forenforcing the data rate and for periodically refreshing itsallocation state.

Signaling for short-term resource reservation is also usedby the SWAN Protocol [7]. SWAN, like dRSVP is fullydecentralized, however it is best effort only and makes noassumptions about underlying QoS capabilities from theMAC layer. The signaling in SWAN is intended for flowadmission and the cross-layer nature of the protocol lies inthe fact that MAC level packet delay information is sharedand used for estimating medium access contention. After aflow is admitted in SWAN, theprotocol uses the packet'sexplicit congestion notification flag (ECN) to notify thatrequested services are no longer supported for that flow.

TIMELY [8] is another cross-layer architecture thatprovides link layer scheduling, resource reservation andadaptation, as well as priority-aware transport protocolthat self-regulates flow based on feedback from the lowerlayers. TIMELY was initially proposed for cell-basedwireless networks, and helped create the basis forsubsequent ad-hoc specific architectures and protocolswith similar capabilities like Spine [9] and CEDAR [10].

20f7

CROSS-LAYER STRATEGIES FOR TACTICALINFORMATION MANAGEMENT SYSTEMS

Tactical networks apply in many domains, such as air-air,air-ground, ground-ground, air-space and ground-space,each of which has different requirements andcharacteristics. For example, dismounted networks andtactical air have many heterogeneous nodes, at lowbandwidths. These networks have limited beyond line ofsight capabilities.

Today's primary Tactical Internet for military applicationsutilizes the EPLRS (Enhanced Position LocationReporting Systems) network with a max bandwidth of 1Mbps while the lower part of the network is limited to 1.2- 4.8 kbps using SINCGARS (Single Channel Ground andAirborne Radio System)

The next echelon network provides higher-bandwidthcommunications support between airfields, forwardoperating bases, and headquarters. It is generallycomprised of fewer nodes, is often static, and resides onmore capable platforms.

A tactical IMS must be able to seamlessly operate acrossthese different types of networks and, where appropriate,leverage the capabilities and services available by eachenvironment to better support the system-wideinformation management tasks.

The XLayer communications substrate proposes toaddress these requirements through four core capabilitiesconsidered critical for the support of tactical InformationManagement Systems:

• Seamless IP-like addressing and communicationsacross multiple heterogeneous networks, protocolsand data links. This capability enables disparatesystems and networks to locate and interface withone another without the need of pre-defined fixedgateways.

• Efficient and predictable detection, addressing andlocalization of platforms and services on complexand dynamic environments.

• Monitoring of network, link capacity andreliability, enabling advanced QoS support andthe online adaptation of applications.

• Data routing and dissemination mechanisms thatare tolerant to node failures, network disruptions,and link delays.

These core capabilities are, in our view, necessary for thedevelopment and implementation of tactical informationmanagement systems. If not provided or supported by the

30f7

underlying communications infrastructure it has to becreated at the level of the applications or middleware(often with redundancy and efficiency costs). The XLayercommunications substrate aims at providing suchcapabilities.

As illustrated in Figure 1, the goal is to create acommunications substrate that abstracts allcommunication interfaces and networks through acommon API and control mechanisms. The XLayersubstrate intercepts calls from applications to any interfaceand properly handles the discovery, routing and datadissemination across the heterogeneous environment.

Figure 1. The Cross-Layer Communications Substrate

By abstracting the capabilities and constraints of theunderlying communications infrastructure through a singlecommon API, the XLayer substrate allows applicationsand tactical middleware to address the underlyingcommunications infrastructure in a common way,regardless of their tactical nature or not, completelyabstracting the existence of gateways, shared links, etc.

THE XLAYER ARCHITECTURE

One of the main requirements for the proposedcommunications substrate is the capability to supportheterogeneous communications interfaces and networkswith different characteristics and capabilities.

The XLayer substrate is a service that exists in multiple(or all) nodes in the network. The XLayer service

abstracts, monitors and controls all communicationsinterfaces at each node to provide a common view of thecommunications infrastructure. As illustrated in Figure 2,the architecture is designed to be modular and extensible,with three types of loadable components (NetworkAdaptors, Controllers, and Application proxies .andproviders) linked together through a set of core servIcesand data structures.

~

c=)

Figure 2. The XLayer Architecture

NETWORK MANAGER

The Network Manager is one of the core containers thatdetects, monitors, and controls all network interfaces inthe host. In addition to standard network interface APIs,the Network Manger provides the APIs for creating virtualnetwork interfaces to maintain static tunnels across remotenetworks (when necessary), and also supports customizedadaptors for specialized radios to be loaded as needed, asillustrated in Figure 3.

Specialized Adaptorfor Radio X

Figure 3. Customized Adaptors for Specialized TacticalRadios

Customized adaptors can be used, for instance, to connecta serial radio to a host such as the Serial Microhard radio.In this case, a serial link adaptor is used to represent that

interface as an IP interface, with a routable IP address(dynamically created by the Network Manager).

Customized adaptors are also responsible for providingthe link monitoring capabilities for specialized radios. Theway in which such information is obtained and monitoredis likely to be radio specific, and may rely on SNMP, OS­level monitoring, or active beaconing. Common linkstatistics such as capacity, utilization and average packetloss is reported to one of the core services in the system(the Node Monitor Service).

Not all tactical radios necessarily require a customizedadaptor. The Fire Series radio, for instance, if configuredin one of its IP modes, does not require a specializedadaptor for integration - one such mode incorporatesTCP/IP layered over MIL-STD-188-184.

Using adaptors for different types of tactical (IP and non­IP) radios, the XLayer architecture is essentiallyanalogous to a centralized bus with a well-knowninterface. The XLayer may effectively be used to enhancethe connectivity between EPLRS and other networks likeDAMA SATCOM, since most components arenarrowband radios with low throughput capabilities.

Because each interface is abstracted from applications, thecross-layer is also capable able to better manage thepacket sizes sent across each link. The Fire Series radiosfor instance, have long channel access delays preventingmultiple radios from transmitting often on the samechannel. A similar constraint is also true for the EPLRSfamily of radios, which has a set number of transmitopportunities with fixed message lengths. Transmittingvery small messages in such kinds of radios will consumethe same bandwidth as larger messages and will under­utilize the channel.

2 bytes

lI:IIonoqnnnr~, ~"''" <~~

Figure 4. Example of an aggregate data packet.

40f7

The XLayer Propagation Service (one of the substrate'score services) handles that problem by building differentdata packets for each interface, and properly aggregatingmultiple messages into a single packet.

The data structure illustrated in Figure 4 allows formultiple messages to be combined into a single packet. Itsupports a simple mechanism for compression (omittingredundant fields) and can be forwarded transparently(although not necessarily parsed) by nodes in the networkthat are not running the XLayer service.

APPLICATION PROXIES AND PROVIDERS

Proxies and providers (right hand side of Figure 2) arealso used to allow generic applications and components tointerface with the cross-layer service. A GPS provider,for instance, may connect to the cross-layer service toprovide position information, which will then be availableto other core services and controllers in the cross-layer.

Providers are generally used to provide information one­way, normally from some external component or process(i.e. GPS, Robotic Platform, Battery Level Monitors, etc.)to the cross-layer service.

The cross-layer service provides a pub-sub system forinformation and state distribution. Providers andapplication proxies update state specific system metrics(such as platform position) with instantaneous updatesfrom external sensors.

Metrics are stored in short (circular) time-series by theNode Monitoring Service. Each variable is identified by a2-byte ID, which is used both for update and lookup.Multiple providers may report the similar metrics fromdifferent sensors (as illustrated in Figure 5).

Figure 5. XLayer Providers for Platform Location

Policies regulating the Node Monitoring Service willdetermine how such metrics will be handled (i.e. will beaveraged, or one takes precedence over the other).Applications may query different metrics by their last

5 of?

(instantaneous) value, their average, variance and trend.The cross-layer updates and maintains these statistics asnew metric values are added to the system.

Similarly to Adaptors (used by the Network Manager tosupport legacy radios and interfaces), specialized XLayerProviders can also be created for custom and legacyhardware. There is a simple Adpator API provided by theXLayer to facilitate the process.

CONTROLLERS

Another important set of components In the XLayerservice is the XLayer Controller set. Controllers aresimple feedback control algorithms that are independentlyloaded and executed as part of the cross-layer substrate.

Controllers have direct access to all monitoring andcontrol capabilities enabled by the XLayer core services,as well as state information maintained by the NodeMonitoring Service and direct access network and proxyadaptors.

The concept of a controller allows a higher-levelapplication to 'push down' to the cross-layer fast-responsecontrol algorithms that can be parameterized to quicklyreact to changes in the system. For instance, a topologycontrol algorithm based on local node density may beloaded by some higher-level application to maintain anaverage local density through power control.

A controller for such topology management algorithm canbe parameterized to maintain a specific density and,quickly respond to local changes in the network topology.In general controllers are designed to provide an efficientmechanism for applications to monitor and regulate lowerlevel events at the communications infrastructure that maywork at very different time scales.

Another example of a controller is the cross-domainrouting for heterogeneous networks. The bridge acrossdisparate networks running different protocols orwaveforms is often provided by pre-defined gatewayscapable of handling both sets of protocols. While aneffective approach for planned network deployments, thenotion of pre-defined connection points for inter-networkconnectivity is not necessarily appropriate for tacticalenvironments.

The challenges involved in such task for tactical domainsinclude not only the identification and configuration ofnodes that will become gateways between differentnetworks, but also the propagation or the appropriaterouting information, the traffic load balance acrossmultiple gateways and also the release and re-allocation of

gateway roles between nodes as the network moves andthe topology changes.

Figure 6. A Dynamic Gateway Controller

Figure 6 illustrates a simple scenario where two distinctnetworks moving by each other will temporarily comewithin communications range from one another. In thisexample, a node located in network A (the client), at thebottom of the image is currently looking up a service thathappens to reside in network B (the server). When located,the client will send a series of data packets to the serverrepresenting, for instance, the upload of a file.

In this example, both networks are operating at thecompatible frequency, using compatible physical andMAC level protocols. While packets can be passed fromone network to another (while within communicationsrange) each network is running a different routingprotocol.

The goal of the cross-layer controller in this example is toidentify (on demand) the different protocols required toenable communication across both networks anddynamically allocate gateway nodes that will translateroutes to enable the connectively between the client andserver.

The controller in this example leverages topologyinformation reported by the cross-layer topology serviceto elect, through a fully distributed algorithm, temporarygateway nodes. Temporary gateway nodes run bothrouting protocols, and report all nodes of one side of thenetwork as immediate neighbors to itself, in relation to theother side of the gateway. Effectively, that creates agateway for the entire network.

Routes associated with the newly identified gateway willthen propagate to enable the data flow between the clientand server. The algorithm is simple but very effective, assoon as the networks come within communications rangefrom one another, a number of gateways are quicklyenabled and data starts flowing across the networks.

60f7

Furthermore, the overhead in terms of additional routeadvertisements is bounded, since it is a function of the(pre-defined) maximum number of dynamic proxies, andindependent of the size 0 the networks. For example, inthe 40-node example illustrated in Figure 6 there are up tothree proxy nodes at any given time, and the averageoverhead in routing advertisements is 8.6 (±1.5)% with95% confidence.

Figure 7. Dynamic Gateway Allocation and Maintenance inTime

Load balancing can be achieved by creating specificweights for the virtual one-hop neighbors created by thetemporary gateways. If weights are assigned correctly, i.e.proportionally to the actual weight of each node in thetopology, the route calculation will take that weight intoaccount when choosing the gateway for a specific traffic.

This qualitative example illustrates some of the benefits ofcross-layer strategies in support to InformationManagement Systems. Controllers can be used to enablevery complex, higher level tasks through simple feedbackcontrol strategies. The example shown in this paper,although simple, illustrates the potential of the proposedcommunications substrate.

CONCLUSIONS AND FUTURE WORK

In this paper we have introduced the XLayer as aneffective communications substrate architecture andcontrol algorithms for several tactical tasks. We have alsodescribed one qualitative example of how such capabilitycan be used, for instance, in the context of dynamicbridging across heterogeneous networks. The sameapproach illustrated in this example for routing protocolscan be easily extended to other approaches such asadaptive discovery, topology management and others.

Using the notion of interface adapters, tactical (IP andnon-IP) based radios can often be easily supported by thecross-layer substrate without modification of the hostradios. This is a significant advantage, as it does notrequire the retrofit of conventional radios deployed and in

use. The current implementation (release 1.0-beta) of theXLayer substrate includes specialized adapters forstandard 802.11 wireless radios (Linksys WRTSL54GSand Asus wireless routers), for dual-interface custom builtsoekris card-based wireless nodes (using 802.11x and900MHz ubiquity cards), and also for the Spectra 910Aserial microhard 900MHz radios.

The release also includes controllers for adaptive gatewayselection for cross-domain routing, adaptive service andplatform discovery, multi-path routing and topologycontrol. In beta mode, the release has been tested andevaluated in emulated environments and small robotictestbeds using ground robots. The XLayer substrate hasalso been preliminarily tested and evaluated inrepresentative tactical environments, such as the Army'sC4ISR on-the-move experiments in 2007 and 2008.

The XLayer concepts described in this work can providesignificant utility to DoD and others users as well (e.g. thefirst responder community). They have similarhierarchical networks from narrow band, spottyconnections to high bandwidth buses. The XLayer canhelp route across the networks dynamically as thesituation arises.

XLayer controllers and algorithms are also highlymodular, and easily portable to other communicationsystems and/or tactical middleware. One of the programsthat may leverage some of the algorithms developed bythe cross-layer communications substrate is the AFRLJCAN project.

The AFRL JCAN program goal is to develop anintelligent information management capability tomaximize the utilization of all available communicationbandwidth on the aircraft. By enhancing Mobile IP andConcurrent Multipath Routing, and augmenting with newconcepts such as Explicit Channel Reservation andWeighted Fair Queueing, dial-up rate IP connectivity isenabled for airborne platforms by utilizing the existingradios/links on the aircraft.

It also supports priority and pre-emption for IP basedapplications such as email, chat, imagery, and file transfer.JCAN also can handle the sporadic connectivityassociated with airborne platform dynamics (i.e. aircraftbanking which causes loss of link due to antennablockage) and mobility via its integration of intelligentproxies.

With these proxies and the additional level of cross layerprotocol optimization inherent in its components whichspan the OSI stack, JCAN can adapt to conditions inherent

in data flows across many different simultaneouscommunication links.

REFERENCES

[1] Scientific Advisory Board, "Building the JointBattlespace Infosphere Volume 1: Summary," SAB­TR-99-02, 2000.

[2] Scientific Advisory Board, "Report on Building theJoint Battlespace Infosphere Volume 2: InteractiveInformation Technologies," SAB-TR-99-02, 1999.

[3] Northrop Grumman Integrated Systems PressRelease:http://www.irconnect.com/noc/press/pages/news_releases.html?d=124312

[4] Mark Linderman, et. aI, "A Reference Model forInformation Management to Support CoalitionInformation Sharing Needs" presented at the 10thInternational Command and Control Research andTechnology Symposium, 2005.

[5] Goldsmith, A., Wicker S., Design Challenges forEnergy-Constrained Ad hoc Wireless Networks. IEEEWireless Communications, August 2002.

[6] Mirhakkak, M., Shult H., Thomson, D., DynamicBandwidth Management and Adaptive Applications fora Variable Bandwidth Wireless Environment, IEEEJSAC, Vol 19, No. 10, October 2001.

[7] Ahn, G.S., Campbell, A., Veres, A., and Sun L.,"Swan: Service differentiation in stateless wireless adhoc networks," in IEEE INFOCOM 2002.

[8] Bharghavan, V., Lee, K., Lu, S., Ha, S., Li, J., Dwyer,D., The TIMELY Adaptive Resource ManagementArchitecture, IEEE Personal CommunicationMagazine, Vol. 5, No.4, August 1999.

[9] Sivakumar, R., Das, B., and Bharghavan, V., Spinerouting in ad hoc networks. Cluster Computing,1(2):237--248,1998.

[10] Prasun S., Raghupathy S., Vaduvur H., CEDAR: ACore-Extraction Distributed Ad Hoc RoutingAlgorithm, The 18th Annual Joint Conference of theIEEE Computer and Communications Societies,INFOCOM '99 New York, NY, USA, pp. 202-209IEEE, March 1999.

7of7