Military Ontologies for Information Dissemination at the Tactical EdgeEmily C. LeBlanc, Duc N. Nguyen, Marcello Balduccini, William C. Regli

Applied Informatics GroupDrexel UniversityPhiladelphia, PA

Joseph B. Kopena, Thomas A. WamboldBellerophon Mobile

Philadelphia, PA

Abstract

In this paper we present our methodology for construct-ing the Tactical Heterogenous Ontology Representation(THOR), a doctrine-based military ontology that mod-els numerous aspects of the military domain as de-scribed by field manuals, joint publications, and sce-narios informed by subject matter experts. Developedfor DARPA’s Content-Based Mobile Edge Network(CBMEN) program, the ontology provides the con-ceptual vocabulary needed to describe and request thewarfighter-generated content. CBMEN leverages smartdevice technologies alongside concepts from content-based networking and knowledge representation in or-der to enable intelligent reasoning over dynamic mis-sion data and the efficient transmission of critical mis-sion content at the tactical edge.

IntroductionWarfighters at the tactical edge are generally required tocommunicate with base facilities in order to report and re-trieve new information about their locations, missions, andpotential threats. With current communications technology,this critical operational content is not always immediatelyaccessible nor distributable for warfighters who are out-side of the range of communication of their bases. Lackingnew information may compromise missions and possibly thesafety of active units. There is a need for reliable and effi-cient content distribution and retrieval of battlefield contentat the tactical edge.

DARPA’s Content-Based Mobile Edge Networking (CB-MEN) program aims to enable ad hoc communicationamong smart devices which are in range of one another. Thesmart-device equipped warfighters may publish about or re-quest information about mission content such as observa-tion reports, updated orders, or mission-time imagery. Eachpiece of content in the system is tagged with semanticallyrich metadata that can be queried and reasoned over in anintelligent way as to return the most relevant available re-sults. In order to tag mission content in a meaningful way asdescribed, we require an intuitive and well-structured rep-resentation of the military domain. In this paper we presentthe methodology used to develop the Tactical HeterogenousOntology Representation (THOR). THOR’s ontology is a

doctrine-base military domain representation that models awide landscape of essential concepts and relationships de-scribed in field manuals, joint publications, and scenariosdeveloped with subject matter experts. The ontology pro-vides the terms, concepts, and relationships necessary to de-scribe critical mission content, thus enabling intelligent rea-soning over dynamic mission data in order to increase situa-tional awareness for warfighters.

The section that follows discusses background informa-tion about the work’s motivation and technologies of theCBMEN program. Next, we will describe our methodologyfor creating the ontology and its coverage of the military do-main. Following that, we discuss in greater detail the role ofrich metadata for the effective dissemination of battlefieldcontent along with some examples of class definitions andinstances. The next section gives examples of competencyquestions for determining the usefulness of the ontology inthe military scenarios. In the following section, we give anoverview of the complete application developed by DrexelUniversity and Bellerophon for the CBMEN program. Fi-nally, we present a scenario that illustrates the use of theontology and reasoning in a simulated mission.

Background and MotivationAs a motivation for our work, consider the following sce-nario in which a platoon of dismounted warfighters arecarrying out patrolling operations in a remote region. Afireteam leader of a squad uses his connected mobile deviceto snap a photo of a suspicious object and identifies it as apotential explosive device outside a remote village and at-tempts to share this photo with members of the entire pla-toon and commanders and intelligence teams at commandposts.

These devices utilize tactical mobile ad hoc networks(MANETs) to exchange this content and informationamongst platoon and squad members where fixed networkinfrastructures (e.g. satelite or mobile cellular networks) donot exist. MANET environments utilize infrastructurelessad hoc wireless networks (ad hoc WiFi), optimized routing(e.g. OLSR (Clausen and Jacquet 2003)), caching and op-portunistic forward approaches (e.g. delay-tolerant network-ing (Cerf et al. 2007)), and additional middleware to per-form content retrieval, storage, and forwarding in lieu of astandard fixed infrastructure network (Sivakami and Nawaz

… Ground Track Equipment Ground Vehicle … Special Equipment … Improvised Explosive Device Land Mine …

Flat Representation: No results

…

Ground Track Equipment

Ground Vehicle

Special Equipment

Improvised Explosive

Device Land Mine

…

Hierarchical Representation: At least 2 results

Figure 1: Flat and Hierarchical Representation

2011).DARPA’s CBMEN program leverages concepts from

