NATO FFT Arch Concept and Roadmap (NU)

DRAFT Technical Note 1322
NATO FRIENDLY FORCE TRACKING

ARCHITECTURE CONCEPT AND ROADMAP
R. Porta
February 2009
The Hague
CONDITIONS OF RELEASE
With reference to NATO Documents C-M(2002)49 and AC/322-D/1, this

document is released to a NATO Government at the direction of the NATO
Consultation, Command and Control (C3) Agency subject to the following
conditions:
1. The recipient NATO Government agrees to use its best endeavours to

ensure that the information herein disclosed, whether or not it bears a security
classification, is not dealt with in any manner (a) contrary to the intent of the
provisions of the Charter of the NATO C3 Organization, or (b) prejudicial to
the rights of the owner thereof to obtain patent, copyright or other likely
statutory protection therefor.
2. If the technical information was originally released to the Agency by a

NATO Government subject to restrictions clearly marked on this document
the recipient NATO Government agrees to abide by the terms of the
restrictions so imposed by the releasing Government.
DRAFT Technical Note 1322
NATO FRIENDLY FORCE TRACKING

ARCHITECTURE CONCEPT AND ROADMAP
R. Porta
Communications and Information Systems
Keywords: Friendly Force Tracking, Blue Force Tracking, Architecture, Roadmap
Abstract
This Note describes a proposed technically-focused Roadmap for Friendly Force Tracking (FFT) in
NATO. It deals with FFT intended as federation of NATO and National capabilities (NATO FFT) and
has the main focus on the interoperability aspects.
The aim is to define a Roadmap for the evolution of NATO FFT that is agreed by NATO and the
Nations and is used for capability planning and implementation.
The scope of this version deals with the technology and does not include the other DOTMPLF aspects.
The two objectives of the analysis reported here are:
• To analyze the various perspectives (operational, technical, programmatic) of the NATO FFT
into the Architecture Concept, described according to the NATO Architecture Framework.
• To formulate a vision and Long Term Roadmap for a ten-years (2009-2018) evolution of the
NATO FFT, based on the Architecture Concept.
Not a complete Reference Architecture, the NATO FFT Architecture Concept is the basis for the
Roadmap described here and expected to be used as baseline for a the development of the NATO
Roadmap by the NATO C3 Board FFT Ad-Hoc Working Group.
Additionally, future work addressing the specification of a detailed Mid-Term Roadmap and
Implementation Strategy could be based on what described in this document.
The work described in this report was carried out under Project NCB001572 of the NC3A Programme
of Work for 2007 and under Project NCB002080 of the NC3A Programme of Work for 2008 and was
concluded in February 2009.
This document is a working paper that may not be cited as representing formally approved NC3A
opinions, conclusions or recommendations.
Approved:
Luigi Bella, Director

Communications and Information Systems
NATO Consultation, Command and Control Agency This document consists

The Hague of xxiv + 108 pages
DRAFT 1.1.0 February 2009 (excluding covers)
This page is left blank intentionally
NATO UNCLASSIFIED
i
0. EXECUTIVE SUMMARY
0.1 INTRODUCTION
This document deals with a ground Friendly Force Tracking capability in NATO as a
federation of NATO and National capabilities (NATO FFT, NFFT), primarily with a technical focus.
The aim of the analysis reported here is to define an Architecture Concept and Roadmap
for the NATO FFT that is agreed by NATO and the Nations and is used for capability planning and
implementation.
• The first objective is to analyze, organize and structure the various perspectives
(operational, technical, programmatic) of the NATO FFT (the Architecture Concept),
describing them according to the NATO Architecture Framework (NAF) views.
• The second objective is to formulate and describe a vision and long-term Roadmap
for a ten-year (2009-2018) evolution of the NATO FFT, described using the
Architecture Concept.
The scope of the analysis reported here is focused on the technology. The other aspects
related the Doctrine, Organization, Training, Material, Leadership and Education, Personnel and
Facilities (so-called DOTMLPF) are not yet taken into account.
Not a complete Reference Architecture, the NATO FFT Architecture Concept is the basis
for the Roadmap described here and expected to be used as baseline for a the development of the
NATO Roadmap by the NATO C3 Board FFT Ad-Hoc Working Group.
Additionally, future work addressing the specification of a detailed Mid-Term Roadmap
and Implementation Strategy could be based on what described in this document.
0.2 RELEVANT STANDARDS AND TECHNOLOGY

The most relevant standards, technologies and capabilities that are required to specify and
implement NFFT are identified and described here. This sets the context for the NFFT Architecture
and Roadmap that is defined in the subsequent chapters.
One major component of this is the assumption of the availability of these standards and
technology, which is called here the External Roadmap. This roadmap is summarized in the following
table.
NATO UNCLASSIFIED DRAFT TN-1322

NATO UNCLASSIFIED
ii
AREA RESP n. CAPABILITIES, STANDARDS & TECHNOLOGY AVAILABILITY

Communication & Network NC3B/SC-6
Services & Standards 1.1 Standard (IP) Communication in static/deployable nodes Current (2008)
1.2 Standard (Ground) Radio Communication Initial: Mid-Term (2014)
Common waveforms / SDR Final: Long-Term (2018) (1)
1.3 Standard (IP) Wireless Ground Tactical Networking Initial: Mid-Term (2014)
(Ground-to Ground, Ground-to-Air) Final: Long-Term (2018) (1)
1.4 Standard (IP) SATCOM [Ground on the Move] Networking Initial: Mid-Term (2014)
1.5 Protected Core (fixed/deployable) Mid-Term (2014)
1.6 Protected Core (field/mobile) Long-Term (2018) (1)
Information Assurance NC3B/SC-4
Services & Standards 2.1 Encryption standards & capabilities (e.g. NINE)
Domain-based Initial: Mid-Term (2014)
Object-based after Long-Term (2018+) (1)
Information Integration NC3B/SC-5

Services & Standards 3.1 Security Boundary Protection Services
Mission/National Secret - Mission/National Restricted Gateways Mid-Term (2014)
Cross-Domain Gateways (full scope) Long-Term (2018)

3.2 XML Standards and profiles Initial: Near-Term (2010)
Final: Mid-Term (2014)
3.3 Core Enterprise Services (messaging, mediation, directory ...) Initial: Near-Term (2010)
(final inc. RT data dissemination) Final: Long-Term (2018) (1)

3.4 MTF-XML Services Mid-Term (2014) (1)
3.5 Tactical Core Services (RT) Initial: Mid-Term (2014) (2)
Final: Long-Term (2018) (2)
3.6 Integrated TDL Data Enterprise Services after Long-Term (2018+) (1)
Community Of Interest (COI) ==
Services & Standards 4.1 C2 Data Federation Services (JC3IEDM, MIP-DEM) Near-Term (2010) - MIP-B3 (2)
Mid-Term (2018) - MIP-B4
4.2 C2 Cross-COI services Initial: Mid-Term (2014) (3)
4.3 Specific COI Services <TO BE DEFINED> Initial: Mid-Term (2014) (1)
Combat Ídentification NC3B/SC-7
Services & Standards CID Technologies and Standards
5.1 Air-to-Surface - RBCI, NCTI Long-Term (2018, 2018+) (1)
5.2 Ground-to-Ground - JCID Near Term (2010)
5.2 Ground-to-Ground - BTID Mid-Term (2014)
5.3 Ground-to-Ground - DSID, NCTI Long-Term (2018) (1)
NOTES (1) Not yet planned; (2) MIP (3) Not formally established
0.3 ARCHITECTURE CONCEPT

The Architecture Concept provides an architectural, time independent, description of the
main components of the NATO FFT and their relationship, according to the NATO Architecture
Framework (NAF) vers.3. It differs from a Reference Architecture in the fact it that does not include
all the views and details required for the latter. The vision and long-term NFFT Roadmap is based on
the Architecture Concept.
For the representation of the Architecture, the main standard NAF views and sub-views
relevant for the purpose are used.
0.3.1 Operational View

The main source for the definition of Operational Views for the NFFT is the work already
performed and published. No specific and detailed operational requirement analysis has been done
specifically for this document.
An example of the force structure is depicted in the following sub-view (NOV-1A).
DRAFT TN-1322 NATO UNCLASSIFIED

NATO UNCLASSIFIED
iii
The high level Operational Requirement for NATO FFT is summarized in the following
view (NOV-1C), derived from [BiSC FFT-CONC, 2008].
NOV-1C REQUIREMENTS
Ref.num Category / Name
Operational Requirements
OPR 1 Operate in near-real time
OPR 2 Identify friendly forces
OPR 3 Monitor the precise location and operational status of friendly forces
OPR 4 Seamlessly provide this information vertically and horizontally throughout the Joint and Combined
battlespace
OPR 5 Operate in conjunction with other sensors to create an accurate, timely Recognized Ground Picture
(RGP)
OPR 6 Enable a sufficient degree of interoperability between NATO and Nationally provided FFT
capabilities
Limitations and Constraints

LIM 1 Security. Dissemination of FFT data is constrained by security policies that are deined by the
NATO Commanders and established and enforced by the data transmittion / data provision entity.
LIM 2 Reporting Latency. Delays in the reporting latency (reporting frequency and communication delays)
produces inconsistencies in the FFT-derived RGB that limis its use for fratricide prevention.
LIM 3 Coverage. FFT will not ikely ever cover the totality of vehicles and dismounted soldiers in the
battlefield. As a consequence "shoot/no-shoot" decisions cannot be solely based on FFT-deriived
information.
LIM 4 Degraded electronic environment. The communication channels used for FFT dissemination could
be negatively impacted by unforeseen physical and electronic environment conditions. As a
consequence, back-up C2 reporting methods and procedures need also be avaiable.
The operational requirements for NATO FFT can be analyzed and detailed through a
scenario represented through the following vignettes:
1) Potential hostile force interference
2) Crowd control

NATO UNCLASSIFIED
iv
3) Maritime force protection

4) Base protection
5) Neutralization of a strategic target
6) Preventing the hi-jack of and aid for a convoy
7) Preventing a bomb attack on NATO Forces
8) Neutralization of a gang leader stronghold
9) Close urban warfare
These vignettes – which have been specified and used for the Wireless Communication
Operational Architecture – WCOA - [NC3A TN-1246] – can be used as baseline for a detailed
operational analysis also for NATO FFT. This analysis has not yet been done.
The model of the FFT data is represented by the logical Information Model (NOV-7),
which is derived from the analysis done for the NFFI specification [NC3B NFFI-DDOC, 2006].
A more detailed definition of the operational requirements can be achieved through

additional analysis with the NFFT stakeholders, using the scenario represented in NOV-1B. This is
outside the analysis done sofar.
0.3.2 Capability View

Friendly Force Tracking (FFT) is defined as
the capability to monitor the precise location of friendly forces in near-real time, and to
exercise Command and Control (C2) on these forces, as necessary.

NATO UNCLASSIFIED
v
FFT provides the Friendly Forces Situation (FF-SIT), which is a component of the
Recognized Ground Picture (RGP). The RGB is a contributor to the Land Situation Awareness (LSA)
which is a component of the Joint Situation Awareness (JSA). These relationships are described in the
Capability Taxonomy sub-view (NCV-2B).
The NFFT Capability consists of sub-capabilities and is related to other capabilities such
Joint Situation Awarenes (JSA), Joint Common Operational Picture (JCOP), Combat Identification
(CID) and Intelligence, Reconnaissance and Surveillance Tracking (ISRT). The composition of NFFT
and the relationships with JSA, JCOP, CID and ISRT is described in the view NCV-4 (Capabilities
Dependencies sub-view) and depicted below.
0.3.3 Service-Oriented View

The NATO Service-Oriented view (NSOV) identifies the main services and their
relationships in relationships with supported capabilities and operational requirements.

NATO UNCLASSIFIED
vi
Services can be defined from a user perspective (“User Services”) or from

technical/implementation perspective (“NNEC Services”). The NSOV included in this version is
mainly an NNEC Service view.
The main sub-view - the Service Taxonomy (NSOV-1), presented below - identifies the
main services and their relationships1.
An initial description of each of these services is provided in NSOV-2A. A detailed

definition is outside the scope of the document.
0.3.4 System View

The NATO System View (NSV) describes the relevant systems, services and networks
that are needed to support the requirements described in the NOV, to implement the capabilities
described in the NCV using the services described in NSOV.
This view does not represent any specific deployment configuration, therefore the number
of nodes, systems and networks and the specific commands / HQ are to be considered only as
examples.
1
In this version we don’t use a standard service taxonomy which is not yet available at the time of writing.

NATO UNCLASSIFIED
vii
The following sub-views describe the System Interfaces: the first with an
operational/physical oriented representation (NSV-1A); the second with a more technical/logical
oriented description.

NATO UNCLASSIFIED
viii
BMS Battle Management System

C2IS C2 Information System
C2IS C2IS C2IS CS Communication Service
DDS Data Dissemination Service
DJTF Deployed Joint Task Force
FTS Force Tracking Service
LTIS Nat HQ IG Interoperability Gateway
L-Nat HQ NATO JFC HQ LTIS
C2-
JC2IS Joint C2IS
DDS
JFC Joint Forces Command
LA-DDS Land-Air DDS
C2- LS-DDS Land—Sensor DDS
DDS LTIS Land Tactical Interop. Service
Nat-L Lead NRF Nation
Air C2IS Nat Non-Lead NRF Nation
NRF NATO Reaction Force
C2IS LTIS OCC Operational Control Centre
TACP Tactical Air Control Post
CAOC / ARS
LA- TCP Tactical Command Post
DDS TT Force Tracking Terminal
DJTF HQ (MMC)
LS-
ABMC LTIS DDS
C2IS
Air C2IS
ABCC
LA-
DDS
Air C2IS FTS FTS

SI SI
LTIS LTIS
LA- TACP LS-
DDS DDS
BMS FTS FTS BMS
L-Nat HQ (OCC) Nat HQ (OCC)
BMS
LTIS FTS FTS FTS FTS
TI TI
FTS
TCP TT TT
TT TT
NSV-1B
The main elements shown in the previous diagram are the following:
FTS TI FTS Terminal Interoperability Service represents the interoperability service
at the Friendly Force Tracking Terminal (TT) level. It provides in a standard
format the shared data originated from that terminal.
FTS SI Force Tracking System (FTS) System Interoperability Service represents the
interoperability service at the Friendly Force Tracking System (FTS) level. It
provides in a standard format the shared data originated from the terminals
of that FTS.
LTIS Land Track/Tactical Interoperability Service is the service supporting the
provision of FFT data for a whole theatre/mission. It provides in a standard
format the shared data originated from all the FFT terminals of all the FTS
involved in a mission/theatre as well as theatre-level data management,
control and mediation services (to be eventually subsumed by Core
Enterprise Services)
LS-DDS Land Tactical Structure Data (LTSD) - Data Dissemination Service is a
generic service supporting the near-real time sharing and dissemination of
tactical structured data similar to FFT (LTSD). This Service, initially
complementary to LTIS, in the longer-term would support also of FFT data,
generalizing and replacing part of the LTIS functionality.
LA-DDS Land-Air Data Dissemination Service, is the service supporting the
dissemination of FFT (and eventually LTSD in general) to air platforms.

NATO UNCLASSIFIED
ix
C2-DDS C2 Data Dissemination Service supports the dissemination (and related

value-added services) of FFT data between FTS and C2 Applications,
Services or Systems C2IS).
The System Communication Description sub-view (NSV-2) describes the main types of
networks required for the communication among the system nodes.
The following interfaces are analyzed: NFFT and Air-C2IS/ Air Platforms, NFFT and
CID, NFFT and MHPS/MTF, and NFFT and C2IS/MIP-enabled Systems.
0.3.5 Technical View

The NATO Technical View (NTV) identifies applicable and available standards and/or
profiles to be used for the implementation of NFFT. It is also used to identify areas where no standard
exists which might then suggest the need for new standardization work.
The following view (NTV-1, Technical Standards Profile) identifies the interfaces
(Service Interoperability Profiles, SIP) and the standards that are applicable for the services identified
in Service-oriented View and applied at the Service Interoperability Points (SIOP’s) defined in the
System View.
NTV-1 TECHNICAL STANDARDS
SERVICE INTERFACE APPLICABLE PROFILE /
STANDARD
Svc# Abbr. Name I/F# Description Std# Description SIP Status
1 FTS-DT FFT Data Transport Svc 1 Data Transport - reliable two-way 1-A NFFI - IP1 (IETF TCP/IP) NFFI v1 (subset) Ratified (interim)
2 Data Transport - unreliable, one-way 1-B NFFI - IP2 (IETF UDP) NFFI v1 (subset) Ratified (interim)
3 Data Exchange Format (DEF) 1-C NFFI - DEF NFFI v1 (subset) Ratified (interim)
2 FTS-DL FFT Data Labelling Svc 4 2-A (RTO XML Labelling draft) Under R&D
5 XML security labels - output format 2-B (RTO XML Labelling draft) Under R&D
6 XML security labels - input format 1-C NFFI DEF NFFI v1 (labels) Ratified (interim)
3 FTS-SI FFT System Interoperability Svc 7 Web-service sharing and dissem. 3 XML service for smart pull (NFFI v2) Under R&D
8 FFT data 1-C NFFI DEF NFFI v1 (subset) Ratified (interim)
4 FTS-TI FFT Terminal Interoperability Svc 9 FFT Tactical Level dissemination 4 NFFI - Tac-Level svc I/F (NFFI v3 svc + data) Not yet addressed
5 LTIS Land Tactical Interoperability Svc 10 Sharing and dissemination FFT data 5 LTIS svc I/F (initial) (LTIS v1 svc + data.) Under R&D
11 Sharing and dissemination FFT data 6 LTIS svc I/F (distributed) (LTIS v2 svc + data.) Not yet addressed
12 Sharing and dissemination FFT data 7 LTIS svc I/F (NNEC) (LTIS v3 svc + data.) Not yet addressed
6 LS-DDS Land Tactical Structured Data 13 Sharing and dissemination (Land Stuct. Data) 8 LS-DDS svc I/F (initial) (LS-DDS v1 svc+data.) Not yet addressed
Dissem.Svc
14 Sharing and dissemination (Land Stuct. Data) 9 LS-DDS svc I/F (NNECl) (LS-DDS v2 svc+data.) Not yet addressed
7 LA-DDS Land-Air Data Dissemination Svc 15 Dissemination / forwarding to Air platforms 10 LA-DDS svc I/F (initial) (LA-DDS v1 svc+data.) Under R&D
16 Dissemination / forwarding to Air platforms 11 LA-DDS svc I/F (NNECl) (LA-DDS v2 svc+data.) Not yet addressed
8 C2-DDS C2IS Dissemination Svc 17 FFT to C2IS Disseminiation Service 12 C2-DDS svc I/F (initial) (C2-DDS v1 svc+data.) Under R&D
18 FFT to C2IS Disseminiation Service 13 C2-DDS svc I/F (NNEC) (C2-DDS v2 svc+data.) Not yet addressed
Highlighted are the new required SIP’s. The specific names given to them (e.g. NFFI v1,
LTIS v1) are purely indicative. The rationale for different versions of the interfaces can be best
understood after looking and the Roadmap section.
0.4 VISION (LONG-TERM ROADMAP)

The vision (or Long-Term Roadmap) describes the envisaged implementation of NFFT
for the next 10 years (2010-2018). It is split into three phases: Near (2010), Mid (2014) and Long
Term (2018). Each includes a definition of the phase objective Architecture and of the activities and
milestones required to implement it.

NATO UNCLASSIFIED
x
Each of these stages implements one Capability Level (CL) of the NFFT Functionality, as
depicted in the following figure (NCV-3).
2009 2010 2011 2012 2013 2014 2015 2016 2017 2018
NFFT CAPABILITY ID 2
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Capability Level 1 (CL-1) 1
Specification and standardization 2
Spec. Milestones: M1, M2, M3 3
Implementation 4
Implem. Milestones: M4, M5, M6 5
Research & Development 7
Implementation 10
Implem. Milestones: M10,M11 M12 11
Spec. Milestones: M13, M14 15
Implementation 16
Implem. Milestones: M15, M16 17
0.4.1 Near-Term (2010)

The objective is:
i. to enhance the current interoperability solution by improving the adaptability and
flexibility and by introducing XML-Services
The expected operational benefits are the following:
a) Improved Situation Awareness in C2IS applications (vertical interoperability)
through the initial introduction of a smart-pull service functionality
b) Re-deplorability of the whole NFFT solution to any new Operational Theatre
(alternative or simultaneous) with any Force structure (NATO or National led)
c) Enhanced FFT and interoperability capabilities (performance, expandability,
robustness, efficiency and sustainability)
The NFFT Capability Level 1 (CL-1) can be called Advanced FFT Interoperability (fixed
FFT-SOA) and be characterized as follows:
1) Enhancement of the interoperability solution in ISAF
2) Horizontal interoperability involves most FTS in the LOW domain. FTS in the
HIGH domain can be also present and federated with some restrictions. Track
information of white/grey assets (e.g. by NGO) operating at the UNCLASSIFIED
(or equivalent level) can be injected in the NFFT federation.

NATO UNCLASSIFIED
xi
3) The Tactical level communication is not standardized and FTS are therefore not
directly interoperable at that level.
4) Access to FFT mission data by other consumers (mainly C2 applications) is
significantly improved through a standard FFT XML-Service functionally (initial
fixed FFT-SOA). Vertical interoperability is therefore enhanced.
5) Re-deployability of a solution similar to the ISAF FFT NNI to other possible
Theatre of Operations and with other Force Structures is made easier through the
LTIS (v 1) functionality.
The following figure (RM-NT) provides a representation of the architecture (system
view).
The new Service Interoperability Profiles (SIP) needed for this capability level are:
• NFFI v2 (XML smart pull services)
• LTIS v1 (initial functionality with limited functionality)
The main Assumptions are described and the major Activities and Milestones are
identified and outlined.
0.4.2 Mid-Term (2014)
The objectives are:

NATO UNCLASSIFIED
xii
i. To extend the RM-NT solution beyond FFT, to include other location--focused

data/service types in the Land Tactical Interoperability (LTI) domain (such as:
warnings, incidents, enemy contact reports, Combat Identification).
ii. To integrate LTI services into a standard fixed/deployavable2 SOA to provide
wide access of such data/services to any net-enabled client as well as being able
to consume other selected net-enabled services within the Land Tactical domain.
iii. To improve interoperability among FTS in the Secret and Restricted security
domains through the enhanced information sharing enabled by new certified BPS
(IEG Case C)
a) Enhanced Situation Awareness in the Battlefield:
o more types of tactical data is shared in near-real-time besides FFT (Land
Tactical Interoperability), e.g. enemy contacts, incidents, warnings)
o better Quality Of Service (through systems and network improvements).
o Sharing extended to NATO/National Tactical Systems operating at both
HIGH and LOW security domains.
b) Enhanced Situation Awareness and C2 at the fixed/deployed Command Post/HQ:
o C2 Applications/Services/Users have smart access to all LTI data
o C2 Applications/Services/Users dealing with the Land Situation are
better integrated with the others.
c) Initial Combat Identification (CID) / FFT operational employment and fratricide
risk reduction
o Standard BTID devices are started being deployed
o Enhanced dissemination achieved through FFT/LTI infrastructure.
d) Enhanced Situation Awareness in the cock-pit.
Improved Quality Of Service (e.g. latency) of FFT/LTI data and of its
dissemination to Air Platforms improves pilots awareness of land situation.
The NFFT Capability Level 2 (CL-2) can be called Land Tactical Interoperability (fixed
LTI-SOA) and be characterized as follows:
1) Horizontal interoperability is extended beyond FFT to include also other LTI
data. The sharing architecture is an enhancement of the one for FFT3. A good
part of the Shared Tactical Ground Picture is achieved.
2) Horizontal interoperability is enhanced to involve FTS and Tracking systems in
the HIGH, LOW and UNCLASSIFIED domain. New BDS technology (IEG
Case C) and augmentation/sanitization services allow the bi-directional
information sharing among these domains (limited only by Security Policies)
3) The Tactical level communication is still largely not standardized and FTS are
therefore not directly interoperable at that level.
2
i.e. based on a fixed or deployable communication infrastructure
3
assuming that parallel and harmonized have similarly progressed for other land sensor data

NATO UNCLASSIFIED
xiii
4) An initial fixed/deployable4 LTI-SOA (including FFT) is implemented,

integrating LTI services with available core infrastructure services. Most of the
C2 services are therefore able to consume and to provide added value to LTI
services.
MIP-enabled C2 Services can also support LTI and can share appropriate LTI –
derived data in a MIP Federation.
5) Initial deployment of CID-standard devices (BTID) and CID dissemination
making use of available LTI./FFT infrastructure and services
The following figure (RM-MT) provides a representation of the architecture (system
view).
The new SIP’s and interfaces needed for this capability level are:
• LTIS v2 (distributed and enhanced functionality)
• FFT-MD (FFT Metadata for service discovery)
• LS-DDS v1 (initial functionality)
• C2-DDS v1
• LA-DDS v1
4
i.e. with services that are connected through the fixed/deployable communication infrastructure.

NATO UNCLASSIFIED
xiv
0.4.3 Long-Term (2018)
The objectives are:
i. To achieve FFT/LTI interoperability also directly at the tactical level
implementing a mobile5 LTI SOA capability, based on (and constrained by)
available interoperable tactical communications.
ii. To achieve land-oriented6 cross-COI interoperability from the tactical to the
strategic level, i.e. the full implementation of the Shared Tactical Ground Picture
concept in a NATO Network Enabled Capability (NNEC) context.
iii. To improve interoperability also with high-value tactical platforms through
enhanced quality of service for FFT/LTI and improved TDL-edge services.
The operational benefits are the following:
a) Enhanced real-time situation awareness in the battlefield comprising the whole
(friendly, enemy or neutral) land situation as well as joint and strategic
information.
b) Improved Land Situation Awareness of the Commander (and of C2 Services)
with tailored and real-time access of all shared land tactical data (if required).
c) Enhanced and real-time Situation Awareness in all weapon-delivery platforms,
significantly reducing the risk of fratricides and collateral damages.
The NFFT Capability Level 3 (CL-3) can be called Land-oriented NNEC (fixed and
mobile LTI-SOA) and be characterized as follows:
1) Achievement of mature, comprehensive and high quality (e.g. real-time) land
situation awareness, integrated with C2 services to enable self-synchronization.
Operational and technical requirements from NOV-1C are supported also for
LTI.
2) Full network-enabled and distributed implementation of the extended-NFFT
capability covering also all aspects of LTI (LTI fixed/mobile SOA).
3) Direct tactical level interoperability - regarding FFT/LTI - as a tactical COI’s,
interoperable with the other mobile/fixed COI’s and infrastructure services. In
particular, efficient and harmonized use of both FFT and CID.
4) The implementation of full NNEC capabilities is limited by:
• residual limitations in tactical communication interoperability
• non-converged and distinct TDL domain
• domain-based security (with small and flexible domains) but not yet object-
level (e.g. individual) security protection
5
i.e. based on a tactical mobile communications. Fixed LTI SOA assumed to have been already implemented at
that time
6
Beyond the Land domain is outside the scope of this document

NATO UNCLASSIFIED
xv
The following figure (RM-LT) provides a representation of the architecture (system

view).
BDE Brigade
BPS Boundary Protection Service
BTN Battalion
CP Command Post
JFC HQ FTS Force Tracking System
HQ Headquarters
NAT HQ IEG Information Exchange Gateway
LCC Land Component Command
LTIS Land Tactical Interoperability Svc
LA-DDS C2IS LTIS C2-DDS MCN Mission Control Node
C2-DDS NN NATO-National
C2-DDS OPC Operational Command
ACC/CAOC/ARS C2IS
RGP Recognize Ground Picture
SCN System Control Node
SI System Interoperability (Service)
LTIS C2-DDS
NGCS NGCS LS-DSS BTN-3 CP
(NN federation) (NN federation) TCP
FACP
LA-DDS
NGCS NGCS
(NN federation) (NN federation)
C2IS FTS-TI
LTIS
OPC HQ FTS-TI
FTS-TI
LS-DSS
MCN
C2-DDS
COY CP
FTS-TI TCP
COY CP
. LTIS
TCP FTS-TI
LTIS
.
LTIS FTS-TI COY CP
. FTS-TI LTIS
TCP
LTIS
FTS-TI
FTS-TI
FTS-TI FTS-TI FTS-TI
FTS-TI
FTS-TI FTS-TI
FTS-TI
RM-LT
The new SIP’s needed for this capability level are:

• NFFI v3 (tactical level interface)
• LTIS v3 (NNEC version, possibly only through Core Services)
• LS-DDS v2 (NNEC version, possibly only through Core Services)
• C2-DDS v2 (NNEC version, possibly only through Core Services)
• LA-DDS v2 (NNEC version, possibly only through Core Services)
0.5 MID-TERM ROADMAP
The Mid-Term Roadmap describes a strategic plan for the implementation of NFFT in the
next 5 years (2010-2014), i.e. for the near-term and mid-term phases introduced in the previous
section. This section is not included in this version of the document.
0.6 CONCLUSIONS AND RECOMMENDATIONS

This document describes an Architecture Concept and Roadmap of the NATO Friendly
Force Tracking capability.

