Tactical Edge Characterization Framework: Volume 3 ... - Mitre

MTR080310
MITRE TECHNICAL REPO RT
Tactical Edge Characterization Framework
Volume 3: Evolution and Application of the
Framework
September 2008
Dr. Fatma Dandashi
Dr. Priscilla Glasow
Dr. David Kaplan
Weber Lin
Salim Semy
Jennifer Valentine
Dr. Beth Yost
Sponsor: OSD (NII) Contract No.: W15P7T-08-C-F600
Dept. No.: E543 Project No.: 0708ECSE-DA
The views, opinions and/or findings contained in this report are those of
The MITRE Corporation and should not be construed as an official
Government position, policy, or decision, unless designated by other
documentation.
2008 The MITRE Corporation. All Rights Reserved.
Approved for Public Release; Distribution Unlimited
Case Number: 09-0166

Executive Summary
Many approaches commonly used to develop a Service-Oriented Environment (SOE) presume
the availability of reliable, consistently available networks that provide significant bandwidth
and little to no latency. Since this is often not the case across the Department of Defense’s (DoD)
networks, the current development methods might not provide reliable capability to users in a
Tactical Edge (TE) environment. 1 This Enterprise Systems Engineering (ESE) Capstone activity
aims to ensure the viability of a SOE to a broader domain of tactical users by gaining a better
understanding of the TE and quantifying its characteristics.
During Fiscal Year (FY) 2007, the ESE Capstone activity developed a Tactical Edge Framework
(TEF). The primary objectives of the TEF are 1) to provide a classification of disadvantaged
users (i.e., users operating in a TE environment), and 2) to provide a common vocabulary to
characterize TE environments. The common vocabulary allows the TE characteristics to be
quantified and solutions to be identified to explicitly address the quantified characteristics. As
the DoD’s components deliver services to the TE, the TEF’s common vocabulary and use of
consistent solutions will promote interoperability across component-specific implementations.
The TEF was documented in two papers; “Common Vocabulary for Tactical Environments”,
which defines a common vocabulary that identifies classes of disadvantaged users at the TE and
characterizes their environments as a set of constraints [2], and “Design Patterns for Tactical
Environments,”, which describes a set of repeatable solutions (i.e., design patterns) to mitigate
the common TE constraints [3].
The focus of the FY 2008 activity was to socialize the TEF and facilitate its transition to the
DoD. The socialization of the TEF across the DoD’s components and the component’s
commands resulted in the validation and evolution of the TEF. The TEF’s evolution included
incorporating Central Command’s (CENTCOM) characterization of the tactical edge into the
TEF, as described by the “Disadvantaged User” white paper, and tailoring the TEF to better
incorporate the DoD’s component-specific perspectives of the TE. Furthermore, the common
vocabulary from the TEF was aligned with authoritative definitions of terms from joint
publications based on work completed by the Core Enterprise Services to the Tactical Edge
(CESTE) Focus Group.
Another focus of the FY 2008 activity was to apply the TEF across multiple DoD programs to
demonstrate its value. The TEF was applied throughout the service acquisition lifecycle, from
the collection of users’ requirements, to documenting use cases, to the design and development
of a service. TEF’s applicability was also demonstrated in managing the portfolio of services at
the TE. The TEF was employed by:
Special Operations Command’s (SOCOM) Tactical Local Area Network in interviewing
users at Tactical Special Operations Centers to collect functional requirements and usage
patterns.
1 Tactical edge is defined by Defense Information Systems Agency (DISA) as anything beyond the Defense Information Systems
Network Point-of-Presence.
iii

Net-Enabled Command Capability (NECC) program office to characterize Disconnected,
Intermittent, and Limited environments.
CESTE Focus Group to develop Performance and Service Reference Models and
departmental guidance for delivering Core Enterprise Services into and throughout the
TE.
Net-Centric Enterprise Solutions for Interoperability (NESI) to define characteristics of
TEF classes of environments’ such that relevant and tailored NESI guidance and best
practices can be identified for each class of TE environment.
As we reflect on the lessons learned from the ESE Capstone activity and consider future setups
to support the realization of services to the TE, we believe that use of the TEF should be further
institutionalized at a departmental level. In support of this, we recommend the following:
Joint Staff and doctrinal leads from the components should adopt the TEF to establish
DoD-wide definitions for the classes of TE environments and use the TEF’s common
vocabulary to characterize them.
The DoD Chief Information Officer and the Net-Centric (NC), Command and Control,
and Battlespace Awareness Capability Portfolio Managers should employ the TEF to
define Service and Performance Reference Models in order to establish an NC Enterprise
Architecture.
Defense Information Systems Agency’s Net-Centric Enterprise Services and NECC, in
conjunction with the DoD’s component-specific Programs of Record developing
enterprise services (e.g., Consolidated Afloat Networks and Enterprise Services, Army
System-Of-Systems Common Operating Environment, Marine Corps Enterprise
Information Technology Services, and Air Force’s Air and Space Operations Center as a
Weapon System) should use the TEF to define and document interfaces and design
patterns to achieve federation and meet Quality of Service requirements across DoD
component-specific TE platforms.
The adoption of a common characterization of the TE and the use of consistent design patterns
will minimize the architectural differences across the DoD’s components and promote
interoperability across component-specific service implementations at the TE.
iv

