2014 IEEE Military Communications Conference

Content-Oriented Mobile Edge Technology System

Integration Framework and Field Evaluation
Zhongren Cao , Matthew French , Rajesh Krishnan , Joshua Ng , David Talmage , Qinqing Zhang
Information

Sciences Institute (ISI)

University of Southern California
Arlington, VA 22203
{zcao,mfrench,jng,dtalmage,qzhang}@isi.edu

AbstractIn recent years, content-oriented networking has

garnered extensive interest from both academia and industry
as a potential direction for future Internet evolution. It is also
a promising solution to address the challenging problem of
on-time situational awareness for soldiers at the tactical edge,
where network connectivity is often intermittent and limited in
capacity. This paper presents the content-oriented mobile edge
technology (COMET) system framework to integrate, test and
evaluate the effectiveness of various content-oriented networking
approaches for mobile edge networks. COMET is a unifying
framework with two innovative system elements, content-oriented
socket (cosocket) and enhanced broadcast abstraction layer
(EBAL). They support and integrate multiple approaches to
content-oriented networking. Furthermore, the effectiveness of
the COMET integration framework has been veried in largescale outdoor eld experiments over a three-squad heterogeneous
network including Rieman tactical radios and WiFi links.
Compared to the baseline network architecture currently being
adopted by the military, a COMET integrated content-oriented
solution recorded an average 27 reduction in content delivery
latency while at the same time delivering 70% more content.

I. I NTRODUCTION
Many military communication systems have adopted the
Internet architecture to achieve network-centric operations.
Despite the fact that this transition has improved the network
operation of military communication systems over their legacy
counterparts, it is still a challenging problem to efciently
share and disseminate mission critical information at the tactical edge, where highly volatile wireless links can easily disrupt
Internet based applications that assume stable connections with
static addresses. The reach-back links connecting edge groups
and the command center often have limited bandwidth and
long delays. These challenges faced by soldiers at tactical
edges negatively impact their on-time situational awareness.
Content-oriented networking offers a viable solution to address the aforementioned problems. Unlike in Internet, where
IP packets are the universal data encapsulation, in contentoriented networking, content (e.g., a video, a text le) and
metadata (e.g., a description of content, a request for content)
are data encapsulations handled by content-oriented network
stacks [1]. The network functionalities in the Internet focus on
This work was supported by the Defense Advanced Research Projects
Agenecy (DARPA) under the CBMEN program. Any opinions, ndings and
conclusions of recommendations expressed in this paper are those of the
authors and do not necessarily reect the views of DARPA. Distribution
Statement A" (Approved for Public Release, Distribution Unlimited).

978-1-4799-6770-4/14 $31.00 2014 IEEE

DOI 10.1109/MILCOM.2014.233

Cosocket,

LLC
Front Royal, VA 22630
krash@cosocket.com

delivering IP packets from one specic address to another and

are agnostic to information inside. Content-oriented networking, on the contrary, focuses on naming, nding, matching,
transferring, distributing, and storing content objects. Applications using content-oriented networking can retrieve information from where it can be obtained most conveniently and
cost efciently. Therefore, for tactical edge networks, contentoriented networking reduces the dependency on expensive
reach-back links, relaxes requirements on address-based link
stability, and increases local information sharing, all of which
enhance situational awareness for soldiers.
There have been many different approaches to contentoriented networking [2] [3], such as the content-centric networking (CCN) [4], which aim to change the current hostcentric Internet architecture and build a new foundation of
future Internet. Some new approaches for content-oriented
networking were developed under the Defense Advanced
Research Project Agency (DARPA) Content-based Mobile
Edge Networking (CBMEN) program [5] [6] [7], which seek
to develop new network services and transport architecture
to enable efcient and transparent distribution of contents
in tactical mobile edge networks. To fairly compare the
performance of different approaches and demonstrate their
individual strengths, multiple approaches have to be tested
over a common set of heterogeneous tactical network infrastructure and exercised by a common set of applications.
To this end, this paper presents the content-oriented mobile
edge technology (COMET) system integration framework.
COMET can integrate a range of content-oriented network
approaches with applications and heterogeneous radio links
into an operational information distribution system for soldiers
at the tactical edge.
The COMET integration framework has two innovative
system elements, the content-oriented socket (cosocket) and
the enhanced broadcast abstraction layer (EBAL). Jointly,
cosocket and EBAL enable technology developers to implement new content-oriented networking approaches, such
as CASCADE [5] and SCALE [6]. The effectiveness of
using the COMET framework to integrate multiple contentoriented networking approaches was veried and demonstrated
in large scale outdoor eld experiments, using a three-squad
heterogeneous network including Rieman tactical radios and
WiFi links. The experiments demonstrated that a COMET
integrated content-oriented networking solution yielded an
1405