NATO UNCLASSIFIED
xvi
• The A&R analysis is a good basis to specify, harmonize standards and plan the
implementation of capabilities that need to interoperate regarding FFT (Near Term) and
Land Tactical Services (Mid to Long Term).
• Available work on NATO FFT specification and on e.g. applicable architectures, related
NATO/National capabilities and roadmaps has been considered to the max extent
possible. But important sources or new document versions might have been overlooked
and might need to be considered.
• The chosen COI-driven approach allows continuing the ISAF FFT NNI focus towards
NNEC, integrating with other (Core or COI) capabilities as are being specified, planned
and implemented.
• The limitations and constraints of this version of the A&R need to be recognized. It is to
be maintained as a living document.
The main recommendations are the following:
1. Review of this document within the NC3B SC5/SC7 FFT AHWG
2. Revision by NC3A according to this review
3. Approval by the FFT AHWG and submission to the NC3B for endorsement
4. Consideration of specific issues (e.g. experimentation for risk reduction, initiation
of harmonization and standardization) within the NC3A (and National) Programs
Of Work for R&D and Experimentation.
5. Definition by the FFT AHWG of the scope of a detailed NFFT Mid-Term
Roadmap, to be drafted by the NC3A as baseline for further staffing.

NATO UNCLASSIFIED
xvii

NATO UNCLASSIFIED
xviii

NATO UNCLASSIFIED
xix
TABLE OF CONTENTS
Page
0. EXECUTIVE SUMMARY I
0.1 INTRODUCTION I
0.2 RELEVANT STANDARDS AND TECHNOLOGY I
0.3 ARCHITECTURE CONCEPT II
0.4 VISION (LONG-TERM ROADMAP) IX
0.5 MID-TERM ROADMAP XV
0.6 CONCLUSIONS AND RECOMMENDATIONS XV
1. INTRODUCTION 1
1.1 STATUS 1
1.2 BACKGROUND 1
1.3 SCOPE, AIM AND OBJECTIVES 2
1.4 APPROACH 3
1.5 RELATED WORK 4
1.6 DOCUMENT OVERVIEW 5
2. RELEVANT STANDARDS AND TECHNOLOGY 7
2.1 TARGET CAPABILITY 8
2.2 RELEVANT ARCHITECTURES AND STANDARDS 8
2.3 NATIONAL ROADMAPS 18
2.4 EXTERNAL ROADMAP 19
3. ARCHITECTURE CONCEPT 22
3.1 OPERATIONAL VIEW 23
3.2 CAPABILITY VIEW 34
3.3 SERVICE-ORIENTED VIEW 41
3.4 SYSTEM VIEW 47
3.5 TECHNICAL VIEW 61
3.6 QUALITY FACTORS 63
4. VISION (LONG-TERM ROADMAP) 65
4.1 SCOPE 65
4.2 LIMITATIONS, RISKS AND ASSUMPTIONS 66
4.3 CURRENT SITUATION 66
4.4 FINAL SITUATION 71
4.5 LONG-TERM ROADMAP 73
4.6 SYNTHESIS 93
5. MID-TERM ROADMAP 97
5.1 GENERAL CONSIDERATIONS 97
5.2 MID-TERM ROADMAP 98
6. CONCLUSIONS AND RECOMMENDATIONS 99
6.1 CONCLUSION 99
6.2 RECOMMENDATIONS 100
REFERENCES 103
ABBREVIATIONS 105

NATO UNCLASSIFIED
xx
T This page is left blank intentionally

NATO UNCLASSIFIED
xxi
LIST OF FIGURES
Page
Figure 1 NATO Architecture Coherence Roadmap (NAC-RM) 13
Figure 2 High level force structure (NOV-1A) 24
Figure 3 Scenario - Vignettes (NOV-1B) 25
Figure 4 Air-Land Operational Information Exchange Requirements (NOV-1D) 27
Figure 5 Operational Security Requirement (NOV-1E) 28
Figure 6 Operational Information Requirements (NOV-2A) 29
Figure 7 Information Model (NOV-7) 32
Figure 8 Capability and C3 Interoperability Requirements (NCV-2A) 36
Figure 9 Capability Taxonomy (NCV-2B) 37
Figure 10 Capability Dependencies (NCV-4) 38
Figure 11 Service Taxonomy (NSOV-1) 43
Figure 12 System Interface Description – Operational (NSV-1A) 48
Figure 13 System Interface Description - Technical (NSV-1B) 49
Figure 14 Systems Communication Description (NSV-2) 55
Figure 15 Systems Functionality Description (NSV-4) 58
Figure 16 Current Situation (RM-NOW) 68
Figure 17 Final Capability (RM-END) 72
Figure 18 Roadmap – Near-Term Architecture (RM-NT) 76
Figure 19 Roadmap –Mid-Term Architecture (RM-MT) 83
Figure 20 Roadmap –Long-Term Architecture (RM-LT) 89
Figure 21 Roadmap – Capability Phasing (NCV-3) 94

NATO UNCLASSIFIED
xxii

NATO UNCLASSIFIED
xxiii
LIST OF TABLES
Page
Table 1 List of Referenced Documents (DOCS) 8
Table 2 NATO Systems Maturity Levels (NSML) 10
Table 3 External Roadmap (EXT-RM1) 20
Table 4 - External Roadmap (EXT-RM2) 21
Table 5 High Level Operational Requirements (NOV-1C) 26
Table 6 OIR - Information Description (NOV-3A) 31
Table 7 NFFT Vision (NCV-1) 35
Table 8 Service Definition (NSOV-2A) 45
Table 9 Service Interoperability Points (NSOV-2B) 46
Table 10 Technical Standards Profile (NTV-1) 62
Table 11 Roadmap - Capabilities (RM-CAP) 95
Table 12 Roadmap - Standards (RM-STD) 96

NATO UNCLASSIFIED
xxiv

NATO UNCLASSIFIED
1
1. INTRODUCTION
This document deals with a ground Friendly Force Tracking capability in NATO as a
federation of NATO and National capabilities (NATO FFT, NFFT), primarily with a technical focus.
The aim of the analysis reported here is to define an Architecture Concept and Roadmap
for the NATO FFT that is agreed by NATO and the Nations and is used for capability planning and
implementation.
This aim is achieved through two main objectives:
• The first objective is to analyze, organize and structure the various perspectives
(operational, technical, programmatic) of the NATO FFT (the Architecture
Concept), describing them according to the NATO Architecture Framework
(NAF) views.
• The second objective is to formulate and describe a vision and long-term
Roadmap for a ten-year (2009-2018) evolution of the NATO FFT, described
using the Architecture Concept.
Not a complete Reference Architecture, the NATO FFT Architecture Concept is the basis
for the Roadmap described here and expected to be used as baseline for a the development of the
NATO Roadmap by the NATO C3 Board FFT Ad-Hoc Working Group (NC3B FFT-AHWG).
Additionally, future work addressing the specification of a detailed Mid-Term Roadmap
and Implementation Strategy could be based on what described in this document.
1.1 STATUS
An extensive review and revision has been done at the NC3A. Among all the
contributions, I would like to thank the following colleagues for their essential contribution:
Frits Broekema, Rob van Engelshoven, Geir Hallingstad, Oyvind Hvinden and Michael
Street
The Near to Mid-Term Implementation (Chapter 5) is presented only as outline and has
not been analyzed in detail. This is the anticipated scope of additional work planed for 2009.
External review, revision, approval and endorsement of this document are being sought.
1.2 BACKGROUND
Friendly Force Tracking (FFT) – despite the several synonyms used7 in different Nations
or Services - is a rather well-defined capability both from an operational and a system perspective. It
can be defined as:
The capability to monitor the precise location of friendly forces in near-real time and to
exercise8 Command and Control on those forces, as necessary [BiSC FFT-CONC, 2008]
7
In particular, Blue Force Tracking (BFT) is commonly used synonym.
8
author would replace “and to exercise” with “in order to enable

NATO UNCLASSIFIED
2
and the End Users (warfighters and command staff) can have a clear visibility of its effects or have a
better Situation Awareness (SA), that can be detailed for FFT as
Seeing accurate and timely information on relevant friendly units that take part in an
operation
Situation Awareness (SA) also support reducing the risk of fratricides, for which a key
enabler is the capability of identifying targets (Target Identification, TI) and identifying friendly units
(which should therefore not be considered as targets). TI and SA are the scope of Combat
Identification (CID). FFT and CID are therefore closely related from an operational perspective but
are quite different from a system and technical perspective.
In its widest definition, FFT encompasses tracks of Air, Ground or Maritime Friendly
Forces. However, in the analysis done and throughout this document we refer only to Ground Forces
and Land Tracks.
FFT capabilities (systems, subsystems or services) are not usually NATO-funded (i.e.
funded though NATO common funds, e.g. the NATO Strategic Investment Program - NSIP). They are
normally capabilities which are procured and provided by the Nations, and are therefore part of the
National Forces. Two significant exceptions of NATO procured Force Tracking System (FTS) are the
FTS for Kosovo (KFTS) and the one for the Afghanistan ISAF Mission (IFTS).
The main responsibility for the technically oriented NATO-wide standardization of FFT
capabilities is the NATO C3 Board (NC3B) and in particular in the Information Services and
Identification Sub-Committee (SC5 and SC7). The first standardization achievement has been NATO
Friendly Force Information (NFFI) interim NATO Standard [NC3B NFFI D-DOC, 2006].
The recently established FFT Ad-Hoc Working Group (FFT AHWG) - jointly managed
and supported by SC5 and SC7 - is the main body responsible for the advice in the technically-
oriented standardization and planning regarding FFT.
The Architecture and Roadmap for FFT is one of the main products that the AHWG is
expected to deliver. Hence the relevance and value of the analysis reported in this document that
NC3A has performed in support of the FFT AHWG.
1.3 SCOPE, AIM AND OBJECTIVES

This document is about NATO FFT (NFFT), intended as interoperable FFT capabilities
in a NATO/multinational9 context. It is therefore a “federation” of national/NATO capabilities and
not only a NATO acquired FFT capability.
The aim of this analysis is to define a Roadmap for the evolution of NATO FFT that is
agreed by NATO and the Nations and is used for capability planning and implementation.
To achieve the aim, two main objectives are defined:
1. The definition of an Architecture Concept for the NATO FFT. The NATO
Architecture Framework (NAF) is to be used a reference.
9
Possibly including also non-NATO countries and other organizations (e.g. UN) involved in a NATO-led
operation.

NATO UNCLASSIFIED
3
2. The definition of a Vision and Strategic Roadmap (NFFT-RM) for the realization
of such capability in the next 10 years, distinguished in target capabilities for
Near (2010), Mid (2014) and Long Term (2018).
The scope of the analysis reported here is focused on the technology. The other aspects
related the Doctrine, Organization, Training, Material, Leadership and Education, Personnel and
Facilities (so-called DOTMLPF) are not yet taken into account.
Future work should address the specification of a detailed Mid-Term Roadmap and
Implementation Strategy should be based on the final Architecture Concept and Vision.
NATO can play a very important role in promoting, enabling and validating
interoperability among the nationally and NATO owned FFT systems, to achieve the agreed
operational goal. A NATO-Nation agreed NFFT Architecture and Roadmap is an essential tool to
facilitate the planning and coordination of the NATO and National programs to eventually implement
interoperable NATO Network Enabled Capabilities.
1.4 APPROACH
The overall analysis approach consists of two phases:
1. Phase-1. Definition of the FFT Architecture Concept and of the NFFT-RM (Chapters
3 and 4), addressing Objectives 1 and 2.
2. Phase-2. Definition of the Near to Mid-Term Roadmap approach (Chapter 5),
addressing Objectives 3.
The following clarifies the approach applied:
• An Architecture is developed to serve an intent and purpose. It needs to include -
at the appropriate level of detail - all and only the aspects (or the Views from the
NAF) that are relevant to achieve the intent. We therefore only used the subset of
the NAF believed necessary for our purpose.
• The analysis was mainly based on source available documentation, e.g.
architectural documents and roadmaps defined in context different but related to
FFT. Some gaps and inconsistencies in the Architecture concept are derived from
the sources used.
• The approach followed is driven by a specific COI (FFT) perspective and then
generalized and integrated with other capabilities (COI, common or core). The
advantage of this approach is a better defined scope, more focus and better
identification of the stakeholders.
Phase-1 consists of the following activities:
a) Collection and analysis of available and documented requirements, analytical and
design concepts and architectures that most are relevant for NFFT (source
documents). This set includes e.g.: NATO and National Roadmap / Master Plans;
(NATO, non-NATO), roadmaps and vision for the evolution of commercial
technologies and standard. Note that there are significant gaps and inconsistencies in
the scope and level of details of the source material used.

NATO UNCLASSIFIED
4
b) This material was then analyzed and used for the definition of the Architecture
Concept. This activity has been performed with a “breadth-first” approach, i.e.
addressing all perspectives (operational, system, technical etc, according to the NAF)
although the analysis of each of them might not be considered as complete yet.
c) The Architecture Concept is then used to formulate a recommended way ahead (the
Vision and Long-Term Roadmap, NFFT-RM), distinguished into three major
milestones: Near. Mid and Long Term.
This document describes the Phase-1 work done by NC3A. A finalization (e.g.
completion, review, revision, agreement) of the Phase-1 deliverables has not been done yet.
Phase-2 comprises the definition of the Mid-Term Roadmap, including an analysis of
some of the implementation concepts and a refinement of a 5-years Roadmap, more detailed that what
done in Phase-1. This Phase has not been performed yet.
The main stakeholders for the FFT Architecture and Roadmap are staff officers, engineers
and managers from NATO and Nations in the following areas:
• The operational end users community
• The requirements and operational concept definition
• The capability planning and management
• The standardization and compliance verification.
• The acquisition and implementation
• The fielding, testing and support
The main forum where the FFT stakeholders – or their representatives - would review,
revise and eventually finalize the NFFT Architecture and Roadmap is the NATO C3 Board FFT Ad-
Hoc Working Group. This document is therefore primarily addressed to that Group.
1.5 RELATED WORK

The definition of the NFFT Architecture Roadmap is related to several other activities
performed in NATO and in the Nations. This section lists only the ones that are most relevant and
directly related.
1.5.1 NATO FFT Capability, Concept and Minimum Military Requirement

The urgent requirements for the NATO Missions in Kosovo and Afghanistan have been
covered by “fast-track” NATO Acquisitions (NSIP – NATO Strategic Investment Program).
Capability requirements specific to those two systems (and in particular the latter) are very relevant for
NFFT.
ACO and ACT are defining the “Bi-SC Concept for FFT and Minimum Military
Requirement of FFT for Ground Forces”. A draft of this document [Bi-SC FFT-CONC, 2008] has
been used as one of the main references for the requirement and capability definition of the NFFT.

NATO UNCLASSIFIED
5
1.5.2 NATO-National FFT Interoperability – Analysis and Experimentation

The ACT Experimental Program of Work (EPOW) for NC3A includes since 2004
analytical and experimentation work (lead by NC3A and performed by NATO and National Teams)
aiming at the interoperability between NATO and National FTS.
The experimentation cycle performed in 2004, 2005 and 2006 has led to the specification
of the experimental NATO Friendly Force Information (NFFI) interface that has been validated with
several Nations in three main experimentation venues (CWID 2005 and 2006, Force Tracking
Experiment - FTEX).
A new cycle has been started to address the enhancement of such interface (CWID 2007
and 2008).
1.5.3 NATO-National Friendly Force Tracking Information Standardization

Using the NFFI experimental specification as baseline, the NATO C3 Board has revised,
agreed and ratified the “Interim NATO Friendly Force Information (NFFI) Standard for
interoperability of Force Tracking Systems” – otherwise called the NFFI D-document (ref. [NC3B
NFFI-DDOC, 2006]). Work is now on-going toward the possible ratification of a corresponding
NATO Standardization Agreement (STANAG-5527).
In the same context, NC3A (under the NC3B Program Of Work), is performing analytical
and experimentation activities to analyze the issues and requirements related to the harmonization of
the FFT with other related standards, e.g.: ADat-P3, MIP/JC3IEDM and LINK-16.
1.5.4 FFT NATO-Nations Interoperability in ISAF

The FFT NATO-Nation Interoperability in ISAF (ISAF FFT NNI) is the currently only
implementation of FFT interoperability in Operations.
The NNI architecture is a hub –and-spoke architecture where the NATO ISAF Force
Tracking System (IFTS) acts as “hub” for the National FTS10 are deployed and NFFI-enabled. This is
the first implementation of an FFT Federation. Work on the ISAF FFT NNI continues, extending the
national participation, enhancing the capabilities and refining requirement definitions and procedures.
1.5.5 NC3B – Joint SC/5 and SC/7 FFT Ad-Hoc Working Group
The recently established Friendly Force Tracking Ad-Hoc Working Group (FFT AHWG)
has a unique advisory role in the definition of FFT policy, planning, guidance and standardization
within the NC3B structure.
The definition of a Vision, Architecture and Roadmap for FFT is one of the main
deliverables of the AHWG. The analysis described in this document is primarily intended as baseline
for this work by the FFT AHWG.
1.6 DOCUMENT OVERVIEW

This document is organized in numbered chapters, sections and subsections.
10
Four at the time of writing: DEU, FRA, NOR, USA,

NATO UNCLASSIFIED
6
• Chapter 1 — Introduction.
• Chapter 2 — Relevant Standards and Technology — identifies the main artefacts
(e.g. standards, technology roadmap, national roadmaps) that are relevant for NFFT
and summarizes their availability over time in the External Roadmap.
• Chapter 3 — Architecture Concept — presents the architectural concepts of the
NFFT. Not a complete Reference Architecture, it includes the essential operational,
functional and system reference needed for the Roadmap definition.
• Chapter 4 —Long-Term Vision — describes the Vision and outlines the Roadmap
for the Near, Mid and Long Term target objectives. This is the core chapter of this
document.
• Chapter 5 — Mid-Term Roadmap — introduces the Mid-term Roadmap and some of
the aspects that need to be addressed. This chapter is a placeholder for future work.
• Chapter 6 – Conclusions and Recommendations.

NATO UNCLASSIFIED
7
2. RELEVANT STANDARDS AND TECHNOLOGY
This Chapter identifies the main standards, technologies and capabilities that are required
to specify and implement NFFT. This sets the context for the NFFT Architecture and Roadmap that is
defined in the subsequent chapters.
One major component of this is the assumption of the availability of these standards and
technology, which is called here the External Roadmap. This roadmap is presented in the last section.
Many artefacts (e.g. architecture and planning documents, standards) in NATO and the
Nations need to be taken into account to define and implement NFFT. Coming from different Nations
and NATO Agencies, it is likely that there is not much consistency among them.
In order to limit this analysis to a manageable set and not to loose the focus on the
objectives, the following has been applied in the analysis done:
• Taking into account all the artefacts defining capability requirements, standard and
planning constraints that are directly applicable to NFFT
• Consider the most relevant11 available sources specifying the availability of standards
and capabilities that are enabler for NFFT, i.e. that are to be used by, or are
constraints for NFFT.
• Generally disregarding (at least initially) the capabilities and standards that are
enabled by NFFT. This is the case, for instance, of most C2 Services. According to a
Service Oriented Architecture (SOA), this approach corresponds to consider the
service producers for the NFFT Services but not its consumers. In subsequent versions
of the NFFT Architecture and Roadmap, it is likely that the analysis of dependencies
is refined and completed in both directions (i.e. dependency for and from NFFT).
Most planning or forecasting information included below is a quite low level of
granularity. Therefore a significant level of uncertainty - especially in the time dimension - is
unavoidable. A couple of years uncertainty for the Mid and Long term assumed dates should be
considered.
The list of the sources analyzed for the NFFT-RM are listed in Table 1 and described in
the following sections.
11
This is of course a subjective assessment

NATO UNCLASSIFIED
8
Table 1
List of Referenced Documents (DOCS)
DOCS APPLICABLE DOCUMENTS
Abbreviation Official Ref Issuer Vers. Issue Date Title
BiSC FFT-CONC AC/322(SC/7)N(2008)0011 ACO, ACT Draft October 2008 Bi-SC Concept for NATO friendly Force Tracking of Ground Forces
ACT NTDES-RM ACT Vers. 0.2 June 2007 NATO Tactical Data Enterprise Services Roadmap
ACT NNEC-DS AC/322(SC/1)N(2008)0053 (INV) ACT Vers. 1.0 Feb 2009 NNEC Data Strategy
MIP Web-Site MIP March 2007 Multilateral Interoperatbility Program - Web Site - http://www.mip-site.org
NC3A AEM NC3A August 2007 Architecture Enginering Methodolgy (NC3A/AEM) (Annex B, para B.6 of
[NAF]
NC3A IFTSCO NC3A September 2006 Interoperability of Friendly Force Tracking Systems in Coalition
Operations", Technical Note 1182
NC3A NML-CS NC3A December 2006 NII-Maturity Levels for Communication Services", Technical Note 1205
NC3A NNEC-FS-Vol1 NC3A October 2005 NNEC Feasibility Study - Vol-1

NC3A NNEC-FS-Vol2 NC3A October 2005 NNEC Feasibility Study - Vol-2
NC3A NNEC-NML NC3A Vers. 1.0 January 2007 Report on the development of the initial NNEC Maturity Levels and its
application
NC3A OA-V2.5 NC3A Vers. 2.5 December 2005 NATO Overarching Architecture
NC3A WCOA AC/322(SC/6)N(2008)0066-ADD1 NNC3A December 2006 Wireless Communications Architecture (land): Scenarios, requirements
(NC3B) and Operational View", Tech. Note 1246
NC3B C3IRO NATO C3 Board July 2007 C3 Interoperability Requirements for Operations
NC3B NAF-V3 AC/322(SC/1-WG/1)N(2007)0004 NATO C3 BVers. 3 August 2007 NATO Architecture Framework (NAF)
NC3B NFFI-DDOC AC/322(SC/5)N(2006)0025 NATO C3 Board December 2006 Interim NATO Friendly Force Information (NFFI) Standard for
interoperability of Force Tracking Systems
US DISA-GCMP US-DoD Vers. 5.25b April 2006 Global Information Grid Master Plan (GCMP)"
2.1 TARGET CAPABILITY
2.1.1 National Force Goals and Long-Term Plans

The overall planning for the provision by the Nations of Forces and Capabilities to
NATO is defined in the Defence Review Process and is defined by the Force Goals FFT-specific
capabilities – as addressed by this document – need to fit and support the stated Force Goals.
An analysis of the NATO Force Goals – for what regards the NATO FFT – has not yet
been done.
2.1.2 Concept for NATO FFT and Minimum Military Requirements

The NATO Strategic Commands (ACO and ACT) are finalizing a joint concept for FFT
and the Minimum Military Requirement (MMR) for the employment of this capability by Ground
Forces. A draft version of this document [BiSC FFT-CONC, 2008] has been used as the main
reference for the capability definition and of NFFT.
2.2 RELEVANT ARCHITECTURES AND STANDARDS

The architecture and standard artefacts that have been specified in NATO and that are
believed the most relevant for NFFT fall in the following areas:
1. General Architecture work, e.g.: Framework, Maturity Levels, Overarching
Architecture
2. Communication Services, e.g.: Architecture and Roadmaps for Wireless
Communication, Satellite Communication (SATCOM) and Tactical Communication
(TACOM).
3. Information Assurance Services, e.g.: encryption
4. Information Integration Services, e.g.: Core Enterprise Services, Message Text
Formats (MTF), common XML conventions, Tactical Data Links.

NATO UNCLASSIFIED
9
5. Communities of Interest (COI) Services, e.g. FFT Interoperability, Multilateral

Interoperability program (MIP), Land, Joint and other C2 Information Services.
6. Identification Standards Services, e.g.: Combat Identification (CID) technologies and
standards
The definition and availability of the corresponding capabilities is taken into account to
the maximum extent possible12.
2.2.1 NATO Architecture Framework (NAF)

The NATO Architecture Framework (NAF) (version 3, ref. [NC3B NAF v3, 2007])
provides a common language and reference to define Architectures. Although the NFFT-RM
document is not meant to be a comprehensive Reference Architecture for FFT, it is important to use a
NATO standard language.
The following are the views of the NAF and have been applied to the maximum extent
possible. They are meaningful for the objective of this document:
• NATO All View (NAV) (Executive Summary)
• NATO Capability View (NCV)
• NATO Operational View (NOV)
• NATO Service-Oriented View (NSOV)
• NATO System View (NSV)
• NATO Technical View (NTV).
The NATO Program View (NPV) has not been considered - at this stage – yet relevant
has not been used.
Overall, the NAF has been largely used as guidance and reference, but it has been adapted
for the objective and scope of this document.
2.2.2 NATO Maturity Levels

One of the recommendations of the NNEC Feasibility Study put forward by the steering
group of nations was, to further develop the concept of the NNEC Capability Maturity Levels.
The original Capability Maturity Model (CMM) was developed for the U.S. Department
of Defence by the Software Engineering Institute (SEI) at Carnegie Mellon University. The CMM was
to provide a standard approach for assessing the maturity of software development processes.
Equivalent to the CMM’s software development maturity levels, process maturity levels for
operational interoperability in a NATO mission have been defined based on the phases of
transformation. The maturity processes describe the effective sharing of information and work
processes across systems and organisational boundaries.
System maturity levels have been derived from the process maturity levels. The system
maturity levels describe the required applications and infrastructure capabilities as services that will
support the corresponding process maturity level.
The current definition of the NML - included in [NC3A NNEC ML v1, 2007] – has been
taken into account for this document. To be noted that this has not been yet agreed by the Nations.
12
With the documentation that was available at the time of writing.

NATO UNCLASSIFIED
10
The NATO Systems Maturity Levels extracted from [NC3A NNEC ML v1, 2007] are the
13
following
Table 2
NATO Systems Maturity Levels (NSML)
NS M L
N ATO SYST EM MATU RY L EVELS
N um Nam e D escr ip tion
1 Isolated C harac terized by standalone applic ations, databases and multiple ty pes of c ommuni cati on networks.
2 Func tional Stovepi pes C harac terized by dedic ated applic ations built to support different func ti ons . These applic ations are often
developed as separ ate sy stems , utili zing their databas es and many cas es thei r own network s. Multi ple
types of c ommunic ation networks ar e involved.
3 Communic ate and Inform C harac terized by improvements i n basic communic ations and information sharing capabilities.
Improvements in c ommunic ations will involve migration towards a single type of network for voic e, data and
video traffi c and will inc lude improved interoper ability between static , deploy able and mobile network s
uti liz ing data link tec hnology. Improvements in information sharing i nvolve the ability of independent
applic ations to exc hange and use i ndependent data components.
4 Collaborate and Plan This phase exploits improvements in shared s ituational awar enes s to improve deci sion mak ing proc es ses.
This phase is c har ac ter ized by the i ntroduc tion of advanc ed c ollaboration and planning capabilities.
5 Sense and Res pond This phase involves the seamless and tr ans par ent c ollaboration of all parties as needed, ac ros s all ec helons
of c ommand. This phase is c harac teriz ed by the a prolifer ation of sensor c apabilities and information
s har ing c apabilities at all levels, and by continued improvements in func tional c apabiliti es to enable
extremely r apid and agile res ponses to c hanging c irc umstanc es and fleeting opportunities .
Although the initial set of NML models is limited in scope it can already be of potential
use for NATO and national planners.
FFT is only one of the NATO and National Capabilities, contributing to the overall
capability. The FFT Capability Levels and Roadmap has to be therefore related to the NML and more
general NML Roadmap.
Work in the definition and agreement on the NML is still on-going. For this version of
the document, no agreed general NML roadmap has been used.
2.2.3 NATO Overarching Architecture

The aim of the Overarching Architecture (OA) v2.5 [NC3A OA v2.5, 2005] is to identify
the early implications of the results of the NNEC Feasibility Study [NC3A NNEC FS vol. I, 2005] and
[NC3A NNEC FS vol. II, 2005] - endorsed by the 26 NATO nations in November 2005 - for the
existing and planned set of NATO Common Funded CIS. Furthermore, it is the aim to identify the
implications to the linkage between NATO CIS and national CIS.
A strong emphasis is placed on a service-oriented approach, which extends from the
descriptions of the operational domain, through systems functionality and infrastructure capabilities
down to technical implementation. It focuses on an initial identification of Service Interoperability
Points (SIOPs). This concept was introduced in the NNEC FS and supports loose coupling between
NATO and national CIS segments. The SIOPs identified in the OA v2.5 allow for a graceful migration
of existing systems into a Network-centric paradigm, which preserves the benefits of past investments
in systems.
13
The description primarily refers to Information and Integration Services

NATO UNCLASSIFIED
11
According to the NATO Interoperability Directive (NID), the OA shall be used as the
basis for providing recommendations for the development of future C3 policies and strategic plans. In
order to keep the required C3 systems in line with the C3 policies and strategic plans the Overarching
Architecture is also the foundation for Reference Architectures. Reference Architectures act as the
basis for the development of Target ("transitional") architectures. The Overarching Architecture is
therefore to be used as guidance also for the FFT Architecture and Roadmap.
However, one of the most important aspects of the OA for the NFFT RM (i.e. the NATO
Services Framework – NSF) is not included in version 2.5 and will be addressed in the next version of
the OA (version 3), which is still under development. So, assumptions regarding standard NATO
services done in this version of the NFFT RM could not be based on the OA.
2.2.4 NATO Friendly Force Information (NFFI) standard and STANAG 5527
NFFI is the current interim standard for FFT Interoperability [NC3B NFFI-DDOC,
2006]). The focus of this specification to is the standardization of the data and higher (application)
level data communication profiles among FTS. Work is on-going at the NC3B to develop and ratify a
corresponding standard for FFT (STANAG 5527)
A preliminary roadmap for FFT interoperability has been defined by NC3A in [NC3A
TN-1182, 2006], based only on an analysis by NC3A and without any NATO or National
endorsement. It has been considered here as a preliminary study.
On going activities have been done and documented in the Research, Development and
Experimentation (RD&E) work done by NC3A (mainly under ACT sponsorship) and the Nations
aiming at an extension and enhancement of current standard for FFT interoperability. This RD&E
work has also been one of the main sources for the definition of the technical oriented vision for
NFFT.
2.2.5 NATO Combat Identification Standards and Roadmap

