ADatP-36 EDA V2 E

NATO UNCLASSIFIED
Releasable to Interoperability Platform
NATO STANDARD
ADatP-36
FRIENDLY FORCE TRACKING

SYSTEMS (FFTS) INTEROPERABILITY
Edition A Version 2
SEPTEMBER 2021
NORTH ATLANTIC TREATY ORGANIZATION
ALLIED DATA PUBLICATION
Published by the
NATO STANDARDIZATION OFFICE (NSO)
© NATO/OTAN
NATO UNCLASSIFIED
NATO UNCLASSIFIED
INTENTIONALLY BLANK
NATO UNCLASSIFIED
NATO UNCLASSIFIED
INTENTIONALLY BLANK
NATO UNCLASSIFIED
NATO UNCLASSIFIED
Releasable to IP
ADatP-36
RESERVED FOR NATO LETTER OF PROMULGATION
I Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
INTENTIONALLY BLANK
II Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
RECORD OF RESERVATIONS
CHAPTER RECORD OF RESERVATION BY NATIONS
Note: The reservations listed on this page include only those that were recorded at
time of promulgation and may not be complete. Refer to the NATO Standardization
Document Database for the complete list of existing reservations.
III Edition A Version 2

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
INTENTIONALLY BLANK
IV Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
RECORD OF SPECIFIC RESERVATIONS
[nation] [detail of reservation]
ALB This STANAG will be implemented after specification of the operational requirement and allocation of
resources in the mid-term procurement plan.
BEL Bel Defence will implement (in a first phase) only for LAND applications.
ITA Italian Navy will implement this STANAG in systems that are now still under development and, at this
time, there is no predictable date of their deployment.
PRT Portuguese Army does not have the capability to verify all requisites and specifications required by
this STANAG, namely to implement the Interface Service Interoperability Profile 3 (SIP 3).
Note: The reservations listed on this page include only those that were recorded at time of
promulgation and may not be complete. Refer to the NATO Standardization Document Database for
the complete list of existing reservations.
V Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
INTENTIONALLY BLANK
VI Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
TABLE OF CONTENTS
Introduction ........................................................................................................................... 1
1. Purpose and Scope of the Document ....................................................................... 1
2. Terms, Definitions and Conventions ......................................................................... 1
3. Friendly Force Tracking (FFT) .................................................................................. 2
FFT Concept ..................................................................................................... 2
Reporting Structure ........................................................................................... 3
FFT Report details ............................................................................................ 4
Security of Information ...................................................................................... 5
Friendly Force Information Message Format ..................................................... 6
Update Rates .................................................................................................... 6
Unique Terminal Identification (UTID) ............................................................... 6
Other Identification Data ................................................................................... 6
Processing of FFI Data ..................................................................................... 6
4. Document Format .................................................................................................... 7
Overview of Annexes ........................................................................................ 8
ANNEX A – Technical Specification – Data Bearer and Routing Layers .......................... A-1
FFI Interface Protocol (IP) / Service Interoperability Profile (SIP) Overview ....... A-1
Interface Protocol 1 (IP1) ................................................................................... A-1
IP1: Link Layer ........................................................................................... A-2
IP1: Internet Layer ...................................................................................... A-2
IP1: Transport Layer ................................................................................... A-2
IP1: Application Layer ................................................................................. A-3
Interface Protocol 2 (IP2) ................................................................................... A-3
IP2: Link Layer ........................................................................................... A-4
IP2: Internet Layer ...................................................................................... A-4
IP2: Transport Layer ................................................................................... A-4
IP2: Application Layer ................................................................................. A-4
FFI Data Compression....................................................................................... A-5
FFI IP1/IP2 Header Specification ....................................................................... A-6
FFI IP1/IP2 Header Introduction ................................................................. A-6
FFI IP1/IP2 Header Elements Specification ................................................ A-7
Modifications of IP1/IP2 Header ............................................................... A-13
Example .......................................................................................................... A-13
VII Edition A Version 2

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
Interface Protocol Implementation ................................................................... A-14

ANNEX B – Technical Specification – Data Element Layer.............................................. B-1
Field usage and processing ............................................................................... B-1
Interpretation and processing of NILLED fields ................................................ B-10
ANNEX C – Technical Specification – Message Structure Layer ..................................... C-1
FFI Payload ....................................................................................................... C-1
FFI Message Implementation ............................................................................ C-2
XML Message Validity ................................................................................ C-2
Efficiency of XML File Preparation .............................................................. C-2
Compounding Multiple Track Updates per Message................................... C-3
Examples of an FFI Message Text Format ........................................................ C-4
Message Models ............................................................................................... C-9
ANNEX D – Technical Specification – Business Rules .................................................... D-1
Use of APP-6 Symbol Coding ............................................................................ D-1
Mandatory Symbol Fields ........................................................................... D-2
Default Symbol Fields ................................................................................. D-3
Unique Terminal Identification (UTID) ................................................................ D-3
Alert/Emergency ................................................................................................ D-4
Time Reference ................................................................................................. D-5
Forwarding Tracks ............................................................................................. D-5
Data Compression Rules ................................................................................... D-6
Augmentation and Sanitization Specification ..................................................... D-6
Definition .................................................................................................... D-6
Reasons for Augmentation and Sanitization ............................................... D-7
Place for Augmentation and Sanitization .................................................... D-7
Augmentable Information............................................................................ D-8
FFI Track Aging ................................................................................................. D-9
Track Aging Definition ................................................................................ D-9
FFI Track Aging Categories ........................................................................ D-9
Duplicate and Future Tracks ..................................................................... D-10
Specific Rules for an FFT Hub ......................................................................... D-11
Specific Rules for an FFT Proxy ................................................................... D-11
ANNEX E – Technical Specification – Web Services – SIP3 ........................................... E-1
Terminology....................................................................................................... E-1
SIP3 .................................................................................................................. E-2
SIP3 Architecture........................................................................................ E-2
VIII Edition A Version 2

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
SIP3 API ..................................................................................................... E-5

Additional Arrangements .......................................................................... E-16
SIP3 Normative Definition......................................................................... E-20
NFFI-13 Query Language Technical Specification ........................................... E-25
Introduction............................................................................................... E-25
SIP3 Filter Language ................................................................................ E-25
Query Language Standard Error Handling ................................................ E-34
NFFI Query Normative Definition .............................................................. E-36
SIP3 Profiling for the FFI MTF Messages ........................................................ E-40
Introduction............................................................................................... E-40
General Rules .......................................................................................... E-41
Pull Mode ................................................................................................. E-41
Push Mode ............................................................................................... E-43
ANNEX F – Technical Specification – Security Cross Domain ......................................... F-1
Security Marking ................................................................................................ F-1
Level 1 ........................................................................................................ F-2
Level 2 ........................................................................................................ F-2
Level 3 ........................................................................................................ F-2
Augmentation Data Classification ...................................................................... F-3
ANNEX G – Technical Specification – Operational Cross-Domain...................................G-1
Mapping FFI to Fixed-Field Message Formats ...................................................G-1
Mapping Decisions and Implementation ............................................................G-1
Mapping Language Constructs ..........................................................................G-1
Backward Compatibility Mapping from NFFI to FFI MTF ....................................G-3
Backward Compatibility Mapping from FFI MTF to NFFI ..................................G-22
LINK 16 Mapping .............................................................................................G-39
ANNEX H – Technical Specification – WEB SERVICES - WSMP FFT Profile ................. H-1
Introduction........................................................................................................ H-1
Audience .................................................................................................... H-1
Namespaces .............................................................................................. H-1
Goal and requirements ...................................................................................... H-2
Goals .......................................................................................................... H-2
Addressed Requirements ........................................................................... H-2
Non-goals ................................................................................................... H-3
WSMP Profile for FFT........................................................................................ H-3
WS-Topic Requirements............................................................................. H-3
IX Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
Data Dialect Requirements ......................................................................... H-4

FFT messages binding ............................................................................... H-4
Metadata Requirements ............................................................................. H-4
Filter Requirements .................................................................................. H-11
Exchange Specific Requirements ............................................................. H-12
ANNEX I – Technical Specification – FFT Filter Language ............................................... I-1
Introduction......................................................................................................... I-1
Goals and Requirements .................................................................................... I-1
Goals ........................................................................................................... I-1
Addressed Requirements ............................................................................ I-1
Non-goals .................................................................................................... I-1
FFT Filter Language ........................................................................................... I-2
Source filter ................................................................................................. I-2
Geographic area filter .................................................................................. I-3
Timeframe filter ........................................................................................... I-5
Normative schema .............................................................................................. I-7
ANNEX J – List of References ..........................................................................................J-1
ANNEX K – Lexicon......................................................................................................... K-1
Acronyms and Abbreviations ............................................................................. K-1
Terms and Definitions ........................................................................................ K-2
ANNEX L – Revision History ............................................................................................ L-1
X Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
LIST OF FIGURES
Figure 1 FFT Generic Network Structure ................................................................................ 3
Figure 2 STANAG Transformation Framework Layers ........................................................... 7
Figure 3 Interface Protocol 1 (IP1)....................................................................................... A-2
Figure 4 Interface Protocol 2 (IP2)....................................................................................... A-4
Figure 5 FFI IP1/IP2 Header and FFI Payload..................................................................... A-6
Figure 6 FFI IP1/IP2 Header Definition ................................................................................ A-7
Figure 7 NFFI Message Data Model .................................................................................... C-9
Figure 8 FFI MTF Message Model .................................................................................... C-10
Figure 9 "Pull Data" Mode ................................................................................................... E-3
Figure 10 "Push Data" Mode ............................................................................................... E-4
Figure 11 SIP3 Service Diagram ......................................................................................... E-5
Figure 12 Pull Request Message schema ........................................................................... E-7
Figure 13 Decoupled Response Message ........................................................................... E-8
Figure 14 SIP3SubscriptionParameter Element ................................................................ E-12
Figure 15 NFFIFilter Structure ........................................................................................... E-27
Figure 16 ReqResFilter Structure ...................................................................................... E-33
Figure 17 FFI Classification ................................................................................................. F-2
Figure 18 Filter element in FFT Filter schema ...................................................................... I-2
Figure 19 Source filter element in FFT Filter schema ........................................................... I-3
Figure 20 Geographic area filter element in FFT Filter schema ............................................ I-4
Figure 21 Boundingbox type in FFT Filter schema ............................................................... I-4
Figure 22 Proximity type in FFT Filter schema ..................................................................... I-5
Figure 23 Timeframe element in FFT Filter schema ............................................................. I-6
XI Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
LIST OF TABLES
Table 1 Sample FFI IP1/IP2 Header.................................................................................. A-14
Table 2 FFI IP1/IP2 Header (Binary Format) ..................................................................... A-14
Table 3 FFI IP1/IP2 Header (Hexadecimal Format) ........................................................... A-14
Table 4 XML (Message/Field) Clarification .......................................................................... B-2
Table 5 Interpretation and processing of nilled fields ......................................................... B-10
Table 6 Structure of APP-6(A)/APP-6(B) Symbol ID code ................................................... D-2
Table 7 Emergency Conditions ........................................................................................... D-5
Table 8 Principle Structure of Augmentation Data ............................................................... D-7
Table 9 Track Augmentation Information ............................................................................. D-8
Table 10 SIP3 Namespaces ................................................................................................ E-2
Table 11 InvalidSubscription Fault Code ........................................................................... E-16
Table 12 Classification of Augmented Track ....................................................................... F-3
Table 13 Mapping language constructs ...............................................................................G-1
Table 14 NFFI to FFI Mapping ............................................................................................G-4
Table 15 FFI MTF to NFFI Mapping ..................................................................................G-23
Table 16 Identifying attributes of an FFT track...................................................................... I-3
XII Edition A Version 2

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
LIST OF XML CODES

XML-Code 1 Example of Blue Dot Minimum FFI XML-MTF Message ................................. C-4
XML-Code 2 Example of a Complete FFI XML-MTF Message ............................................ C-5
XML-Code 3 Pull NFFI Track Data Request Message......................................................... E-6
XML-Code 4 Pull NFFI Message ......................................................................................... E-8
XML-Code 5 Subscription Example ................................................................................... E-11
XML-Code 8 FilterType XSD Fragment ............................................................................. E-15
XML-Code 9 DeliveryType XSD Fragment ........................................................................ E-15
XML-Code 10 Example Fault Message ............................................................................. E-18
XML-Code 11 Normative "compressionAlgs.xsd" .............................................................. E-20
XML-Code 12 Normative “SIP3.xsd” ................................................................................. E-20
XML-Code 13 Normative “SIP3_Definitions.wsdl” ............................................................. E-21
XML-Code 14 Normative “SIP3_Service_Eventing.wsdl” .................................................. E-22
XML-Code 15 Normative “SIP3_delivery_decoupled_batched.xsd”................................... E-23
XML-Code 16 Normative “errorCodes.xsd” ....................................................................... E-23
XML-Code 17 Normative “SIP3_Service_TracksPush.wsdl”.............................................. E-24
XML-Code 18 Normative “SIP3_Service_DecoupledReqRes.wsdl” ................................... E-24
XML-Code 19 XPath Input NFFI Message ........................................................................ E-30
XML-Code 20 XPath Result NFFI Message ...................................................................... E-31
XML-Code 21 Normative “nffi_13_Query.xsd” ................................................................... E-36
XML-Code 22 Normative “NFFI_13_ReqResFilter.xsd” ..................................................... E-40
XML-Code 23 SIP3 data request message ....................................................................... E-42
XML-Code 24 Uncompressed response message example .............................................. E-43
XML-Code 25 Compressed response message example .................................................. E-43
XML-Code 26 Example of track message to be compressed ............................................ E-43
XML-Code 27 Example of a SIP3 subscription message ................................................... E-44
XML-Code 28 WSMP message containing single FFT Message with 1 track. ..................... H-7
XML-Code 29 Normative FFT filtering language schema ..................................................... I-8
XIII Edition A Version 2

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
INTENTIONALLY BLANK
XIV Edition A Version 2

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
INTRODUCTION
In modern warfare, the knowledge of the exact geographical positions of own forces down to
the level of individual soldiers has become a necessity. In areas where allied forces operate in
a geographically shared area and especially within the dynamic environment of asymmetric
and urban warfare as well in situations where immediate decisions have to be taken, the
tracking of own forces is essential for automatic provision of horizontal and vertical situational
awareness in order to prevent fratricide.
Nations have procured various friendly force tracking and command and control systems with
differing capabilities. Some systems only provide position reports with corresponding
timestamps whereby others, besides position reporting of own forces, allow the full array of
command and control. Differences in type, format and content of the exchanged information as
well as technical variances of the used protocols prevent the direct exchange of positional and
other information of friendly forces between the different national systems. In order to overcome
this essential war fighting deficiency ADatP-36 outlines the conceptual, procedural and
technical details for allowing exchange of information amongst the array of Friendly Force
Tracking Systems (FFTS) via an agreed interface.
1. PURPOSE AND SCOPE OF THE DOCUMENT

In any national, multinational, coalition and NATO operation, all authoritative commanders
require situational awareness about the precise disposition of all friendly forces at all times with
the highest possible accuracy. This document outlines the basic technical and operational
principles for using FFTS in an environment, where differing FFTS and FFTS-capable C2
Systems operate together by means of exchanging Friendly Force Information (FFI) messages
listed in the NATO Message Catalogue (APP-11) [Ref 14]. It also provides the technical
standard for exchanging FFI messages. The detailed FFI-message text format (MTF) is
contained in APP-11(D)(1) [Ref 14]. In addition to the message format, this document defines
mapping details for allowing data transfer between differing standards (i.e., FFI MTF to NFFI).
This standard does not cover the system-specific protocols that connect Friendly Force
Tracking Terminals with their connected Gateways.
2. TERMS, DEFINITIONS AND CONVENTIONS

A list of acronyms and a list of terms and definitions are included in ANNEX K.
The FFI message format is based on the formatting language of ADatP-3(A) [Ref 13]. Message
formats that adhere to ADatP-3(A) are called Message Text Formats (MTF). Therefore, the FFI
message format is called “FFI MTF” to distinguish it from the previous NATO Friendly Force
Information (NFFI) message format, which was based on an extensible markup language
(XML) schema definition, another formatting language. An ADatP-3(A) message format is also
documented in an XML schema, but with some extensions to regular XML. ADatP-3(A)
compliant message formats are regularly published in APP-11, the NATO Message Catalogue,
which is the authoritative source of message specifications in NATO.
This document expresses specific parts of the standard in a declarative way. These are called
Business Rules (BR). BR are numbered for unique reference purposes and highlighted in this
document for easy retrieval. They use specific vocabulary based on IETF RFC 2119 [Ref 8] to
express mandatory and optional/conditional parts of the standard.
BR-Example-1. ** Example ** Declarative Business Rule text. ** Example **
1 Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD
NOT, RECOMMENDED, MAY and OPTIONAL in this standard are to be interpreted as
described in IETF RFC 2119 [Ref 8] and to be used as described in IETF RFC 8174 [Ref 31].
3. FRIENDLY FORCE TRACKING (FFT)

FFT CONCEPT
Friendly Force Tracking (FFT) is the capability to report and monitor the location of Friendly
Forces and to support Command and Control on those forces, also called FFT and formerly
called Blue Force Tracking. This information is introduced to the tactical and operational
pictures via a coordinated flow of information by means of available communication circuits.
The aim is to enhance situational awareness and combat effectiveness by providing the
location of friendly forces.
Positions of maritime and air forces are reported by several different systems (e.g. radar, IFF,
tactical data links), which are normally not available to ground forces at either vehicle or
individual level. In order to mitigate this vital deficiency, FFTS have been introduced to the
forces of almost all NATO-nations and non-NATO/PfP-EAPC nations. Each FFTS allows a
nation’s forces to report their positional information within the technical framework of their
respective national system. For operations of a single nation this is fully sufficient. However, in
NATO/coalition/multi-national operations, commanders of forces from various nations require
access to the information about all forces under their command. At the tactical level, this
information needs also to be exchanged horizontally amongst neighbouring forces.
FFT is based on self-reporting of friendly elements, which is not sensor derived. This principle
implies that the report contains valid information and must be treated as information with very
high reliability.
Tracked objects are typically ground vehicles or dismounted soldiers of national, NATO owned
or allied forces. FFT may also be used in tracking of low flying aircraft (e.g., helicopter and
UAV). This standard may be used for interoperability and data exchange for tracking data from
a collaborating civilian entity that is providing tracking data to friendly forces such as a Non-
Governmental Organization or civilian convoy.
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
REPORTING STRUCTURE
Figure 1 FFT Generic Network Structure
Figure 1 shows a generic FFT network with particular roles. One implemented system could
actually perform one or more roles in a network. However, the specific business rules for each
of these roles should clearly be separated in the system design.
The basic roles in the FFT network are:
 FFT Gateway: this role collects FFT information from connected FFT Terminals via system
specific message formats and converts it to the FFI standard. Likewise it receives standard
FFI messages and forwards them to the connected terminals, if possible.
 FFT Hub: the Hubs receive information from one or more Gateways, Hubs or Proxies and
disseminate them to other connected systems, while avoiding data loops.
 FFT Proxy: the Proxy can convert from one protocol or standard to another. It has to follow
the standards of both related protocols.
 FFT Consumer: the Consumer role receives FFT information forwarded from FFT
Gateways, Hubs, and Proxies.
 FFT Augmentation: augmentation is used to add information about a specific track to the
received messages and forward it to other systems in the network.
 FFT Sanitization: the Sanitization role removes information from received messages and
forwards the reduced information to other systems in the network.
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
In the context of basic network and information sharing, individual FFT Terminals report within
their individual network to a dedicated system, called the FFT Gateway, which in turn converts
the reports into the FFI message format and forwards the information to the FFT network within
a dedicated area of operations. The information is distributed via FFT Hubs and Gateways and
thus is available to all connected systems. Provisions in the network design have to prevent
data loops and forwarding of information with inappropriate security classification. In some
scenarios it might be required to translate the exchanged information to other standards or
other versions of FFT message formats via so called FFT Proxies, or to add (augment) specific
information to or delete (sanitize) specific information from the submitted messages.
Note: “FFT Terminal” is used synonymously in this standard with “FFT Transponder”. The term
“Transponder” is used for legacy reasons when it indicates a part of a field name such as
“TransponderId”.
Note that the standard for information exchange between the Terminals and the Gateway is
not covered by ADatP-36.
Beyond the described roles, services may be established in an FFT network to allow storage
of information and provide that information on demand. This allows a more sophisticated
dissemination of track information, as used in the web-service specification in ANNEX A of this
standard.
FFT REPORT DETAILS
BR-Minimum FFI-1. As a basic principle an FFI report SHALL contain the following
minimum information:
1. Transponder Identification
2. System Name
3. Track Security Marking
4. Time
5. Location (Latitude, Longitude) at time (above)
Note: These minimum data elements provide the basic position report or “blue dot” that will
indicate a unique reporting device’s identification (indicated by the Unique Terminal
Identification (UTID)) and position at the reported time. UTID is defined as the combination of
System and TransponderId fields and is described in greater detail in paragraph 3.7.
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
BR-Minimum FFI-2. Additional information, which MAY be reported, MAY encompass:
 Subsystem name
 Nationality of the FFT System
 Reliability and Credibility categorization of data
 Security marking for “Detailed Track” and “Blue Dot”
 Altitude data
 Movement data (direction, speed, inclination)
 Positional and movement accuracy details
 Planned route points with timing
 Track symbol1,2 and utilised symbol standard
 Unit short name
 Other identification numbers that pertain to other systems
 Operational status information
 Emergency information
 Additional details deemed necessary and not contained in the other parts of the
report.
The additional information may be reported, but it is not mandatory to report this information,
as it would be complementary to the positional information required for preventing fratricide.
SECURITY OF INFORMATION
Security of information is a recognized NATO requirement. Classified information shall be
safeguarded by a balanced set of security measures, including personnel security, physical
security, security of information, Communication and Information System Security (CIS
Security), which shall extend to all individuals having access to classified information, all media-
carrying information, and to all premises containing such information3.
In FFT, information security needs to be applied to protect tactical resources. The level of
classification, and therefore the required efforts for its protection, depends on the operational
scenario in which FFT is performed and NATO and national policies. Even if none of the FFT
information is classified as being harmfull for the operation (NATO UNCLASSIFIED), the
information should be proper marked to define the intended public for his information.4
This standard does not provide the measures and means to protect the actual FFT network.
The only security aspect covered as a first step and minimum requirement to achieve
information security is the possibility to apply proper security marking. This paragraph and
ANNEX F provide the technical foundation for the security marking of FFT information.
The security of the transmitted FFI data is maintained by segregation of the levels of
classification:
 Overall message classification (must be at least the highest classification of all contained
tracks)
 Track classification (overall classification of all data pertaining to the track)
 Blue Dot classification (classification of data pertaining to track position and source of the
track information)
1 Allied Procedural Publication 6 (APP-6), “APP-6(A) Military Symbols for Land Based Systems” [Ref
16]
2 Allied Procedural Publication 6 (APP-6), ”Joint Symbology APP-6(B)” [Ref 30]
3 C-M(2002)49-COR12, Security within the NATO [Ref 1]
4 C-M(2002)60, The management of non-classified NATO information [Ref 36]
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
 Track details classification (classification of track details beyond Track Source and
Positional Data)
Refer to ANNEX F for detailed description of security marking.
FRIENDLY FORCE INFORMATION MESSAGE FORMAT

In order to exchange Friendly Force Information (FFI) among the various national systems,
NATO nations have standardised the information exchange format for FFI as an ADatP-3(A)
compliant message in APP-11(D)(1) [Ref 14]. Before this message was agreed to, a specific
NFFI (NATO Friendly Force Information) message format was introduced and approved in an
NFFI Decision Document (DDoc) [Ref 11] as the Interim NFFI Standard for Interoperability of
Force Tracking Systems.
The Friendly Force Information (FFI) message text format (MTF) has since been introduced to
the NATO Message Catalogue (APP-11) and will be used as the means to exchange FFI data.
FFI MTF formats may be subject to change in future editions of this standard (and APP-11) to
meet emerging/evolving operational and technical requirements of the FFI COI.
Specific rules for the message format, consisting of individual fields and the message structure
are detailed in ANNEX A and ANNEX B.
UPDATE RATES
Individual FFTS have differing update rates of their positions. As it is important to allow
commanders at all levels and weapon engagement elements to base their decisions on the
most precise information, it is important that the positions are updated in accordance with a
well-considered operational necessity. A moving target will require a higher update rate at
higher speeds than with lower speeds, whereas a stationary unit would not require any update
until it is moving away from the last reported position. FFTS update rates should be as high as
possible, within operational and physical limitations, to allow for the most accuracy of the data
within the systems.
UNIQUE TERMINAL IDENTIFICATION (UTID)

In the field of FFT, the requirement for the ability to unambiguously associate data to a unique
identifier mandates the need for a mechanism to control the assignment and distribution of
unique terminal identifications (IDs) across a network. The options are individually controlled
distribution of terminal IDs, or generation and distribution at highest possible level; the latter is
the only suitable solution for assuring uniqueness within the whole FFTS. Considering
national, NATO, multi-national (non-NATO), and coalition (NATO and other nations)
operations, the prerequisite for the required integrity of FFI data is a standardised identifier for
all FFTS.
Refer to paragraph D.2 for detailed description of UTID.
OTHER IDENTIFICATION DATA

In order to support systems with access to other information domains, additional corroborative
identification information can be transmitted. Systems capable of correlation can utilise this
information for validating the information from other sources with the FFI data. Detailed
description of the ‘Other Identification’ field is provided in Table 4 XML (Message/Field)
Clarification.
PROCESSING OF FFI DATA
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
BR-Processing-1. With the minimum mandated information that MUST be transmitted,
the received information SHALL be used as static information until such time the data
is updated by a new report.
BR-Processing-2. As the update rate may be relatively low, reported positions in FFI-
derived reports MUST always be labelled with the timestamp corresponding to that
position.
BR-Processing-3. In case movement data (i.e. bearing, speed, inclination) is reported,

the system processing the information MAY use this information to extrapolate the data
until a new report is received. The extrapolated information SHALL NOT be forwarded
to any other system.
4. DOCUMENT FORMAT
The standard contained in this publication has been developed based on the layered approach
of the STANAG Transformation Framework (STF). The structure of this document (in particular
the annex titles and content) has been aligned with this layered approach.
The STF supports increased interoperability and enhanced reusability among information
exchange standards. The diagram at Figure 2 illustrates the STF.
Figure 2 STANAG Transformation Framework Layers
The STF is characterized by:

 Multiple independent layers
 Reusability between standards of the same nature
 Use of layers and layer interfaces to support coherence between standards
 A machine-readable representation of the layers
The different layers of this framework meet the requirements of the NATO Architecture
Framework and provide for compatibility with future NATO information exchange capabilities.
Note that this publication does not fully meet the STF, because not all parts are represented in
a machine-processable format.
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36
OVERVIEW OF ANNEXES
ANNEX A – Technical Specification – Data Bearer and Routing Layers

ANNEX A specifies the recommended physical mechanisms used for the exchange of
or access to FFT data and specifies the two FFI Interface Protocols (FFI-IP), i.e.,
Interface Protocol 1 (IP1) and Interface Protocol 2 (IP2) that are recommended for the
exchange of or access to FFI data.
ANNEX B – Technical Specification – Data Element Layer
ANNEX B specifies the data elements, when to use them, how to use them, and
processing rules.
ANNEX C – Technical Specification – Message Structure Layer
ANNEX C describes the message structure for the FFT information exchange and
specifies when to use them, how to use them, and further processing rules.
ANNEX D – Technical Specification – Business Rules
ANNEX D defines the technical business rules that are to be derived from requirements
originated from the operational and technical environment. The business rules
complement the other aspects addressed in this document.
ANNEX E – Technical Specification – Web Services – SIP3
ANNEX E defines and describes the Service Interoperability Profile 3 (SIP3) that
supports data transfer with an interface specified according to Web Service
interoperability standards.
ANNEX F – Technical Specification – Security Cross Domain
ANNEX F describes the information required to exchange Friendly Forces Information
across security domains, including:
 How to apply security marking within the FFI MTF
 Sanitization rules to pass the appropriate information to other security domains
 Information integrity mechanisms
ANNEX G – Technical Specification – Operational Cross-Domain
ANNEX G describes the operational cross-domain aspects, where FFT information is
exchanged among different operational domains, including backward compatibility
mapping between FFI MTF and NFFI v.1.3
ANNEX H – Technical Specification – WEB SERVICES - WSMP FFT Profile
ANNEX H defines a profile for WSMP to exchange Friendly Force Information.
ANNEX I – Technical Specification – FFT Filter Language
ANNEX I specifies an XML-based language to express filters on Friendly Force Tracks.
ANNEX J – List of References
ANNEX J contains a list of all references used within the document.
ANNEX K – Lexicon
ANNEX K contains a list of acronyms and a list of terms and definitions used within this
document.
ANNEX L – Revision History
ANNEX L contains the list of changes made in this document with respect to the previous
version [Ref 26].
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
– TECHNICAL SPECIFICATION – DATA BEARER AND

ROUTING LAYERS
FFI INTERFACE PROTOCOL (IP) / SERVICE INTEROPERABILITY PROFILE (SIP)

OVERVIEW
ANNEX A specifies the two FFI Interface Protocols (FFI-IP), i.e., Interface Protocol 1 (IP1) and
Interface Protocol 2 (IP2) that are used for the exchange of or access to FFI data. It also
includes examples of FFI IP1/IP2 messages. The SIP3 specification is detailed at ANNEX E
and the protocol for web services, WSMP FFI Profile, is covered in ANNEX H.
BR-Implementation-1. IP1 SHALL be the minimum implementation for data exchange

or access to FFI data
BR-Implementation-2. Implementation of IP2, SIP3 and WSMP are OPTIONAL and

MAY be implemented.
For clarity of the protocols, this annex follows the layer model as laid down in IETF RFC 1122
[Ref 5] (Requirements for Internet Hosts -- Communication Layers), dated Oct 1989. This
document defines the following layers: Link Layer, Internet Layer, Transport Layer, and
Application Layer.
In more detail:
 IP1 - two-way reliable push operation over Transmission Control Protocol (TCP) [Ref 4] that
allows two parties to connect to each other (unicast) and exchange information by a reliable
two-way method.
 IP2 - one-way unreliable push operation over User Datagram Protocol (UDP) [Ref 3] for
one-way communication, either for unicast (e.g., for passing data through a data diode
between security domains) or multicast/broadcast.
 SIP3 - supports a data transfer functionality via Service Oriented Architectures,
complementing those specified with IP1 and IP2. Details about this interface are defined in
ANNEX E.
 WSMP – this protocol will supersede SIP3 in the next edition of ADatP-36 and is still
optional in this version of the standard. The WSMP standard is not yet approved and ratified
but the ratification draft will be published shortly. It supports a data transfer functionality
using Service Oriented Architectures, complementing those specified with IP1 and IP2.
Details about this interface are defined in ANNEX H.
INTERFACE PROTOCOL 1 (IP1)

The two-way reliable push Interface Protocol (IP1) is a protocol that allows two parties to
connect to each other (unicast) and exchange information in a reliable two-way method. This
Interface Protocol defines the link layer, transport layer, internet layer, and application layer of
the Internet Network model. Only the application layer is specific to FFI.
A-1 Edition A Version 2

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
Figure 3 Interface Protocol 1 (IP1)
IP1: LINK LAYER

The link layer consists of all hardware needed to set up a physical network connection. In IP1
there are no restrictions to this layer, as long as an Internet Protocol (IP)-based network can
be set up on top of the hardware; e.g., it is allowed to use IEEE802.3 and/or IEEE802.11
compliant hardware, also in combination with each other.
BR-IP1-1. The link layer SHALL allow setting up an IP-based network on top of the
hardware.
IP1: INTERNET LAYER

The internet layer routes data according to unique network device addresses. The internet layer
used for IP1 is the standard IP-based infrastructure. Each node in the network must have a
unique IP address, which is used to uniquely identify a network node. In network design the
implications of Internet Protocol version (IPv4 or IPv6) must be considered.
BR-IP1-2. At a minimum, IPv4 SHALL be supported.
BR-IP1-3. IPv6 MAY be used between systems. If it is used then coordination SHALL
be done to ensure both endpoints are using IPv6.
IP1: TRANSPORT LAYER

The transport layer manages end-to-end data delivery in the network. The transport layer of
IP1 is formed by the standard transmission control protocol (TCP). TCP provides connection
oriented, reliable, byte-stream data delivery.
Connection-oriented protocols establish an end-to-end link before any data is transported.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
BR-IP1-4. The TCP connection MAY remain open until either the producer or consumer
system disconnects or a time-out occurs. The connection has to be established only
once to exchange multiple messages (i.e., the TCP/IP connection is Always Open).
Note: There may be an exception to the Always Open connection. If the network or architecture
is unstable the Always Open option may lead to unexpected data loss. There are two
possibilities to help alleviate data loss:
BR-IP1-5. Both the producer and consumer systems MAY set up an Open-Send-Close
connection. The producer system SHALL buffer messages that are being sent to ensure
100% data integrity. The amount of buffering SHALL be coordinated between the
producer and the consumer (i.e. last 1000 messages, last 5 minutes of data
transmission) because the producer system MAY become degraded if buffering is
indefinite.
BR-IP1-6. The consumer system MUST establish a monitoring capability to determine

if data flow has been interrupted, and if so, resets the connection. While this method
will provide for some data assurance, there can still be data loss even if buffered on the
producer system.
Drawbacks may include inefficiencies while using the monitoring method and communications
overhead when using the Open-Send-Close method.
Using TCP communication all TCP packets have guaranteed delivery. TCP’s client/server
relationship requires additional session configuration. TCP is the protocol of choice for data
transactions in which performance must give way to integrity, controllability, and reliability.
IP1: APPLICATION LAYER

Within the IP1 application layer the FFI IP1/IP2 Header and FFI Payload are defined, and
together, they make up the FFI IP1 message.
BR-IP1-7. The Domain Name Service (DNS) is a service to resolve node names to IP
addresses and IP addresses to node names. This means that a DNS SHOULD be
running in the overall network setup.
BR-IP1-8. Firewalls MAY be used. If used, they SHALL be configured to enable DNS
communication. The use of DNS over security zones is not always allowed or possible.
INTERFACE PROTOCOL 2 (IP2)

The one-way unreliable push is an Interface Protocol that can be used for one-way
communication, either for unicast or multicast. One network node can send messages to one
or more other network nodes, using an unreliable method. This means that there is no delivery
guarantee. This IP can be used in situations in which the data is to be sent in near-real time
without the overhead of the reliability, or situations in which the same data should be distributed
over multiple network nodes but delivery guarantee is less important.
As in IP1, in IP2 the four layers of the Internet Network Model are defined. Only the application
layer is specific to FFI and some provisions are made on the use of the transport layer.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
Figure 4 Interface Protocol 2 (IP2)
IP2: LINK LAYER

See IP1: Link layer (paragraph A.2.1).
IP2: INTERNET LAYER

See IP1: Internet layer (paragraph A.2.2).
IP2: TRANSPORT LAYER

The UDP protocol standard is a ‘connectionless’ protocol, employing ‘best effort’ logic to send
the message despite the receiving status.
BR-IP2-1. The IP2 implementation SHALL support unicast UDP communication.

Unicast UDP communication is much like TCP communication in that there is a single
consumer endpoint to which the data producer sends data. The difference is that
communication between endpoints is accomplished using UDP.
BR-IP2-2. Multicast UDP communication MAY be supported, but coordination between

systems SHALL occur to ensure both the producer and consumer are using multicast
UDP. Multicast allows multiple consumers to receive data that is sent to a multicast
group. As with unicast there is no guarantee that the data will be received by the
consumer.
IP2: APPLICATION LAYER

Like in the IP1 application layer FFI Header and FFI Payload are defined.
BR-IP2-3. The application layer of IP2 uses the header for rebuilding the FFI messages
that are spread over multiple UDP packet segments. The reassembling SHALL be done
based on the header fields ‘Message Identifier’, ‘Packet segment number’ and ‘Payload
length’.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
Within the IP2 application layer, like in IP1, the FFI IP1/IP2 Header and FFI Payload are
defined. All headers (potentially with repetitions) and the payload (potentially split into multiple
UDP packets) together make up the FFI IP2 message.
BR-IP2-4. The Domain Name Service (DNS) is a service to resolve node names to IP
addresses and IP addresses to node names. This means that a DNS SHOULD be
running in the overall network setup.
BR-IP2-5. Firewalls MAY be used. If used, they SHALL be configured to enable DNS
communication. The use of DNS over security zones may not always be allowed or
possible.
The following business rules SHALL be used when implementing the IP2 application layer’s
FFI message segmentation:
BR-IP2-6. The maximum size of the IP2 messages SHALL be coordinated between
the producer and consumer. This is due to the fact that some consumers have a limit
on the size of UDP datagrams that can be received and processed.
BR-IP2-7. The coordinated UDP datagram size SHOULD be as large as possibly can
be supported by both the producer and the consumer in order to minimize IP2 message
segmentation processing.
BR-IP2-8. Once the maximum UDP datagram size is determined, then the producer
SHALL take one of three actions to ensure that no packet size is larger than the
maximum packet size minus 16 bytes for the IP1/IP2 header size:
1. Split the FFI message into separate, complete, well-formed FFI XML messages
where none of the resulting FFI messages is larger than the maximum UDP
datagram limit.
2. Disassemble the FFI message into multiple segments where no datagram is larger
than the maximum UDP datagram limit. For this action, the producer SHALL set
the ‘Packet segment number’, as described in this document, so that the
consumer can reassemble the message.
3. Compress the payload using the compression technique discussed in this
document. If the payload is still larger than the maximum agreed UDP datagram
limit, then one of the other actions above SHALL be used.
BR-IP2-9. BR-IP2-8 option 1 SHOULD be used, so that all messages can be sent as
a single UDP datagram.
At implementation, a parameter should be set to ensure that no UDP packets will be saved for
reassembling longer than a default value (e.g., of 120 seconds).
BR-IP2-10. Any message that cannot be reassembled owing to missing UDP packets
SHALL be discarded after the specified time-out.
The definitions of the header and payload are the same as those for the header and payload
of IP1. More details are provided in the following paragraphs.
FFI DATA COMPRESSION

The FFI IP1/IP2 header encoding field allows application of a compression algorithm to the FFI
payload. The FFI payload may be compressed to reduce the size of the payload before
transmitting to an FFI data consumer. If use of compression is desired, then there must be

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
coordination between the FFI data producer and the FFI data consumer. Business rules for FFI
data compression are detailed in ANNEX D.
FFI IP1/IP2 HEADER SPECIFICATION
FFI IP1/IP2 HEADER INTRODUCTION

The FFI IP1/IP2 header is common to both IP1 and IP2.
Figure 5 FFI IP1/IP2 Header and FFI Payload
The FFI IP1/IP2 Header is an application-layer prefix for both IP1 and IP2. It includes
information about the sender and the destination, the different encodings for FFI, and the
different message types. For the IP2 transport it provides the capability to split the message
into smaller packets and reassemble at the destination. It also provides some capabilities that
could be exploited in the future such as specification of a message transport priority and the
possible authentication of the sender (based on the provided sender certificate). The FFI
IP1/IP2 header consists of a data structure that is introduced in front of the FFI payload, as
depicted in Figure 5.
The FFI IP1/IP2 Header is a bit-based fixed-field structure of 16 bytes in “network order”
(“bigendian”), i.e., the most significant bit is stored or transmitted first in the same way as in
conventional binary mathematics. The FFI IP1/IP2 header structure is depicted in Figure 6 with
the fields described in the following paragraphs.
BR-IP Implementation-1. If the FFI IP1/IP2 header contains unknown values in any of
the fields: Message Type, Encoding, or Spare, the payload of the message SHALL be
dropped by any role.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
FFI IP1/IP2 HEADER ELEMENTS SPECIFICATION
Figure 6 FFI IP1/IP2 Header Definition
Field: Message Type

Range/Units: 0-15
Default: 1
Start bit: 0
Length: 4
Description: An identifier of which payload message is used. This identifier is
coded as follows:
0 NFFI
1 FFI MTF (minimum implementation capability)
2-14 Reserved for future use
15 Reserved for use of other message types as mutually
agreed

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
Field: Priority
Range/Units: 0-3
Default: 0
Start bit: 4
Length: 2
Description: The priority of the message in the payload according to the
Combined Communications Electronics Board (CCEB) military
precedence. The Priority field is intended as an indication for a
message handling and routing component. The implementation
of different priority levels depends on their functionality.
The possible values are:
0 ROUTINE (R): Reserved for transmission by rapid means

but not of sufficient urgency to require
higher precedence
1 PRIORITY (P): Reserved for traffic requiring priority above
ROUTINE level
2 IMMEDIATE (O): Reserved for messages relating to
situations gravely affecting the security of
the nation
3 FLASH (Z): Reserved for extreme urgency
BR-Header Field-1. The Default value of ‘0’ SHALL be used. Do not evaluate this field.
Field: Spare (former Destination country)

Range/Units: 0-1023
Default: 0
Start bit: 6
Length: 10
Description: Spare field, with fixed value 0. In a network with systems based
on the previous NFFI interim standard, systems might transmit
a number in this field. Legacy implementations who receive
value 0 will interpret it as “Any Country”.
BR-Header Field-2. Transmitting systems SHALL set the value of the field “Spare
(former Destination Country)” to 0. Receiving systems SHALL ignore values other than
0, which might be received from legacy implementations.
Field: Destination system

Range/Units: 0-255
Default: 0
Start bit: 16
Length: 8
Description: The identifier (number) of the Destination system, i.e., the Force
Tracking System being addressed in the network.
The meaning of this identifier is specified and agreed at least for a

certain operational context.
There are no overall pre-defined meanings of these values except

for value 0 (all bits = “0”) that is used to denote “all systems”.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
BR-Header Field-3. Destination System numbers SHALL be assigned by a network
authority and the information SHALL be distributed to all nodes in the network.
BR-Header Field-4. Destination System numbers SHALL be unique in a network.
Field: Destination subsystem

Range/Units: 0-255
Default: 0
Start bit: 24
Length: 8
Description: The identifier (number) of the Destination subsystem of the
specified system.
The meaning of this identifier is specified and agreed for a certain

operational context.
There are no overall pre-defined meanings of these values except

for value 0 (all bits = “0”) that is used to denote “all subsystems”.
BR-Header Field-5. Destination subsystem numbers SHALL be assigned by the

system authority and MAY be distributed to all nodes in the network.
BR-Header Field-6. Destination subsystem numbers MUST be unique only within a

system.
Use of Destination set:
BR-Header Field-7. The Destination set (system, subsystem fields) in the header
SHALL be ignored by the HUB and Proxy systems and SHALL NOT be used for routing
purposes.
Field: Timestamp
Range/Units: 0-4294967295
Start bit: 32
Length: 32
Description Time the message was sent by the sender in seconds (unsigned
integer, in network order) since 1970/01/01-00:00:00 UTC.
BR-Header Field-10. When an FFI IP1/IP2 message is forwarded without

modifications, only the timestamp together with the Source set (system, subsystem
fields) of the Hub SHALL be changed.
BR-Header Field-11. When an FFI IP1/IP2 message is forwarded with modifications

(e.g. encoding, message type, compounding of multiple tracks, augmentation), the
timestamp together with the Source set (system, subsystem fields) of the Hub or other
role doing the modification, and other relevant fields SHALL be updated.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
Field: Message Identifier
Range/Units: 0-255
Start bit: 64
Length: 8
Description The sequence number of the message contained in the payload.
For IP2 (UDP), it is used to identify UDP packets that belong to the
same FFI message, enabling the reconstruction of messages that
are split over multiple UDP packets.
BR-Header Field-12. For IP1, the Message Identifier and Packet segment number
SHALL be set to 0 by the transmitting system and SHALL be ignored by the receiving
system.
BR-Header Field-13. For IP2, the Message Identifier identifies the FFI message and
after a value of “255” is used, MUST restart at “0”.
BR-Header Field-14. For IP2, the Message Identifier SHALL be increased for each
transmitted message.
BR-Header Field-15. For IP2, the Message Identifier and Packet segment number
together SHALL be used to reassemble User Datagram Protocol (UDP) packets into
the original FFI payload.
BR-Header Field-16. For IP2, an incomplete message SHALL be immediately dropped

if a new message is received with a different value of Message Identifier field.
Field: Packet segment number

Range/Units: 0-255
Start bit: 72
Length: 8
Description The sequence number of the segment of the current FFI
message. This number in combination with the Message Identifier
forms the packet number of a certain message and is used,
together with the Payload Length field, to reassemble separate
UDP packets into one FFI message.
BR-Header Field-17. For IP1 (TCP/IP) this field SHALL NOT be used and SHALL be
set to zero.
BR-Header Field-18. For IP2 (UDP) this field SHALL be set to zero for the first packet,
and SHALL increment by one for each additional packet associated with a Message
Identifier.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
Field: Encoding
Range/Units: 0-15
Default: 0
Start bit: 80
Length: 4
Description: This field indicates the encoding of the payload data. The
following options are defined:
0 Uncompressed ASCII (minimum implementation

capability)
1 Compressed ASCII using the Deflate algorithm (see
details in ANNEX D)
2-15 Reserved for future use (other compression
algorithms)
Comment: When 0, the payload is interpreted as self-explanatory XML, in line with the message
format indicated with the Message Type field.
Use of Encoding field:
The default and normal mode of encoding the message payload is uncompressed ASCII XML
(value “0”).
BR-Header Field-19. If the data is compressed, this field SHALL specify which
algorithm is used.
Field: Spare
Range/Units: 0-3
Start bit: 84
Length: 2
Description Spare field, with fixed value 0
Field: Spare (former Source country)

Range/Units: 0-1023
Start bit: 86
Length: 10
Description Spare field, with fixed value 0. In a network with systems based
on the previous NFFI interim standard, legacy implementations
who receive value 0 will interpret it as “Not specified”.
BR-Header Field-20. Transmitting systems SHALL set the value of the field “Spare
(former Source Country)” to 0. Receiving systems SHALL ignore values other than 0,
which might be received from legacy implementations.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
Field: Source system
Range/Units: 0-255
Default: 0
Start bit: 96
Length: 8
Description The identifier (number) of the Source system, i.e., the Force
Tracking System sending the data. The meaning of this identifier
is specified and agreed at least for a certain operational context.
There are no overall pre-defined meanings of these values

except for value 0 (all bits = “0”) that is used to denote
“unspecified” or “not assigned”.
It is data transport related information, having nothing to do with

system field in FFI message definition.
BR-Header Field-21. If the source system is unknown or not assigned, the value 0
SHALL be used for the source system.
BR-Header Field-22. A unique Source System number SHALL be assigned by a

network authority to each system in the network and the information SHALL be
distributed to all nodes in the network.
Field: Source subsystem
Range/Units: 0-255
Default: 0
Start bit: 104
Length: 8
Description The identifier (number) of the Source subsystem of the specified
system.
The meaning of this identifier is specified and agreed for a certain

operational context.
There are no overall pre-defined meanings of these values

except for value 0 (all bits = “0”) that is used to denote
“unspecified” or “not assigned”.
It is data transport related information, and has nothing to do with

subsystem field in FFI message definition.
BR-Header Field-23. Source subsystem numbers SHALL be assigned by the system

authority and MAY be distributed to all nodes in the network.
BR-Header Field-24. Source subsystem numbers MUST be unique only within a

system.
Use of Source set:
BR-Header Field-25. The Source set (system, subsystem fields) MAY be used for
logging, traceability and possible collision/duplication detection.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
The source set content is generally related to a communication segment between a sender and
receiver.
BR-Header Field-26. When a system forwards a message with any modifications, it

SHALL update the source fields and timestamp as well as the affected fields like
payload length, combining tracks, augmenting, encoding or message type.
Field: Payload length
Range/Units: 0-65535
Start bit: 112
Length: 16
Description The field is mandatory both for IP1 and IP2. In both cases, Payload
length is the total length of the payload message in bytes. This length
always reflects the total length of the sent message, although, for IP2,
only part of it might be contained in the current UDP packet.
Use of Payload length field:
BR-Header Field-27. The Payload length field SHALL indicate the length of the actual
and complete FFI payload. For a compressed payload (encoding field contains a value
other than zero) the payload length SHALL refer to the length of the compressed
message.
BR-Header Field-28. For IP1, Payload length SHALL be used to identify the length of
individual messages when reading from an open TCP/IP connection.
BR-Header Field-29. If the payload length does not correspond to the actual received
number of bytes for the FFT Payload, the message SHALL be discarded by the receiver.
MODIFICATIONS OF IP1/IP2 HEADER

BR-Header Mod-1. An FFT Gateway or Proxy that generates an FFI IP1/IP2 message
SHALL produce an IP1/IP2 header with all fields completed.
BR-Header Mod-2. An FFT Hub, that forwards a received message without

modification, SHALL change the following fields of the IP1/IP2 header:
1. Source set (Source System, Source Subsystem)
2. Timestamp
BR-Header Mod-3. An FFT Hub that forwards a received message with modifications
(compounding multiple tracks, change of encoding), SHALL create a new IP1/IP2
header, including new payload length, source system fields and a new timestamp.
EXAMPLE
The FFI IP1/IP2 header is defined by the header specification, which is a sequence of 16 bytes.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
An example FFI IP1/IP2 header (with arbitrary values) is shown in Table 1.
Table 1 Sample FFI IP1/IP2 Header
Interpreted Decimal
Field Value Value Binary Value
Message Type FFI 1 0001
Priority ROUTINE 0 00
Spare N/A 0 0000000000
Destination System
All systems 0 00000000
Destination
All subsystems 0 00000000
Subsystem
14 Jan 2011
Timestamp 1294967295 01001101001011111010000111111111
01:08:15 Z
Message
6th message 5 00000101
Identifier
Packet Segment
4th packet 3 00000011
Number
Uncompressed
Encoding 0 0000
ASCII
Spare N/A 0 00
Spare N/A 0 0000000000
Source System System 150 150 10010110
Source
Subsystem 200 200 11001000
Subsystem
Payload Length 1036 Bytes 1036 0000010000001100
The assembled 16 byte – 128 bits – of the FFI IP1/IP2 header in binary format will be:
Table 2 FFI IP1/IP2 Header (Binary Format)
Value Bit positions

0001 | 0000 | 0000 | 0000 | 0000 | 0000 | 0000 | 0000 0 - 31
0100 | 1101 | 0010 | 1111 | 1010 | 0001 | 1111 | 1111 32 - 63
0000 | 0101 | 0000 | 0011 | 0000 | 0000 | 0000 | 0000 64 - 95
1001 | 0110 | 1100 | 1000 | 0000 | 0100 | 0000 | 1100 96 - 127
In hexadecimal format this is:
Table 3 FFI IP1/IP2 Header (Hexadecimal Format)
0x1000.0000.4D2F.A1FF.0503.0000.96C8.040C
INTERFACE PROTOCOL IMPLEMENTATION

This section complements earlier paragraphs in order to cover all aspects of the interface
protocols and remove ambiguities about implementation of protocol handlers and FFI

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
Gateways. It complements the definition presented in the previous sections with specific
requirements for configuration and customization.
BR-IP Implementation-2. The owner of each FFT Gateway, Hub and Proxy SHALL
configure the (logical) association of the following parameters:
 System and Subsystem
 The used IP addresses
 The system name for use in the UTID
 If Domain Name Service (DNS) is enabled in the network, the DNS names
BR-IP Implementation-3. In the IP1 setup, the listening port of the TCP server MAY
be a single port for multiple connections or SHOULD be a dedicated port for each
connection, which will be defined during network design. Set-up of ports is a matter of
network design and coordination SHALL be required between all connecting systems
within the network.
BR-IP Implementation-4. This configuration MAY be part of the specifications in the

SOPs/TTPs for the operation/mission and SHALL be shared with all connected
systems.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX A to ADatP-36
INTENTIONALLY BLANK

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX B to ADatP-36
– TECHNICAL SPECIFICATION – DATA ELEMENT LAYER
Generally, this annex elaborates on the use of the elemental units of the FFI message format. It provides further details, beyond the original publication of the
specification in the NATO Message Catalogue, APP-11(D)(1) [Ref 14]. The user format for the FFI message format in APP-11(D)(1) has to be consulted prior
to the details provided below.
FIELD USAGE AND PROCESSING

Table 4 below gives particular instructions for each field in the format.
Column A (Element Name) provides a path name to each individual field in XPath notation [Ref 21]. All path names are to be considered relative to the root
node, which is addressed by “/mtf:FriendlyForceInformation/”, followed by the value shown in the table. Note, that the path does not account for addressing
repeatable elements.
Column B (When to Use) gives further clarification on the selection of fields for message preparation. Fields that are marked as “Not to be used” are generally
fields that are included in any MTF by the standards ADatP-3(A) and APP-11(D)(1), but have no application in FFT.
Column C (How to Use) provides more detailed instructions on how a message producer shall use a particular field and some additional conventions.
Column D (How to Process) provides additional instructions on how a particular field shall be processed on receipt.
B-1 Edition A Version 2

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX B to ADatP-36
Table 4 XML (Message/Field) Clarification
No. Element Name (xpath notation) When to Use How to Use How to Process
X A B C D
1 ExerciseIdentification/ExerciseNickname Operational decision If an exercise, incorporate element. If not an If not used, assume Operation.
exercise, do not use.
2 ExerciseIdentification/ExerciseIdentifier/ Not to be Used Not applicable (N/A)
ExerciseAdditionalIdentifier
3 ExerciseIdentification/ExerciseIdentifier/ Not to be Used N/A
ExerciseAdditionalNickname
4 OperationCodeword/OperationCodeword Operational decision If an operation, incorporate element. If not an If not used, and ExerciseNickname is
operation, do not use. not used, assume Operation.
5 OperationCodeword/ Not to be Used N/A
PlanOriginatorAndNumber
6 OperationCodeword/OptionNickname Not to be Used N/A
7 OperationCodeword/ Not to be Used N/A
SecondaryOptionNickname
8 MessageIdentifier/ Mandatory Fixed Value of “FFI”. Incorporate value.
MessageTextFormatIdentifier
9 MessageIdentifier/Standard Mandatory Value as given in the FFI message Incorporate value.
specification: fixed value of “APP-11(D)”
10 MessageIdentifier/Version Mandatory Value as given in current FFI message Incorporate value.
specification: fixed value of “1”
11 MessageIdentifier/Originator Mandatory Used to uniquely identify the producer of
message.
Name of node producing the message as
defined by the network authority (may be
system, unit, role name, or other).
If forwarding a message (nothing in
message content is changed), do not
change the Originator.
If a node modifies the message (compound,
split, sanitize, augment, transform, etc.) it
MUST set itself as the originator when
transmitting.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX B to ADatP-36
X A B C D
12 MessageIdentifier/MessageSerialNumber Operational decision May be used together with Originator and
ReferenceTimeOfPublication to uniquely
identify a message
13 MessageIdentifier/ Mandatory to use one of Used with Originator and optionally
ReferenceTimeOfPublication/ these elements MessageSerialNumber to uniquely identify a
MonthNameAbbreviated message
14 MessageIdentifier/
ReferenceTimeOfPublication/DateTimeIso
15 MessageIdentifier/Qualifier Not to be Used N/A
16 MessageIdentifier/SerialNumberOfQualifier Not to be Used N/A
17 MessageIdentifier/MessageSecurityPolicy Mandatory Value determined by network management May be used in a security gateway for
authority. processing and/or filtering.
18 MessageIdentifier/MessageClassification/ Mandatory to use one of This element shall be used for all Policies May be used in a security gateway for
SecurityClassificationExtended these elements when the Classification Label is one of the processing and/or filtering.
following standard, unabbreviated
Classifications/Markings:
 UNCLASSIFIED
 RESTRICTED
 CONFIDENTIAL
 SECRET
 TOP SECRET

19 MessageIdentifier/MessageClassification/ Use this element when the Classification May be used in a security gateway for
SecurityClassification Label is not one of the standard, processing and/or filtering.
unabbreviated Classifications/Markings
mentioned above.
20 MessageIdentifier/ Operational decision Values determined by network management May be used in a security gateway for
MessageSecurityCategory authority. processing and/or filtering.
21 Reference/SerialLetter Not to be Used N/A
22 Reference/CommunicationsType/ Not to be Used N/A
MessageTextFormatIdentifier
23 Reference/CommunicationsType/ Not to be Used N/A
CommunicationType

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX B to ADatP-36
X A B C D
24 Reference/TitleOfDocument Not to be Used N/A
25 Reference/Originator Not to be Used N/A
26 Reference/DateAndOrTimeOfReference/ Not to be Used N/A
Dtg
DateDdmmmyyyy
MonthYear
DateTimeIso
30 Reference/ReferenceSerialNumber Not to be Used N/A
31 Reference/SpecialNotation Not to be Used N/A
32 Reference/GroupOfFields/ Not to be Used N/A
SicOrFileNumber/Sic
33 Reference/GroupOfFields/ Not to be Used N/A
SicOrFileNumber/FilingNumber
34 GeodeticDatum/GeodeticDatum Mandatory Fixed value of “WGE”. Upon receipt of a message that does
not contain “WGE”:
• If known other datum is agreed,
then process.
• If datum is missing, assume “WGE”
 If datum is not known or invalid
value, message SHALL be
dropped. If dropped, originator
SHOULD be informed and operator
SHALL be informed.
35 GeodeticDatum/ Not to be Used N/A
NationalGridSystemCoordinates

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX B to ADatP-36
X A B C D
36 TrackInformation/TrackSource/ Mandatory As assigned by system owner to uniquely
TransponderId identify terminal within the system.
TransponderId is used in combination with
System to form the Unique Terminal
Identification (UTID).
The TransponderId SHALL be considered
case insensitive.
37 TrackInformation/TrackSource/System Mandatory System name SHOULD be coordinated with
the network management authority.
System is used in combination with
TransponderId to form the Unique Terminal
Identification (UTID).
38 TrackInformation/TrackSource/Subsystem Operational decision Used to provide addition level of detail to
System.
39 TrackInformation/TrackSource/Nationality/ Operational decision Use one of enumerated values.
GeographicalEntity The Geographical Entity is the geographical
entity of the System
(TrackInformation/TrackSource/System), it is
NOT the geographical entity of the track
40 TrackInformation/TrackSource/Nationality/ Used only if there is no enumerated value for
NonStandardGeographicalEntity nationality.
The Geographical Entity is the geographical
entity of the System
(TrackInformation/TrackSource/System), it is
NOT the geographical entity of the track
41 TrackInformation/TrackSource/Reliability Operational decision If used, select one of the enumerated values.
42 TrackInformation/TrackSource/Credibility Operational decision If used, select one of the enumerated values.
43 TrackInformation/TrackSecurityLabel/ Mandatory Must be same as MessageSecurityPolicy. May be used in a security gateway for
TrackSecurityPolicy processing and/or filtering.
44 TrackInformation/TrackSecurityLabel/ Mandatory to use one of When TrackSecurityPolicy is “NATO” use this May be used in a security gateway for
TrackSecurityClassification/ these elements element. processing and/or filtering.
SecurityClassificationExtended

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX B to ADatP-36
X A B C D
45 TrackInformation/TrackSecurityLabel/ When TrackSecurityPolicy is not “NATO” use May be used in a security gateway for
TrackSecurityClassification/ this element. Values determined by network processing and/or filtering.
SecurityClassification design authority.
46 TrackInformation/TrackSecurityLabel/ Operational decision Values determined by network management May be used in a security gateway for
TrackSecurityCategory authority. processing and/or filtering.
47 TrackInformation/TrackSecurityLabel/ Operational decision to Values determined by network management May be used in a security gateway for
BlueDotSecurityClassification/ use one of these authority. processing and/or filtering.
SecurityClassificationExtended elements
48 TrackInformation/TrackSecurityLabel/ Values determined by network management May be used in a security gateway for
BlueDotSecurityClassification/ authority. processing and/or filtering.
SecurityClassification
BlueDotSecurityCategory authority. processing and/or filtering.
50 TrackInformation/TrackSecurityLabel/ Operational decision to Values determined by network management May be used in a security gateway for
DetailsSecurityClassification/ use one of these authority. processing and/or filtering.
SecurityClassificationExtended elements
51 TrackInformation/TrackSecurityLabel/ Values determined by network management May be used in a security gateway for
DetailsSecurityClassification/ authority. processing and/or filtering.
DetailsSecurityCategory authority. processing and/or filtering.
53 TrackInformation/TrackPositionalData/Time Mandatory Use date and time of reported track position. Refer to business rules concerning
time late, future, and duplicate tracks.
54 TrackInformation/TrackPositionalData/ Mandatory Use the location of reported track position.
Location
55 TrackInformation/TrackPositionalData/ Operational decision MAY be used when accuracy information is
HorizontalAccuracy available.
56 TrackInformation/TrackPositionalData/ Operational decision Convert to integer values and limit to values
Altitude between -400 and 99999 metres.
If values exceed the permitted range, the
maximum/minimum value SHALL be entered.
57 TrackInformation/TrackPositionalData/ Operational decision MAY be used when accuracy information is
VerticalAccuracy available.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX B to ADatP-36
X A B C D
58 TrackInformation/TrackMovementData/ Operational decision Convert to integer (0-359).
Bearing
59 TrackInformation/TrackMovementData/ Operational decision MAY be used when accuracy information is
BearingAccuracy available.
60 TrackInformation/TrackMovementData/ Operational decision Use value of “KPH” for If receive a
Speed UnitOfSpeedVelocityMeasurement element. UnitOfSpeedVelocityMeasurement
element value other than “KPH”,
convert to “KPH”.
61 TrackInformation/TrackMovementData/ Operational decision MAY be used when accuracy If receive a
SpeedAccuracy information is available. Use UnitOfSpeedVelocityMeasurement
value of “KPH” for element value other than “KPH”,
UnitOfSpeedVelocityMeasurement element. convert to “KPH”.
62 TrackInformation/TrackMovementData/ Operational decision Positive values (1 to 90) for ascending tracks,
Inclination negative values (-1 to -90) for descending
tracks. Value zero indicates a horizontal
movement.
63 TrackInformation/TrackMovementData/ Operational decision MAY be used when accuracy information is
InclinationAccuracy available.
64 TrackInformation/TrackPlannedLocation/ Operational decision Enter the estimated date time of arrival Time SHOULD be added as a
EstimatedTimeOfArrival at the associated location, Element MAY datetime-group symbol modifier in
be repeated with accordance with APP-6(A) and APP-
PlannedLocation and 6(B) on the top left corner of the
EstimatedTimeOfDeparture as needed for symbol, e.g.
additional planned locations. “190905ZFEB2013”.
Should be used when position is not expected
to be reported within normal reporting
frequency.
65 TrackInformation/TrackPlannedLocation/ Operational decision Element MAY be repeated with If receive planned location, in
PlannedLocation EstimatedTimeOfArrival and accordance with APP-6(A) and APP-
EstimatedTimeOfDeparture as needed for 6(B), use “A” in fourth position in the
additional planned locations. UnitSymbol code to display
anticipated symbols.
Should be used when position is not expected
to be reported within normal reporting
frequency.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX B to ADatP-36
X A B C D
66 TrackInformation/TrackPlannedLocation/ Operational decision Enter the estimated date time of departure Time SHOULD be added as a
EstimatedTimeOfDeparture from the associated location, Element MAY datetime-group symbol modifier
be repeated with EstimatedTimeOfArrival together with ETA in accordance with
and PlannedLocation as needed for APP-6(A) and APP-6(B) on the top
additional planned locations. left corner of the symbol,
Should be used when position is not expected concatenated by a dash, e.g.
to be reported within normal reporting “200600ZMAR2013-
frequency. 200630ZMAR2013”.
67 TrackInformation/TrackIdentificationData/ Operational decision UnitSymbol SHALL be used if “Affiliation” is If no UnitSymbol is included in the
UnitSymbol other than “Friend”, e.g., “SNGPEVC--------“ track, the default symbol code is
for a neutral civilian vehicle. “SFGP-----------“.
If UnitSymbol cannot be transmitted for other
than “Friend” the whole track SHALL NOT be
transmitted.
68 TrackInformation/TrackIdentificationData/ Operational decision Default value is “APP-6(A)”. Use of any other If value is not “APP-6(A)” confirm
SymbolStandard standard requires coordination. standard in use.
If no value is provided for the Symbol
Standard, the default value APP-6(A)
SHALL be assumed.
69 TrackInformation/TrackIdentificationData/ Operational decision When received, it SHOULD be
UnitShortName displayed with the unit symbol.
70 TrackInformation/TrackIdentificationData/ Operational decision Should insert UIC if available
GroupOfFields/OtherId/
UnitIdentificationCode
72 TrackInformation/TrackIdentificationData/ Operational decision Should be inserted if available.
GroupOfFields/OtherId/IffSifMode1Code

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX B to ADatP-36
X A B C D
GroupOfFields/OtherId/IffSifModeSCode
UnitReferenceNumberVmf
78 TrackInformation/TrackIdentificationData/ Not to be used. Planned for future use.
DataLinkTrackNumber
GroupOfFields/OtherId/ObjectItemId
80 TrackInformation/OperationalStatus/Alert Operational decision Used only, when the reporting entity is in an Notify Owning Operations Center /
emergency situation. Value “NO” SHOULD Data Owner if value is “YES”. TTPs
NOT be inserted. may need to be developed.
If no value is provided, the entity is
assumed to not have an emergency
situation.
81 TrackInformation/OperationalStatus/ Operational decision Should be inserted if available.
Footprint
Strength
PersonnelStrength
84 TrackInformation/OperationalStatus/Status Operational decision Enumerated value SHOULD be inserted if
available.
85 TrackInformation/NatureOfEmergency/ Operational decision Should be used if Alert is “YES”.
TextIndicator SHALL NOT be used if Alert is “NO”
or not present.
If used, the fixed value is “NATURE OF
EMERGENCY”.
86 TrackInformation/NatureOfEmergency/ Operational decision SHALL be used if If Alert is “Yes” and FreeText is
FreeText NatureOfEmergency/TextIndicator is used. received, Owning Operations Center /
SHALL NOT be used otherwise. Data Owner SHOULD be notified of
FreeText value.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX B to ADatP-36
X A B C D
87 TrackInformation/DetailData/TextIndicator Operational decision SHALL be used if FreeText is to be used.
88 TrackInformation/DetailData/FreeText Operational decision Use to provide additional detailed data not
indicated in rest of message.
89 [different]/Amplification Not to be used N/A
90 [different]/Narrative Not to be used N/A
91 Remarks Not to be used N/A
INTERPRETATION AND PROCESSING OF NILLED FIELDS

A field can be present in the message, while the content of a field is either not available or withheld. ADatP-3(A) [Ref 13] specifies the notation to represent
these nilled fields(see Annex K:Nilled field
This is represented in MTF (i.e. slant delimited) by an “hyphen” (i.e., ‘-’) and in XML-MTF by an empty field with an attribute xsi:nil. The table below provides the
interpretation for FFI messages in case the field is nilled.
Table 5 Interpretation and processing of nilled fields
Containing element Interpretation in case the field is

Nillable element Action in case the field is nilled
(the XML type) nilled
AmplificationType FreeText Process tracks Ignore element on receipt (see
Table 4)
NarrativeType FreeText Process tracks Ignore element on receipt (see
Table 4)
RemarksType FreeText Process tracks Ignore element on receipt (see
Table 4)

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX B to ADatP-36
ExerciseIdentificationType ExerciseNickname Process tracks Ignore element on receipt
OperationCodewordType OperationCodeword Process tracks Ignore element on receipt
MessageIdentifierType MessageTextFormatIdentifier Process tracks Derive the information from the
XML Schema namespace
MessageIdentifierType Standard Process tracks Derive the information from the
MessageIdentifierType Version Process tracks Derive the information from the
MessageIdentifierType Originator Process tracks Ignore element on receipt
MessageIdentifierType ReferenceTimeOfPublication Process tracks Ignore element on receipt
MessageIdentifierType MessageSecurityPolicy Process tracks Use the default network Policy
MessageIdentifierType MessageClassification Process tracks Use the default network higher
classification
ReferenceType SerialLetter Process tracks Ignore element on receipt (see
Table 4)
ReferenceType CommunicationsType Process tracks Ignore element on receipt (see
Table 4)
ReferenceType DateAndOrTimeOfReference Process tracks Ignore element on receipt (see
Table 4)
GeodeticDatumType GeodeticDatum Upon receipt of a message that does
not contain “WGE”:
 If known other datum is agreed,
then process.
 If datum is missing, assume
“WGE”
 If datum is not known or an
invalid value, message SHALL
be dropped. If dropped,
originator SHOULD be informed
and operator SHALL be
informed.
TrackSourceType TransponderID Drop track
TrackSourceType System Drop track
TrackSecurityType TrackSecurityPolicy Process tracks Use the default network Policy

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX B to ADatP-36
TrackSecurityType TrackSecurityClassification Process tracks Use the default network higher
classification
TrackPositionalDataType Time Drop track Don’t replace with current time, but
drop the track
TrackPositionalDataType Location Drop track
TrackMovementDataType Bearing Process tracks Ignore element on receipt
TrackPlannedLocationType EstimatedTimeOfArrival Process tracks Ignore element on receipt
TrackPlannedLocationType PlannedLocation Process tracks Ignore element on receipt
TrackIdentificationDataType UnitSymbol Process tracks Ignore element on receipt (see also
BR-Symbol-8)
OperationalStatusType Alert Process tracks Set as False
GeneralTextType TextIndicator Process tracks Use instead the GeneralText
(NatureOfEmergency or DetailData)
GeneralTextType FreeText Process tracks Ignore the GeneratText element
and sub-elements
(NatureOfEmergency or DetailData)
BR-Element Layer-1. A message producer SHALL follow the instructions provided in columns B and C of Table 4.
BR-Element Layer-2. A message consumer SHOULD follow the instructions provided in Table 4 (column D) and Table 5.
BR-Element Layer-3. In case of a conflict between spelling or instructions for field content between this annex and the format as published in APP-
11(D)(1), APP-11(D)(1) is the binding specification and SHALL be obeyed.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX C to ADatP-36
– TECHNICAL SPECIFICATION – MESSAGE STRUCTURE

LAYER
This annex provides details on the use of the message structure of the FFI message format. It
provides further details, beyond the original publication of the specification in the NATO
Message Catalogue, APP-11(D)(1) [Ref 14]. The user format for the FFI message format in
APP-11(D)(1) has to be consulted prior to the details provided below.
BR-Message Layer-1. In case of a conflict between the message structure between

this annex and the format as published in APP-11(D)(1), APP-11(D)(1) is the binding
specification and SHALL be obeyed.
BR-Message Layer-2. Until the FFI message text format (FFI MTF) has been fully
implemented into all FFTS, the NFFI format MAY be used concurrently for continued
interoperability.
The technical interdependencies for utilisation of both formats, APP-11(D)(1) and D-Doc, are
outlined in ANNEX G.
FFI PAYLOAD
The FFI payload contains the actual FFI data, depending on the message type specified in the
FFI IP1/IP2 header. The FFI payload contains XML data (NFFI or FFI MTF).
BR-Payload-1. For the FFI MTF message type, the payload MUST be compliant with
ADatP-3(A). In particular, the following ADatP-3(A) rules MUST be obeyed:
1. In accordance with the XML-MTF grammar specified in ADatP-3(A), Annex E,
Appendix 1, Paragraph 3, the root element is:
MESSAGE ::= <mtf:message-text-format-name xmlns:mtf=“MESSAGE-NS” […]
</mtf:message-text-format-name> and uses the fixed namespace prefix “mtf:”
2. The mandatory attribute for free text fields to preserve contained whitespaces is
defined in ADatP-3(A), Annex E, Appendix 1, Paragraph 3 as:
FREE-TEXT-FIELD ::= <field-position-name xml:space=’preserve’>FREE-
TEXT</field-position-name> | EMPTY-FIELD
3. Empty fields in XML-MTF cannot always be simply dropped to maintain the
compatibility with the slant delimited representation. More specifically, in the slant
delimited representation the empty fields MAY be filled by a hyphen character (“-“).
The derivation of those hyphenated fields into XML-MTF is defined in ADatP-3(A),
Annex E, Appendix 1, Paragraph 3 as:
EMPTY-FIELD ::= <field-position-name xsi:nil="true"/>.
Note that the slant delimited representation MUST not be used for information
exchange compatible with this standard.
BR-Payload-2. If a received message uses the FFI-MTF message type and does not
comply with above listed ADatP-3(A) specific limitations of XML it SHALL be processed.
BR-Payload-3. If a received message uses the FFI-MTF message type and does not
comply with ADatP-3(A) Structural Relationship Rules, it SHALL be processed.
C-1 Edition A Version 2

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX C to ADatP-36
BR-Payload-4. The FFI payload SHALL be presented as XML character sequence,
starting with the XML processing instruction (<?xml version=”1.0”?>) and ending with the
close-tag of the FFI message, without any additional file-format characters (so-called
Magic Numbers) such as Byte-Order-Marks. The encoding SHALL be UTF-8.
BR-Payload-5. In case the payload is compressed, neither the content of the

compressed data, nor the resulting compressed file, SHALL use any file-format
characters, such as Byte-Order-Marks.
FFI MESSAGE IMPLEMENTATION

The rules for correct interpretation of the FFI message are defined in APP-11. All systems
implementing the APP-11 FFI MTF should always implement the complete message in order
to allow processing of all information within the receiving systems although the transmission of
information may be limited due to national security policy or restrictions.
BR-Message Implementation-1. Implementation of FFI MTF SHALL follow the rules

of this standard and the implementation rules of ADatP-3(A).
XML MESSAGE VALIDITY

BR-XML-1. XML messages that are being transmitted SHALL conform to the schema.
BR-XML-2. Received XML messages that are not well formed SHALL be ignored.
BR-XML-3. If a received XML message is well formed, but does not conform to the
schema, it MAY be ignored (standard behaviour for XML parsers).
BR-XML-4. In case the originator that reported broken messages can be identified, any
means SHOULD be used to inform the originator to rectify the problem.
BR-XML-5. A message that does not conform to the schema and contains more than
one track MAY be segmented by the receiving system into single tracks and each newly
generated message is validated.
BR-XML-6. A message with a non-compliant track MAY be processed in case there

are errors in OPTIONAL elements. These fields with errors SHALL be ignored in this
case.
EFFICIENCY OF XML FILE PREPARATION

In order to reduce the size of each XML message, the following rules SHALL be followed.
Additional possibilities to reduce the requirements for transmission bandwidth are covered in
ANNEX B (with respect to which fields are to be used) and in paragraph D.6 below (with respect
to data compression).
BR-XML-7. The XML file SHALL be produced and transmitted without filling characters
for visual enhancement, such as additional line breaks, and indentation by whitespace
characters or tabulator characters (pretty-print).

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX C to ADatP-36
BR-XML-8. The XML file SHALL be produced and transmitted without following
attributes: mtfid, segSeq, setSeq, setid, ffSeq, ffirnFudn. The only attribute that SHALL
be used for free text fields is the attribute xml:space=’preserve’ to preserve whitespace
in those fields.
BR-XML-9. The Alert field SHALL only be used with the contained value “YES”, if a
condition as described in paragraph D.3 for an alert exists. If no condition for an alert
exists, the field and the included value “NO” SHALL only be included in the message, if
other fields in the set “Operational Status” are required to be transmitted.
COMPOUNDING MULTIPLE TRACK UPDATES PER MESSAGE
BR-Compound Tracks-1. Multiple tracks SHOULD be sent per message in cases

where multiple track updates are available for transmission rather than sending a
separate message for each track. This will reduce network bandwidth and message
processing times by reducing the number of IP1/IP2 headers and repetitive non-track
message data.
BR-Compound Tracks-2. When compounding multiple tracks per message, roles

SHALL ensure that the normal rules for message transmission specified in this
document are applied. Roles that compound tracks and then retransmit them via the
IP1 or IP2 protocol SHALL ensure that the size of the new message does not exceed
the permitted message size of these protocols after compounding.
The following additional rules SHALL be observed when compounding multiple tracks in a
message:
BR-Compound Tracks-3. The security policy for all tracks in a message SHALL be
the same and SHALL be reflected in the ADatP-3(A) Message Header security marking.
BR-Compound Tracks-4. Message Classification in the ADatP-3(A) Message Header

security marking SHALL be set to the highest classification of all tracks contained in the
message.
For example, if three tracks are combined into one message and the track security markings
are for example RESTRICTED, CONFIDENTIAL and SECRET, then the message
classification shall be set to SECRET.
BR-Compound Tracks-5. Message Security Category SHALL be set to the most

restrictive category of all tracks contained in the message.
For example, if two tracks are compound into one message and the track classification
categories are "REL TO JPN" and "REL JPN, KOR", then the message classification category
would be "REL TO JPN".
BR-Compound Tracks-6. If the categories cannot be compared or the resulting

category would not allow to forward the message to any system, then tracks SHALL
NOT be compounded.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX C to ADatP-36
BR-Compound Tracks-7. Tracks from messages that differ in any of the following
attributes SHALL NOT be merged into one message:
1. From IP1/IP2 header:
- Message type
- Destination System/Sub-system
2. From ADatP-3(A) message header:
- Any used field from the EXERCISE IDENTIFICATION, the OPERATION
CODEWORD, and the GEODETIC DATUM set
- Fields MESSAGE TEXT FORMAT IDENTIFIER, STANDARD, VERSION,
MESSAGE SECURITY POLICY, and MESSAGE SECURITY CATEGORY from
the MESSAGE IDENTIFIER set
BR-Compound Tracks-8. When tracks are compounded into a new message, the
ADatP-3(A) Message Header SHALL reflect the compounding system as originating
system and the actual time.
BR-Compound Tracks-9. The size of the compound message SHALL NOT exceed
the limit of the maximum payload length as specified in the IP1/IP2 header, if transmitted
via IP1 or IP2, i.e. 65535.
EXAMPLES OF AN FFI MESSAGE TEXT FORMAT

Note: BR-XML-7 states that XML files SHALL be produced and transmitted without filling
characters for visual enhancement, such as additional line breaks, and indentation by
whitespace characters or tabulator characters. The following example messages include them
for readability, but they are not to be included in XML files that are produced.
XML-Code 1 Example of Blue Dot Minimum FFI XML-MTF Message
<?xml version="1.0" encoding="UTF-8"?>


<mtf:FriendlyForceInformation xmlns:mtf="urn:nato:mtf:app-11(d):1:ffi" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance">
<ExerciseIdentification>
<ExerciseNickname>CWIX 2013</ExerciseNickname>
</ExerciseIdentification>
<MessageIdentifier>
<MessageTextFormatIdentifier>FFI</MessageTextFormatIdentifier>
<Standard>APP-11(D)</Standard>
<Version>1</Version>
<Originator>ITA</Originator>
<MessageSerialNumber>1902</MessageSerialNumber>
<ReferenceTimeOfPublication>
<DateTimeIso>
<Year4Digit>2013</Year4Digit>
<MonthNumeric>05</MonthNumeric>
<Day>27</Day>
<TimeDelimiter>T</TimeDelimiter>
<HourTime>15</HourTime>
<MinuteTime>21</MinuteTime>
<SecondTime>30</SecondTime>
<TimeZoneZulu>Z</TimeZoneZulu>
</DateTimeIso>
</ReferenceTimeOfPublication>
<MessageSecurityPolicy>CWIX</MessageSecurityPolicy>
<MessageClassification>
<SecurityClassificationExtended>UNCLASSIFIED</SecurityClassificationExtended>
</MessageClassification>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX C to ADatP-36
<MessageSecurityCategory>RELEASABLE TO ISAF</MessageSecurityCategory>
</MessageIdentifier>
<GeodeticDatum>
<GeodeticDatum>WGE</GeodeticDatum>
</GeodeticDatum>
<TrackInformation>
<TrackSource>
<TransponderId>ITA1234</TransponderId>
<System>BLUEFORCE</System>
</TrackSource>
<TrackSecurityLabel>
<TrackSecurityPolicy>CWIX</TrackSecurityPolicy>
<TrackSecurityClassification>
<SecurityClassificationExtended>UNCLASSIFIED</SecurityClassificationExtended>
</TrackSecurityClassification>
<TrackSecurityCategory>RELEASABLE TO ISAF</TrackSecurityCategory>
</TrackSecurityLabel>
<TrackPositionalData>
<Time>
<Day>27</Day>
</Time>
<Location>
<LatitudeDegrees>34</LatitudeDegrees>
<LatitudeMinutes04DecimalPlaces>04.1593</LatitudeMinutes04DecimalPlaces>
<LatitudinalHemisphere>N</LatitudinalHemisphere>
<Hyphen>-</Hyphen>
<LongitudeDegrees>064</LongitudeDegrees>
<LongitudeMinutes04DecimalPlaces>04.1593</LongitudeMinutes04DecimalPlaces>
<LongitudinalHemisphere>E</LongitudinalHemisphere>
</Location>
</TrackPositionalData>
</TrackInformation>
</mtf:FriendlyForceInformation>
The following is an example of a complete FFI message.
XML-Code 2 Example of a Complete FFI XML-MTF Message


<mtf:FriendlyForceInformation xmlns:mtf="urn:nato:mtf:app-11(d):1:ffi" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance">
<OperationCodeword>
<OperationCodeword>ISAF</OperationCodeword>
</OperationCodeword>
<MessageIdentifier>
<MessageTextFormatIdentifier>FFI</MessageTextFormatIdentifier>
<Standard>APP-11(D)</Standard>
<Version>1</Version>
<Originator>USA</Originator>
<MessageSerialNumber>2102</MessageSerialNumber>
<ReferenceTimeOfPublication>
<DateTimeIso>
<Day>27</Day>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX C to ADatP-36
</DateTimeIso>
</ReferenceTimeOfPublication>
<MessageSecurityPolicy>ISAF</MessageSecurityPolicy>
<MessageClassification>
<SecurityClassificationExtended>RESTRICTED</SecurityClassificationExtended>
</MessageClassification>
<GeodeticDatum>
<GeodeticDatum>WGE</GeodeticDatum>
</GeodeticDatum>
<TrackInformation>
<TrackSource>
<TransponderId>USA2601</TransponderId>
<System>CCIS</System>
<Subsystem>SUBSYSTEM</Subsystem>
<Nationality>
<GeographicalEntity>USA</GeographicalEntity>
</Nationality>
<Reliability>A</Reliability>
<Credibility>1</Credibility>
</TrackSource>
<TrackSecurityPolicy>ISAF</TrackSecurityPolicy>
<SecurityClassification>ISAF RESTRICTED</SecurityClassification>
<BlueDotSecurityClassification>
<SecurityClassification>ISAF UNCLASSIFIED</SecurityClassification>
</BlueDotSecurityClassification>
<BlueDotSecurityCategory>RELEASABLE TO INTERNET</BlueDotSecurityCategory>
<DetailsSecurityClassification>
<SecurityClassification>ISAF RESTRICTED</SecurityClassification>
</DetailsSecurityClassification>
<Time>
<Day>27</Day>
</Time>
<Location>
<Hyphen>-</Hyphen>
</Location>
<HorizontalAccuracy>10</HorizontalAccuracy>
<Altitude>0</Altitude>
<VerticalAccuracy>10</VerticalAccuracy>
<TrackMovementData>
<Bearing>001</Bearing>
<BearingAccuracy>10</BearingAccuracy>
<Speed>
<ContextQuantity000999>005</ContextQuantity000999>
<UnitOfSpeedVelocityMeasurement>KPH</UnitOfSpeedVelocityMeasurement>
</Speed>
<SpeedAccuracy>
<ContextQuantity000999>001</ContextQuantity000999>
<UnitOfSpeedVelocityMeasurement>KPH</UnitOfSpeedVelocityMeasurement>
</SpeedAccuracy>
<Inclination>0</Inclination>
<InclinationAccuracy>10</InclinationAccuracy>
</TrackMovementData>
<TrackPlannedLocation>
<EstimatedTimeOfArrival>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX C to ADatP-36
<Day>27</Day>
</EstimatedTimeOfArrival>
<PlannedLocation>
<Hyphen>-</Hyphen>
</PlannedLocation>
<EstimatedTimeOfDeparture>
<Day>27</Day>
</EstimatedTimeOfDeparture>
</TrackPlannedLocation>
<TrackIdentificationData>
<UnitSymbol>SFGPUCIZ---EUSG</UnitSymbol>
<SymbolStandard>APP-6(A)</SymbolStandard>
<UnitShortName>2ND MECH COMP</UnitShortName>
<GroupOfFields>
<OtherId>
<UnitIdentificationCode>
<ArmedService>A</ArmedService>
<FileSequentialLocationNumber>147501</FileSequentialLocationNumber>
</UnitIdentificationCode>
</OtherId>
</GroupOfFields>
</TrackIdentificationData>
<OperationalStatus>
<Alert>NO</Alert>
<Footprint>10</Footprint>
<Strength>1</Strength>
<PersonnelStrength>5</PersonnelStrength>
<Status>1</Status>
</OperationalStatus>
</TrackInformation>
<TrackInformation>
<TrackSource>
<TransponderId>USA2607</TransponderId>
<System>CCIS2</System>
<Subsystem>SUBSYSTEM-A</Subsystem>
<Nationality>
</Nationality>
<Reliability>A</Reliability>
<Credibility>1</Credibility>
</TrackSource>
<TrackSecurityPolicy>ISAF</TrackSecurityPolicy>
<SecurityClassificationExtended>RESTRICTED</SecurityClassificationExtended>
<Time>
<Day>27</Day>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX C to ADatP-36
</Time>
<Location>
<Hyphen>-</Hyphen>
</Location>
<HorizontalAccuracy>10</HorizontalAccuracy>
<Altitude>0</Altitude>
<VerticalAccuracy>10</VerticalAccuracy>
<TrackIdentificationData>
<UnitSymbol>SFGPUCIZ---EUSG</UnitSymbol>
<SymbolStandard>APP-6(A)</SymbolStandard>
<UnitShortName>2ND MECH COMP</UnitShortName>
<GroupOfFields>
<OtherId>
<UnitIdentificationCode>
<ArmedService>A</ArmedService>
<FileSequentialLocationNumber>147501</FileSequentialLocationNumber>
</UnitIdentificationCode>
</OtherId>
</GroupOfFields>
</TrackIdentificationData>
<OperationalStatus>
<Alert>YES</Alert>
<Footprint>10</Footprint>
<Strength>1</Strength>
<Status>1</Status>
</OperationalStatus>
<NatureOfEmergency>
<TextIndicator>NATURE OF EMERGENCY</TextIndicator>
<FreeText xml:space="preserve">TIC</FreeText>
</NatureOfEmergency>
</TrackInformation>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX C to ADatP-36
MESSAGE MODELS
Figure 7 NFFI Message Data Model

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX C to ADatP-36
Figure 8 FFI MTF Message Model

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX D to ADatP-36
– TECHNICAL SPECIFICATION – BUSINESS RULES
Generally the technical business rules are to be derived from the requirements originated from
the operational environment. The business rules complement the aspects already addressed
in this document. Business rules in this standard are expressed in natural language in one of
two forms:
 Imperative. An imperative rule is a statement of what shall be under the conditions specified
in the rule. For example, ‘the received information shall be used as static information until
such time the data is updated by a new report.’
 Conditional Imperative. A conditional imperative rule is a statement of what shall be, in the
event of another condition being met. For example, ‘if a nation captures data on another
nation’s transport package, then it SHALL transmit that information to the owner of the
transport package.’
In either of these two forms of business rule, the associated action that is required may be
RECOMMENDED rather than essential, which is the norm. In that instance the word ‘SHALL’
is replaced with the word ‘MAY’.
USE OF APP-6 SYMBOL CODING
BR-Symbol-1. The use of the symbol codes in accordance with APP-6(A) [Ref 16] or
APP-6(B) [Ref 30] is mandated.
In the FFI MTF, the TrackIdentificationData Element contains two fields to exchange the
relevant symbol for the track: the UnitSymbol field and the SymbolStandard field, as explained
in ANNEX B.
BR-Symbol-2. If no value is provided for the SymbolStandard field, the content of the
UnitSymbol field SHALL be interpreted to be based on APP-6(A).
In APP-6, the Symbol ID code (the content of the UnitSymbol field) is an alphanumeric code
based on a structure that provides the minimum elements required to construct the basic icon
and/or a complete symbol. Note: Current FFI MTF message schema only complies with APP-
6(A) or APP-6(B). Changes to APP-6 may imply changes to the message schema.
Table 6 below shows the basic structure of the Symbol ID code. The exact details and permitted
values of each position are specified in APP-6(A) [Ref 16] and APP-6(B) [Ref 30].
D-1 Edition A Version 2

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX D to ADatP-36
Table 6 Structure of APP-6(A)/APP-6(B) Symbol ID code
Position Content
1 Coding Scheme
2 Affiliation
3 Battle Dimension
4 Status
5-10 Function ID
11-12 Size/Mobility
13-14 Country Code56
15 Order of Battle
Examples include:
 SFGPUCIZ---EUKG representing a United Kingdom Mechanized Infantry Company
belonging to the Ground ORBAT
 SFGPUCAT---APLG representing a Polish Armoured Track Unit of size Team (such as a
Tank) belonging to the Ground ORBAT
 SFGPUCFRMSEFNLG representing a Netherlands Self-Propelled Multi-Rocket Launcher
Task Force Battalion belonging to the Ground ORBAT
 SFFPGSR----DUSG representing a United States SOF Ranger Platoon belonging to the
Ground ORBAT
MANDATORY SYMBOL FIELDS

The following fields within the UnitSymbol field are mandatory for FFI messages:
Coding Scheme
This indicates the overall symbology set to which the symbol belongs.
BR-Symbol-3. For FFT, the APP-6(A)/APP-6(B) coding scheme SHALL be limited to

the value “S” (Warfighting).
Affiliation
7
Affiliation refers to the relationship of the reporter to the operational object being represented.
The basic affiliation categories are unknown, friend, neutral, and hostile.
BR-Symbol-4. For FFT purposes, the APP-6 affiliation code SHALL be limited to
values “F” (Friend) and “N” (Neutral) of self-reported units.
Battle Dimension
Battle dimension defines the primary mission area for the operational object within the
battlespace. An object can have a mission area above the earth's surface (i.e., in the air or
outer space), on the earth's surface, or below the earth's surface. If the mission area of an
5 The country codes in the symbol ID code conform to [Ref 2] in accordance with APP-6(A) [Ref 16]
and APP-6(B) [Ref 30].
6 The country code SHALL be interpreted as the country code belonging to the unit that is reported in
the track.
7 The term “affiliation” in this standard is used synonymously with the term “identity”. This standard
uses the definitions of the standard identities as specified in STANAG 1241, Edition 5 [Ref 15].
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX D to ADatP-36
object is on the earth's surface, it can be either on land or sea. The land dimension includes
those mission areas on the land surface or close to the surface (e.g., land mines and
underground shelters), whereas the sea surface dimension includes only those objects whose
mission area is on the sea surface.
BR-Symbol-5. For FFT purposes, the Battle Dimension position of the Symbol ID code
SHALL be filled, but it MAY contain any permitted value from the used symbology
standard.
Status
This code indicates whether the information of the track is current or anticipated/planned.
BR-Symbol-6. For FFTS, the APP-6(A)/APP-6(B) code for the status SHALL be fixed
to “P” (Present).
Unused positions
Any of the other positions of the APP-6(A)/APP-6(B) Symbol ID code could not be filled or only
partially filled. Due to the 15-character fixed length string for the overall Symbol ID code, those
positions have to be filled with a default character.
BR-Symbol-7. As defined by APP-6(A) and APP-6(B), unused positions in the Symbol

ID code field SHALL be filled with dashes (“-“).
DEFAULT SYMBOL FIELDS

Friendly “Blue Dot”
BR-Symbol-8. If no UnitSymbol field is included in the track, it is assumed that only

“Blue Dot” or minimum data elements are provided with the minimum position report
information.
BR-Symbol-9. The default value to represent Friendly Force objects without explicit
Unit Symbol information in line with APP-6(A)/APP-6(B) SHALL be:
SFGP-----------
Neutral “Blue Dot”

In order to differentiate between a Friendly minimum data track and a Neutral minimum data
track, the neutral track must contain a Symbol ID code that expresses the neutral identity.
BR-Symbol-10. All the FFI reports with an identity different from “Friend” SHALL
include in the message a valid value for the appropriate identity in the UnitSymbol’s
Affiliation field in the UnitSymbol field.
For example, for a civilian vehicle the symbol that shall be used in line with APP-6(A) is:
 SNGPEVC--------
UNIQUE TERMINAL IDENTIFICATION (UTID)

Unique identification is mandatory for coherent data management. In FFT the unambiguous
association of data with an identifier mandates a controlled dissemination of unique terminal
identifications (UTID). In view of the options for individually controlled distribution of terminal
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX D to ADatP-36
IDs or generation and distribution at highest possible level, the latter is the only suitable solution
for assuring uniqueness within the whole system. Considering national, NATO, multinational
(non-NATO), and coalition (NATO and other nations) operations, the prerequisite for the
required integrity of FFI data is a standardised identifier for all FFTS.
BR-UTID-1. UTID MUST be unique among systems operating within an FFT network.
BR-UTID-2. All systems utilising FFTS data SHALL allow processing of the FFT Unique
Terminal ID (UTID) which is defined as the combination of the mandatory FFI System
and TransponderId fields.
BR-UTID-3. In order to make the uniqueness of FFT Terminals easy to manage and
configure, every system owner SHALL ensure that each UTID generated by his system
at no time is used more than once.
BR-UTID-4. Network management authority SHALL coordinate UTIDs for every real
operation or exercise to ensure that every system uses a different system name and
include a comprehensive list of system names in the FFT network design configuration.
ALERT/EMERGENCY
While the intent of the OperationalStatus/Alert field is to be used for Emergencies, it may
erroneously be used by organizations for testing systems, inadvertent use, or misguided use.
In order to ensure appropriate actions are taken in the event of a true emergency, and to
prevent unnecessary actions taken to respond to non-emergency alerts, appropriate Tactics,
Techniques and Procedures (TTPs) need to be put in place between coalition Operations
Centers. This may be as simple as a phone call notification to inform the owning Operations
Center or Data Owner that an Alert has been received and to get positive verification of the
Alert.
BR-Alert-1. Only if an FFT Terminal is in an emergency state, SHALL the Alert field be
set to the value ‘YES’.
BR-Alert-2. If the Alert field is set to ‘YES’, the detailed nature of the emergency may
be explained in the following GENTEXT set, with TrackInformation/
NatureOfEmergency/TextIndicator set to ‘NATURE OF EMERGENCY’ and the
TrackInformation/NatureOfEmergency/FreeText field using the standard brevity texts
as listed in
Table 7.
BR-Alert-3. The network operational authority SHALL specify rules for using the Alert
flag in a Standard Operating Procedure or equivalent operational instruction. This
specification SHALL include conditions, when an Alert MAY be set, which value will be
used in the field NatureOfEmergency/FreeText, who in the network has the
responsibility to set/reset the Alert, which actions will be expected on receipt of an Alert
in combination with the NatureOfEmergency/FreeText field.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX D to ADatP-36
Table 7 Emergency Conditions
Text for ‘Nature of Emergency’
Condition field
Bomb Threat BOMB THREAT
Chemical, Biological, Radiological, Nuclear (CBRN) CBRN
Communication COMMS
Emergency EMERG
Improvised Explosive Device (IED) IED
Medical Evacuation (MEDEVAC) MEDEVAC
Military Operations Other Than War MOOTW
Riot RIOT
Troops in Contact (TIC) TIC
Terminal lost or compromised TERM LOST
Other As needed
TIME REFERENCE
All Friendly Force Tracking Systems and their associated reporting rely on time information.
Timestamps appear in the IP1/IP2 header and the timestamp within the message header and
reported track information. Without proper arrangements for time synchronization there is a risk
of losing or misinterpreting vital information.
BR-Time-1. All timestamps SHALL be based on the Coordinated Universal Time

(UTC).
BR-Time-2. Systems that are using GPS-derived time SHALL convert all timestamps
to UTC time for the reporting and transmitting of track information and assume that
received track information is UTC based and apply the respective conversion to GPS
time.
FORWARDING TRACKS
BR-Forward Tracks-1. FFT Gateways, Hubs, and Proxies SHALL always
forward/process tracks unless the blue dot fields are invalid (i.e. contain invalid content
according to the standard). If other fields are invalid, those fields MUST be nilled if they
are mandatory, or removed if they are OPTIONAL.
BR-Forward Tracks-2. Gateways, Hubs and Proxies SHALL process and forward
tracks received.
BR-Forward Tracks-3. If any information on a specific track (identified by UTID)

changes, it MAY be updated in the receiving system.
BR-Forward Tracks-4. If an optional attribute that was previously sent is no longer

sent, the receiving system MAY keep the previous attributes associated to the track.
This does not apply to the Alert field.
BR-Forward Tracks-5. The sending system MUST NOT assume that previously sent
information has been stored in a receiving system.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX D to ADatP-36
BR-Forward Tracks-6. A FFT Hub MAY forward invalid tracks, when it does not
validate messages.
DATA COMPRESSION RULES

The FFI IP1/IP2 header encoding field allows application of a compression algorithm to the FFI
payload. The FFI payload may be compressed. The business rules for FFI data compression
are:
BR-Compression-1. All FFI data producers SHALL be able to provide FFI data in an
uncompressed format.
BR-Compression-2. All FFI data consumers SHALL be able to receive FFI data in an
uncompressed format.
BR-Compression-3. If compression is used by a data producer the DEFLATE

algorithm SHALL be used and it SHALL comply with the Internet Engineering Task
Force (IETF) Request for Comment (RFC) 1951 [Ref 7] and in particular not contain the
ZLIB header as specified in IETF RFC 1950 [Ref 6].
BR-Compression-4. There SHALL be agreement between the FFI data producer and
the FFI data consumer on the use of a compression algorithm.
BR-Compression-5. The payload length in the IP1/IP2 header SHALL refer to the
compressed payload length.
BR-Compression-6. If compression is used in combination with IP2, the FFI data

producer SHALL compress the payload before it is segmented into multiple UDP
packets and transmitted.
BR-Compression-7. If compression is used in combination with IP2, the FFI data

consumer SHALL reassemble all packets before uncompressing the payload.
AUGMENTATION AND SANITIZATION SPECIFICATION
DEFINITION
Augmentation is the process to enhance and enrich information (add/modify) of an existing
Tracked Object. The augmented information can add extra information or can add more
accurate and reliable information to the existing information.
Sanitization is the reverse process, to remove selected information from a Tracked Object,
without touching the consistency of the set of minimum data elements as defined by BR-
Minimum FFI-1.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX D to ADatP-36
Table 8 Principle Structure of Augmentation Data
Correlation Security of Table Security of

Key Entry Augmentation Data Augmented Data
UTID Security marking of Country - Unit Symbol Unit Short ...

Security marking of Blue Dot
- System Augmenting Data of the - Standard Name plus Augmenting Data
- Transponder - Policy System - Policy
ID - Classification - Classification
- Category - Category
Example
- FISH - NATO - DEU - SFGPUCR--- - 2nd ... - NATO

- DEU123456 - RESTRICTED -BGMG RECCE - CONFIDENTIAL
- REL TO ISAF - APP-6(A) Squad - None
REASONS FOR AUGMENTATION AND SANITIZATION

Security
BR-Augment-1. Data sanitization MAY be done to remove sensitive information, in
some cases, it is necessary to remove certain fields due to security reasons. If track
data, coming from the tactical level arrives at a domain with higher security level,
augmentation information MAY be added.
Bandwidth
BR-Augment-2. Data sanitization MAY be done to limit the transmitted information.
The transmission bandwidth to remote Gateways can be very limited and in some cases
very expensive. The information that is normally static MAY be eliminated from the
message and then recomposed in the remote Gateway with augmentation information
in a local database.
Extra information
BR-Augment-3. Data augmentation MAY be done to incorporate information from a
different data source or interface that MAY be added to received information about an
FFT entity. For example, an FFT Proxy can have additional information about an FFT
entity that will allow augmenting the received information.
PLACE FOR AUGMENTATION AND SANITIZATION

Track Augmentation and Sanitization are network roles, independent from other roles. They
may be located centrally near FFT Hubs or FFT Proxies, or decentralized near FFT Gateways
or Security Domain borders. In any case the network design must consider positioning the
Augmentation and Sanitization roles into places, from where the distribution to all necessary
Track consumers is possible, Track duplication is prevented, and the proper security levels are
applied.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX D to ADatP-36
BR-Augment-4. Roles that augment tracks and then retransmit them via the IP1 or IP2
protocol SHALL ensure that the size of the new message does not exceed the permitted
message size of these protocols after augmentation.
AUGMENTABLE INFORMATION
Augmentation Parameter Types
BR-Augment-5. The following types of augmentation data MAY be included when
augmentation is performed:
 DI - Dynamic Information (e.g., Time, Location, Altitude) will change very often.
 SD - Semi-Dynamic (e.g., Planned location, Operational Status) will change, but
normally not very often.
 SS - Semi-Static Information (e.g., unit short name) can change, but not often.
 SI - Static Information (e.g., Nationality, TransponderId) will rarely ever change.
Track Information
Table 9 Track Augmentation Information
Value Type of Parameter Place for Augmentation

TrackSource
Subsystem (Source) Static Information Terminal, Gateway
Nationality Static Information Terminal, Gateway
Reliability Static Information Terminal, Gateway
Credibility Static Information Terminal, Gateway
TrackSecurityLabel
TrackSecurityClassification Semi-Static Information Gateway, Hub
TrackSecurityCategory Semi-Static Information Gateway, Hub
BlueDotSecurityClassification Semi-Static Information Gateway, Hub
BlueDotSecurityCategory Semi-Static Information Gateway, Hub
DetailsSecurityClassification Semi-Static Information Gateway, Hub
DetailsSecurityCategory Semi-Static Information Gateway, Hub
TrackPositionalData
Time Dynamic Information Terminal, Proxy
Location Dynamic Information Terminal, Proxy
HorizontalAccuracy Dynamic Information Terminal, Proxy
Altitude Dynamic Information Terminal, Proxy
VerticalAccuracy Dynamic Information Terminal, Proxy
TrackMovementData
Bearing Dynamic Information Terminal, Proxy
BearingAccuracy Dynamic Information Terminal, Proxy
Speed Dynamic Information Terminal, Proxy
SpeedAccuracy Dynamic Information Terminal, Proxy
Inclination Dynamic Information Terminal, Proxy
InclinationAccuracy Dynamic Information Terminal, Proxy
TrackPlannedLocation
EstimatedTimeOfArrival Semi-Dynamic Terminal, Gateway

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX D to ADatP-36
Value Type of Parameter Place for Augmentation
PlannedLocation Semi-Dynamic Terminal, Gateway
EstimatedTimeOfDeparture Semi-Dynamic Terminal, Gateway
TrackIdentificationData
UnitSymbol Static Information Terminal, Gateway, Hub, Proxy
SymbolStandard Static Information Terminal, Gateway, Hub, Proxy
UnitShortName Static Information Terminal, Gateway, Hub, Proxy
OtherId Static Information Terminal, Gateway, Hub, Proxy
OperationalStatus
Alert Semi-Dynamic Terminal, Gateway, Proxy
Footprint Semi-Dynamic Terminal, Gateway, Proxy
Strength Semi-Dynamic Terminal, Gateway, Proxy
PersonnelStrength Semi-Dynamic Terminal, Gateway, Proxy
Status Semi-Dynamic Terminal, Gateway, Proxy
NatureOfEmergency
TextIndicator Semi-Dynamic Terminal, Gateway, Proxy
FreeText Semi-Dynamic Terminal, Gateway, Proxy
DetailData
TextIndicator Semi-Dynamic Terminal, Gateway, Proxy
FreeText Semi-Dynamic Terminal, Gateway, Proxy
FFI TRACK AGING
TRACK AGING DEFINITION

FFI track aging is a way of determining when an FFI track is active, inactive or needs to be
dropped/deleted. The following paragraphs discuss each aging category and provide business
rules for handling of the FFI track in each category.
To determine which category a track belongs to, there are time periods that must be defined
and agreed upon. All of the time periods shall be part of the network design for any specific
exercise or mission network which will allow for the Situational Awareness (SA) to be the same
for all the systems of the network.
BR-Aging-1. Periods for track aging SHALL be defined for a network by the network
management authority and applied by all systems
FFI TRACK AGING CATEGORIES

Active FFI Track
BR-Track Age-1. An FFI track that has been received or updated within a specified
time period SHALL be considered active.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX D to ADatP-36
BR-Track Age-2. An FFI track SHALL be considered to be updated if a newly received
FFI track:
 Represents an FFI track that does not currently exist in the FFTS, or
 Has a timestamp that is newer than the current timestamp for an existing FFI track.
Inactive FFI Track
BR-Track Age-3. An FFI track that has not been received or updated within a specified
time period is considered inactive.
Dropped FFI Track
BR-Track Age-4. An FFI track that has not been received or updated after a specified
time period is considered to be a track that shall be dropped or deleted from an FFTS..
Systems should take in consideration the operational consequences of dropping tracks. As

already described in the 3.6 it makes a difference if a track is describing a fast-moving vehicle
or a stationary command post. A system should balance this and find the most optimal update
rate for each type of tracks received.
BR-Track Age-5. An FFT Hub or FFT Proxy, or FFT Augmentation/Sanitization role

SHALL NOT suppress tracks if they are received with a timestamp older than the
specified time period for dropped tracks.
DUPLICATE AND FUTURE TRACKS

Duplicate tracks are tracks for which information with the identical UTID and timestamp or
newer information has already been received by a specific role. As there are in principle no
storage requirements from this interoperability standard, except for the SIP3 and WSMP
interface, there are no mandatory requirements for recognition and special processing of
duplicate tracks.
BR-Duplication-1. An FFT role MAY implement capabilities to identify duplicate tracks.
BR-Duplication-2. An FFT Gateway MAY decide to not forward duplicate tracks to its
connected FFT Terminals or to the FFI network.
BR-Duplication-3. An FFT Hub, FFT Proxy or FFT Augmentation/Sanitizing role

SHALL NOT suppress duplicate tracks.
BR-Duplication-4. An FFT Hub or FFT Proxy SHALL NOT generate duplicate track
updates, if no new messages are received.
Future tracks are tracks that are received with a timestamp that is in the future of the receiving
system time. This could either be due to small deviations of system clocks, wrong time settings
in the sending or receiving system or an error in forwarding/translations.
Like for track aging, a time period must be defined and agreed upon, in which future tracks are
acceptable. The time period shall be part of the network design for any specific exercise or
mission network which will allow for the Situational Awareness (SA) to be the same for all the
systems of the network.
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX D to ADatP-36
BR-Future-1. Periods for future tracks SHALL be defined for a network by the network
management authority and applied by all systems
BR-Future-2. If a track is received with a timestamp that is after the current time of the
receiving role, but within the agreed tolerance window, the track SHALL be processed.
BR-Future-3. If a track is received with a timestamp that is after the current time of the
receiving role, and beyond the agreed tolerance window, the track SHALL be dropped
by any role and not processed.
SPECIFIC RULES FOR AN FFT HUB
BR-FFT Hub-1. The FFT Hub SHALL be able to:

 Receive FFI tracks from Gateways, Hubs, and Proxies.
 Disseminate FFI tracks to Gateways, Hubs, Proxies and Consumers.
 Perform filtering by System name (minimum implementation).
 Not send track data back to the originator to prevent data looping.
 Modify the FFI IP1/IP2 header with the source system information (system,
subsystem), a new timestamp, and – if applicable – update encoding and payload
length.
BR-FFT Hub-2. The FFT Hub MAY be able to apply compression and decompression.
BR-FFT Hub-3. In principle, all messages that are received by the central FFT Hub are
transmitted to all connected FFT Gateways, Proxies or Hubs.
BR-FFT Hub-4. The FFT HUB SHALL prevent FFI messages being sent to those
Gateways, Proxies or Hubs that originally reported the information.
BR-FFT Hub-5. The FFT Hub MAY be able to compound multiple tracks into one
message.
SPECIFIC RULES FOR AN FFT PROXY
BR-FFT Proxy-1. The FFT Proxy SHALL have the capability to convert from at least
one protocol or standard to FFI MTF or from FFI MTF to at least one other protocol or
standard. The system is NOT REQUIRED to convert in both directions to be considered
an FFT Proxy.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX D to ADatP-36
BR-FFT Proxy-2. If the FFT Proxy is converting to FFI MTF, it SHALL be able to:
 Disseminate FFI tracks to Gateways, Hubs, Proxies and Consumers.
 Perform filtering by System name (minimum implementation).
 Create an FFI IP1/IP2 header where the source system information (system,
subsystem) is set to the FFT Proxy system’s information and the timestamp is set
to the current time.
- The contents of the IP1/IP2 header MUST conform to the rules for
transmission in this specification (e.g. the payload length MUST be set
correctly).
- If valid values cannot be translated for other IP1/IP2 header fields, then default
values SHOULD be used.
BR-FFT Proxy-3. If the FFT Proxy is converting to FFI MTF, it MAY be able to apply
compression.
BR-FFT Proxy-4. If the FFT Proxy is converting from FFI MTF, it SHALL be able to:
 Receive FFI tracks from Gateways, Hubs, and Proxies.
 Produce compliant FFI track messages in at least one other protocol or standard.
BR-FFT Proxy-5. If the FFT Proxy is converting from FFI MTF, it MAY be able to apply
decompression.
BR-FFT Proxy-6. The FFT Proxy SHALL NOT convert data to or from FFI MTF that
violates the standards of either related protocol.
BR-FFT Proxy-7. The FFT Proxy SHOULD conform to the mapping guidance provided
in ANNEX G. If relevant mapping guidance is absent from ANNEX G, systems of
protocols other than FFI MTF SHOULD provide their mapping guidance.
BR-FFT Proxy-8. The FFT Proxy MAY be able to compound multiple tracks into one
message.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
– TECHNICAL SPECIFICATION – WEB SERVICES – SIP3
TERMINOLOGY
Below is specific terminology used in this annex:
 SIP3 – the message exchange protocol defined by this annex.
 Data Producer – an application that maintains data about events and is able to answer SIP3
requests.
 Data Consumer – an application that makes SIP3 requests for and consumes data about
events.
 Delivery Mode – the mechanism by which event messages are delivered from the Data
Producer to the Data Consumer in the Push (Publish/Subscribe) scenario.
 Notification – a one-way message sent to indicate that an event has occurred.
 Subscriber – an application that sends requests to create, renew, and/or delete
subscriptions. It MAY coincide with the Data Consumer.
 Subscription Manager – the Data Producer when it accepts requests to manage the status
of, renew, and/or delete subscriptions.
Due to the historical ties with the FFT Community of Interest, the following terms may be used
as well.
 Track consumer – an application that requests tracks from a track server using the SIP3
protocol.
 Track server – a server that maintains information about the tracks and is able to answer
SIP3 requests.
 Pull mode – a delivery mechanism where a data user sends requests to a server as
individual, synchronous Simple Object Access Protocol (SOAP) messages.
 Push Mode - a delivery mechanism where the Data Producer sends event messages to the
Data Consumer as individual, unsolicited, asynchronous SOAP messages.
To correctly interpret the terms and the concepts expressed in this annex the basic knowledge
of the following arguments is required:
 XML format and namespaces
 Friendly Force Tracking
 NFFI-13 Query language
Unless otherwise specified, the namespace prefixes used in this annex MUST be interpreted
as indicated in Table 10:
E-1 Edition A Version 2

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
Table 10 SIP3 Namespaces
Prefix Namespace
nffi-q urn:nato:fft:protocols:nffi13:query
sip3 urn:nato:fft:protocols:sip3
sip3-c urn:nato:fft:protocols:sip3:compression
mtf urn:nato:mtf:app-11(d):1:ffi
nffi urn:nato:fft:protocols:nffi13
sip3-f urn:nato:fft:protocols:sip3:reqresfilter
wse http://schemas.xmlsoap.org/ws/2004/08/eventing
SIP3
This Annex presents the Service Interoperability Profile 3 (SIP3) version 1.2 Web-Service
specifications for exchange of XML-based data. Historically, such data is for Friendly Force
Tracking and the NFFI format may be used.
This technical specification is intended for software developers to implement interoperable

“SIP3 services” and “SIP3 clients”. It describes:
 Architecture
 Application Programming Interface (API)
 Arrangements
 Error Handling
SIP3 ARCHITECTURE
SIP3 specifies a set of Simple Object Access Protocol (SOAP) Web Services that are described
in paragraph E.2.2, “SIP3 API”.
BR-SIP3-1. Any system supporting SIP3 MUST implement the API in conformance
with this specification.
Use of Web Services Standards in SIP3

An overview of the standards adopted in SIP3 is provided in this section.
BR-SIP3-2. Web services: SIP3 version 1.2 SHALL conform to the SOAP 1.1 protocol.
BR-SIP3-3. Basic Profile: SIP3 version 1.2 SHALL conform to the WS-I Basic Profile
1.1 [Ref 18].
BR-SIP3-4. Eventing: The SIP3 version 1.2 push functionality SHALL conform to the
WS-Eventing specification [Ref 20].
BR-SIP3-5. Security: SIP3 version 1.2 does not mandate the usage of security/access
control. If security/access control is implemented it SHALL conform to the WS-Security
specification [Ref 17].

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
Security
BR-SIP3-6. If a data provider does not support the WS-Security specification,

processing a request received by the provider that specifies it MUST NOT fail and the
provider’s server has to discharge the security information.
BR-SIP3-7. If a data provider’s server implements the WS-Security, processing a

request that does not specifies it MAY fail and MAY generate a fault.
General Architecture of the Interface

Two operational modes are defined for the SIP3 services: “push” mode and “pull” mode. The
pull mode is based on the Request/Response interaction pattern and may be used for data
synchronization. The pull mode may also be used to access historical data or, more generally,
to extract data for analytical purposes. The push mode is based on the Publish/Subscribe
interaction pattern and may be used for constant data updates to maintain synchronization. In
an operational scenario it is recommended to use the pull mode to achieve initial
synchronization before switching to the push mode to maintain synchronization.
E.2.1.3.1. Pull Mode

The Pull mode in SIP3 is based on classical Web services Request/Response interaction
pattern as depicted in Figure 9. The process is initiated by a Data Consumer sending a SOAP
message to the Data Provider requesting data. The request message may include a filter that
the Provider should use to select the data to be returned to the Consumer. The Provider sends
a SOAP message back to the Consumer containing the selected data (or containing a fault).
Figure 9 "Pull Data" Mode
Data Consumer Data Provider

Request -
Application query Data Source
Web Service Web Service
Web Service Web Service
Interface Interface
Interface Interface
Response -
data
The filter is not specified in this specification because it depends on the format of the data,
which is not part of this specification by design.
BR-SIP3-8. At run-time, the Producer and Consumer MUST agree on the format of the
data, on the format of the filter and on the rule for binding the data and the filter
messages in the SIP3 messages.
E.2.1.3.2. Push Mode

The Push mode in SIP3 is based on the Publish/Subscribe interaction pattern as depicted in
Figure 10. The process is initiated by a Data Subscriber who sends a SOAP message (1)
requesting a subscription for Data to a Provider (or to a delegated Subscription Manager). The
request specifies details such as subscription name, Consumer address, interval, termination
time, etc. The subscription may also detail a filter for the Producer to select the data of interest
for the Consumer. A SOAP message (2) is sent back to the Consumer confirming that the
subscription was successful (or containing a fault). After successful subscription, the Producer
will send SOAP messages (3) back to the Consumer containing data.
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
Figure 10 "Push Data" Mode
BR-SIP3-9. The specification for the push mode relies on the WS-Eventing
specification. WS-Eventing introduces a default Filter Dialect but other custom dialects
agreed between the Data Subscriber and Data Provider MAY be used.
The Push mode is specified in paragraph E.2.2.2 “Push Service”.
E.2.1.3.3. SIP3 Services interface overview

An overview of the SIP3 service definition is depicted in Figure 11. The
‘SIP3_Service_EventSource’ corresponds with a Data Provider. The ‘EventSource’ and
‘SubscriptionManager’ port-types are re-used from WS-Eventing. The
8
SIP3_Service_TracksPush corresponds with a Data Consumer. This specification includes
the binding of the port-types and all their operations to SOAP transported over HTTP.
8 The name ‘Tracks Push’ is inherited from the track-oriented legacy of SIP3 and may be interpreted as
‘Data Push’
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
Figure 11 SIP3 Service Diagram
E.2.1.3.4. File structure

The schemas and the WSDL files are organized as follows:
 SIP3.xsd: Contains the SIP3 types and the global element schema.
 compressionAlgs.xsd: Contains the compression related elements.
 SIP3_Definitions.wsdl: Is the service interface definition describing the abstract type
interface and the protocol binding.
 SIP3_Service_DecoupledReqRes.wsdl: The service implementation definition for the pull
protocol (request/response).
 SIP3_Service_TracksPush.wsdl: The service implementation definition for the push
protocol (subscription based on WS-Eventing).
 SIP3_delivery_decoupled_batched.xsd: Schema for the delivery batched mode
(subscription based on WS-Eventing).
SIP3 API
The SIP3 Pull Service and Push Service are specified in this paragraph. It explains how the
services are defined, and how the design has de-coupled message formats and filter
languages used by a particular COI from the service definitions. It also explains how a COI
must ‘re-couple’ the message formats and filter languages used at run-time. The examples in
this paragraph use the NFFI V1.3 message format and the “urn:nato:fft:protocols:nffi13:query”
filter language.
BR-SIP3-10. Other message formats and filter dialects mutually supported by a Data
Producer and Data Consumer MAY be used.
Pull Service
The Request/Response (pull) service consists of a single operation for request/response where
the type of the message and the filter are not explicitly defined. The service requires that the
Data Consumer’s request at run-time states the desired format for the data to be provided in,
and that the Data Provider’s reply states the format of the provided data. Furthermore, the
Consumer’s request must state the ‘dialect’ of the filter. This approach allows the SIP3 design
to be decoupled from the message formats and filter languages used by a particular COI. The

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
request and the response messages are defined in the SIP3.xsd file under the namespace
“urn:nato:fft:protocols:sip3”.
E.2.2.1.1. Data Compression
BR-SIP3-11. The Consumer MAY request to receive a compressed payload specifying

one or more supported compression algorithms in the message header of the pull data
request.
BR-SIP3-12. In case the Provider supports a compression algorithm specified by the

Consumer, the selected data SHALL be sent back compressed, within the SOAP
envelope.
BR-SIP3-13. If none of the algorithms specified in the pull data request is supported by
the Provider, the selected data SHALL be sent in plain text.
The XML elements used to specify the compression are defined in the compressionAlgs.xsd
under the namespace “urn:nato:fft:protocols:sip3:compression”.
BR-SIP3-14. Compression SHALL be applied to the returned data only.
BR-SIP3-15. Data compression MUST be performed using the requested compression

algorithm, it MUST be encoded in base64Binary format and it MUST be included as a
text string in the response Message element.
E.2.2.1.2. Data Request Message

A message requesting a data-pull from a producer is depicted in XML-Code 3.
XML-Code 3 Pull NFFI Track Data Request Message
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sip3="urn:nato:fft:protocols:sip3"

xmlns:cmp="urn:nato:fft:protocols:sip3:compression" xmlns:qry="urn:nato:fft:protocols:nffi13:query">
<soapenv:Header>
<sip3:CompressionAlgsSupported>
<cmp:compression>NONE</cmp:compression>
</sip3:CompressionAlgsSupported>
</soapenv:Header>
<soapenv:Body>
<sip3:SIP3DataRequest>
<sip3:ResponseDialect>urn:nato:fft:protocols:nffi13</sip3:ResponseDialect>
<sip3:Filter Dialect="urn:nato:fft:protocols:sip3:reqresfilter">
<sip3:ReqResFilter>
<qry:NFFIFilter>
…………..
</qry:NFFIFilter>
</sip3:ReqResFilter>
</sip3:Filter>
</sip3:SIP3DataRequest>
</soapenv:Body>
</soapenv:Envelope>
In this example message, the producer is a ‘FFT Track Server’ and can provide data about FFT
tracks. In the header, no compression is requested with the indicated value of ‘NONE’ being a
reserved keyword indicating that data compression is not requested. The keyword ‘NONE’
could be substituted by any keyword the Data Consumer and Data Producer agree to indicate
the compression algorithm such as ‘GZIP’. The message states that the data must be returned
using the NFFI V1.3 message format, and that the tracks must match the rules indicated in the
filter expressed in “urn:nato:fft:protocols:sip3:reqresfilter” format.
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
The XML schema of the pull request message is depicted in Figure 12.
Figure 12 Pull Request Message schema
The following describes the normative constraints on the request elements.
BR-SIP3-16. /SIP3DataRequest/ResponseDialect – The ResponseDialect is of type

xs:anyUri and states the requested format for the data in the response message. The
response dialect URI MUST be mutually agreed upon by the Consumer and Provider.
If the Provider does not support the requested dialect it MUST return an
UnsupportedResponseDialect fault indicating the supported dialects. The field is
OPTIONAL. The default value is implementation dependent.
BR-SIP3-17. /SIP3DataRequest/Filter – The Filter is of type xs:any and states the filter
to apply to the data. Only the data that matches the filter MUST be returned by the track
server. The field is mandatory.
BR-SIP3-18. /SIP3DataRequest/Filter@Dialect – the Dialect is of type xs:anyUri and

states the dialect used to express the filter. If the server does not support the requested
dialect it MUST return an UnsupportedFilterDialect fault indicating the supported
dialects. The field is OPTIONAL. The default value is implementation dependent.
E.2.2.1.3. Response message
The response message is composed of a SIP3 envelope containing the message payload.
BR-SIP3-19. During the payload inclusion in the SIP3 message all the rules dictated
by the payload standard MUST be honoured.
There are cases of requests in which the data Provider cannot return the required information
in a single payload message. Such is the case for a request for FFT information in FFI MTF
format in which the returned FFT data would be marked with multiple security policies and the
merging of such information is excluded by security rules. Because the SIP3 protocol expects
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
a single response message in response to a request and because a response message can
contain only one message payload this case cannot be handled by the SIP3 protocol.
BR-SIP3-20. If for any reason the data Provider cannot compound the data selected
by the data Consumer in a single payload message, the Provider MUST return a
MultiplePayloadNotSupported fault. The fault SIP3FString element MUST be completed
with explicit indication of the fault reason including, where available, information on how
to request valid messages. That means if the message cannot be compounded because
of multiple security policies the SIP3FString MUST contain the list of the security
policies the producer was trying to compound.
An example of a SOAP response message containing non-compressed data is depicted below.

The NFFI V1.3 NFFIMessage is the data. It is also stated by the Producer that not all available
data was transferred. The Consumer may avoid subsequent loss of data by adapting the query
to match less data.
XML-Code 4 Pull NFFI Message
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<CompressionAlgUsed xmlns="urn:nato:fft:protocols:sip3">NONE</CompressionAlgUsed>
</soapenv:Header>
<soapenv:Body>
<SIP3DataResponse xmlns="urn:nato:fft:protocols:sip3">
<allAvailableDataTransferred>false</allAvailableDataTransferred>
<Message Dialect="urn:nato:fft:protocols:nffi13">
<NFFIMessage xmlns="urn:nato:fft:protocols:nffi13">
<track xmlns:sip3="urn:nato:fft:protocols:sip3" xmlns:nffi="urn:nato:fft:protocols:nffi13">
……..
</track>
</NFFIMessage> </Message>
</SIP3DataResponse>
</soapenv:Body>
</soapenv:Envelope>
The XML schema of the pull response message is depicted in Figure 13. Note that the element
NFFIMessage is not part of the structure.
Figure 13 Decoupled Response Message

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
Reponses to SOAP requests can take one of two forms: success or error. In case of success
the Producer shall send a Message element containing the (compressed) data. If no data meets
query conditions, the Message element will exist but be empty.
The following rules describe the normative constraints on the response elements:
 //SIP3DataResponse/allAvailableDataTransferred – The allAvailableDataTransferred is of

type xs:boolean and states if the Producer could transfer all the data matching the query,
or not.
BR-SIP3-21. The value of the allAvailableDataTransferred element SHALL be set to
“true” when all available data was transferred. It SHALL be set to “false” if data has
been dropped by the sender to reduce the size of the returned message or to respect
the MaxFrame filter parameter or for any other reason.
 //SIP3DataResponse/Message – The Message element is of type xs:any. It contains the

actual content of the response.
BR-SIP3-22. The Message element SHALL contain the data matching the query
expressed in the dialect requested by the Consumer.
BR-SIP3-23. //SIP3DataResponse/Message@Dialect – The Dialect attribute SHALL

state the dialect/format of the data.
BR-SIP3-24. The Consumer MAY drop the received message, if the Dialect attribute
does not match the requested ResponseDialect.
E.2.2.1.4. Error message
BR-SIP3-25. In case of error, a standard SOAP fault message SHALL be generated.

Error message handling is discussed in paragraph E.2.3.3 “SIP3 Standard Error
Handling” of this annex.
Push Service
To specify the publish-subscribe interaction pattern for SIP3, the WS-Eventing specification
has been re-used. A detailed discussion about WS-Eventing is beyond the scope of this
specification.
BR-SIP3-26. The Producer (Source) and the Consumer (Sink) MUST follow the WS-
Eventing rules.
WS-Eventing introduces the notion of a “delivery mechanism” which specifies how a Consumer
is to be ‘notified’ by a Producer. A new “delivery mechanism” is specified in this document which
better suits the needs of SIP3 regarding message flow control.
Leveraging the extensibility of the WS-Eventing specification, an additional subscription

parameter is introduced in the subscription message to state the format/dialect for the data it
should receive.
To increase the independency of the SIP3 protocol from a COI-specific message format the
filtering dialect for the WS-Eventing is part of another specification.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
BR-SIP3-27. The Producer and Consumer MUST mutually agree upon the filter dialect
used during subscription and on the rule for binding the agreed filters in the SIP3
subscription messages.
The customized messages sections are defined in the SIP3.xsd file under the namespace
“urn:nato:fft:protocols:sip3”.
E.2.2.2.1. Data Compression
The PUSH service may have the capability to compress data matching the filter.
BR-SIP3-28. The Consumer MAY request data to be compressed by stating one or

more preferred compression algorithms.
BR-SIP3-29. If the Producer supports one of the compression algorithms specified by

the Consumer the selected data SHALL be sent compressed to the Consumer.
BR-SIP3-30. If none of the algorithms specified in the request is supported by the

Provider, the selected data SHALL be sent in plain text.
The XML elements used to specify the compression are defined in the compressionAlgs.xsd
under the namespace “urn:nato:fft:protocols:sip3:compression”. The compression protocol will
be discussed later in the paragraph E.2.3.2 “Compression”.
E.2.2.2.2. Delivery mechanisms
BR-SIP3-31. The WS-Eventing defines a single delivery mode, Push Mode, which is
simple asynchronous messaging. This standard delivery mode is not tailored for our
usage inside the FFT COI so it SHOULD NOT be used and supported.
BR-SIP3-32. A new delivery mode that allows improved flow control SHOULD be used.
The new delivery mode is identified by the following namespace:
 urn:nato:fft:protocols:sip3:delivery:decoupled_batched
 The structure for subscribing with this mode can be found in the file
“SIP3_delivery_decoupled_batched.xsd”.
The flow of messages sent between the Producer and Consumer may be reduced by batching
data into a single message.
E.2.2.2.2.1. Elements detail
The following describes the normative constraints on the elements.
BR-SIP3-33. MinTime – of type xs:long and states the Minimum delay in seconds
between two consecutive deliveries. In case messages are generated at higher
frequency than the one expressed by MinTime the producer MUST cache those
messages and MUST send them at the expiration of the minimum delay time. The field
of type long. The field is mandatory.
BR-SIP3-34. Heartbeats – of type xs:boolean and states if it is required to send always

a data message when the minimum delay has expired even though there is no data to
send, in this case an empty message MUST be sent. The field is OPTIONAL and the
default value is true.
E.2.2.2.2.2. Delivery Behaviour

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
BR-SIP3-35. A WS-Eventing Provider supporting “urn:nato:fft:protocols:
sip3:delivery:decoupled_batched” SHALL send a message to the Consumer with a
frequency corresponding with the MinTime stated by the Consumer during subscription.
It is presumed the Provider starts with an empty buffer and MinTime is reset.
BR-SIP3-36. The Producer SHALL store new data in the buffer until the MinTime
expires and ‘flushes’ the buffer content to the Consumer after applying the filter, and
resets the MinTime.
BR-SIP3-37. If the buffer is empty when MinTime expires because nothing of interest
happened since the last flush, the Provider MUST send an (empty) message (without
data) if Heartbeats is true. If Heartbeats is false, the Provider MUST NOT send any
message to the Consumer.
In case the Consumer is not reachable or is temporarily disconnected, the following rules apply:
BR-SIP3-38. If the Consumer is not reachable, the Producer SHALL cache the
undelivered data and SHOULD attempt to send the messages at a configurable
frequency and for a configurable number of attempts.
BR-SIP3-40. In case the size of the cached data exceeds the cache dimension the
Producer MAY remove the oldest data from the cache.
BR-SIP3-41. If the configurable number of attempts to resend is exceeded, the

consumer’s connection SHALL be considered lost, the subscription SHALL be removed
and the related cache SHALL be emptied. If the subscriber has indicated at the
subscription a wse:EndTo, a wse:SubscriptionEnd message indicating the reason for
subscription removal SHALL be sent to that endpoint.
There are cases of subscriptions in which the data Provider cannot forward the required
information in a single payload message. Such is the case for a subscription to FFT information
in FFI MTF format in which the returned FFT data would be marked with multiple security
policies and the merging of such information is excluded by security rules.
BR-SIP3-42. If for any reason the data Provider cannot compound the data selected
by the data consumer in a single payload message, the Provider MUST generate
multiple payloads and send them separately via consecutive deliveries, one for each
generated payload.
E.2.2.2.2.3. Subscription Example

Below is an example of subscription with the delivery protocol batched with the relevant parts
in red.
XML-Code 5 Subscription Example
<s:Envelope
xmlns:s=http://www.w3.org/2003/05/soap-envelope
xmlns:a=http://www.w3.org/Submission/ws-addressing
xmlns:dmb="urn:nato:fft:protocols:sip3:delivery:decoupled_batched"
xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing">
<s:Header>
.......
.......
</s:Header>
<s:Body>
<wse:Subscribe>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
<wse:EndTo>
<a:Address>http://localhost:8080/SubscriptionEnd</a:Address>
</wse:EndTo>
<wse:Delivery Mode="urn:nato:fft:protocols:sip3:delivery:decoupled_batched">
<dmb:MinTime>20</dmb:MinTime>
<dmb:Heartbeats>true</dmb:Heartbeats>
<wse:NotifyTo>
<a:Address>http://localhost:8080/TrackPush</a:Address>
<a:ReferenceParameters>
<MySubscription xmlns="urn:MyNamespace">1234567890</MySubscription>
</a:ReferenceParameters>
</wse:NotifyTo>
</wse:Delivery>
.......
</s:Body>
</s:Envelope>
E.2.2.2.3. Subscription Parameters

The WS-Eventing specification for subscription does not allow the Consumer to state the
desired format for the data. This is required for SIP3 in order to keep the specification decoupled
from COI-specific message formats. WS-Eventing provides an extensibility point which allows
addition of an arbitrary element after the wse:Filter element within wse:Subscription element.
BR-SIP3-43. If a Consumer would like to state the characteristics of data messages it

MUST add the urn:nato:fft:protocols:sip3:SIP3SubscriptionParameter element as the
last element within wse:Subscription element. The XML schema of the
SIP3SubscriptionParameter element is depicted below.
Figure 14 SIP3SubscriptionParameter Element

The following describes the normative constraints on the SIP3SubscriptionParameter
elements.
BR-SIP3-44. //SIP3SubscriptionParameter – Is the root element that contains the

subscription parameters. To maintain message compatibility with the SIP3 version 1.1.x
this is not mandatory. The field is OPTIONAL. If it is not present or NIL all the child
elements values MUST be considered defaulted.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
BR-SIP3-45. //SIP3SubscriptionParameter/ResponseDialect – ResponseDialect is of
type xs:anyUri and specifies the requested format for the data in the response message.
The response dialect URI and the rule for binding the response in the SIP3 messages
MUST be agreed upon by Subscriber, Consumer and Provider. If the Provider does not
support the requested dialect it MUST return an UnsupportedResponseDialect fault
stating the supported dialects. The field is OPTIONAL. The default value is
implementation dependent.
BR-SIP3-46. //SIP3SubscriptionParameter/MultipleTrackAllowed –
MultipleTrackAllowed is of type xs:boolean and specifies if the event message can
contain multiple data items. If this element is set to “false” the Provider SHOULD send
messages containing only one data item each 9 . If the Producer cannot honour the
MultipleTrackAllowed request because this option is not supported it MUST return an
UnsupportedMultipleTrackAllowed fault stating the default behaviour. The field is
OPTIONAL. The default value “true”.
E.2.2.2.3.2. Subscription example

Below is an example of subscription to demonstrate the usage of the
SIP3SubscriptionParameter element with the relevant parts in red.
<s:Envelope
xmlns:a=http://www.w3.org/Submission/ws-addressing
<s:Header>
.......
.......
</s:Header>
<s:Body>
<wse:Subscribe>
<wse:EndTo>
.......
</wse:EndTo>
.......
.......
</wse:Delivery>
<wse:Filter Dialect="……….">
.......
.......
</wse:Filter>
<SIP3SubscriptionParameter xmlns="urn:nato:fft:protocols:sip3">
<ResponseDialect>urn:nato:fft:protocols:nffi13</ResponseDialect>
<MultipleTrackAllowed>true</MultipleTrackAllowed>
</SIP3SubscriptionParameter>
</wse:Subscribe>
</s:Body>
</s:Envelope>
9 Many of the FFT formats like NFFI 1.3 and FFI MTF allow the possibility to wrap multiple tracks within
a single message. This is optimal for the network and system performance but may be suboptimal
for message processing. Track Consumers may prefer receipt of messages containing only one track
(update).
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
E.2.2.2.4. Filtering dialect
BR-SIP3-47. A Producer MAY support the standard WS-Eventing XPath filtering. Fault
handling is specified in the WS-Eventing specification.
BR-SIP3-48. To maintain message compatibility with the SIP3 version 1.1.x, a

Producer SHOULD support the “urn:nato:fft:protocols:nffi13:query” filtering language.
In such case the filter type contents MUST be one and only one NFFIFilter element from
“urn:nato:fft:protocols:nffi13:query” namespace.
BR-SIP3-49. A Producer MAY support any filter dialect mutually supported by a Data
Producer and Subscriber.
Below is an example of subscription using the “urn:nato:fft:protocols:nffi13:query” filter dialect

with the relevant parts in red.
<s:Envelope
xmlns:a="http://www.w3.org/Submission/ws-addressing"
xmlns:qry="urn:nato:fft:protocols:nffi13:query"
<s:Header>
.......
.......
</s:Header>
<s:Body>
<wse:Subscribe>
<wse:EndTo>
.......
</wse:EndTo>
.......
.......
</wse:Delivery>
.......
<wse:Filter Dialect="urn:nato:fft:protocols:nffi13:query">
<qry:NFFIFilter>
<qry:historyDepth>1</qry:historyDepth>
</qry:NFFIFilter>
</wse:Filter>
.......
</s:Body>
</s:Envelope>
E.2.2.2.5. Consumer
The Consumer (Sink) service supports a one-way SOAP message flow executed in the “fire-
and-forget” mode.
BR-SIP3-50. To be compliant with WS-Eventing, the usage of the WS-Addressing is

REQUIRED.
DecoupledTrackPush
BR-SIP3-51. The SOAP message sent from the Provider to the data Consumer
SHOULD be of type SIP3DataResponse.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
BR-SIP3-52. The Provider SHALL provide to the Consumer the subscription name
used in the subscribe process to identify the subscription. This SHALL be carried as
mandatory HEADER information and for this reason is not defined in the response
message but in the WSDL port definition.
E.2.2.3.1. Track message structure
This message is the same used for the response in the pull mode. No differences exist between
this and the definition for the pull mode.
E.2.2.3.2. WS-Eventing usage
This paragraph defines the business rules to apply to the WS-Eventing for SIP3 usage. It is
organized by WS-Eventing data type, and the business rules are defined for each relevant data
type.
E.2.2.3.2.1. FilterType
BR-SIP3-53. //FilterType/Dialect (type xs:anyURI) SHOULD be interpreted following
the WS-Eventing rules. It MAY be any URI describing a filter dialect agreed between
the Consumer and the Producer. Common options are:
 “http://www.w3.org/TR/1999/REC-xpath-19991116”: (Default value) in such case
the filter type contents can be a sequence from 1 to many XPath predicates.
 Any other agreed query language: in such case the filter type MUST contain only
one root element of the filter in the specified format.
XML-Code 8 FilterType XSD Fragment
<xs:complexType name="FilterType" mixed="true">

<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="Dialect" type="xs:anyURI" use="optional" />
<xs:anyAttribute namespace="##other" processContents="lax" /> </xs:complexType>
E.2.2.3.2.2. DeliveryType
BR-SIP3-54. //DeliveryType/Mode (type xs:anyURI) SHOULD be considered as

restricted to the following list:
 “http://schemas.xmlsoap.org/ws/2004/08/eventing/DeliveryModes/Push” (Default
value).
 “urn:nato:fft:protocols:sip3:delivery:decoupled_batched”.
If an unsupported delivery mode is requested, the SIP3 data provider MUST return a
DeliveryModeRequestedUnavailable fault.
XML-Code 9 DeliveryType XSD Fragment


<xs:complexType name="DeliveryType" mixed="true">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence>
<xs:attribute name="Mode" type="xs:anyURI" use="optional" />
<xs:anyAttribute namespace="##other" processContents="lax" /> </xs:complexType>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
E.2.2.3.2.3. Operation on non-existing subscriptions
The WS-Eventing definition does not define any explicit action or error in case renew, delete or
getStatus operations are requested on a non-existent or expired subscription. To recover this
gap a new fault message has been defined and must be returned in the previously described
situation.
BR-SIP3-55. This fault message MUST be sent according to the rules described in
paragraph E.2.2.3.2.4. It SHALL be sent to the [fault endpoint], if present and valid.
Otherwise it SHALL be sent to the [reply endpoint] if present. If neither is present fault
MAY be sent to the [source endpoint].
E.2.2.3.2.4. Fault: InvalidSubscription

BR-SIP3-56. This fault MUST be sent when a Renew or Get or Delete request specifies
a non-existent, expired or invalid subscription.
Table 11 InvalidSubscription Fault Code
[faultcode] s12:Sender
[faultstring] wse:InvalidSubscription
[detail] The requested subscription is non-existent or invalid.
[faultactor] none
ADDITIONAL ARRANGEMENTS
SOAP Header
WS-I Basic Profile 1.1 [Ref 18] normative statements provide some guidance also about how
to handle SOAP headers. For example, if a new element is defined for the SOAP header then
all involved parties would have to include, understand and process them.
On the other hand, a SOAP envelope MAY contain SOAP header blocks that are not described
in the wsdl:binding that describes it but MUST contain SOAP header blocks that are described
in the wsdl:binding.
BR-SIP3-57. The SIP3 compression and/or security-related SOAP headers information

SHALL NOT be included as part of wsdl:binding definition but MAY be added to the
SOAP header by the involved parties as needed. The involved parties are free to check
their existence and act consequently.
Compression
E.2.3.2.1. Compression approaches
At least two basic approaches are possible for compression in SIP3:
 Compression algorithm similar to that implemented by the Agile Delta compression, i.e.,
with the compression applying to the whole message. This mechanism is transparent for
SIP3 and therefore is out of scope of SIP3 definition.
 Compression mechanism built-in SIP3 definition.
 All compression-related definitions (apart from elements to be used in SOAP message
headers) are defined in a separate schema definition file, i.e., compressionAlgs.xsd,
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
currently part of SIP3 definition and are under the “urn:nato:fft:protocols:sip3:compression”
namespace.
E.2.3.2.2. SIP compression principles
Three basic factors played a role in the SIP3 compression definition:
 Compression-related part of the definition should be transparent for the core of SIP3
specifications.
 Changes in compression part of the definition (e.g., new compression algorithms, additional
parameters for compression algorithms) should not affect SIP3 specifications.
 Usage of compression in SIP3 has to respect limitations following from the WS-I Basic
Profile 1.1 standard.
E.2.3.2.3. Built-in compression rules
The procedure for SIP3 built-in compression mechanism is as follows.
BR-SIP3-58. The data consumer MAY specify a list of supported compression

algorithm(s). There are two places in SIP3 where the data consumer MAY specify a list
of supported compression algorithms:
 In the header of a SOAP request message in pull service.
 In the header of a SOAP request message in subscription sign up operation.
BR-SIP3-59. Compression SHALL only occur if both the consumer and the producer
support the same algorithm(s). Supporting compression is NOT MANDATORY
(functionality level).
E.2.3.2.4. Exchange of compression information

For SIP3 compression mechanism, the following elements are used in the SOAP header to
indicate supported compression algorithms and used algorithm:
 <xs:element name=”CompressionAlgsSupported”
type=”compressionAlgorithmsSupported” />
 <xs:element name=”CompressionAlgUsed” type=”compressionAlgType” />
E.2.3.2.5. Basic compression algorithm
The ’compressionAlgorithmsSupported‘ and ’compressionAlgType‘ types are defined in
compressionAlgs.xsd while the ‘CompressionAlgsSupported’ and ‘CompressionAlgUsed’
elements are defined in the SIP3.xsd. Please note that the complete element names are the
following:
 urn:nato:fft:protocols:sip3:compression:compressionAlgType
 urn:nato:fft:protocols:sip3:compression:compressionAlgorithmsSupported
 urn:nato:fft:protocols:sip3:CompressionAlgsSupported
 urn:nato:fft:protocols:sip3:CompressionAlgUse
SIP3 Standard Error Handling

In case of error during the execution on a SIP3 Producer, depending on the protocol and on
the error type, a fault message may be generated from the Producer and sent back to the
Consumer.
There are mainly two kinds of faults, protocol-dependent faults and Producer-internal faults.
From the interoperability point of view, to make it easy for a Consumer to understand the error
and eventually change the query, protocol-dependent faults are standardized. The effort to
generate meaningful Producer-internal faults is left to the Producer’s implementation.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
BR-SIP3-60. In case of fault, the string “SIP3Fault” MAY be assigned to the SOAP
faultString field while the SOAP detail field MUST contain a SIP3Fault message.
BR-SIP3-61. The SIP3Fault message is a custom fault message defined in the file
errorCodes.xsd that SHALL carry the following two types of information to help the fault
identification:
 SIP3FCode – The unique SIP3 fault code.
 SIP3FString – A human readable explanation of the fault (The English language
reason element)
Below is an example of a fault message a client may receive in case the producer’s server does
not support the historyDepth specified in the query.
XML-Code 10 Example Fault Message
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server</faultcode>
<faultstring>SIP3Fault</faultstring>
<detail>
<SIP3Fault xmlns="urn:nato:fft:protocols:sip3:errors">
<SIP3FCode> UnsupportedFilterHistoryDepth </SIP3FCode>
<SIP3FString> The service provider doesn’t support a historyDepth greater than 5</SIP3FString>
</SIP3Fault>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
Pull Mode Faults

E.2.3.4.1. UnsupportedResponseDialect
Related filter parameter: //SIP3DataRequest/ResponseDialect.
BR-SIP3-62. This fault SHALL be sent when a client requests a ResponseDialect that
the service cannot provide.
 SIP3FCode UnsupportedResponseDialect
 SIP3FString Text explaining the failure; e.g., “The service
provider doesn’t support the requested
ResponseDialect”
 SIP3FSupportedDialect List of the supported dialects
E.2.3.4.2. UnsupportedFilterDialect
Related filter parameter: //SIP3DataRequest/Filter@Dialect.
BR-SIP3-63. This fault SHALL be sent when a client specifies a filter dialect that the
service cannot support.
 SIP3FCode UnsupportedFilterDialect
provider doesn’t support the requested filter dialect”

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
E.2.3.4.3. MultiplePayloadNotSupported
BR-SIP3-64. This fault SHALL be sent when a client requests data that cannot be
compounded in a single return payload.
 SIP3FCode MultiplePayloadNotSupported
provider cannot return data in compliance with the
security profile. The producer is trying to compound
a message with following security policies: NATO;
ISAF.”
Push Mode Faults
BR-SIP3-65. Any protocol-dependent faults during a push mode related operation,

except the SIP3 related ones, SHOULD be handled as specified in the WS-Eventing
specification Section 5.
Please note that to maintain compatibility with the WS-Eventing specification no faults were
added to the WSDL PortTypes definition for the WS-Eventing ports. This does not prevent the
usage of the SIP3Fault message for the SOAP detail field in case of SIP3 related faults.
E.2.3.5.1. UnsupportedResponseDialect
Related subscription element: //SIP3SubscriptionParameter/ResponseDialect.
BR-SIP3-66. This fault SHALL be sent when a subscriber requests a ResponseDialect

that the service cannot provide.
 SIP3FCode UnsupportedResponseDialect
provider doesn’t support the requested
ResponseDialect”
 SIP3FSupportedDialect List of the supported dialect
E.2.3.5.2. UnsupportedFilterDialect
Related filter parameter: //SIP3DataRequest/Filter@Dialect.
BR-SIP3-67. This fault SHALL be sent when a client specifies a filter dialect that the
service cannot support.
 SIP3FCode UnsupportedFilterDialect
 SIP3FString Text explaining the failure; e.g., “The service provider
doesn’t support the requested filter dialect”

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
E.2.3.5.3. UnsupportedMultipleTrackAllowed
Related subscription element: //SIP3SubscriptionParameter/MultipleTrackAllowed
BR-SIP3-68. This fault SHALL be sent when the provider doesn’t support the
MultipleTrackAllowed parameter.
 SIP3FCode UnsupportedMultipleTrackAllowed
 SIP3FString Text explaining the failure; e.g., “The service provider
doesn’t support the MultipleTrackAllowed parameter. By
default multiple tracks are sent”
SIP3 NORMATIVE DEFINITION

Normative “compressionAlgs.xsd”
XML-Code 11 Normative "compressionAlgs.xsd"





<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ns="urn:nato:fft:protocols:sip3:compression"
targetNamespace="urn:nato:fft:protocols:sip3:compression" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:simpleType name="compressionAlgType">
<xs:restriction base="xs:string">
<xs:enumeration value="GZIP"/>
<xs:enumeration value="EFX"/>
<xs:enumeration value="XMLPPM"/>
<xs:enumeration value="NONE"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="compressionAlgorithmsSupported">
<xs:sequence>
<xs:element name="compression" type="ns:compressionAlgType" nillable="false" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Normative “SIP3.xsd”
XML-Code 12 Normative “SIP3.xsd”


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:error="urn:nato:fft:protocols:sip3:errors"
xmlns:compr="urn:nato:fft:protocols:sip3:compression" xmlns="urn:nato:fft:protocols:sip3"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" targetNamespace="urn:nato:fft:protocols:sip3"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:nato:fft:protocols:sip3:compression" schemaLocation="compressionAlgs.xsd"/> <xs:import
namespace="urn:nato:fft:protocols:sip3:errors" schemaLocation="errorCodes.xsd"/> 
<xs:element name="CompressionAlgsSupported" type="compr:compressionAlgorithmsSupported"/> <xs:element
name="CompressionAlgUsed" type="compr:compressionAlgType"> <xs:annotation>
<xs:documentation>Compression algorithm used by data provider (decided by data provider)</xs:documentation>
</xs:annotation>
</xs:element>

<xs:simpleType name="allAvailableDataTransferredType">
<xs:restriction base="xs:boolean"/>
</xs:simpleType> <xs:annotation>
<xs:documentation>Decoupled ReqRes base datatype</xs:documentation> </xs:annotation>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
<xs:complexType name="GenericRequestType" mixed="true">
<xs:sequence>

<xs:element name="ResponseDialect" type="xs:anyURI" minOccurs="0"/>

<xs:element name="Filter" type="DataType"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType>
<xs:complexType name="GenericResponseType" mixed="true">
<xs:sequence>
<xs:element name="allAvailableDataTransferred" type="allAvailableDataTransferredType"/>
<xs:element name="Message" type="DataType"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="DataType" mixed="true">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence>
<xs:attribute name="Dialect" type="xs:anyURI" use="optional"/>
</xs:complexType>

<xs:element name="SIP3DataRequest" type="GenericRequestType"/>
<xs:element name="SIP3DataResponse" type="GenericResponseType"/>


<xs:simpleType name="ResponseDialectType">
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:complexType name="GenericSubscriptionParameterType" mixed="true"> <xs:sequence>

<xs:element name="ResponseDialect" type="ResponseDialectType" minOccurs="0"/>

<xs:element name="MultipleTrackAllowed" type="xs:boolean" default="true" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence>
</xs:complexType>
<xs:element name="SIP3SubscriptionParameter" type="GenericSubscriptionParameterType"/>
</xs:schema>
Normative “SIP3_Definitions.wsdl”
XML-Code 13 Normative “SIP3_Definitions.wsdl”


<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:ns="urn:nato:fft:protocols:sip3:wsdlservice"
xmlns:ns1="urn:nato:fft:protocols:sip3" xmlns:ns3="urn:nato:fft:protocols:sip3:compression"
xmlns:ns4="urn:nato:fft:protocols:sip3:errors" xmlns:ns7="urn:nato:fft:protocols:sip3:compression"
targetNamespace="urn:nato:fft:protocols:sip3:wsdlservice">
<wsdl:types>
<xs:schema>
<xs:import namespace="urn:nato:fft:protocols:sip3" schemaLocation="SIP3.xsd"/> </xs:schema>
</wsdl:types>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
<wsdl:message name="CompressionSupported">
<wsdl:part name="compression" element="ns1:CompressionAlgsSupported"/>
</wsdl:message>
<wsdl:message name="CompressionUsed">
<wsdl:part name="compression" element="ns1:CompressionAlgUsed"/> </wsdl:message>
<wsdl:message name="DecoupledPullDataRequestMessage">
<wsdl:part name="parameter" element="ns1:SIP3DataRequest"/> </wsdl:message>
<wsdl:message name="DecoupledPushDataResponseMessage">
<wsdl:part name="parameter" element="ns1:SIP3DataResponse"/>
</wsdl:message>
<wsdl:message name="DecoupledPullDataFaultMessage">
<wsdl:part name="parameter" element="ns4:SIP3Fault"/>
</wsdl:message>
<wsdl:portType name="SIP3_Port_DecoupledReqRes">
<wsdl:documentation>Decoupled Request Response protocol</wsdl:documentation>
<wsdl:operation name="DecoupledPullDataOperation">
<wsdl:input name="DecoupledPullDataRequest" message="ns:DecoupledPullDataRequestMessage"/>
<wsdl:output name="DecoupledPullDataResponse" message="ns:DecoupledPushDataResponseMessage"/>
<wsdl:fault name="DecoupledPullDataFault" message="ns:DecoupledPullDataFaultMessage"/> </wsdl:operation>
</wsdl:portType>
<wsdl:portType name="SIP3_Port_DecoupledTracksPush">
<wsdl:operation name="DecoupledTracksPushDataOperation">
<wsdl:input name="DecoupledPushDataResponse" message="ns:DecoupledPushDataResponseMessage"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
Normative “SIP3_Service_Eventing.wsdl”
XML-Code 14 Normative “SIP3_Service_Eventing.wsdl”


xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:tns="urn:nato:fft:protocols:sip3:eventingservice"
xmlns:ns="http://schemas.xmlsoap.org/ws/2004/08/eventing" targetNamespace="urn:nato:fft:protocols:sip3:eventingservice">
<wsdl:import namespace="http://schemas.xmlsoap.org/ws/2004/08/eventing"
location="http://schemas.xmlsoap.org/ws/2004/08/eventing/eventing.wsdl"/> <wsdl:import
namespace="urn:nato:fft:protocols:sip3:delivery:decoupled_batched" location="SIP3_delivery_decoupled_batched.xsd"/>
<wsdl:binding name="SIP3_Binding_SubscriptionManager" type="ns:SubscriptionManager">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="RenewOp">
<soap:operation soapAction="http://schemas.xmlsoap.org/ws/2004/08/eventing/Renew"/> <wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetStatusOp">
<soap:operation soapAction="http://schemas.xmlsoap.org/ws/2004/08/eventing/GetStatus"/> <wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="UnsubscribeOp">
<soap:operation soapAction="http://schemas.xmlsoap.org/ws/2004/08/eventing/Unsubscribe"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation> </wsdl:binding>
<wsdl:binding name="SIP3_Binding_EventSource" type="ns:EventSource">

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="SubscribeOp">
<soap:operation soapAction="http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe"/> <wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="SubscriptionEnd">
<soap:operation soapAction="http://schemas.xmlsoap.org/ws/2004/08/eventing/SubscriptionEnd"/> <wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="SIP3_Service_Eventsource">
<wsdl:port name="SIP3_Port_EventSource" binding="tns:SIP3_Binding_EventSource">
<soap:address location="http://localhost/Eventsource_Service"/> </wsdl:port>
<wsdl:port name="SIP3_Port_SubscriptionManager" binding="tns:SIP3_Binding_SubscriptionManager">
<soap:address location="http://localhost/SubscriptionManager_Service"/> </wsdl:port>
</wsdl:service>
</wsdl:definitions>
Normative “SIP3_delivery_decoupled_batched.xsd”
XML-Code 15 Normative “SIP3_delivery_decoupled_batched.xsd”

 

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:nato:fft:protocols:sip3:delivery:decoupled_batched"
targetNamespace="urn:nato:fft:protocols:sip3:delivery:decoupled_batched" elementFormDefault="qualified"
attributeFormDefault="unqualified"> <xs:annotation>
<xs:documentation>Schema defining the additional parameters to be used for the batched delivery mode. Those parameters
are to be added to the subscribe/delivery section of the WS-Event subscription. The delivery mode to use to request for the
batched delivery if the "urn:nato:fft:protocols:sip3:delivery:decoupled_batched". This delivery schema is to be used in conjuction
with the DecTrackPush event sink</xs:documentation> </xs:annotation>
<xs:element name="Heartbeats" type="xs:boolean" default="true">
<xs:annotation>
<xs:documentation>If true the Heartbeat signal is REQUIRED for the batched mode. Normally if there are no data collected in
the time interval the track message is not be sent at the interval expiration. If the Heartbeat is "true" the data provider MUST
always send a message (also if empty) at the interval expiration time.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="MinTime" type="xs:long">
<xs:annotation>
<xs:documentation>Is the Minimum delay in seconds between two consecutive updates. In case no tracks where collected in
the interval the server SHOULD NOT send the update message except if the Heartbeat is true.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:schema>
Normative “errorCodes.xsd”
XML-Code 16 Normative “errorCodes.xsd”



<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ns4="urn:nato:fft:protocols:sip3:errors"
targetNamespace="urn:nato:fft:protocols:sip3:errors" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="SIP3Fault">
<xs:complexType>
<xs:sequence>
<xs:element name="SIP3FCode" type="xs:string"/>
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
<xs:element name="SIP3FString" type="xs:string"/>

<xs:element name="SIP3FSupportedDialect" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Normative “SIP3_Service_TracksPush.wsdl”
XML-Code 17 Normative “SIP3_Service_TracksPush.wsdl”

 

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:sip3="urn:nato:fft:protocols:sip3"
xmlns:def="urn:nato:fft:protocols:sip3:wsdlservice" xmlns:ns="urn:nato:fft:protocols:sip3:decoupledpushservice"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:ns1="urn:nato:fft:protocols:sip3:compression" xmlns:ns4="urn:nato:fft:protocols:sip3"
xmlns:ns5="urn:nato:fft:protocols:sip3:errors"
targetNamespace="urn:nato:fft:protocols:sip3:decoupledpushservice">
<wsdl:import namespace="urn:nato:fft:protocols:sip3:wsdlservice" location="SIP3_Definitions.wsdl"/> <wsdl:types>
<xs:schema elementFormDefault="qualified"
targetNamespace="urn:nato:fft:protocols:sip3:decoupledpushservice"/>
</wsdl:types>
<wsdl:binding name="SIP3_Binding_DecoupledTracksPush" type="def:SIP3_Port_DecoupledTracksPush">
<wsdl:operation name="DecoupledTracksPushDataOperation">
<soap:operation soapAction="DecoupledTracksPushDataOperation"/>
<wsdl:input name="DecoupledPushDataResponse">
</wsdl:input>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="SIP3_Service_DecoupledTracksPush">
<wsdl:documentation>SIP3 DecoupledTracksPush Service. This service implements the "event sink" needed to receive the
data subscribed (see WS-Eventing protocol). It implement a one-way "fire-and-forget" operation initiated by data
provider.</wsdl:documentation>
<wsdl:port name="SIP3_ServicePort_DecoupledTracksPush" binding="ns:SIP3_Binding_DecoupledTracksPush">
<soap:address location="http://localhost/DecoupledTracksPush_Service"/> </wsdl:port>
</wsdl:service>
</wsdl:definitions>
Normative “SIP3_Service_DecoupledReqRes.wsdl”
XML-Code 18 Normative “SIP3_Service_DecoupledReqRes.wsdl”


xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:def="urn:nato:fft:protocols:sip3:wsdlservice"
xmlns:ns="urn:nato:fft:protocols:sip3:decoupledreqresservice" name="SIP3_Service_DecoupledReqRes"
targetNamespace="urn:nato:fft:protocols:sip3:decoupledreqresservice">
<wsdl:import namespace="urn:nato:fft:protocols:sip3:wsdlservice" location="SIP3_Definitions.wsdl"/>
<wsdl:binding name="SIP3_Binding_DecoupledReqRes" type="def:SIP3_Port_DecoupledReqRes">
<wsdl:operation name="DecoupledPullDataOperation">
<soap:operation soapAction="DecoupledPullDataOperation"/>
<wsdl:input name="DecoupledPullDataRequest">
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
</wsdl:input>
<wsdl:output name="DecoupledPullDataResponse">
</wsdl:output>
<wsdl:fault name="DecoupledPullDataFault">
<soap:fault name="DecoupledPullDataFault" use="literal"/>
</wsdl:fault>
</wsdl:operation> </wsdl:binding>
<wsdl:service name="SIP3_Service_DecoupledReqRes">
<wsdl:documentation>Decoupled SIP3 Request/Response Service.
Initiated by subscriber.</wsdl:documentation>
<wsdl:port name="SIP3_ServicePort_DecoupledReqRes" binding="ns:SIP3_Binding_DecoupledReqRes">
<soap:address location="http://localhost/DecoupledReqRes_Service"/> </wsdl:port>
</wsdl:service>
</wsdl:definitions>
NFFI-13 QUERY LANGUAGE TECHNICAL SPECIFICATION
INTRODUCTION
SIP3 is a Web services based interface recommended for exchange and access of Friendly
Force Tracking (FFT) data.
SIP3 only describes the web services interface and the protocol used for the communication
but does not mandate either the format of the data nor the way in which the data of interest is
selected. The SIP3 protocols support any XML formatted data and filters that are supported by
both the SIP3 data provider and data consumer. The filtering language is a key element for a
SIP3 enabled service because the filtering language type and expressivity determines the SIP3
data selection functionality.
This section describes the “NFFI_13_Query” filtering language. Despite the fact that it is based
on the NFFI V1.3 message format, the “NFFI_13_Query” filtering language can be successfully
applied to the FFI MTF messages assuming the semantic mapping between the NFFI V1.3
element and the corresponding FFI MTF elements is defined.
For the actual scope the mapping principle exposed in this document at ANNEX G, section G.3
“BACKWARD COMPATIBILITY MAPPING FROM NFFI TO FFI MTF” must be applied to the
NFFI filter language to filter FFI MTF data.
This specification defines:

 General syntax of the filter
 Semantics of the filter element.
 Usage of the filter and expected behaviour of the SIP3 data producer in response to the
filtered request.
SIP3 FILTER LANGUAGE

The “NFFI_13_Query” filtering language was initially developed to filter the FFT tracks
exchanged using the SIP3 v1.x message transport protocol.
It was intended to select NFFI V1.3 formatted FFT tracks and for this reason it largely uses the
NFFI V1.3 data type and structure in the filter definition. It can be successfully used to filter FFT
tracks represented in other formats, like FFI MTF, assuming knowledge of the semantics of the
FFT elements for the format conversion.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
BR-NFFI Query-1. In this annex, where not stated differently, the semantics of the
filtering element SHALL be the same as the corresponding elements in the NFFI V1.3
standard.
BR-NFFI Query-2. The “NFFI_13_Query” filtering language MUST be identified with

the string “urn:nato:fft:protocols:nffi13:query” when needed (i.e. the indication of the
filtering dialect in the SIP3 requests).
NFFIFilter Element
BR-NFFI Query-3. The NFFIFilter element identifies the basic filter structure that
SHALL be used in the “SIP3 Push” protocol. It is defined in the file “NFFI_13_Query.xsd”
and all its elements are in the namespace “urn:nato:fft:protocols:nffi13:query”.
BR-NFFI Query-4. The NFFIFilter element MAY be used in the subscription message
indicating the “urn:nato:fft:protocols:nffi13:query” as “filter dialect” and including an
NFFIFilter element in the “Filter” element of the subscription request.
It is also the basis for the “ReqResFilter” element used in the “pull” request.
E.3.2.1.1. Filter overview
From a logical point of view, the filter schema contains two kinds of information:
 Filtering values: Used to select the tracks with data values matching the filter
(sourceSystem, geoFilter, XPathFilter, period). Those are divided in sections to clearly
separate and identify the values.
 Track number limitation: Used to control the number of returned tracks (historyDepth,
maxFrame).
E.3.2.1.2. Filter schema
Figure 15 shows the filter XML schema.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
Figure 15 NFFIFilter Structure

The following rules describe the normative constraints on the filter elements:
BR-NFFI Query-5. /NFFIFilterType/historyDepth – the element specifies the number

of tracks, calculating down from the most recent track (per every unit being
traced/accessible in the track server) which SHALL be sent to the track consumer. It is
agreed that value “0” for this element means that the track consumer demands all
available tracks. Such filters sections MAY be supported from the data providers (SIP3
servers). If the data provider server does not support such filtering or the indicated
historyDepth value then a request that specifies them MUST fail and the server MUST
generate an UnsupportedHistoryDepthFilter fault. The field is OPTIONAL, data
consumer/Subscriber MAY specify the number of the latest tracks (per traced object)
expected from data provider/Publisher. The default value is 1. If this filter is used in
conjunction with the /NFFIFilterType/geoFilter for the tracks eligible to be reported only
the historical tracks selected by the historyDepth that are inside the selected areas
SHALL be reported.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
BR-NFFI Query-6. /NFFIFilterType/systemList – the element limits the scope of tracks
data returned by a specific data source limiting the track source admitted values. Such
filters sections MUST be supported from the data providers (SIP3 servers). The field is
OPTIONAL, the default value is to do not filter by track source.
BR-NFFI Query-7. /NFFIFilterType/systemList/incl_excl – Two variants of specification

are available: inclusive (all tracks with a matching track source are returned) or
exclusive (all systems apart from matching ones). Value “INCLUSIVE” means the
inclusive variant, and respectively value “EXCLUSIVE” means the exclusive variant.
Such filters sections MUST be supported from the data providers (SIP3 servers). The
field is OPTIONAL. The default value is INCLUSIVE.
BR-NFFI Query-8. /NFFIFilterType/systemList/trackSource/ – Is the list of the

trackSource element identifying the systems to be included/excluded from the result. If
more than one trackSource is in the list the filter has to be considered as a logical OR
between all the trackSource listed. Such filters sections MUST be supported from the
data providers (SIP3 servers). The field is mandatory if the
/NFFIFilterType/systemList exist.
BR-NFFI Query-9. /NFFIFilterType/systemList/trackSource/sourceSystem – Is the

system to be included/excluded from the result. Such filters sections MUST be
supported from the data providers (SIP3 servers). The field is OPTIONAL. The default
value is to do not apply any filter on the sourceSystem.
BR-NFFI Query-10. /NFFIFilterType/systemList/trackSource/sourceSystem/country –

The ‘%’ characters MAY be used in this section to represent from zero character to any
character or any combination of characters. This enables multiple selections with a
single specification. The ‘%’ character substitution MAY be supported from the data
providers (SIP3 servers). If the data providers server do not support such wildcard then
a request that specifies it MUST fail and the server MUST generate an
UnsupportedWildcard fault. Such filters sections MUST be supported from the data
providers (SIP3 servers). The field is OPTIONAL. The default is to do not apply any filter
on the country. In case this filter section is specified and it is empty all and only the
tracks having an empty or a NULL country value MUST be returned.
BR-NFFI Query-11. /NFFIFilterType/systemList/trackSource/sourceSystem/system –

The ‘%’ characters MAY be used in this section to represent from zero character to any
on the system.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
BR-NFFI Query-12. /NFFIFilterType/systemList/trackSource/sourceSystem/
subsystem – The ‘%’ characters MAY be used in this section to represent from zero
character to any character or any combination of characters. This enables multiple
selections with a single specification. The ‘%’ character substitution MAY be supported
from the data providers (SIP3 servers). If the data providers server do not support such
wildcard then a request that specifies it MUST fail and the server MUST generate an
on the subsystem. In case this filter section is specified and it is empty, only the tracks
having an empty or a NULL subsystem value MUST be returned.
BR-NFFI Query-13. /NFFIFilterType/systemList/trackSource/transponderId – The ‘%’

characters MAY be used in this section to represent from zero character to any
UnsupportedWildcard fault. The element limits the scope of tracks data returned by a
specific data source limiting the transponderId admitted values. Such filters sections
MUST be supported from the data providers (SIP3 servers). The field is OPTIONAL.
The default is to do not apply any filter on the transponderId.
BR-NFFI Query-14. /NFFIFilterType/geoFilter – the element allows limiting tracks to

only those which fit the specified list of geographic area. Borders of the area have a
shape specified by its sub element. Such filters sections MAY be supported from the
data providers (SIP3 servers). If the data provider server does not support such filtering
then a request that specifies them MUST fail and the server MUST generate an
UnsupportedGeoFilter fault. If more than one geoFilter section is indicated all the areas
specified MUST be considered in logical OR (a track MUST belong at least to a defined
area to be selected). The field is OPTIONAL. The default value is to do not apply the
filter.
BR-NFFI Query-15. /NFFIFilterType/geoFilter/Circle – the element allows limitation of

tracks to only those which fit the specified circle. Such filters sections MAY be supported
from the data providers (SIP3 servers). If the data provider server does not support such
filtering then a request that specifies them MUST fail and the server MUST generate an
UnsupportedGeoCircleFilter fault. The field is OPTIONAL. The default value is to do not
apply the filter.
BR-NFFI Query-16. /NFFIFilterType/geoFilter/closedPolygon – the element allows

limitation of tracks to only those which fit the specified closed polygon. If the submitted
polygon is not closed the track server MUST provide its closure joining the last and the
first points. Such filters sections MAY be supported from the data providers (SIP3
servers). If the data provider server does not support such filtering then a request that
specifies them MUST fail and the server MUST generate an
UnsupportedGeoClosedPolygonFilter fault. The field is OPTIONAL. The default value
is to do not apply the filter.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
BR-NFFI Query-17. /NFFIFilterType/geoFilter/rectangle – the element allows limitation
of tracks to only those which fit the specified rectangle. Such filters sections MAY be
supported from the data providers (SIP3 servers). If the data provider server does not
support such filtering then a request that specifies them MUST fail and the server MUST
generate an UnsupportedGeoRectangularFilter fault. The field is OPTIONAL. The
default value is to do not apply the filter. Please note that the rectangle coordinates are
to be expressed as North/West – South/East corner.
BR-NFFI Query-18. /NFFIFilterType/XPathFilter – the element allows limitation of

tracks to only those which match the given XPath [Ref 21] predicate expression
(PredicateExpr); The XPath MUST be expressed in the form of a string. In order to
guarantee the interoperability in case of different internal representations of the tracks,
it is agreed that XPath filter is applied starting from the “track” root node. Only full valid
tracks matching the predicate expression (for with the evaluated predicate expression
assume the value of TRUE) are to be returned as a result of the XPath filter. Such filters
sections MAY be supported from the data providers (SIP3 servers). If the data provider
server does not support such filtering then a request that specifies them MUST fail and
the server MUST generate an UnsupportedXPathFilter fault. If more than one
XPathFilter section is indicated all the filters specified MUST be considered in logical
OR (a track MUST match at least one filter to be selected). The field is OPTIONAL. The
default value is to do not apply the filter.
Here some example of equivalent predicate queries:

 //nffi:positionalData/nffi:trackSource[nffi:transponderId=”tr5”]
 //nffi:trackSource[nffi:transponderId=”tr5”]
Those applied on the NFFI message of XML-Code 19 will return the NFFI as at XML-Code 20.
XML-Code 19 XPath Input NFFI Message
<NFFIMessage xmlns="urn:nato:fft:protocols:nffi13"> <track>

<positionalData>
<trackSource>
<sourceSystem>
<system>TBMS</system>
</sourceSystem>
<transponderId>FRATHASIM0</transponderId>
</trackSource>
<dateTime>20070216100407</dateTime>
<coordinates>
<latitude>34.906490</latitude>
<longitude>67.021670</longitude>
</coordinates>
</positionalData>
</track>
<track>
<positionalData> <trackSource>
<sourceSystem>
</sourceSystem>
</trackSource>
<dateTime>20070216100407</dateTime> <coordinates>
</coordinates>
</positionalData>
</track>
</NFFIMessage>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
XML-Code 20 XPath Result NFFI Message
<NFFIMessage xmlns="urn:nato:fft:protocols:nffi13">
<track>
<positionalData>
<trackSource>
<sourceSystem>
</sourceSystem>
</trackSource>
<dateTime>20070216100407</dateTime>
<coordinates>
</coordinates>
</positionalData>
</track>
</NFFIMessage>
BR-NFFI Query-19. /NFFIFilterType/maxFrame – maximum number of tracks being

returned. The limitation on the transferred amount of data SHOULD be implemented in
such a way to allow to send information concerning as many units as possible being
traced/accessible in the responding system as possible. Such filters sections MUST be
supported from the data providers (SIP3 servers). The field is OPTIONAL. The default
is use the data providers (SIP3 servers) limit.
This field is introduced in order to limit the amount of data being transferred e.g. in the case
when the network bandwidth is an important issue.
E.3.2.1.3. How to apply filters
To have a predictable and common result of the track filtering operation between different SIP3
data producer implementations, it is important to define how to apply the filter.
E.3.2.1.3.1. Filtering elements with multiplicity > 1

Some XML elements have a multiplicity major that is greater than 1. For those elements the
filter MUST be computed as follows:
BR-NFFI Query-20. trackSource: All the trackSource elements MUST be considered

to be connected by a logical OR, i.e. “the tracks matching the first trackSource PLUS
the tracks matching the second trackSource PLUS ....” are to be considered eligible to
be returned.
BR-NFFI Query-21. geoFilter: All the geoFilter elements MUST be considered to be

connected by a logical OR, i.e. “the tracks matching the first geoFilter PLUS the tracks
matching the second geoFilter PLUS ....” are to be considered eligible to be returned.
BR-NFFI Query-22. XPathFilter : All the XPathFilter elements MUST be considered to

be connected by a logical OR, i.e. “the tracks matching the first XPathFilter PLUS the
tracks matching the second XPathFilter PLUS ....” are to be considered eligible to be
returned.
E.3.2.1.3.2. Combination of filtering elements

BR-NFFI Query-23. If in a filter is present any combination of trackSource, geoFilter,
XPathFilter, period elements, they MUST be considered to be connected by a logical
AND, calculated as: systemList AND (geoFilter OR geoFilter OR...) AND (XPathFilter
OR XPathFilter OR ...) AND period.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
E.3.2.1.3.3. Filtering steps
BR-NFFI Query-24. The ordered list of the steps that MUST be applied during the filtering
are:
1. Filter the eligible tracks to be returned to the track consumer using the sourceSystem,
XPathFilter and period parameters if any.
2. If geoFilter has been specified
- If period is not specified or is specified only with the start parameter then filter only the
tracks belonging to unit that have their last position reported inside the area defined in the
geoFilter.
- If period is specified with the end parameter then filter all the tracks reported within
the given period of time in the area specified in the geoFilter.
3. On the eligible tracks apply the historyDepth filter in order to return only the most
recent (in terms of creation time) historyDepth number of tracks for each unit
4. From the result of the previous operation return biggest possible number of the most
recent tracks for each different unit up to the maxFrame total number (the expected result
is the selection of an equal number of updates from each track).
ReqResFilter element
In the “SIP3 Push” scenario the messages are supposed to be published only once after they
are reported, in line with that the NFFIFilter do not offer the selection of the FFT tracks based
on the track report time.
This makes the NFFIFilter filter not suitable for the “SIP3 Pull” scenario where operating on
cached data is required the possibility to select the messages for their reporting time.
The ReqResFilter fill this gap adding to the NFFIFilter structure an element for the time frame
filtering.
BR-NFFI Query-25. The ReqResFilter MUST be used in the “SIP3 Pull” scenario. It is
defined in the file “NFFI_13_ReqResFilter.xsd” and all the elements are in the
namespace “urn:nato:fft:protocols:sip3”.
BR-NFFI Query-26. The ReqResFilter MAY be used in the SIP3 request/response

operation (pull mode) indicating the “urn:nato:fft:protocols:sip3:reqresfilter” as “filter
dialect” and including an element in the “Filter” element of the request.
E.3.2.2.1. Filter overview

From logical point of view the filter schema contain two kind of information:
 Time frame information: Used to select the tracks based than the report time. All the tracks
reported in the selected time frame must be considered to be selected and returned.
 Basic filtering: Used to select tracks based on parameters other than the report time.
E.3.2.2.2. Filter schema
Figure 16 describes the filter XML schema.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
Figure 16 ReqResFilter Structure
E.3.2.2.3. Elements detail

The following paragraphs describe the normative constraints on the request elements:
BR-NFFI Query-27. /ReqResFilter/NFFIFilter – NFFIFilter is of type NFFIFilterType,

select tracks based on parameters other than the report time. For detailed description
see section E.3.2.1. The field is OPTIONAL. The default SHALL be to select all.
BR-NFFI Query-28. /ReqResFilter/period – select the tracks based on their reporting

time. The field is OPTIONAL and includes two attributes, ‘start’, and ‘end’ of type
“urn:nato:fft:protocols:nffi13:dateTimeType”. If ‘end’ argument is not specified (it is
OPTIONAL) then all tracks collected since time specified in ‘start’ argument (mandatory)
MUST be selected. The default SHALL be to select all. Such filters sections MAY be
supported from the data providers (SIP3 servers). If the data provider server does not
support such filtering then a request that specifies it MUST fail and the server MUST
generate an UnsupportedPeriodFilter fault.
E.3.2.2.4. How to apply filters

To have a predictable and common result of the track filtering operation between different SIP3
data producer implementations, it is important to define how to apply the filter.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
BR-NFFI Query-29. The ordered list of the steps that MUST be applied during the
filtering are:
1. On the tracks stored on the track server apply the “period” filter to select only the
tracks in the indicated time frame.
2. On the tracks selected at step 1 (reported in the requested time frame) apply the
filter specified at the NFFIFilter element following the rules indicated in the section
E.3.2.1.3.
QUERY LANGUAGE STANDARD ERROR HANDLING

General
BR-NFFI Query-30. In case of error during the execution of a track consumer request
on a SIP3 track server, depending on the protocol and on the error type, a fault message
MAY be generated from the server and sent back to the consumer.
BR-NFFI Query-31. The fault handling MUST be executed in accordance with the SIP3
specification used.
Only the fault codes relevant for the filters are defined.
Filter faults
In the Push mode scenario the filter faults are used to inform a track consumer or the Subscriber
that some part of the requested filter options cannot be honoured by the track server because
the filter type is not implemented or the filtering cannot be executed with the given parameter.
BR-NFFI Query-32. In the Push mode scenario in case the filtering or the requested
filter dialect is not supported, the WS-Eventing faults SHOULD be used.
Following is the list of the faults:

E.3.3.2.1. UnsupportedFilterPeriod
Related filter parameter: /ReqResFilter/period
BR-NFFI Query-33. The UnsupportedFilterPeriod fault SHALL be thrown when a client

specifies a period and the server cannot provide this filtering option.
 SIP3FCode UnsupportedFilterPeriod
 SIP3FString Text explaining the failure; e.g., “The service provider doesn’t
support the requested start time”.
E.3.3.2.2. UnsupportedHistoryDepthFilter
Related filter parameter: /NFFIFilterType/historyDepth
BR-NFFI Query-34. The UnsupportedFilterHistoryDepth fault SHALL be thrown when

a client specifies a history depth that the server cannot provide.
 SIP3FCode UnsupportedFilterHistoryDepth
 SIP3FString Text explaining the failure; e.g., “The service provider doesn’t
support a historyDepth greater than 5”.
E.3.3.2.3. UnsupportedWildcardFilter
Related filter parameters:
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
 /NFFIFilterType/sourceSystem/systemList/country;
 /NFFIFilterType/sourceSystem/systemList/system;
 /NFFIFilterType/sourceSystem/systemList/subsystem;
 /NFFIFilterType/transponderId
BR-NFFI Query-35. The UnsupportedFilterWildcard fault SHALL be thrown when

wildcards specified by the client isn’t supported by the server. If this fault is thrown, the
service doesn’t support wildcards in any search-parameters.
 SIP3FCode UnsupportedFilterWildcard
 SIP3FString The service provider doesn’t support wildcards.
E.3.3.2.4. InvalidFilterGeo
Related filter parameter: /NFFIFilterType/geoFilter
BR-NFFI Query-36. The InvalidFilterGeo fault SHALL be thrown when the client
specifies a geo filter with an invalid format (e.g. Invalid point, invalid coordinate, …).
 SIP3FCode InvalidFilterGeo
 SIP3FString Text explaining the failure
E.3.3.2.5. UnsupportedFilterGeo
BR-NFFI Query-37. The fault UnsupportedFilterGeo SHALL be thrown when the client
specifies a geo filter and the service does not support geo filtering.
 SIP3FCode UnsupportedFilterGeo
 SIP3FString The service provider doesn’t support geo filtering.
E.3.3.2.6. UnsupportedFilterGeoCircle
BR-NFFI Query-38. The UnsupportedFilterGeoCircle fault SHALL be thrown when the

client specifies a geo circle filter and the service doesn’t support it, but supports other
geo filters.
 SIP3FCode UnsupportedFilterGeoCircle
 SIP3FString The service provider doesn’t support geo circle filtering.
E.3.3.2.7. UnsupportedFilterGeoPolygon
BR-NFFI Query-39. The UnsupportedFilterGeoPolygon fault SHALL be thrown when

the client specifies a geo polygon filter and the service doesn’t support it, but supports
other geo filters.
 SIP3FCode UnsupportedFilterGeoPolygon
 SIP3FString The service provider doesn’t support geo polygon filtering.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
E.3.3.2.8. UnsupportedFilterGeoRectangular
BR-NFFI Query-40. The UnsupportedFilterGeoRectangular fault SHALL be thrown

when the client specifies a geo rectangular filter and the service doesn’t support it, but
supports other geo filters.
 SIP3FCode UnsupportedFilterGeoRectangular
 SIP3FString The service provider doesn’t support geo rectangular filtering.
E.3.3.2.9. UnsupportedXPathFilter
Related filter parameter: /NFFIFilterType/XPathFilter
BR-NFFI Query-41. The UnsupportedXPathFilter fault SHALL be thrown when the

client specifies an XPath filter and the service doesn’t support it.
 SIP3FCode UnsupportedXPathFilter
 SIP3FString The service provider doesn’t support XPath filtering.
E.3.3.2.10. InvalidXPathFilter
Related filter parameter: /NFFIFilterType/XPathFilter
BR-NFFI Query-42. The InvalidXPathFilter fault SHALL be thrown when the client
specifies an invalid XPath filter. For example if the client specifies an XPath expression
which isn’t a PredicatExpr.
 SIP3FCode InvalidXPathFilter
 SIP3FString The XPath expression isn’t valid.
NFFI QUERY NORMATIVE DEFINITION

Normative “nffi_13_Query.xsd”
XML-Code 21 Normative “nffi_13_Query.xsd”


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:nffi="urn:nato:fft:protocols:nffi13"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns="urn:nato:fft:protocols:nffi13:query"
targetNamespace="urn:nato:fft:protocols:nffi13:query" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:nato:fft:protocols:nffi13" schemaLocation="NFFI_13.xsd"/>

<xs:element name="NFFIFilter" type="NFFIFilterType"/>

<xs:complexType name="NFFIFilterType">
<xs:sequence>
<xs:element name="historyDepth" default="1" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:unsignedInt">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="systemList" minOccurs="0">
<xs:annotation>
<xs:documentation>inclusive/exclusive</xs:documentation>
</xs:annotation>
<xs:complexType> <xs:sequence>
<xs:element name="incl_excl" type="filterIncl_exclType" default="INCLUSIVE" minOccurs="0"/>
<xs:element name="trackSource" type="trackSourceType" maxOccurs="unbounded"/> </xs:sequence>
</xs:complexType>
</xs:element>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
<xs:element name="geoFilter" nillable="false" minOccurs="0" maxOccurs="unbounded"> <xs:annotation>
<xs:documentation> </xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:choice>
<xs:element name="rectangular" nillable="false" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="leftTopCorner">
<xs:annotation>
<xs:documentation>North/West corner of the rectangle</xs:documentation> </xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="longitude" type="nffi:longitudeType"/>
<xs:element name="latitude" type="nffi:latitudeType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="rightBottomCorner">
<xs:annotation>
<xs:documentation>South/Est corner of the rectangle</xs:documentation> </xs:annotation>
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="closedPolygon" nillable="false" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="point" minOccurs="3" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="circle" nillable="false" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="center">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="radius" type="xs:unsignedLong">
<xs:annotation>
<xs:documentation>Distance from the central point in meters</xs:documentation> </xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="XPathFilter" type="xs:string" nillable="false" minOccurs="0" maxOccurs="unbounded"/> <xs:element
name="maxFrame" nillable="false" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:unsignedLong">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
</xs:sequence>
</xs:complexType>

<xs:complexType name="SourceSystemType">
<xs:annotation>
<xs:documentation>Purpose: track data source identification for filtering.
Format: identifies track data owner/producer (system that releases the data and country which controls the system). The element
is critical for providing track uniqueness. Beeing a filter element no mandatory elements exists </xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="country" type="countryType" minOccurs="0"/>
<xs:element name="system" type="systemType" minOccurs="0"/>
<xs:element name="subsystem" type="systemType" minOccurs="0"/> </xs:sequence>
</xs:complexType>


<xs:simpleType name="countryType">
<xs:annotation>
<xs:documentation>Purpose: National allegiance of the track data source.
Format: String of Three letter-codes. For proper values in this filter, refer to the Geographical Entity codes as specified in the FFI
MTF. To accept the wildchar % the lenght can be from 1 to 3</xs:documentation> </xs:annotation>
<xs:maxLength value="3"/>
<xs:pattern value="([%A-Z])*"/>
</xs:restriction>
</xs:simpleType>


<xs:simpleType name="systemType">
<xs:annotation>
<xs:documentation>Purpose: Identification of the system which releases data.
Format: string of up to 30 characters. Following characters are permissible: [A-Z], [a-z], [0-9], period, comma, colon, asterisk, and
dash.</xs:documentation>
</xs:annotation>
<xs:pattern value="([%A-Za-z0-9\.,:\*\-])*"/>
</xs:restriction>
</xs:simpleType>


<xs:simpleType name="transponderIdType">
<xs:annotation>
<xs:documentation>Purpose: Data transmitting device identification / originator identification.
Format: String of up to 60 characters. Following characters are permissible: [A-Z], [a-z], [0-9], period, comma, colon, asterisk,
and dash.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string"> <xs:minLength value="1"/>
<xs:pattern value="([%A-Za-z0-9\.,:\*\-])*"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="filterIncl_exclType">
<xs:enumeration value="INCLUSIVE"/>
<xs:enumeration value="EXCLUSIVE"/>
</xs:restriction>
</xs:simpleType>


<xs:complexType name="trackSourceType">
<xs:annotation>
<xs:documentation>Purpose: unambiguous identification of data source.
Format: contains a value being a combination of data on the device that transmitted the data and the system which releases the
data. The value has to be unique for every device/system in order to unambiguously identify the source of information.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="sourceSystem" type="SourceSystemType" minOccurs="0"/>
<xs:element name="transponderId" type="transponderIdType" minOccurs="0"/>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
</xs:sequence>
</xs:complexType>
</xs:schema>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
Normative “NFFI_13_ReqResFilter.xsd”
XML-Code 22 Normative “NFFI_13_ReqResFilter.xsd”


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:nffi="urn:nato:fft:protocols:nffi13"
xmlns:error="urn:nato:fft:protocols:sip3:errors" xmlns:compr="urn:nato:fft:protocols:sip3:compression"
xmlns="urn:nato:fft:protocols:sip3" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:qry="urn:nato:fft:protocols:nffi13:query" targetNamespace="urn:nato:fft:protocols:sip3" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="urn:nato:fft:protocols:nffi13" schemaLocation="NFFI_13.xsd"/>
<xs:import namespace="urn:nato:fft:protocols:nffi13:query" schemaLocation="NFFI_13_Query.xsd"/>

<xs:complexType name="ReqResPeriodType">
<xs:annotation>
<xs:documentation>ReqRes time frame filter(not needed for the subscription)</xs:documentation> </xs:annotation>
<xs:attribute name="start" type="nffi:dateTimeType" use="required"/>
<xs:attribute name="end" type="nffi:dateTimeType"/>
</xs:complexType>
<xs:element name="ReqResFilter"> <xs:annotation>
<xs:documentation>ReqRes data filter (is the standard filter plus the time frame)</xs:documentation> </xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="period" type="ReqResPeriodType" nillable="false" minOccurs="0"/> <xs:element ref="qry:NFFIFilter"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
SIP3 PROFILING FOR THE FFI MTF MESSAGES
INTRODUCTION
SIP3 is a Web services based interface recommended for exchange and access of Friendly
Force Tracking (FFT) data. It only describes the web services interface and the protocol used
for the communication but does not mandate either the format of the data or the way in which
the data of interest is selected.
This section explains how to use the SIP3 v1.2 protocol to filter and exchange FFI MTF
formatted messages. In detail it describes:
 General message dependent rules.
 How to compose valid SIP3 messages using the NFFI_13_Query filter dialect and the FFI
MTF payload.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
GENERAL RULES
The usage of the FFI MTF message format induces the following restrictions to the SOAP
messages:
BR-SIP3 Profile-1. Some of the FFI MTF elements are unqualified (do not belong to
any namespace). For this reason the default namespace MUST NOT be defined for the
FFI MTF elements. As a consequence, the default namespace cannot be declared for
the //SIP3DataResponse/Message/ element and for any of its ancestors or the default
namespace MUST be undeclared before the unqualified elements.
BR-SIP3 Profile-2. The namespace prefix “mtf” MUST be always used to indicate the
"urn:nato:mtf:app-11(d):1:ffi" namespace.
PULL MODE
This section describes:
 How to compose valid SIP3 request messages having the filter expressed in the
NFFI_13_Query filter language.
 How to compose valid SIP3 response messages containing an FFI MTF data payload.
Request
BR-SIP3 Profile-3. The SIP3 Data Consumer MAY request any response data dialect
pre-agreed with the SIP3 Data Producer.
BR-SIP3 Profile-4. The SIP3 Data Consumer MAY request any filtering language pre-
agreed with the SIP3 Data Producer.
BR-SIP3 Profile-5. The SIP3 Data Producer, in order to be backward compatible,

MUST at least support the NFFI-13-Query language.
The NFFI-13-Query language offers the users two query dialects.

 The first, defined in the namespace “urn:nato:fft:protocols:nffi13:query”, is a generic
Friendly Force Tracking (FFT) track selection language based on the NFFI v1.3 data
model. It is intended to select single or group of tracks depending on characteristics like
the nationality, system ID, tracker ID, and others. This query dialect is intended to filter
live data where the concept of time is not relevant.
 The second, defined in the namespace “urn:nato:fft:protocols:sip3:reqresfilter”, is an
extension of the first query dialect which adds the concept of time frame filtering. This
query dialect is intended to filter stored and/or historical data.
BR-SIP3 Profile-6. The Pull Mode is used mainly to retrieve historical data or to
synchronize SIP3 Track servers.
The SIP3 data request element //sip3:SIP3DataRequest/sip3:filter MUST contain (have
as descendant) the root node of the query message (i.e. the XML element //sip3-
f:ReqResFilter ).
BR-SIP3 Profile-7. The attribute //sip3:SIP3DataRequest/sip3:filter@Dialect of the

SIP3 request message MUST have the value “urn:nato:fft:protocols:sip3:reqresfilter”.
A SIP3 Data consumer can request to receive FFT Tracks in a specific message format. For
the two most common formats the following rules apply:

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
BR-SIP3 Profile-8. To request data in FFI MTF format the element

//sip3:SIP3DataRequest/sip3:ResponseDialect in the SIP3 request MUST have the
value “urn:nato:mtf:app-11(d):1:ffi”.
BR-SIP3 Profile-9. To request data in NFFI-13 format the element

//sip3:SIP3DataRequest/sip3:ResponseDialect of the SIP3 request MUST have the
value “urn:nato:fft:protocols:nffi13”.
XML-Code 23 is an example of a SIP3 data request SOAP message requesting a response in

FFI MTF format:
XML-Code 23 SIP3 data request message
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sip3="urn:nato:fft:protocols:sip3"

xmlns:cmp="urn:nato:fft:protocols:sip3:compression" xmlns:qry="urn:nato:fft:protocols:nffi13:query">
<soapenv:Header>
<sip3:CompressionAlgsSupported>
<compression xmlns="urn:nato:fft:protocols:sip3:compression">NONE</compression>
</sip3:CompressionAlgsSupported>
</soapenv:Header>
<soapenv:Body>
<sip3:SIP3DataRequest>
<sip3:ResponseDialect></sip3:ResponseDialect>
<sip3:Filter Dialect="urn:nato:fft:protocols:sip3:reqresfilter">
<sip3:ReqResFilter> <qry:NFFIFilter>
…………..
</qry:NFFIFilter>
</sip3:ReqResFilter>
</sip3:Filter>
</sip3:SIP3DataRequest>
</soapenv:Body>
</soapenv:Envelope>
Response
BR-SIP3 Profile-10. The //sip3:SIP3DataResponse/sip3:Message@Dialect attribute of

the SIP3 response message MUST contain the value “urn:nato:mtf:app-11(d):1:ffi” to
indicate that the track message is in APP-11(D)(1) FFI MTF format.
BR-SIP3 Profile-11. The //sip3:SIP3DataResponse/sip3:Message@Dialect attribute of

the SIP3 response message MUST contain the value “urn:nato:fft:protocols:nffi13” to
indicate that the track message is in NFFI version 1.3 format.
BR-SIP3 Profile-12. The Consumer MAY drop the received message, if the Dialect
attribute does not match the requested ResponseDialect.
BR-SIP3 Profile-13. If the returned track message is not compressed the SIP3 data
response element //sip3:SIP3DataResponse/sip3:Message MUST contain (have as
descendant) the root node of the returned track message (i.e. the XML element
//mtf:FriendlyForceInformation). See XML-Code 24 for an example.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
BR-SIP3 Profile-14. If the returned track message is compressed the SIP3 data
response element //sip3:SIP3DataResponse/sip3:Message MUST contain the Base64
encoded format of the compressed message (see XML-Code 25). The compressed
message is built by compressing the content of the
//sip3:SIP3DataResponse/sip3:Message element that SHOULD be returned in case the
compression is not enabled (see XML-Code 26).
XML-Code 24 Uncompressed response message example
<soapenv:Header>
<CompressionAlgUsed xmlns="urn:nato:fft:protocols:sip3">NONE</CompressionAlgUsed>
</soapenv:Header>
<soapenv:Body>
<sip3:SIP3DataResponse xmlns:sip3="urn:nato:fft:protocols:sip3">
<sip3:allAvailableDataTransferred>true</ sip3:allAvailableDataTransferred>
<sip3:Message Dialect=”urn:nato:mtf:app-11(d):1:ffi”>
<mtf:FriendlyForceInformation xmlns:mtf="urn:nato:mtf:app-11(d):1:ffi">
<MessageIdentifier>
……..
</sip3:Message>
</sip3:SIP3DataResponse>
</soapenv:Body>
</soapenv:Envelope>
XML-Code 25 Compressed response message example
<soapenv:Header>
<CompressionAlgUsed xmlns="urn:nato:fft:protocols:sip3">GZIP</CompressionAlgUsed>
</soapenv:Header>
<soapenv:Body>
<sip3:SIP3DataResponse xmlns:sip3="urn:nato:fft:protocols:sip3">
<sip3:allAvailableDataTransferred>true</ sip3:allAvailableDataTransferred>
<sip3:Message Dialect=”urn:nato:mtf:app-11(d):1:ffi”>
H4SIAAA………………..
</sip3:Message>
</sip3:SIP3DataResponse>
</soapenv:Body>
</soapenv:Envelope>
XML-Code 26 Example of track message to be compressed
<mtf:FriendlyForceInformation xmlns:mtf="urn:nato:mtf:app-11(d):1:ffi">
<MessageIdentifier>
……..
PUSH MODE
This section describes:
 How to compose valid SIP3 subscription messages having the filter expressed in the
NFFI_13_Query filter language.
 How to compose valid SIP3 response messages containing an FFI MTF data payload.
Subscription Request

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
BR-SIP3 Profile-15. The SIP3 Data Consumer MAY subscribe using any response
data dialect pre-agreed with the SIP3 Subscription Manager.
BR-SIP3 Profile-16. The SIP3 Data Consumer MAY subscribe using any filtering
language pre-agreed with the SIP3 Subscription Manager.
BR-SIP3 Profile-17. The SIP3 Subscription Manager, in order to be backward

compatible with the SIP3 V1.1 [Ref 13] SIP3 Data Consumers, MUST at least support
the NFFI-13-Query language.
The NFFI-13-Query language offers the users two query dialects.

 The first, defined in the namespace “urn:nato:fft:protocols:nffi13:query”, is a generic
Friendly Force Tracking (FFT) tracks selection language based on the NFFI v1.3 data
model. It is intended to select single or group of tracks depending on characteristics like the
nationality, system ID, tracker ID and others. This query dialect is intended to filter live data
where the concept of time is not relevant.
 The second, defined in the namespace “urn:nato:fft:protocols:sip3:reqresfilter”, is an
extension on the previous that adds the concept of the time frame filtering. This query
dialect is intended to filter stored and/or historical data.
BR-SIP3 Profile-18. The Push Mode being mainly used to retrieve live data, it MUST
use the “urn:nato:fft:protocols:nffi13:query” query dialect.
BR-SIP3 Profile-19. The SIP3 subscription message element

//wse:Subscribe/wse:Filter MUST contain (have as descendant) the root node of the
query message (i.e. the XML element nffi-q:NFFIFilter)
BR-SIP3 Profile-20. The attribute //wse:Subscribe/wse:Filter@Dialect of the SIP3

subscription message MUST have the value “urn:nato:fft:protocols:nffi13:query”.
A SIP3 Data consumer can subscribe for FFT Tracks in a specific message format. For the two
most common formats the following rules apply:
BR-SIP3 Profile-21. To subscribe to FFT data in FFI MTF format the

//wse:Subscribe/sip3:SubscriptionParameter/sip3:ResponseDialect element in the
SIP3 subscription MUST have the value “urn:nato:mtf:app-11(d):1:ffi”.
BR-SIP3 Profile-22. To subscribe to FFT data in NFFI-13 format the value of the
//wse:Subscribe/sip3:SubscriptionParameter/sip3:ResponseDialect element in the
SIP3 subscription MUST have the value “urn:nato:fft:protocols:nffi13”.
XML-Code 27 Example of a SIP3 subscription message
<s:Envelope
xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/Submission/ws-addressing"
xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing"> <s:Header>
.......
.......
</s:Header>
<s:Body>
<wse:Subscribe>
<wse:EndTo>
<a:Address>http://localhost:8080/SubscriptionEnd</a:Address>
</wse:EndTo>
<dmb:MinTime>20</dmb:MinTime>
<dmb:Heartbeats>true</dmb:Heartbeats>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
<wse:NotifyTo>
<a:Address>http://localhost:8080/TrackPush</a:Address>
<a:ReferenceParameters>
<MySubscription xmlns="urn:MyNamespace">1234567890</MySubscription> </a:ReferenceParameters>
</wse:NotifyTo>
</wse:Delivery>
<wse:Filter Dialect="urn:nato:fft:protocols:nffi13:query">
<nffi-q:NFFIFilter xmlns:nffi-q="urn:nato:fft:protocols:nffi13:query">
………
………
</nffi-q:NFFIFilter>
</wse:Filter>
<SIP3SubscriptionParameter xmlns="urn:nato:fft:protocols:sip3">
<ResponseDialect>urn:nato:mtf:app-11(d):1:ffi</ResponseDialect>
<MultipleTrackAllowed>true</MultipleTrackAllowed>
</SIP3SubscriptionParameter>
</wse:Subscribe>
</s:Body>
</s:Envelope>
Notification Message
The notification message sent by the SIP3 event source to subscribed receivers is the same
as the “PUSH mode” response message.
BR-SIP3 Profile-23. All the rules and limitations described in this document for the
“PUSH mode” response message MUST be applied to the notification message.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX E to ADatP-36
INTENTIONALLY BLANK

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX F to ADatP-36
– TECHNICAL SPECIFICATION – SECURITY CROSS

DOMAIN
SECURITY MARKING
BR-Security-1. It is REQUIRED that data in a classified environment is marked against

prevailing security classification. Also data in an unclassified environment should be
properly marked to define the intended public for the information in this data. Security
marking rules are expressed in a security/Information management policy valid for the
environment/operation as defined within the respective operational orders and other
supporting documentation.
BR-Security-2. The FFI MTF allows detailed security marking of individual data blocks
within the report, so the data SHALL NOT be released into domains with inappropriate
security levels.
BR-Security-3. Each security marking consists of the security policy, security

classification and security category elements [Ref 10].
BR-Security-4. The message header itself is not classified.
BR-Security-5. All information within one message SHALL apply the same security
policy, but MAY have different classification levels within this policy and MAY have
different security categories.
The FFI MTF message allows three levels of Security Marking of FFI data as shown in Figure
17.
F-1 Edition A Version 2

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX F to ADatP-36
Figure 17 FFI Classification
LEVEL 1
The “message security marking” is a marking that encompasses the overall security level. It is
contained in the MessageIdentifier element.
BR-Security-6. The message security marking SHALL equate at least to the highest
security level within the message (highest of any track included in the payload).
LEVEL 2
BR-Security-7. This classification provides the overall security classification of the data
of a single track and SHALL be at least at the highest level of the related Blue Dot Data
and Details Data.
LEVEL 3
BR-Security-8. The security classification of track details MAY be further subdivided

into:
 Blue Dot Data consisting of Track Source and Track Positional Data,
 Details consisting of Track Identification, Other ID, Operational Status, Track
Movement, Track Planned Location and Detail Data.
Both sections can be marked independently by the originating system.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX F to ADatP-36
AUGMENTATION DATA CLASSIFICATION
BR-Security-9. The Augmentation Table SHALL be classified at the highest level of
any augmentation data entry as assigned by the system owner.
BR-Security-10. If an augmentation data entry is combined with the Blue Dot Data (the
track is augmented), the track SHALL be classified at the highest level of the two or at
a higher classification as directed by the data owner.
BR-Security-11. Classification markings of augmentation data entries and the

combination of Blue Dot Data and Augmentation Data Entry SHALL be entered in the
Augmentation Table.
BR-Security-12. If Augmentation Data is combined with Blue Dot Data, the individual
element markings SHALL be maintained.
Table 12 Classification of Augmented Track
Blue Dot
Track Classification Classification Details Classification
Blue Dot Data Equal to Blue Dot As assigned by system None
classification owner
Augmentation Data None None Assigned by system
Entry owner
Augmented Track Highest level of Blue As assigned by system As assigned by system
(Blue Dot + Details) Dot or Details or owner owner
higher as directed by
data owner
BR-Security-13. In all instances the security policy, security classification and security
category MAY be selected individually.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX F to ADatP-36
INTENTIONALLY BLANK

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36
– TECHNICAL SPECIFICATION – OPERATIONAL CROSS-DOMAIN
MAPPING FFI TO FIXED-FIELD MESSAGE FORMATS

Implementing a mapping agent from FFI to fixed-field formats, e.g., LINK-16, presents the problem of dealing with optional FFI elements, which are required for
the target format.
There is no generally applicable solution for this if not making all the corresponding FFI fields as a mandatory, which would not be acceptable for other reasons10.
The introduction of default values in FFI (as mentioned before) has not been made since it creates interpretation problems.
MAPPING DECISIONS AND IMPLEMENTATION

Mapping decisions and implementation can only (and therefore “shall”) be done in the specific FFT Proxy. Since mapping choices might vary from
configuration to configuration, mapping choices should be configurable to the greatest extent possible.
MAPPING LANGUAGE CONSTRUCTS

Following constructs have been used in the mapping algorithm column C of Table 14 and
Table 15 to have an unambiguous implementation.
Table 13 Mapping language constructs
Statements
<statement1> Normal sequence of statements. <statement2> will be processed after <statement1> is completely processed.
<statement2>
IF <condition1> THEN Regular IF clause. IF <condition1> is met, only <statement1> will be executed. If <condition1> is not met, but
(<statement1>) <condition2> is met, then only <statement2> will be executed. More conditions and statements can sequentially
10 For example, the reasons that were used to make them optional FFI fields without this mapping consideration.
G-1 Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36
[ELSE IF <condition2> THEN be listed. If none of the before listed conditions are met, and an optional OTHERWISE element is included, only
(<statement2>)] <statement3> will be executed.
[OTHERWISE In order to read the nesting correctly, the relevant statement or list of statements is embraced with a bracket.
(<statement3>)]
<target variable>:=<term> Assigns the result of the evaluated <term> to a <target variable>. Implies the existence or generation of the
element and necessary parent elements.
Generate <element> Generates an empty element in the Target structure. If necessary, this is an implied action for any element and
parent element, that is filled with a statement <element>:=<value>
Do not generate <element> Instruction to not generate the expressed <element> in the target structure.
Functions
ABS(<number>) Returns the absolute value of a <number>, a number without signs.
CONCAT(<string1>,…,<string_n>) Returns a string that sequentially combines non-empty <string1> to <string_n>
CONTAINS(<string1>,<string2>) Returns true, if <string2> is a substring of <string1>, otherwise returns false.
FORMAT(<value>,<pattern>) Returns a string, that represents the <value> formatted with the <pattern>. <pattern> can contain
following characters:
# for a digit (leading zeros are suppressed)
0 for a digit (leading zeros are expressed as 0)
. for a decimal delimiter (will be skipped, if no decimal places follow).

INT(<number>) Returns the integer part of a <number> by dropping the non integer part of a number. This would
result in the following behaviour: INT(5.3) = 5, INT(-5.3) = -5.
LENGTH(<string>) Returns the number of characters contained in the given <string>. Returns zero for empty strings.
REPLACE(<string>,<original characters>,<replacement Replaces all occurrences of <original characters> by <replacement characters> in a <string> and
characters>) returns the updated string. If the <original characters> and <replacement characters> contain more
than one character, they are to be read as pairs: first <original character> will be replaced with first
<replacement character>, and so on.
ROUND(<number>) Returns <number> rounded to the nearest integer.
SUBSTR(<string>,<number1>,<number2>) Returns the substring from <string> that starts at character <number1> and is <number2>
characters long. If <number1> is larger than the length of string, returns empty string. If
<number1>+<number2> is larger than length it returns the maximum available characters starting at
character <number1>.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36
<element> contains data Returns the opposite result from the “does not contain data” function.
<element> does not contain data Returns the value true, if the <element> does not exist or contains special values for xml type
double NaN or INF, a XML type string contains an empty string. For ADatP-3ADatP-3(A) MTFs, the
occurrence of the attribute xsi:nil=’true’ is accounted as “does not contain data”.
Operators
<value1>=<value2> Operation returns true, if both <value1> and <value2> are equal, and returns false otherwise. Both
parameters can be variables, fixed values or evaluated terms.
>, >=, <, <= Regular mathematical operators greater than, greater than or equal, less than, less than or equal.
Returns values true or false.
<value1> <> <value2> Operator returns true, if operands are not equal or exactly one operand does not contain data.
Returns false otherwise.
<value1> AND <value2> Regular logical operators to combine logical terms.
<value1> OR <value2>
<value> is valid for <element> Operation returns true, if <value> is a valid content for <element> in terms of XML validity, and
returns false otherwise.
Other Constructs
“string” Quotation marks are used to mark a string constant.
{ text } Textual description of complex functionality.
BACKWARD COMPATIBILITY MAPPING FROM NFFI TO FFI MTF

This mapping assumes, that the source message is a valid NFFI message instance, following the rules of the Interim NFFI Standard for Interoperability of FTS
[Ref 11].
BR-Mapping-1. If at least one of the blue dot fields in a track of an NFFI message is invalid (according to the NFFI D-document [Ref 11]), the track
SHALL be dropped from the message by the NFFI to FFI MTF Proxy.
The target message has to be created according to the business rules of this specification.
BR-Mapping-2. If a track resulting from the mapping rules contains one or more invalid blue dot fields, the track SHALL be dropped from the message
and not forwarded.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36
Table 14 provides information on which NFFI source data element value is mapped to which FFI MTF target data elements, and explains specific limitations.
BR-Mapping-3. An NFFI to FFI MTF Proxy SHALL implement all lines as shown in Table 14 if marked as Required for Minimum Implementation (column
D).
BR-Mapping-4. An NFFI to FFI MTF Proxy MAY implement lines as shown in Table 14 not marked as Required for Minimum Implementation (column
D).
BR-Mapping-5. If a target FFI MTF set does not contain any filled fields based on the mapping rules, the set element itself MUST NOT be generated.
Individual lines of Table 14 can be referred to as: BR-Mapping NFFI to FFI-X-Y, where X and Y are the numbers in the first two columns.
Table 14 NFFI to FFI Mapping
Declaration of used elements Required for

Group Rule General mapping instructions and
Target: FFI MTF elements (/mtf:FriendlyForceInformation/…) Mapping details/ pseudo algorithm Minimum
No. No. noticeable limitations of target element
Source NFFI 1.3.1 elements (/NFFIMessage/track/…) Implementation
X Y A B C D
NFFI FIELDS THAT CANNOT BE FORWARDED TO FFI
0 1 Source1: …/deviceSpecificData/additionalId No equivalent FFI element Drop Source1 information X

0 2 Source1: …/deviceSpecificData/phoneNumber No equivalent FFI element Drop Source1 information X
0 3 Source1: …/deviceSpecificData/serialNumber No equivalent FFI element Drop Source1 information X
0 4 Source1: …/deviceSpecificData/terminalType No equivalent FFI element Drop Source1 information X
0 5 Source1: …/deviceSpecificData/terminalId No equivalent FFI element Drop Source1 information X
0 6 Source1: …/deviceSpecificData/specialUserDefined No equivalent FFI element Drop Source1 information X
0 7 Source1: …/detailData No equivalent FFI element Drop Source1 information X
EXERCISE IDENTIFICATION
1 0 Target1: …/ExerciseIdentification Generate element, if any of the sub- Generate Target1, if any of its
elements are used. subelements is generated
1 1 Target1: …/ExerciseIdentification/ExerciseNickname No equivalent NFFI element. IF Const1 contains data THEN

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
Const1: System specific value for Exercise Nickname Can be filled with fixed value (Target1:=Const1)
OTHERWISE
(Do not generate Target1)
1 2 Target1: …/ExerciseIdentification/ExerciseIdentifier No equivalent NFFI element. Do not generate Target1 X
OPERATION CODEWORD
2 0 Target1: …/OperationCodeword Generate element, if any of the sub- Generate Target1, if any of its
2 1 Target1: …/OperationCodeword/OperationCodeword No equivalent NFFI element. IF Const1 does not contain data AND
Const2 contains data THEN
Const1: System specific value for Exercise Nickname
Notes:
(Target1:=Const2)
Const2: System specific value for Operation Codeword Can be filled with fixed value, but is
mutually exclusive from Exercise OTHERWISE
Nickname in Exercise Identification (Do not generate Target1)
element
2 2 Target1: …/OperationCodeword/PlanOriginatorAndNumber No equivalent NFFI element. Do not generate Target1 X
2 3 Target1: …/OperationCodeword/OptionNickname No equivalent NFFI element. Do not generate Target1 X
2 4 Target1: …/OperationCodeword/SecondaryOptionNickname No equivalent NFFI element. Do not generate Target1 X
MESSAGE IDENTIFIER
3 0 Target1: …/MessageIdentifier Generate element Generate Target1 X

3 1 Target1: …/MessageIdentifier/MessageTextFormatIdentifier Fixed value: "FFI" Target1:="FFI" X
3 2 Target1: …/MessageIdentifier/Standard Fixed value: "APP-11(D)" Target1:="APP-11(D)" X
3 3 Target1: …/MessageIdentifier/Version Fixed value: "1" Target1:="1" X
3 4 Target1: …/MessageIdentifier/Originator Proxy system specific value REQUIRED Target1:=Const1 X
Const1: Proxy system value for Originator
3 5 Target1: …/MessageIdentifier/MessageSerialNumber No equivalent NFFI element. Target1:=Var1
Var1: Proxy system specific counter for Serial Number of Generated by Proxy system, MAY be used
Message in combination with content of Originator

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
and ReferenceTimeOfPublication to
uniquely identify a message
Notes:
1) 1-7 alphanumeric characters
3 6 Target1: …/MessageIdentifier/ReferenceTimeOfPublication/ Generate current value for either month or IF Var1 contains data THEN X
MonthNameAbbreviated time. Values are mutually exclusive. (Target1:=Var1
Target2: …/MessageIdentifier/ReferenceTimeOfPublication/ Do not generate Target2)
DateTimeIso
OTHERWISE
Var1: Current month name in standard English 3-letter
abbreviation (Target2:=Var2
Var2: Current date-time in ISO format Do not generate Target1)
3 7 Target1: …/MessageIdentifier/Qualifier No equivalent NFFI element. Do not generate Target1 X

3 8 Target1: …/MessageIdentifier/SerialNumberOfQualifier No equivalent NFFI element. Do not generate Target1 X
3 9 Target1: …/MessageIdentifier/MessageSecurityPolicy No equivalent NFFI element for complete Target1:=Const1 X
Const1: Network specific value for Security Policy message. Network specific default value
REQUIRED.
3 10 Target1: …/MessageIdentifier/MessageClassification/ No equivalent NFFI element for complete If Var1 contains data THEN X
SecurityClassificationExtended message. Network system specific default (IF Var1 is valid for Target1 THEN
Target2: …/MessageIdentifier/MessageClassification/ value REQUIRED. Var1 is a placeholder
which MAY be produced by the Proxy (Target1:=Var1
system, based on received information. It Do not generate Target2
Var1: Calculated highest classification of tracks contained in is empty, if the highest level of
message classification of processed tracks cannot )
Const1: Network specific value for highest permitted classification be decided. OTHERWISE
Const1 is a REQUIRED network specific (Target2:=Var1
default value for the highest classification
that can be processed on the network or Do not generate Target1
system. In the algorithm the valid content )
of Const1 is assumed.
)
If classification label is available in the
OTHERWISE
enumeration of Target1, this alternative
SHALL be used, Use Target2 otherwise. (IF Const1 is valid for Target1 THEN
(Target1:=Const1

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
Do not generate Target2
)
OTHERWISE
(Target2:=Const1
)
)
3 11 Target1: …/MessageIdentifier/MessageSecurityCategory No equivalent NFFI element for complete If Var1 contains data THEN
Var1: Calculated category of tracks contained in message message. Network specific default value (Target1:=Var1)
REQUIRED.
Const1: Network specific value for category ELSE IF Const1 contains data THEN
Var1 is a placeholder which MAY be
produced by the Proxy system, based on (Target1:=Const1)
received information. It is empty, if the OTHERWISE
most restrictive level of category of
processed tracks cannot be decided. (Do not generate Target1)
Const1 is a REQUIRED network specific
default value for the most restrictive
category that can be processed on the
network or system.
REFERENCE
4 0 Target1: …/Reference and all sub-elements No equivalent NFFI element. Do not generate Target1 X
GEODETIC DATUM
5 0 Target1: …/GeodeticDatum Generate element Generate Target1 X

5 1 Target1: …/GeodeticDatum/GeodeticDatum NFFI standard is WGS 1984 [Ref 19] as Target1:="WGE" X
geodetic datum
5 2 Target1: …/GeodeticDatum/NationalGridSystemCoordinates No equivalent NFFI element. Do not generate Target1 X
TRACK INFORMATION
6 0 Target1: …/TrackInformation For each NFFI track generate an FFI Generate Target1 X
Track Information.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
Source1: /NFFIMessage/track
TRACK SOURCE
7 0 Target1: …/TrackInformation/TrackSource Generate element Generate Target1 X

7 1 Target1: …/TrackInformation/TrackSource/TransponderId NFFI format allows ":" characters which IF CONTAINS(Source1, “:”) THEN X
Source1: …/positionalData/trackSource/transponderId are prohibited in ADatP-3(A) message due (Drop whole track)
to special purpose of character as field
descriptor delimiter OTHERWISE
(Target1:=Source1)
Notes:
2) No modification of value allowed
Character ":" cannot be used in FFI. Only
NFFI transponderId that are valid in
FFI SHALL be forwarded due to
significance of field.
Special attention in network management
required to make sure that the
transponder IDs are valid in NFFI
and FFI in a mixed network.
7 2 Target1: …/TrackInformation/TrackSource/System Copy from NFFI, but consider prohibited IF Source1 is valid for Target1 THEN X
Source1: …/positionalData/trackSource/sourceSystem/system characters in FFI (Target1:=Source1)
Notes: OTHERWISE
3) No modification of value allowed (Drop whole track)
Characters "a"-"z", "*" and ":" cannot be
used in FFI. Only NFFI system
names that are valid in FFI SHALL
be forwarded due to significance of
field.
subsystem names are valid in NFFI
7 3 Target1: …/TrackInformation/TrackSource/Subsystem Copy from NFFI, but consider prohibited IF Source1 does not contain data THEN X
characters in FFI
Source1: …/positionalData/trackSource/sourceSystem/subsystem (Do not generate Target1)

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
ELSE IF Source1 is valid for Target1
Notes:
THEN
4) No modification of value allowed
(Target1:=Source1)
Characters "a"-"z", "*" and ":" cannot be
used in FFI. Only NFFI subsystem OTHERWISE
names that are valid in FFI SHALL (Drop whole track)
be forwarded due to significance of
field.
subsystem names are valid in NFFI
7 4 Target1: …/TrackInformation/TrackSource/Nationality/ Simple translation IF Source1 does not contain data THEN
GeographicalEntity
(Do not generate Target1
Notes:
Target2: …/TrackInformation/TrackSource/Nationality/
5) Alternative with enumeration SHALL Do not generate Target2)
NonStandardGeographicalEntity
be used, if value is contained. The ELSE IF Source1 = “XXN” THEN
Source1: …/positionalData/trackSource/sourceSystem/country free text alternative SHALL only be
used, if no equivalent value is (Target1:= “XXE”
available in the enumeration and Do not generate Target2)
value is agreed in the network.
ELSE IF Source1 is valid for Target1
6) The code used to express NATO as THEN
Gateway Nationality is different in the
two standards. (Target1:=Source1
Do not generate Target2)
OTHERWISE
(Target2:=Source1
Do not generate Target1)
7 5 Target1: …/TrackInformation/TrackSource/Reliability Simple translation IF Source1 does not contain data THEN
Source1: …/positionalData/reliability (Do not generate Target1)
ELSE IF Source1 = “COMPLETELY
RELIABLE” THEN
(Target1:=“A”)
ELSE IF Source1 = “USUALLY
RELIABLE” THEN

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
(Target1:=“B”)
ELSE IF Source1 = “FAIRLY RELIABLE”
THEN
(Target1:=“C”)
ELSE IF Source1 = “NOT USUALLY
RELIABLE” THEN
(Target1:=“D”)
ELSE IF Source1 = “UNRELIABLE”
THEN
(Target1:=“E”)
ELSE IF Source1 = “RELIABILITY
CANNOT BE JUDGED” THEN
(Target1:=“F”)
7 6 Target1: …/TrackInformation/TrackSource/Credibility Simple translation IF Source1 does not contain data THEN
Source1: …/positionalData/credibility (Do not generate Target1)
ELSE IF Source1 = “CONFIRMED BY
OTHER SOURCES” THEN
(Target1:=“1”)
ELSE IF Source1 = “PROBABLY TRUE”
THEN
(Target1:=“2”)
ELSE IF Source1 = “POSSIBLY TRUE”
THEN
(Target1:=“3”)
ELSE IF Source1 = “DOUBTFULLY
TRUE” THEN
(Target1:=“4”)
ELSE IF Source1 = “IMPROBABLE”
THEN
(Target1:=“5”)

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
ELSE IF Source1 = “TRUTH CANNOT
BE JUDGED” THEN
(Target1:=“6”)
TRACK SECURITY LABEL
8 0 Target1: …/TrackInformation/TrackSecurityLabel Generate element Generate Target1 X

8 1 Target1: …/TrackInformation/TrackSecurityLabel/ No equivalent NFFI element for complete { If all existing Source fields are equal or X
TrackSecurityPolicy track. Source system specific default value empty, use this value for Target1,
Source1: …/positionalData/@secPolicyName required or common policy from all source otherwise assign network specific value
fields. from Const1 }
Source2: …/identificationData/@secPolicyName
Source3: …/operStatusData/@secPolicyName
Source4 …/deviceSpecificData/@secPolicyName
Source5: …/detailData/@secPolicyName
Const1: Network specific value for security policy
8 2 Target1: …/TrackInformation/TrackSecurityLabel/ No equivalent NFFI element for complete { If fields Source1 to Source5 are equal X
TrackSecurityClassification/ track. or empty, evaluate the highest value
SecurityClassificationExtended If Source1 to Source5 are empty or from Source6 to Source10. Use this
value for Target1 or Target2, as
Target2: …/TrackInformation/TrackSecurityLabel/ contain the same value, evaluate the
TrackSecurityClassification/SecurityClassification highest value from Source6 to Source10. appropriate, otherwise assign network
If not possible, use Const1 as network specific value from Const1. }
Source1: …/positionalData/@secPolicyName
default value.
Target1 to be used, whenever possible.
Source3: …/operStatusData/@secPolicyName Target2 otherwise.
Source6: …/positionalData/@secClassification
Source7: …/identificationData/@secClassification
Source8: …/operStatusData/@secClassification
Source9 …/deviceSpecificData/@secClassification
Source10: …/detailData/@secClassification

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
Const1: Network specific value for highest permitted security
classification
8 3 Target1: …/TrackInformation/TrackSecurityLabel/ No equivalent NFFI element for complete { If fields Source1 to Source5 are equal
TrackSecurityCategory track. or empty, evaluate the most restrictive
Source1: …/positionalData/@secPolicyName If Source1 to Source5 are empty or value from Source6 to Source10. Use
contain the same value, evaluate the most this value for Target1, otherwise assign
Source2: …/identificationData/@secPolicyName network specific value from Const1. If
restrictive value from Source6 to
Source3: …/operStatusData/@secPolicyName Source10. If not possible, use Const1 as Const1 does not contain data, do not
network default value. generate Target1 }
Source6: …/positionalData/@secCategory
Source7: …/identificationData/@secCategory
Source8: …/operStatusData/@secCategory
Source9 …/deviceSpecificData/@secCategory
Source10: …/detailData/@secCategory
Const1: Network specific value for most restrictive security
category
8 4 Target1: …/TrackInformation/TrackSecurityLabel/ If NFFI security policy is identical to track { Compare policies and existing NATO
BlueDotSecurityClassification/ overall security policy above, then the markings and copy from NFFI. Otherwise
SecurityClassificationExtended positional data classification SHALL be do not generate Target1 }
Target2: …/TrackInformation/TrackSecurityLabel/ used for blue dot classification. Target1 to
be used, whenever possible. Target2
BlueDotSecurityClassification/SecurityClassification
otherwise.
Source2: …/positionalData/@secClassification Notes:
7) Only if security policies of track and
blue dot match
8 5 Target1: …/TrackInformation/TrackSecurityLabel/ If NFFI security policy is identical to track { Compare policies and copy from NFFI.
BlueDotSecurityCategory overall security policy above, then the Otherwise do not generate Target1 }
Source1: …/positionalData/@secPolicyName positional data security category SHALL
be used for blue dot security category.
Notes:
8) Only if security policies of track and
blue dot match

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
8 6 Target1: …/TrackInformation/TrackSecurityLabel/ Complex security rules need to be
DetailsSecurityClassification/ identified and agreed for a particular
SecurityClassificationExtended network prior to mapping this element.
Target2: …/TrackInformation/TrackSecurityLabel/ Target1 to be used, whenever possible.
Target2 otherwise.
DetailsSecurityClassification/SecurityClassification
Source6: …/positionalData/@secClassification
Source7: …/identificationData/@secClassification
Source8: …/operStatusData/@secClassification
Source9 …/deviceSpecificData/@secClassification
Source10: …/detailData/@secClassification
8 7 Target1: …/TrackInformation/TrackSecurityLabel/ Complex security rules need to be
DetailsSecurityCategory identified and agreed for a particular
Source1: …/positionalData/@secPolicyName network prior to mapping this element.
Source7: …/identificationData/@secCategory
Source8: …/operStatusData/@secCategory
Source9 …/deviceSpecificData/@secCategory
Source10: …/detailData/@secCategory
TRACK POSITIONAL DATA
9 0 Target1: …/TrackInformation/TrackPositionalData Generate element Generate Target1 X

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
9 1 Target1: …/TrackInformation/TrackPositionalData/Time Simple translation Target1/Year:=SUBSTR(Source1,1,4) X
Source1: …/positionalData/dateTime Target1/Month:=SUBSTR(Source1,5,2)
Notes:
9) All created target elements have to Target1/Day:=SUBSTR(Source1,7,2)
maintain the fixed length as in the Target1/TimeDelimiter:=“T”
NFFI element
Target1/Hour:=SUBSTR(Source1,9,2)
Target1/Minute:=SUBSTR(Source1,11,2)
Target1/Second:=SUBSTR(Source1,13,2
)
Target1/TimeZone:=“Z”
9 2 Target1: …/TrackInformation/TrackPositionalData/Location Simple translation Target1/LatitudeDegrees:= X
Source1: …/positionalData/coordinates/latitude FORMAT(INT(ABS(Source1)),00)
Notes:
Source2: …/positionalData/coordinates/longitude Target1/LatitudeMinutes04DecimalPlace
10) All numerical subelements of Target1
s:= FORMAT(INT(ABS(Source1)-
have a fixed format with 2 or 3
INT(ABS(Source1)) * 60 * 10000) /
integer places. In case the resulting
10000,00.####)
number is shorter than the specified
length, it needs to be filled with IF Source1 >= 0 THEN
leading zeros. (Target1/LatitudinalHemisphere:=“N”)
Latitude 0° will be expressed as Northern OTHERWISE
Hemisphere
(Target1/LatitudinalHemisphere:=“S”)
Longitude 0° will be expressed as Eastern
Hemisphere Target1/Hyphen:=“-”
Target1/LongitudeDegrees:=
FORMAT(INT(ABS(Source2)),000)
Target1/LongitudeMinutes04DecimalPlac
es:= FORMAT(INT(ABS(Source2)-
INT(ABS(Source2)) * 60 * 10000) /
10000,00.####)
IF Source2 >= 0 THEN
(Target1/LongitudinalHemisphere:=“E”)
OTHERWISE
(Target1/LongitudinalHemisphere:=“W”)

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
9 3 Target1: …/TrackInformation/TrackPositionalData/ Attribute twice in NFFI for latitude and IF Source1 does not contain data AND
HorizontalAccuracy longitude. FFI only has one field. Source2 does not contain data THEN
Source1: …/positionalData/coordinates/latitude/@accuracy FFI HorizontalAccuracy will only be (Do not generate Target1)
Source2: …/positionalData/coordinates/longitude/@accuracy produced in combination with a valid OTHERWISE
Location.
(IF Source1 contains data AND
Notes: Source2 does not contain data
11) The less accurate dimension value in THEN
the sources SHALL be used for the (Temp1:=Source1)
target element
ELSE IF Source2 contains data AND
The value in FFI needs to be between 1 Source1 does not contain
and 999 data THEN
(Temp1:=Source2)
ELSE IF Source1 >= Source2 THEN
(Temp1:=Source1)
ELSE IF Source1 < Source2 THEN
(Temp1:=Source2)
IF Temp1 < 1 THEN
(Target1:=1)
ELSE IF Temp1 > 999 THEN
(Target1:=999)
OTHERWISE
(Target1:=ROUND(Temp1))
)
9 4 Target1: …/TrackInformation/TrackPositionalData/Altitude Simple translation. IF Source1 does contain data THEN
Target2: …/TrackInformation/TrackPositionalData/VerticalAccuracy FFI VerticalAccuracy will only be produced (IF Source1 < -400 THEN
in combination with a valid Altitude.
Source1: …/positionalData/coordinates/altitude (Target1:=-400)
Source2: …/positionalData/coordinates/altitude/@accuracy Notes: ELSE IF Source1 > 99999 THEN
12) The value in FFI Altitude needs to be (Target1:=99999)
between -400 and 99999
OTHERWISE
13) The value in FFI VerticalAccuracy
needs to be between 1 and 999 (Target1:=ROUND(Source1))

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
IF Source2 does not contain data
THEN
OTHERWISE
(IF Source2 < 1 THEN
(Target2:=1)
ELSE IF Source2 > 999 THEN
(Target2:=999)
OTHERWISE
(Target2:=ROUND(Source2))
)
)
OTHERWISE
)
TRACK MOVEMENT DATA
10 0 Target1: …/TrackInformation/TrackMovementData Generate element, if any of the sub- Generate Target1, if any of its
10 1 Target1: …/TrackInformation/TrackMovementData/Bearing Round value for Bearing. Replace value IF Source1 contains data THEN
Target2: …/TrackInformation/TrackMovementData/ 360 with 0. For the BearingAccuracy, (IF ROUND(Source1) = 360 THEN
BearingAccuracy divide by 2 and round value.
(Target1:=0)
Source1: …/positionalData/bearing FFI BearingAccuracy will only be
produced in combination with a valid OTHERWISE
Source2: …/positionalData/bearing/@accuracy Bearing. (Target1:=ROUND(Source1))
Notes: IF Source2 contains data THEN
14) NFFI bearing uses real numbers (Target2:=ROUND(Source2 / 2))
between 0 and 360, FFI uses
integers only between 0 and 359 OTHERWISE

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
NFFI values 0 and 360 are technically )
identical OTHERWISE
NFFI accuracy uses real numbers (Do not generate Target1
between 0 and 360, FFI uses
integers between 0 and 180 Do not generate Target2)
NFFI accuracy describes the sector of )
uncertainty with the given bearing in
the centre of the uncertainty sector,
while FFI BearingAccuracy uses the
given angle at each side of the
bearing to describe the uncertainty
sector
10 2 Target1: …/TrackInformation/TrackMovementData/Speed For Speed and SpeedAccuracy, take the IF Source1 contains data THEN
rounded values and limit to maximum
Target2: …/TrackInformation/TrackMovementData/SpeedAccuracy (IF ROUND(Source1) > 999 THEN
value 999.
Source1: …/positionalData/speed (Target1/ContextQuantity000999:=
FFI SpeedAccuracy will only be produced 999)
Source2: …/positionalData/speed/@accuracy in combination with a valid Speed.
OTHERWISE
Notes: (Target1/ContextQuantity000999:=
15) NFFI data type uses real numbers ROUND(Source1))
>=0 and values above 999 km/h, FFI
uses integers only between 0 and Target1/
999 UnitOfSpeedVelocityMeasurement:=
“KPH”
FFI unit of measurements is always set to
km per hour IF Source2 contains data THEN
(IF ROUND(Source2) > 999 THEN
(Target2/ContextQuantity000999:=
999)
OTHERWISE
(Target2/ContextQuantity000999:=
ROUND(Source2))
Target2/
UnitOfSpeedVelocityMeasurement:=
“KPH”
)
OTHERWISE

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
)
OTHERWISE
)
10 3 Target1: …/TrackInformation/TrackMovementData/Inclination For FFI Inclination, map rounded values IF Source1 contains data THEN
Target2: …/TrackInformation/TrackMovementData/ from 0 to 360 (excluding 91 to 269) into (IF ROUND(Source1) <= 90 THEN
range -90 to +90.
InclinationAccuracy (Target1:=ROUND(Source1)
For FFI InclinationAccuracy, division by 2
Source1: …/positionalData/inclination IF Source2 contains data THEN
and round value.
Source2: …/positionalData/inclination/@accuracy
FFI InclinationAccuracy will only be (Target2:=ROUND(Source2 / 2))
produced in combination with a valid )
Inclination.
ELSE IF ROUND(Source1) >= 270
Notes: THEN
16) NFFI inclination data type allows real (Target1:=ROUND(Source1) - 360
numbers and values from 0 to 360.
Values from 91 to 269 are IF Source2 contains data THEN
meaningless. (Target2:=ROUND(Source2 / 2))
17) NFFI inclination values 0 and 360 are )
technically identical and translated to
OTHERWISE
value 0 in FFI.
18) NFFI accuracy uses real numbers
between 0 and 360, FFI uses Do not generate Target2
integers between 0 and 180 )
19) NFFI accuracy describes the sector )
of uncertainty with the given
inclination in the centre of the OTHERWISE
uncertainty sector, while FFI uses the (Do not generate Target1
given angle at each side of the
inclination to describe the uncertainty Do not generate Target2
sector. )

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
TRACK PLANNED LOCATION
11 0 Target1: …/TrackInformation/TrackPlannedLocation and all sub- No equivalent NFFI element. Do not generate Target1 X
elements
TRACK IDENTIFICATION DATA
12 0 Target1: …/OperationCodeword Generate element, if any of the sub- Generate Target1, if any of its
12 1 Target1: …/TrackInformation/TrackIdentificationData/UnitSymbol Copy from NFFI IF Source1 contains data THEN
Target2: …/TrackInformation/TrackIdentificationData/ (Target1:=Source1
Notes:
SymbolStandard
20) NFFI standard is APP-6(A) as Target2:=”APP-6(A)”
Source1: …/identificationData/unitSymbol symbol standard )
OTHERWISE
)
12 2 Target1: …/TrackInformation/TrackIdentificationData/ Copy from NFFI, but consider prohibited IF Source1 contains data THEN
UnitShortName characters in FFI (Step1:=REPLACE(Source2,”:”,””)
Source1: …/identificationData/unitSymbol Step2:=REPLACE(Step1,”*”,””)
Notes:
Source2: …/identificationData/unitShortName 21) Characters “a”-“z”, “*” and “:” cannot Target1:=REPLACE(Step2,”[a-z]”,”[A-
be used in FFI Z]”)
OTHERWISE
12 3 Target1: …/TrackInformation/TrackIdentificationData/ No equivalent NFFI element. Do not generate Target1 through Target9 X
GroupOfFields/OtherId/UnitIdentificationCodeUic
Target2: …/TrackInformation/TrackIdentificationData/

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
GroupOfFields/OtherId/UnitReferenceNumberVmf
GroupOfFields/OtherId/DataLinkTrackNumber
OPERATIONAL STATUS
13 0 Target1: …/TrackInformation/OperationalStatus Generate element, if any of the sub- Generate Target1, if any of its X
13 1 Target1: …/TrackInformation/OperationalStatus/Alert Simple translation IF Source1 = true OR Source1 = 1 THEN X
Source1: …/deviceSpecificData/alert (Target1:= “YES”)
Source2: …/operStatusData/footprint ELSE IF Source1 does not contain data
AND
Source3: …/operStatusData/strength
(Source2 contains data OR
Source4: …/operStatusData/statusCode Source3 contains data OR
Source4 contains data) THEN
(Target1:= “NO”)
OTHERWISE
13 2 Target1: …/TrackInformation/OperationalStatus/Footprint Simple translation Step1:=ROUND(Source1)
Source1: …/operStatusData/footprint IF Step1>0 AND Step1<= 99999 THEN
Notes:
22) NFFI data type allows real numbers (Target1:=Step1)
and values from 0 to unlimited ELSE IF Step1>99999 THEN
FFI allows integers only between 1 and (Target1:=99999)
99999
OTHERWISE

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
13 3 Target1: …/TrackInformation/OperationalStatus/Strength Simple translation IF Source1>0 AND Source1<= 9999
Source1: …/operStatusData/strength THEN
Notes:
(Target1:= Source1)
23) NFFI strength data type allows 0 to
65535 ELSE IF Source1>9999 THEN
24) FFI Strength data type only numbers (Target1:=9999)
between 1 and 9999 OTHERWISE
13 4 Target1: …/TrackInformation/OperationalStatus/PersonnelStrength No equivalent NFFI element. Do not generate Target1 X
13 5 Target1: …/TrackInformation/OperationalStatus/Status Simple translation, with exception of two IF Source1=”OPERATIONAL” THEN
Source1: …/operStatusData/statusCode NFFI codes (Target1=1)
Notes: ELSE IF Source1=”SUBSTANTIALLY
25) Less detail due to merging values OPERATIONAL” THEN
into one code and dropping explicit (Target1=2)
value “NOT KNOWN”
ELSE IF Source1=”MARGINALLY
OPERATIONAL” THEN
(Target1=3)
ELSE IF Source1=”TEMPORARILY NOT
OPERATIONAL” or Source1=“NOT
OPERATIONAL” THEN
(Target1=4)
OTHERWISE
NATURE OF EMERGENCY
14 0 Target1: …/TrackInformation/NatureOfEmergency and all sub- No equivalent NFFI element Do not generate Target1 X
elements

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
DETAIL DATA
15 0 Target1: …/TrackInformation/DetailData Generate element, if any of the sub- Generate Target1, if any of its
15 1 Target1: …/TrackInformation/DetailData/TextIndicator Fixed value "DETAIL DATA" for FFI IF { any of the iterations of Source1
TextIndicator, if set is used. Concatenate contains legal characters for Target2 }
Target2: …/TrackInformation/DetailData/FreeText
non-empty NFFI remarks iterations and THEN
Source1: …/deviceSpecificData/remarks replace prohibited characters and include (Target2:= { Concatenate non-empty
in FFI FreeText.
iterations of Source1 and separate by a
line break character. Replace prohibited
Notes:
characters by a legal replacement
26) Remarks in NFFI can be empty.
character. If a colon is the last character,
27) FFI FreeText SHALL NOT be empty. add a space character after the colon. }
28) The use of double slant character “//” Target1:=“DETAIL DATA”
is not allowed and the use of a colon
)
“:’ is not allowed as the final
character. The combination of “://” is OTHERWISE
allowed. (Do not generate Target1
29) ADatP-3(A) limits permitted Do not generate Target2
characters for the FreeText element.
)
30) NFFI remarks can have up to 4
iterations
OTHER SETS
16 1 Target1: …/[different]/Amplification Not to be used Do not generate Target1 X

16 2 Target1: …/[different]/Narrative Not to be used Do not generate Target1 X
16 3 Target1: …/Remarks Not to be used Do not generate Target1 X
BACKWARD COMPATIBILITY MAPPING FROM FFI MTF TO NFFI

This mapping assumes, that the source message is a valid FFI MTF message instance, following the rules of this document.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36
BR-Mapping-6. If at least one of the blue dot fields of a track in a FFI MTF message are invalid according to the rules in this standard, the track SHALL
be dropped by the FFI MTF to NFFI Proxy.
The target message has to be created according to the business rules of the Interim NFFI Standard for Interoperability of FTS [Ref 11].
BR-Mapping-7. If a track resulting from the mapping rules contains at least one blue dot field that is invalid according to the NFFI D-document [Ref 11],
the track SHALL be dropped from the message and not forwarded.
Table 15 provides information on which FFI MTF source data element value is mapped to which NFFI target data element, and explains specific limitations.
BR-Mapping-8. An FFI MTF to NFFI Proxy SHALL implement all lines as shown in the Table 15 if marked as Required for Minimum Implementation
(column D).
BR-Mapping-9. An FFI MTF to NFFI Proxy MAY implement lines as shown in Table 15 not marked as Required for Minimum Implementation (column
D).
Individual lines of Table 15 can be referred to as BR-Mapping FFI to NFFI-X-Y, where X and Y are the numbers in the first two columns.
Table 15 FFI MTF to NFFI Mapping

Target: NFFI 1.3.1 elements (/NFFIMessage/track/…) Mapping details/ pseudo algorithm Minimum
Source: FFI MTF elements (/mtf:FriendlyForceInformation/…) Implementation
X Y A B C D
FFI FIELDS THAT CANNOT BE FORWARDED TO NFFI
0 1 Source1: …/ExerciseIdentification element and all sub- No equivalent NFFI element Drop Source1 information X
elements
0 2 Source1: …/OperationCodeword element and all sub-elements No equivalent NFFI element Drop Source1 information X
0 3 Source1: …/MessageIdentifier/Originator No equivalent NFFI element Drop Source1 information X

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
0 4 Source1: …/MessageIdentifier/MessageSerialNumber No equivalent NFFI element Drop Source1 information X
0 5 Source1: …/MessageIdentifier/ReferenceTimeOfPublication/ No equivalent NFFI element Drop Source1 information X
MonthNameAbbreviated
0 6 Source1: …/MessageIdentifier/ReferenceTimeOfPublication/ No equivalent NFFI element Drop Source1 information X
DateTimeIso
0 7 Source1: …/MessageIdentifier/Qualifier No equivalent NFFI element Drop Source1 information X
0 8 Source1: …/MessageIdentifier/SerialNumberOfQualifier No equivalent NFFI element Drop Source1 information X
0 9 Source1: …/MessageIdentifier/MessageSecurityPolicy No equivalent NFFI element Drop Source1 information X
0 10 Source1: …/MessageIdentifier/MessageClassification/ No equivalent NFFI element Drop Source1 information X
0 11 Source1: …/MessageIdentifier/MessageClassification/ No equivalent NFFI element Drop Source1 information X
0 12 Source1: …/MessageIdentifier/MessageSecurityCategory No equivalent NFFI element Drop Source1 information X
0 13 Source1: …/Reference element and all sub-elements No equivalent NFFI element Drop Source1 information X
0 14 Source1: …/TrackInformation/TrackPlannedLocation element No equivalent NFFI element Drop Source1 information X
and all sub-elements
0 15 Source1: …/TrackInformation/TrackIdentificationData/ No equivalent NFFI element Drop Source1 information X
GroupOfFields/OtherId/UnitIdentificationCodeUic
GroupOfFields/OtherId/UnitReferenceNumberVmf

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
GroupOfFields/OtherId/DataLinkTrackNumber
0 24 Source1: …/TrackInformation/OperationalStatus/ No equivalent NFFI element Drop Source1 information X
PersonnelStrength
0 25 Source1: …/TrackInformation/NatureOfEmergency/ Only fixed label for slant delimited Drop Source1 information X
TextIndicator representation
0 26 Source1: …/TrackInformation/DetailData/TextIndicator Only fixed label for slant delimited Drop Source1 information X
representation
0 27 Source1: …/[different]/Amplification No equivalent NFFI element Drop Source1 information X
0 28 Source1: …/[different]/Narrative No equivalent NFFI element Drop Source1 information X
0 29 Source1: …/Remarks No equivalent NFFI element Drop Source1 information X
MANDATORY CONDITIONS TO VERIFY MAPPING APPLICABILITY OF SOURCE FORMAT
1 1 Source1: …/MessageIdentifier/MessageTextFormatIdentifier This mapping only applies, if FFI IF Source1 <> “FFI” THEN X
MessageTextFormatIdentifier = FFI,
( { Drop message } )
otherwise stop processing.
1 2 Source1: …/MessageIdentifier/Standard This mapping only applies, if FFI Standard IF Source1 <> “APP-11(D)” THEN X
= APP-11(D), otherwise stop processing. ( { Drop message } )
1 3 Source1: …/MessageIdentifier/Version This mapping only applies, if FFI Version IF Source1 <> “1” THEN X
= 1, otherwise stop processing.
1 4 Source1: …/GeodeticDatum/GeodeticDatum This mapping only applies, if FFI IF Source1 <> “WGE” THEN X
GeodeticDatum = WGE, otherwise stop
processing.
1 5 Source1: …/GeodeticDatum/NationalGridSystemCoordinates This mapping only applies, if FFI IF Source1 contains data THEN X
NationalGridSystemCoordinates is empty,
otherwise stop processing.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
TRACK ROOT ELEMENT
2 0 Target1: /NFFIMessage/track For each FFI TrackInformation generate Generate Target1

an NFFI track.
Source1: …/TrackInformation
positionalData SECTION
3 0 Target1: …/positionalData Generate element Generate Target1 X

3 1 Target1: …/positionalData/@secPolicyName For the policy use FFI IF Source4 contains data AND
Target2: …/positionalData/@secClassification TrackSecurityPolicy. Source4 is valid for Target2 AND
{ no element from Source8 is used in the
Target3: …/positionalData/@secCategory For the classification use FFI
BlueDotSecurityClassification, if available track } THEN
Source1: …/TrackInformation/TrackSecurityLabel/ and no FFI TrackMovementData element (Target1:=Source1
TrackSecurityPolicy is used, otherwise use FFI
Target2:=Source4
Source2: …/TrackInformation/TrackSecurityLabel/ TrackSecurityClassification.
TrackSecurityClassification/ IF Source7 contains data THEN
For the category use the SecurityCategory
SecurityClassificationExtended that is related to the classification element (Target3:=Source7)
Source3: …/TrackInformation/TrackSecurityLabel/ used above, i.e. either FFI )
TrackSecurityClassification/SecurityClassification BlueDotSecurityCategory or FFI
TrackSecurityCategory. ELSE IF Source5 contains data AND
Source4: …/TrackInformation/TrackSecurityLabel/ Source5 is valid for Target2 AND
BlueDotSecurityClassification/ Notes: { no element from Source8 is used in the
SecurityClassificationExtended 31) Whether security attributes are used track } THEN
Source5: …/TrackInformation/TrackSecurityLabel/ in the NFFI network is an operational (Target1:=Source1
BlueDotSecurityClassification/SecurityClassification decision. Security labels are not
mandatory in NFFI, but will be Target2:=Source5
Source6: …/TrackInformation/TrackSecurityLabel/ included in any FFI message. If IF Source7 contains data THEN
TrackSecurityCategory implemented at all, the forwarding of
(Target3:=Source7)
Source7: …/TrackInformation/TrackSecurityLabel/ labels SHOULD be configurable.
BlueDotSecurityCategory )
If the available classification marking is
Source8: …/TrackInformation/TrackMovementData longer than 30 characters, drop all ELSE IF Source2 contains data AND
three security related attributes, Source2 is valid for Target2 THEN
because a modification of the value (Target1:=Source1
by truncation is not acceptable.
Target2:=Source2
IF Source6 contains data THEN
(Target3:=Source6)

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
)
Source3 is valid for Target2 THEN
(Target1:=Source1
Target2:=Source3
(Target3:=Source6)
)
3 2 Target1: …/positionalData/trackSource/sourceSystem/country Use the available FFI alternative. IF Source1 contains data THEN
Source1: …/TrackInformation/TrackSource/Nationality/ (IF Source1 = “XXE” THEN
Notes:
GeographicalEntity (Target1:=“XXN”)
32) The code used to express NATO is
Source2: …/TrackInformation/TrackSource/Nationality/ different in the two standards. OTHERWISE
NonStandardGeographicalEntity
(Target1:=Source1)
ELSE IF Source2 contains data THEN
(Target1:=Source2)
OTHERWISE
3 3 Target1: …/positionalData/trackSource/sourceSystem/system Use FFI System, if it is a legal NFFI IF Source1 is valid for Target1 THEN X
Source1: …/TrackInformation/TrackSource/System system value. Otherwise the whole track (Target1:=Source1)
SHALL be dropped.
OTHERWISE
Notes: ( { Drop whole track } )
33) No modification of value allowed!
3 4 Target1: …/positionalData/trackSource/sourceSystem/ Use FFI Subsystem, if it is a legal NFFI IF Source1 is valid for Target1 THEN X
subsystem subsystem value. Otherwise the whole (Target1:=Source1)
Source1: …/TrackInformation/TrackSource/Subsystem track SHALL be dropped.
OTHERWISE
Notes: ( { Drop whole track } )
3 5 Target1: …/positionalData/trackSource/transponderId Use FFI TransponderId, if it is a legal NFFI IF Source1 is valid for Target1 THEN X
Source1: …/TrackInformation/TrackSource/TransponderId transponderId value. Otherwise the whole (Target1:=Source1)
track SHALL be dropped.
OTHERWISE

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
( { Drop whole track } )
Notes:
3 6 Target1: …/positionalData/dateTime Transform FFI Time to the NFFI dateTime Target1:=CONCAT( X
Source1: …/TrackInformation/TrackPositionalData/Time structure. FORMAT(Source1/Year,0000),
FORMAT(Source1/Month,00),
FORMAT(Source1/Day,00),
FORMAT(Source1/Hour,00),
FORMAT(Source1/Minute,00),
FORMAT(Source1/Second,00))
3 7 Target1: …/positionalData/coordinates/latitude Transform FFI Location to NFFI latitude IF Source1/LatitudinalHemisphere = “N” THEN X
structure.
Source1: …/TrackInformation/TrackPositionalData/Location (Target1:=ROUND(Source1/LatitudeDegrees
+ (Source1/LatitudeMinutes04DecimalPlaces /
Notes:
60) * 100000) / 100000
36) In order to limit the size of the
resulting number, it is rounded to 5 )
decimal places, which ensures no OTHERWISE
significant loss of precision from the
Source format. (Target1:= -1 * ROUND(Source1/
LatitudeDegrees + (Source1/
LatitudeMinutes04DecimalPlaces / 60) *
100000) / 100000
)
3 8 Target1: …/positionalData/coordinates/longitude Transform FFI Location to NFFI longitude IF Source1/LongitudinalHemisphere = “E” X
structure. THEN
Source1: …/TrackInformation/TrackPositionalData/Location
(Target1:=ROUND(Source1/
Notes:
LongitudeDegrees + (Source1/
37) In order to limit the size of the
LongitudeMinutes04DecimalPlaces / 60) *
resulting number, it is rounded to 5
100000) / 100000
decimal places, which ensures no
loss of precision from the Source )
format. OTHERWISE
(Target1:= -1 * ROUND(Source1/
LongitudeDegrees + (Source1/
LongitudeMinutes04DecimalPlaces / 60) *
100000) / 100000
)

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
3 9 Target1: …/positionalData/coordinates/latitude/@accuracy Use FFI HorizontalAccuracy for both NFFI IF Source1 contains data THEN
Target2: …/positionalData/coordinates/longitude/@accuracy accuracy attributes. (Target1:=Source1
Source1: …/TrackInformation/TrackPositionalData/ Target2:=Source1
HorizontalAccuracy )
OTHERWISE
)
3 10 Target1: …/positionalData/coordinates/altitude Use FFI Altitude. IF Source1 contains data THEN
Source1: …/TrackInformation/TrackPositionalData/Altitude (Target1:=Source1)
OTHERWISE
3 11 Target1: …/positionalData/coordinates/altitude/@accuracy Use FFI VerticalAccuracy, if FFI Altitude is IF Source1 contains data AND
Source1: …/TrackInformation/TrackPositionalData/Altitude also used. Source2 contains data THEN
Source2: …/TrackInformation/TrackPositionalData/ (Target1:=Source2)

VerticalAccuracy OTHERWISE
3 12 Target1: …/positionalData/bearing Use FFI Bearing. IF Source1 contains data THEN
Source1: …/TrackInformation/TrackMovementData/Bearing (Target1:=Source1)
OTHERWISE
3 13 Target1: …/positionalData/bearing/@accuracy Use FFI BearingAccuracy multiplied by 2, IF Source1 contains data AND
Source1: …/TrackInformation/TrackMovementData/Bearing if FFI Bearing is also used. Source2 contains data THEN
Source2: …/TrackInformation/TrackMovementData/ (Target1:=Source2 * 2)

Notes:
BearingAccuracy 38) NFFI uses real numbers between 0 OTHERWISE
and 360, FFI uses integers between (Do not generate Target1)
0 and 180.
NFFI describes the sector of uncertainty
with the given bearing in the centre of
the uncertainty sector, while FFI uses
the given angle at each side of the

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
bearing to describe the uncertainty
sector.
3 14 Target1: …/positionalData/speed Use FFI Speed converted to km per hour. IF Source1 contains data THEN
Source1: …/TrackInformation/TrackMovementData/Speed (IF Source1/
Notes:
Const1: 1.852 UnitOfSpeedVelocityMeasurement = “KPH”
39) Conversion rates:
THEN
Const2: 1.60934 from Knots (KTS) to KPH: 1.852
(Const1) (Target1:=Source1/
Const3: 3.6 from Miles per hour (MPH) to KPH: ContextQuantity000999)
1.60934 (Const2) ELSE IF Source1/
from Metres per second (MPS) to UnitOfSpeedVelocityMeasurement = “KTS”
KPH: 3.6 (Const3) THEN
ContextQuantity000999 * Const1))
ELSE IF Source1/
UnitOfSpeedVelocityMeasurement = “MPH”
THEN
ELSE IF Source1/
UnitOfSpeedVelocityMeasurement = “MPS”
THEN
)
OTHERWISE
3 15 Target1: …/positionalData/speed/@accuracy Use FFI SpeedAccuracy converted to km IF Source1 contains data AND
Source1: …/TrackInformation/TrackMovementData/Speed per hour, if FFI Speed is also used. Source2 contains data THEN
Source2: …/TrackInformation/TrackMovementData/ (IF Source2/

Notes:
UnitOfSpeedVelocityMeasurement = “KPH”
SpeedAccuracy 40) Same conversion rates as for speed
THEN
Const1: 1.852 are used.
(Target1:=Source2/
Const2: 1.60934 ContextQuantity000999)
Const3: 3.6

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
ELSE IF Source2/
UnitOfSpeedVelocityMeasurement = “KTS”
THEN
ELSE IF Source2/
UnitOfSpeedVelocityMeasurement = “MPH”
THEN
ELSE IF Source2/
UnitOfSpeedVelocityMeasurement = “MPS”
THEN
)
OTHERWISE
3 16 Target1: …/positionalData/reliability Simple translation IF Source1 = “A” THEN
Source1: …/TrackInformation/TrackSource/Reliability (Target1:=“COMPLETELY RELIABLE”)
ELSE IF Source1 = “B” THEN
(Target1:=“USUALLY RELIABLE”)
ELSE IF Source1 = “C” THEN
(Target1:=“FAIRLY RELIABLE”)
ELSE IF Source1 = “D” THEN
(Target1:=“NOT USUALLY RELIABLE”)
ELSE IF Source1 = “E” THEN
(Target1:=“UNRELIABLE”)
ELSE IF Source1 = “F” THEN
(Target1:=“RELIABILITY CANNOT BE
JUDGED”)
OTHERWISE

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
3 17 Target1: …/positionalData/credibility Simple translation IF Source1 = “1” THEN
Source1: …/TrackInformation/TrackSource/Credibility (Target1:=“CONFIRMED BY OTHER
SOURCES”)
ELSE IF Source1 = “2” THEN
(Target1:=“PROBABLY TRUE”)
(Target1:=“POSSIBLY TRUE”)
(Target1:=“DOUBTFULLY TRUE”)
(Target1:=“IMPROBABLE”)
(Target1:=“TRUTH CANNOT BE JUDGED”)
OTHERWISE
3 18 Target1: …/positionalData/inclination Use FFI Inclination with transformation. IF Source1 >= 0 THEN
Source1: …/TrackInformation/TrackMovementData/Inclination (Target1:=Source1)
Notes:
41) NFFI uses 0-359, FFI uses -90 to 90. ELSE IF Source1 < 0 THEN
Map values from -90 to -1 into range (Target1:=Source1 + 360)
270 to 359 and positive values are
copied. OTHERWISE
3 19 Target1: …/positionalData/inclination/@accuracy Use FFI InclinationAccuracy multiplied by IF Source1 contains data AND
2, if FFI Inclination is also used. Source2 contains data THEN
Source1: …/TrackInformation/TrackMovementData/Inclination
(Target1:=Source2 * 2)
Source2: …/TrackInformation/TrackMovementData/ Notes:
InclinationAccuracy 42) NFFI uses real numbers between 0 OTHERWISE
and 360, FFI uses integers between (Do not generate Target1)
0 and 180.
43) NFFI describes the sector of
uncertainty with the given inclination
in the centre of the uncertainty

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
sector, while FFI uses the given
angle at each side of the inclination
to describe the uncertainty sector.
identificationData SECTION
4 0 Target1: …/identificationData Generate element, if any of the sub- Generate Target1, if any of its subelements is
elements are used. generated
4 1 Target1: …/identificationData/@secPolicyName Only generate these attributes, if any of IF Source4 contains data AND
the other elements of this section is Source4 is valid for Target2 THEN
Target2: …/identificationData/@secClassification
generated. (Target1:=Source1
Target3: …/identificationData/@secCategory
For the policy use FFI Target2:=Source4
Source1: …/TrackInformation/TrackSecurityLabel/ TrackSecurityPolicy.
TrackSecurityPolicy IF Source7 contains data THEN
For the classification use FFI
Source2: …/TrackInformation/TrackSecurityLabel/ DetailsSecurityClassification, if available, (Target3:=Source7)
TrackSecurityClassification/ otherwise use FFI )
SecurityClassificationExtended TrackSecurityClassification.
Source3: …/TrackInformation/TrackSecurityLabel/ For the category use the SecurityCategory Source5 is valid for Target2 THEN
TrackSecurityClassification/SecurityClassification that is related to the above selected
classification element (i.e. Track Security (Target1:=Source1
Source4: …/TrackInformation/TrackSecurityLabel/
DetailsSecurityClassification/ or Track Details Security). Target2:=Source5
SecurityClassificationExtended IF Source7 contains data THEN
Notes:
Source5: …/TrackInformation/TrackSecurityLabel/ 44) Whether security attributes are used (Target3:=Source7)
DetailsSecurityClassification/SecurityClassification in the NFFI network is an operational
)
Source6: …/TrackInformation/TrackSecurityLabel/ decision. Security labels are not
TrackSecurityCategory mandatory in NFFI, but will be ELSE IF Source2 contains data AND
included in any FFI message. If Source2 is valid for Target2 THEN
Source7: …/TrackInformation/TrackSecurityLabel/ implemented at all, the forwarding of
DetailsSecurityCategory (Target1:=Source1
labels SHOULD be configurable.
Target2:=Source2
If the available classification marking is
longer than 30 characters, drop all IF Source6 contains data THEN
three security related attributes, (Target3:=Source6)
because a modification of the value
by truncation is not acceptable. )
NFFI @secClassification only allows 30 ELSE IF Source3 contains data AND

characters, while FFI Source3 is valid for Target2 THEN
SecurityClassification allows 50 (Target1:=Source1
characters. If the selected value is

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
longer than 30 characters, the whole Target2:=Source3
set of security attributes SHALL be
dropped.
(Target3:=Source6)
)
4 2 Target1: …/identificationData NFFI does not cover other than APP-6(A) IF Source3 contains data THEN X
symbols. FFI can explicitly express other
Target2: …/identificationData/unitSymbol (IF Source1 contains data AND
standards. As the Symbol ID code MAY (Source2 does not contain data OR
Target3: …/identificationData/unitShortName contain indication about an identity other Source2 = “APP-6(A)”) THEN
Source1: …/TrackInformation/TrackIdentificationData/ than friendly (e.g. civil convoys), that
UnitSymbol mandates the use of a Unit Symbol in (Target2:=Source1)
those cases. ELSE IF Source1 does not contain data
Source2: …/TrackInformation/TrackIdentificationData/
For the NFFI unitShortName use FFI THEN
SymbolStandard
UnitShortName, but remove prohibited (Target2:=Const1)
Source3: …/TrackInformation/TrackIdentificationData/ characters in NFFI and truncate to
UnitShortName maximum allowed length. OTHERWISE
Const1: “SFGP-----------” In NFFI, unitSymbol and unitShortName (Target2:=Const2)
Const2: “SUGP-----------” can only be transmitted together. Target3:=SUBSTR(
If only one of FFI UnitShortName or REPLACE(Source3, “ ()?”, “”),
UnitSymbol is missing, a default value will 1,15)
be added for the other element. )
If both - Unit Symbol and Unit Short Name ELSE IF Source1 does contain data THEN
- are missing in the source message, the
identificationData element will not be (IF Source2 does not contain data OR
generated. Source2 = “APP-6(A)” THEN
(Target2:=Source1
Notes:
Target3:={ Based on
45) If the Proxy does not recognize the
SUBSTR(Source1,2,1) select the default name,
used symbol standard a default
usually FRIEND or NEUTRAL11 }
translation to an unknown identity in
the APP-6(A) will be used, instead of )
dropping the track. This step includes OTHERWISE
a small risk of losing identity details,
11
NFFI unitShortName = Translation of 2nd character in Symbol-ID with APP-6(A) [Ref 16], Table B-I values (uppercase only and space characters removed to comply with
NFFI and FFI syntax): P: PENDING; U: UNKNOWN; A: ASSUMEDFRIEND; F: FRIEND; N: NEUTRAL; S: SUSPECT; H: HOSTILE; J: JOKER; K: FAKER; O:
NONESPECIFIED; Any other character: UNKNOWN.
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
but will not accidently cause a track (Target2:=Const2;
to turn to a friendly track due to
Target3:=“UNKNOWN”
misinterpretation of the unitSymbol in
the NFFI receiving system and at the )
same time not unnecessarily drop )
tracks from the FFI MTF based FFT
network. OTHERWISE
46) In Source2, the absence of data will (Do not generate Target1)
be interpreted as being an APP-6(A)
symbol in Source1.
47) If unitShortName is available without
unitSymbol, the default “SFGP---------
--” will be used.
48) If the UnitShortName is missing, but
a UnitSymbol is available, a default
value will be generated based on the
identity provided within the Symbol
ID code.
49) NFFI UnitShortName allows only 15
characters and characters " ", "(", ")",
"?" are not allowed.
operStatusData SECTION
5 0 Target1: …/operStatusData Generate element, if any of the sub- Generate Target1, if any of its subelements is
5 1 Target1: …/operStatusData/@secPolicyName Only generate these attributes, if any of IF Source4 contains data AND
Target2: …/operStatusData/@secClassification the other elements of this section is Source4 is valid for Target2 THEN
generated.
Target3: …/operStatusData/@secCategory (Target1:=Source1
For the policy use FFI
Source1: …/TrackInformation/TrackSecurityLabel/ Target2:=Source4
TrackSecurityPolicy.
(Target1:=Source1

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
Source4: …/TrackInformation/TrackSecurityLabel/ classification element (i.e. Track Security Target2:=Source5
DetailsSecurityClassification/ or Track Details Security).
Notes: (Target3:=Source7)
50) Whether security attributes are used )
DetailsSecurityClassification/SecurityClassification
in the NFFI network is an operational
Source6: …/TrackInformation/TrackSecurityLabel/ decision. Security labels are not ELSE IF Source2 contains data AND
TrackSecurityCategory mandatory in NFFI, but will be Source2 is valid for Target2 THEN
Source7: …/TrackInformation/TrackSecurityLabel/ included in any FFI message. If (Target1:=Source1
DetailsSecurityCategory implemented at all, the forwarding of
labels SHOULD be configurable. Target2:=Source2
If the available classification marking is IF Source6 contains data THEN

longer than 30 characters, drop all (Target3:=Source6)
three security related attributes,
)
by truncation is not acceptable. ELSE IF Source3 contains data AND
Source3 is valid for Target2 THEN
NFFI @secClassification only allows 30
characters, while FFI (Target1:=Source1
SecurityClassification allows 50 Target2:=Source3
characters. If the selected value is
longer than 30 characters, the whole IF Source6 contains data THEN
set of security attributes SHALL be (Target3:=Source6)
dropped.
)
5 2 Target1: …/operStatusData/footprint Use FFI Footprint IF Source1 contains data THEN
Source1: …/TrackInformation/OperationalStatus/Footprint (Target1:=Source1)
OTHERWISE
5 3 Target1: …/operStatusData/strength Use FFI Strength IF Source1 contains data THEN
Source1: …/TrackInformation/OperationalStatus/Strength (Target1:=Source1)
OTHERWISE
5 4 Target1: …/operStatusData/statusCode Simple translation, with exception of two IF Source1 = “1” THEN
Source1: …/TrackInformation/OperationalStatus/Status NFFI codes. (Target1:= “OPERATIONAL”)
Notes: ELSE IF Source1 = “2” THEN

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
NFFI values TEMPORARILY NOT (Target1:= “SUBSTANTIALLY
OPERATIONAL and NOT KNOWN are OPERATIONAL”)
not available in FFI and thus will never be ELSE IF Source1 = “3” THEN
produced.
(Target1:= “MARGINALLY OPERATIONAL”)
(Target1:= “NOT OPERATIONAL”)
OTHERWISE
deviceSpecificData SECTION
6 0 Target1: …/deviceSpecificData Generate element, if any of the sub- Generate Target1, if any of its subelements is
6 1 Target1: …/operStatusData/@secPolicyName Only generate these attributes, if any of IF Source4 contains data AND
Target2: …/operStatusData/@secClassification the other elements of this section is Source4 is valid for Target2 THEN
generated.
Target3: …/operStatusData/@secCategory (Target1:=Source1
For the policy use FFI
Source1: …/TrackInformation/TrackSecurityLabel/ Target2:=Source4
TrackSecurityPolicy.
classification element (i.e. Track Security (Target1:=Source1
DetailsSecurityClassification/ or Track Details Security). Target2:=Source5
SecurityClassificationExtended IF Source7 contains data THEN
Notes:
Source5: …/TrackInformation/TrackSecurityLabel/ 51) Whether security attributes are used (Target3:=Source7)
DetailsSecurityClassification/SecurityClassification in the NFFI network is an operational
)
Source6: …/TrackInformation/TrackSecurityLabel/ decision. Security labels are not
TrackSecurityCategory mandatory in NFFI, but will be ELSE IF Source2 contains data AND
included in any FFI message. If Source2 is valid for Target2 THEN
Source7: …/TrackInformation/TrackSecurityLabel/ implemented at all, the forwarding of
DetailsSecurityCategory (Target1:=Source1
labels SHOULD be configurable.
Target2:=Source2
52) If the available classification marking
is longer than 30 characters, drop all IF Source6 contains data THEN

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
three security related attributes, (Target3:=Source6)
)
by truncation is not acceptable.
53) NFFI @secClassification only allows Source3 is valid for Target2 THEN
30 characters, while FFI
SecurityClassification allows 50 (Target1:=Source1
characters. If the selected value is Target2:=Source3
longer than 30 characters, the whole
set of security attributes SHALL be IF Source6 contains data THEN
dropped. (Target3:=Source6)
)
6 2 Target1: …/deviceSpecificData/alert Simple translation IF Source1 = “YES” THEN X
Source1: …/TrackInformation/OperationalStatus/Alert (Target1:=true)
OTHERWISE
6 3 Target1: …/deviceSpecificData/remarks Generate NFFI remarks, if FFI IF Source1 = “YES” AND
Source1: …/TrackInformation/OperationalStatus/Alert NatureOfEmergency is used and FFI Alert Source2 contains data THEN
is YES.
Source2: …/TrackInformation/NatureOfEmergency/FreeText (Temp1:=REPLACE(Source2, “ ”, “-”)
More NFFI remarks are used to represent
Source3: …/TrackInformation/DetailData/FreeText Target1[1]:=SUBSTR(Temp1,1,60)
the content of FFI DetailData, which has to
be split into individual pieces of up to 60 IF Source3 contains data THEN
characters. The remaining text has to be (Temp2:=REPLACE(Source3, “ ”, “-”)
dropped.
Target1[2]:=SUBSTR(Temp2,1,60)
If the FFI FreeText contains space
characters, they will be replaced by IF LENGTH(Temp2)) > 60 THEN
dashes (“-“). (Target1[3]:=SUBSTR(Temp2,61,60))
Notes: IF LENGTH(Temp2)) > 120 THEN

54) FFI Freetext has unlimited length; (Target1[4]:=SUBSTR(Temp2,121,60))
NFFI remarks limits to 60 characters,
)
but has up to four remarks.
)
NFFI allows [A-Z], [a-z], [0-9], period,
comma, colon, asterisk, and dash. ELSE IF Source3 contains data THEN
Space characters are not allowed in (Temp1:=REPLACE(Source3, “ ”, “-”)
NFFI and have to be replaced with a
“-” as replacement character. Target1[1]:=SUBSTR(Temp1,1,60)
IF LENGTH(Temp1)) > 60 THEN

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36

X Y A B C D
(Target1[2]:=SUBSTR(Temp1,61,60))
)
6 4 Target1: …/deviceSpecificData/additionalId No equivalent FFI element Do not generate NFFI Target1 X
6 5 Target1: …/deviceSpecificData/phoneNumber No equivalent FFI element Do not generate NFFI Target1 X
6 6 Target1: …/deviceSpecificData/serialNumber No equivalent FFI element Do not generate NFFI Target1 X
6 7 Target1: …/deviceSpecificData/terminalType No equivalent FFI element Do not generate NFFI Target1 X
6 8 Target1: …/deviceSpecificData/terminalId No equivalent FFI element Do not generate NFFI Target1 X
6 9 Target1: …/deviceSpecificData/specialUserDefined No equivalent FFI element Do not generate NFFI Target1 X
detailData SECTION
7 1 Target1: …/detailData No equivalent FFI element Do not generate NFFI Target1 X
LINK 16 MAPPING
For mapping of FFI MTF to Link 16, refer to ADatP-37, NATO Standard “Services to Forward Friendly Force Information to Weapon Delivery Assets”.

NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX G to ADatP-36
INTENTIONALLY BLANK

NATO UNCLASSIFIED
NATO UNCLASSIFIED
Releasable to IP
ANNEX H to ADatP-36
– TECHNICAL SPECIFICATION – WEB SERVICES - WSMP

FFT PROFILE
INTRODUCTION
This annex contains a WSMP profile for the Friendly Force Tracking (FFT) Community of
Interest (CoI) to exchange ADatP-36(A) messages; it is an application of the STANAG 5644
specification [Ref 22] for the exchange of FFI MTF messages.
This profile provides a specification for the exchange of FFT tracks in the NFFI 1.3 or FFI -MTF
format, using the WSMP protocol. The ADatP-36 or NFFI 1.3 messages containing the tracks
will be generically referenced in this document as “FFT messages”.
AUDIENCE
The target audience for this profile is the community of software developers who are:
 Implementers of ADatP-36(A)(2) WSMP-based service provider.

 Implementers of ADatP-36(A)(2) WSMP-based client applications.
NAMESPACES
Below are the namespaces that are used in this profile.
Abbreviation Namespace
cm urn:nato:stanag:4774:confidentialitymetadatalabel:1:0
dc http://purl.org/dc/elements/1.1/
dcterms http://purl.org/dc/terms/
fft-q urn:nato:fft:filter:1:0
mb urn:nato:stanag:4778:bindinginformation:1:0
mtf urn:nato:mtf:app-11(d):1:ffi
ncms urn:nato:stanag:5636:A:1:elements
nffi urn:nato:fft:protocols:nffi13
nffi-q urn:nato:fft:protocols:nffi13:query
sip3-f urn:nato:fft:protocols:sip3
soap12 http://www.w3.org/2003/05/soap-envelope
soapenc http://www.w3.org/2003/05/soap-encoding
wsa http://www.w3.org/2005/08/addressing
H-1
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
Releasable to IP
ANNEX H to ADatP-36
wsaw http://www.w3.org/2006/02/addressing/wsdl
wsdl http://schemas.xmlsoap.org/wsdl/
wsmp urn:nato:stanag:5644:wsmp:1:3
wsmp-f urn:nato:stanag:5644:wsmp:1:3:fault
wsmp-r urn:nato:stanag:5644:wsmp:1:3:resources
wsmp-s urn:nato:stanag:5644:wsmp:1:3:soap:services
wsmp-sp urn:nato:stanag:5644:wsmp:1:3:soap:parameters
wsn-b http://docs.oasis-open.org/wsn/b-2
wsn-bw http://docs.oasis-open.org/wsn/bw-2
wsn-t http://docs.oasis-open.org/wsn/t-1
wsoap12 http://schemas.xmlsoap.org/wsdl/soap12/
wsrf-bf http://docs.oasis-open.org/wsrf/bf-2
wsrf-r http://docs.oasis-open.org/wsrf/r-2
wsrf-rp http://docs.oasis-open.org/wsrf/rp-2
wsrf-rpw http://docs.oasis-open.org/wsrf/rpw-2
wsrf-rw http://docs.oasis-open.org/wsrf/rw-2
xml http://www.w3.org/XML/1998/namespace
xsd http://www.w3.org/2001/XMLSchema
xsi http://www.w3.org/2001/XMLSchema-instance
GOAL AND REQUIREMENTS
GOALS
 Profile the usage of WSMP for the FFT CoI.
 Provide business rules for the exchange of FFT CoI messages.
ADDRESSED REQUIREMENTS
In order to meet the described goals, the WSMP profile shall explicitly address the following
requirements:
 Identify the required Message Exchange Patterns (MEP).
 Specify how to transport ADatP-36(A)(2) messages using the WSMP protocol.
 Identify FFT CoI filtering languages and specify how to use them in conjunction with WSMP
to filter FFT data.
H-2
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
Releasable to IP
ANNEX H to ADatP-36
NON-GOALS
The following goals are out of scope of this annex:
 To define the format of message payloads: the format and the business rules for the ADatP-
36(A)(2) messages are described in ANNEX B and ANNEX C.
 To define the WSMP standard.
 To define and/or profile the messaging protocols.
 To define the message and protocol security aspects.
WSMP PROFILE FOR FFT
This section defines how to use WSMP (ADatP-5644) [Ref 22] within the FFT Community of
Interest (CoI). The requirements in this section have no impact on the WSMP standard but
define the WSMP CoI profile for FFT. In line with requirement R-WSMP-B-2 of ADatP-5644,
contradicting requirements between ADatP-5644, and the WSMP FFT CoI Profile, are to be
treated as follows:
 The ADatP-5644 (WSMP) core requirements have precedence over any WSMP
Message Exchange Profile (MEP).
 The WSMP Message Exchange Profile (MEP) requirements have precedence over this
CoI profile.
The following sections will use the definitions below:

Definition: The WSMP FFT Profile is the profile defined by this document’s Annex H & I, fully
named the WSMP CoI profile for FFT.
Definition: A WSMP FFT System is an FFT system that implements the WSMP FFT Profile to
provide and/or receive FFT Messages
Definition: A WSMP FFT Provider is a WSMP FFT System that supports the providing of FFT
messages using the WSMP FFT Profile.
Definition: A WSMP FFT Receiver is a WSMP FFT System that supports the receiving of FFT
messages using the WSMP FFT Profile.
BR-WSMP-1. The WSMP FFT Profile SHALL be identified with the URI:
“urn:nato:stanag:5644:wsmp:1:3:profiles:coi:ffi:1:5”
This URI will be used in the wsmp-r:WSMPProfile WS-Resource message according to the
WSMP requirements.
BR-WSMP-2. A WSMP FFT System SHALL support the “WSMP Message Exchange
Profile – SOAP 1.2 Profile v1.0” defined in Annex B of ADatP-5644.
WS-TOPIC REQUIREMENTS
Using WSMP, information must be published on a topic (WS-Topic). Topics can be organised
hierarchically into one or more trees of topics. These topics are described within a namespace
(Topic-Namespace). During a deployment, multiple of these topic trees can coexist, defined
within one or more namespaces. The network management authority provides all FFT System
with the documents that describe all topic trees relevant for the mission. The FFT Systems
supported by the network management authority derive from the topic trees which topic(s) are
to be used for exchanging the FFT messages.
H-3
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
Releasable to IP
ANNEX H to ADatP-36
BR-WSMP-3. A WSMP FFT Provider SHALL publish the FFT messages on the correct
topics from the topic trees provided by the network management authority.
In some cases, a WSMP FFT Provider may be unable to determine the topic on which to publish
a specific FFT message. This could occur when information is provided using IP1/IP2 or SIP3
protocols to a Hub or Proxy supporting the exchange using WMSP. The network management
authority also specifies a “default Topic” from the provided topic trees, to be used in these
cases.
BR-WSMP-4. A WSMP FFT Provider SHALL publish FFT messages using the ‘default
Topic’ provided by the network management authority when no other Topic could be
determined.
DATA DIALECT REQUIREMENTS
The WSMP FFT Profile defines the following Data Dialects

Data Dialect Element URI
NFFI 1.3 nffi:NFFIMessage urn:nato:fft:protocols:nffi13
FFI-MTF mtf:FriendlyForceInformation urn:nato:mtf:app-11(d):1:ffi
BR-WSMP-Data-1. A WSMP FFT System SHALL support data dialect FFI-MTF.
Following the ADatP-5644 specification, a WSMP FFT Receiver will request the FFT data
dialect supported from the WSMP FFT provider using the webservice address of the WSMP
FFT Provider. Following the ADatP-5644 specification, a WSMP FFT Provider will expose all
the FFT data dialects for the message formats that it supports.
FFT Message Binding
BR-WSMP-Data-2. A WSMP FFT Provider SHALL include the FFT Message as a child
element of the //wsmp:WSMPMsg/wsmp:Update/wsmp:Data element in all responses.
In some cases payload information with different charateristics (e.g. topic and/or security
labelling) can be separated, into multiple update operation (wsmp:Update elements) of the
WSMP message (wsmp:WSMPMsg), each one containing a different payload in its wsmp:Data
child-element.
BR-WSMP-Data-3. A WSMP FFT Provider sending an FFI-MTF message, SHALL

provide a single mtf:FriendlyForceInformation element as a descendant of the
wsmp:Data elements, and the value “urn:nato:mtf:app-11(d):1:ffi” in the @Dialect
attribute.
BR-WSMP-Data-4. A WSMP FFT Provider sending an NFFI 1.3 message, SHALL

provide a single nffi:NFFIMessage element as the descendant of the wsmp:Data
elements, and the value “urn:nato:fft:protocols:nffi13” in the @Dialect attribute.
METADATA REQUIREMENTS
The WSMP specification defines two places to provide metadata for the content of a WSMP-
message. At the message level using the //wsmp:WSMPMsg/wsmp:MetadataBinding element,
H-4
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
Releasable to IP
ANNEX H to ADatP-36
and at the operation level, inside a CRUD-Command (Create, Read, Update or Delete). This
section defines how these elements are used by the WSMP FFT Profile.
BR-WSMP-Metadata-1. A WSMP FFT Provider SHALL provide, the mandatory

STANAG 5636 [Ref 35] WSMP message metadata included in the
//wsmp:WSMPMsg/wsmp:MetadataBinding element.
BR-WSMP-Metadata-2. A WSMP FFT Provider SHALL provide the metadata

contained in the //wsmp:WSMPMsg/wsmp:MetadataBinding element using an ADatP-
4778 metadata binding as specified by ADatP-4778.2.
BR-WSMP-Metadata-3. A WSMP FFT Provider SHALL NOT provide metadata in the

//wsmp:WSMPMsg/wsmp:Update//wsmp:MetadataBinding element.
As specified by ADatP-4778 an mb:BindingInformation element is provided as a descendant of

the //wsmp:WSMPMsg/wsmp:MetadataBinding element. The @Dialect attribute for the
MetadataBinding element is given the value “urn:nato:stanag:4778:bindinginformation:1:0”.
When the metadata is provided using an ADatP-4778 mb:BindingInformation element the

details provided in ADatP-4778 [Ref 25] dictate to which elements the metadata is applicable.
In case metadata is not provided inside such an element, the WSMP specification states.
 Metadata provided at the message level is applicable to all wsmp:Data elements
contained in the entire message.
 Metadata provided at the operation level is applicable only to the wsmp:Data element
contained in that operation.
Confidentiality Labelling Requirements

FFT messages exchanged as part of the WSMP FFT Profile contain marking information.
Marking information identifies the policy, classification and releasability of the information
contained in the messages. The policy uniquely identifies the Governing Authority which
manages the policy to which the marking information relates.
The marking on the FFT message is mandatory for the FFI message and is optional in an NFFI
1.3 message. To support interoperable information exchange of FFT messages via WSMP, the
marking information (contained in FFT messages) are to be converted to STANAG 5636 (that
subsume the security metadata standard STANAG 4774 [Ref 24]) confidentiality labels. This
Annex specifies how to convert from FFT security marking elements to STANAG 4774
confidentiality labels.
The FFT messages exchanged via WSMP have an associated confidentiality label. The binding
specification for binding confidentiality metadata to XML data within a WSMP message is
defined in ADatP-4778.2 [Ref 29]. The binding of STANAG 4774 confidentiality labels to FFT
messages exchanged via WSMP includes additional constraints over ADatP-4778.2 (included
as requirements in this Annex).
To support interoperability with security labels from multiple policies, it is recommended that
security policies are described in Open XML Security Policy Information File (SPIF) format [Ref
23]. A SPIF describes all the allowable values within a security policy and the relationships
between them. A SPIF can also include information that defines how the allowable values
should be rendered as a security marking. A SPIF can include information for rendering in
different languages. A SPIF can include equivalent mappings to different security policies.
H-5
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
Releasable to IP
ANNEX H to ADatP-36
BR-WSMP-Security-1. A WSMP FFT Provider SHALL NOT assemble tracks marked

with different confidentiality policies in a single WSMP message.
The Security Authority governing the Mission Network may require the protection of the integrity
of FFT messages by a digital signature or a hashed message authentication code.
BR-WSMP-Security-2. A WSMP FFT Provider SHALL follow the Cryptographic

Artefacts Binding Profile defined in ADatP-4778.2 [Ref 29], when protecting the integrity
of an FFT message.
When a WSMP FFT Provider has to convert the security markings of an FFT Message, the
preferred procedure is described here:
1) Transform the “FFT message security marking” (that encompasses the overall security
level) contained in the MessageIdentifier element along with other FFT XML metadata to
a FORMETS Discovery Metadata Specification (FDMS) Version 2.0 metadata card [Ref
32].
2) Transform the FDMS Version 2.0 metadata card to a NATO Discovery Metadata
Specification (NDMS) Version 3.0 metadata card [Ref 33].
3) Transform the NDMS Version 3.0 metadata card to a STANAG 4778 [Ref 25] Detached
BDO (that contains the transformation of the NDMS-specific security marking elements to
the STANAG 4774 confidentiality metadata label elements) (see [Ref 9]). This
transformation results in a STANAG 4778 Detached BDO mb:BindingInformation XML
element.
In case a WSMP FFT Provider has to send FFT tracks with different classifications or
categories, as a result of a Read operation or because of an active subscription, these may be
divided in different WSMP messages, each one containing only tracks with the same
classification or category.
H-6
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
Releasable to IP
ANNEX H to ADatP-36
Example
The example below illustrates a single ADatP-36(A)(2) message contained within the WSMP message with the confidentiality labelling requirements applied.
XML-Code 28 WSMP message containing single FFT Message with 1 track.

1 <wsmp:WSMPMsg xmlns:wsmp="urn:nato:stanag:5644:wsmp:1:3" xmlns:cm="urn:nato:stanag:4774:confidentialitymetadatalabel:1:0" xmlns:mtf="urn:nato:mtf:app-11(d):1:ffi"
xmlns:mb="urn:nato:stanag:4778:bindinginformation:1:0" xmlns:ncms="urn:nato:stanag:5636:A:1:elements" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<wsmp:MetadataBinding wsmp:Dialect="urn:nato:stanag:4778:bindinginformation:1:0">
2 <mb:BindingInformation>
3 <mb:MetadataBindingContainer>
4 <mb:MetadataBinding>
5 <mb:Metadata>
6 <cm:originatorConfidentialityLabel>
7 <cm:ConfidentialityInformation>
8 <cm:PolicyIdentifier>ACME</cm:PolicyIdentifier>
9 <cm:Classification>UNCLASSIFIED</cm:Classification>
10 <cm:Category TagName="Releasable To" Type="PERMISSIVE">
11 <cm:GenericValue>AUS</cm:GenericValue>
12 <cm:GenericValue>AUT</cm:GenericValue>
13 <cm:GenericValue>CHE</cm:GenericValue>
14 <cm:GenericValue>FIN</cm:GenericValue>
15 <cm:GenericValue>NZL</cm:GenericValue>
16 <cm:GenericValue>SWE</cm:GenericValue>
17 </cm:Category>
18 </cm:ConfidentialityInformation>
19 <cm:CreationDateTime>2016-11-20T12:30:00Z</cm:CreationDateTime>
20 </cm:originatorConfidentialityLabel>
21 </mb:Metadata>
22 <mb:Metadata>
23 <cm:metadataConfidentialityLabel>
28 <cm:GenericValue>AUS</cm:GenericValue>
29 <cm:GenericValue>AUT</cm:GenericValue>
30 <cm:GenericValue>CHE</cm:GenericValue>
32 <cm:GenericValue>NZL</cm:GenericValue>
33 <cm:GenericValue>SWE</cm:GenericValue>
34 </cm:Category>
37 </cm:metadataConfidentialityLabel>
H-7 Edition A Version 2

NATO UNCLASSIFIED
NATO UNCLASSIFIED
Releasable to IP
ANNEX H to ADatP-36
38 </mb:Metadata>
39 <mb:Metadata>
40 <ncms:Creator ncms:type="organiation">FFTS VERIFICATION</ncms:Creator>
41 </mb:Metadata>
42 <mb:Metadata>
43 <ncms:DateCreated>2016-06-15</ncms:DateCreated>
44 </mb:Metadata>
45 <mb:Metadata>
46 <ncms:Identifier>0520000</ncms:Identifier>
47 </mb:Metadata>
48 <mb:Metadata>
49 <ncms:Publisher ncms:type="organiation">FFTS VERIFICATION</ncms:Publisher>
50 </mb:Metadata>
51 <mb:Metadata>
52 <ncms:Title>Track Update 0520000</ncms:Title>
53 </mb:Metadata>
54 <mb:DataReference URI="">
55 <ds:Transforms>
56 <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
57 <ds:XPath>//wsmp:WsmpMsg</ds:XPath>
58 </ds:Transform>
59 </ds:Transforms>
60 </mb:DataReference>
61 </mb:MetadataBinding>
62 <mb:MetadataBinding>
63 <mb:Metadata>
64 <cm:originatorConfidentialityLabel>
70 </cm:Category>
73 </cm:originatorConfidentialityLabel>
74 </mb:Metadata>
75 <mb:DataReference URI="">
76 <ds:Transforms>
77 <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
78 <ds:XPath>//mtf:TrackSource | //mtf:TrackSecurityLabel | //mtf:TrackPositionalData</ds:XPath>
79 </ds:Transform>
80 </ds:Transforms>
81 </mb:DataReference>
82 </mb:MetadataBinding>
83 </mb:MetadataBindingContainer>
84 </mb:BindingInformation>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
Releasable to IP
ANNEX H to ADatP-36
85 </wsmp:MetadataBinding>
86 <wsmp:Update>
87 <wsmp:Data wsmp:Dialect="urn:nato:mtf:app-11(d):1:ffi">
88 <mtf:FriendlyForceInformation>
89 <MessageIdentifier>
90 <MessageTextFormatIdentifier>FFI</MessageTextFormatIdentifier>
91 <Standard>APP-11(D)</Standard>
92 <Version>1</Version>
93 <Originator>FFTS VERIFICATION</Originator>
94 <MessageSerialNumber>0520000</MessageSerialNumber>
95 <ReferenceTimeOfPublication>
96 <MonthNameAbbreviated>JUN</MonthNameAbbreviated>
97 </ReferenceTimeOfPublication>
98 <MessageSecurityPolicy>ACME</MessageSecurityPolicy>
99 <MessageClassification>
100 <SecurityClassificationExtended>UNCLASSIFIED</SecurityClassificationExtended>
101 </MessageClassification>
102 <MessageSecurityCategory>REL TO AUS,AUT,CHE,FIN,NZL,SWE</MessageSecurityCategory>
103 </MessageIdentifier>
104 <GeodeticDatum>
105 <GeodeticDatum>WGE</GeodeticDatum>
106 </GeodeticDatum>
107 <TrackInformation>
108 <TrackSource>
109 <TransponderId>IOTA052a000</TransponderId>
110 <System>IOTA-FFT</System>
111 <Nationality>
112 <GeographicalEntity>XXE</GeographicalEntity>
113 </Nationality>
114 </TrackSource>
115 <TrackSecurityLabel>
116 <TrackSecurityPolicy>ACME</TrackSecurityPolicy>
117 <TrackSecurityClassification>
119 </TrackSecurityClassification>
120 <TrackSecurityCategory>REL TO AUS,AUT,CHE,FIN,NZL,SWE</TrackSecurityCategory>
121 <BlueDotSecurityClassification>
123 </BlueDotSecurityClassification>
124 <BlueDotSecurityCategory>REL TO FIN</BlueDotSecurityCategory>
125 </TrackSecurityLabel>
126 <TrackPositionalData>
127 <Time>
128 <Year4Digit>2016</Year4Digit>
129 <MonthNumeric>06</MonthNumeric>
130 <Day>15</Day>
131 <TimeDelimiter>T</TimeDelimiter>

NATO UNCLASSIFIED
NATO UNCLASSIFIED
Releasable to IP
ANNEX H to ADatP-36
132 <HourTime>12</HourTime>
133 <MinuteTime>00</MinuteTime>
134 <SecondTime>00</SecondTime>
135 <TimeZoneZulu>Z</TimeZoneZulu>
136 </Time>
137 <Location>
138 <LatitudeDegrees>61</LatitudeDegrees>
139 <LatitudeMinutes04DecimalPlaces>26.846</LatitudeMinutes04DecimalPlaces>
140 <LatitudinalHemisphere>N</LatitudinalHemisphere>
141 <Hyphen>-</Hyphen>
142 <LongitudeDegrees>023</LongitudeDegrees>
143 <LongitudeMinutes04DecimalPlaces>27.795</LongitudeMinutes04DecimalPlaces>
144 <LongitudinalHemisphere>E</LongitudinalHemisphere>
145 </Location>
146 </TrackPositionalData>
147 <TrackIdentificationData>
148 <UnitSymbol>SFGPUCRH----GM-</UnitSymbol>
149 </TrackIdentificationData>
150 </TrackInformation>
151 </mtf:FriendlyForceInformation>
152 </wsmp:Data>
153 </wsmp:Update>
154 </wsmp:WSMPMsg>
155
156

NATO UNCLASSIFIED
NATO UNCLASSIFIED
Releasable to IP
ANNEX H to ADatP-36
FILTER REQUIREMENTS
This section and its subsections describe all the FilterDialects relevant for the WSMP FFT
Profile. As specified by WSMP (ADatP-5644), a WSMP FFT Provider advertises all supported
filter dialects through its resource properties.
TopicExpression Filter
WSMP (ADatP-5644) specifies the TopicExpression filter. The following requirements apply to
the WSMP FFT Profile.
BR-WSMP-Filter-1. An WSMP FFT System SHALL support the TopicExpression Filter

defined by WSMP.
BR-WSMP-Filter-2. A WSMP FFT System SHALL support the “Simple” and “Concrete”
TopicExpression Dialects.
NOTE: In addition, a WSMP FFT System may support the “Full” TopicExpression Dialect.
MetadataExpression Filter
WSMP (ADatP-5644) specifies the MetadataExpression Filter. The following requirements

apply to the WSMP FFT Profile.
BR-WSMP-Filter-3. A WSMP FFT Provider SHALL support the MetadataExpression

Filter defined by WSMP.
MessageContent Filter
WSMP (ADatP-5644) specifies two DataContent filter dialects, “XPath” and “Data-dialect”.
BR-WSMP-Filter-4. A WSMP FFT Provider SHALL support the “Data-dialect” filter

defined by WSMP.
In addition to this the WSMP FFT Profile defines the “FFT Filter” dialect This filter is based on
a neutral syntax that is defined in ANNEX I.
BR-WSMP-Filter-5. A WSMP FFT Provider SHALL support the “FFT Filter” as defined
in Annex I of this specification.
The MessageContent filter is present in both Publish/Subscribe (wsn-b:MessageContent) and

Request/Response (wsmp:MessageContent). These are used respectively when subscribing
and requesting.
BR-WSMP-Filter-6. An WSMP FFT Receiver using the “FFT Filter” SHALL provide a
single fft-q:Filter element in the MessageContent filter element, with the value
“urn:nato:fft:filter:1:0” for the @Dialect attribute.
H-11
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
Releasable to IP
ANNEX H to ADatP-36
WSMP (ADatP-5644) specifies that in case multiple filters are indicated in the query message
(i.e. more sub element of the //WSMPRead/Filter are defined) the WSMP FFT Providers will
return only the tracks matching all the filters (Logical AND operation between the filter
elements).
BR-WSMP-Filter-7. A WSMP FFT Provider SHALL apply the filter to individual track
data and not to FFT messages.
This means that a response to a read operation will only return tracks matching the requested
filter.
EXCHANGE SPECIFIC REQUIREMENTS

WSMP (ADatP-5644) specifies two Message Exchange Patterns (MEP). This section provides
additional context for those MEP when used with the WSMP FFT Profile.
Request/Response MEP
This MEP is implemented over SOAP 1.2 using the WSMP-RR protocol defined in WSMP
(ADatP-5644). The WSMP specification requires a WSMP Service Provider to expose all
service endpoints (Create, Read, Update and Delete), however the CoI profile must define
which ones are supported for the profile. Section H.3.2 defining the data dialects specifies how
the FFT messages are provided as part of the WSMP messages.
BR-WSMP-RR-1. An WSMP FFT System SHALL implement the Read operation.
The other operations (Create, Update and Delete) may be implemented by a WSMP service,
however their behaviour is not defined by the WSMP FFT Profile.
WSMP FFT Receivers requesting FFT data from a WSMP FFT Provider will invoke the Read
operation by sending a //wsmp:Read message. WSMP FFT Receivers will request FFT tracks
of interest by defining a filter in the //wsmp:Read/wsmp:Filter request element using one of the
dialects defined in H.3.4.
BR-WSMP-RR-2. A WSMP FFT Provider SHALL return a WSMP message

(wsmp:WSMPMsg) without any update elements (//wsmp:WSMPMsg/wsmp:Update)
when a filter excludes all tracks.
Publish/Subscribe MEP
A WSMP FFT Provider may only notify on changes to the tracks. This means that the creation
of a subscription does not result in a Notification. The WSMP FFT Provider will only create a
notification message when a track is updated or created after the subscription has been
created.
BR-WSMP-PS-1. A WSMP FFT Provider SHALL NOT create a notification as a result

of the creation of a subscription.
BR-WSMP-PS-2. A WSMP FFT Provider SHALL only create a notification message

when a track is updated or created.
H-12
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX I to ADatP-36
– TECHNICAL SPECIFICATION – FFT FILTER LANGUAGE
INTRODUCTION
This annex provides a filtering language specification that is used (see BR-WSMP-Filter-6) by
the WSMP FFT Profile defined in ANNEX H.
WSMP FFT Receivers need to have a mechanism to select the data of interest.
The scope of this Annex is to define a content filtering language that allows WSMP FFT
Receivers to select the FFT Tracks that are to be provided by a WSMP FFT Provider.
GOALS AND REQUIREMENTS
GOALS
 Define a filter language for FFT information.

 Describe how filters can be combined.
 Provide business rules for WSMP FFT Providers on how to apply the filters to select the
relevant FFT information to return to the WSMP FFT Receiver.
ADDRESSED REQUIREMENTS
This filtering language specification enables the following consumer requirements:
 Ability to specify if FFT track historical information should be returned for FFT tracks.
 Ability to filter FFT information reported in a specific time period.
 Ability to filter on UTID.
 Ability to filter on a two-dimensional geographic area.
NON-GOALS
The following goals are out of scope of this annex:
 To define the usage of an FFT-Filter instance FFTRequest.
 To define the Message Exchange Pattern (MEP) or Web Service Profile for the delivery of
FFT Tracksthat passed Filtering.
I-1
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX I to ADatP-36
FFT FILTER LANGUAGE

The FFT Filtering Language facilitates expressing filter-queries to WSMP FFT Providers. The
filter language provides filtering/querying on Track History, Track-Report Time, and various
types of Track/Unit-Selectors.
An FFT filter in a Web-Service request is an instance of the FFT Filter Language XML Schema
depicted in the figure below.
Figure 18 Filter element in FFT Filter schema
When applying an FFT filter in the sense of this Annex, the FFT Filter Language XML Schema
(see section I.4) is used. This schema is the normative location where the format, structure,
value-type and other meta-data for XML-Elements and XML-Types are defined.
BR-FFT-Filter-1. WSMP FFT Providers receiving an FFT filter element that does not
validate against the FFT Filter Language XML Schema SHALL not process the
message and SHALL generate a Fault, indicating that the specified FFT filter element
is not valid.
BR-FFT-Filter-2. WSMP FFT Providers SHALL ignore any received empty FFT filter
instances (no child elements).
BR-FFT-Filter-3. WSMP FFT Providers SHALL only provide FFT Tracks that pass FFT
filter in responses and notifications.
BR-FFT-Filter-4. WSMP FFT Providers SHALL interpret the occurance of multiple filter
elements (Source, Geometry, History and TimeFrame), as a “logical and” between
these filter elements. I.e., a filtered response needs to comply with all of these elements.
SOURCE FILTER
The source filter allows selecting FFT Tracks based on their identifying attributes. The
attributes that can be used to identify an FFT Track are outlined in the table below. Note that
I-2
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX I to ADatP-36
those attributes may be identified and named differently in various FFT message formats. This
section does not describe how the mentioned attributes are represented in the FFT messages.
Table 16 Identifying attributes of an FFT track
Unit/Track Attribute Description

System Name of the FFT System
TerminalId Unique Identifier of a unit’s FFT-Terminal within the FFT System
The source selector element in an FFT Filter is depicted in the figure below.
Figure 19 Source filter element in FFT Filter schema
BR-FFT-Filter-Source-1. A WSMP FFT Provider SHALL implement the source filter.

Note: even though a WSMP FFT Provider has to support the source filter, the presence of a
source element (fft-q:Source) in an FFT Filter is optional.
BR-FFT-Filter-Source-2. When applying the source filter, a WSMP FFT Provider

SHALL only provide FFT Tracks whose identifying attributes are matching the specified
criteria.
Note that currently there is no support for wildcards or regular expressions.
BR-FFT-Filter-Source-3. A WSMP FFT Receiver SHALL provide at least one of the

child elements in the source element (fft-q:Source).
BR-FFT-Filter-Source-4. A WSMP FFT Provider SHALL generate a fault indication the

source filter when the source element (fft-q:Source) is empty (no children).
GEOGRAPHIC AREA FILTER

The geographic area filter allows selecting FFT Tracks based on their geographic position. A
geographic area is specified as either a boundingbox area or as a proximity area. The
geographical area selector element in an FFT Filter is depicted in the figure below.
I-3
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX I to ADatP-36
Figure 20 Geographic area filter element in FFT Filter schema
BR-FFT-Filter-Geometry-1. A WSMP FFT Provider SHALL implement the geographic

area filter.
Note: even though a WSMP FFT Provider has to support the geographic area filter, the
presence of a geometry element (fft-q:Geometry) in an FFT Filter is optional.
BR-FFT-Filter-Geometry-2. When applying the geographic area filter, a WSMP FFT

Provider SHALL only provide FFT Tracks whose geographic location is within the
boundaries of the specified geographical area.
Geographic area filter using Bounding Box
A boundingbox area for a geographical area filter is defined by its north-west corner and its
south-east corner. The boundingbox selector type in an FFT Filter is depicted in the figure
below.
Figure 21 Boundingbox type in FFT Filter schema
I-4
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX I to ADatP-36
BR-FFT-Filter-Geometry-3. When applying the boundingbox area filter, a WSMP FFT

specified boundingbox.
The following formula SHALL be used:

If (SouthEastCorner.Longitude >= NorthWestCorner.Longitude)
 (SouthEastCorner.Latitude <= Track.Latitude
AND (Track.Latitude <= NorthWestCorner.Latitude)
AND (SouthEastCorner.Longitude >= Track.Longitude)
AND (Track.Longitude >= NorthWestCorner.Longitude)
Else // (SouthEastCorner.Longitude < NorthWestCorner.Longitude)
 (SouthEastCorner.Latitude <= Track.Latitude)
AND (Track.Latitude <= NorthWestCorner.Latitude)
AND ((Track.Longitude <= SouthEastCorner.Longitude)
OR (Track.Longitude >= NorthWestCorner.Longitude))
Geographic area filtering using Proximity

A proximity area for a geographical area filter is defined by its coordinate and its radius. The
proximity selector type in an FFT Filter is depicted in the figure below.
Figure 22 Proximity type in FFT Filter schema
BR-FFT-Filter-Geometry-4. When applying the proximity area filter, a WSMP FFT

specified proximity.
The following criteria apply:

When the orthodromic distance (great-circle distance) between geographic position of
an FFT Track and the coordinate of the proximity element is less than or equal to the
radius of the proximity element.
TIMEFRAME FILTER
The time-frame area filter allows requesting historical FFT Tracks based on the reporting-
datetime of their updates. The timeframe filter is applicable only to the Request/Response
Message Exchange Pattern (MEP). The timeframe selector element in an FFT Filter is depicted
in the figure below.
I-5
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX I to ADatP-36
Figure 23 Timeframe element in FFT Filter schema
BR-FFT-Filter-Timeframe-1. A WSMP FFT Provider SHALL implement the timeframe

filter for Request/Response.
Note: even though a WSMP FFT Provider has to support the timeframe filter, the presence of
a time frame element (fft-q:Timeframe) in an FFT Filter is optional.
BR-FFT-Filter-Timeframe-2. A WSMP FFT Provider SHALL generate a fault when it

receives a subscription that includes a timeframe filter.

receives a timeframe filter in which the Start time or the End time is in the future (relative
to current system time).
The WSMP FFT Provider SHALL indicate malformed timeframe filtering parameters in
the generated fault.

receives a timeframe filter in which the Start time is greater than the End time.
The WSMP FFT Provider SHALL indicate malformed timeframe filtering parameters in
the generated fault.
BR-FFT-Filter-Timeframe-5. When applying the timeframe filter, a WSMP FFT

Provider SHALL only provide FFT Track updates whose reporting-datetime is within the
specified timeframe.
The following formula SHALL be used:

If (End is not specified)
 (Track.ReportingDatetime >= Timeframe.Start)
Else // (End is specified)
 (Timeframe.Start <= Track.ReportingDatetime)
AND (Track.ReportingDatetime <= Timeframe.End)
When history element (fft-q:History) has the value “true” or 1, the WSMP FFT Provider
SHALL provide all the results.
When history element (fft-q:History) has the value “false” or 0, the WSMP FFT Provider
SHALL only provide from the results, the Track-Update(s) with the highest reporting-
datetime for each FFT Track.
I-6
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX I to ADatP-36
NORMATIVE SCHEMA
1 <?xml version="1.0" encoding="UTF-8"?>
2 
3 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
4 xmlns:fft-q="urn:nato:fft:filter:1:0" targetNamespace="urn:nato:fft:filter:1:0"
5 elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0.0">
6 <xs:simpleType name="NoSpaceStringType">
7 <xs:restriction base="xs:string">
8 <xs:pattern value="[^\s]+"/>
9 </xs:restriction>
10 </xs:simpleType>
11 <xs:simpleType name="TerminalIdType">
12 <xs:restriction base="fft-q:NoSpaceStringType"/>
13 </xs:simpleType>
14 <xs:simpleType name="SystemType">
15 <xs:restriction base="fft-q:NoSpaceStringType"/>
16 </xs:simpleType>
17 <xs:simpleType name="LongitudeType">
18 <xs:restriction base="xs:double">
19 <xs:minExclusive value="-180"/>
20 <xs:maxInclusive value="180"/>
21 </xs:restriction>
22 </xs:simpleType>
23 <xs:simpleType name="LatitudeType">
25 <xs:minInclusive value="-90"/>
26 <xs:maxInclusive value="90"/>
28 </xs:simpleType>
29 <xs:simpleType name="RadiusType">
31 <xs:minExclusive value="0"/>
32 
34 </xs:simpleType>
35 <xs:element name="Start" type="xs:dateTime"/>
36 <xs:element name="End" type="xs:dateTime"/>
37 <xs:element name="History" type="xs:boolean"/>
38 <xs:element name="TerminalId" type="fft-q:TerminalIdType"/>
39 <xs:element name="System" type="fft-q:SystemType"/>
40 <xs:element name="Longitude" type="fft-q:LongitudeType"/>
41 <xs:element name="Latitude" type="fft-q:LatitudeType"/>
42 <xs:element name="Radius" type="fft-q:RadiusType"/>
43 <xs:complexType name="TimeframeType">
44 <xs:sequence minOccurs="0">
45 <xs:element ref="fft-q:Start"/>
46 <xs:element ref="fft-q:End" minOccurs="0"/>
47 <xs:element ref="fft-q:History"/>
48 </xs:sequence>
49 </xs:complexType>
50 <xs:complexType name="CoordinateType">
52 <xs:element ref="fft-q:Latitude"/>
53 <xs:element ref="fft-q:Longitude"/>
54 </xs:sequence>
56 <xs:complexType name="BoundingBoxType">
57 <xs:complexContent>
58 <xs:extension base="fft-q:GeometryType">
60 <xs:element ref="fft-q:NorthWestCorner"/>
61 <xs:element ref="fft-q:SouthEastCorner"/>
62 </xs:sequence>
63 </xs:extension>
64 </xs:complexContent>
66 <xs:complexType name="ProximityType">
67 <xs:complexContent>
68 <xs:extension base="fft-q:GeometryType">
70 <xs:element ref="fft-q:Coordinate"/>
I-7
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX I to ADatP-36
71 <xs:element ref="fft-q:Radius"/>
72 </xs:sequence>
73 </xs:extension>
74 </xs:complexContent>
76 <xs:element name="Timeframe" type="fft-q:TimeframeType"/>
77 <xs:element name="NorthWestCorner" type="fft-q:CoordinateType"/>
78 <xs:element name="SouthEastCorner" type="fft-q:CoordinateType"/>
79 <xs:element name="Coordinate" type="fft-q:CoordinateType"/>
80 <xs:complexType name="GeometryType" abstract="true"/>
81 <xs:complexType name="SourceType">
82 <xs:sequence>
83 <xs:element ref="fft-q:System" minOccurs="0"/>
84 <xs:element ref="fft-q:TerminalId" minOccurs="0" maxOccurs="unbounded"/>
85 </xs:sequence>
87 <xs:element name="Geometry" type="fft-q:GeometryType"/>
88 <xs:element name="Source" type="fft-q:SourceType"/>
89 <xs:complexType name="FilterType">
91 <xs:element ref="fft-q:Source" minOccurs="0"/>
92 <xs:element ref="fft-q:Geometry" minOccurs="0"/>
93 <xs:element ref="fft-q:Timeframe" minOccurs="0"/>
94 </xs:sequence>
96 <xs:element name="Filter" type="fft-q:FilterType"/>
97 </xs:schema>
98
XML-Code 29 Normative FFT filtering language schema
I-8
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX J to ADatP-36
– LIST OF REFERENCES
[Ref 1] C-M(2002)49-COR12, Security within the NATO, Corrigendum to C-M(2002)49

dated 17 June 2002, Amendment 12, dated September 2015 (NATO Unclassified)
[Ref 2] Federal Information Processing Standard; April 1995 Countries, Dependencies,
Areas of Special Sovereignty, and Their Principal Administrative Divisions; FIPS
PUB 10-4
[Ref 3] Internet Engineering Task Force (IETF) Request for Comment (RFC) 768 User
Datagram Protocol, 28 August 1980
[Ref 4] Internet Engineering Task Force (IETF) Request for Comment (RFC) 793
Transmission Control Protocol (TCP), September 1981
[Ref 5] Internet Engineering Task Force (IETF) Request for Comment (RFC) 1122
Requirements for Internet Hosts -- Communication Layers, October 1989
[Ref 6] Internet Engineering Task Force (IETF) Request for Comment (RFC) 1950 – ZLIB
Compressed Data Format Specification, Version 3.3, May 1996
[Ref 7] Internet Engineering Task Force (IETF) Request for Comment (RFC) 1951 -
DEFLATE Compressed Data Format Specification, May 1996
[Ref 8] Internet Engineering Task Force (IETF) Request for Comment (RFC) 2119 - Key
words for use in RFCs to Indicate Requirement Levels, March 1997
[Ref 9] NCI Agency, NDMS Version 3.0 Metadata Card to STANAG 4778 (XSLT), at NATO
Metadata Registry & Repository (NMRR)
[Ref 10] NATO Consultation, Command and Control Board (NC3B) AC/322-D(2004)0022
(INV), (16 March 2004) NATO C3 Board Technical and Implementation Guidance
for Consistent Marking of NATO Information in C3 Systems (NATO Unclassified)
[Ref 11] NATO Consultation, Command and Control Board (NC3B) AC/322-D(2006)0066 (15
December 2006) Interim NATO Friendly Force Information (NFFI) Standard for
Interoperability of Force Tracking Systems (FTS) (NFFI D-document), and xsd files,
version 1.3.1 (NATO Unclassified)
[Ref 12] NATO Interoperability Standards and Profiles (ADatP-34(K)) Version 11, 3 August
2018
[Ref 13] NATO Standardization Agency; 02 December 2009, NATO Message Text
Formatting System; ADatP-3(A), Change 1 / STANAG 5500 Edition 7 (NATO/EAPC
Unclassified)
[Ref 14] NATO Standardization Office; 23 November 2015, NATO Message Catalogue; APP-
11(D)(1); STANAG 7149; (NATO Unclassified)
J-1
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX J to ADatP-36
[Ref 15] NATO Standardization Organization; NATO Standard Identity Description Structure
For Tactical Use; STANAG 1241, Edition 5, 27 October 2009 (NATO Unclassified)
[Ref 16] NATO Standardization Organisation (NSO); APP-6(A) Military Symbols for Land-
Based Systems; STANAG 2019 Edition 4 / APP-06 Edition A, December 1999
(NATO Unclassified)
[Ref 17] Oasis, “Web Services Security: SOAP Message Security 1.1, "https://www.oasis-
open.org/committees/download.php/16790/wss-v1.1-spec-os-
SOAPMessageSecurity.pdf", 1 February 2006
[Ref 18] Web Services Interoperability Organization, “WS-I Basic Profile Version 1.1”,
http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html, 24 August 2004
[Ref 19] WGS 84 USA Department of Defense – National Geospatial-Intelligence Agency
World Geodetic System 1984 (WGS 84) (Unclassified)
[Ref 20] World Wide Web Consortium (W3C), “Web Services Eventing (WS-Eventing)”,
http://www.w3.org/Submission/WS-Eventing/, W3C Member Submission 15 March
2006
[Ref 21] World Wide Web Consortium (W3C) Recommendation, “XML Path Language
(XPath) Version 1.0”, http://www.w3.org/TR/xpath/, W3C Recommendation 16
November 1999, revised October 2016
[Ref 22] NATO Standardization Organisation (NSO); “Web Service Messaging Profile
(WSMP)”, STANAG-5644, Nov 2020 (NATO Unclassified)
[Ref 23] Open XML SPIF format (online) http://www.xmlspif.org, “Security Policy Information
File (SPIF) v2.0 format”, XMLSPIF.ORG, at
http://www.xmlspif.org/schema/xmlspif.xsd , May 2010.
[Ref 24] NATO Standardization Organisation (NSO); Confidentiality Metadata Label Syntax;
ADatP-4774, Edition A Version 1, December 2017
[Ref 25] NATO Standardization Organisation (NSO); Metadata Binding Mechanism; ADatP-
4778, Edition A Version 1, October 2018
[Ref 26] NATO Standardization Organisation (NSO), “Friendly Force Tracking Systems
(FFTS) Interoperability”, ADatP-36, Edition A Version 1, 20 March 2017
[Ref 27] OASIS, “Web Services Base Notification 1.3”, at http://docs.oasis-
open.org/wsn/wsn-ws_base_notification-1.3-spec-os.pdf, 1 October 2006
[Ref 28] TIDE community, “TIDE Publish Subscribe WS-Notification”, at
https://tide.act.nato.int/tidepedia/index.php/TIDE_Publish_Subscribe_WS-
Notification, 16 November 2015
[Ref 29] NATO Standardization Organisation (NSO); Profiles for binding Metadata to a Data
Object; ADatP-4778.2, Edition A Version 1, December 2020
[Ref 30] NATO Standardization Organisation (NSO), “JOINT SYMBOLOGY APP-6(B)”,
STANAG 2019 Edition 5 / APP-06 Edition B, 25 June 2008
J-2
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX J to ADatP-36
[Ref 31] Internet Engineering Task Force (IETF), Request for Comments (RFC) 8174 -
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words, May 2017
[Ref 32] NCI Agency, XML-MTF metadata to a FORMETS Discovery Metadata Specification
(FDMS) Version 2.0 metadata card (XSLT), at NATO Metadata Registry &
Repository (NMRR)
[Ref 33] FDMS Version 2.0 metadata card to a NATO Discovery Metadata Specification
(NDMS) Version 3.0 metadata card (XSLT), at NATO Metadata Registry &
Repository (NMRR)
[Ref 34] Wikipedia definition (on-line), http://en.wikipedia.org, “Vertex (geometry)”, at
http://en.wikipedia.org/wiki/Vertex_(geometry)
[Ref 35] ADatP-5636, Core Metadata Specification
[Ref 36] C-M(2002)60, The management of non-classified NATO information, dated 11 July
2002
J-3
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX J to ADatP-36
INTENTIONALLY BLANK
J-4
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX K to ADatP-36
– LEXICON
ACRONYMS AND ABBREVIATIONS
ADatP Allied Data Publication

API Application Programming Interface
APP Allied Procedural Publication
ASCII American Standard Code for Information Interchange
BR Business Rule
C3 Consultation, Command and Control
COI Community of Interest
DNS Domain Name System
EAPC European Atlantic Partnership Council
FFI IP1 FFI Interface Protocol 1
FFI IP2 FFI Interface Protocol 2
FFT Friendly Force Tracking
FFTS Friendly Force Tracking System
FIPS Federal Information Processing Standard
FT Force Tracker
FTS Force Tracking Systems
HTTP Hypertext Transport Protocol
ID Identification
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IP Internet Protocol
IP Interoperability Platform
IPv4 Internet Protocol Version 4
IPv6 Internet Protocol Version 6
ISAF International Security Assistance Force
ISO International Standards Organization
IT Information Technology
MTF Message Text Format
NATO North Atlantic Treaty Organization
NC3A NATO Consultation, Command and Control Agency (now NCIA, NATO
Communications and Information Agency)
NFFI NATO Friendly Force Information
NSA NATO Standardization Agency
NSO NATO Standardisation Office
ORBAT Order of Battle
OSI Open Systems Interconnection
RFC Request for Comments
SIP Service Interoperability Profile
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SOF Special Operations Forces
SOP Standard Operating Procedure
STANAG Standardization Agreement
K-1
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX K to ADatP-36
TCP Transmission Control Protocol

TCP/IP Transmission Control Protocol/Internet Protocol
TTP Tactics, Techniques and Procedures
UDP User Datagram Protocol
URN Unit Reference Number
UTC Universal Time Coordinated
UTID Unique Terminal Identification
UTF Unicode Transformation Format
VMF Variable Message Format
WGS World Geodetic System
WSDL Web Service Definition Language
WS-I BP Web Services Interoperability Basic Profile
WSS Web Services - Security
XML eXtensible Markup Language
XSD XML Schema Definition
WSMP Web Service Message Protocol
TERMS AND DEFINITIONS

In this standard the following terms have the meanings set out below.
Augmentation
The process to enhance and enrich information (add/modify) of an existing Friendly Force
Tracking object. The augmented information can add extra information or can provide more
accuracy and reliable information on the existing information.
Augmentation Parameter Types

• DI - Dynamic Information (e.g., Time, Location, Altitude) will change very often.
• SD - Semi-Dynamic (e.g., Planned location, Operational Status) will change, but normally
not very often.
• SS - Semi-Static Information (e.g., unit short name) can change, but not often.
• SI - Static Information (e.g., Nationality, TransponderID) will rarely ever change.
Blue Dot
A “Blue Dot” is a minimum position report for a friendly force track that only indicates the FFT
Terminal UTID, its position at a reported time together with its security classification.
Command and Control System

The facilities, equipment, communications, procedures, and personnel essential to a
commander for planning, directing, and controlling operations of assigned and attached forces
pursuant to the missions assigned.
Compound tracks
“To compound tracks” is the act of combining multiple track updates into a single message.
Therefore a compound track message is a message that contains more than one track update.
FFI IP1/IP2 Message

The combination of an IP1/IP2 header together with its FFI Payload in form of a message,
compressed or uncompressed, is called the FFI IP1/IP2 Message.
K-2
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX K to ADatP-36
FFI Payload
The FFI Payload contains the Friendly Force Information in a format indicated in the preceding
IP1/IP2 header.
FFT (Concept)
Friendly Force Tracking – The capability to report and monitor the location of Friendly Forces
and to support Command and Control on those forces. Also called FFT and formerly called
Blue Force Tracking.
FFT Gateway
A system that connects one or more FFT Terminals and can exchange information with other
FFT Gateways or with FFT Hubs via FFI MTF.
FFT Hub
A system that connects more than one FFT Gateway but not FFT Terminals. Filters and
business rules must be applied in order to not create data loops.
FFI Message
An FFI message that is a conforming to APP-11(D)(1) [Ref 14] and the formatting language of
ADatP-3(A) [Ref 13]. Note that only the XML-MTF representation (and not the MTF slant
delimited representation) is used for information exchange compatible with this standard.
FFT Message
An FFT message, in the context of an information exchange compatible with this standard, is
either an FFI XML-MTF formatted message or an NFFI formatted message.
FFT Proxy
An FFT Gateway or FFT Hub able to exchange at least two different protocols such as FFI MTF
and NFFI and is able to map information.
FFT Terminal or FFT Transponder

The individual reporting device of a Friendly Force Tracking System. It is connected to an FFT
Gateway using a system-specific protocol that is not addressed by this standard. Note: “FFT
Terminal” is used synonymously in this standard with “FFT Transponder”. The term
“Transponder” is used for legacy reasons when it indicates a part of a field name such as
TransponderId.
FFTS capable C2 System

A command and control system that includes the capability to track unit position with accuracy
and automatically report unit position and status information to the chain of command in near
real time.
Friendly Force Information (FFI)

Information provided by a Friendly Force Tracking System (FFTS) that tracks unit position with
accuracy and automatically reports unit position and status information to the chain of
command in near real time.
Friendly Force Tracking System (FFTS)

A system that generates own positions with high accuracy and automatically report these
positions and, where implemented, additional status information to the chain of command.
K-3
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX K to ADatP-36
FFTS may be a standalone system or fielded as an inherent functionality within a battle

management or command and control system.
Friendly Force Information Message Text Format (FFI MTF)

An ADatP-3(A) [Ref 13] compliant message format to exchange positional and operational
information of friendly forces.
Formatting Language
A specification that details how a message format is specified.
IP1/IP2 header
The FFI IP1/IP2 header is an application-layer prefix for both IP1 and IP2.
Mapping
The translation of information from one standard to another, applying applicable business rules.
Message Text Formats (MTF)

Message formats that adhere to ADatP-3(A) [Ref 13] and published in the APP-11 NATO MTF
Catalogue.
Message Format
A detailed technical description of the structure, permissible content and meaning or
interpretation of the content of a message for the purpose of information exchange.
Message
An instance of an information exchange that follows a particular message format.
Nilled field
A field in a message that has no content. This is represented in MTF (i.e. slant delimited) by an
“hyphen” (i.e., ‘-’) and in XML-MTF by an empty field with an attribute xsi:nil. See also ADatP-
3(A) [Ref 13].
When the data needed to complete a field is not available or is being withheld, the Hyphen "-"
is used as the field content.
(1) The use of a Hyphen may only be used once in a field irrespective of whether it is an
elemental or a composite. In the case of a composite if one of the elements of the composite
are not available or being withheld the whole field should be considered to be not available and
a single hyphen should be inserted in the field. A field descriptor cannot be used in conjunction
with a hyphen.
(2) If a Composite Field is specified, all elements of a composite field format must be known in
order for it to be completed. As an example, Table 2000 (Day and Time) is a composite field
format composed of elemental Tables 1000 (Day), 1001 (Hours), 1002 (Minutes) and 1003
(Time Zone). If the correct time zone is not known, Table 2000 is not known, in its entirety, and
the hyphen must be used.
Optional field
A field that does not need to be present in the message.
K-4
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX K to ADatP-36
Security Marking
A marking is human understandable, formatted text that is applied to printed or displayed
information, and that represents restrictions on the handling or dissemination of that
information, as required by a security policy. See AC/322-D(2004)0022 (INV) [Ref 10].
Security Policy
In the context of information exchange, a security policy is a set of rules for protecting
information against unauthorized disclosure while maintaining authorized access, and
preventing loss or unauthorized modification. See AC/322-D(2004)0022 (INV) [Ref 10].
Tracked Objects
Tracked objects are typically vehicles or dismounted soldiers. FFTS may also be used in
tracking of low flying aircraft (e.g., helicopter and UAV). This standard may be used for
interoperability and data exchange for tracking data from a collaborating civilian entity that is
providing tracking data to friendly forces such as a Non-Governmental Organization or civilian
convoy
Track Online, Offline, Dropped

An Active Track is a track that has been updated within a specified period. A Track is said to
be updated if it has a newer reported time at a specific location. An Inactive Track is a track
that has not been updated within a specified period. A Track is dropped, if it has been inactive
for a specific period.
Parameters shall be part of the network design for any specific exercise or mission network,
therefore the Situational Awareness (SA) will be the same in all the systems of the network.
Unique Terminal Identification (UTID)

Unique information is mandatory for coherent data management. In the field of FFT, the
unambiguous association of data with an identifier mandates a controlled dissemination of
unique terminal identifications (UTIDs).
Valid XML
An XML document is considered valid, if it is well-formed and complies with the relevant XML
schema.
Well-formed XML
An XML document is considered well-formed if it uses the correct XML syntax according to
W3C standards.
K-5
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX K to ADatP-36
INTENTIONALLY BLANK
K-6
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ANNEX L to ADatP-36
– REVISION HISTORY
The table below provides the changes between edition A version 1 (see [Ref 26] and this
(version 2) standard.
Numbered Item Action Subject

BR-Payload-4 Added Do not include BOM in the payload
BR-Payload-5 Added Do not include BOM in the payload
Table 4 XML (Message/Field) Changed Geographical entity interpretation
Clarification
Table 4 XML (Message/Field) Changed Undefined GeodeticDatum behaviour
Clarification
Table 5 Interpretation and Added Interpretation of nilled fields
processing of nilled fields
Section D.1. Changed UnitSymbol can only contain APP-
6(A) or APP-6(B) symbol ID codes.
Table 6 Structure of APP- Changed Symbol country interpretation
6(A)/APP-6(B) Symbol ID code
BR-Forward Tracks-1 Changed Process invalid message if blue dot
BR-Mapping-1 fields are valid
BR-Mapping-2
BR-Mapping-6
BR-Mapping-7
BR-Header Field-7 Changed Don’t use the IP1 Destination System
field for routing
BR-Header Field-8 Deleted Don’t use the IP1 Destination System
BR-Header Field-9 field for routing
BR-Forward Tracks-6 Added Hub behaviour
BR-FFT Proxy-8 Changed Compounding is optional
BR-FFT Hub-5
Table 4 XML (Message/Field) Changed The TransponderId is case
Clarification insensitive
Table 4 XML (Message/Field) Changed Set the Originator after message
Clarification modification
R-FFIS12-17 Changed Refined requirement
R-FFIS12-34
R-FFIS12-12 Deleted Redundant
R-FFIS12-13
R-FFTFL-68 Added Generic for all type of filters
R-FFTFL-22, 28, 31-34, 37, 41, Deleted Redundant requirements
45, 51, 53, 56, 59
ANNEX H Added Added a new annex that provides a
WSMP profile for FFT.
ANNEX I Added Added a new annex that provides the
filtering language specification, to be
used by the FFT WSMP profile.
INTENTIONALLY BLANK
L-1
Edition A Version 2
NATO UNCLASSIFIED
NATO UNCLASSIFIED
ADatP-36(A)(2)
Edition A Version 2
NATO UNCLASSIFIED

ADatP-36 EDA V2 E

Uploaded by

Copyright:

Available Formats

You might also like

ADatP-36 EDA V2 E

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

ADatP-36 EDA V2 E

Uploaded by

Copyright:

Available Formats

NATO UNCLASSIFIED

Releasable to Interoperability Platform

FRIENDLY FORCE TRACKING

NORTH ATLANTIC TREATY ORGANIZATION

ALLIED DATA PUBLICATION

RESERVED FOR NATO LETTER OF PROMULGATION

CHAPTER RECORD OF RESERVATION BY NATIONS

III Edition A Version 2

RECORD OF SPECIFIC RESERVATIONS

[nation] [detail of reservation]

VII Edition A Version 2

Interface Protocol Implementation ................................................................... A-14

VIII Edition A Version 2

SIP3 API ..................................................................................................... E-5

Data Dialect Requirements ......................................................................... H-4

XII Edition A Version 2

LIST OF XML CODES

XIII Edition A Version 2

XIV Edition A Version 2

1. PURPOSE AND SCOPE OF THE DOCUMENT

2. TERMS, DEFINITIONS AND CONVENTIONS

3. FRIENDLY FORCE TRACKING (FFT)

The basic roles in the FFT network are:

FFT REPORT DETAILS

Refer to ANNEX F for detailed description of security marking.

FRIENDLY FORCE INFORMATION MESSAGE FORMAT

UNIQUE TERMINAL IDENTIFICATION (UTID)

OTHER IDENTIFICATION DATA

PROCESSING OF FFI DATA

BR-Processing-3. In case movement data (i.e. bearing, speed, inclination) is reported,

Figure 2 STANAG Transformation Framework Layers

The STF is characterized by:

ANNEX A – Technical Specification – Data Bearer and Routing Layers

– TECHNICAL SPECIFICATION – DATA BEARER AND

FFI INTERFACE PROTOCOL (IP) / SERVICE INTEROPERABILITY PROFILE (SIP)

BR-Implementation-1. IP1 SHALL be the minimum implementation for data exchange

BR-Implementation-2. Implementation of IP2, SIP3 and WSMP are OPTIONAL and

INTERFACE PROTOCOL 1 (IP1)

A-1 Edition A Version 2

IP1: LINK LAYER

IP1: INTERNET LAYER

BR-IP1-2. At a minimum, IPv4 SHALL be supported.

IP1: TRANSPORT LAYER

Connection-oriented protocols establish an end-to-end link before any data is transported.

A-2 Edition A Version 2

BR-IP1-6. The consumer system MUST establish a monitoring capability to determine

IP1: APPLICATION LAYER

INTERFACE PROTOCOL 2 (IP2)

A-3 Edition A Version 2

IP2: LINK LAYER

IP2: INTERNET LAYER

IP2: TRANSPORT LAYER

BR-IP2-1. The IP2 implementation SHALL support unicast UDP communication.

BR-IP2-2. Multicast UDP communication MAY be supported, but coordination between

IP2: APPLICATION LAYER

A-4 Edition A Version 2

FFI DATA COMPRESSION

A-5 Edition A Version 2

FFI IP1/IP2 HEADER SPECIFICATION