Acknowledgements
This work is the result of the contributions of many people across MITRE. We would like to
thank the following people for their participation in this project:
Frank Petroski and John McNamara for their leadership and guidance throughout the
project.
Francis Driscoll for his leadership and guidance to socialize the TEF across the Navy’s
programs.
Susan Cohn, Daniel Potter, Karen Carten, Amin Shaikh, Mark Troutt, and Michael Kazin
for developing the website.
Jeffrey Higginson and Marwan Sabbouh for providing valuable input as consultants
throughout the project.
Bruce Binney for his support to employ the TEF as part of the Navy’s Net-Enabled
Command Capability Component Program Management Office activities.
David Edwards for his collaboration in harmonizing the TEF with Central Command’s
“Disadvantaged User” white paper (working with Kris Newport and Robert Lee),
socializing the TEF within the Special Operations Command community, and using the
TEF as part of the Tactical Local Area Network program.
Bradford Mercer and Kenneth Griesi for their collaboration in providing the Navy’s input
to evolve the TEF and using the TEF within the Consolidated Afloat Networks and
Enterprise Services program.
John Michitson, James Kennedy, and Lynne Spruill for their collaboration in
incorporating the TEF into Net-Centric Enterprise Solutions for Interoperability.
David Miller and Janet Manu for their collaboration in socializing the TEF with the Core
Enterprise Services to the Tactical Edge Focus Group.
Colin Valentine, Robert Pitsko, Jeremy Brady, and Richard Sparshatt for providing the
Army’s input to evolve the TEF.
v

Table of Contents
1. Introduction ............................................................................................................................. 2
2. The Tactical Edge Framework ................................................................................................ 3
2.1 Common Vocabulary ............................................................................................................ 3
2.2 Classes of Tactical Edge Environments ................................................................................ 4
3. Evolution of the Tactical Edge Framework ............................................................................ 5
3.1 Harmonizing With the Central Command Representation ................................................... 5
3.2 Tailoring the Tactical Edge Framework ............................................................................... 6
3.2.1 Process of Tailoring the Tactical Edge Framework ....................................................... 7
3.2.2 Results of Tailoring the Tactical Edge Framework ....................................................... 7
3.2.3 Implications of Tailoring the Tactical Edge Framework ............................................... 8
4. Applications of the Tactical Edge Framework ....................................................................... 9
4.1 Collect User Requirements ................................................................................................. 10
4.2 Develop Mission Threads ................................................................................................... 11
4.3 Identify Design Patterns ...................................................................................................... 11
4.4 Identify Services ................................................................................................................. 12
4.5 Identify Technology Standards and Best Practices ............................................................. 12
4.6 Support Service Acquisition ............................................................................................... 13
4.7 Support Portfolio management ........................................................................................... 13
5. Tactical Edge Framework Website ....................................................................................... 13
6. Conclusions and Recommendations ..................................................................................... 15
7. References ............................................................................................................................. 16
Appendix A: Harmonization of the Tactical Edge Framework and Central Command’s
“Disadvantaged User” White Paper .............................................................................................. 17
Appendix B: Authoritative Definitions of Common Vocabulary Terms...................................... 18
Appendix C: Cross Referencing Common Vocabulary With the Tactical Edge Gateway
Functionality Taxonomy ............................................................................................................... 21
Appendix D: Acronym List .......................................................................................................... 22
vi

List of Figures
Figure 1. Common Vocabulary for TE Environments.................................................................... 3
Figure 2. Using the Common Vocabulary to Characterize a Destroyer ......................................... 4
Figure 3. Binning Platforms With Similar Constraints Into a Representative Class ...................... 5
Figure 4. Harmonized Tactical Edge Framework ........................................................................... 6
Figure 5. Non-Tailored Tactical Edge Framework vs. Tailored for Special Operations Command
......................................................................................................................................................... 7
Figure 6. Accuracy of Design Patterns With the Tailored Tactical Edge Framework ................... 9
Figure 7. Applications of the Tactical Edge Framework .............................................................. 10
Figure 8. Main Page of the Tactical Edge Framework Website ................................................... 14
Figure 9. Using Web Architect to Find Tailored Guidance .......................................................... 15
vii

1. Introduction
Many approaches commonly used to develop Service-Oriented Environments (SOE) presume the
availability of reliable, consistently available networks that provide significant bandwidth and
little to no latency. Since this is often not the case across the Department of Defense’s (DoD)
networks, current development methods might not provide reliable capabilities to users in a
Tactical Edge (TE) environment 2 . This Enterprise Systems Engineering (ESE) Capstone activity
aims to ensure the viability of an SOE to a broader domain of tactical users by gaining a better
understanding of the TE and quantifying its characteristics.
During Fiscal Year (FY) 2007, the ESE Capstone activity developed a Tactical Edge Framework
(TEF). The primary objectives of the TEF are to 1) provide a classification of disadvantaged
users (i.e., users operating in a TE environment) and 2) to provide a common vocabulary to
characterize TE environments. The common vocabulary allows the TE characteristics to be
quantified and subsequently, solutions to be identified to explicitly address the constraints. As
the DoD’s components deliver services to the TE, the TEF’s common vocabulary and use of
consistent solutions (i.e., design patterns) will promote interoperability across componentspecific
implementations.
The results of this work are documented in two papers; “Common Vocabulary for Tactical
Environments,” which defines a common vocabulary that identifies classes of disadvantaged
users at the TE and characterizes their environments as a set of constraints [2], and “Design
Patterns for Tactical Environments,” which describes a set of repeatable solutions (i.e., design
patterns) for the commonly occurring problems [3]. These design patterns define options to help
mitigate the constraints at the TE and enable the delivery of services to users in constrained
environments. The paper also documents infrastructure requirements and a reference
implementation associated with the design patterns.
The focus of the FY 2008 activity was to apply the TEF to DoD programs, while continuing to
socialize and evolve the TEF and facilitate its transition to the DoD. The activity’s three major
thrusts were to:
Socialize the TEF across the DoD’s components and the components’ commands.
Evolve the TEF, harmonize it with other representations of the TE, and validate it with
the DoD’s components.
Apply the TEF to tactical Programs of Record (PoR) across the DoD to demonstrate its
value throughout the service acquisition lifecycle, including collecting users’
requirements, documenting use cases, designing and developing services, and managing a
portfolio of services at the TE.
This paper is organized as follows: Section 2 of this paper provides an overview of the
components of the TEF, including the common vocabulary and classes of TE environments.
Section 3 describes how the TEF evolved in FY 2008, including the tailored versions developed
2 Tactical Edge is defined by DISA as anything beyond the Defense Information Systems Network’s (DISN) Point-of Presence
(PoP).
2