A preliminary analysis has been done on an initial roadmap for NATO Combat
Identification standards and interoperable capabilities produced by the NATO C3 Board (Sub-
Committee 7).
A completion and revision of this analysis needs to be done.
2.2.6 NATO Communication Services Architecture and Roadmap

The Communication Services most relevant for FFT are those “at the edge” and their
availability and quality is therefore the most critical for this Roadmap. They are addressed in the next
sections.
2.2.6.1 Wireless (non SATCOM) Communication Architecture (Land)

The FFT capability is strongly dependent on the available communication in the
battlefield. In particular, the availability of a standard wireless communication is important.
The NC3A Technical Note [NC3A TN-1246] “Wireless Communication Operational
Architecture” is very relevant for the NFFT-RM. The operational land scenario that has been
developed and analyzed there can be considered as largely applicable also for FFT.

NATO UNCLASSIFIED
12
The scope of the WCOA is both wider and more restricted than the one for NFFT. It is
wider in terms of data and service types: not only FFT but also voice, video etc.. But it is more
restricted since it focuses only on data transmission services of one type (wireless non SATCOM),
while FFT includes end services available with any Beyond Line of Sight (BLOS) communication.
At the time of writing, only the Operational Architecture has been developed. The System
Architecture is being defined and no services roadmap is available.
2.2.6.2 SATCOM Communication Architecture

The FFT capability is strongly dependent on available communication capability, in
particular SATCOM “Communications On The Move (COTM)”, i.e. reaching the mobile platforms
(soldiers) in the battlefield. Planned availability of specific such capability is therefore important for
the FFT RM.
2.2.6.3 Tactical Communication Architecture (Land)

The FFT capability is strongly dependent on available tactical communication (TACOM)
capability reaching the mobile platforms (warfighters) in the battlefield. Planned availability of
specifically such capabilities is therefore important for the FFT RM.
No service roadmap for TACOM has been considered yet.
2.2.6.4 Core Communication Architecture

The FFT capability is also dependent on core communication capabilities, enabling the
interoperability of mobile platforms (soldiers) in the battlefield with reach-back headquarters
capabilities. Although this is a general requirement for many services besides FFT, the FFT capability
places specific requirements level (e.g. for latency) on these services. The FFT Roadmap should also
take this into account when the required quality for communication services is planned to be provided.
The NII Communications Reference Architecture (NCRA) [NC3A NCRA ed.1, in prep.],
which is currently being developed by NC3A includes a detailed evolutionary view in which many of
the communication capabilities required in the NII are put into each other’s context. Specific
properties that are unique across the entire NII like QoS framework, end-to-end services, security,
PCN etc.. are important for the NFFT roadmap.
[NC3A TN-1205, in prep.] provides a detailed proposed definition of NATO Maturity
Levels for Communication Services. It is considered relevant at least as methodology for the NFFT
Roadmap and Implementation. No service roadmap is available at the time of writing
2.2.7 NATO Information Services Architecture and Roadmap
2.2.7.1 Information Integration Services Architecture

A roadmap for the delivery of Information and Integration Services (IIS) for NATO has
not as yet been developed. A broad architecture coherence roadmap has been defined by ACT and is
depicted in the following figure.

NATO UNCLASSIFIED
13
NNEC Convergence
Service Management
Community of
Information Security
Interest
Control
Information
Integration
Communications
System of Federation of
Services Systems
2010
Service Orchestration SoSE 2009

COI Services RA CP103 CP107 CP110
SMC
volu ion
tion
Information Integration RA
CP149 CP150 ACCS
2008
t
Service Communications RACP101 CP104 CP130

NIS Evolu
CP103 CP107 CP110

Definitio LOG OPS INTEL
PE
n CP150
L
AIS
NM
Information Integration RA 2007

CP101 CP104 CP130
Wireless Static SATCOM
Communications RA
CP101 CP130
Wireless SATCOM
CP104 CP150 + Other
Static AIS 2006
CPs
OA Development RA Development
Service Centric System Centric
Figure 1 NATO Architecture Coherence Roadmap (NAC-RM)
This roadmap sets a temporal outlook of the evolution of Capability Packages (CP) and
Services towards NNEC and provides a very general but not detailed or precise idea of availability of
Services that could/should be used for the FFT capability.
No NATO planning document providing a more detailed plan regarding availability of
IIS in NATO was available at the time of writing.
2.2.7.2 NATO Tactical Data Enterprise Services Roadmap

The focus of the emerging “NATO Tactical Data Enterprise Services (NTDES) –
Roadmap” (ref. [ACT NTDES-RM, 2007]) is the harmonization and evolution of Tactical Data Links
(TDL) toward NNEC. The current version does not include explicitly FFT services and the available
FFT Standard [NC3B NFFI-DDOC, 2006].
The long term goal of this Roadmap is for NTDES to include also FFT services. But the
specific timeframe of the NTDES Roadmap is beyond the year 2018, which is the limit of the NFFT
Roadmap described there. The consideration of NTDES has therefore been limited in this version.

NATO UNCLASSIFIED
14
2.2.8 Information Assurance Architecture and Roadmap14

Two important capabilities that are strongly related to information assurance are flexible
networking and information sharing solutions. Both were identified in the NNEC FS [NC3A NNEC
FS vol. I, 2005], [NC3A NNEC FS vol. II, 2005], and both are also very relevant to the achievement
of the long-term15 NFFT capability, given that NFFT relies on a robust and flexible communication
system, and that it requires sharing between multiple security domains in a federated environment.
The Protected Core Networking initiative is focused on providing flexible networking, while the
development of information sharing solutions focuses on enabling cross security domain information
sharing. Being NFFT one very relevant application for this type of technical capability (and probably
even one of the main application drivers) both are further described below.
2.2.8.1 Boundary Protection Services

The term Boundary Protection Services (BPS) includes all components that are required
to enable cross-domain information exchange or service delivery. It comprises technologies ranging
from simple firewalls, to one-way diodes to more comprehensive and standardized Information
Exchange Gateways (IEG).
Taking the IEG Roadmap [NC3A IEG-RM, 2008] as the main source, the assumption on
availability of the services that are relevant for NFFT is the following:
Current Situation (2009)
• firewalls, considered adequate to protect information flows between NATO
Mission Restricted and Nation Mission Restricted
• preliminary IEG Case B1 Pilots, considered adequate to protect information
flows between NATO Secret and Nation Secret
• preliminary IEG Case C1 Pilots, considered adequate to protect information
flows between
o NATO Secret and NATO Mission Secret and
o Nation Secret and Nation Mission Secret
Near Term (2010)
(consolidation of preliminary IEG solutions)
• IEG Case B1, adequate to protect information flows between NATO Secret and
Nation Secret
• IEG Case C1, adequate to protect information flows between
o NATO Secret and NATO Mission Secret and
o Nation Secret and Nation Mission Secret
Mid Term (2014)
(with additional Research and Development)
• IEC (Case C2), adequate to protect information flows
o between NATO Mission Restricted and Nation Mission Restricted
14
Most of this section has been contributed by G. Hallingstad and O. Hvinden (NC3A).
15
Terms still used here with a generic meaning. The NFFT Roadmap (Chapter 4) will be more specific on this.

NATO UNCLASSIFIED
15
o between NATO Mission Secret and Nation Mission Secret

Specific plans need to be put in place.
• IEG (Case C6), adequate to protect information flows
o between NATO Mission Secret and NATO Mission Restricted
o between Nation Mission Secret and Nation Mission Restricted
Considering the general problem, this is particularly challenging to solve.
Specific plans need to be put in place at least to cover specific requirements
Long Term (2018)
(with additional Research and Development)
• IEG (Case C6), general solution
• IEG (Case D), adequate to protect information flows
o between Restricted and Unclassified (in general)
2.2.8.2 Protected Core Networking (PCN)

Protected core networking is a combined communication and information assurance
concept intended to be used for the creation of a secure and flexible communications capability in
federated environments. The concept, described in [NC3A TN-1241, 2007], focuses on how to build a
communications capability which is dynamic while maintaining high availability of the network
services. These services include differentiated services based on priority and traffic class (e.g. voice
and video), as well as security services such as the provision of traffic flow confidentiality. Building a
core based on PCN enables interoperability between nations, and eliminates the need for system
specific communications solutions.
A common concern - when going from a system specific communications solution to a
shared networking model - is that it is difficult to protect against traffic analysis. In PCN, protection
of traffic flow confidentiality is offered as a service, so that traffic in need of this protection will
receive it, and traffic without such needs might be transported e.g. along a faster path. This is possible
because a Protected Core is still a trusted network, not for securing information itself, but trusted to
provide transport of information according to given quality and security parameters.
The PCN concept focuses on how to provide a secure and reliable information transport
capability, and does not ensure the confidentiality of information. This must be done by other means,
typically by IP encryption. However, current IP crypto is not able to support the dynamic
environments offered by PCN, and a new generation of IP encryption devices must become available
before this can happen. Work on the requirements for the NII IP Network Encryption (NINE)
Interoperability standard has started, and includes support for PCN environments.
Further requirements on NINE for NFFT, particularly in the longer term, is that NINE
devices are able to establish secure communications, without prior configuration of the specific
devices involved, protecting the confidentiality of information at an appropriate level depending on the
security domains. This means that two tracking terminals from different owners, certified from their
respective security authorities, should be able to meet for the first time in a tactical setting, identify
and authenticate each other, and negotiate the proper confidentiality protection between them. This
requirement must be accounted for in the NINE interoperability specification.

NATO UNCLASSIFIED
16
Protected Core Networking is anticipated to become available in 2012-2014 and is

expected to expand. Towards the end of the temporal scope of the FFT roadmap, the FFT
communication should rely mostly on a protected core rather than creating unique connections for the
FFT systems themselves.
2.2.8.3 Information sharing solutions

In a Protected Core Networking environment, flexible and robust communication
between information domains is possible. However, PCN does not provide any information sharing
solutions. In order to share information between security domains, information sharing solutions must
be implemented in the information domains, differentiating which information is releasable to another
party and which is not. These solutions are often referred to as cross domain solutions.
When interconnecting networks, boundary protection services are used to enforce the
proper separation between the networks. This is to ensure that unauthorized users are not able to
access the network that is being protected. While strong boundary protection is necessary in order to
interconnect networks, it is not sufficient in order to share information. For this, additional
mechanisms are necessary that are able to differentiate information according to releasability and
possibly to sanitize information for release to a certain level. This requires information to be labelled
and a mechanism to verify labels and prevent any information leakage when releasing information to
another security domain.
If information in an information domain should be differentiated, information must be
labelled according to a given scheme. Having a standard way of labelling information object will
ensure that information from multiple sources can be understood the same way with regard to the
label, making it possible for the same release mechanism to act on multiple types of information. The
labelling of FFT tracks in particular should follow the standard of labelling information objects, when
such a standard becomes available16.
When interconnecting networks and releasing information, the risk of leaking information
to unauthorized parties could increase. This needs to be mitigated by assurance in border protection,
label verification, information sanitation, as well as the assurance of the label itself. The assurance
requirements vary according to the interconnected networks, e.g. the assurance requirement will be
higher when connecting a NATO Secret network to a public network compared to connecting a NATO
Secret network to a NATO Confidential or NATO Restricted network. Ways or devices to share
information between domains can be information diodes, guards, or information exchange gateways
(IEG).
A goal in the protection of information is to move from the current model of protecting
the information confidentiality of information when it is transferred between security domains, to
protection of the individual information objects at all times, regardless of whether it is being
transmitted or stored. This is referred to as object level protection in the NNEC FS. True object level
protection with multi-level security possibilities is not expected to be widely available in the
16
The NFFI definition [NC3B NFFI-DOC, 2006] already includes a labelling scheme along these lines. This is
however not yet used in implementations due to the lack of adequate technical and procedural (or better
DOTMLPF) standards and capabilities.

NATO UNCLASSIFIED
17
timeframe of the FFT Roadmap. Labelling and handling of objects, like object level, in system high
networks is expected to be available earlier.
2.2.9 Command and Control Information Services

Air, Land, Maritime, Joint Command and Control Information Services (C2IS) –
including Joint Intelligence, Surveillance and Reconnaissance, Logistics, Theatre Missile Defence -
are consumers of FFT data and services. In particular, the Land Command and Control Information
Services (LCCIS) is also a producer of FFT “processed” information.
In NATO these services are provided by the Bi-SC AIS - in support of the NATO
Command Structure - and by the Nations, in support of their Force Structure.
C2IS and FFT Service interoperability are complementary. The relationship between the
C2IS and NFFT Architecture and Roadmaps can be summarized as follows:
• The NFFT and C2IS Architecture must be consistent and harmonized
• The NFFT Roadmap need to take into account that C2IS are the main consumers of
FFT services, which should therefore be enabled and capable to make use of former.
• The planning NATO and National C2IS need take into account the NFFT services,
their interfaces and availability.
2.2.9.1 Multilateral Interoperability Program

A specific case of C2IS Interoperability is the Multilateral Interoperability Program [MIP
Web-Site, 2007], which is one of the main references for multinational interoperability, primarily
among NATO and National Land-oriented CCIS’s. The main source used for the MIP Roadmap is the
“MIP Interoperability Program Schedule” (see ref. [MIPS v.3.4 D]).
The NFFT and MIP-compliant C2IS capabilities are complementary and need eventually
to be integrated in the NNEC concept. The NFFT and the MIP Roadmap need therefore be eventually
consistent and harmonized in the sense described in the previous section.
The technical MIP Interoperability Concept is mainly a Federated Database using an
agreed Information Exchange Data Model (now the Joint C3 Information Exchange Data Model -
JC3IEDM). The data replication protocol (Data Exchange Mechanism, DEM) is agreed.
The main capability increments of MIP are the “Blocks”. Each Block corresponds to a
version of the JC3IEDM.
Block-3 (B3) (JC3IEDM vers.3) - currently in the validation phase - is planned to be finalized
in 2008-2009. National deployment plan are not known. According to this plan,
It is applicable for the Near-Term of the NFFT Roadmap.
Block-4 (B4) (JC3IEDM vers.4) is under development. Current draft release is planned for
2012. It is therefore applicable for the Mid-Term.
Block-5 (B5) (JC3IEDM vers.5) is preliminary planned for release in 2016. It is therefore
applicable for the Long-Term
Respect to the NFFT Roadmap, therefore MIP-B3 is relevant for the Near Term and MIP-
B4 and B5 Are relevant for the Mid to Long term.

NATO UNCLASSIFIED
18
A FFT-MIP integration analysis and validation has been started in 2008 between the
current FFT standard and MIP-B3. FFT is considered as the contributor to MIP of land tracks part.
The following is expected outcome for the Near-Term.
• No change is required neither for MIP-B3 nor for the current NFFI standard (or
STANAG 5527).
• Mapping agents are developed to associate the appropriate MIP (C2) object to FFT-
derived positional data
For the Mid-to-Long Term perspective the FFT-MIP integration might proceed with
changes in either the C2IS or FFT Service/s or both and with the likely definition of specific mediation
services. The plans for MIP-B4 and B5 should take into account the availability of NATO and
National FFT (and more generally Land Tactical Interoperability Services) provided according to the
agreed version of the NFFT Roadmap.
2.3 NATIONAL ROADMAPS

Most Nations have developed or are developing roadmaps for C2IS - likely also including
FTS – and NNEC Services.
The initial definition of the NFFT Roadmap needs to take into account and by
harmonized with the available National Roadmaps. Later – when finalized and endorsed by the
Nations – the NFFT Roadmap is expected to be an input for future versions of the National Roadmaps.
A preliminary collection of information for National roadmaps and plans related to NFFT
has been performed by NC3A17. The feedback has been very limited. This section captures the only
relevant roadmap that has been received (from the USA) at the time of writing.
A more comprehensive analysis of National roadmaps is expected to be performed in a
new revision and update of this document.
2.3.1 USA
Specific activities relevant to FFT interoperability and its evolution are on going in the
USA (e.g. related to the activities by Blue Force Tracking Community Of Interest) as well as - more
generally – for the implementation and evolution of the Global Information Grid (GIG).
The information that - at the time of writing - has been received by the USA (Defense
Information Systems Agency, DISA) is the Global Information Grid Convergence Master Plan
(GCMP). Its scope is wider than NFFT but it is definitely a relevant input for the NFFT Roadmap.
2.3.1.1 USA – Global Information Grid Master Plan (GCMP)

The US Global Information Grid (GIG) Master Plan [US DISA GCMP, 2006] describes
the strategic 10-years plan for the GIG, which corresponds to the Network and Information
Infrastructure (NII) that is a required capability by NFFT.
The stages for the Near, Mid and Long Term for the GCMP regard respectively the
periods: 2006-2008, 2009-2012 and 2013-2016. Given the intrinsic uncertainty of any roadmap and
17
Through a Request for Information submitted to NC3A National Experts in June 2007

NATO UNCLASSIFIED
19
the reasonable assumption that a NATO-wide roadmap would be delayed respect to the USA, the
stages described in the GCMP version analyzed correspond adequately to those of the NFFT
Roadmap.
Technologies and capabilities are distinguished in the GCMP according four areas: (with
the corresponding NNEC Service Areas specified between brackets):
• Application and Services - A&S (NNEC COI and Information Integration Services)
• Network and Transport - N&T (NNEC Communication Services)
• Information Assurance - IA (NNEC Information Assurance Services)
• NetOps and Assured Service - NO (NNEC System Management Services)
In addition a User-Oriented (UO) service definition is provided.
The GCMP includes broad and comprehensive overview (both descriptive and
prescriptive) of the evolution of (US) technology and capabilities for the next 10 years, distinguished
in these areas. See [US DISA GCMP, 2006] for a detailed description.
The main milestones of the GCMP that are considered relevant for the NFFT Roadmap
are taken into account in the definition of the External Roadmap for NFFT.
2.4 EXTERNAL ROADMAP

The External Roadmap described in this section summarizes the assumed availability
over time period (2009-2018) of the most relevant standards, technologies and capabilities that are
required for NFFT. It describes the dependencies for (not from) the NFFT Capability, i.e. the context
for the definition and implementation of the NFFT Architecture and Roadmap. It is intended to be
used as the main planning interface between the various programs that are related to NFFT.
As mentioned before, the scope of the analysis reported here is focused on the
technology. The other aspects related the DOTMLPF are not taken into account.
The analysis of the available source documents has been presented in the previous section
of this chapter. The key sources are:
• Several draft or final architecture and/or roadmap documents by the NATO C3
Board Sub-Committees and/or ACT.
• the US Roadmap for the GIG (GCMP)
• the judgement by NC3A subject matter experts, as reflected in draft or final
Technical Notes.
Additional and more up-to-date source documentation is expected to be analyzed in
future revisions of this document.
The External Roadmap is summarized below in two tables:
• a high-level tabular version, indicating also the standardization responsibilities
within the NATO Committee Structure (EXT-RM1)
• a more detailed GANNT focused on capabilities and technologies (EXT-RM2)

TN-1322
Table 3
External Roadmap (EXT-RM1)
AREA RESP n. CAPABILITIES, STANDARDS & TECHNOLOGY AVAILABILITY

Communication & Network NC3B/SC-6
Services & Standards 1.1 Standard (IP) Communication in static/deployable nodes Current (2008)
1.2 Standard (Ground) Radio Communication Initial: Mid-Term (2014)
Common waveforms / SDR Final: Long-Term (2018) (1)
1.3 Standard (IP) Wireless Ground Tactical Networking Initial: Mid-Term (2014)
1.4 Standard (IP) SATCOM [Ground on the Move] Networking Initial: Mid-Term (2014)
1.5 Protected Core (fixed/deployable) Mid-Term (2014)
1.6 Protected Core (field/mobile) Long-Term (2018) (1)
Information Assurance NC3B/SC-4
Services & Standards 2.1 Encryption standards & capabilities (e.g. NINE)
NATO UNCLASSIFIED
NATO UNCLASSIFIED
Domain-based Initial: Mid-Term (2014)
Object-based after Long-Term (2018+) (1)
Information Integration NC3B/SC-5

Services & Standards 3.1 Security Boundary Protection Services
Mission/National Secret - Mission/National Restricted Gateways Mid-Term (2014)
Cross-Domain Gateways (full scope) Long-Term (2018)

3.2 XML Standards and profiles Initial: Near-Term (2010)
20
Final: Mid-Term (2014)
3.3 Core Enterprise Services (messaging, mediation, directory ...) Initial: Near-Term (2010)
(final inc. RT data dissemination) Final: Long-Term (2018) (1)

3.4 MTF-XML Services Mid-Term (2014) (1)
3.5 Tactical Core Services (RT) Initial: Mid-Term (2014) (2)
3.6 Integrated TDL Data Enterprise Services after Long-Term (2018+) (1)
Community Of Interest (COI) ==
Services & Standards 4.1 C2 Data Federation Services (JC3IEDM, MIP-DEM) Near-Term (2010) - MIP-B3 (2)
Mid-Term (2018) - MIP-B4
4.2 C2 Cross-COI services Initial: Mid-Term (2014) (3)
4.3 Specific COI Services <TO BE DEFINED> Initial: Mid-Term (2014) (1)
Combat Ídentification NC3B/SC-7
Services & Standards CID Technologies and Standards
5.1 Air-to-Surface - RBCI, NCTI Long-Term (2018, 2018+) (1)
5.2 Ground-to-Ground - JCID Near Term (2010)
5.2 Ground-to-Ground - BTID Mid-Term (2014)
5.3 Ground-to-Ground - DSID, NCTI Long-Term (2018) (1)
NOTES (1) Not yet planned; (2) MIP (3) Not formally established
Table 4 - External Roadmap (EXT-RM2)
EXT-RM2 EXTERNAL ROADMAP
Area / Category Near-Term Mid-Term Long-Term

Ref 2009 2010 Ref 2011 2012 2013 2014 Ref 2015 2016 2017 2018
CAPABILITIES / SERVICES NT MT LT
UM Users and Missions -------- in progress (selected, fixed access) ------- -------- in progress (selected mobile access) ---------- --- wide and mature implementation (most Nations) ----
1 some net-apps 1 Network connectivty to dis-mounted troop 1 Full network connectivty to dis-mounted troops and
(with limitations) (some Nations) land sensors (most Nations)
2 start of Enterprise wireless apps (some Nations) 2 (Land) sensor data available and consumed
by new netwrok services
COI Community of Intererest ---------------------- in progress ---------------------- ----- implementation of selected services/areas ----------- --- wide and mature implementation (most Nations) ----
(TO BE DEFINED ) (TO BE DEFINED ) (TO BE DEFINED )
II Information Integration ---------------------- in progress ---------------------- ----- implementation (some Nations, restrictions ) -------- --- wide and mature implementation (most Nations) ----
3 Limited and experimental CES 2 Core subset of CES (NATO and some Nations) 3 Mature implementation of NCES (NATO and most Nations)
(NATO and some Nations)
NATO UNCLASSIFIED
4 some NCES pilots completed (IM, WebCollab) 3 widespread NCES operations (some Nations) 4 Non Real-Time and Real-Time integrated services
NATO UNCLASSIFIED
5 start of SIP for EoP 4 NCES: collaboration, messaging, mediation, discovery

CS Communication Services ---------------------- in progress ---------------------- ----- implementation (some Nations, restrictions ) --------- --- wide and mature implementation (most Nations) ----
6 Core Network: improvement 5 Core Network: extension and consoldation 5 Core Network: implementation (most Nations)
7 improving voice/video over IP 6 Everything over IP (EoIP) (some Nations) 6 Everything over IP (EoIP) (most Nations)
8 continuing IPv6 migration 7 IPv6 implementation (some Nations) 7 IPv6 implementation (most Nations)
9 extending optical core 8 All optical core - terrestrial and space (some Nations) 8 All optical core - terrestrial and space (most Nations)
10 extending Protected Core Nework (classified) 9 initial Protected Core Networking capabilities 9 protected Core Networking extends to the tactical edge
(most Nations)
11 SATCOM: improving satellite latency 10 SATCOM: on IP (some Nations) 10 SATCOM : integrated with Core Network (IPv6)
21
12 TACOM 11 TACOM 11 TACOM : integrated with Core Network (IPv6)
13 WCOM 12 WCOM 12 WCOM : integrated with Core Network (IPv6)
14 TDL : no major evolution 13 TDL : enhancement (reduced restrictions) 13 TDL: improvements and increased interoperability
with Core network
14 dedicated data-link connections 14 Increased connectivity of platforms, gateway and
other ad-hoc solutions
15 limited connectivity, limited access to data, 15 increased support of interoperability connections
static infrastructure between TDL and IP-networks
16 complex manual configuration
IA Information Assurance ---------------------- in progress ---------------------- ----- implementation (some Nations, restrictions ) -------- --- wide and mature implementation (most Nations) ----
16 Protected Core: initial security services 17 Protected core: maturing security services
basic traffic flow confidentiality protection full traffic flow confidentiality
dynamic risk assessment and security accreditation
15 initial NINE Ispec 17 Initial NINE devices (some Nations) 18 implementation of NINE (most Nations)
16 initial labelling specificaiton 18 cross domain solution (HIGH to LOW track forwarding) 19 cross domain solutions (HIGH to Public forwarding)
services-based cross domain solutions
SM System/Service Management -------------------------- in progress -------------------------- ----- implementation (some Nations, restrictions ) -------- --- wide and mature implementation (most Nations) ----
17 improving performance at the tactical.edge 19 Solid behaviour at the tactical edge (some Nations) 20 Solid behaviour at the tactical edge (some Nations)
21 Integration of SMS with COP (most Nations)
ID Identification ----------------------- std in progress ---------------------- --- initial imp;lementation (some Nations, restrictions ) --- ----- additional technologies (most Nations) ---------
20 Initial G-to-G: BTID 22 G-to-G (BTID+, NSID, NCTI) and A-to-S (RBCI, NCTI)
Abbreviations Used
TN-1322
CES Core Enterprise Service NCES Network CES TACOM Tactical Communication
COP Common Operational Picture NL-TDL Non-Land TDL TDL Tactical Data Link
HAIPE High Assurance Internet Protocol Encryptor PKI Public Key Infrastructure WCOM Wireless Communcation (non SATCOM)
IP Internet Protocol SATCOM Satellite Communication
NATO UNCLASSIFIED
22
3. ARCHITECTURE CONCEPT
This section describes the Architecture Concept for NFFT, providing a high level, time
independent, description of the main components of the NATO FFT and their relationship. It differs
from a Reference Architecture in the fact it that does not include all the views and details required for
the latter.
The objective is to provide the essential architecture elements that are required to place
into context define and make understandable the Roadmap, which is described in Chapter 4.
The views presented in this chapter are based on the NATO Architectural Framework
(NAF), Version 3 [NC3B NAF v3, 2007]. The purpose of the NAF Views is to describe a perspective
in the most appropriate language for the relevant stakeholders.
The NAF has been used to the extent that is relevant and feasible for the purpose and
scope of the analysis. Not all the NAF views and sub-views are therefore included. E.g.:
• the function of the NATO All View (NAV) is covered by the Executive
Summary
• the NATO Program View (NPV) is not included.
Other major differences or omission respect to the NAF are indicated.
The architecture concepts refer to the final architecture for the NFFT subject area. It does
not include any time-dependent aspects with regard to the implementation. Scheduling, architectural
restrictions and constraints in the realization of the architecture are described in the Roadmap
Chapter 4.

NATO UNCLASSIFIED
23
3.1 OPERATIONAL VIEW

The NATO Operational View (NOV) is one of the standard views specified in the NATO
Architecture Framework. The main stakeholders for this view are representative of the Operational
End Users community (both J3 and J6 area) and the requirements and concept definition.
The main source for the definition of Operational Views for the NFFT is the work
already performed and published. No specific and detailed operational requirement analysis has been
done specifically for this version.
The NFFT Concept (including also the definition of the Minimum Military Requirement
(MMR) for FFT) is being been developed by the NATO Strategic Commands It is primarily based on
the analysis and experiments from the two recent NATO Missions involving a FFT Capability:
Kosovo and Afghanistan.
The main definition of the requirements included in the latest draft of the mentioned
document [BiSC FFT-CONC, 2008] has been used as main reference here.
For a possible refinement and revision of the operational requirements an available
relevant analysis has been identified. It regards the definition of the Wireless Communication
Operational Architecture [NC3A TN-1246], which includes also FFT. It has been performed by NC3A
with extensive involvement of NATO and National operational Staff officers. A reference to this is
included in the view NOV-1B.
3.1.1 General assumptions and observations