average of 27 improvement in content delivery latency and

70% improvement in content delivery satisfaction over the
current tactical edge network deployment.
The rest of this paper is organized as follows. Section
II explains the COMET technology, including cosocket and
EBAL, in detail. The heterogeneous network infrastructure and
eld experiment setup are described in Section III. Experiment
results are presented and analyzed in Section IV, followed by
the conclusion in Section V.
II. COMET I NTEGRATION F RAMEWORK
To facilitate the technology development of multiple
content-oriented network solutions, the COMET framework
favors simple interface abstractions that are powerful, inclusive, and unifying. It minimizes the consensus prole such
that the ontological commitments that alternative contentoriented networking approaches will need to make in order to
be integrated are small. The COMET integration framework
adopts the hourglass model as illustrated in Fig. 1. It builds
around two abstraction interfaces. On the top of the hourglass
is the cosocket application programming interface; on the
bottom is the EBAL.
Cosocket is an application programming interface (API),
which abstracts the interaction between applications with
the underlying content-oriented networking stack. Cosocket
enables applications to uniformly access services provided by
content-oriented networking regardless of the rich and varied
underling technology solutions and implementations. With the
cosocket abstraction, legacy applications, tactical applications
as well as commercial applications can all be rapidly ported
or developed over a variety of content-oriented networking
solutions.
EBAL sits below the content-oriented networking stack,
for which it provides a uniform abstraction of content link
layer transmission services, including the broadcast service,
and shields the underlying heterogeneous nature of radio link
technologies. It is intended to enable multiple content-oriented
network solutions to uniformly access the disparate tactical
and commercial communications technologies, such as adhoc WiFi, Soldier Radio Waveform (SRW) using the Rieman
Radio, and emulated links in a seamless fashion.
A. Cosocket Design Philosophy
The cosocket API is architected to provide a simple, versatile, and powerful interface for secure content networking.
Cosocket is designed to be neutral to applications, radios,
networks, and query languages. It intends to support a wide
range of content-oriented networking approaches, from simple
to sophisticated ones.
The design of cosocket is inspired by the very successful Berkeley Software Distribution (BSD) network socket
abstraction. An application does not care whether the data
written to a BSD socket will go over Ethernet or over ber,
or whether open shortest path rst (OSPF), border gateway
protocol (BGP), or another protocol would be used to route
it. Likewise, the content written to the cosocket is agnostic
to the underlying content-oriented network mechanisms by

Fig. 1.

COMET hourglass system integration model.

which content is disseminated. A cosocket binds to a content

description, analogous to the way a socket binds to network
address, port, and protocol. The cosocket enables access to
content by description without focus on its storage location.
The cosocket design is also inuenced by the ubiquitous
web search form and web tag-and-upload form metaphors.
Current web search forms have seen a rich set of capabilities
evolve over time, from Lycos to the latest search engines such
as Google, Bing, or Ask, that allow for extremely simple to
very sophisticated queries, and quietly and cleverly maintain
signicant user behavior and popularity context. Similarly,
the cosocket builds upon and unies familiar content access
metaphors and application use cases. These metaphors and
use cases are drawn from the world-wide web, knowledgebased systems, and publish-subscribe systems. Metaphors include tag-and-upload, search, syndication feeds, and several
others. Application use cases include publish-subscribe, content search and discovery, caching, auto-tagging, distributed
tagging, syndication, peer-to-peer, social media messaging,
and semantic multicast.
B. Cosocket and Applications
Applications create cosockets and describe what content
they want. For each cosocket, the system creates a binding
and a stream handle is returned. Applications keep receiving
matching content steam from each cosocket until the cosocket
is closed. The cosocket parameters can include constraints and
preferences, such as ranking, order, maximum time, maximum
results returned, scope of dissemination. The cosocket supports
poll and select modes for active applications and can be persistent across reboots and application exits, if desired for passive
applications (akin to email folders or RSS feeds). Applications
can provide a description with the content to be sent over
cosockets into the underlying content-oriented network stack.
In addition, metadata generation rules can be associated with
a cosocket that allows any content written to the cosocket to
be tagged with descriptive metadata automatically.
Content-oriented networking via the cosocket unshackles
content from application stovepipes and enables content from
1406