for the Navy, Army, and Special Operation Forces. Section 4 details how the TEF was applied to
provide guidance for the DoD’s programs by using the TEF to support the collection of users’
requirements and use case documentation, the design and development of a service, and
management of a portfolio of services at the TE. Section 5 provides an overview of the TEF
website. Section 6 provides a summary of accomplishments and recommendations for advancing
the delivery of services to the TE.
2. The Tactical Edge Framework
The TEF provides a common vocabulary for identifying constraints at the TE. Employing these
common terms allows one to recognize commonalities across the Services’ TE platforms. The
FY 2007 work created the common vocabulary and identified a set of design patterns; the FY
2008 work used the vocabulary and design patterns as the first essential step in applying the TEF
to provide guidance across the DoD’s programs.
2.1 Common Vocabulary
The common vocabulary is a fundamental part of the TEF; it provides the building blocks for a
user to characterize the TE environment. The common vocabulary consists of a set of attributes
and possible values for the attributes. The attributes represent the constraints of the environment
that are important to consider for the delivery of services to the TE. The TEF attributes
characterize the network, system, physical environment, operational and security constraints.
(See Figure 1.)
Network Operational System
Connectivity
Bandwidth
Latency
Reliability
Predictability
Physical Environment Security
Heating, Ventilation,
and Air Conditioning
(HV/AC)
Lighting
Hazards
Repairability
Decision Timelines
Content
System Training
Confidentiality
Integrity
Availability
Figure 1. Common Vocabulary for TE Environments
3
System Processing
Storage
Standard User Interface
Ruggedness
Size, Weight, & Power
(SWaP)
The common vocabulary can be used to describe the TE constraints. (See Figure 2.) Red, yellow,
and green indicate the degree to which a particular value is a constraint; green represents
minimal to no constraints, yellow represents moderate constraints, and red represents severe

constraints. The end result is a consistent characterization that can be used to compare
constraints across the Services’ TE platforms.
Figure 2. Using the Common Vocabulary to Characterize a Destroyer
The common vocabulary of the TEF that was developed during the FY 2007 ESE Capstone
activity was applied and verified during the FY 2008 ESE Capstone activity. In addition, during
FY 2008, the vocabulary was aligned with authoritative definitions of terms from joint
publications based on work completed by the Core Enterprise Services to the Tactical Edge
(CES2TE) Focus Group. The vocabulary is provided in Figure 1 and the authoritative definitions
are provided in Appendix B. All definitions are from Joint Publication 1-02, Department of
Defense Dictionary of Military and Associated Terms. As amended through May 30, 2008
(http://www.dtic.mil/doctrine/jel/doddict).
In addition to aligning the vocabulary with authoritative definitions from Joint Publication 1-02,
the vocabulary can also be cross referenced with existing terms of reference, such as “Tactical
Edge Gateways Functional Taxonomy,” in Appendix C [1].
2.2 Classes of Tactical Edge Environments
Characterizing platforms using the TEF’s common vocabulary can help classify platforms that
have similar constraints. When constraints are similar, rather than treating each platform
individually, it is useful to define a representative set of classes in which to bin the platforms.
(See Figure 3.) The classes of TE environments defined in the TEF provide the benefit of
reducing the classification of TE platforms to a manageable set, which leads to reusable solutions
across multiple platforms and DoD components. The classes of TE environments defined in the
TEF are based on the analysis of use cases across the DoD to identify commonalities in the
constraints of the TE environment. The class names and attribute values may be tailored to suit
specific DoD components’ terms of reference and constraints.
4

Figure 3. Binning Platforms With Similar Constraints Into a Representative Class
3. Evolution of the Tactical Edge Framework
In FY 2008, one of the major thrusts was the evolution of the TEF. This evolution was the result
of two primary activities: 1) harmonizing the TEF with the CENTCOM’s TE representation, and
2) tailoring the TEF’s attribute values for particular DoD components.
3.1 Harmonizing With the Central Command Representation
The TEF was harmonized with findings from another effort described in the “Disadvantaged
User” 3 white paper. The names of the classes of TE environments, the common vocabulary, and
specific values were harmonized. Some key decisions that came from this harmonization process
are documented in Appendix A.
The results of the harmonization process are reflected in the TEF. The numerical values in the
TEF are a result of combining the TEF’s values with CENTCOM’s values as defined in the
“Disadvantaged User” white paper and then further iterating with Subject Matter Experts (SMEs)
as described in Section 3.2. The TEF that resulted from this FY 2008 harmonization activity is
shown in Figure 4. The rows represent the common vocabulary used to describe the constraints
at the TE. Each column represents a unique class of TE environment. The colors define the
3 http://communityshare.mitre.org/sites/g051/CENTCOM/Products/Forms/AllItems.aspx
5

