Abstract—Mobile tactical MANETs are interconnected via a quasi-static backbone network (QSN) that is relatively stationary and has substantial radio bandwidth capability. Because of high mobility and terrain sensitivity, the bandwidth available to mobile nodes within the MANET may vary significantly over time. During the periods where the bandwidth available is reduced, MANET nodes may be unable to handle the information load sourced from or distributed via the QSN. Furthermore, end-user devices and end-users themselves may have limited capability to receive/process data. Thus, the data delivered to tactical MANETs needs to be carefully managed. In previous work, we proposed Heterogeneous Intelligent Filtering (HIF) in multi-domain heterogeneous networks, for intelligent active filtering and transformation of the data to match network and end-user capacity. In this work2, we report on extending HIF to militarily important applications such as XMPP-based chat, SOA Web-services, and VOIP applications. We also provide experimental results based on outdoor testing of the filtering and content adaptation capabilities of HIF agents deployed in an HMS radio inter-network at Ft. Monmouth, NJ.
The highly mobile nature and terrain sensitivity in tactical MANETs leads to varying patterns of bandwidth available to mobile nodes within the MANET. Typically, tactical MANETs are interconnected via one or more gateways to a quasi-static upper-echelon backbone network (QSN) that is generally relatively stationary and has higher bandwidth compared with MANETs (shown in Figure 1). When the available bandwidth is low, MANET nodes may be unable to handle the information load sourced from or distributed via the QSN. The difference may be dramatic –for example a node in a QSN may be able to handle a multimegabit/s video feed while the MANET node may only be able to handle orders of magnitude smaller bandwidth.
In our previous work [1], we proposed Heterogeneous Intelligent Filtering (HIF) in multi-domain heterogeneous networks, for intelligent active filtering and transformation of data to match network and end-user capacity. HIF agents
rapidly and autonomously adapt the flow of information content to the changing mission needs and network characteristics. The filtering employed by the HIF agents is driven by both QoS feedback from the network and applications. Deployment of HIF filters are most effective at the MANET gateways, which are the points in the network where discontinuities in network capability occur. In this paper, we report on our experience generalizing and extending the set of militarily important applications supported in HIF, including XMPP-based chat, SOA Web-services, and VOIP applications. We provide experimental results based on outdoor testing of HIF agents deployed in an HMS [14] radio inter-network at Ft. Monmouth, NJ.
II. BACKGROUNDA. Hetergenous Intelligent Filtering (HIF) Overview
The Heterogeneous Intelligent Filtering (HIF) concept is based on the idea of network-based data transformation, and data filtering through agents distributed in the network. A tactical MANET is expected to have significant variations in available bandwidth, packet loss, and user demands as a function of time. For real-time services, a traditional approach for handling varying user demand i s through admission control. Unfortunately there are tactical scenarios for which this approach does not work [1], a key problem being how to choose which flows to drop. The HIF mechanism we are proposing may be used in conjunction with admission control or not.
Figure 1: HIF agents in MANET internetworking
In HIF, adaptation takes place by data-reducing existing flows so that they consume less bandwidth, while attempting to maintain the utility of the information being transmitted[16]. By adaptively decreasing the demand on the system, we can allow new flows to enter the system without having to remove flows already in the system. Figure 1 depicts a typical MANET internetworking scenario, where tactical MANETs are connected to an upper echelon quasi-static
1 Contact Author2 Prepared through the PILSNER program. The U.S. Government is authorized to reproduce and distribute reprints for Government purposes notwithstanding any copyright notation thereon.
Upper Echelon Mobile Backbone Network
Ad hoc Mobility (MANET1)
Ad hoc Mobility (MANET2)
Gateway agent
Wireless LOS
Wireless LOS
Client agents
S2
R3
S1
R1
R2
S3
The 2010 Military Communications Conference - Unclassified Program - Networking Protocols and Performance Track
backbone network (QSN). Although QSN is mobile, it is called quasi-static relative to degree of the mobility of MANETs. The sources of multicast data can be seen originating from both the backbone and edge MANETs. In this work, we described two types of HIF agent: A Gateway agent (detailed in Figure 2) runs on the
gateway nodes that connect the upper echelon mobile backbone to the MANET.
A Client agent resides on a selected group of nodes of the MANET. The client agent has a subset of thefunctionality of the gateway agent.
The Gateway agent consists of the following modules: o Application Gateway:
This module provides the core filtering and adaptation functionality of the gateway. This module takes in application packets and applies appropriate transformation and filtering mechanisms to reduce the data transmitted. An application gateway is instantiated for every active session i.e. sessions for which there are receivers in the MANET. The Application Gateway module contains the followingentities:- Parser: Parses the application packet received by
packet receiver to extract the application specific information.
- Scoping: Determines if the application packet received within a session i s relevant to the MANET. The relevancy of the packet is determined by “scoping rules” which can be configured by an administrator of the gateway. An example of a scoping rule is for the gateway to drop all Situational Awareness (SA) packets that are beyond a 10 km radius of the gateway.
- Filtering: Implements various filtering algorithms such as transcoding or time-series based filtering mechanisms to reduce the bandwidth used on MANET. The filtering rules are dynamically adapted based on inputs from the adaptation module.
- Persistence and Replay: Persistence provides mechanisms to store information from application packets arriving at the gateway for future play-back. Replay provides mechanisms to receive “replay” requests from a client and replay the relevant persisted data to the client.
- Transport Adapter: Provides mechanism to change transport protocol for information passing from backbone to MANETs. For example reliable UDP could be used instead of TCP.
- Application Packet Sender: Consists of a protocol and transport specific socket to send the application packet to the MANET after the filtering and adaptation mechanisms have been applied.
- Application Packet Receiver: Consists of a transport and protocol specific socket that reads application packets coming to the gateway from the backbone.
o Adaptation Module: This module keeps track of both network-derived and session-derived QoS information, and decides on the appropriate data transformation and filtering mechanisms to
be applied to new and existing sessions. Each data transformed version of a session is referred to as an Operating Point. Adaptation allows the bandwidth of the application to be reduced, and the packet loss resilience to be increased in response to the changing performance.
Figure 2: Gateway Design
The adaptation module learns of the QoS informationfrom the MMP QoS Report messages that are sent by the client agents to the Gateway agent. o Service Discovery Module:
This module is responsible for discovering the sessions that are available in the backbone and advertising them into the MANET. Client agents in a MANET use the advertised session list to discover the available sessions that can be received.o Session Manager:
This module manages the creation and deletion of application gateway instances. Application gateways are dynamically created when a client in a MANET requests a session from the session manager.
The following components of the gateway are not depicted in figure 2:o Network Awareness:
This module implements active probing mechanisms for estimating bandwidth and loss QoS within the network and is implemented in both gateway and client agents.o MANET Management Protocol (MMP):
MMP performs HIF control functions including support for multicast group management, and is responsible for control communication between the application server and clients in the MANET.
B. Related WorkAdaptation of voice and video media content has been
previously described in the context of wired networks with different access types and capabilities (see for example [2] and [3]). Adaptation of web based content based on other constraints such as device capability has been studied in the context of pervasive computing. In [20], an adaptive web content transformation proxy solution is proposed aiming to balance the presentation quality (focusing on HTML based web pages with web data compression) and the server workload based on available resources. In [19], XSLT based content adaptation based on network policy, access policy and server load is described. In [18], a distributed service-
888
based solution for content adaptation has been proposed that focuses on dynamically chaining different web based services to best fit the delivery context. In [4] adaptation of proxies in a mobile environment was considered, and it was concluded that protocol filtering was preferable to application filtering. In [1], it is noted that application filtering is valuable because in situational awareness [5], effective filtering needs to be based on application attributes such as geographical coordinates, roles and priorities. There are several works, such as [6] that perform filtering considering user intent, which is also being considered in HIF.
Figure 3: Inline Gateway
III. APPLICATIONS AND FILTERS
In this section, we discuss the militarily important applications such as XMPP-based chat, SOA Web-services, and VOIP applications, and describe how they may be filtered in response to network changes. First we distinguish between two types of HIF Application Gateway: 1) An Inline Gateway (shown in Figure 3), and 2) an External Gateway(shown in Figure 4). Each type of gateway is used for filtering different applications.
Figure 4: External Gateway
The essential difference between the two types is that the External Gateway does not implement scoping and filtering rules, and requires an external agent (for example, an externally controllable media transcoder) to accomplish content adaptation. In contrast, the Inline Gateway performs the function of parsing the application packets and invoking the scoping and/or filtering rules to process, filter and scopethe serviced packet streams.
Our gateway component design is flexible and covers a broad range of capabilities: they perform inline or external functions, support multicast or unicast applications, and filter not only voice and video but also data traffic. The VLC and IVOX gateways are external gateways supporting
multimedia streaming and interactive voice applications,respectively to clients in a multicast group. The C2MINCS, Chat and SOA gateways are inline gateways that filter XML data types; the C2MINCS gateway support multicast clients while the Chat and SOA gateways support unicast clients.
A. MultimediaThe gateway for audio/video streaming multimedia
applications is an external HIF gateway and uses the well-known VLC [7] software system as transcoding engine for audio and video. The Filtering module implements a scheme to transcode a voice/video session using a decode/-re-encode approach. The choice of decode/encode parameters is guided by the adaptation module. For audio filtering, RTP transport is assumed. The audio filter transcodes a mp3 Audio stream of 128 kbp s into another MPEG Audio at 56 or 48 kbps. The video filter is used to transcode video that has been encoded using MPEG2, MPEG4 or H.264 (with MPEG Transport Stream (mpeg-ts) as the multiplexer) for into various lower rate forms. The format of the transcoded stream may or may not be the same as the original stream.
There are two video filters currently implemented in the system: (1) A video filter that transcodes H.264 encoded video stream (assuming 512 kb/sec, 320x240, 25 fps source stream) into another H.264 stream at the following bitrates: 256 kb/sec, 128 kb/sec, and (2) A video filter that transcodes MPEG4 encoded video stream (assuming 512 kb/sec, 176x114, 15 fps source stream): into another MPEG4 stream at the following bitrates: 128 kb/sec.
The Persistence module supports the replay ofcontinuous media sessions upon request, going back up to nseconds of playback time into the stream. It consists of a recording channel and a replay channel, which are logically decoupled. The recording channel is activated when the session is first activated at an application gateway; it taps into the inbound raw data stream from the backbone (not filtered, scoped or otherwise transformed) and saves it to persistent storage. The Replay channel is activated by replay requests received from the MANET and responds to the replay requests using the saved data.
B. Situational Awareness (SA)C2MINCS [5] is a SA application developed by the US
Army’s CERDEC. The HIF C2MINCS gateway is an inline gateway that filters C2MINCS data traffic. The Application Packet Receiver consists of a multicast socket to readC2MINCS packets arriving from the backbone. The Application Packet Sender consists of a multicast socket to send C2MINCS packets to MANET.
The Parser parses each C2MINCS packet and extractsthe application specific information. C2MINCS uses XML messages with a COT schema to describe the different SA messages [9]. Table 1 shows an example of a Scoping table. The attributes could be matched with required values defined by filter rules; for instance radius could be matched with say 10km and based on the Action defined, the packet will either be accepted or discarded.
The Filtering module implements the filtering mechanisms for C2MINCS message to selectively drop packets. Events from sources that continually send updates
889
(such as blue force tracks) or other that are deemed to be not important can be selectively dropped.
Table 1: Scoping rule for C2MINCS
The state of a C2MINCS session is defined in terms of the entities represented in the application. The state is thecollection C of all entities E such that, for all entities E in C, when the stale field of E is larger than the current time, there exists no other entity E’ such that:
uid(E’) = uid(E); time(E’) > time(E);The C2MINCS Persistence module maintains the current
state of a session and allows a C2MINCS client agent to synchronize to this state in case it joins the MANET late, restarts, or otherwise loses state information.
C. ChatOne of the unicast applications supported in HIF is Chat
based on the eXtensible Messaging and Presence Protocol (XMPP) [11]. This protocol is widely used for real-time messaging with key applications being IM by popular servers such as Googletalk. The XMPP protocol uses TCP primarily for client-to-server and server-to-server communication, although there are extensions for XMPP over HTTP.
The HIF Chat inline Gateway runs XMPP over Reliable UDP (RUDP) [10], [17].The primary reason is that TCP (which is used by XMPP by default) has proven to be unsatisfactory in MANETs. Losses in communication over wireless links cause retransmissions, which are incorrectly understood to be congestion. This causes the TCP window size to reduce drastically leading to poor performance [10]. For this reason, we employed proxies that use TCP on the client and server facing ends and RUDP on the MANETfacing ends. The XMPP Chat gateway is used as an intercept for filtering messages from the XMPP server to the client(shown in Figure 5).
The Application Packet Receiver is a TCP Socket Stream between the gateway and the XMPP chat server (e.g. Openfire [15]). The Application Packet Sender is also a TCP Socket Stream between the gateway and the RUDP proxy in the gateway. The Parser parses each XMPP packet and extracts the application specific information. Each packet contains a XMPP payload stanza which is itself an XML object. Since is not possible to use canonical XPath based parsing for XML streams, text-based parsing is used instead. The Filtering module interprets content from the chatpayload. When filtering is enabled via the operating point provided by the adaptation module, payloads that start with a pre-defined keyword (e.g., PRIORITY) are passed by the gateway – all other payloads are dropped. Note that Stanza Interception Filtering Technology Extension (SIFT) [11] based filtering that can also be performed at the XMPP chat server – this is being investigated as a future extension to HIF.
D. SOA/Web ServicesThe main problem being addressed is the heavy-weight
and verbose forms of XML documents appropriate for the enterprise domain, are too bloated for the tactical domain. The HIF SOA gateway delivers more compact and efficient forms of SOA services to the tactical domain. and furthermore, transforms the style of communication from the synchronous SOAP/HTTP protocol to asynchronousmessage protocol. This is valuable as the clients may often be intermittently disconnected.
Figure 5: XMPP Chat Gateway
An enterprise service bus with an embedded Java Message Service broker (Apache ActiveMQ) [12] is used to mediate between the synchronous and asynchronous modes of communication. The SOA application gateway (SOA Proxy) is configured with the target SOA Web Service and advertises a specific topic to be used by the MANET client (shown in Figure 6).
Figure 6: Accessing Enterprise SOA Service within Tactical Network
The Parsing module parses the XML SOAP header and payload and prepares the data structures for further message processing. It is a client of the enterprise SOA WS and is configured with the Web Service Description Language files that provide information about the service operations. The Filtering module performs filtering by pruning extraneous content from the XML messages depending on the operating point provided by Adaptation module.
E. VOIP
Figure 7: IVOX Gateway
Tactical RUDP Protocol
SOA WX serviceSOA WX Tactical Client
End-User located in a tactical domain
getWXforecast()
WXresponse
JMS Communication Bus
Remote Network Tactical
Edge Node
SOAP/HTTP/TCP
890
In this section, we describe the design of a VOIP gateway (shown in Figure 7), where the filtering capabilities of HIF occur at the data source. The design uses the Interactive VOice eXchange (IVOX) [21], a voice-over-IP (VoIP) application that uses several voice compression algorithms (vocoders) to achieve low network bandwidth requirements while still maintaining optimal voice quality. Voice audio is compressed by IVOX at the source, sent across the network and then converted back to voice by IVOX at the remote end. The Filtering module issues codec data rate changing commands to the source-end IVOX based on the latest operating point decisions. The Vocoders currently used in the IVOX gateway includes: (1) ADPCM speech at 32 kb/sec, (2) GSM speech at 13 kb/sec, and (3) HQ2400 speech at 2.4 kb/sec.
Table 2 below summarizes the operating points employed in the various applications discussed above. The operating points are designed to transform the data demand of the content of the application in question to match the currently available bandwidth in the network. The various operating points are invoked by the adaptation module in response to inputs from the network awareness module, based on the degree of detected network stress. Table 2 illustrates the substantial benefit in terms of bandwidth or data reduction when the operating points are invoked, a benefit unlikely to be achieved without awareness of what constitutes useful information to the application in question.Table 2: Resource consumption of applications at various operating points
Application Op 1 Op 2 Op 3SA 65 kbps 20 kbps 10 kbpsCHAT 7322 bytes 2251 bytes N/ASOA 2679 bytes 493 bytes 416 bytesVOIP 32 kbps 15 kbps 2.4 kbps
IV. EXPERIMENTAL RESULTS
A. Outdoor Testbed at Fort Monmouth, NJOutdoor testing of the HIF software was performed at
Fort Monmouth, NJ in July 2009. Tests were conducted over the following test beds: (1) A single MANET shown in Figure 8 with one router connected over multicast to a HIF gateway node and a client host, both of which used HMS radios (an experimental prototype version built by US Army Cerdec) for wireless communication; (2) Two MANET clouds (shown in Figure 9) connected by routers over a satellite link. HIF Gateway 1 was configured in a forwarding mode, with the HIF Gateway 2 sourcing application traffic to Client 1 in the first MANET.
Two HMS radio configurations were used: one with adata rate of 120kbps and the other with a data rate of 70kbps. Applications transmitted for sessions of 10 minutes duration– one consisted of voice traffic using IVOX, and the otherSA data traffic using C2MINCS. The operating points of the voice and data traffic were either 32kbps or 2.4kbps for IVOX and either 60kbps and 15kbps for C2MINCS.B. Performance Results
In the single MANET test bed, IVOX and C2MINCS traffic was sourced at the higher bit rates, while the HMS radio link bandwidths used were 70 kbps. The results shown in Table 3 show the packet loss rates observed in three
application scenarios, with a fixed application data rate (high/low) and with the data rate controlled by HIF adaptation. The application starts sending at high data rate, close to the radio link capacity. HIF reacts to losses due to high bandwidth utilization and adapts the data rate, performing almost as well as when the applications are operated constantly at their lowest operating points. In this experiment, HIF alleviated packet losses by a factor of almost 2, and noticeably improved both speech intelligibility and SA application smoothness.
Figure 8: Single MANET TestbedFor the two MANET case, HIF Gateway 2 provides the
C2MINCS traffic (HIF Gateway 1 acts as a pass-through for the traffic) to Client 1. Based on the poor network conditions, HIF Gateway 1 filtered the incoming C2MINCS messages, removing the redundant ones, and lowers the bitrate thereby reducing the packet losses rate and improving application behavior.
Figure 9: Two cloud MANET TestbedThe traffic bit rate adaptation is portrayed in Figure 10,
for IVOX voice traffic in the single MANET scenario, in Figure 11 for C2MINCS data traffic the single MANETscenario, and in Figure 12 for the two MANET scenario,respectively. The IVOX codec is initially ADPCM (38kbps)and switched to HQ2400 (5kbps). The difference between the measured bandwidth and the nominal codec rates of 32 kbps and 2.4 kbps is due to packet overhead.
Figure 10: IVOX traffic in single MANET testbed is adapted by HIF For C2MINCS, initially traffic starts at 62 kbps and is
adapted to 12 kbps in the both MANET scenarios.V. LESSONS LEARNED AND FUTURE WORK
The design and development of the HIF gateways for different applications unearthed challenges that helped evolve the gateway architecture, resulting in lessons learned and topics to be explored in the future. These include:Different filters for different information types: Voice and video payloads had to be dealt with differently from data
891
payloads. Data payloads could undergo inspection and hence be filtered based on content, while voice and video required transcoding. This led to the design of inline and external gateway types. The inline gateways performed payload based filtering while the external gateways simply used transcoding techniques from external libraries.
Figure 11: C2MINCS traffic in single MANET is adapted by HIF
Figure 12: C2MINCS traffic in two MANET test bed adapted by HIF
Table 3: HIF Benefit due to Loss Rate ReductionOperating Point IVOX C2MINCS
1 MANETC2MINCS2 MANET
Low 7.4% 15.7% 12.5%High 14.5% 29.7% 26.4%
HIF Adapted 8.4% 17.1% 14.4%Streams versus messages: The communication style used by applications called for different filtering approaches even when the underlying formats and schemas are the same; XPath-based filtering used in C2MINCS messages could not be applied to XMPP Chat streams even though both used XML formats. To circumvent this issue, we used text-based on-the-wire filtering for XMPP streams. User Intent based filtering: In addition to network driven adaptation, content transformation based on user context,behavior, device capability (e.g. SmartPhone versus a laptop, speaker being on or off) is currently being studied.Intermittent MANET connectivity: Applications such asSOA/Web-Services and XMPP Chat that use TCP suffer due to intermittent losses in MANETs. A pluggable Transport Adaptor was incorporated in the gateway to deal with this challenge. For the SOA gateway, a JMS middleware bus [12]transport adaptor was tested over UDP to decrease loss sensitivity and increase reliability. For the Chat gateway, a Reliable UDP transport was used, in a proxy mode between XMPP client and server. Although both transports worked reasonably well, each did have scalability limitations. For example, on high message volume, the reliability mechanism in ActiveMQ JMS/UDP failed. The RUDP proxy design required every TCP socket used in the XMPP protocol to use a separate RUDP proxy. A better solution that provides reliability with scalability such as Data Distribution Service (DDS) [13] is being researched. Application-based disruption tolerance: We realized that application-based disruption tolerance, a mechanism that complements the solutions above by storing messages and replaying only the relevant ones, is highly valuable. This is being reported on in a companion paper.
Multicast versus Unicast sessions: A client agent on a handheld cellular device may need to use unicast to access applications that may be inherently multicast (e.g., C2MINCS). Yet commercial cellular networks typically do not support multicast. This is yet another topic being actively worked on as an evolution of the HIF gateway.Multiple HIF gateways: Dynamic adaptation and load balancing across multiple flows is a significant challenge due to the need to coordinate multiple instances of adaptation algorithms. This will be worked on as part of future work.
VI. CONCLUSIONHIF offers significant improvements in the efficient use
of MANET resources, by dynamically and significantly reducing application bandwidth needs and alleviating network loss. HIF achieves this by filtering data intelligently to maintain the usefulness of the information. The flexible, component-oriented design of the HIF framework allows for the straight-forward incorporation of different kinds of multicast or unicast applications such as C2MINCS, Chat, SOA, VLC, and VOIP. This capability has been successfully demonstrated for different kinds of traffic such as voice and SA in the outdoor experiments using military radios and networks.
VII. REFERENCES[1] J. T. Barton, et al, “Heterogenous Intelligent Filtering in Tactical
Wireless Mobile Networks”, IEEE MILCOM 2009.[2] E. Amir, S. McCanne, and H. Zhang, “An Application Level Video
Gateway”, Proc. ACM Multimedia ‘95, November 1995.[3] D. Shur, "Unicast Access to Multicast Internet Protocol Sessions",
Invited paper, IEEE ICC/Encom'98, Atlanta, GA, June 1998.[4] B. Zenel and D. Duchamp “A General Purpose Proxy Filtering
Mechanism Applied to the Mobile Environment”, MOBICOM 1997.[5] K. Barry et al, “Shared Situation Awareness For Networked
Dismounted Soldiers”, Ft. Belvoir Defense Technical Information Center DEC 2004.
[6] J. Teevan et al, "To personalize or not to personalize: modeling queries with variation in user intent", Proceedings of the 31st annual international ACM SIGIR conference, 2008.
[7] http://www.videolan.org/videolan/[8] RFC 3550: RTP: A Transport Protocol for Real-Time Applications,
H. Schulzrinne et al, July 2003.[9] Developers Guide to Cursor on Target, 2005, MITRE Corporation[10] K.Parmeswran, et al, “A Distributed Hierarchical Policy Management
System for Security Control over Tactical Mobile Ad Hoc Networks”, IEEE Military Communications Conference, Oct 2007.
[11] http://www.xmpp.org[12] http://activemq.apache.org/index.html[13] http://www.omg.org[14] M. Hasan et al, “Designing the Joint Tactical Radio System (JTRS)
Handheld, Manpack, and Small form Fit (HMS) Radios for Interoperable Networking and Waveform Applications” IEEE Milcom 2007.
[15] http://www.igniterealtime.org/projects/openfire/[16] S. Eswaran, D. Shur, S. Samtani and A. Staikos, “Information Utility
in Mission-oriented Networks”, Accepted for IEEE WoWMoM, June 2010.
[17] C. Partridge and R Hinden, “Version 2 of the Reliable Data Protocol (RDP)”, RFC 1151, April 1990