different universes to be combined to meet user needs. This

ability was demonstrated in the CBMEN program. For example, the Tactical Reporting and Acquisition (TRAQ) application, a non-networked warghter app originally developed
by the XEROX Palo Alto Research Center (PARC) for the
DARPA Transformative Apps program, can share content with
Future Skies Dismounted Ad-hoc Reporting Tool (DART)
application and vice versa. Another example showed that
content from expendable unmanned ground sensors (E-UGS)
can be readily incorporated into the CBMEN system using COMET integrated content-oriented network stacks. The
content generated by E-UGS can then be shared with our
GeoBrowser application or any other application using the
cosocket API.
Programming using the cosocket API has been shown to
have low barrier to entry for software developers. A number
of CBMEN performer organizations as well as the CBMEN
government testing and evaluation team were able to interface
with and use the cosocket API in their applications. Developers
from these organizations have used the cosocket API to
develop applications, including warghter handheld application prototypes, test applications for performance evaluation,
utilities to bridge to existing content universes, social media
without infrastructure, and others.
C. EBAL
As shown in Fig 1, EBAL is located below the contentoriented network stack. It provides a uniform abstraction layer
for content delivery over various radio networks underneath.
The EBAL abstraction interface is designed to serve two
critical purposes. First, the EBAL API provides a set of unied
primitives for content-oriented network nodes to talk to each
other using commonly understood data encapsulations over a
single content hop while staying agnostic to the underlying
disparate radio link technologies. Thus, using the COMET
integration framework, the code base of any content-oriented
networking stack can be easily ported to a variety of heterogeneous radio network congurations. The emphasis on a single
content hop is because multiple content hops are handled by
the content-oriented network stack above the EBAL. Secondly,
EBAL is proposed to take advantage of the broadcast nature of
the wireless medium. It is designed as a simple and general
API to allow content-oriented network stacks to expect and
make use of the wireless broadcast primitive instead of the
conventional MANET network layer broadcast delivery.
EBAL consists of several transport primitives optimized to
support content-oriented operations over a wireless broadcast
medium, including
Neighbor discovery and maintenance
Delivery policy
Connection management
Link type and quality statistics.
1) Neighbor discovery and maintenance: EBAL on each
content-oriented network node discovers its neighboring nodes
within one hop over all available network interfaces. It
provides a neighbor table with a tuple given by (NodeID,
Interface). The NodeID is unique to each content-oriented

network node. The interface is the specic link by which that

neighbor node is reachable on the reference node. If there are
multiple communication links connecting to a single neighbor,
multiple tuple entries will be listed in the neighbor table. For
example, if a neighboring node has both WiFi and Bluetooth
connections to the reference node, the neighboring node will
have two separate entries in the neighbor table, with the same
NodeID but different Interface values.
This neighbor representation has several benets unique
to content-oriented network operations. First, a neighbor is
identied by its identity instead of its address. Nodes without
globally routable addresses can still be reachable by any
content distribution solution. Second, it is straightforward to
nd out whether there are multiple communication links to the
same neighbor. Intelligent and efcient usage of the existing
links can be explored. Third, the neighbor list is updated
frequently to allow the content management and distribution
components to recognize and react to the one-hop topology
change accordingly.
The neighbor discovery and maintenance mechanism is
realized by sending beacon messages periodically. The beacon
message interval and the number of missed beacons before
updating the neighbor table are two congurable parameters.
The neighbor table is accessible by content-oriented stacks
using the EBAL API.
In the current implementation, beacon messages are sent
in UDP broadcast over both IPv4 and IPv6 subnet addresses
to each port. If a link type does not support UDP broadcast,
static neighbors" are congured. Beacon messages are sent
to the unicast addresses of those static neighbors for node
discovery and maintenance.
2) Delivery policy: There are two main delivery policies in
EBAL, unreliable (e.g., best effort without delivery conrmation) and reliable with delivery conrmation.
3) Connection management: EBAL connection management controls the sending and receiving functions, transferring
data encapsulations from the content-oriented network stack
to neighboring nodes, and passing up received data encapsulations from the network interface to the stack.
To align with its delivery policy, EBAL provides two basic
data encapsulations, frame and message, to its content-oriented
network stack users. EBAL frames are used for unreliable
transmission. The size of individual EBAL frame is limited
by the characteristics of radio links and the software implementation. EBAL messages, on the other hand, are intended
for reliable transmissions. The run-time maximum size of an
EBAL message is limited by the available space in the EBAL
message transmission queue.
In the EBAL API, reliable deliveries are sent using the
sendMsg() function, while unreliable deliveries are handled
using the sendFrame() function. Correspondingly, reliable
deliveries are received using the recvMsg() function and the
unreliable deliveries using the recvFrame() function.
The EBAL message queue has a parameterized total size
limitation so that EBAL can apply back pressure to the
upper content stack if it generates messages faster than that
can be handled by the underlying radio links. Each EBAL
message is saved in a queue waiting for acknowledgement