• The purpose of this view is not to specify a deployment configuration. Therefore the
number of instances of systems, networks and services, their localization in specific
commands or HQ and their connectivity are to be considered only as indicative.
• Not all vehicles or dis-mounted soldiers are/will be equipped with an FFT capability.
This percentage will likely increase over time.
• Each National Battalion/Battle-Group is provided with an organic and
homogeneous18 FFT capability
• The same or a homogenous FFT capability will not be available to all National
Battalions/Battle-Groups involved in an operation, which means that multinational
units (Battalions / Battle Group) could be equipped with non-homogenous FFT
capabilities.
3.1.2 Sub-Views
The sub-views are defined using the scenario and vignettes developed for the Wireless
Communication Operational Architecture (WCOA) [NC3A TN-1246], that, as mentioned above, are
considered to large extent applicable to the NFFT Operational View.
No NFFT specific analysis has been done yet. It might the objective of a future revision of the NOV.
NOV-1 High Level Operational Concept Description
NOV-1A High level force structure
18
i.e. with one FFT System

NATO UNCLASSIFIED
24
Figure 2 High level force structure (NOV-1A)
This 3-dimensional view represents (as example) the operational units and commands
involved in a typical NRF deployment.19 The “logical operational information flows are
also represented: they do not represent (although might be related to) direct physical
communication channels.
All land units depicted are supposed to be equipped with (National NATO) Force
Tracking Systems. The non-Land units are a representation of the requirement for
dissemination of FFT data to other services/platforms.
NOV-1B Scenario – Vignettes
Vignettes are used to describe specific and applicable operationally meaningful cases that
can be used to elicit operational requirements or assess system or technical solutions.
19
Indeed it refers to the scenario developed in [NC3A TN-1246]

NATO UNCLASSIFIED
25
Figure 3 Scenario - Vignettes (NOV-1B)
This 2-dimensional view shows the relationships between the different mission areas
(vignettes), defined for the WCOA. The scenario includes the following operational
vignettes:
1) Potential hostile force interference
2) Crowd control
3) Maritime force protection
4) Base protection
5) Neutralization of a strategic target
6) Preventing the hi-jack of and aid for a convoy
7) Preventing a bomb attack on NATO Forces
8) Neutralization of a gang leader stronghold
9) Close urban warfare
The main difference between this and NFFT perspective is that the focus of the WCOA is
the wireless non-SATCOM communications which includes more than just FFT data but
only for what regards the data transport through wireless communication.
For the complete description of the WCOA scenario and vignettes please refer to [NC3A
TN-1246] (Chapters 3 and 4).
NOV-1C High Level Requirements

NATO UNCLASSIFIED
26
Table 5
High Level Operational Requirements (NOV-1C)
NOV-1C REQUIREMENTS
Ref.num Category / Name
Operational Requirements
OPR 1 Operate in near-real time
OPR 2 Identify friendly forces
OPR 3 Monitor the precise location and operational status of friendly forces
OPR 4 Seamlessly provide this information vertically and horizontally throughout the Joint and Combined
battlespace
OPR 5 Operate in conjunction with other sensors to create an accurate, timely Recognized Ground Picture
(RGP)
OPR 6 Enable a sufficient degree of interoperability between NATO and Nationally provided FFT
capabilities
Limitations and Constraints

LIM 1 Security. Dissemination of FFT data is constrained by security policies that are deined by the
NATO Commanders and established and enforced by the data transmittion / data provision entity.
LIM 2 Reporting Latency. Delays in the reporting latency (reporting frequency and communication delays)
produces inconsistencies in the FFT-derived RGB that limis its use for fratricide prevention.
LIM 3 Coverage. FFT will not ikely ever cover the totality of vehicles and dismounted soldiers in the
battlefield. As a consequence "shoot/no-shoot" decisions cannot be solely based on FFT-deriived
information.
LIM 4 Degraded electronic environment. The communication channels used for FFT dissemination could
be negatively impacted by unforeseen physical and electronic environment conditions. As a
consequence, back-up C2 reporting methods and procedures need also be avaiable.
This view summarizes the main operational requirements (OPR) and the limitations and
constraints (LIM) for NFFT, as directly derived from the Bi-SC Concept for NATO
Friendly Force Tracking [BiSC FFT-CONC, 2008]. It is neither assumed to be complete
nor totally consistent with other requirement definitions, yet it the most specific and
authoritative available expression of requirements for NATO FFT.
A more detailed definition of the operational requirements can be achieved through
additional analysis with the NFFT stakeholders, e.g. using the scenario represented in
NOV-1B.

NATO UNCLASSIFIED
27
NOV-1D Air-Land Operational Information Exchange Requirements
Figure 4 Air-Land Operational Information Exchange Requirements (NOV-1D)
This view represents the main relevant Operational Information Requirements (OIR) of
FFT data with Air platforms and systems. Two main classes of OIR regarding own land
forces are distinguished into20:
• Situation Awareness, representing positional/status information with quality
characteristics (accuracy, timeliness …) sufficient for general awareness and non-
combat use of it
• Combat Identification, representing information about own forces but with a high
degree of accuracy, timeliness and assurance to be used for engagement purposes.
The figure distinguishes two main classes that are quite different in terms of capability
definitions:
1. Transfer of FFT data from fixed site (OPC HQ) to
- NATO fixed sites (ACC, CAOC, (D)ARS), which are equipped
with components of an Air Command and Control System (ACCS)
- NATO air platforms with wide communication capabilities
(ABCC).
2. Transfer of FFT data from mobile/deployed posts (TACP, TCP) to air
platforms (aircraft, ABCC) which are in their TDL communication
range.
20
These concepts and definitions are further addressed in the NATO Capability View (para 3.3).

NATO UNCLASSIFIED
28
This distinction will be important in the NATO System View analysis.
NOV-1E Operational Security Requirements (NOV-1E)

The sub-view NOV-1E provides a more explicit representation of some aspects relevant
for security.
Figure 5 Operational Security Requirement (NOV-1E)
The figure shows a variation of NOV-1A with a security domain overlay used as an
example to show how an FFT capability must be able to cross security domains, both
between domains of different ownership, domains with different security classification,
or both. Corresponding security policies and procedures need to be in place, allowing
this type of information exchange.
NOV-2 Operational Node Connectivity Description
This view illustrates the operational domain’s needs for information exchange in support
of operational activities. NOV-2 depicts operational nodes with need lines between those
nodes that indicate a need to exchange information.
NOV-2A Operational Information Requirements

NATO UNCLASSIFIED
29
Figure 6 Operational Information Requirements (NOV-2A)
This view identifies – on the basis of NOV-1A – the main logical information exchanges
among the operational nodes.
Different colour lines denote different information types associated to a track. See also
NOV- 3A and NOV-7 for a description of these information types.
• Black need-lines represent positional information (POS)
• Yellow need-lines represent identification information (IDE)
• Red need-lines represent operation status information (OPS)
(POS, IDE and OPS are further explained in the context of NOV-7.)
The legend in the figure also shows a possible graphical correspondence on a situation
display of a track with one information type.
Please note the following:
• All shown need-lines refer to “logical” land FFT information exchanges, i.e. to
mobile land forces (vehicles, dismounted soldiers)
• Physical channels can be different than those depicted. For example: there can be
Beyond Line Of Sights (BLOS) communication channels allowing lower level units
to exchange voice or data with their national Operation Control Centres or other
National Commands
• The direction of information is not shown explicitly as it should clear from the
context.
• Data-store symbols denote semi-static information that is persistent in nodal
information systems.
• The absence of some need-lines in the unit’s subordinates to one of the battalions
exemplifies that in some circumstances such information cannot be exchanged.
• The absence of IDE need-lines from some dis-mounted soldiers shows that they are
not distinctively identifiable, but only through their position

NATO UNCLASSIFIED
30
The figures relates also to a process called “information augmentation” in which

• The positional information (POS) that is received in near-real time “in band”, is
enhanced with additional information – relative to the same unit (vehicle, soldier)
this is otherwise known.
• This information (augmentation information) can be obtained (“off band”) through
other mechanism and is stored in specific locations. This is the meaning of an
information systems symbol in NOV-2A.
Information augmentation is normally required when for various reasons (available
communication bandwidth, security …) all available FFT information cannot be
exchanged “in band”. See also at NOV-1E for the security aspects of the problem.
NOV-3 Operational Information Requirements (OIR)

The purpose of this NAF view is to summarize the characteristics of the all information
exchanges between operational nodes, as identified in NOV-2. It includes one sub-view.

NATO UNCLASSIFIED
31
NOV-3A OIR – Information Requirement Description
Table 6
OIR - Information Description (NOV-3A)
NOV-3A OPERATIONAL INFORMATION REQUIREMENT
Ref Class Attributes
Name Description (cases) Volatility Sensitivity
POS 1 Positional information basic positional and tracker identification with "random" tracker ID 4-5 1-2
information. It contains a set of elements that
together constitute the minimal portion of
positional information that characterizes one
track.
with fixed tracker ID 4-5 2
IDE 2 Identification information identification of the operational unit (and/or platform info 2 3
platform) that is associated with the provided
positional information It is usually required for
standard situation display
unit info 1-2 4
OPS 3 Operational Status characterization of the operational status and semi-current (manually reported) 4-5 4
information intent (mission) of the tracked object
current (automatically reported) 3-4 4
with intent 2 5
ATTRIBUTES
VOLATILITY
Value Name Description Example
0 none Static information. Update rate: e.g. > 3 months OPPLAN information
1 extremely low Fixed per operation / NRF Rotation. Update rate: Op. deployment dat (position of
e.g.1 week - 3 months fixed sites, tracker allocation)
2 very low Fixed per (land) mission. Update rate: e.g.1-7 land mission: planning information
days
3 low Fixed per (land) mission. Update rate: e.g.1-24 land mission: status information
hrs
4 medium Current position. Update rate: e.g.1-60 min land position : normal tracking
mode
5 high Current position. Update rate: e.g.1-60 sec land position : close tracking mode
6 very high Current position. Update rate: e.g. < 1 sec Not applicable
SENSITIVITY
Value Name Description Example
0 none publicly available information fixed site locations published on
INTERNET
1 very low Ex. classificaton: NU, FOUO short-lived information, positions of
fixed sites
2 low Ex. classification: NR, FOUO positional information of vehicles
3 medium Ex. classification: NR, NC position,identification and
characterization of a unit
4 high Ex. classification: NC, NS position and status of a unit
5 very high Ex. classification: NS full information about unit
disposition, status and intent
6 extremely high Ex. classification: CTS Not Applicable
This view describes and characterizes the three classes of information flows identified in
NOV-2A. The description of these classes is based on the main categories of information
as included in the NFFI definition [NC3B NFFI-DDOC, 2006]. Each of these classes is
then characterized with two attributes:
• Volatility (dynamic properties)
• Sensitivity (security)
This definition of the metrics - in particular for volatility - is only indicative and refers to
current technology advancements. A refined and more comprehensive metrics (including
other variables) is necessary for the definition of the quality factors of the capability.

NATO UNCLASSIFIED
32
NOV-7 Information Model

This view presents a model of the information that is being exchanged via FFT and of the
other objects involved in the FFT process.
It complements the capability and service taxonomies represented respectively in NCV-4
(para. 3.3) and NSOV-1 (para. 3.4) and further details the information classes included in
NOV-2A and NOV-3A.
Figure 7 Information Model (NOV-7)
Some observation on the notation used in the figure:

• The names of the entities (boxes) and attributes are used as common terminology
in this architecture
• The model represents also a taxonomy of the domain, which is primarily
described though generalization and aggregation relationships.
• A generalization relationship (specific to generic), is named “IS-A”
• An aggregation or composition relationship (whole to part), is named
“COMPRISES”
• The cardinality of a relationship is indicated between parentheses after the
relationship name: (MIN, MAX). E.g.: (0, 1) zero or one (optional); (1,1) exactly
one (mandatory); (0,N) zero or more (optional).
The area shaded in blue in the Figure shows the specific scope of the exchanged
information regarding FFT. The model depicts also (in a different shade colour) the
extension (generalization) to other types of position-bound information that can be

NATO UNCLASSIFIED
33
cooperatively reported by the same agents, e.g.: incidents, enemy contact reports, Combat
Identification (CID). This type of data has similar characteristics as FFT-data and is
called in the following Land Tactical Structured21 Data (LTSD)
The FFT-part of this model is derived from the data model of the NATO Friendly
Information (NFFI) Data Exchange Format (DEF) [NC3B NFFI-DDOC, 2006]22.
The operational information flows POS, IDE and OPS identified and described in NOV-
2A and NOV-3A correspond to the NOV-7 information model as follows:
• POS: “Position and dynamics” entity
• IDE: “Identification” entity
• OPS: “Operational Status” entity
Relationship with the MIP Data Model(s) (JC3IEDM) and Data Exchange Mechanism.
Some of the relationship between the two information models can be summarized as
follows:
1. An FFT track (covered by the NFFT Information Model) represents the (current or
past) position of one land unit or individual soldier. FFT tracks are uniquely
identified in NFFI and non-duplication can be guaranteed by FFT services.
2. A “MIP data exchange” occurs between two or more MIP-enabled C2IS or LCCIS
application/service and can include C2-relevant information about a Land Unit
(including its current or past position). It is based on JC3IEDM
3. If a MIP-enabled (L)CCIS application uses NFFT as automated source for FFT data
about a specific land unit. One or more FFT tracks can correspond to the same MIP
Unit position.
4. The MIP Data Exchange Mechanism (DEM) is used to synchronize C2-relevant
information among C2IS typically at a lower level of granularity (e.g. from an
organizational and time perspective) than a typical FFT data dissemination in the
NATO FFT. This means that some level of aggregation and filtering is likely needed
to map the corresponding data (e.g. Unit Position) from one mechanism to the other.
For more information on the relationships between NFFT and MIP see also the System
View (para. 3.4)
The following standard NAF sub-views are not included in this version:
• NOV-4 (Organizational Relationship Chart)
• NOV-5 (Operational Activity Model)
• NOV-6 (Operational Sequence and Timing Description)
21
Structured is intended here primarily to distinguish it from multimedia data and free text messages
22
Note that the NFFI Data Model includes also the security-metadata and a placeholder (detailedData section)
that could be used for a possible future extension to LTSD

NATO UNCLASSIFIED
34
3.2 CAPABILITY VIEW

The NATO Capability View (NCV) is one of the standard views included in the NATO
Architecture Framework. The main stakeholders for this view are Strategic and Operational Planners /
Capability Requirement Managers (e.g. from Strategic NATO and National Commands, Agencies and
NATO HQ). Communication and Information System (CIS) Planners need also be involved.
The overall Capability described in this document is FFT for NATO, generally identified
as “NATO FFT” (NFFT). The main reference for this view is provided by [BiSC FFT-CONC, 2008].
A capability is defined in general as the ability to deliver a specified type of effect or a
specified course of action. As already stated above - Friendly Force Tracking is defined as
The capability to monitor the precise location of friendly forces in near-real time, and to
exercise Command and Control (C2) on these forces, as necessary
The capability View presented here describes the NFFT Capability for the purpose of
defining and implementing Capabilities, according to the capability-based planning process used in
NATO.

None
3.2.2 Sub-Views
The intent of the capability sub-views shown in the following is to show the relationship
between high-level NFFT capability requirements, capability goals and capability definitions in
connection with FFT.
NCV-1 provides a high level definition of the “WHAT”, “WHY” and “HOW” of NFFT
from a capability definition perspective. It implicitly includes the vision statement for NFFT, as
mainly defined in the BiSC Concept [BiSC FFT-CONC, 2008].

NATO UNCLASSIFIED
35
Table 7
NFFT Vision (NCV-1)
NC V-1 CAPABILIT Y VISIO N
Ref.num Facet
Operational G oals
OPG 1 To seamlessly provide near-r eal time Friendly For ce Information throughout the NATO Forc e
and Command Structur e
OPG 2 To inc rease situational awar eness of the land battlespac e
- Inc rease the oper ational effec tiveness of the force
- Minimize the risk of fratricide
Suppo rted ( Strategic) Operational Objectives

SOO 1 FFT is directly related to land and joint situational awar eness that support NATO
Tr ansformational Objec tives for
1.1 - Information Superiority
1.2 - Effective Engagement,
1.3 - J oint Maneuver
Provided Operational Function

POF 1 To provide the prec ise location ( and identity) of friendly land forces, as well as movement
spec ifics ( primary)
POF 2 To provide a communication capability to support C2 of Forces (sec ondary )
Suppo rted O perational (NATO M ilitary) Functions

SOF 1 Operational Command and Control
SOF 2 Logistic al Support
SOF 3 For ce Protec tion
SOF 4 Joint Maneuvre
M ain expected Benefits

BEN 1 Increased Ability to Operate Inside the Adver sary's Dec ision Cyc le
BEN 2 For ce multiplication
BEN 3 Improved Sync hronization of Forces
BEN 4 Reduced Risk and Dec reased Fratric ide
Approach
APP 1 To c apitalize on existing or emerging national FFT capabilities
APP 2 NATO provides the interoper ability standards and deployable infrastructure to support FFT data
exc hange between deployed FFT Systems and C2IS
- "hor izontal" (among tactical for ces)
- "vertical" (to higher Commands)
A refinement of the capability definition and the relationships with interoperability

requirements and goals is presented in the sub-view (NCV-2A), depicted in the following figure.

NATO UNCLASSIFIED
36
Figure 8 Capability and C3 Interoperability Requirements (NCV-2A)
NCV-2A – mainly derived from [NC3B C3IRO, 2007] - shows the main relevant
Capability Requirements (CR, drawn with continuous contour), their relationship with Command,
Communication and Consultation (C3) Interoperability Requirements (C3IR, dashed contours) and
NC3O Interoperability Goals (NIG, dotted contours) The specific scope of this document is in the
shaded box.
This view should also be revised according to the definition of the Force Goals for the
National involvement in NATO-led operations. << TO BE COMPLETED>>
The next sub-view (NCV-2B) clarifies the scope of NFFT in relation to other relevant
capabilities.

NATO UNCLASSIFIED
37
Figure 9 Capability Taxonomy (NCV-2B)
Some observation on the notation used in the figure:

• The relationship named “COMPRISES” indicates aggregation or composition.
The scope of this document is FFT-SIT, which is therefore part of the Land Situation
Awareness (i.e. awareness about ground-based assets and activities). Other definitions of FFT (for
instance including also friendly Air and Maritime situation) are not applicable to NFFT as defined
here.
As mentioned, the Friendly Force Situation Capability analyzed in this document is
focused on the Communication and Information Systems technology (part of the Material), a portion
of the overall Capability which would cover the whole DOTMLPF spectrum. The description of the
other relevant aspects should be defined in a subsequent revision and update of this document.

NATO UNCLASSIFIED
38
Figure 10 Capability Dependencies (NCV-4)
The NCV-4 (presented in the previous figure) describes the dependencies between NFFT
and related capabilities, details NCV-2B and expands NCV-2A in order to:
• specify the focus and scope for NATO Friendly Force Tracking (NFFT), relating it
to other relevant and distinct capabilities.
• describe a first level capability taxonomy
This view – very important for the NFFT Architecture - is not meant to be complete: it
focuses only on those aspects considered more important at this level of definition of the NFFT.
The other main network-enabled capabilities shown in the diagram are:
• Joint Common Operational Picture (JCOP) (with the C2IS Services required to
achieve it)
• Ground Common Operational Picture GCOP (with the LCCIS Services required to
achieve it)
• Tactical Communication capability (TACOM)

NATO UNCLASSIFIED
39
• Combat Identification (CID)

• Intelligence, Surveillance and Reconnaissance Tracking (ISRT).
The definition and relationship with Joint Situation Awareness (JSA), Combat
Identification (CID) and Intelligence, Surveillance and Reconnaissance Tracking (ISRT) are expanded
below.
Joint Situation Awareness (JSA) is:
the capability corresponding to the mental representation and understanding of
objects, events, people, system states, interactions, environmental conditions, and
other situation-specific factors affecting human performance in complex and
dynamic tasks. SA can be more simply defined as “knowing what is going on [in
the battlespace ] so you can figure out what to do”. JSA is SA applied to a joint
service space.
Combat Identification (CID) is:
the capability corresponding to the process of attaining an accurate
characterization of detected objects in the battlespace to the extent that high
confidence, timely application of tactical military options and weapons resources
can occur.
Combat Identification comprises a number of different technologies and can be
further distinguished into Air-to-Surface Identification (ASID), Battlefield Combat
Identification (BTID) and Air Identification friend and Foe (AIFF). NCV-4 shows
them as two distinct but closely related capabilities.
This is not the only possible definition. Another definition considers CID as
including Situation Awareness and therefore FFT. It is not recommended here due
to the significant diversity of the processes and technology.
Intelligence, Reconnaissance and Surveillance Tracking (ISRT) is
the capability – within the Intelligence, Surveillance and Reconnaissance domain,
to track the position of ground “objects” primarily done through non-cooperative
means.
ISRT is defined here as distinct and complementary to FFT. Other definitions
considering FFT as part of ISRT are not used due to the basic diversity between
cooperative and non-cooperative tracking processes and technology.
The meaning of the different entities and relationships represented in the diagram23 can
be derived intuitively from their names. More precisely, the following graphical and naming
conventions have been used for the shown relationships:
• Logical/Operational24 Capabilities are depicted with black, dashed contours
• Physical Capabilities / Services25 are depicted with red continuous contours
• The shaded rectangle shows the scope of this document.
• Specialization (generic to specific), named “SPECIALIZED AS” (dashed lines)
• Aggregation/Composition (system to part), named “COMPRISES”
23
Which is - more precisely - a “data model”
24
In other words: DOTMLPF
25
Only the “Material” components of DOTMLPF

NATO UNCLASSIFIED
40
• Dependency (capability to required capability), named “REQUIRES”26

• Implementation (function to capability), named “REALIZED WITH”
The main purpose of this view is to define better the scope (shaded box) and the
relationship between NFFT and its context.
The Basic FFT capability (FFT-BAS) is distinguished from the “interoperability-
enabling” capability (FFT-INT). Both are required to have an interoperable (“federated”) NATO FFT
Capability however their impact and role is different
• The FFT-BAS corresponds to the “standalone” National, NATO or commercial FFT
system/service, including the basic (hardware and software) components such as:
terminals, communication and control nodes/stations. It provides the basic capability
of tracking within a homogeneous (national) system and service. The report timing,
accuracy, level of information is determined by FFT-BAS
• FFT-INT is the additional capability that is required to have multiple (NATO,
National) FFT-BAS interoperating among each other.
This distinction is also very important for the NATO Program View (NPV)27 since the
current FFT NATO and National Programs have only focused sofar on the first capability.
As for the required communications capabilities, they are distinguished into:
(a) The Intra-FTS Communication (COM-IN), is connecting the various components
of each FFT-BAS. It can be included in the FTS itself or provided by an available
tactical communication system/service.
(b) The Mission Inter-FTS Communication (COM-EX), is connecting the various FTS
in the mission. It could also be based on other available communication services.
Other less relevant capabilities related to NFFT are not shown in the diagram.
• NCV-5 (Capability to Organizational Deployment Mapping)
• NCV-6 (Capability to Operational Activities Mapping)
• NCV-7 (Capability to Service Mapping)
The standard view NCV-3 (Capability Phasing) is used in (Chapter 4) to describe the
Roadmap.
Note that Security is considered as a property of a capability and does not represent a
capability on its own. No specific security view is therefore defined.
26
The REQUIRES relationship is less specific than COMPRISES, meaning that the required capability may or
may not be comprised in the subject capability
27
Not included in this version of the document.

NATO UNCLASSIFIED
41
3.3 SERVICE-ORIENTED VIEW

The NATO Service-Oriented View (NSOV) is one of the standard views included in the
NATO Architecture Framework. The main stakeholders for this view are actual or representative of:
the following areas: CIS Architects and Designers, acquisition and implementation, standardization
and compliance verification.
The intent of this section is to identify the main services and their relationships, to
provide a description of the main relationships with capabilities and supported operational
requirements
The distinction between Services and Capabilities is not always obvious. We define here
services as standard interfaces that can be provided by capabilities. The same capability can support
multiple services.
Services (e.g. as described in [NC3A AEM, 2007]) can be defined from a user
perspective (“User Services”) or from technical/implementation perspective (“NNEC Services”). The
NSOV described in this version of the document is mainly an NNEC Service view. A detailed
specification of these Services is outside the scope.
The identification and definition of services done in NSOV helps also clarifying and
refining the functionality and definition of capabilities as identified in NCV-4 at a rather high level of
abstraction.

• The current focus of the Service Oriented View is the services that are or will need
to be provided by NATO and/or Nations to implement interoperable FFT in NATO.
It is therefore primarily focused on the FFT-INT capability (as in NCV-4). Note
however that there is a close relationship between the FFT-INT and the FFT-BAS
supported services.
• The component FFT capability (FFT-BAS in NCV-4) is (initially at least) assumed
as defined and provided autonomously by Nations.
• In a subsequent stage, it is envisaged that specification for FFT-INT will cascade
into requirements for each individual FFT-BAS. So, it is anticipated that the
roadmap should also affect the component (FFT-BAS) capability.
• The NSOV view is time-independent, i.e. not all the described services are assumed
to be implemented and available at the same time. The Roadmap (Chapter 4), details
specific implementation time dependencies.
3.3.2 Sub-Views
NSOV-1 Service Taxonomy, which identifies the main services and their relationships. This
diagram is indeed more than a taxonomy28 (as specified from the NAF), but enhances
classification relationships with several other types of relationships.
28
In the “knowledge representation” domain, taxonomies are more or less equivalent to classifications of
concepts. More complex conceptual representations are normally described as “ontology’s”.

NATO UNCLASSIFIED
42
NSOV-1 is used also to expand and detail the services described in NSV-4 and also to
show a “build” relationship among them29. In this version we don’t use a standard NNEC
service taxonomy or framework that is not yet available at the time of writing.
Out of NSV-4, only the services that are required for interoperability purposes (i.e. those
provided or required by the FFT Interoperability Capability - FFT-INT) are included
here.
29
Which should indeed – e.g. according to AEM – be represented in the Component views.

NATO UNCLASSIFIED
43
Figure 11 Service Taxonomy (NSOV-1)
NATO UNCLASSIFIED TN-1322
NATO UNCLASSIFIED
44
The description of the services is provided in NSOV-2A. The meaning of the different
relationships can be guessed from the names used. To be more precise, the following
naming conventions have been used for the relationships:
• Generalization (specific to generic), named “IS-A” (dashed line)
• Service provision (consumer to producer), named “USES”
• Service composition (super-service to sub-service), named “COMPRISES”
“Generalization” is used to identify a possible “service re-use” relationship:
• The generic service can be a “core” service implementing the whole specific
functionality (as a subset)
• The generic service implements a significant portion of the specific functionality
Besides the FFT Services, NSOV-1 also includes other related services:
• the main consuming services (C2IS and BMS) and
• the main supporting services (e.g.: “Tactical Communication”, “Enterprise Service
Management”).
Each service is described in NSOV- 2.
Services are grouped according to the five standard NNEC Capability Areas defined in
the Overarching Architecture [NC3A OA v2.5, 2005]. (The last four areas are also
collectively named as NII – Network and Information Infrastructure).
• Community Of Interest (COI)
• Information Integration
• Service Management and Control
• Communications and Networks
• Information Assurance
In addition to these five Capability Areas, COI Services that are common to multiple
COI’s are also introduced (“Common COI Services”).
Whenever appropriate, services are associated to the Service Categories of the emerging
NNEC Services Framework (NSF) (ref. [NC3A-NNEC-NML, 2007]).
The figure shows also the relationships between FFT-specific Services, COI Common
Services and Infrastructure Services.
The FFT-specific Services are represented with blue-filled boxes in Error! Reference
source not found.. Those for which the Service Interface is particular relevant for NFFT
are depicted with heavy contours.
NSOV-2 Service Definition

This view provides a high-level definition of the Services included in NSOV-1. It is
intended as an initial definition only, which can be used as baseline for a further analysis
and a more detailed definition. It comprises two sub-views.

NATO UNCLASSIFIED
45
NSOV-2A Service Definition,
Table 8
Service Definition (NSOV-2A)
NSOV-2A SERVICE DEFINITION
RN Abbrev. Service Name I/F Service Description
COI SERVICES: OTHER SERVICES

1 BMS Battle Management Service (Generic) Battle Management Service that requires FFT data
2 C2IS Command and Control (C2) Information Service (Generic) C2 Information Service that requires FFT data
COI SERVICES: FFT SERVICES
3 FTS-CL FTS Data Cleansing Service Service implementing the cleansing of the FFT data (e.g. removal
of old or duplicate tracks)
4 FTS-DA FTS Data Augmentation Service Service providing a track-by-track augmentation (enhancement)
of FFT data according to an existing augmentation database
5 FTS-DC FTS Data Conversion Service Service converting FFT data from/to the native format to/from
another (standard) format or between two standard formats
6 FTS-DDS FTS Data Dissemination Service Service providing the dissemination of FFT data
7 FTS-DF FTS Data Filtering Service Service filtering outgoing FFT data and (possibly) also incoming
FFT data
8 FTS-DM FTS Data Management Service FFT Service providing all functions required to manage the FFT
data (aggregate)
9 FTS-IS FFT Interoperability Service(s) Aggregate of all services required to to achieve the NFFT
capability
10 FTS-SI FTS System Interoperability Service Service providing access to all function and data of a component
Force Tracking System
11 FTS-SM FTS Service Management Service Service supporting the management of all FFT services
12 FTS-SS FTS Security Service Service providing all functions required to protect and securely
store and exchange FFT data with different component of the
13 FTS-TI FTS Terminal Interoperability Service Service providing automated (periodic) FFT reports including (but
not limited to) positional timestamped data about the object that
the terminal represents.
14 LTIS Land Tactical Interoperability Service Service enabling the federation of multiple FFT Services in a
coalition environment (data sharing and management)
COI SERVICES: COMMON COI SERVICES
15 LA-DDS Land to Air Data Dissemination Service Service supporting the dissemination of Land Sensor data to Air
platforms
16 LS-DDS Land Tactical Structured Data - Data Service supporting the dissemination of Land Tactical Structured
Dissemination Service Data (LTSD, including FFT)
17 C2-DDS C2 Data Dissemination Service Service supporting the dissemination of C2 Data (other than FFT)
INFORMATION INTEGRATION SERVICES