degree of constraints; green represents minimal to no constraints, yellow represents moderate
constraints, and red represents severe constraints.
Figure 4. Harmonized Tactical Edge Framework
3.2 Tailoring the Tactical Edge Framework
Ideally, all of the military Services’ platforms fit nicely into one of the classes of TE
environments defined in the TEF. In practice, while the majority of the platforms fit into one of
the TEF’s classes of environments, the flexibility to tailor the TEF’s attribute values makes it
more widely applicable. This need for flexibility was more noticeable after the FY 2008
harmonization process; the TEF values transitioned from focusing on high-level text descriptions
(e.g., good connectivity) to focusing on numerical values (e.g., 85-100% connectivity). There
can be agreement by the military Services on high-level descriptions, but disagreement on
numerical values. Tailoring the TEF means it can be applied to situations where a platform does
not fit into one of the four classes of TE environments defined in the non-tailored TEF, while
retaining the benefits of using a common vocabulary to describe the classes of TE environments.
6

3.2.1 Process of Tailoring the Tactical Edge Framework
While the common vocabulary remains constant (i.e., the attributes that characterize classes of
TE environments do not change), a user can adjust the specific values of the attributes to better
reflect their platforms. For extreme differences in values, the tailored values can essentially
result in an entirely new class of TE environment. The process of tailoring the TEF involves
engaging SMEs and finding authoritative documentation, if possible, to support the SMEs’
recommendations.
3.2.2 Results of Tailoring the Tactical Edge Framework
The first tailored version of the TEF was created for Special Operations Command (SOCOM).
Special Operations Forces are unique in that their operations require very good connectivity,
plenty of bandwidth, and spare parts must be available. The SOCOM-specific TEF values
include >99% connectivity (even for dismounted users) and up to two megabits of bandwidth per
second for dismounted users. The majority of the tailored values were consistent with the nontailored
TEF, which helped further validate the original values. The differences between the nontailored
TEF and SOCOM’s tailored version are shown in Figure 5.
Figure 5. Non-Tailored Tactical Edge Framework vs. Tailored for Special
Operations Command
For the Navy, one of the major issues with the non-tailored TEF was that the majority of the
Navy’s fleet straddled two categories (i.e., Tactical Mobile Center and Mobile Platform). As a
result, a hybrid class of TE environment was created in the Navy’s tailored TEF, which included
the characteristics of both classes of TE environments. The Navy’s hybrid class replaces the nontailored
TEF’s Mobile Platform class. While the TEF’s vocabulary remained constant, the Navy-
7

specific TEF was developed in coordination with Navy SMEs to better represent the Navy’s
perspective.
Finally, within the Army, one of the major extensions of the TEF was adding a new class to
characterize unmanned systems, including a subclass for Tier 1 Unmanned Systems (e.g., small
unmanned ground sensors) and another subclass for Tier 2 Unmanned Systems (e.g., medium-tolarge
unmanned platforms, such as the Predator). The Army also updated the way in which the
network was characterized from a Local Area Network/Wide Area Network distinction in the
non-tailored TEF to specific communication architectures within and between TE environments.
The differences between the Army’s tailored TEF and the non-tailored TEF were so significant
that the additional Unmanned Aircraft Systems classes and the method of characterizing the
network were not rolled up into the non-tailored TEF; however, we believe that incorporating
these differences into the non-tailored TEF warrants further consideration as the TEF continues
to evolve.
For the Navy and Army, the tailored versions of the TEF continue to evolve. Current iterations
are available on the TEF website, which is discussed in Section 5.
3.2.3 Implications of Tailoring the Tactical Edge Framework
Tailoring the values in the TEF can be problematic if solutions are mapped to entire TE
environments (e.g., Mobile Platform). For example, consider a case where an existing chat
service is operational in a Mobile Platform environment, which is characterized in the nontailored
TEF as having moderate bandwidth and connectivity constraints. If the Mobile Platform
environment is tailored so the bandwidth and connectivity are severely constrained rather than
moderately constrained, the chat service might not work in the tailored Mobile Platform
environment with severe constraints.
This problem can be solved by mapping solutions to attributes rather than TE environments. If
the chat service was mapped to moderate bandwidth and connectivity constraints rather than the
Mobile Platform environment, the chat service would still be mapped to the moderately
constrained non-tailored Mobile Platform environment; however, the chat service would no
longer be mapped to the severely constrained tailored Mobile Platform environment. For an
example, see Figure 6.
As mentioned previously, the ability to apply the TEF to situations that do not perfectly match
the non-tailored TEF environments increases the TEF’s applicability to a larger audience and
solutions can accurately be mapped to any TE environment as long as it is described using the
common vocabulary.
8

Figure 6. Accuracy of Design Patterns With the Tailored Tactical Edge Framework
4. Applications of the Tactical Edge Framework
To validate the TEF and support adoption, the TEF was applied to multiple DoD programs to
demonstrate the TEF’s contributions to realize services at the TE. This section describes the
TEF’s applicability throughout the service’s acquisition lifecycle, including collecting users’
requirements, documenting use cases, designing and developing a service, and managing a
portfolio of services at the TE. (See Figure 7.)
9