1407

once it is transmitted. If the transmission fails, the message

will be retransmitted. Each message has a maximum number
of transmissions that is allowed. The status of the message
delivery, success or failure, will be notied to the upper content
stack.
As an example, CASCADE pushes metadata to the whole
network while the content le itself is only delivered to query
nodes. Thus, it is reasonable to use the unreliable sendFrame()
function to disseminate the metadata if the purpose is to avoid
a ood of acknowledgements. However, if the reliable delivery
of metadata is more important, then metadata is transmitted
using the sendMsg() function.
The implementation of these API functions can take various
approaches. For example, in the current EBAL implementation, reliable transmissions uses TCP while unreliable transmissions use UDP. Since the TCP performance is lackluster
in the contentious wireless Ad Hoc network, an additional
stop-and-wait" protocol is used on top of TCP tracking
messages in the EBAL message queue. Ideally, a non-TCP
based reliable transmission protocol is preferable to implement
the sendMsg() and recvMsg() functions.
4) Link type and quality statistics: EBAL provides the link
statistics interface to record and report measurement results
of transmissions over heterogeneous links. The measured
statistics include but are not limited to link transmission rate,
link throughput and latency, and link duty-cycle. These measurements are very useful in characterizing the communication
performance and tuning parameters in resource management
algorithms to improve the overall system performance.

Fig. 2. The deployed topology used in the COMET integration technology

eld tests and the demonstration.

In the eld, nine soldiers of each squad are distributed on a

circle while the 10th soldier, the squad leader, is at the center.
Every soldier has a Galaxy Nexus Android smart phone. Low
cost Android devices offer both exibility and scalability for
high speed local intra-squad communications. In addition, each
squad leader has a Rieman Radio, a Program of Record
radio currently being elded to the military. The Rieman
radios form an SRW network, which is used for inter-squad
communications and reach back links. The Rieman Radio
connects to the Android phone of the squad leader using
Ethernet over USB. As a result, the Android phones of squad
leaders have two network interfaces, one is the Wi-Fi network
and the other is the SRW network. It is important to note that
members of the same squad can communicate with each other
over Wi-Fi, however, any communications between squads or
to the command center must traverse the SRW tactical links
utilizing the Rieman radio.

III. F IELD E XPERIMENT D ESIGN

The COMET team designed eld experiments to evaluate
and demonstrate the advantages of content-oriented networks
for warghters at the tactical edge. The scenario is relevant to
modern insurgency warfare operations.

B. Action Prole

A. Field Scenario and Setup

To conduct the cordon and search mission, each soldier is

engaged in publishing contents, such as spot reports, position
and location information (PLI), texts, etc. Most soldiers are
mainly interested in information published by other soldiers in
the same squad. Additionally, some soldiers are also interested
in the information published by soldiers in other squads, such
as threats the other squads may discover.
Action proles describe the content publishing and subscription actions used in experiments. The action prole used in this
paper denes content actions for all 30 nodes. Each action item
is associated with a time stamp. It takes around 10 minutes to
nish all actions in this action prole. The size of every piece
of content is 5 KB. There are 300 total publishing actions and
990 total query actions. The majority of queries, 810 out of
990, are intra-squad queries. There are 153 queries requesting
for content published outside the squad of the query node.
And the rest 27 out of the 990 queries ask for content that
has never been published. Thus, there is a total of 963 queries
expecting to be satised in each experiment run. This action
prole quantitatively reects the correlation characteristics we
assumed for content interests in the tactical edge, i.e., the