18 NSF-MT Model Translation Service Infrastructure service supporting the (automated / algorithmic)
mediation of data among different formats (NNEC
Svc.Framework - Service Category)
19 NSF-SD Service Discovery Service Infrastructure service supporting the discovery of services (NNEC
20 NSF-SY Synchronization Service Infrastructure service supporting the dissemination data (in near
real time) to any other possible consumer service (NNEC
21 ==EPS Edge Proxy Service Service proding the interface with legacy Tactical Networks
SERVICE MANAG'T & CONTROL SERVICES
22 ==SMS Enterprise Service Management Service Infrastructure service supporting the management of any other
service
INFORMATION ASSURANCE SERVICES
23 FTS-DL FTS Data Labelling Service Service providing the labelling of FFT data required to implement
the security release policy
24 ==SS Core Security Service Infrastructure Security Service
25 ==BPS Boundary Protection Service Infrastructure service supporting the information assurance on the
exchange of data across different security domains (ex. IEG)
26 ==OPS Object Protection Service Infrastructure service supporting the information assurance on the (1)
exchange of data objects among different battlespace objects
with different security
COMMUNICATIONS & NETWORK SERVICES
27 FTS-DT FTS Data Transport Service Service providing the transport of FFT data
28 ==TCS Tactical Comm. Services Tactical communication services, Line Of Sight (LOS) or Beyond
(BLOS) supporting the Land Battlefield
Notes (1) Outside timeframe of roadmap

NATO UNCLASSIFIED
46
NSOV-2A identifies, describes (in general terms) and classifies the services depicted in
NSOV-1. Highlighted are those FFT services considered as most relevant for this
document.
Several of these services have already been outlined in some of the other views. A
detailed definition and specification of the services listed in NSOV-2A is outside the
scope of this document.
NSOV-2B Service Interoperability Points (SIOP)

This view describes the main SIOPs, i.e. is the (logical) points in the architecture where
interoperability is required and implemented (from the NFFT perspective). For each
SIOP, standard interfaces and profiles (Service Interoperability Profiles – SIP) are
applicable.
Table 9
Service Interoperability Points (NSOV-2B)
NSOV-2B SERVICE INTEROPERABILITY POINTS (SIOP)
Abbrev. Name Description Applicable
Services
SIOP-TT Force Tracking Terminal SIOP at one single FFT Terminal in the battlefield (vehicle or dismounted FTS-TI
soldier).
SIOP-SCN Force Tracking Service/System SIOP corresponding to a whole (homogeneous) Force Tracking System FTS-SI
Control Node or Service (FTS). Normally located at (one of) the Operational Control
Center than manages the FTS in the Theater (or a Region of it). Fixed,
deployed or mobile Command Post. It is likely co-located with the
Operation Center of the FTS Network
SIOP-MCN Force Tracking Service Mission SIOP corresponding to the whole (federated) Force Tracking (for one LTIS
Control Node single Theatre or for multiple Theatres). It is usually co-located with
Mission Operational Control Centers than monitors and manages all
NATO/coalition FFT in the Theater. It is likely co-located with the
Operation Center of the Mission Network
SIOP-TCP Tactical Command Post SIOP corresponding to a Tactical Command Post LTIS
SIOP-G2A Tactical Ground-to-Air SIOP corresponding to Command HQ or Post that has the capability of LA-DDS
communicating with Air Platforms. E.g. a Tactical Air Control Post
(TACP)
SIOP-XSD Security Cross-domain Boundary SIOP corresponding to the boundary between two Security Domains FTS-SS
(normally a pair, on each side of the boundary)
SIOP-F2C FTS to C2IS SIOP corresponding to the interface between an FTS (or Lant Tactical C2-DDS
C2IS) and C2IS application or services.
An indication of the applicable profiles (SIP) corresponding to each SIOP is provided in

the NTV (para. 3.6).
The detailed specification is not in the scope of this document and needs to be addressed
in future, more specific architecture and design activities.
• NSOV-3 (Services to Operational Activities Mapping)
• NSOV-4 (Service Orchestration)
• NSOV-5 (Service Behaviour)

NATO UNCLASSIFIED
47
3.4 SYSTEM VIEW

The NATO System View (NSV) is one of the standard views included in the NATO
Architecture Framework. It describes the FFT-relevant systems, services and networks that are needed
to support the requirements described in the NOV, to implement the capabilities described in the NCV
using the services described in NSOV.
The main stakeholders for this view are actual or delegated representative of the
following areas: CIS Architects and Designers, acquisition and implementation, operational system
management, standardization and compliance verification.

• The purpose of this view is not to specify a deployment configuration. Therefore the
number of nodes, systems and networks and the specific commands / HQ are to be
considered only as examples.
• To simplify some pictures, an FTS has been associated to a Battalion-level unit.
Consequently, the FTS Operational Control Center corresponds to the Battalion HQ.
(primarily applicable to NSV-1)
• This has to be considered only as example. In reality, a Battalion could involve
National Units equipped with different national FTS or an FTS could be used by
multiple National Battalions.
3.4.2 Sub-Views
The following views represent a deployed NRF configuration, involving:
• Two Nations (Nat and L-Nat, the Lead Nation) each with a deployed Tactical C2IS
and corresponding Tactical Networks, a National Reach-Back communication and
C2IS at the Reach-Back facility.
• One Combined Air Operations Center (CAOC) / ACCS Control Center (ARS)
• One Airborne Command Center (ABCC)
• One Mission Tactical Network (which may or may not be the same or integrated
with the tactical Network of the Lead Nation)
• The NATO Joint Force Command (JFC), with its C2IS and access to the NGCS
• The NATO General Purpose Segment Communications System (NGCS)
• One Deployed Joint Task Force (DJTF) Command, including its C2IS and the
connectivity to the NGCS and Mission Network.
• Several Tactical Data Link Networks (for connectivity with airborne platforms)
The NATO System Views is generally applicable to any time-phase (a near, medium and
long-term perspective). Specific applicability only one or more of these phases is explained when
required.
NSV-1 System Interface Description

This sub-view depicts the main interfaces among the relevant systems, services and
networks.

NATO UNCLASSIFIED
48
In a full network-enabled environment any “service” component can in principle be used

and by any “consumer” components. However in order to define such interfaces the main
consumer-producers interfaces need to be identified and used as drivers. This is the
purpose of the NSV view.
This view can become a rather complex one if too many systems, networks and interfaces
are represented in the same diagram. To make it more understandable, the view is split
into two sub-views (NSV-1A and NSV-1B) each representing it from a different
perspective and addressed to a different class of readers.
Systems and subsystems are either Capabilities (as from NSV-4) or Services (as from
NSOV-1). An explanation of the graphics and symbols used and their meaning
(complementing the figure legend) is described below.
XXX XXX XXX
L-Nat HQ JFC HQ Nat HQ
Strat/Opew NW
ABCC Airborne CCIS
(NATO NW) ABMC Airborne Mission Control System
C2IS C2 Information System
DJTF Deployed Joint task Force
ABMC FTS Force Tracking Service
TDL
Nat-L Lead NRF Nation
Nat Non-Lead NRF Nation
X NFT NATO Force Tracking
NGCS NATO Gen.purp.Comm.System
MCC Mission Control Center
OCC Operational Control Center
TCP Tactical Command Post
CAOC / ARS TDL TACP TACP Tactical Air Control Post
DJTF (MCC) TDL Tactical Data Link
TT Force Tracking Terminal
InterFTS
Mission
ABCC
II Tac NW II
L-Nat HQ (OCC) Nat HQ (OCC)
Nat Nat.
Tac NW Tac NW
TT TCP TCP TT
TT TT TT TT
TT TT
NSV-1A
Figure 12 System Interface Description – Operational (NSV-1A)
NSV-1A This sub-view depicts the main system interfaces with operational/physical
oriented representation. A more precise technical description is in NSV-1B and NSV-2.
This view is largely time-independent but is more evocative of a mid-term architecture.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
49
TN-1322
Figure 13 System Interface Description - Technical (NSV-1B)

NATO UNCLASSIFIED
50
NSV-1B This subview shows the main information services and interfaces with a
more formal technical notation than in NSV-1A30. Not all services and relationships from
NSOV-1 have been included for readability.
The specific meaning and use of the graphical symbols is as follows:
• HQ, command posts or platforms (vehicles) are depicted with continuous-contour
rectangles
• Systems, Subsystems, Components are depicted with dashed-contour rectangles or
triangles.
• Information (interoperability) services are depicted with circles: With fill if they are
FFT-specific services; without fill otherwise. (These services are a subset of those in
NSOV-2A)
• Interfaces are depicted with lines connecting services, systems or subsystems
(depending on the chosen level of granularity). Squared end-point denotes the
service provider end of the interface.
• Time applicability is represented by the color
- Black, if always applicable (i.e. starting from near term)
- Blue, if applicable from the medium term
- Red, if applicable only for the long-term.
To have a more comprehensive of the system interoperability, NSV-1B should be
considered in conjunction with NSV-2, which focuses on the communication aspects. In
order to obtain the service of any of the information services (NSV-1B), a suitable
Communication Service is to be available (as depicted in NSV-2) to support the
connectivity and data exchange between client and server of the IS. The word suitable
implies that the service level and the security requirements are to be met as well.
The function provided by the all services is described in NSOV-2A. In the context of
NSV-1B, the function of the main interoperability services can further described as
follows.
FTS TI FTS Terminal Interoperability Service represents the interoperability
service at the Friendly Force Tracking Terminal (TT) level. It provides in a
standard format the data originated from that terminal. Data can be all or
subsets of the tracks and whole tracks or subsets of them, i.e. different
filters can be applied. The service specifies how this data is provided and
the associated quality factors (e.g. regarding accuracy, currency and non
redundancy).
As shown in the diagram this Service is functionality applicable to the long-
term31.
FTS SI FTS System Interoperability Service represents the interoperability service
at the Friendly Force Tracking System (FTS) level. It provides in a standard
format the data originated from the terminals of that FTS. Filtering and
service provision properties similar to those for FTS-TI apply.
30
The notation used is largely based on the AEM methodology [NC3A AEM, 2007]
31
Such a service exist also in the short and medium term but - from an NFFT perspective - is not considered as
“standard” until the long-term

NATO UNCLASSIFIED
51
LTIS Land Track/Tactical Interoperability Service is the service supporting the

provision of FFT data for a whole theater/mission. It provides in a standard
format the data originated from all the FFT terminals of all FTS involved in
a mission/theatre Filtering and service provision properties similar to those
for FTS-SI apply.
Besides this, LTIS can also provide theatre-level data management, control
and mediation services (to be eventually subsumed by Core Enterprise
Services).
The diagram shows that LTIS provides this service at a single point
(corresponding to a Theatre Interoperability “hub”). This is likely the initial
configuration only. For subsequent evolutions (long term) a more
distributed LTIS architecture is implemented, than can also involve multiple
theatres (if required).
LS-DDS Land Tactical Structured Data (LTSD) - Data Dissemination Service is a
generic service supporting the near-real time sharing and dissemination of
tactical structured data similar to FFT (LTSD). This Service, initially
complementary to LTIS, in the longer-term would support also of FFT data,
generalizing and replacing part of the LTIS functionality.
LS-DDS would also include the functionality to mediate different data
formats for LTSD32 corresponds to part of the functionality of emerging
commercial components called Tactical Service Bus (TSB).
LA-DDS Land-Air Data Dissemination Service, is the service supporting the
dissemination of FFT (and eventually LTSD in general) to air platforms.
Note that LA-DDS is not required for the dissemination to ground
(fixed/deployable) air C2 centres.
C2-DDS C2 Data Dissemination Service supports the dissemination (and related
value-added services) of data (including situation awareness data and raw or
processed FFT) between FTS and C2 Applications, Services or Systems.
The main aspects that refer only to the long term (depicted with red, dotted lines) are
summarized as follows.
• Standard FFT service interoperability is also implemented at the terminal level (FTS
TI)
• LTIS can manage also other land-sensor data (e.g. through the LS-DDS). Likely,
other services equivalent to FTS-SI and FTS-TI would then be implemented for
these other sensor types.
• A distributed architecture is implemented through multiple, interacting LTIS in
different nodes. LTIS is not only a single Mission-level service, but it can be present
at different echelon levels, managing the FFT data for the respective organizational
unit.
• For example: the diagram shows also one LTIS at the Tactical Command Post (TCP)
level and one at the JFC HQ level.
32
E.g. relevant Message Text Formats (MTF)

NATO UNCLASSIFIED
52
- The first could be used to manage “local” interoperability within the TCP Area
of Responsibility (AOR) even if not connected to the Wide Area Network
(WAN) and system or theatre-level services.
- The second could be used to support a “reach-back” or back-up mission
management capability.
Analysis of specific issues
NFFT and Air C2IS / Air Mission Control (platforms)
This interface deals with the feed of FFT/LTDS from ground to air. Two types of
interfaces are shown as examples in NSV-1B.
• the Air Mission Planning interface between LTIS (service provider) and Air
C2IS at the CAOC and/or ABCC (service consumer). Its purpose is to provide
FFT data to the Air C2IS for planning purposes and/or for further dissemination
• TACP, ABCC and/or CAOC provide FFT data and services to Air Platforms
(Airborne Mission Control) through the LA-DDS service, converting, filtering
and providing the available FFT data (obtained though the LTIS interface). LA-
DDS is represented as a non-FFT specific service (non-filled circle), therefore -
likely - in the ACCS domain.
As for the time phasing, the view presents
• the interoperability between the MMC and the ACC/CAOC/ARS or ABCC
(mainly for mission planning and general situation awareness of the ground
situation) as applicable from the near term
• the interoperability with air platforms (ABMC) (mainly for combat or support
missions) as primarily applicable for the medium term
• the full interoperability with mobile ground-based tactical Command Posts
(TACP) as applicable to the mid-to-long term
NFFT and Message Handling and Processing Services (MHPS)
MHPS are Core Services supporting the delivery of structured text messages (MTF)
normally through a non-real time, store and forward mechanism.
FFT data can – with some limitations – also be converted into suitable MTF and
delivered through MHPS. This functionality is part of NFFT and in particular of the LS-
DDS service and – if the recipient is a C2IS – the C2-DDS service.
NFFT and CID
From an Operational view CID and FFT are closely related and the logical core data set
definition is basically the same. From an Information modelling perspective, CID data is
indeed a subset of the FFT data (as from NOV-7), including only the Identification and
possibly also the positional data.
However, the data/service quality characteristics (e.g. confidence of the identification and
data timeliness) and implementation are significantly different.
The two services need to be closely interoperable to complement each other and better
support a wider range of mission types and e.g. to achieve a significant reduction in the
risk of fratricides.
From a System view:

NATO UNCLASSIFIED
53
• the CID SIOP’s are typically at the terminal level, while the NFFT SIOP’s are at
the System, Mission and eventually also at the Terminal (SCN, MCN and TT –
as from NSOV-2B).
• CID data can be disseminated Beyond Line Of Sight (BLOS) e.g. to through
Tactical Data Links or be overlaid on NFFT. This latter can be considered as
part of the NFFT LTIS and/or LS-DDS functionality.
• Common FFT-CID SIOPs are at the Tactical Command Post (TCP) (and
Tactical Air Command Post – TACP) and – eventually – at the TT.
• Possible theatre-wide CID Services33 are likely required to interoperate with
NFFT LTIS.
NFFT and C2IS/MIP
One interface is shown as example in NSV-1B between NFFT and the C2IS’s in the
DJTF HQ. In reality, more interfaces of this type could be present also in other NATO
and the National HQ’s. The main functionally for which interoperability between NFFT
and C2IS is required regards:
• the consumption of FFT data by any C2IS service/ application. The accessed
service is typically the LTIS.
• the dissemination and possible mediation of FFT/LTDS data for other C2IS
application or services. This function is typically done by the C2-DDS service.
One special case of NFFT-C2IS interoperability is the one with MIP34. The C2-DDS
Service can support – among others - also the MIP interface
The applicable data models for the C2-DDS are:
• The Joint Command, Control and Consultation Information Exchange Data
Model (JC3IEDM) on the MIP side and
• The NATO Standardization Agreement STANAG 5527 on the FFT side
Some functionality that the C2-DDS needs to support is the following:
• An association of one or more tracks to the appropriate Land Unit need to be
performed. This can be done within NFFT or possibly also in the C2IS. If done in
both it needs to be consistent.
• Tracks need to be filtered (by time or by subordination structure) to match the
sharing level/granularity supported by FFT (normally higher) with that
appropriate for the C2IS / MIP (normally lower).
• One ore more tracks need to be aggregated (or selected) into one Land Unit
position.
• Within the two domains (FTS and C2IS) the same objects need to be identified
uniquely (when required, e.g. the Land Units) and the information need to be
mapped consistently. The most normal flow of information is from FFT to MIP.
33
Such as the proposed CID Database Service
34
This paragraph is based on the preliminary status of the FFT-MIP harmonization work done in 2008

NATO UNCLASSIFIED
54
NSV-2 System Communications Description

This view depicts - at a relatively high level – the types of networks and interfaces that
are most relevant for NFFT. It complements NSV-1B by describing the communication
services that are required to support the information interoperability services included in
that view.
No detailed communication design is addressed in this version.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
55
TN-1322
Figure 14 Systems Communication Description (NSV-2)

NATO UNCLASSIFIED
56
The notation used is similar to that used in NSV-1B and is largely based on the AEM
methodology [NC3A-AEM, 2007] and is described below
• HQ, command posts or platforms (vehicles) are depicted with continuous-contour
rectangles
• Networks are depicted with star shaped polygons. They are connected to HQ,
Commands, systems or subsystems (depending from the granularity) or to other
networks
• Communication Services are depicted with circles. (Only the most relevant are
shown)
• Interfaces are depicted with lines connecting networks to other networks, services
etc … Squared end-point denotes the service provider end of the interface.
• Lines connecting two networks represent network bridges/routes or gateways.
• Only the most relevant or complex network interfaces are considered as
Communication Services (CS) and depicted with circles. Simpler network interfaces
are represented as lines connecting systems/subsystems to Networks.
• An interface to a network is represented with dashed lines if it (may) need to provide
a mobile access point.
• Time applicability is represented by the color
- Black, if always applicable (i.e. starting from near term)
- Blue, if applicable from the medium term
- Red, if applicable only for the long-term.
Note that:
• Not all possible interfaces are shown in the diagrams for readability reasons. Only
the most relevant are shown.
• Communication Services (CS) are assumed to be based on underlying network and
transport services (not shown).
• All depicted networks are not necessarily physically distinct. Some of them (e.g. the
Tactical Mission Network and a Tactical Network) may be virtual private network
on the same physical communication infrastructure.
The main references for NSV-2 are the architecture and roadmap reference documents
for the communication services identified in Chapter 2.
The main new system aspects for the long term (depicted in red) are the following
• one virtual network, built on the principles of PCN, to ensure high availability and
sufficient communications and security services.
- It interconnects all the networks within the mission (federated mission network,
FMN) and is potentially extensible beyond the mission (shown as curved
dotted lines connecting networks)
- It bridges LOS (radio) networks with BLOS, WAN communications.
- This is not a simple bridge in communications terminology but has to have
intelligence to dynamically optimize the use of the available wireless LOS
connectivity (maximum use within the available capacity) and relay the
required data BLOS.
• “Communication islands” (i.e. temporary or permanent stand-alone tactical and/or
TDL networks) can still be present35
35
Shown in the diagram as isolated TDL or TacNW networks.

NATO UNCLASSIFIED
57
Analysis of specific issues

The following – non exhaustive – list requirements for FFT should be noted:
FFT and TACOM
• FFT requires both tactical and non-tactical communication capabilities. Since
however the most critical requirements are on the tactical part, the TACOM
requirements have been emphasized
• TACOM will be a combination / integration of Wireless, Line Of Sight (LOS)
networks and Beyond Line of Sight (BLOS), Wide Area Network (WAN)
communications (HF, SATCOM etc …)
• The combination of TACOM and SATCOM are the main required capabilities to
support the NFFT requirements for tactical networking in the Medium to Long term.
FFT and TDL
• Tactical Data Links are required to reliably and securely communicate with high-
value (primarily Air and Maritime) assets at the “edges”.
• Due to their relatively high procurement and support cost, their role is seen as
limited to specific ground mobile assets compared to a wide availability in the
battlefield of TACOM and SATCOM-based communication devices.
NSV-4 System Functionality Description

This view describes in more detail the functionality of the main FFT-relevant systems
and subsystems shown in NSV-1.

TN-1322
Air C2 Air Command & Control capab (generic)

FTS Force Tracking System
I/F Interface
NATO FFT LTIS Land Tactical Interop. Service
Capability NII NNEC Information Infrastructure (generic)
(NFFT) NNEC NATO Network Enabled Capability
COMPRISES
Intra-FTS Basic FFT FFT Interoperability Inter-FTS

Communication REQUIRES Capability Capability REQUIRES Comm. Capability
(COM-IN) (FFT-BAS) (FFT-INT) [COM-EX]
PROVIDES
NATO UNCLASSIFIED
PROVIDES
NATO UNCLASSIFIED
FFT Terminal FFT System FFT Sharing &
FFT Security ACHIEVED THRU
Interoperability Interoperability Managemnt
FTS Manag. FFT Terminal

& Control Tracking
ACHIEVED THRU ACHIEVED THRU ACHIEVED THRU ACHIEVED THRU
FFT Terminal COMPRISES Land Tactical Inter-FTS

FTS Security FTS Terminal Interop. FTS System Interop
58
Communication Interoperability Svc Comm. Service
Service (FTS-SS) Svc (FTS-TI) Svc (FTS-SI)
(LTIS) (COM-EX)
NII
FFT Positioning PROVIDES

Air C2 and Navigation
Interoperability
Vertical Horizontal FFT

REQUIRES Interoperability Interoperability Data Management
ACHIEVED FFT Situaton
THRU Display
COMPRISES
ACHIEVED
THRU
REQUIRES
Core Security Boundary FFT (G2G) FFT FFT
SUPPORTS
Service (==SS) Protection Data Dissemination Data Augmentation Data Cleansing
Land/Air Data
Ground-to-Air
Dissemination Svc. SUPPORTS
Interoperability
(LA-DDS)
NSV-4
Figure 15 Systems Functionality Description (NSV-4)

NATO UNCLASSIFIED
59
The distinction between capabilities, services and functionality is often not obvious. In
this document - and in this view in particular - we consider
• Functionality as a specification of functional requirements that is more abstract (or
at least not required to be further detailed) than functional aspects of capabilities
• Services as a further level of specification of capabilities
The purpose of this view is to show main functionalities of the NATO FFT and associate
them to the services required to implement them.
The use and meaning of the graphical symbols and terminology used is the same as for
NCV-4. In addition to this, services are depicted with oval shapes.
The FFT Interoperability capability (FFT-INT) need to provide four main functionalities:
1. The FFT Security, providing information and communication assurance among the
inter-operating participants (FFT capabilities).
2. The FFT Terminal Interoperability, enabling the standard FFT exchange between
different FFT Terminals, directly from terminal to terminal.
3. The FFT System Interoperability, enabling interoperability with each
NATO/National FTS as a whole.
4. The FFT Sharing and Management, supporting the sharing of FFT data and its
management within a specific domain. Initially this dominates the Mission-level.
Note that
• The capabilities are derived from NCV-4 and are depicted in the pop part of the
diagram.
• The services are the main (first level) services from NSOV-1.
• NSV-3 (Systems to Systems Matrix)
• NSV-5 (Systems Function to Operational Activity Traceability Matrix)
• NSV-6 (Systems Data Exchange Matrix)
• NSV-7 (System Quality Requirements Description)
• NSV-8 (System Evolution Description
• NSV-9 (Technology Forecast)
• NSV-10 (System Rules, Sequence and Timing Description)
• NSV-11 (System Data Model)
• NSV-12 (Service Provision)
3.4.3 Information assurance considerations on FFT information sharing

There are several factors that must be considered when interconnecting systems for,
either solely or partially, sharing of FFT information.
• First, the integrity of the system must be considered. A connection to another
system means exposing ones own system to a different set of threats. In the case of
trusted partners, these threats are similar to threats in ones native system, but must
still be considered. If the system carrying the FFT information is used for more than
just FFT information, the impact of a compromise will likely be higher than if the
FFT system was a separate system. Therefore, any interconnection must be
evaluated in order to ensure low overall risk.

NATO UNCLASSIFIED
60
• Second, the sharing of information means trusting other entities to protect your
information according to agreed procedures. In order to do this, agreed procedures
must be in place to ensure that proper mechanisms are applied.
These factors need to be addressed by policy and procedures (or more generally
DOTMLPF) and by the implementation of security services or security-related functionalities, which
is outside the current scope of this document.

NATO UNCLASSIFIED
61
3.5 TECHNICAL VIEW

The NATO Technical View (NTV) is one of the standard views included in the NATO
Architecture Framework. The main stakeholders for this view are actual or representative of the
following areas: CIS Architects and Designers, standardization and compliance verification.
This view identifies applicable and available standards and/or profiles to be used for the
implementation of NFFT. It is also used to identify areas where no standard exists which might then
suggest the need for new standardization work.

Some new acronyms are used to identify new standards or profiles for NFFT Note
however that:
• It is not the intent of this document to make any specific proposal for new NATO
Standards but only to indicate areas where some degree of standardization is required
to implement NFFT.
• The acronyms used in this document (e.g. NFFI v2, NFFI v3, LTIS v1, LTIS v2, LS
DDS v1, LA-DDS v1, C2-DDS v1) are used to identify and characterize some
interface/profile standardization needs. Their description outlines in general terms
what their scope is.
3.5.2 Sub-Views
This version of the document does not include any detailed system and technical
interfaces.
NTV-1 Technical Standards Profile

This view is used to identify applicable standards for the main interfaces that have been
identified in the System (NSV) and Service (NSOV) Views.

TN-1322
Table 10
Technical Standards Profile (NTV-1)
NTV-1 TECHNICAL STANDARDS

SERVICE INTERFACE APPLICABLE PROFILE /
STANDARD
Svc# Abbr. Name I/F# SIOP Type Description Std# Description SIP Refs Status
1 FTS-DT FFT Data Transport Svc 1 SCN Comm.Prot. Data Transport - reliable two-way 1-A NFFI - IP1 (IETF TCP/IP) NFFI v1 (subset) (A) Ratified (interim) (1)
2 SCN Comm.Prot. Data Transport - unreliable, one-way 1-B NFFI - IP2 (IETF UDP) NFFI v1 (subset) (A) Ratified (interim) (1)
3 ANY Data Format Data Exchange Format (DEF) 1-C NFFI - DEF NFFI v1 (subset) (A) Ratified (interim) (1)
2 FTS-DL FFT Data Labelling Svc 4 XSD Serv.I/F 2-A (RTO XML Labelling draft) (B) Under R&D
NATO UNCLASSIFIED
NATO UNCLASSIFIED
5 XSD Data Format XML security labels - output format 2-B (RTO XML Labelling draft) (B) Under R&D
6 XSD Data Format XML security labels - input format 1-C NFFI DEF NFFI v1 (labels) (A) (C) Ratified (interim)
(D)
3 FTS-SI FFT System Interoperability Svc 7 SCN Serv.I/F Web-service sharing and dissem. 3 XML service for smart pull (NFFI v2) (E) Under R&D
8 SCN Data Format FFT data 1-C NFFI DEF NFFI v1 (subset) (A) Ratified (interim) (1)
4 FTS-TI FFT Terminal Interoperability Svc 9 TT Serv.+ Data FFT Tactical Level dissemination 4 NFFI - Tac-Level svc I/F (NFFI v3 svc + data) Not yet addressed
5 LTIS Land Tactical Interoperability Svc 10 MCN Serv.+ Data Sharing and dissemination FFT data 5 LTIS svc I/F (initial) (LTIS v1 svc + data.) (F) Under R&D (2)
11 MCN Serv.+ Data Sharing and dissemination FFT data 6 LTIS svc I/F (distributed) (LTIS v2 svc + data.) Not yet addressed
62
12 MCN, Serv.+ Data Sharing and dissemination FFT data 7 LTIS svc I/F (NNEC) (LTIS v3 svc + data.) Not yet addressed
TCP
6 LS-DDS Land Tactical Structured Data 13 MCN, Serv.+ Data Sharing and dissemination (Land Stuct. Data) 8 LS-DDS svc I/F (initial) (LS-DDS v1 svc+data.) Not yet addressed
Dissem.Svc TCP
14 MCN, Serv.+ Data Sharing and dissemination (Land Stuct. Data) 9 LS-DDS svc I/F (NNECl) (LS-DDS v2 svc+data.) Not yet addressed
TCP
7 LA-DDS Land-Air Data Dissemination Svc 15 G2A Serv.+ Data Dissemination / forwarding to Air platforms 10 LA-DDS svc I/F (initial) (LA-DDS v1 svc+data.) Under R&D
16 G2A Serv.+ Data Dissemination / forwarding to Air platforms 11 LA-DDS svc I/F (NNECl) (LA-DDS v2 svc+data.) Not yet addressed
8 C2-DDS C2IS Dissemination Svc 17 F2C Serv.+ Data FFT to C2IS Disseminiation Service 12 C2-DDS svc I/F (initial) (C2-DDS v1 svc+data.) Under R&D
18 F2C Serv.+ Data FFT to C2IS Disseminiation Service 13 C2-DDS svc I/F (NNEC) (C2-DDS v2 svc+data.) Not yet addressed
References Notes
(A) AC/322(SC/5)N(2006)0025 (D) Intel.Community (IC) Labelling (TBD) (1) approved as D-Doc. In review as STANAG 5527 prop.
(B) RTO INFOSEC labelling WG (E) E.g. SIP3 v1. from CWID08- NBFSA Trial (2) LTIS - Land tactical Interoperability Service
(C) AC/322SC/5)N(2006)008
NATO UNCLASSIFIED
63
The view lists the main service interfaces derived from NSOV-136. If required, different
interfaces are distinguished for different interoperability points (SIOP). NII services are
not included.
For each of these interfaces a possibly applicable profile or standard is identified, or its
absence is outlined. The “status” column presents the assessed status of definition and
implementation for the profile or standard.
Highlighted are the new required SIP’s. The specific names given to them (e.g. NFFI v1,
LTIS v1) are purely indicative. The different versions of the interfaces can be best
understood after looking and the Roadmap sections.
• NTV-2 (Technical Standards Forecast)
• NTV-3 (Standards Configurations)
A revision of the NTV considering the latest version of the NATO Standard Interface
Profile (NSIP) needs to be done.
3.6 QUALITY FACTORS
Quality Factors (QF) are non-functional requirements that measure whether the extent of
a function or capability has been fulfilled. QF can be defined and measured at different levels
depending on the requirement level. QF’s are an essential part of the specification of the Service
Interoperability Profiles (SIP).
QF can in general be distinguished into the following classes (from [NC3A AEM, 2007]
• Quality of Operations (QoO)
• Quality of Information (QoI)
• Quality of Service (QoS)
Some of Technical Requirements defined in NOV-1C (e.g. availability, upgradeability).
are indeed Quality Factors. Other examples of QF for FFT are: timeliness, latency, accuracy,
precision. QF for FFT should be applicable, specific and measurable37
The specification of QF for FFT should first of all identify what is being measured. This
could be (from NCV-4)
1. the basic FFT Capability (FFT-BAS), i.e. the baseline (national) tracking system /
service
2. the FFT-INT Capability only, i.e. the (likely) degradation of performance due to the
interoperability capability
3. the overall (federated) NATO FFT capability (NFFT).
In general, the objective for NFFT should be the specification, implementation and
enforcement of QF at the overall (federated) level (3). But levels 1) and 2) should be addressed first in
order to achieve 3).
Significant differences in the QF of the components systems (FFT-BAS) could have a
relevant negative impact on the overall capability. For example: having some component systems
36
Depicted with thicker shape contours in NSOV-1
37
i.e. an operational measuring method and a testing environment can be defined