A
p
p
l
y
T
E
F
Identify performance measures and outcomes, metrics
Mission Threads/Use Cases
2) Model mission threads in BPMN, map actors to TEF
environments
Core Enterprise Services
• M2M Messaging
• Mediation
• Security Service
• Service Discovery
• Collaboration
• Content Delivery
• Content Discovery
• People Discovery
• ESM
4.1 Collect User Requirements
Joint Capability Areas (JCAs)
1) Collect user requirements based on identified capability gaps
Technology
(standards)
6) Support service acquisition
-Identify industry standards for edge networking
-Identify technical standards/specification for deploying services
-Identify DoD/industry standards for data formats
Figure 7. Applications of the Tactical Edge Framework
In the process of defining strategic roadmaps, it is important to start by determining users’ needs,
defining the strategic goals for capability development, and using this information to identify
capability gaps. While some capability gaps can emerge from the portfolio management
processes, interviewing users is also a key component of identifying capability gaps and
collecting requirements for future capabilities. The TEF can be utilized in this process to identify
capability gaps by asking end-users about their functional operational needs, documenting
mission threads (e.g., how they accomplish their tasks), and by inquiring about their TE
environment’s constraints using the TEF’s common vocabulary and attribute values as guidance.
(See Figure 7, Step 1.) This results in capturing end-user requirements in the context of the
constraints of the environment. Once the necessary functions are identified for specific
constrained environments, identifying where current or planned solutions might be inadequate
becomes evident as TEF guidance, which includes a set of design patterns that are useful for
specific environments. In this manner, capability gaps are flagged and can be documented (i.e.,
where current or planned services do not intersect with recommended guidance).
As an example, the TEF was employed by SOCOM’s Tactical Local Area Network team during
interviews with users at Tactical Special Operations Centers (TSOCs), including Special
10
Design Patterns /mission thread decomposition
4) Identify services based on
applicable TEF environment values
and identified patterns
Data
3) Decompose mission threads
and identify design patterns
Services
5) Identify technology standards and
best practices
- SLA
- Rules
- Policy

Operations Command, South and Special Operations Command, Central. Prior to the interviews
at TSOCs, questions were formulated that included queries about the TE environment and
environment-specific attributes as defined by TEF. With these questions, the interviewers
collected functional requirements and usage patterns that can feed into use cases related to
specific TE environments. Including questions about the TEF’s attributes in the interview
process also helped validate the TEF with the SOCOM community.
4.2 Develop Mission Threads
Using the capability gaps and user requirements as a starting point, the next step is to document
use cases through the development of mission threads, which in essence defines the Concept of
Operations of the needed capability. Mission threads can include interaction patterns between
actors. The actors in a TE mission thread can be characterized by using the TEF’s common
vocabulary and binning the actors into one of the four classes of TE environments (i.e., Tactical
Fixed Center, Tactical Mobile Center, Mobile Platform, and Dismounted User). This is the
equivalent of mapping each swim lane in a Business Process Modeling Notation 4 process flow
diagram to the applicable TE environment. (See Figure 7, Step 2.) The benefit of this alignment
is that it identifies the constraints that need to be taken into account within and across multiple
classes of TE environments.
For example, the Core Enterprise Services to the Tactical Edge (CESTE) Focus Group is using
the TEF to develop reference models for the DoD Chief Information Officer’s (CIO)
organization. The TEF was used by the CESTE Focus Group to map actors in a Joint Close Air
Support (JCAS) scenario to the TEF’s classes of TE environments. This mapping was used as
part of identifying the Business Reference Model’s content for the JCAS’ architecture. Once this
mapping was complete, the TEF vocabulary and the attribute values for each class of TE
environment of the JCAS’ actors were immediately available for use as non-functional
performance metrics. The values were employed as metric constrains and were used to define
and populate the Performance Reference Model for the JCAS’ architecture.
4.3 Identify Design Patterns
Aligning mission threads with the TEF allows one to identify applicable design patterns and
other guidance, which enables the delivery of effective services to support the mission threads.
Design patterns are first associated with the TEF’s attribute constraints that they can help
mitigate [3]. (See Appendix C.) For example, a design pattern can be associated with intermittent
connectivity and low bandwidth. Services are aligned with the TEF’s classes of environments in
which they were designed to function. (See Figure 7, Step 3.)
For example, the TEF was used by the Net-Enabled Command Capability (NECC) program to
characterize Disconnected, Intermittent, and Limited (DIL) environments and define the
interface between the Global Information Grid Computing Nodes (GCN), including enterprise
GCNs (e.g., Defense Information Systems Agency’s [DISA] Enterprise Computing Center) and
local GCNs (e.g., DIL environments).
4 Business Process Modeling Notation, as defined by the Object Management Group .
11