content-based networking, knowledge representation, andreasoning in order to enable information dissemination atthe tactical edge. The program aims to maximize warfightersituational awareness by facilitating reliable and efficient ac-cess of battlefield content in tactical edge networks wherereliable connectivity is not guaranteed. Mobile devices op-erating in this tactical edge network context must utilize lo-cal secondary storage and processing capabilities to performmany tasks. Modern tactical edge networking is thereforebased on disruption tolerant and information-centric tech-niques, utilizing extensive caching and comparatively ex-pressive addressing.

In content-based networking (Jacobson et al. 2009), thefiles (or content) of the system are addressed by name ratherthan by their host machine location. Content for the mobile-device-equipped warfighter is in the form of files such asimagery, map tiles, orders, and documents. Rather than ex-changing the content itself, the nodes within CBMEN willexchange metadata describing available content. If the meta-data description of content is relevant to the warfighter, thenCBMEN system will deliver the binary files to their devicefor consumption.

The ramifications of exchanging meaningful metadata in-stead of the actual content in an edge-network are wide-ranging, but its primary effect is in the reduction of theamount of data flooding an already resource-constrainedmobile edge network, enabling exchange of higher prioritycontent when the need arises.

The CBMEN system is composed of five primary com-ponents: applications, the content naming registrar, the Au-togen interface, the content management service, contentdatastore, and content distribution service. The content man-agement service attaches unique identifiers to content foruse by the registrar, datastore and distribution services. Thecontent datastore holds content created by the device and

cached content from other devices. The distribution serviceefficiently publishes and receives content to and from thenetwork. The content management, content datastore, andcontent distribution service are the key components of thecontent-access middleware charged with disseminating themetadata and content efficiently across the tactical edge net-work. It is beyond the scope of this work and is described indetail in (Strayer et al. 2013).

The ontology forms the conceptual backbone of the sys-tem with the content metadata serving as instance data overwhich the registrar will reason. The developed ontology con-structs utilize basic class, subclass relationships. They arewritten in OWL and restricted to OWL-Lite. A detailed de-scription of the rationale and methodology for the ontologyand its development is described in the following section.

OntologyThe THOR ontology is composed of a number of sub-ontologies modeling a number of military sub-domain con-cepts, properties, and relationships. Each sub-ontology is or-ganized by resource and contains extensive taxonomies ofthe military warfighter domain. It extends the work of thecommand and control ontology (Nguyen et al. 2010), incor-porating knowledge from resources such as US Army FM5-0 Operations Process (U.S. Department of Army 2007),MIL-STD 2525 Military Symbology (U.S. Department ofDefense 2008) and other official doctrine. Using these re-sources to create the domain representation ensures that mil-itary users of all ranks will be familiar with the vocabularyand basic structures of the representation. Other Departmentof Defense data models such as UCore 1, and NIEM 2 havealso been consulted and concepts have been incorporatedinto the THOR ontology as needed.

1http://ise.gov/universal-core-ucore2https://www.niem.gov/Pages/default.aspx

In addition to the doctrinal representations, the ontologyincorporates generic communication entities and domain-independent features capturing basic message structure, geo-temporal marking, and provenance. The ontology is encodedusing RDF Schema (RDFS)3, and the Web Ontology Lan-guage (OWL)4, version 2, EL profile for tractable expres-sive description logic (Baader, Brand, and Lutz 2005), aswell as Terse RDF Triple Language5 for encoding instancesof ontology classes. The languages provide a sufficientlyconstrained set of constructs for modeling the domain, en-abling a great deal of knowledge to be captured in forms thatare easily computable by smaller mobile devices. The ontol-ogy employs the languages to construct formal conceptual-izations of military domain aspects relevant to dismountedwarfighters, CBMEN’s primary intended users.

The ontology provides a substantial basis for integrat-ing a wide range of military applications into the system.Moreover, it is designed for future expansion and evolution.Other domains and application specializations may be incor-porated in the future without modification of the core ontol-ogy.

MethodologyAn iterative process was used to develop the THOR ontol-ogy. The process has been roughly divided into two tracks,corresponding to structured knowledge contained within theset of military doctrine and domain-independent documenta-tion and for military-specific development that falls outsideof what is immediately available from the doctrine.

The essential steps for the doctrinal track include:1. Conceptual Deconstruction: Studying source material,