NATO UNCLASSIFIED
64
reporting every 10 minutes with a 2 minutes latency while other report every 30 seconds with 3 sec
latency can degrade significantly the overall Situation Awareness and level trust in the capability.
Further analysis for this section is out of the scope of this document.
3.6.1 Quality of Operation for FFT

Quality of Operation (QoO) constrains and give direction to the way the operation is
conducted.
3.6.2 Quality of Information for FFT

Quality of Information (QoI) refers to
(a) the intrinsic characteristics of the data (information characteristics) such as volume,
frequency and type independently from its use.
(b) the characteristics that are related to the exchange of data (communication
characteristics), such as availability, integrity etc …
3.6.3 Quality of Service for FFT

Quality of Service (QoS) constraints is the degree of measure of satisfaction with which
the user experiences a user service. From this User-perspective, QoS for infrastructure services
(required by these) additional QoS are derived.

NATO UNCLASSIFIED
65
4. VISION (LONG-TERM ROADMAP)
The Architecture Concept described in Chapter 3, describes the essential aspects of the
Friendly Force Tracking capability in NATO (NFFT).
This section presents a long term vision for the target 10-years period, represented as a
broad long-term roadmap (NFFT-RM). This is the core chapter of this document.
The vision described here is based on earlier work done by NC3A [NC3A TN-1182,
2006] (now extensively revised and extended) and on the architecture concept that has been described
in the previous chapter.
NFFT-RM consists of the following:
(a) The initial situation
(b) The desired final situation
(c) The roadmap itself, split into three major stages: Near, Mid and Long term
Each of these is represented through and End-of-Stage (EoS) architecture, reflecting the
only the Initial Operation of a corresponding Capability (IOC), i.e. when that capability is
implemented operationally by an initial significant subset of Nations and/or NATO Systems. Final
Operating Capabilities (FOC) – i.e. the extension of the implementation to all NATO Nations – are
difficult to estimate and are not included.
Following an approach similar to the one adopted in Chapter 3, “views” are used here to
represent the envisaged target architecture at the end of each stage. While in the Architecture Concept
the views are (to a large extent) time-independent, the End-of-Stage architectures correspond here to
the capability objective at a particular time.
4.1 SCOPE
The temporal scope of the NFFT-RM is a ten-year period (2009-2018), split into three
stages
• Near Term (2009-2010)
• Mid Term (2011-2014)
• Long Term (2015-2018)
The focus of this version of the roadmap is on the implementation of a “federated” FFT
capability in NATO. Therefore the following subject areas are considered out of scope:
(a) Implementation planning of “external” (i.e. non FFT) services, e.g. in the NNEC
Information and Communication Service areas. The assumption is that they are
available according to the External Roadmap ( para. Error! Reference source not
found.).
(b) Implementation of required COI / application or capabilities other than those
identified
(c) Implementation of NATO and National basic FFT Capability itself (FFT-BAS
capability in NCV-4).
Regarding the last point, it is important to notice that the main focus for this version of
the Architecture and Roadmap is the FFT Interoperability Capability (FFT-INT), considered as

NATO UNCLASSIFIED
66
distinct from and complementary to FFT-BAS (see NCV-4). This document is mainly descriptive
regarding FFT-BAS, which are assumed to be provided autonomously by NATO and the Nations.
Future work for the planning of the NFFT implementation38 will need to be more
prescriptive regarding such capabilities, e.g. respect the Quality of Service.
4.2 LIMITATIONS, RISKS AND ASSUMPTIONS

The main limitations, risks and assumptions are identified below.
Limitations:
• This is not the only possible roadmap and it cannot be demonstrated to be the best. However,
by making it as much as possible explicit it can be better understood and revised by the
different stakeholders.
• The level of detail and confidence is obviously much higher for the near and mid-term than
for the Long term.
Risks:
• The implementation of a FFT-focused Roadmap (such as the one this document describes) has
the risk of being inconsistent with roadmaps for other capabilities (COI, Core, Infrastructure).
• To eliminate or mitigate this risk, the NFFT Roadmap needs to be harmonized with related
and wider-scope roadmaps as soon as these are available.
Assumptions:
• The implementation of a NFFT-RM Milestone by at least some Nations normally follows the
implementation of a corresponding National FFT capability. A delay of some two years is
considered realistic and used.
• The identified milestones (for near, medium and long term) refer to general and standard
solutions. Specific ad-hoc solutions - developed earlier to addressed specific urgent
requirements – cannot be considered here.
• The COI-driven and incremental development perspective followed in the definition of the
NFFT roadmap is believed particularly suitable for an implementation approach driven by
“Quick Wins”. This as compared to infrastructure-driven implementation approach.
Eventually the two are obviously to merge.
• This COI driven approach previously described is in line with the general COI-driven NNEC
implementation, e.g. as described – regarding data – in the NNEC Data Strategy ACT NNEC-
DS, 2009].
4.3 CURRENT SITUATION

4.3.1 Overview
The current situation is characterized by the following main achievements:
1. Definition and approval by all Nations of the interim NFFI Standard for
Interoperability Among Force Tracking Systems [NC3B NFFI-DDOC, 2006]
38
E.g. for the detailed NFFT Mid-Term Roadmap

NATO UNCLASSIFIED
67
2. Implementation of an Initial Operational Capability of NATO-National Interface

(NNI) based on NFFI [NC3B NFFI-DDOC, 2006] in the NATO-procured ISAF
Force Tracking System (IFTS) deployed in Afghanistan
3. Definition and implementation of an FTS NNI Quick Win (QW), between the IFTS
and the National FFT Systems deployed in Afghanistan. This QW is coordinated by
NATO with national involvement and responsibility for the implementation of the
National Interfaces.
Because of the strong relationship between the FFT NNI QW in ISAF and the “Current
Situation” with regards to this document, the NNI QW is used as template for the representation of the
current situation.
Current Architecture
This overall capability (denoted also as Capability Level 0 or CL-0) is depicted in the
following view. National flags and system/network configuration are used only as examples.

NATO UNCLASSIFIED
68
Figure 16 Current Situation (RM-NOW)
TN-1322 NATO UNCLASSIFIED
NATO UNCLASSIFIED
69
Operational View
The operational capability (i.e. the overall capability NFFT from NCV-4) supports all the
Main Operational Requirements (OPR-1 to OPR-6) described in NOV-1C with some restrictions
regarding the security classification, the extent/functionality and quality factors of the capability.
1. The classification level of participating FTS is NATO / Mission Restricted or
equivalent National classification. This limits the FFT data that can be exchanged :
with respect to NOV-2A only POS information can be exchanged among FTS
2. A FFT information augmentation process - where POS information is enhanced with
more sensitive and more static IDE and/or OPS information that is exchanged off-
band39 - is implemented in the HIGH domain. This process is not fully automated.
3. Near-real time FFT data is available for C2 Situation Awareness applications. Some
restrictions apply on the implementation of the standard NFFI format for this flow.
4. Near-real time FFT data is also for Air Mission Planning, / Air Situation Awareness
applications. This flow has not been fully implemented yet.
Capability View
This current capability (denoted also as Capability Level 0 or CL-0) - as depicted in RM-
NOW - realizes many of the aspects of NFFT.
• FFT is shared among national and NATO FTS (horizontal interoperability)
• FFT is transferred from FTS to C2 Situation Awareness Applications and is
included in the theatre Common Operational Picture (COP) (vertical
interoperability)
• FFT is/will be transferred to Air C2 Centres for planning purposes (limited Air-Land
interoperability).
System, Service and Technical Views
The main architectural elements are summarized below:
1. System Architecture
i. The main topology is a Hub-and-Spoke, where the hub implementation is not (yet)
standardized and is implemented within the NATO FTS-hub40. The NATO FTS
System Control Node acts also as the Mission Control Node.
ii. Ad-hoc non standard hierarchical-hub solutions41 might be implemented e.g. for
optimization in co-located SCN.
iii. The IFTS also supports the sharing and dissemination function (subset of the FFT-
SM capability) as part of its functionality
iv. No other common services (apart from transport services) are shared across NATO
and national systems and domains
2. Service Interoperability Points (SIOP) and Profiles (SIP)
39
Meaning not on the same communication service used for near-real time FFT exchange
40
i.e. the IFTS for Afghanistan / ISAF
41
E.g. two-levels hub corresponding to multi-national / multi-FTS Regional Commands

NATO UNCLASSIFIED
70
i. The SIOP’s (between national FTS and IFTS) are at the FFT System Control Node
level (SIOP-SCN), which normally corresponds to the highest deployed
national commands.
ii. The SIP’s are based on the [NC3B NFFI-DDOC, 2006] ) standard (NFFI v1 in
NTV-1 and consist of Data Exchange Format (DEF) and data push between the
nodes and the hub.
iii. Quality Factors (e.g. timeliness, accuracy) are not yet addressed and included in the
SIP.
iv. The exchange of information required for data augmentation is performed via a
partly manual process and is not yet standardized. Augmentation data is not
passed through the same channels as the live tracking data.
3. Information Assurance
i. Multiple security levels exist, with two domains per Nation/NATO. FTS
interoperability (FTS-SI and COM-EX) are at the NATO Restricted / National
Restricted / National FOUO level. Horizontal (battlefield) FFT sharing is
therefore at this level only.
ii. Boundary protection devices with proper assurance to allow transfer of information
from restricted to mission secret (one way only) exist.
iii. Information sharing of FFT data from the restricted domain to the Mission Secret /
National Secret domain is enabled.
iv. A data augmentation process is authorized and performed in the Mission (ISAF)
Secret domain using semi-static augmentation data. Such data is received
periodically, according to the appropriate Standard Operating Procedures (SOP)
with a partly-automated, “off band” process.
v. All additional specific Mission (ISAF) security requirements and constraints are
supported.
4. Standards
i. NFFI v1 is standardized as [NC3B NFFI-DDOC, 2006]. It is in the process of
becoming a STANAG (STANAG 5527)
As already mentioned in the introduction of this chapter, at the time of writing the IOC is
implemented and the extension to all Nations is still in progress.
4.3.2 Limitations and Constraints

The following are the main limitations and constraints with respect to the Architectural
Concept presented in Chapter 3. Specific issues applicable for ISAF and the IFTS are generalized
when possible.
1. FTS whose security classification is higher than National or Mission Restricted can
in principle42 be connected through one-way guarding devices. Overall
interoperability with other restricted-level participants is limited.
42
This configuration has not yet bee implemented operationally at the time of writing this document.

NATO UNCLASSIFIED
71
2. As a consequence of the above, the security classification of FFT data that can be
exchanged among all FTS (horizontal interoperability) is not higher than
NATO/National restricted.
3. With reference to NOV-2A, the previous point implies (under the current
NATO/ISAF Security Policies) that only POS data (blue dots) can be exchanged
among FTS.
4. The data augmentation process (see previous paragraph) is not fully automated and
standardized so it is not easily replicable to a different context.
5. The system architecture has been realized with a “hub” system supported by a
specific system (ISAF FTS, IFTS). It is therefore a non-standard, system-specific
implementation of this topology.
6. As a consequence of the above, this capability is not easily re-deployable to an
operational area different from the original Theatre of Operations (Afghanistan)
without additional development.
7. From a technical/service perspective the standardized solution which uses the
Extensible Mark-up Language – XML – for the format of the exchange FFT data, is
not service oriented (as demanded by NNEC) and is not based on web-services.
8. Quality Factors (e.g. timeliness) are not addressed in the standard interface, which
might cause limitation in Situation Awareness.
4.4 FINAL SITUATION

The “final” envisaged situation consists in the implementation of all the NATO FFT
functionality fully integrated as a NATO Network Enabled Capability (NNEC). It represents the end
goal that is pursued. In reality – without going into philosophical discussions - no “final” situation will
ever exist. Its practical value in this document is to help identifying and analyzing the most difficult
and long term problems.
This view represents the implementation of the envisaged highest NNEC maturity level
for NATO FFT. It requires a comparable high maturity level for all required services and in particular
the Network and Information Infrastructure (NII).
It is difficult to provide even an indicative year for the achievement of this goal.
However, the rather confirmed assessment is that it is beyond the ten-year period covered in this
Roadmap (2009-2018).

TN-1322
JFC HQ
LTIS
Nat HQ
FTS-SS
NCES Nat HQ
Z NCES
Z Z
LTIS
NATO UNCLASSIFIED
Z FTS-SS
NATO UNCLASSIFIED
Z
NCES
NCES
FTS-TI
Z FTS-SS
FTS-TI
72
FTS-SS Z
FTS-TI
LTIS
Z
FTS-TI FTS-SS
Z Z FTS-SS
FTS-TI
FTS-SS
FTS Force Tracking Service
FTS-SS FTS Security Service
FTS-TI FTS Terminal Interop. Service
LTIS Land Tactical Interop. Service
NCES NNEC Core Enterprise Service
NNEC NATO Network Enables Capability
Z Encryption Service/Device
RM-END
Figure 17 Final Capability (RM-END)

NATO UNCLASSIFIED
73
The NNEC FFT capability depicted in the RM-END represents the full implementation
of the highest (“Sense and Respond”) NATO Maturity Level. It is included here as an indication of
what is the current NNEC goal for FFT.
The big cloud shows the envisaged homogeneous shared information space. In reality at
any point of time disconnection and dis-homogeneity will be likely present.
The next paragraph expands on some of the issues related to the achievement of a shared
information space from the IA point of view.
4.4.1 IA Considerations
In the vision, the protected core extends to every desktop and gives global connectivity,
providing all the desired needs for all traffic. In the time frame of the roadmap, it is reasonable to
believe that the protected core will extend to tracking terminals where necessary, but that this will
have to be planned. In the vision, the global reach is higher, and the time required to ensure the extent
of the connectivity will be very small.
With the core extending to the terminal and/or the terminal being able to establish
communications laterally, each terminal will also have to be able to establish secure communications
and decide on releasability of information. The establishment of secure communications is expected
to be possible in the long term by the introduction of new IP encryption equipment, and one can
expect that release capability is present in at least a certain number of terminals, enabling ad-hoc
cross-domain information sharing. This sharing capability is dependent on being able to provide the
proper assurance of release at the terminal itself. In the vision, all terminals would have the capability
to share information with any other terminal according to the security policy in effect.
Finally, the long term still expects IP encryption to be the primary measure for data
confidentiality protection. In the vision, IP encryption is abandoned for true object level protection
where each information object is protected according to its current security requirements at all time,
regardless of whether it’s being transported or stored. This would further ease sharing between
security domains and lighten the necessary equipment required.
4.5 LONG-TERM ROADMAP

The NFFT-RM spans a ten-year period (2009-2018) and is divided into three stages: Near
(2010), Mid (2014) and Long Term (2018).
Each stage is represented by an End Of Stage Target Architecture (EOS-TA) which
represents the envisaged/planned Capability Level (CL) at the end of the stage.
As already mentioned in the introduction of this chapter, the implementation of the
Capability Level by the corresponding End Of Stage is an Initial Operating Capability (IOC). The
achievement of a Full Operating Capability (FOC) is not indicated in the Roadmap, but it is assumed
to occur at least within the subsequent stage.
The general approach followed is the following:
• For each of the stages, the End-Of-Stage Capability is identified and described using
a corresponding view (RM-NT, RM-MT and RM-LT). This is the EOS-TA for that
stage, as described by the Architecture Concept (Chapter 3).
• One approach to implement this capability (from the previous capability stage) is
then outlined and the number of steps (Milestones) identified. This is not the only or

NATO UNCLASSIFIED
74
necessarily best approach but it is believe a good basis for strategic planning
purposes.
Each TA is graphically represented with only one view that summarizes and highlights
the main aspects of the capability. It is primarily an operationally oriented System View, mainly
derived from the High Level Force Structure (NOV-1A) and the System Interface Description (NSV-
1A). Simplifications with respect to these views are introduced in order to focus on the architectural
aspects that are most relevant.
The main simplifications with respect to the NATO Views presented in the Architecture
Concept are the following:
1. Only one Operational Command HQ is identified. In an NRF Scenario it can
correspond to a Brigade HQ, to the Land Component Command (LCC) HQ or to the
DJTF HQ.
2. Below this level different Battalion Command Posts/HQ’s are represented. Each of
these is assumed in the Near and Medium Term to be provided with its own organic
and homogeneous FFT capability. This HQ/Command Post is co-located with the
FTS Operational Control Centre (System Control Node).
3. When required, multi-national (and therefore multi-systems) HQ/Commands (or co-
located Commands) are represented as two or more connected43 Command Post/HQ
4. The ACC and the CAOC are graphically combined in the same HQ (although this
would not be the case in reality).
The capabilities are identified and named according to the Capability Hierarchy presented
in NCV-4 and in the Service Taxonomy (NSOV-1). The System/Service Interoperability Points
(SIOP) are also included using the terminology of NSOV-2B.
Please note also the following for the graphical and textual notations used:
1. The national flags are used only as examples to show heterogeneity of systems and
security
2. Regarding the identification of standards, the terminology used in the NTV is used.
See the assumptions described there (para. 3.6.1).
3. The wording “Quality Factors (QF) are standardized means that some key quality
factors (such as: timeliness, latency, accuracy etc …) are included in the SIP and are
therefore to be supported to achieve interoperability. The phrase ”Quality Factors
are implemented” then means that this SIP is supported including the QF.
4.5.1 Near Term (2010)

The Near-Term situation is an evolution of the current situation with a completion of the
analytical, experimental, standardization activities and operational implementation that have already
been initiated. This two-years period includes the consolidation and implementation of concepts and
standards that are already being defined, not the introduction of new concepts.
The objective is
i. to enhance the current interoperability solution by improving the adaptability
and flexibility and by introducing XML-Services
43
Graphically, through thick lines

NATO UNCLASSIFIED
75

a) Improved Situation Awareness in C2IS applications (vertical interoperability)
through the initial introduction of a smart-pull service functionality
b) Re-deplorability of the whole NFFT solution to any new Operational Theatre
(alternative or simultaneous) with any Force structure (NATO or National led)
c) Enhanced FFT and interoperability capabilities (performance, expandability,
robustness, efficiency and sustainability)
Assumptions and External Dependencies
The following main assumptions are made regarding available technology and required
components. They are largely reflected in the External Roadmap (para. Error! Reference source not
found.).
1. There are no major advancement of the enabling technologies and standards. In
particular, there are no significant changes in the available tactical communication
capabilities and there is no major advancement in BPS capabilities.
2. As for BPS, is expected a consolidation of IEG (Case B1 and C1 Pilots) for the
exchange of information between Mission Secret and National/NATO Secret.
Information exchange between the Restricted and Secret domains is largely based
one-way security protection devices (data diodes) (LOW-to-HIGH)
3. Requirements and procedures for FFT management and interoperability are
improved through lessons learned in the operational employment in Afghanistan and
Balkans. Changes in the FFT interfaces and functionality are requested and included
in the life cycle planning.
4. Basic FTS capabilities and communication are more robust and capable of
supporting higher reporting frequencies.
5. FFT technology evolution is largely based on the R&D activity done in 2007-2008.
EOS-TA
The End-of-Stage Architecture (EOS-TA) reflecting the Near Term is depicted in the following view.
It corresponds to Capability Level 1 (CL-1) of the NFFT.

TN-1322
BDE Brigade
BTN Battalion
COM-IN Intra-FTS Communication
COP JFC HQ NATO Secret COM-EX Inter-FTS Communication
COP Common Operational Picture
FTS Force Tracking System
HQ Headquarters
LA-DDS NGCS IEG
LCC
Information Exchange Gateway
Land Component Command
(NS WAN) LTIS Land Tactical Interoperability Svc
ACC/CAOC NATO Secret MCN Mission Control Node
NGCS NGCS NATO Gen.purp.Comm.System
COM-EX (Mission NW – HIGH) NW Communication Network
OPC Operational Command
RGP Recognize Ground Picture
SI System Interoperability (Service)
NATO UNCLASSIFIED
NATO UNCLASSIFIED
LTIS
BTN-4 HQ FTS-SI COP BTN-3 CP
FTS-SI
SCN (LTIS) Mission HIGH SCN
OPC HQ
BPS/ IEG (DJTF/LCC/BDE)
COM-IN
MCN COM-IN
LTIS OPC HQ
Mission LOW
76
Nat-E LOW
Nat-D HIGH
NGCS
COM-EX
TT TT TCP (Mission NW – LOW)
TT TT TCP
FTS-SI BTN-2 HQ
BTN-5 HQ FTS-SI BTN-1 HQ FTS-SI
SCN
SCN
SCN
COM-IN COM-IN COM-IN
UNCLASS
Nat-A LOW Nat-B LOW Nat-C LOW
TT TT TCP TT TT TCP TT TT TCP
RM-NT
Figure 18 Roadmap – Near-Term Architecture (RM-NT)

NATO UNCLASSIFIED
77
Operational View
The overall NFFT capability supports all the Main Operational Requirements (OPR-1 to
OPR-6) described in NOV-1C. The following are some characteristics of this stage:
1. FTS interoperability can be achieved in different Theatres of Operations, possibly at
the same time (multi-mission capability requirements from NOV-1C)
2. While both HIGH and LOW FTS (as well as the BMS and C2IS) are present,
significant limitations and restrictions exist in the interoperability and sharing
between these security levels.
3. The different security levels do not share the same view: HIGH systems can see
everything, while LOW systems (typically in the battlefield) can only see part of the
picture (the LOW classified). This reduced horizontal interoperability has some
impact on Situation Awareness in the battlefield.
4. (Filtered) FFT data is distributed in near real time to Air Platform and Maritime
through fixed/deployed sites (ACC, CAOC, ARS …) for situation awareness only.
This has still limited implementation at this stage primarily due to quality factors of
the data flows.
5. Non Military forces, units and/or vehicles also contribute (feed) to the NFFT
6. Limitations in Situation Awareness due to non-homogeneous or not-harmonized
Quality Factors (e.g. timeliness) among the various FTS are still present.
Capability View
This level of NFFT Capability (CL-1) provides a more standard and enhanced
implementation NATO FFT compared to the current situation, with the following main
characteristics:
1) Enhancement of the interoperability solution in ISAF
2) Horizontal interoperability involves most FTS in the LOW domain. FTS in the
HIGH domain can be also present and federated with some restrictions. Track
information of white/grey assets (e.g. by NGO) operating at the
UNCLASSIFIED (or equivalent level) can be injected in the NFFT federation.
3) The Tactical level communication is not standardized and FTS are therefore not
directly interoperable at that level.
4) Access to FFT mission data by other consumers (mainly C2 applications) is
significantly improved through a standard FFT XML-Service functionally (initial
fixed FFT-SOA). Vertical interoperability is therefore enhanced.
5) Re-deployability of the ISAF NNI solution in other possible Theatre of
Operations and with other Force Structures is made easier through an initial LTIS
functionality.
System Architecture
i. The configuration is still a Hub-and-Spoke topology as per in the current
situation. The hub is at the OPC HQ (DJTF, LCC or BDE HQ), corresponding

NATO UNCLASSIFIED
78
to the Mission Control Node for the overall FFT capability (NFFT Control
Node).
ii. An initial limited distributed configuration might be implemented to achieve
some optimization in the communication requirements involving multi-FTS
HQ/Commands. E.g.: a “two-level hub configuration hierarchy” (theatre and
regional) allows reducing the communication load when more SCN are co-
located in the same region.
iii. The Service Interoperability Points (SIOP) and Profiles (SIP) are the same as in
the Current Situation, i.e. in fixed /deployable sites: SIOP-FCN, SIOP-MCN,
SIOP-G2A and SIOP-XSD (see NSOB-2B).
iv. In general (like for the current situation), Beyond Line Of Site (BLOS)
communication is required;
• for individual tracking terminals TT to communicate with a “fixed”
operational control (SCN)
• for the SCN to communicate with the fixed Mission Control (MCN)
v. The MCN provides the sharing and dissemination capability within the whole
mission area.
It can be dynamically adapted to different FTS and different areas of
deployment. If required, it could also be connected to a Reach-Back facility
(COM-EX., in the figure)
vi. The following additional system aspects are not explicitly identified in the
figure.
• The OPC HQ will include – besides the MCN - also other C2IS
Application Services.
• An Interface is present between C2IS applications enabling the
dissemination of received FFT data (raw or processed) to other C2IS
application or services, likely using the MIP Interface. Possible
processing involves data filtering and aggregation.
Services
i. A new SIP element (complementing NFFI v1) is implemented in some/all the
SIOPs supporting a Web Service Interface (called conventionally NFFI v2 as
from NTV-1). NFFI v2 is standardized as appropriate.
ii. An FTS-SI can support one (NFFI v1) or more (NFFI v1 and v2) SIP’s. If more
are available, the most appropriate one is used depending upon the requirement.
iii. A new standard capability is specified and implemented: the Land Track
Interoperability Service (LTIS) v1 which supports the sharing and
dissemination of FFT data (received through FTS-SI) using all FFT SIP’s.
iv. LTIS v1 is supported (at least) by NATO and (possibly) by some nations. A
reduced LTIS capability is implemented to support the “hierarchical-hub”
topology (co-located SCN).

NATO UNCLASSIFIED
79
v. No other common service is assumed to be shared across systems/domains for