MITRE recommended an adaptation of the common vocabulary to characterize NECC’s local
GCNs in order to differentiate between the classes of local GCNs from those of enterprise
GCMs, and to further tailor the solution sets being developed for the local GCNs to differentiate
them from those being adopted for enterprise GCNs. These recommendations are documented in
the paper, “NECC Disconnected, Intermittent, Low Bandwidth Requirements and Architectural
Approaches” (NECC Disconnected, Intermittent, Low Bandwidth Requirements and
Architectural Approaches 2008). In addition, NECC’s Architecture Framework document
adopted the DIL characterization in its definition of the operational environment [5].
4.4 Identify Services
Aligning a mission thread’s actors with the applicable TEF class of environment allows for the
identification of services and design patterns that provide options to help in mitigating the
constraints for a particular TE mission thread. The design patterns can then be incorporated into
service specifications to ensure that the results can provide the needed capabilities given the
constraints of the classes of TE environments. In addition, aligning service solutions to the TEF
(i.e., mapping service solutions to the classes of TE environments in which they currently, or are
intended to, operate) allows Portfolio Managers (PMs) to assess the existing portfolio to
determine if a newly identified capability need can be met with existing solutions, and if such
solutions will support use in the intended TE environment. In other words, mapping services to
TEF classes of environments allows PMs to look across an existing portfolio of services and
COTS tools to identify existing solutions built with the necessary underlying assumptions about
constraints. (See Figure 7, Step 4.) The TEF classes of environments allow for comparisons
across DoD components and various types of TE platforms that otherwise can have appeared as
distinct entities.
For example, under the CESTE Focus Group, CES were identified from the information flows
modeled in the JCAS scenario. The TEF’s design patterns were then used to identify specific
service tailoring needed for each JCAS actor, as required by their class of TE environment. This
mapping was used to define the Service Reference Model and identify required services for the
JCAS architecture.
4.5 Identify Technology Standards and Best Practices
Best practices and standards are a crucial enabler of interoperable systems because they promote
a reasonable degree of consistency across service implementations. One challenge in employing
this guidance is determining what is applicable; it is often difficult to identify the specific
guidance that applies to a particular situation. For example, a developer might focus on defining
a data staging strategy for users who have connectivity only 10-40% of the time. The TEF can be
used to organize best practices and standards for developers. Within the TEF, mapping the
classes of TE environments to the best practices and standards organizes the guidance so it can
be navigated by a particular TE environment or constraint. (See Figure 7, Step 5.) The TEF
allows developers to identify specific guidance based on a particular context (e.g., user interfaces
for dismounted users). The guidance can also be tailored to address a particular challenge in a TE
environment. The intent is to provide a TE perspective on the multiple volumes of guidance so a
user developing services for the TE can employ the TEF to navigate through the material and
identify relevant and possibly tailored guidance. The guidance is aligned with the constraints of
12