Fig. 2 provides a low altitude aerial overview of the experiment layout on a narrow range of hilly terrains about 5
km long and 175 meters wide. The range runs from west to
east with the west end of the range showing on the bottom
of the gure. The tactical scenario that was considered are
as following. This range, Area of Operations (AO) Cobra,
is where insurgent forces have tried to establish improvised
explosive device (IED) cells and factories. Insurgents only
operate in groups of one to three due to US/Coalition presence.
The 1st Platoon of the C Company is conducting a cordon and
search mission in AO Cobra to disrupt and defeat insurgent
forces and provide stability and security in order to turn over
the region to National Police.
The building on the west end of AO Cobra is the command
center for the 1st Platoon, which has 3 squads with 10 soldiers
in each squad. Squad 1 and 3 were cordoning the exterior access roads while squad 2 was conducting the search. As shown
in Fig. 2, each squad is on one hill. The distance between
two neighboring squads are around 1000 meters. Squad 1 was
stationed approximately 100m outside the command center.

1408

Fig. 3.

Architectural difference between CBMEN solutions and the baseline.

closer the soldiers are in a mission, the more correlated their

interests are.
C. The Comparison between CBMEN and the Baseline
The advantages of content-oriented networking should be
demonstrated and evaluated in comparison to the existing
approach used by the military for handling information access
and delivery, i.e., the baseline. In the following, COMET
integrated content-oriented networking solutions are called
CBMEN solutions. The architecture difference between the
baseline and CBMEN solutions is shown in Fig. 3. The
baseline uses the classical server-client architecture, where
any piece of content, regardless of its initial publish location,
is pushed back to a centralized upper-echelon server right
after being published. When requesting content, each node
pulls the content from the upper-echelon server. For soldiers
at the edge this architecture creates several inefciencies. It
requires that all content ow over the low bandwidth tactical
links. As seen from the top portion of Fig. 3, this has the
effect of quickly saturating the tactical links, especially in
links that are close to the server. It also means that in austere
operations where a squad is completely cut off, no information
can be either uploaded or downloaded. In eld experiments,
the upper-echelon server in the baseline case was set up in the
command center and can be accessed by soldier nodes over
the data link of the Rieman Radio SRW network.
The lower portion of Fig. 3 illustrates the architecture of
CBMEN solutions. Rather than uploading all content to the
centralized server, a node simply publishes or announces that
it has produced a piece of content. When the content is being
requested by another party, it will leave its publisher. For
example, the upper-echelon server can request the content
from the node, replicating the transfer of the content in the
baseline case. More importantly, compared to the baseline
case, one or more copies of that content are retained within the
edge network. Consequently, another warghter in the same
squad can directly get the content from within the squad using
the high speed local wireless link without traversing highly
contentious and capacity-limited reach-back links. Soldiers in
other squads can get the content either from the upper-echelon

Fig. 4. The cumulative distribution of query satisfaction latency comparison

between CBMEN and the baseline.

server or directly from another squad that has the content,

whichever is more convenient. Furthermore, as long as one
member in a squad has the content, all other members of
the squad can get the content from within the squad. Squad
members no longer need to get that content from outside
their squad. In short, CBMEN solutions provide soldiers with
multiple choices of where they can access content thus they
can choose the one that has the least network cost. In turn,
CBMEN solutions reduce the burden on reach-back links
enabling more mission critical data to be delivered to soldiers
at the tactical edge.
IV. E XPERIMENT R ESULTS A NALYSIS
In this section, eld experiment results are analyzed. We
developed an Android app, the ISI Exerciser, which takes the
content action prole in Sec. III-B as inputs and publishes
contents and generates queries at prescribed time stamps on
each Android phone. For each query, there are three possible
results. First, the queried content is rst located and then
fetched successfully. This is a successful query. Second,
the queried content is located but the fetch failed. This is a
partially successful query. Lastly, the queried content cannot
1409

be located, so it is a failed query. The rst metric used to

characterize the performance of CBMEN solutions is the query
success ratio, as given by
ps =

The number of successful queries

.
The number of total queries

(1)

The second metric used for evaluating the CBMEN solution