the purpose of FFT interoperability44.
Information Assurance
i. Two main classification levels are present (for each Nation and Mission-wide):
LOW (e.g. National or Mission restricted) and HIGH (e.g. National Secret,
NATO Confidential).
ii. Additionally a lower (e.g. UNCLASSIFED) level could be present).
iii. Appropriate Boundary Protection Service (BPS) is used to properly separate the
interconnected networks under different ownership.
iv. One-way data-diode to enable exchange of information from Mission LOW to
Mission HIGH. A similar solution can support to flow from UNCLASSIFIED
to LOW.
v. Limited information sharing solutions exist to enable horizontal and vertical
(one-way) information exchange.
vi. A “data augmentation” process is performed by NATO and the Nations in the
Mission/ National HIGH domain on LOW-classified data. It is fully
standardized and fully automated. As from NOV-3A, POS is augmented with
IDE data and little volatile OPS data.
vii. The overall flow is similar to the Current Situation: HIGH systems/services can
access HIGH and LOW (possibly augmented) information and LOW
systems/services can access LOW information.
Standards
New FFT Services are being specified and standardized in addition to NFFI v1 (i.e.
[NC3B NFFI-DDOC, 2006] or STANAG 5527 ed. 1). In particular: (as from NTV-1)
i. A web-service Interface (NFFI v2) for the FTS System Service (FTS-SI) (in
addition to NFFI v1) is specified (at least) as interim standard
ii. A Land Track Interoperability Service version 1 (LTIS v1), an interface for the
track management functionality is defined (at least) as interim standard.
iii. Operational and technical information management procedures are defined and
agreed to enable interoperability between NFFI-enabled FTS and MIP-enabled
C2IS. The actual implementation is planned for the Medium-Term.
Main Activities:
1) Consolidation of current solution in ISAF and extended support of National FTS
for NFFI and/or STANAG 5527.
2) Specification, standardization, validation of an XML-Service Interface to support
a flexible smart-pull of FFT data.
3) Specification, standardization, validation of an initial set of Land Track
Interoperability Services (LTIS) supporting standard enabling services that are
required to achieve mission-level FFT interoperability.
44
Services such email or directory could be present but are not considered relevant for the purpose of FFT

NATO UNCLASSIFIED
80
4) Initial implementation of Ad-Hoc Mediation Agents45 supporting cross-COI

interoperability. Areas include: general-purpose C2 Services (MIP) and Standard
Message Processing Services (ADatP-3) and limited FFT-to-Air Platform
interoperability (Link-16)
5) Operational-ready implementation of the above functionality (SIP3, LTIS and the
Ad-Hoc Mediation Agents).
Milestones
A possible implementation approach for the EOS-TA consists of the following main
milestones:
M 1. STANAG 5527 is ratified
M 2. NFFI v2 (SIP3) is specified and proposed as standard (extension)
M 3. LTIS v1 is specified and proposed as standard.
M 4. Initial LTIS v1 Capabilities are implemented
M 5. Initial support of the NFFI v2 interface (SIP3) is implemented.
4.5.2 Mid-Term (2014)

The main evolution in the Mid-Term with respect to the NT regards the further
integration of NATO FFT services with COI and Core services and the enhanced information sharing
enabled by new certified boundary protection device technology.
The objectives are:
i. To extend the RM-NT solution beyond FFT, to include other location--focused
data/service types in the Land Tactical Interoperability (LTI) domain (such as:
warnings, incidents, enemy contact reports, Combat Identification).
ii. To integrate LTI services into a standard fixed46 SOA to provide wide access of
such data/services to any net-enabled client as well as being able to consume
other selected net-enabled services within the Land Tactical domain.
iii. To improve interoperability among FTS in the Secret and Restricted security
domains through the enhanced information sharing enabled by new certified BPS
(IEG Case C)
a) Enhanced Situation Awareness in the Battlefield:
o more types of tactical data is shared in near-real-time besides FFT (Land
Tactical Interoperability), e.g. enemy contacts, incidents, warnings)
o better Quality Of Service (through systems and network improvements).
o Sharing extended to NATO/National Tactical Systems operating at both
HIGH and LOW security domains.
b) Enhanced Situation Awareness and C2 at the fixed/deployed Command Post/HQ:
o C2 Applications/Services/Users have smart access to all LTI data
45
Included in LTIS or in other COI services as most appropriate
46
i.e. based on a fixed or deployable communication infrastructure

NATO UNCLASSIFIED
81
o C2 Applications/Services/Users dealing with the Land Situation are

better integrated with the others.
c) Initial Combat Identification (CID) / FFT operational employment and fratricide
risk reduction
o Standard BTID devices are started being deployed
o Enhanced dissemination achieved through FFT/LTI infrastructure.
d) Enhanced Situation Awareness in the cock-pit.
Improved Quality Of Service (e.g. latency) of FFT/LTI data and of its
dissemination to Air Platforms improves pilots awareness of land situation.
The following main assumptions regard enabling technology and capabilities. They
reflect the External Roadmap (EXT-RM).
1. In general, progress in the NNEC infrastructure is achieved, but not homogeneous
among the different Nations.
2. Increased tactical connectivity is achieved with the deployment of an interoperable
narrowband waveform for UHF/VHF tactical use and information assurance to the
dismounted soldiers. Information assurance solutions may be based on Secure
Communications Interoperability Protocol (SCIP), being a bandwidth efficient IA
mechanism suitable for use on wireless channels which is supported by NATO.
3. Full tactical communication interoperability is not yet generally available. Some
Nations may have a federated tactical IP-network capability. Other Nations could
achieve this inter-networking only through (Mission Network) provided by NATO
or other nations47.
4. Basic FFT Services (FFT-BAS) are improved respect the NT and are able to provide
much more timely (near real-time) reporting, thanks to improvement of the tactical
communication infrastructure. In particular: TACOM, non-SATCOM Wireless
Communication and SATCOM “on the move” is increasingly available although
with limitations.
5. Initial standard Boundary Protection Services are implemented, support the HIGH to
LOW sanitization of FFT data (IEG Case C)
6. FFT Services (FTS-SI and LTIS) based only upon NFFI v1 are being replaced by
new versions based on NFFI v2 (web-service interface). This provides more
flexibility, efficiency and enables better cross-domain data exchange.
7. Other land tactical COI interoperability services progress in a similar way as for
FFT. Interoperability services equivalent to FTS-SS, FTS-TI and FTS-SI are being
specified and developed with an architecture that is harmonized with FFT.
8. Initial standard NATO and National Core Service (NCES) are becoming available
and accessible. However, not all NCES are mature and are available by in all
Nations. More specifically:
47
Like in the Near-Term

NATO UNCLASSIFIED
82
• Available NCES are accessible from fixed or deployed locations (i.e. not yet
through mobile communications).
• Among the standard NCES assumed to be available are: messaging, some
mediation (or Model Translation, NSF-MT) services and Service Discovery
(NSF-SD) services.
9. C2 Services (supporting MIP Block-3) are interoperable with FFT (and possibly
other land tactical) Services through specific mediation agents and information
management procedures.
10. Initial deployment of standard Combat Identification (CID) terminal devices (e.g.
Battlefield Identification Technology, BTID).
11. Specific Edge Proxies are implemented and deployed, supporting the forwarding of
FFT (and possibly other land tactical) to air and maritime platforms through Tactical
Data Link (TDL) networks.
EOS-TA
The End-of-Stage Architecture (EOS-TA) reflecting the Mid Term is depicted in the
following view. It corresponds to a Capability Level 2 (CL-2) of the NFFT.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
83
TN-1322
Figure 19 Roadmap –Mid-Term Architecture (RM-MT)

NATO UNCLASSIFIED
84
Operational View
The operational NFFT capability (as from NCV-4) supports all the Main Operational
Requirements (OPR-1 to OPR-6) described in NOV-1C making a significant progress towards the
implementation of a Shared Tactical Ground Picture. The main diffrences with the Near Term are the
following:
1. Enhanced Land Tactical Interoperability is achieved including not only FFT
information but also other location-based sensor derived or human-provided
structured data such as: specific sensors, enemy contacts, incidents, warnings (called
here LTSD - Land Tactical Structured Data). Such data is disseminated in near-real
time in a way similarly to FFT for Tactical Users and Command Staff.
2. Situation Awareness in the Battlefield is improved through better Quality of Service
(e.g. availability, latency and reliability)
3. Situation Awareness in the Battlefield is improved because Land/Joint Tactical
NATO and National systems are fully interoperable regarding LTSD both at the
HIGH and the LOW security level. Each system can see all the available and
released/sanitized information from the other systems.
4. Situation Awareness at the Command Post / HQ is enhanced e.g. through increased
visibility and accessability from C2 applications of NATO/National LTSD
5. C2 Services dealing with the Land Situation are better integrated: they can access
and consume LTSD and provide added value services to any other C2 Service.
6. LTSD (including FFT) can be distributed in near real time to all Air and Maritime
Platform and to TDL enabled Tactical Posts for situation awareness.
7. The most appropriate FFT services and data can be retrieved through discovery
service.
8. Initial deployment of standard BTID devices and dissemination through the LTSD
infrastructure improves Combat Identification and reduces the risk of fratricide.
Capability View
The new capability corresponds to the NFFT Capability Level 2 (CL-2) and can be
characterized as follows:
1) Horizontal interoperability is extended beyond FFT to include also other LTI
data. The sharing architecture is an enhancement of the one for FFT48. A good
part of the Shared Tactical Ground Picture is achieved.
2) Horizontal interoperability is enhanced to involve FTS and Tracking systems in
the HIGH, LOW and UNCLASSIFIED domain. New BDS technology (IEG
Case C) and augmentation/sanitization services allow the bi-directional
information sharing among these domains (limited only by Security Policies)
3) FTS can be discovered though discovery services and published metadata is
used to enhance the value for consuming application/services.
4) The Tactical level communication is still largely not standardized and FTS are
therefore not directly interoperable at that level.
48
assuming that parallel and harmonized have similarly progressed for other land sensor data

NATO UNCLASSIFIED
85
5) An initial fixed49 LTI-SOA (including FFT) is implemented, integrating LTI

services with available core infrastructure services. Most of the C2 services are
therefore able to consume and to provide added value to LTI services.
MIP-enabled C2 Services can also support LTI and can share appropriate LTI –
derived data in a MIP Federation.
6) Initial deployment of CID-standard devices (BTID) and CID dissemination
making use of available LTI./FFT infrastructure and services
System Architecture
i. The scope of the capability is extended interoperability from FFT to LTSD,
including also other (than FFT) location-based, near-real-time, battlefield
originated data.
ii. The same interoperability points exist as in the Near Term: SIOP-SCN, SIOP-
MCN, SIOP-G2A and SIOP-XSD (see NSOB-2B).
iii. At the system level a more distributed architecture is implemented.
• horizontal (tactical level) interoperability is still based on a (possible
hierarchical) Hub-and-Spoke configuration through additional federation
services (e.g. LTIS, LS-DDS, LA-DDS)
• an initial peer-to-peer SOA is implemented by the services based on the
fixed infrastructure (fixed SOA, including LTIS, LS-DDS, and LA-
DDS).
iv. The fixed infrastructure is enhanced through the publication of service metadata
about the available and accessible services. This data enables standard core
Service Discovery Services.
v. Common C2-DDS Services are implemented to support the transfer of LTSD
(processed) data between fixed C2IS Applications/Services. MIP-Enabled
application/Services are fully integrated with LTSD services.
vi. More C2 COI services are standardized and implemented. New cross-COI
interfaces are implemented as evolution and/or replacement of MIP-B4 to better
address cross-COI Service interoperability. Services
Services
i. New Common COI and Core services are standardized (and re-used within
newly developed FFT Services). In particular, new Land-COI Services can
support the sharing of other (than FFT) types of land sensor data
ii. LTIS version 2 Services, support a more distributed architecture improving the
overall availability, reliability and performance. LTIS are present at
fixed/deployed SIOP’s.
iii. Metadata publishing and discovery services include also FFT metadata
49
i.e. with services that are connected through the fixed/deployable communication infrastructure

NATO UNCLASSIFIED
86
iv. A Land Tactical Structured Data (LTDS) – Data Dissemination Service (LS-
DSS) Specification is standardized and implemented at least by NATO. LS-
DSS is a Common COI Service supporting the sharing and dissemination not
only of FFT data but also other land sensor data with similar characteristics. It
generalizes to LTDS the function done in LTIS v2 for FFT.
v. Land-to-Air Dissemination Services (LA-DDS) are mature and widely
available, not only in fixed Air Commands, but also in Tactical Command Posts
/ Forward Air Controllers. It uses core services (Edge Proxy Services, EPS)
vi. Local integration of FFT and CID and possible dissemination through the FFT -
or more generally land tactical - interoperability infrastructure (LTIS, LS-DDS
services).
vii. FTS-SI, LTIS and LS-DSS are enhanced and re-implemented using available
and accessible core services: NSF-SY (Data Synchronization), NSF-MT
(Model Translation). NSF-MT can for example be used to implement the FFT-
MIP interface.
viii. Core or Common COI Services are accessed from “fixed/deployed” points
(SIOP-FCN, SIOP-MCN) and not from mobile posts.
i. Similar to the near term situation, multiple security levels are implemented.
However, information sharing is improved, both horizontally and vertically due
to improvement in information sharing technology and boundary protection
services.
ii. High assurance boundary protection services protect interconnected networks
against unauthorized access. Certain flows can be allowed both from LOW to
HIGH and from HIGH to LOW.
iii. Labels are attached to information objects at the HIGH level, including tracks.
Labels are bound to the information object in a way that guarantees proper
assurance.
iv. Information sanitization services with proper assurance exist in order to
downgrade information objects from HIGH to LOW, allowing forwarding of
these sanitized information objects to LOW.
v. Information management functions such as data labelling, data augmentation,
and sanitization are largely automated.
Standards
i. The LTIS specification is extended to Version 2, supporting more distributed
configurations.
ii. A Land Structured Data - Data Dissemination Service (LS-DSS) is specified (at
least as an interim standard). LS-DDS used for required CID dissemination.
iii. Quality Factors included in the SIP definitions of LTIS and LD-DDS. Initial
support.
iv. FFT-specific metadata extension is specified and published (through standard
service) and is used for service discovery and/or for enhanced service
consumption.

NATO UNCLASSIFIED
87
v. Implementation of existing interface standards (NFFI v1. and NFFI v.2) are
validated against new service infrastructure. Revision as required.
Milestones
The main milestones which have been identified to achieve the implementation of the
EOS-TA are the following:
M 6. LTIS v2 is specified and proposed as standard
M 7. FTS Metadata is specified
M 8. LS-DDS v1 is specified and proposed as standard
M 9. C2-DDS v1 is specified and proposed as standard
M 10. LA-DDS v1 is specified and proposed as standard
M 11. Initial support for LTIS v2, LS-DDS v1, C2-DDS v1, LA-DDS v1 and FFT-
MD is implemented, using available Core Enterprise Services50
4.5.3 Long Term (2018)

The long-term goal is to move further towards NNEC. However, its objectives and target
capabilities are of course less defined and more uncertain than for the near and medium term.
One important reason for including the long-term perspective in this roadmap, is to
outline those aspects of full implementation of NATO FFT in NNEC (as represented in the “Final
Situation”, para. 4.4) that are believed as not yet achievable in ten years.
The objectives are:
i. To achieve FFT/LTI interoperability also directly at the tactical level
implementing a mobile51 LTI SOA capability, based on (and constrained by)
available interoperable tactical communications.
ii. To achieve land-oriented52 cross-COI interoperability from the tactical to the
strategic level, i.e. the full implementation of the Shared Tactical Ground
Picture concept in a NATO Network Enabled Capability (NNEC) context.
iii. To improve interoperability also with high-value tactical platforms through
enhanced quality of service for FFT/LTI and improved TDL-edge services.
The operational benefits are the following:
i. Enhanced real-time situation awareness in the battlefield comprising the
whole (friendly, enemy or neutral) land situation as well as joint and strategic
information.
ii. Improved Land Situation Awareness of the Commander (and of C2 Services)
with tailored and real-time access of all shared land tactical data (if required).
50
For simplicity, all the implementation milestones have been combined in one
51
i.e. based on a tactical mobile communications. Fixed LTI SOA assumed to have been already implemented at
that time
52
Beyond the Land domain is outside the scope of this document

NATO UNCLASSIFIED
88
iii. Enhanced and real-time Situation Awareness in all weapon-delivery

platforms, significantly reducing the risk of fratricides and collateral
damages.
The following main assumptions are made regarding available technology and required
components. They largely reflect the External Roadmap (para. Error! Reference source not found.)
1. Mature implementation of other (at least land) tactical services by NATO and (at
least) most Nations
2. Mature and distributed NCES are available in NATO and all (or at least most)
Nations
3. Accessible and available (wireless and SATCOM based) communication in the
battlefield
4. A protected core network is available in fixed/deployed locations as well as in
mobile ones, providing communications and security services (such as traffic flow
confidentiality).
5. Tracking terminals are equipped with modern IP encryption devices, adhering to the
interoperability standard for NINE and enabling the dynamic setup of secure
communications between tracking terminals under different ownership.
6. At least a limited set of tracking terminals are equipped with technology for cross
domain information sharing, enabling direct sharing between terminals of different
classification.
7. Standard Combat Identification (CID) terminal devices (multiple technologies, both
Air-to-Surface and Ground-to-Ground) are widely deployed.
EOS-TA
The End-of-Stage Architecture (EOS-TA) reflecting the Long Term is depicted in the
following view. It corresponds to a Capability Level 3 (CL-3) of the NFFT.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
89
.
.
TN-1322
Figure 20 Roadmap –Long-Term Architecture (RM-LT)

NATO UNCLASSIFIED
90
Operational View
The main aspects of RM-LT from an operational perspectives are the following:
1. Increased availability, performance and reliability of the interoperability solution
also for disadvantaged users53.
2. Interoperability is achieved also among user terminals (dismounted soldiers, vehicle)
only connected through LOS
3. The sharing of tactical and operational situation assessment (or Shared Tactical
Ground Picture) is fully implemented.
4. Each NATO/National FTS component at any echelon level is interoperable
(regarding at least land tactical data) with all other components of different
NATO/National FTS in near real-time through widespread deployment of common
waveforms (narrowband and wideband) and common IA mechanisms for both
NATO and coalition.
5. Each FTS-equipped unit can provide its information to any user/service in the
network and can consume any available service in near real-time (according to
sharing policies). Some restrictions apply.
6. Each tactical unit has near real time land tactical information (including but not
limited to FFT) of its own and relevant units.
7. This sharing is achieved largely independently from the available connectivity54.
Local standard wireless connectivity with neighbouring units is assumed to be
always available. If BLOS connectivity to the OPC HQ and/or Higher Commands is
available, these commands can have a near-real-time FFT picture.
8. Information aggregation and filtering is performed by the COI services / wireless
communication nodes of unit commanders in order to optimize the use of available
scarce communication capabilities (e.g. of the radio spectrum).
9. Most Quality Factors issues related to the (Land) Situation Awareness are solved:
the NATO FFT situation awareness is not degraded respect the single FFT system
awareness.
10. For the land, air or maritime tactical user FFT data is real-time and is enhanced with
trusted identification information (Combat ID). When integrated, this information is
therefore usable directly for targeting purposes.
Capability View
The NFFT Capability Level 3 (CL-3) can be characterized as follows:
1. Achievement of mature, comprehensive and high quality (e.g. real-time) land
situation awareness, integrated with C2 services to enable self-synchronization.
Operational and technical requirements from NOV-1C are supported also for LTI.
2. Full network-enabled and distributed implementation of the extended-NFFT
capability covering also all aspects of LTI (LTI fixed/mobile SOA).
53
Indicating in particular the soldiers in the battlefield
54
In the near and medium term configuration, to achieve this there was a requirement to have – typically BLOS
- connectivity to fixed Control Nodes

NATO UNCLASSIFIED
91
3. Direct tactical level interoperability - regarding FFT/LTI - as a tactical COI’s,

interoperable with the other mobile/fixed COI’s and infrastructure services. In
particular, efficient and harmonized use of both FFT and CID.
In particular:
• Each battlefield User with a FFT/LTI Terminal capability can
o Securely communicate directly with its neighbours through interoperable
(wireless non-SATCOM) communication.
o Provide its own FFT/LTI data to any available and accessible consumer on the
network, managed/filtered through management services (like LTIS), in fixed
and/or mobile sites.
o If required, provide its own FFT/LTI data (non-managed/filtered) to any
available and accessible consumer on the network without any service
intermediary.
o Consume in near real-time any available and accessible information services.
o Protect itself (information assurance)
• Each User and/or Service in the network can
o Discover, access and consume in real-time, tailored, raw LTSD data from
battlefield services
o Discover, access and consume in real-time, tailored, processed/value added
data from other network-enabled services
System Architecture
i. The main enhancement respect the CL-2 topology (as from NCV-4 and NSV-
4) is that it becomes truly distributed.
ii. A standard FFT/Land Sensor interface is also available at the terminal level
(FTS-TI), based on standard direct (LOS) or BLOS connectivity
iii. The management of FFT/LTSD and services is done more flexibly and
efficiently corresponding to organizationally deployed elements. E.g.: Company
level FFT data is managed by an information management service
corresponding (and co-located) with the Tactical Command for that Company.
iv. SIOP’s for FFT service/data consumption are (a) at the terminal level (SIOP-
TT) for un-managed data and (b) at the higher55 Tactical Command for
managed FFT data (SIOP-TCP). SIOP’s at the FFT System Level (SCN) are
progressively disappearing.
Services
55
E.g. Platoon, Company, Battalion – depending upon specific requirements.

NATO UNCLASSIFIED
92
i. The FTS Terminal Interoperability Service (FTS-TI) is specified and

implemented. It may subsume some of the functionality of the FTS System
Interoperability Service.
ii. Mission-Level FTS/LTSD management is available through LTIS v2 and LS-
DSS Services.
iii. In addition to the above, an enhancement of the LTIS service is specified and
implemented (LTIS v3) which can be distributed at the terminal level
(battlefield). Local interoperability can achieved also when not connected to the
WAN.
i. Boundary protection is implemented at the edge of the network, e.g. at the
tracking terminal itself, making it possible for the terminal to interconnect to
other systems while maintaining assurance of its own system.
ii. IP encryption devices are able to dynamically set up secure communications to
other IP encryption devices. The devices are implemented at the edge of the
network enabling secure communications directly between terminals.
iii. All information objects are labelled with information that indicates the
assurance requirements for the object.
iv. Information sharing solutions are implemented at the edge of the network, at
least partially. This enables tracking terminals to share information cross
domain without using a central release point.
v. Protected core networking is implemented and extends to the tactical area,
providing the necessary communications and security services for FTS.
Standards
i. A new interface (NFFI v3) is specified to support efficiently the interoperability
services at the terminal level (FTS-TI).
ii. An enhancement of the LTIS Service is specified (LTIS v3), supporting a
distributed LTIS functionality. It makes use of new services such as the
Synchronization (NSF-SY) and the Service management (SMS).
Milestones
The main milestones which have been identified to achieve the implementation of the
EOS-TA are the following:
M 12. NFFI v3 is specified and standardized
M 13. NNEC versions of the other NFFT services (LTIS v3, LS-DDS v2, C2-DDS
v2, LA-DDS v2) are specified and proposed for standardization. They are
based (or subsumed) by available NNEC Core Services.
M 14. Initial implementation of standard Terminal Interface (FTS-TI) using the
NFFI v3 standard and of the NNEC-based services are implemented
At least the key National/NATO FTS supports the LTIS v3 service specification for the
FFT-SM capability.

NATO UNCLASSIFIED
93
4.6 SYNTHESIS
The planned availability of the capabilities in the different roadmap phases and their
description is provided in the next two views.

TN-1322
Figure 21 Roadmap – Capability Phasing (NCV-3)
2009 2010 2011 2012 2013 2014 2015 2016 2017 2018
NFFT CAPABILITY ID 2
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Implementation 4
NATO UNCLASSIFIED
Implem. Milestones: M4, M5, M6 5
NATO UNCLASSIFIED
94
Implementation 10
Implem. Milestones: M10,M11 M12 11
Spec. Milestones: M13, M14 15
Implementation 16
Implem. Milestones: M15, M16 17

Table 11 Roadmap - Capabilities (RM-CAP)
R M -C A P C A P A B IL IT IE S
S tage C a pab. C a p a b il i t y D e s c r i p t io n T e c h n ic a l C h a ra c t e ris t ic s
L ev el
C u rre n t B a s i c F F T I n t e r o p e r a b il i t y
1 H o riz o n t a l I n t e r o p e ra b ilit y t h ro u g h s y s t e m le v e l g a t e w a y s A S I O P : a t e a c h F T S O C C (S C N );
B S I P : N F F I v 1 ( D E a n d d a t a p u s h p r o to c o l s I P 1 / I P 2 )
2 In f o r m a t i o n A s s u r a n c e ( IA ) C H u b - b a s e d ( n o n - s ta n d a r d , s y s t e m - s p e c i f i c )
L O W ( M i s s io n , N a ti o n s ) : F T S , B M S D IA : L O W t o H I G H s e c u r i t y f l o w t h r o u g h a D i o d e
H I G H (M is s io n , N a t io n s , N A T O ) : C 2 I S E S e m i - a u t o m a t e d , o n s ta n d a r d i z e d d a t a a u g m e n ta ti o n ( N A T O )
3 H o r i z o n t a l i n t e r o p e r a b i l i t y : W i th i n L O W S e c u r it y d o m a i n o n l y F Q u a l i ty F a c to r s ( Q F ) n o t a d d r e s s e d /s t a n d a r d i z e d
4 V e r t i c a l i n t e r o p e r a b i l i ty : F r o m F T S t o C 2 I S G P e r f o r m a n c e /C o v e r a g e e x a m p l e s :
5 C r o s s -s e r v ic e in t e ro p . : F F T t o A ir C 2 I S ( f ix e d / d e p lo y e d n o d e s ) N e a r - r e a l - t im e : 5 - 1 0 m in ; C o v e r a g e : 1 :1 0 0 t o 1 :1 0 v e h i c l e
N e a r -T e r m C L -1 A d v a n c e d F F T I n t e r o p e r a b i li t y ( f ix e d F F T - S O A )
1 E n h a n c e m e n t o f th e i n t e r o p e r a b i l i t y s o l u t i o n i n I S A F ( s y s te m - l e v e l g a t e w a y s ) A S IO P : a t e a c h S C N a n d a t th e M C N
B S I P : N F F I v 1 ( D E a n d d a t a p u s h p r o to c o l s I P 1 / I P 2 )
2 H o r i z o n t a l i n t e r o p e r a b i l i t y i n v o l v e s m o s t F T S i n t h e L O W d o m a i n . F T S i n t h e H IG H
d o m a i n c a n b e a l s o p r e s e n t a n d f e d e r a t e d w i th s o m e r e s t r i c ti o n s .
3 T r a c k i n fo r m a t i o n o f w h i t e / g r e y a s s e t s ( e . g . b y N G O ) o p e r a t i n g a t t h e U N C L A S S I F I E D
( o r e q u i v a l e n t l e v e l ) c a n b e i n j e c t e d i n th e N F F T f e d e r a t i o n .
NATO UNCLASSIFIED
4 A c c e s s to F F T m i s s i o n d a t a b y o t h e r c o n s u m e r s ( m a i n l y C 2 a p p l i c a t i o n s ) i s s i g n i f i c a n t l y C S I P : N F F I v 1 ; N F F I v 2 ( i n t e r i m ) , L T IS v 1 ( i n te r i m )
NATO UNCLASSIFIED
im p r o v e d t h r o u g h a s t a n d a r d F F T X M L - S e r v i c e f u n c t io n a l ly
5 R e - d e p l o y a b i li t y o f t h e I S A F N N I s o l u ti o n i n o t h e r p o s s i b l e T h e a t r e o f O p e r a t i o n s a n d D H u b - b a s e d ( s t a n d a r d , d e p l o y a b l e ) - M C N . N A T O / N a t io n L T IS
w i t h o t h e r F o r c e S tr u c t u r e s i s m a d e e a s i e r t h r o u g h a n in i ti a l L T I S f u n c ti o n a li t y .
6 In f o r m a t i o n A s s u r a n c e : M u l t i p l e s e c u r i t y l e v e l s
L O W ( M i s s io n , N a ti o n s ) : F T S , B M S E IA : O n e - w a y B S D t h r o u g h d io d e s a n d I E G ( c a s e A 1 , B 1 )
H I G H (M is s io n , N a t io n s , N A T O ) : F T S , C 2 I S F F u l l y s ta n d a r d i z e d a n d a u t o m a t e d d a t a a u g m e n ta ti o n ( N A T O , N a t i o n s )
7 H o r i z o n t a l i n t e r o p e r a b i l i t y : W i th i n L O W a n d H I G H r e s p e c t iv e l y . L O W - to - H I G H o n l y G Q u a l i ty F a c to r s ( Q F ) n o t a d d r e s s e d /s t a n d a r d i z e d
8 V e r t i c a l i n t e r o p e r a b i l i ty : F F T to C 2 I S ; b a s i c M I P in t e r o p e r a b i l i ty H P e r f o r m a n c e /C o v e r a g e e x a m p l e s :
9 C r o s s - s e r v i c e i n t e r o p . : l i m i t e d F F T to A i r /M a r M a r i t i m e P l a t f o r m s ( S A o n l y ) N e a r - r e a l - t im e : 1 - 1 0 m in ; C o v e r a g e : 1 :1 0 0 t o 1 :1 0 v e h i c l e
M i d -T e r m C L -2 L a n d T a c t ic a l In t e r o p e r a b i l it y ( f i x e d L T I- S O A ) (1)
95
1 H o riz o n t a l in t e r o p e r a b ilit y is e x t e n d e d b e y o n d F F T t o in c lu d e a ls o o t h e r L T I a n d L T D S A S IO P : a t e a c h S C N a n d a t th e M C N (2)
d a t a . T h e s h a r in g a rc h it e c t u r e is a n e n h a n c e m e n t o f t h e o n e f o r F F T .
B S IP : D E F : N F F I v 1 ; N F F I v 2 , L T IS v 2 , L S -D D S
2 H o riz o n t a l in t e r o p e r a b ilit y is e n h a n c e d t o in v o lv e F T S a n d T r a c k in g s y s t e m s in t h e C IA : H i g h a s s u r a n c e B D S I E G C a s e C ) a l l o w l i m it e d H I G H to L O W f lo w
H I G H , L O W a n d U N C L A S S I F I E D d o m a in .
3 N e w B D S t e c h n o l o g y ( I E G C a s e C ) a n d a u g m e n t a t i o n / s a n it i z a t io n s e r v i c e s a l l o w t h e b i - D IA : F u l l c r o s s - d o m a i n s a n i t i z a t io n / a u g m e n t a t i o n
d i r e c ti o n a l i n f o r m a ti o n s h a r i n g a m o n g t h e s e d o m a i n s ( l i m i t e d o n l y b y S e c u r i t y P o l i c i e s )
4 A n in i ti a l f i x e d L T I- S O A ( i n c l u d i n g F F T ) i s i m p l e m e n t e d , i n t e g r a ti n g L T I s e r v i c e s w i t h E M u lt i-h u b ( s t a n d a rd , d e p lo y a b le ) - M C N
a v a i l a b le c o r e i n fr a s t r u c t u r e s e r v i c e s . M o s t o f t h e C 2 s e r v i c e s a r e t h e r e f o r e a b l e t o
c o n s u m e a n d to p r o v i d e a d d e d v a l u e t o L T I s e r v i c e s .
5 M IP - e n a b l e d C 2 S e r v i c e s c a n a l s o s u p p o r t L T I a n d c a n s h a r e a p p r o p r i a te L T I – d e r i v e d F Q u a l i ty F a c to r s ( Q F ) : s ta n d a r d i z e d . I n i t i a l i m p le m e n t a t o n
d a t a i n a M I P F e d e r a t io n .
6 In i ti a l d e p l o y m e n t o f C I D - s ta n d a r d d e v i c e s ( B T I D ) a n d C I D d i s s e m i n a ti o n m a k in g u s e
o f a v a i l a b le L T I . /F F T i n f r a s tr u c t u r e a n d s e r v i c e s
7 C r o s s - s e r v i c e i n t e r o p . : L T I t o A i r / M a r M a r it i m e P l a tf o r m s ( S A o n l y ) G P e r f o r m a n c e /C o v e r a g e e x a m p l e s :
N e a r - r e a l - t im e : 0 . 5 - 5 m i n ; C o v e r a g e : 1 : 5 0 to 1 : 5 v e h i c l e
L o n g - T e rm C L -3 L a n d -o r i e n te d N N E C ( fi x e d a n d m o b i l e L T I -S O A )
1 A c h ie v e m e n t o f m a t u r e , c o m p r e h e n s i v e a n d h i g h q u a l i ty ( e . g . r e a l - t i m e ) l a n d s i tu a t i o n A S I O P : a t e a c h t e r m in a l (T T ), a t T C P / T A C P , a t t h e M C N
a w a r e n e s s , i n te g r a t e d w i th C 2 s e r v ic e s t o e n a b l e s e lf - s y n c h r o n i z a t i o n
2 F u l l n e t w o r k - e n a b le d a n d d i s t r i b u te d i m p l e m e n t a t i o n o f t h e e x te n d e d - N F F T c a p a b i l i t y B S I P : D E F : N F F I v 2 (T C P / T A C P , M C N ) , N F F I v 3 ( T T ) , L T I S v 3 , L S - D S S
c o v e r i n g a l s o a l l a s p e c t s o f L T I ( L T I f i x e d /m o b il e S O A ) .
3 D i r e c t t a c t i c a l l e v e l F F T / L T I i n t e r o p e r a b i l i t y , a l s o w i t h th e o t h e r m o b i l e / f i x e d C O I ’ s a n d C H u b o r p e e r - to - p e e r to p o l o g y ( M C N , S C N , T T )
w i t h i n f r a s tr u c t u r e s e r v i c e s .
D S e c u r it y : m u l ti p le , d y n a m i c d o m a i n s
4 S e c u rit y : E F l e x i b l e B o u n d a r y P r o t e c t i o n S e r v ic e s
M S L , d y n a m ic d o m a in b o u n d a r ie s F F u ll s t a n d a rd iz e d . I n it ia l im p le m e n t a t o n o f Q u a lit y F a c t o r s ( a t le a s t L a n d )
5 F u l l F F T - C ID In te r o p e r a v b i l i t y a t th e te r m i n a l l e v e l G P e r f o r m a n c e /C o v e r a g e e x a m p l e s :
6 R e a l ti m e L T S D i n th e c o c k - p it R e a l - ti m e : 1 - 6 0 s e c ;C o v e r a g e : 1 : 1 v e h i c l e 1 : 1 - 5 d i s m o u n te d s o l d i e r
TN-1322
N o tes
( 1 ) L T I - L a n d T a c ti c a l I n t e r o p e r a b i l i t y
( 2 ) L T S D - L a n d T a c ti c a l S tr u c t u r e d D a t a
NATO UNCLASSIFIED
96
The scope of the envisaged required standards for the roadmap is synthesized in the following table.
Table 12
Roadmap - Standards (Specifications)
RM-STD FFT STANDARD OUTLINE
Stage Reference Description Relationship with other standards
Current NFFI v1 DEF; TCP/IP & UDP push profiles NFFI D-Doc, current operational baseline
Near-Term STANAG 5527 ed1 DEF; TCP/IP & UDP push profiles ratified version - equivalent to NFFI v1
NFFI v2 (interim) Web-service NFFI interface. Request Response, Limited Extension of NFFI v.1 to include (o.a.) a (web) service
Publish and Subscribe interface. Interim version
LTIS v1 LTIS specification : hub configuartion Initial specificaton of LTIS
Mid-Term NFFI v2 final version of NFFI v2 (including e.g. FFTI/LTI metadata)