the TE environment to support binning the guidance by the constraints as well as clustering it by
the classes of TE environments.
For example, this approach is being employed by Net-Centric Enterprise Solutions for
Interoperability (NESI), specifically within NESI’s Part 4 on Node Guidance. The TEF was used
to define operational environment characteristics for the Global Information Grid’s core and the
TE; the common vocabulary was used to define criteria so relevant guidance and best practices
for implementing the node capabilities within NESI can be specified for each operational
environment.
4.6 Support Service Acquisition
A challenge with acquiring systems for the TE is identifying quantifiable criteria to assess the
readiness of the systems that will operate within TE environments. Aligning mission threads to
the TEF provides a means to characterize the constraints of the classes of TE environments using
a common vocabulary and to derive the non-functional requirements that can be part of a
Request for Proposal (RFP). (See Figure 7, Step 6.) These non-functional requirements
characterize the unique considerations of each TE environment in which the system will be
deployed. The TEF also provides a common means to assess bidder’s submissions. In the
proposal creation process, bidders can describe the classes of TE environments for which their
solutions will provide capabilities and align them to the non-functional requirements in the RFP.
This simplifies the proposal evaluation process by grouping the proposed services into a
common set of bins to characterize and assess the proposals. Furthermore, quantifying the
constraints of the TE environments through common attribute values helps identify design
patterns against which the proposed solutions can be compared.
4.7 Support Portfolio management
To support portfolio management, the CESTE Focus Group will deliver a plan to explore issues
associated with the deployment of services at the TE, a set of reference models, and departmental
guidance for delivering Core Enterprise Services to and throughout the TE. The value of
applying the TEF to the reference models’ development is the TEF’s common vocabulary (i.e.,
set of attributes) characterize different aspects of the classes of TE environments and provides
the basis for an initial service and performance TE ontology.
5. Tactical Edge Framework Website
As shown in the examples in Section 4, the TEF can be applied throughout the process of
analyzing, designing, and developing TE services. To encourage the adoption and re-use of the
TEF, the FY 2008 ESE Capstone activity’s products were posted on an interactive website. (See
Figure 8.) The website is currently available on MITRE’s internal network
(http://calypso.mitre.org/tacticaledgeframework) and it can be accessed at a secure external
website for both government and MITRE access
(https://yukon2.mitre.org/tacticaledgeframework/).
13

Figure 8. Main Page of the Tactical Edge Framework Website
The main page provides an overview of the TEF, describing why it was developed and what it
can be used for. From the main page, users can access the latest version of the TEF, design
patterns, existing services, and examples of TE use cases. These features allow MITRE to
provide the most up-to-date tailored versions of the TEF, an overview of the existing services
that were designed to work in the TEF’s classes of environments, and access to a significant
repository of cutting-edge design patterns intended to overcome common constraints at the TE.
In addition to finding content, users can also contribute content to the website. We hope the
website’s content will become richer and more expansive as awareness of the website increases
and government users add to it. After a user is approved for an account, he or she can:
Add use cases that describe user requirements and TE constraints.
Add design patterns and associate them with the TEF’s common vocabulary.
Add services and bin them by the type of TE environment in which they are intended to
function.
As users contribute and search for content, they are essentially using processes similar to those
used by MITRE’s ESE Capstone activity team in applying the TEF in FY 2008 (i.e., capturing
user requirements, identifying design patterns to overcome constraints, and consolidating the
services designed to work in the TEF’s classes of environments).
An additional feature provides a powerful method to search for relevant design patterns. Using
the Web Architect model, users can choose specific classes of TE environments and attributes
from the TEF and tailor the constraints to match their classes of TE environments, to retrieve the
most accurate results for a specific TE environment. (See Figure 9.)
14

Figure 9. Using Web Architect to Find Tailored Guidance
In the future, we hope the TEF website will enable users of the TEF to more readily capture TE
users’ requirements, identify design patterns to overcome TE constraints, consolidate TE
services, and more.
6. Conclusions and Recommendations
The primary objective of the TEF is to provide a common vocabulary to characterize TE
environments so the TE characteristics can be quantified and solutions can be identified to
explicitly address them. Subsequently, as the DoD’s components deliver services to the TE, the
TEF’s common vocabulary and use of consistent design patterns will promote interoperability
across component-specific implementations.
To support this objective, the focus of MITRE’s ESE Capstone activity in FY 2008 was to
socialize the TEF and facilitate its transition to the DoD. The socialization of the TEF across the
DoD’s components and the component’s commands resulted in the validation and evolution of
the TEF.
Another focus of the FY 2008 activity was to apply the TEF across multiple DoD programs to
demonstrate its value. This resulted in the initial adoption of the TEF across several DoD
programs. Along with this progress toward the bottom-up adoption of the TEF, it is imperative
that the use of the TEF and its common vocabulary be further institutionalized at a departmental
level. In support of this, we recommend the following:
Joint Staff and doctrinal leads from the components should adopt the TEF to establish
DoD-wide definitions for the classes of TE environments and use the TEF’s common
vocabulary to characterize them.
15

The DoD CIO and the Net-Centric (NC), Command and Control, and Battlespace
Awareness Capability PMs should employ the TEF to define Service and Performance
Reference Models in order to establish an NC Enterprise Architecture.
DISA’s Net-Centric Enterprise Services and NECC, in conjunction with the Servicespecific
PoR developing enterprise services (e.g., Navy Consolidated Afloat Networks
and Enterprise Services, Army System-Of-Systems Common Operating Environment,
Marine Corps Enterprise Information Technology Services, and Air Force Air and Space
Operations Center as a Weapon System) should use the TEF to define and document
interfaces and design patterns to achieve federation and meet Quality of Service
requirements across Service-specific TE platforms.
The adoption of a common characterization of the TE and the use of consistent design patterns
across the DoD will minimize architectural differences across the DoD’s components and
promote interoperability across component-specific service implementations at the TE.
7. References
1. Dally, K. et al.,"Tactical Edge Gateway Functional Taxonomy," October 2007, ESE
Capstone Product, The MITRE Corporation, MTR 070286.
2. Dandashi, F. et al., "Tactical Edge Characterization Framework, Volume 1: Common
Vocabulary for Tactical Environments," November 2007, ESE Capstone Product, The
MITRE Corporation, MTR 070331.
3. Dandashi, F. et al., "Tactical Edge Characterization Framework, Volume 2: Design
Patterns for Tactical Environments," September 2007, ESE Capstone Product, The
MITRE Corporation, MTR 070326.
4. Net-Enabled Command Capability, "NECC Disconnected, Intermittent, Low Bandwidth
Requirements and Architectural Approaches," 2008.
5. Net-Enabled Command Capability, "NECC Software Architecture Framework, Software
and Physical Views," 2008.
16

Appendix A: Harmonization of the Tactical Edge Framework and
Central Command’s “Disadvantaged User” White Paper
Class names were merged:
o Tactical Edge Framework’s (TEF’s) “fixed center” and Central Command’s
(CENTCOM) “tactical fixed” became “tactical fixed center.”
o TEF’s “mobile center” and CENTCOM’s “tactical semi-fixed” became “tactical
mobile center.”
o TEF’s “mobile swarm” and CENTCOM’s “mobile (mounted and maritime)”
became “mounted user.” [Note: After the harmonization process, this class was
renamed “mobile platform.”]
o TEF’s “dismounted” and CENTCOM’s “mobile-dismounted” became
“dismounted user.”
High-level categories were merged:
o TEF categories: network, resource, user interface, and security threats.
o CENTCOM categories: physical and environment, communications, and
operational/other.
o Harmonized categories: network, system, environment, operational, and security.
Attribute values were merged:
o TEF values: general characterization (e.g., high, medium, and low).
o CENTCOM values: specific values.
o Harmonized values: described as a range between two specific values.
Standard terms of reference were replaced with unofficial attribute names:
o Size, Weight, and Power terminology was used.
o Confidentiality, Integrity, and Availability terminology was used in the security
category.
o CENTCOM’s spectral environment attribute was combined with TEF’s
predictability attribute.
o Heating, Ventilation, and Air Conditioning and environmental constraints
remained because Special Operations Command considered them to be important
issues. The Communications Architecture column from CENTCOM’s TEF (i.e.,
wideband satellite communications, cable, fiber, wireless, etc.) was adequately
captured by the Local Area Network/Wide Area Network (LAN/WAN) aspects in
the harmonized TEF. It was noted that line-of-site can be a point-to-point
connection that does not have a LAN/WAN interface.
17

Appendix B: Authoritative Definitions of Common Vocabulary Terms
Network
System
Connectivity: “The ability to exchange information by electronic means.” The Tactical
Edge Framework (TEF) measures connectivity using the frequency with which the
network is available. This can be quantified as a percentage of time when connectivity is
available.
Bandwidth: “The difference between the limiting frequencies of a continuous frequency
band expressed in hertz (i.e., cycles per second). The term bandwidth is also loosely used
to refer to the rate at which data can be transmitted over a given communications circuit.
In the latter usage, bandwidth is usually expressed in either kilobits per second or
megabits per second.” The TEF measures bandwidth in kilobits or megabits per second.
Latency: Definition not in Joint Publication 1-02. The TEF uses latency to mean the
amount of time it takes a packet of data to travel from one point to another in a network.
It is measured in milliseconds.
Reliability: Definition not in Joint Publication 1-02. The TEF uses reliability to indicate
whether the delivery of a message in a network is guaranteed or not. It is measured as the
percent of time the delivery is guaranteed. A lack of reliability can Result from a
resource’s failure or packet loss.
Predictability: Definition not in Joint Publication 1-02. The TEF uses predictability to
mean the degree that the network environment can be anticipated (e.g., spectral
environment, delivery of messages, security threats, lighting constraints, etc.) at any
given time. A discrete value of predictable, mostly predictable, less predictable, or
unpredictable is used in the TEF to indicate predictability.
System Processing: “A system of operations designed to convert raw data into useful
information.” The TEF provides a measure of processing power by binning processing
power into handheld, single workstation, multiple workstations, or servers. A more
specific measurement can be the rate at which a computing device performs operations,
(i.e., the clock rate [speed] of the Central Processing Unit).
Storage: “A device consisting of electronic, electrostatic, electrical, hardware or other
elements into which data may be entered, and from which data may be obtained as
desired.” The TEF provides a measure of storage by binning storage into handheld
memory, single data storage device, and large data storage device. A more specific
measurement can be gigabytes.
Standard User Interface (SUI): Definition not in Joint Publication 1-02. The TEF uses
SUI to mean the type of device being used and the corresponding standard style of the
user interface for the device. The TEF bins SUI into handheld, tablet, laptop, and
desktop.
Ruggedness: Definition not in Joint Publication 1-02. The TEF uses ruggedness to mean
a device’s ability to survive the environment’s hazards. The TEF bins ruggedness into the
number of environmental constraints that a device needs to withstand (i.e., few, some,
and many ruggedness considerations).
18

Size: 1) "Available Payload: The passenger and/or cargo capacity expressed in weight
and/or space available to the user." Or 2) "Man Portable: Capable of being carried by one
man. Specifically, the term may be used to qualify: 1. Items designed to be carried as an
integral part of individual, crew-served, or team equipment of the dismounted soldier in
conjunction with assigned duties. Upper weight limit: approximately 14 kilograms (31
pounds.) 2. In land warfare, equipment that can be carried by one man over long distance
without serious degradation of the performance of normal duties." The TEF bins size into

Security
meaning is or might be assigned.” The TEF measures data complexity by binning it into
complex, intermediate, and simplified.
System Training: Definition not in Joint Publication 1-02. The TEF uses system training
to mean the amount of training a user receives on how to use the application, which is a
combination of the length and type of training and the frequency of use. System training
is binned into minimal, intermediate, and extensive.
Information Assurance (IA): “Measures that protect and defend information and
information systems by ensuring their availability, integrity, authentication,
confidentiality, and non-repudiation.” This includes providing for the restoration of
information systems by incorporating protection, detection, and reaction capabilities.
Confidentiality: Definition not in Joint Publication 1-02. The TEF uses confidentiality to
mean assurance that information is not disclosed to unauthorized persons, processes, or
devices. The TEF provides a list of the most common types of risks to confidentiality in
each environment.
Integrity: Definition not in Joint Publication 1-02. The TEF uses integrity to mean the
quality of an information system reflecting the logical correctness and reliability of the
operating system, the logical completeness of the hardware and software implementing
the protection mechanisms, and the consistency of the data structures and occurrences of
the stored data. In a formal security mode, integrity can be interpreted more narrowly to
mean protection against unauthorized modification or the destruction of information. The
TEF provides a list of the most common types of risks to integrity in each environment.
Availability: Definition not in Joint Publication 1-02. The TEF uses availability to mean
timely, reliable access to data and information services for authorized users. The TEF
provides a list of the most common types of security risks to availability in each
environment.
All definitions in quotations are from Joint Publication 1-02, Department of Defense Dictionary
of Military and Associated Terms. As amended through 30 May 2008
(http://www.dtic.mil/doctrine/jel/doddict).
20

Appendix C: Cross Referencing Common Vocabulary With the Tactical
Edge Gateway Functionality Taxonomy
The following are approximate mappings from the Tactical Edge Framework to the Tactical
Edge Gateways Functional Taxonomy [1]:
Bandwidth – Capacity
Reliability – Signal, Statistical Availability
Predictability – Station Time
Confidentiality – Access
Integrity – Traffic
Availability – Threat Survivability
Storage – Storage
Size, Weight, and Power (SWaP) – SWaP Suitability, Existing Payloads
Network and Security category attributes – Operational Enabling attributes
System, Environment, and Operational category attributes – Operational Fit attributes
TEF classes – Gateway Platforms.
21

Appendix D: Acronym List
CENTCOM Central Command
CES2TE Core Enterprise Services to the Tactical Edge
CIO Chief Information Officer
COTS Commercial Off-the-Shelf
CPMO Component Program Management Office
DIL Disconnected, Intermittent, and Limited
DoD Department of Defense
ECU Environmental Control Unit
ESE Enterprise Systems Engineering
FY Fiscal Year
GCN Grid Computing Node
HVAC Heating, Ventilation, and Air Conditioning
IA Information Assurance
LAN Local Area Network
NC Net-Centric
NECC Net-Enabled Command Capability
NESI Net-Centric Enterprise Solutions for Interoperability
PoR Programs of Record
RFP Request for Proposal
SME Subject Matter Experts
SOCOM Special Operations Command
22

SOE Service-Oriented Environment
SUI Standard User Interface
TE Tactical Edge
TEF Tactical Edge Framework
TSOC Tactical Special Operations Centers
WAN Wide Area Network
23