such as military doctrine and sample application data, andidentifying the fundamental concepts and relationshipstherein. The main products of this step are documents list-ing terms and properties and representing natural connec-tions between them.

2. Concept Analysis and Organization: Organizing the con-cepts and relationships of the previous step into preciselydefined structures. The output of this step is a collectionof spreadsheets capturing these structures by category.

3. Encoding: Transcribing the structures of the previous stepinto RDF/OWL documents representing the ontology.

4. Evaluation: Testing the resulting iteration of the ontol-ogy to determine its ability to capture the required dataand support applications in the domain, and iterating overthe development process as necessary until the ontologymeets the requirements.For the military-specific development that falls outside

of enumeration by field manuals, realistic mission scenar-ios have been deconstructed using the process shown in Fig-ure 2:

1. Identifying all top-level concepts among the data objectsmanipulated and background knowledge used in this sce-nario;3http://www.w3.org/TR/rdf-schema/4http://www.w3.org/standards/techs/owl5http://www.w3.org/TR/turtle/

2. Determining class–subclass relationships among them;

3. Elaborating and identifying properties of those classes;

4. Specifying data domains and ranges for those properties;

5. Checking this deconstruction against the scenario ele-ments and iterating as necessary.

The scenario deconstruction is then utilized to evaluatethe capabilities of the THOR ontology and drive further de-velopment until all military-specific elements and relation-ships introduced by the scenario are represented by the on-tology.

Evaluation of the ontology has been conducted using thethree following mechanisms:

• Reviewing with subject matter experts (SMEs).

• Theoretical application to a motivating scenario. For ex-ample, given a mission scenario, is the current ontologysuitable to describe all necessary aspects of the situation?

• Collection of and testing against a set of competencyquestions (described in a later section of this paper).

CoverageFollowing from these iterative development processes andmechanisms, the THOR ontology supports describing andquerying content associated with a wide swatch of opera-tionally relevant applications and data. An overview of themajor topic areas is as follows:

• Data Specifications, e.g., file formats and languages

• Force Structure, e.g., battalion, company, platoon, squad

• Unit and Personnel Roles, e.g., unit identity, size

• Equipment, e.g., ground vehicles, ships, aircraft

• Mission Types, e.g., Patrol, raid, attack, defend

• Operations, e.g., movement descriptions and routes, tasksand maneuvers

• Geography and Environment Conditions, e.g., MGRS,Lat/Lon

• Military Message Types, e.g., spot reports, PLI, orders,priorities

• Provenance, e.g., authorship, time-stamping, and version-ing

Rich Metadata for Battlefield ContentTHOR’s approach to addressing and requesting objectshas several distinct advantages over other schemes used incontent-based networking. Most of these are based on es-sentially opaque string descriptors, which are generally bothhuman-oriented and flat. These schemes present a numberof shortcomings, including errors in human data entry, aninability to seamlessly scale specificity/generality, the ne-cessity of publishers and consumers using exactly the samedescriptors for a connection to be realized, and unnecessaryverbosity.