LTIS v2 LTIS specification - system-level distibution extension to LTIS v1 (distributed architecture). Standard
Publish and Subscribe
LS-DDS Land Structured Data - Data Dissemination Service
Long-Term NFFI v3 Optimized service interface and DEF revision of NFFI for the battle-field level interoperability
LTIS v3 LTIS specification - terminal-level distribution extension to LTIS v2
Please note the following limitations and constraints:

• The table only specifies a general requirement and scope for new interfaces to be
addressed in order to implement the interoperability required to achieve the roadmap
objectives.
• It is not a proposal for specific, well delimited new standards. Version numbers (in
particular for NFFI) are only used as indications for the evolution of a class of
interfaces to be standardized
• It is not meant to be a comprehensive. It is mainly intended as baseline for further
interoperability analysis and standardization activities.

NATO UNCLASSIFIED
97
5. MID-TERM ROADMAP
This section describes and details the implementation approach that is recommended to
achieve the Mid-Term objective as summarized in paragraphs 4.5.1 and 4.5.2 .
In order to provide some specific indication for the evolution of current systems and
standards and to facilitate the planning for compliance testing and verification, Service Interfaces (or
Service Interoperability Profiles - SIP) are outlined and associated to Capability Levels.
This chapter contains for the time being only some considerations that should be
addressed for the Mid-Term roadmap definition. Most of the work has still to be done.
5.1 GENERAL CONSIDERATIONS
5.1.1 Life Cycle and Compliance Testing

This section presents some analysis regarding the Life Cycle of FFT capabilities, within
the wider context of NNEC. It specifies the Quality Factors, as introduced in Section 3.7 and specifies
the measurement and compliance testing approach.
The following aspects should be addressed:
• National Life-Cycle for Force Tracking Services
• Compliance Verification Approach
• Risk Analysis and Mitigation
5.1.2 Compliance measurement and verification

This section will be detailed and completed in a future version of this document.
5.1.2.1 Quality Factors

This section details the definition Quality Factors as introduced in Section 3.7 and
specifies the measurement and compliance testing approach.
This section will be detailed and completed in a future version of this document.
5.1.2.2 FFT Capability Levels and NATO Maturity Levels

This section relates FFT capability levels to the NATO Maturity Levels (NML) as
initially described in [NC3A NNEC ML v1, 2007] to show the contribution of FFT to the wider
NATO capability.
This initial high-level association to FFT Capability Levels (FFT CL) and the NML (as
currently defined in the reference) is the following:
• FFT CL-0 (RM-NOW) corresponds to the introduction of NML-3 (Communicate
and Inform)
• FFT CL-1 (RM-NT) corresponds to an additional maturity step for NML-3
(Communicate and Inform)

NATO UNCLASSIFIED
98
• FFT CL-2 (RM-MT) corresponds to the full implementation of NML-3

(Communicate and Inform)
• FFT CL-3 (RM-LT) corresponds to NML-4 (Collaborate and Plan)
• FFT Final (RM-END) corresponds to the full implementation of NML-5 (Sense and
Respond)
The consolidation and intended use of the NML as maturity model for NATO/National
capabilities is still on-going. In this version of the document is therefore not yet possible to detail this
initial mapping, taking the NML into full account. This section will be detailed and completed in a
future revision of the NFFT.
5.1.2.3 Service and Interoperability Performance Profiles

This section details the profiles that have been introduced in the NTV and specifies a
metric that can be used to measure compliance. This section will be detailed and completed in a future
revision of the NFFT.
5.1.3 Test Plan Template and Guidance

This section outlines a recommended (generic) compliance test and verification plan that
can be used as a baseline for further test planning. It includes guidelines, procedures and requirements
for testing facilities. This section will be detailed and completed in a future revision of the NFFT.
5.2 MID-TERM ROADMAP

This section details and expands the tasks required to achieve the Mid-Term objectives,
i.e. it is a detailed Mid-Term Roadmap specification. This section will be detailed and completed in a
future revision of the NFFT.

NATO UNCLASSIFIED
99
6. CONCLUSIONS AND RECOMMENDATIONS
This document outlines an Architecture and Roadmap of the NATO Friendly Force
Tracking capability towards NNEC which can be used as baseline for an agreed NATO-National
Roadmap.
Stemming from the specific FFT perspective, this evolution would lead to the full
integration of the NFFT capability with the NNEC infrastructure and COI capabilities as they become
available.
The specific objective of this work was to define:
• An Architecture Concept for FFT in NATO, addressing all the main perspectives
with a sufficient level of detail.
• A Vision for the evolution of the NATO FFT Capability (as defined in the
architecture) in the Long-Term (to 2018), split into three phases: Near (2010), Mid
(2014) and Long term (2018).
• The basis for the definition of a Mid-Term Implementation Roadmap.
6.1 CONCLUSION
This document describes an Architecture Concept and Roadmap of the NATO Friendly
Force Tracking capability.
• The A&R analysis is a good basis to specify, harmonize standards and plan the
implementation of capabilities that need to interoperate regarding FFT (Near Term) and
Land Tactical Services (Mid to Long Term).
• Available work on NATO FFT specification and on e.g. applicable architectures, related
NATO/National capabilities and roadmaps has been considered to the max extent
possible. The NFFT Architecture Concept and Roadmap is consistent with these other
documents as far as they have been identified and obtained. But important sources or new
document versions might have been overlooked and might need to be considered.
• The chosen COI-capability driven approach allows continuing the ISAF FFT NNI focus
towards NNEC, integrating with other (Core or COI) capabilities as are being specified,
planned and implemented. The advantage of such approach is its focus and limited scope,
making it easy to relate the capability levels to operational benefits.
• The limitations and constraints of this version of the A&R need to be recognized. It is to
be maintained as a living document.
Some specific limitations in this version are the following:
• Most aspects in the Architecture Concept are based on what has already been defined
and documented and are not therefore necessarily consistent, complete or equally
balanced. Constraints and assumptions on the evolution of related capabilities (and
other relevant external factors) have been considered as an External Roadmap and
taken into account for the NFFT roadmap. (Chapter 2)

NATO UNCLASSIFIED
100
• The available source documents have been used to the extent possible and some
assumptions are made and described for what was not included and required. The
time and resources available for this activity was the key limiting factor for the
extent of the breadth and depth of the analysis. Some parts are likely less refined
than others.
• The Architecture Concept definition has been analyzed from different perspectives
and represented following the NATO Architecture Framework (NAF) as guideline
(Chapter 3). It is not meant to be a complete Reference Architecture for FFT in
NATO. This is why it has been named “Architecture Concept”.
• The Planning aspects for the Mid-Term implementation of the Roadmap (Chapter 5)
have not yet been analyzed and specified yet. This could address, among others :
- A detailed Mid-Term Roadmap
- A refined definition of compliance levels, taking into account the Quality
Factors (on one end of the detail and granularity spectrum) and the NATO
Maturity Levels (on the other).
- Compliance Testing Plan templates and guidelines and requirements on Testing
processes and facilities
- Relationship among FFT Compliance Testing and different NATO National
Validation, Testing and Certification activities.
6.2 RECOMMENDATIONS
With the mentioned limitations and constraints, this document is believed a good baseline
to eventually achieve a version that is agreed by NATO and the Nations.
More work, involving all NATO and National stakeholders and subject matter experts is
required, e.g.
• To extensively review and revise and eventually agree this baseline. All the NATO
views of the architecture concept can be involved.
• To consider further inputs (if available) from NATO and Nations, e.g.:
o NATO Force Goals
o NISP vers.2
o NATO Roadmaps on other related capabilities
o National Roadmaps.
• To extend and/or detail other aspects as required
• To decide and specify the Mid Term Roadmap (outside the scope of this version).
In addition, some R&D, experimentation and standardization activities could already be
started, e.g.
• To refine the definition of interfaces and standards that have been outlined as
required
• To further analyze some technical aspects in order to reduce the implementation’
risks

NATO UNCLASSIFIED
101
This could lead to the revision of the Program of Work for NATO common funded (e.g.
NC3A) or Nation R&D and experimentation activities.
Summing up, the main recommendations for NATO and the Nations are the following:
1. Review of this document within the NC3B SC5/SC7 FFT AHWG
1. Revision by NC3A according to this review
2. Approval by the FFT AHWG and submission to the NC3B for endorsement
3. Consideration of specific issues (e.g. experimentation for risk reduction, initiation of
harmonization and standardization) within the NC3A (and National) Programs Of
Work for R&D and Experimentation.
4. Definition by the FFT AHWG of the scope of a detailed NFFT Mid-Term Roadmap,
to be drafted by the NC3A as baseline for further staffing.

NATO UNCLASSIFIED
102

NATO UNCLASSIFIED
103
REFERENCES
[ACT NNEC-DS, 2009]:

Allied Command Transformation, “NNEC Data Strategy”, Draft [AC/322(SC/1)N(2008)0053 (INV)],
ACT, 2 February 2009 (NATO Unclassified).
[ACT NTDES-RM, 2007]:
Allied Command Transformation, “NATO Tactical Data Enterprise Services Roadmap” (Version 0.2),
HQ SACT, 14 June 2007 (NATO Unclassified).
[BiSC FFT-CONC, 2008]:
Allied Command Operations and Allied Command Transformation, “Bi-SC Concept for NATO
Friendly Force Tracking of Ground Forces”, Draft [AC/322(SC/7)N(2008)0011], 31 Oct 2008 (NATO
Restricted).
[MIP Web-Site, 2007]:
Multilateral Interoperability Program Web-Site, http://www.mip-site.org, cited March 2007.
[MIP, MIPS v 3.4 D, 2007]:
Multilateral Interoperability Program, MIP Integrated Program Schedule (v.3.4 DRAFT), 1 December
2007
[NC3A AEM, 2007]:
NATO Consultation, Command and Control Agency “Architecture Engineering Methodology”, in
North Atlantic Council document AC/322(SC/1-WG/1)N(2007)0004, NATO C3 Board, “NATO
Architecture Framework (NAF) Version 3 ([NC3B NAF v3, 2007] in this reference list), Annex B
(aka Appendix 9 to Annex 3), “Architecture Methodologies”, Section B.6, “NC3A/AEM”, NAC,
Brussels, Belgium, 31 August 2007 (NATO/EAPC Unclassified).
[NC3A NCRA ed.1, in prep.]:
NATO Consultation, Command and Control Agency, “NII Communications Reference Architecture”
Edition 1, R. van Engelshoven, NC3A The Hague, Netherlands, in preparation (NATO Unclassified).
[NC3A NNEC FS vol. I, 2005]:
NATO Consultation, Command and Control Agency document, NATO Network-Enabled Capability
(NNEC) Feasibility Study (FS) Volume I: “Overview of NATO Network-Centric Operational Needs
and Implications for the Development of Net-Centric Solutions”, P. Bartolomasi, T. Buckman,
A. Campbell, J. Grainger, J. Mahaffey, R. Marchand, O. Kruidhof, C. Shawcross, K. Veum, produced
by NC3A Integrated Programme Team 1 (Architectures for Network-Enabled Capabilities) for the
NNEC Steering Group, NC3A The Hague, Netherlands, October 2005 (NATO Unclassified).
[NC3A NNEC FS vol. II, 2005]:
NATO Consultation, Command and Control Agency document, NATO Network-Enabled Capability
(NNEC) Feasibility Study (FS) Volume II: “Detailed Report Covering a Strategy and Roadmap for
Realizing an NNEC Networking and Information Infrastructure (NII)”, version 2.0, M. Booth,
T. Buckman, J. Busch, B. Caplan, B. Christiansen, R. van Engelshoven, K. Eckstein, G. Hallingstad,
T. Halmai, P. Howland, V. Rodriguez-Herola, D. Kallgren, S. Onganer, R. Porta, S. Shawcross,
P. Szczucki, K. Veum, produced by the NC3A Integrated Programme Team 1 (Architectures for
Network-Enabled Capabilities) for the NNEC Steering Group, NC3A The Hague, Netherlands,
October 2005 (NATO Unclassified).
[NC3A NNEC ML v1, 2007]:
NATO Consultation, Command and Control Agency, “Report on the development of the initial NNEC
Maturity Levels and its application”, version 1.0, document NC3A-BE/CIS/IPT-1/07/001, NC3A
Brussels, Belgium, February 2007 (NATO/EAPC Unclassified).

NATO UNCLASSIFIED
104
REFERENCES (continued)
[NC3A OA v2.5, 2005]:

NATO Consultation, Command and Control Agency, “NATO Overarching Architecture”, version 2.5,
document NC3A-BE/CISD/IPT-1/05/24, NC3A Brussels, Belgium, December 2005 (NATO
Restricted).
[NC3A IEG-RM, 2008]:
NATO Consultation, Command and Control Agency Doc. Num 2666, “Information exchange
Gateway Roadmap”, O. Hvinden, A. Murdoch, S. Kuene, M. Diepstraten, L. Schenkels, M. Booth,
NC3A The Hague, Netherlands, November 2008 (NATO Unclassified) (TO BE PUBLISHED).
[NC3A TN-1182, 2006]:
NATO Consultation, Command and Control Agency Technical Note 1182, “Interoperability of
Friendly Force Tracking Systems in Coalition Operations”, R. Porta, G. Hallingstad, NC3A The
Hague, Netherlands, September 2006 (NATO Unclassified).
[NC3A TN-1205, in prep.]:
NATO Consultation, Command and Control Agency Technical Note 1205, “NII-Maturity Levels for
Communication Services” (provisional title), R.J. van Engelshoven, T. Halmai, A. van den Boogaart,
NC3A The Hague, Netherlands, in preparation (NATO Unclassified).
[NC3A TN-1241, 2007]:
NATO Consultation, Command and Control Agency Technical Note 1241, “Protected Core
Networking – Initial Concept Description”, G. Hallingstad, S. Oudkerk, NC3A The Hague,
Netherlands, March 2007 (NATO Unclassified).
[NC3A TN-1246]:
NATO Consultation, Command and Control Agency Technical Note 1246, “Wireless
Communications Architecture (Land): Scenarios, Requirements and Operational View”, P. Albano, F.
Suzuki, M. Street, NC3A The Hague, Netherlands, September 2008 (NATO Restricted).
[NC3B C3IRO, 2007]:
NATO C3 Board, “C3 Interoperability Requirements for Operations”, AC/322-D(2007)0029, NC3B,
Brussels, Belgium, 6 July 2007 (NATO Restricted).
[NC3B NAF v3, 2007]:
NATO C3 Board, “NATO Architecture Framework (NAF) Version 3”, North Atlantic Council
document AC/322(SC/1-WG/1)N(2007)0004, NAC, Brussels, Belgium, 31 August 2007
(NATO/EAPC Unclassified).
[NC3B NFFI-DDOC, 2006]:
NATO Command and Control Board (NC3B), “Interim NATO Friendly Force Information (NFFI)
Standard for interoperability of Force Tracking Systems”. [AC/322(SC/5)N(2006)0025)], NC3B
Brussels, Belgium, December 2006 (NATO Unclassified).
[US DISA GCMP, 2006]:
US Defense Information Systems Agency, “Global Information Grid Master Plan (GCMP)”, version
5.25b, DISA, US Department of Defense, April 2006 (US For Official Use Only).

NATO UNCLASSIFIED
105
ABBREVIATIONS
ABCC Airborne Command Centre\

ACC Air Component Command
ACCS Air Command and Control System
ACO [NATO] Allied Command Operation
ACT [NATO] Allied Command Transformation
AEM Architecture Engineering Methodology
AHWG Ad Hoc Working Group
AIS Allied Information System
AOR Area of Responsibility
BDE Brigade
BFSA Blue Force Tracking Situation Awareness
BFT Blue Force Tracking (synonymous to FFT)
BG Battle Group
Bi-SC Bi-Strategic Command (ACO and ACT)
BiSC-AIS Bi-Strategic Alliance Information System
BLOS Beyond Line Of Sight
BMS Battle Management System Service
BTN Battalion
C2 Command and Control

C2IS Command and Control and Information System (or Services)
C3 Command, Communication and Consultation
C31R C3 (Command and Consultation) Information Requirements
CAOC Combined Air Operations Centre
CID Combat Identification
CIS Communication and Information System
CL Capability Level
CMM Capability Maturity Model
COI Community of Interest
COMM Communication
COMSEC Communication Security
COP Common Operational Picture
COTM Communication On the Move
CP Capability Package
CR Capability Requirement
CWID Coalition Warrior Interoperability Demonstration
DDS Data Dissemination Service

DEF Data Exchange Format
DJTF Deployed Joint Task Force Command
DOTMLPF Doctrine, Organization, Training, Material, Leadership, Personnel, Facilities
EOS End of Stage

EPOW Experimental Program of Work
FFT Friendly Force Tracking

NATO UNCLASSIFIED
106
ABBREVIATIONS (continued)
FMN Federated Mission Network

FOC Final Operational Capability
FOUO For Official Use Only
FTS Force Tracking System/Service
HF High Frequency
HQ Headquarters
HQ SACT HQ=headquarters
IA Information Assurance
IED Improvised Explosive Device
IEG Information Exchange Gateway
IES Information Exchange Standard
IFTS ISAF Force Tracking System
IIS Integration Information Services (s)
IOC Initial Operational Capability
IP Internet Protocol
ISAF International Security Assistance Force
ISSC Information Services Sub-Committee
JC3IEDM Joint Command, Control and Consultation Information Exchange Data Model
JFC Joint Force Command
LC2IS Land C2 Information System (specific program)
LCC Land Component Commander
LCCIS Land C2 Information System (generic term)
LOS Line of Sight
LTIS Land Track/Tactical Interoperability Service
LTSD Land Tactical Structured Data
MCN Mission Control Node

MHPS Message Handling and Processing Service
MIP Multilateral Interoperability Program
MMR Minimum Military Requirement
MSL Multi Security Level
MTF Message Text Format
NAF NATO Architecture Framework

NATO VMF NATO Variable Message Format
NAV NATO All View
NC3A NATO C3 Agency
NC3B NATO C3 Board
NC3O NATO C3 Organization
NCES Network Core Enterprise Services
NCRL NATO Capability Requirement List
NCS NATO Command Structure
NCV NATO Capability View
NFFI NATO Friendly Force Information
NFFI DEF NFFI Data Exchange Format
NFFT NATO Friendly Force Tracking

NATO UNCLASSIFIED
107
NFFT-RM NATO Friendly Force Tracking Roadmap

NFS NATO Force Structure
NGCS NATO General Purpose Segment Communications System
NID NATO Interoperability Directive
NII Network and Information Infrastructure
NINE NII IP Network Encryption
NML NATO Maturity Level
NNEC NATO Network Enabled Capability
NNI NATO-Nation Interoperability
NOV NATO Operational View
NPV NATO Program View
NRF NATO Response Force
NSEV NATO FFT Security View
NSF NNEC Service Framework
NSIP NATO Strategic Investment Program
NSML NATO System Maturity Level
NSOV NATO Service-Oriented View
NSV NATO System View
NT Near Term
NTDES NATO Tactical Data Enterprise Service(s)
NTV NATO Technical View
OA Operational Architecture
OCC Operational Control Center
OIR Operational Information Requirement
PCN Protected Core Networking

POW Program Of Work
QoI Quality of Information

QoO Quality of Operation
QoS Quality of Service
OPC Operational Command
QF Quality Factor
QW Quick Win
RM Road Map
RM-LT Long Term RM
RM-MT Mid Term RM
RM-NT Near Term RM
SA Situation Awareness
SACT Supreme Allied Command Transformation
SATCOM Satellite Communication
SCIP Secure Communications Interoperability Protocol
SEI Software Engineering Institute
SIOP Service Interoperability Point
SIP Service Interoperability Profile

NATO UNCLASSIFIED
108
SMS Service Management Service

SOA Service Oriented Architecture
SOP Standard Operating Procedure
SPOW Scientific Program of Work
STANAG NATO Standardization Agreement
TA Target Architecture
TACNW Tactical Communication (Network)
TACOM Tactical Communication (Network)
TBD To Be Defined
TCP Tactical Command Post
TDL Tactical Data Link
TI Target Identification
UAV Un-manned Aerial Vehicles

UGS Un-manned Ground Sensor
UHF Ultra High Frequency
US BFT COI IES US BFT COI Information Exchange Standard
US GCMP US Global Information Grid Convergence Management Plan
VHF Very High Frequency
WAN Wide Area Network

WCOA Wireless Communication Operational Architecture
WLESS Wireless
WSI Web Service Interface
XML Extensible Mark-up Language

NATO FFT Arch Concept and Roadmap (NU)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NATO FFT Arch Concept and Roadmap (NU)

Uploaded by

Copyright:

Available Formats

DRAFT Technical Note 1322

NATO FRIENDLY FORCE TRACKING

With reference to NATO Documents C-M(2002)49 and AC/322-D/1, this

1. The recipient NATO Government agrees to use its best endeavours to

2. If the technical information was originally released to the Agency by a

NATO FRIENDLY FORCE TRACKING

Keywords: Friendly Force Tracking, Blue Force Tracking, Architecture, Roadmap

Luigi Bella, Director

NATO Consultation, Command and Control Agency This document consists

0.2 RELEVANT STANDARDS AND TECHNOLOGY

NATO UNCLASSIFIED DRAFT TN-1322

AREA RESP n. CAPABILITIES, STANDARDS & TECHNOLOGY AVAILABILITY

Information Integration NC3B/SC-5

Cross-Domain Gateways (full scope) Long-Term (2018)

(final inc. RT data dissemination) Final: Long-Term (2018) (1)

0.3 ARCHITECTURE CONCEPT

0.3.1 Operational View

DRAFT TN-1322 NATO UNCLASSIFIED

Limitations and Constraints

NATO UNCLASSIFIED DRAFT TN-1322

3) Maritime force protection

A more detailed definition of the operational requirements can be achieved through

0.3.2 Capability View

DRAFT TN-1322 NATO UNCLASSIFIED

0.3.3 Service-Oriented View

NATO UNCLASSIFIED DRAFT TN-1322

Services can be defined from a user perspective (“User Services”) or from

An initial description of each of these services is provided in NSOV-2A. A detailed

0.3.4 System View

DRAFT TN-1322 NATO UNCLASSIFIED

NATO UNCLASSIFIED DRAFT TN-1322

BMS Battle Management System

Air C2IS FTS FTS

DRAFT TN-1322 NATO UNCLASSIFIED

C2-DDS C2 Data Dissemination Service supports the dissemination (and related

0.3.5 Technical View

0.4 VISION (LONG-TERM ROADMAP)

NATO UNCLASSIFIED DRAFT TN-1322

Capability Level 1 (CL-1) 1

Specification and standardization 2

Spec. Milestones: M1, M2, M3 3

Implem. Milestones: M4, M5, M6 5

Capability Level 2 (CL-2) 6

Research & Development 7

Specification and standardization 8

Spec. Milestones: M7, M8, M9 9

Implem. Milestones: M10,M11 M12 11

Capability Level 3 (CL-3) 12

Research & Development 13

Specification and standardization 14

Spec. Milestones: M13, M14 15

Implem. Milestones: M15, M16 17

0.4.1 Near-Term (2010)

DRAFT TN-1322 NATO UNCLASSIFIED

NATO UNCLASSIFIED DRAFT TN-1322

i. To extend the RM-NT solution beyond FFT, to include other location--focused

DRAFT TN-1322 NATO UNCLASSIFIED

4) An initial fixed/deployable4 LTI-SOA (including FFT) is implemented,

NATO UNCLASSIFIED DRAFT TN-1322

DRAFT TN-1322 NATO UNCLASSIFIED

The following figure (RM-LT) provides a representation of the architecture (system

The new SIP’s needed for this capability level are:

0.6 CONCLUSIONS AND RECOMMENDATIONS

NATO UNCLASSIFIED DRAFT TN-1322