performance is the query satisfaction latency, which is dened
as the time between the generation of a query and the queried
content is completely delivered to the query node.
The baseline case was executed multiple times in the
eld to serve as the performance benchmark. Because of the
large round-trip delays to and from the upper-echelon server,
all baseline experiments resulted in large number of failed
queries. This was not the case for CBMEN solutions, where a
majority of queries completed successfully. In the following,
we present and analyze some numerical results obtained using
a CBMEN solution [5] from eld experiments.
In Fig. 4, we compare the cumulative query satisfaction
delays between the CBMEN and the baseline. For the latter,
we can see all query satisfactory latencies were more than 2
seconds with a majority of them were satised 10 seconds
after the query was generated. On the contrary, the fastest
query response CBMEN received was at 0.4 seconds. The
majority of queries were satised within one second. Looked
from another angle, the CBMEN solution satised 738 queries
with a query satisfaction latency less than 2 seconds, while the
baseline only satised a single query within 2 seconds latency
window. Fig. 4 also shows that the total number of satised
queries using CBMEN far exceeds that in the baseline case.
CBMEN registered a total of 815 success queries, so the query
success ratio ps = 815/963 = 85%. Only 475 queries were
satised in the baseline case, which amounted to a mere 49%
query success ratio. Among successful queries, the latency for
the 90% percentile was 20.903 seconds for baseline and only
0.788 seconds for CBMEN.
Fig. 5 plots the same data in histogram format to demonstrate a different view point. Here, it becomes clear that the
vast majority of CBMEN responses are received in under 1s,
while the baseline architecture is unable to have any returns
in this time frame at all. In our experiments, CBMEN reduced
the median latency of delivering content by a factor of 27
over the baseline, while also delivering 70% more content. It
is clear that CBMEN signicantly reduces the query latency
and satises more content queries, which means, compared to
the existing solutions used at the edge, warghters using the
CBMEN technology not only can access more mission critical
information, but also get them much faster.
V. C ONCLUSION
COMET provides a unifying framework integrating a multitude of applications and content-oriented networking approaches into an operational system over heterogeneous network links. The effectiveness of the COMET integration
framework is veried and demonstrated by large-scale outdoor
experiments, in which COMET integrated multiple contentoriented networking stacks. The COMET framework is designed to work with a variety of content-oriented networking

Fig. 5. Histogram comparison of query satisfaction latency between CBMEN

and the baseline.

solutions developed by a vibrant community with a diversity of

approaches for naming, managing, distributing, and securing
content. Towards the future, further work is needed to develop
software libraries to integrate additional content-oriented networking solutions with the COMET framework.
ACKNOWLEDGEMENT
The authors gratefully acknowledge our sponsor and the entire COMET project team for making the COMET integration
framework a success. Specically, we would like to thank Dr.
Keith Gremban, Dr. Wayne Phoel for program support. We are
grateful to our former USC/ISI colleague Preston Marshall, our
team members and collaborators Lindley French, Eric Johnson
and Karl Jagler from Argon ST, a Boeing Company, Ignacio
Solis and Van Jacobson from PARC, A Xerox Company, Sam
Khoury from General Dynamics Corporation, and Carolyn
Talcott and Chris Lockett from SRI International, for their
great contributions and support to this project.
R EFERENCES
[1] V. Jacobson, Google Tech Talk A New Way to Look at Networking,
http://www.youtube.com/watch?v=gqGEMQveoqg, August 30, 2006.
[2] G. Xylomenos, C. Ververidis, V. Siris, N. Fotiou, C. Tsilopoulos, X. Vasilakos, K. Katsaros, and G. Polyzos, A survey of information-centric
networking research, Communications Surveys Tutorials, IEEE, vol. PP,
no. 99, pp. 126, 2013.
[3] B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, and B. Ohlman, A
survey of information-centric networking, Communications Magazine,
IEEE, vol. 50, no. 7, pp. 2636, July 2012.
[4] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs,
and R. L. Braynard, Networking named content, in Proceedings of the
5th International Conference on Emerging Networking Experiments and
Technologies, ser. CoNEXT 09. New York, NY, USA: ACM, 2009, pp.
112. [Online]. Available: http://doi.acm.org/10.1145/1658939.1658941
[5] T. Strayer, V. Kawadia, A. Caro, S. Nelson, D. Ryder, C. Clark, K. S. B.
Tedesco, and O. DeRosa, CASCADE: Content access system for the
combat-agile distributed environment, in Military Communications Conference, MILCOM 2013 - 2013 IEEE, Nov 2013, pp. 15181523.
[6] M. R. Schurgot, J. Esteban, L. Greenwald, Y. Guo, M. Smith, D. Stott,
M. Varvello, and L. Wang, Providing local content discovery and sharing
in mobile tactical networks, in Military Communications Conference,
MILCOM 2013 - 2013 IEEE, Nov 2013, pp. 15061511.
[7] S. Wood, J. Mathewson, J. Joy, M.-O. Stehr, M. Kim, A. Gehani,
M. Gerla, H. Sadjadpour, and J. Garcia-Luna-Aceves, ICEMAN: A
system for efcient, robust and secure situational awareness at the network
edge, in Military Communications Conference, MILCOM 2013 - 2013
IEEE, Nov 2013, pp. 15121517.

1410