1.  Iden(fy  top-­‐level  concepts  from  the  

Scenario  

2.  Determine  sub-­‐concept  

rela(onships  

3.  Iden(fy  concept  and  sub-­‐concept  

proper(es  

4.  Determine  domain  and  ranges  

of  proper(es  

5.  Repeat  from  step  2  un(l  all  scenario  

concepts  are  covered.  

Figure 2: Process for deconstructing a motivating scenario.

Figure 3: THOR ontology sources and key topic areas.

THOR’s ontology-backed metadata addresses these con-cerns. The structured but schema-free metadata model en-ables content to be expressively described, enabling appli-cations and users to capture whatever aspects they deempotentially relevant. Extensive taxonomies and automatedsuper/sub-class inferences further enable searches and sub-scriptions to be as general or specific as necessary whilemaintaining comparative terseness.

Figure 1 illustrates how hierarchical organization ofterms facilitates this better than flat labels, enablingthe system to return the most fitting set of informa-tion for a query. For example, Warfighter A observesan improvised explosive device (IED) on their patrol.They publish a Spot Report about the IED, using theterm “equipment:ImprovisedExplosiveDevice”. WarfighterB is moving into the same area looking for suspiciousequipment and subscribes to Spot Reports about “equip-ment:GroundTrackEquipment”. Because “equipment:IED”is a subclass of “equipment:GroundTrackEquipment”,THOR will recognize Warfighter A’s report of an IED sight-ing as content that should be delivered to Warfighter B.

Here we will provide some examples of how one createsinstances of the classes in the ontology. First is the encodingof the domain concept ”GroundTrackEquipment” in Turtle.

<owl:Class ref:ID=GroundTrackEquipment>

<rdfs:label xml:lang=en>Ground Track Equipment</rdfs:label>

<rdfs:subClassOf><owl:Class ref:ID=Equipment/><rdfs:subClassOf>

</owl:Class>

The following is a sample instance of the class “Ground-TrackEquipment” named “e234”.

:e234 a equipment:GroundTrackEquipment

equipment:mil2525_affiliation [a roles:Hostile];

The following is a sample instance of a Spot Reportnamed M2 about an instance of ground track equipment.M2 contains an image of the equipment being reported,and the report is created by the Rifleman. In the interest ofspace, the prefix “messages” is abbreviated to “m”, and theclass “GroundTrackEquipment” to “GTE”.

:M2 a msg:SpotReport ;

m:contentType [ a provenance:ImageEntity ] ;m:equipment [ a equipment:GTE ] ;m:originator [ a roles:Rifleman ] ;

Competency QuestionsAnother technique used in developing and evaluating theTHOR ontology is the use of competency questions - spe-

cific use cases applying the ontology to automated reason-ing, defining a set of queries the ontology must be able toanswer. A list of these questions in natural language was de-veloped through discussion with SMEs and studying moti-vating scenarios. Each question was then modeled as sampledata and a query using the ontology, with refinements andadditions being prompted if that proved impossible.

The following example represents a class of simple searchqueries:

Retrieve all spot reports observing ground vehicles.

This request may be encoded as a query in the THORontology as follows:

SELECT ?id ?lat ?lon ?equ ?reportUnit?reportUnittype ?equtype

WHERE {?id a messages:SpotReport .?id messages:latitude ?lat .?id messages:longitude ?lon .?id messages:equipment ?equ .?id messages:priority ?reportUnit .?reportUnit rdf:type ?reportUnittype .?equ a equipment:GroundVehicle .

}

With the sample data conceived from motivating scenar-ios, matching this query requires applying a taxonomy ofvehicles, e.g., that a Jeep and a tank are both ground vehi-cles.

Another example asks for a more specific data value:

Return the collection of available spot reports about hos-tile people and their affiliation.

The ontology permits capturing this in SPARQL as fol-lows:

SELECT ?id ?lat ?lon ?equ ?afftype ?equtype

WHERE {?id a messages:SpotReport .?id messages:latitude ?lat .?id messages:longitude ?lon .?id messages:equipment ?equ .?equ a equipment:SpecialEquipment .?equ equipment:mil2525_affiliation

[ a roles:Hostile ] .?equ equipment:mil2525_affiliation ?aff .?aff a ?afftype .

MINUS { ?aff rdf:type ?subtype .?subtype rdfs:subClassOf?afftype .

}}

This query includes a complex construct selecting themost specific affiliation, rather than all its taxonomic an-tecedents, based on the MIL2525 labels. Correctly matching

this query requires both a taxonomy of affiliations in the on-tology, and the ability of the reasoner to process the MINUSoperator used in this query to exclude redundant results. Thefollowing example question requires testing literal data:

Return the collection of available reports that fall withina specified area.

This may be rendered in SPARQL as a query using theontology:

SELECT ?id ?lat ?lon ?equ ?reportUnit?reportUnittype ?equtype

WHERE {?id a messages:SpotReport .?id messages:latitude ?lat .?id messages:longitude ?lon .?id messages:equipment ?equ .?id messages:priority ?reportUnit .?reportUnit rdf:type ?reportUnittype .?equ a equipment:GroundVehicle .

FILTER (?lat < 3818 && ?lat > 3817)FILTER (?lon > -7730 && ?lon < -7729)

}

This question demonstrates that content may be associ-ated with particular positions, and that it is possible to reasonover those defining regions of interest.

The ontology defines a rich representation of military con-tent using terms and relationships derived from subject mat-ter experts and military doctrine precisely to enable this sortof inference. Using it, warfighters may specify exactly whatthey are publishing and what content they wish to receive,being as specific or general as they wish with the systemmaking automated connections as appropriate. In this waythey may better manage the extensive volume and diversevariety of content that will be present on the battlefield.

RegistrarThe purpose of this section is to give an overview of thecomplete application developed by Drexel University andBellerophon for the CBMEN program. THOR’s ContentNaming Service is CBMEN’s registrar, implementing itssearch and subscription capabilities. This component con-sists of a thin shell interfacing with the larger CBMEN sys-tem that passes data to and from Masterchief. Developed forthe CBMEN program, Masterchief is a general purpose Se-mantic Web knowledge base designed specifically to supportapplications on mobile devices, and the applications are bothintended to be installed on the device of every warfighter. InCBMEN it stores content metadata and applies it to searchesand subscriptions enacted by applications.

MasterchiefInside Masterchief there are three major pathways, imple-menting an RDF triple store, SPARQL queries, and sub-scriptions and OWL reasoning. All of these are rooted on anSQLite database which provides the underlying data storage

Figure 4: The Autogen interface reporting options and pop-ulating fields.

and manipulation. A major design point here is the assump-tion that modern mobile devices have limited primary mem-ory but relatively plentiful secondary memory. Masterchiefthus pushes nearly all logic and storage into the database,rendering its primary memory consumption very low andactually constant in the absence of a few particular queryoperators. This approach also enables persistence and readyrehydration of the registrar across system reboots.

Searches are executed in Masterchief by transforming thespecified SPARQL query into SQL over the triple store’spartition scheme. A recursive traversal of the SPARQLstructure generates a single SQL statement capturing the en-tire output of the query.

AutogenTHOR’s metadata approach to labeling and querying contentprovides for sophisticated filtering and discovery. Creatingappropriate metadata that is as richly descriptive as possiblethough is a significant challenge. Users must be presentedwith an intuitive interface and the ability to rapidly navi-gate and utilize the extensive ontological structure. Further,this interface must be populated from the ontology itself ashardcoding this interface will render it likely to become un-synchronized with ontology updates over time.

Constructing and maintaining such an interface is a sig-nificant burden to place on CBMEN application develop-ers. Appropriately interrogating the ontology requires a fairamount of familiarity with knowledge representation andspecifically RDFS/OWL. A significant amount of work mayalso be entailed to connect the ontology to an interface.

These concerns are addressed in CBMEN via the Auto-gen component. Autogen is a free-standing Android activitythat any application may invoke to have the user populatemetadata. While applications are free to generate metadatain any way they wish, this provides an easy mechanism topopulate descriptions for publishing with content.

Autogen provides an interface for the user to attach meta-data in the form of instance data to content. For each pieceof content, Autogen will query Masterchief for an initial setof concepts for which to generate and attach instance data.Once the entry is complete, the constructed object is re-turned to the invoking application where it may be readilyserialized to RDF and published with the associated con-

Figure 5: Events and Movement from Motivating Scenario

tent. In this way Autogen provides applications a dynami-cally created interface for generating metadata based on theTHOR ontology that is easy to use for both application de-velopers and users.

ScenarioSeveral operational scenarios have been used to motivateand evaluate the THOR ontology during development. Thesehave been created alongside and shared with the larger eval-uation and demonstration efforts of the entire CBMEN sys-tem. The following example illustrates how CBMEN wouldbe used to support dismounted warfighters exchanging con-tent in an area of operations (AO).

Dismounts from three squads are equipped with CBMEN-enabled mobile devices. The squads each have a differentmission: Squads A and B are conducting patrol missionsnearby a town where Squad C, a quick reactionary force(QRF), is deployed to capture a known high-value individ-ual. Prior to the mission, the CBMEN devices are config-ured to subscribe to relevant content publications based onthe dismount’s role and mission. Once configured and readyto deploy, Squads A and B carry out their missions record-ing and publishing reports, including observations of poten-tial Improvised Explosive Devices (IEDs) and IED factories,persons of interest, road obstructions, and other alerts. SquadC identifies and captures the target high-value individual andpublishes a spot report with an image of them. The forwardoperating base receives the report of the HVI capture andimage and other relevant reports of IEDs and other prior-ity reports. Upon mission completion, each squad returns totheir forward operating base for debriefing as well as ag-gregating and archiving all relevant mission data. Figure 5shows the activities of each squad in the AO.

Now we observe the scenario in more detail, looking atthe events of each time step. Each Squad has three devices,held by the Squad Leader, a Fire Team Leader, and the FireTeam‘s Automatic Rifleman. The set of possible subscrip-tions contains spot reports about Special Equipment with

Unit Role Squad A Squad B Squad CSquad Leader Special Equipment Special Equipment Special Equipment

Fire Team Leader Special Equipment, HVI Special Equipment Special EquipmentRifleman Special Equipment IED, Obstacles Special Equipment

Table 1: Unit role content interests for each squad.

Time step Squad A Squad B Squad Ct1 Observes and Reports: Jeep Observes and Reports: IED -t2 Receives: IED - Receives: IEDt3 Observes and Reports: Bridge - Observes and Reports: HVIt4 Receives: HVI - -

Table 2: Timeline of publications and satisfied subscriptions.

Hostile affiliation, High Value Target(HVT) with Suspiciousaffiliation, and Ground Track Vehicles. Squad subscriptionsare detailed in Table 1. Note that there is no subscription forspot reports about Ground Track Vehicles.

At time t1, Squad A sees a seemingly suspicious jeep driv-ing outside of the perimeter of the AO. At the same timestep, Squad B observes an unexploded IED. Squads A andB cross paths at time t2, and Squads A and C receive Bs spotreport about IEDs because they are both interested in Spe-cial Equipment (B does not receive a duplicate of its ownspot report). At time t3, Squad C observes what might be aknown HVT ducking between buildings in the village. In thelast time step t4, Squad A receives C’s spot report about thepotential HVT because it is interested in HVTs. No Squadreceives the spot report about the Jeep because no one has asubscription for spot reports about Ground Track Vehicles.Table 2 gives a breaks down each squad’s event by time step.

In this scenario, we have shown that squads can subscribeto reports about high level concepts in the hierarchy (Spe-cial Equipment) and can receive reports about concepts sub-sumed (IED) by the higher level class. We have also demon-strated that even if a report is available to a warfighter byproximity (Jeep), she will not receive the message becausethere is no subscription or active query looking for that classor any of its ancestors.

ConclusionIn this paper, we discussed the necessity of a doctrine-basedontology as part of a larger solution to the issue of dissemi-nating critical information at the tactical edge. We describedthe methodologies and sources used to build the ontology,and provided samples of class instances as well as somecomplex SPARQL queries that can be used to reason for rel-evant information indirectly. For context, we described thereasoning system, Masterchief, and the ontology interface,Autogen. Finally, we gave a sample scenario in which high-lighted some of the less obvious capabilities of the ontologyand reasoning system.

AcknowledgementThis material is based upon work supported by the De-fense Advanced Research Projects Agency (DARPA) and

SPAWAR Systems Center Pacific (SSC Pacific) under Con-tract No. N66001-12-C-4052. Any opinions, findings andconclusions or recommendations expressed in this materialare those of the author(s) and do not necessarily reflect theviews of DARPA or SSC Pacific.

ReferencesBaader, F.; Brand, S.; and Lutz, C. 2005. Pushing the ELenvelope. In In Proc. of IJCAI 2005, 364–369. Morgan-Kaufmann Publishers.Cerf, V.; Burleigh, S.; Hooke, A.; Torgerson, L.; Durst, R.;Scott, K.; Fall, K.; and Weiss, H. 2007. Delay-tolerant net-working architecture. Technical report, RFC 4838, April.Clausen, T., and Jacquet, P. 2003. Optimized Link StateRouting Protocol (OLSR). RFC 3626, Internet EngineeringTask Force.Jacobson, V.; Smetters, D. K.; Thornton, J. D.; Plass, M. F.;Briggs, N. H.; and Braynard, R. L. 2009. Networking namedcontent. In CoNEXT ’09.Nguyen, D. N.; Kopena, J. B.; Loo, B. T.; and Regli, W. C.2010. Ontologies for distributed command and control mes-saging. Formal Ontologies in Information Systems.Sivakami, R., and Nawaz, G. 2011. Secured communicationfor manets in military. In Computer, Communication andElectrical Technology (ICCCET), 2011 International Con-ference on, 146–151.Strayer, T.; Kawadia, V.; Caro, A.; Nelson, S.; Ryder, D.;Clark, C.; Sadeghi, K.; Tedesco, B.; and DeRosa, O. 2013.CASCADE: Content access system for the combat-agile dis-tributed environment. In Military Communications Confer-ence, IEEE, 1518–1523.U.S. Department of Army. 2007. The operations process.Technical Report FM 5-0, U.S. Department of Army.U.S. Department of Defense. 2008. Common warfightingsymbology. Technical Report MIL-STD-2525C, U.S. De-partment of Defense.