Land Force Tracking Gateway Network Centric Capability Pattern€¦ · 3/3/2010 · Resource Tracking Gateway, Asset Tracking Gateway, Friendly Force Tracking (FFT), Blue Force Tracking

SF FT/C3 Interoperability IPT

Land Force Tracking Gateway

Network Centric Capability Pattern

Approved for Public Release Distribution Unlimited NCOIC-LandForcesTrackingGateway20100303v3.0

Version 3.0

Page 1 / 24

Command Control Communications Interoperability IPT

Land Force Tracking Gateway Network Centric Capability Pattern

Resource Tracking Gateway, Asset Tracking Gateway, Friendly Force Tracking (FFT),

Blue Force Tracking (BFT), NATO Friendly Forces Information, (NFFI), Civil Organizations Tracking Gateway, Geolocalization and Positioning Exchange Gateway

Jerome Huchard (EADS), Xavier Denis (EADS), Mikael Laby (EADS), Hans Polzer

(Lockeed Martin), Jean-Michel Negret (Thales)

Version 3.0 February 2010

Version History

Version Number

Description Author

2.0 Proposed for NCOIC Technical Council Formal Review Mikael Laby 3.0 Change Request and MarCom Review Implemented Changes Mikael Laby

Abstract

The Land Force Tracking Gateway Network Centric Capability Pattern provides guidance to industry on implementation of a gateway to achieve interoperability among disparate systems from civil or military organizations. It is intended for use in a ground context such as police, military, firefighters, non-governmental organizations (NGOs), and emergency responders who need to exchange localization information between or across systems and organizations. For the purpose of this document, the term “force” refers to a coherent set of individuals acting as a group for the purpose of an organization, as in a company’s “workforce” or a city’s “police force.”

Users of this pattern include the following: • Subject matter experts (SME) from organizations involved in homeland security, aviation,

medical, emergency response, NGOs (for example, Red Cross), and NATO. • System architects not directly involved in developing systems such as land force tracking

systems and command, control, and communication (C3) systems. This pattern serves as a key element for information sharing among multiple stakeholders and domains and as a good example of public awareness of a proven solution by using the public NCOIC Building Block Repository. This pattern complies with the NCOIC Interoperability Framework NIF™ Solution Description Reference Manual (NSD-RM).





Version 3.0

Page 2 / 24

Table of Contents 1 1 Description..............................................................................................................................3 2

1.1 Intent ............................................................................................................................... 3 3 1.2 Problem Statement and Context ..................................................................................... 4 4

1.2.1 Problem................................................................................................................... 4 5 1.2.2 Context.................................................................................................................... 5 6

1.3 Participants...................................................................................................................... 6 7 1.3.1 Actors...................................................................................................................... 6 8 1.3.2 Interfaces................................................................................................................. 6 9

1.4 Pre-Conditions ................................................................................................................ 7 10 1.5 Structure.......................................................................................................................... 8 11 1.6 Behavior.......................................................................................................................... 8 12

1.6.1 Operational Sequence ............................................................................................. 8 13 1.6.2 Collaboration ........................................................................................................ 10 14

1.7 Post-Conditions............................................................................................................. 10 15 1.7.1 Exchange With Peer Force Elements Across or Between Organizations) ........... 11 16 1.7.2 Exchange Between Nodes in a Single Organization ............................................ 11 17 1.7.3 Exchange With Peer Force Elements Within a Single Organization) .................. 11 18

2 Implementation ....................................................................................................................13 19 2.1 Expert Advice ............................................................................................................... 13 20

2.1.1 Lessons Learned ................................................................................................... 13 21 2.1.2 Constraints ............................................................................................................ 14 22

2.2 Flexibility...................................................................................................................... 15 23 2.3 Known Uses .................................................................................................................. 15 24 2.4 Related Patterns ............................................................................................................ 16 25 2.5 References..................................................................................................................... 17 26

3 Verification ...........................................................................................................................19 27 3.1 Conformance................................................................................................................. 19 28

3.1.1 Terminology of Shall, Should, May, and Can in This Document ........................ 19 29 3.1.2 Specific Acceptance Criteria ................................................................................ 19 30 3.1.3 [REF D-Document] Conformance........................................................................ 20 31 3.1.4 [REF Service Interoperability Protocol SIP3] Conformance ............................... 21 32

3.2 Verification ................................................................................................................... 21 33 4 Appendices............................................................................................................................21 34

4.1 [REF Service Interoperability Protocol SIP3] Expert Advice ...................................... 21 35 4.2 Acronym List ................................................................................................................ 23 36

37 List of Figures 38

Figure 1. Land Force Tracking Gateway Context ......................................................................... 5 39 Figure 2. Land Force Tracking Gateway Participants ................................................................... 6 40 Figure 3. Concepts Around Land Force Tracking Gateway.......................................................... 8 41 Figure 4. Land Force Tracking Gateway Pattern Operational Sequence....................................... 9 42 Figure 5. Force Tracking Gateways and System Connection...................................................... 10 43 Figure 6. Related NCOIC Patterns .............................................................................................. 16 44

45





Version 3.0

Page 3 / 24

1 Description

1.1 Intent The intent of the Land Force Tracking Gateway Pattern is to enable enhanced tracking of

entities engaged in a land single-service operation (i.e., police, firefighters) or multiservice operation (joint, cross-domain) context. For the purpose of this document, the term “force” refers to a coherent set of individuals acting as a group for the purpose of an organization. Implementation of the Land Force Tracking Gateway Pattern will simplify and improve the implementation of location tracking-based interoperability.

The Land Force Tracking Gateway Pattern and its implementation improves the interoperability among nation and organization land-oriented tracking capabilities by:

• Facilitating the reuse of components across different civil and military domains. • Improving return on investment through a better and more economical product/service. • Providing guidance on the implementation of such capabilities supporting existing force

tracking standards. • Enhancing the interoperability between tracking/situational awareness(SA) and with non-

tracking/SA capabilities in new and unanticipated interactions made possible by increased net-centricity. The Land Force Tracking Gateway Pattern replaces manual nonstructured information flows

(with inherent language and interpretation problems) with structured, formatted information flows.

The Land Force Tracking Gateway Pattern facilitates the establishment of a coherent land tracking capability across all levels of civil and military command, harmonizing national and organizational tracking contributions into a networked system of systems solution. This objective is accomplished by:

• Ensuring that tracking capabilities conform to a specified set of network-centric pattern guidelines so that criteria will be met to achieve interoperability and integration requirements.

• Providing management directives for implementation of tracking capabilities—complementing specific standards directives—to ensure the provision of adequate tracking information to decision support systems and decision-makers across various levels of national and organizational command or management levels.





Version 3.0

Page 4 / 24

1.2 Problem Statement and Context

1.2.1 Problem From an operational perspective, organizations need to rely on neighboring and adjacent

domain entities (police, firefighters etc.), to accomplish their missions and attain mutual Situational Awareness (SA). The expectations regarding tracking solutions are as follows: • Increased mutual support among joint and federation forces.

− Better awareness of available force elements. − Improved resource sharing among force element providers.

• Improved utilization of available force elements. − Better execution monitoring and replanning capability during operations. − Increased ability to operate in an “effects-based” operational paradigm.

• Quicker response to emerging operational situations and force element needs. • Response to emerging operational situations and force element needs. • Reduction or prevention of accidents, e.g.:

− Dropping of a fire retardant on firefighters. − “Friendly fire” or fratricide incidents.

• Increased willingness to rely on nonorganic support. • Improved logistics responsiveness and more efficient logistics operations.

From a system perspective, in such a federation environment, separate systems and respective system management are held at national contingent or organization levels, which are not prepared to exchange tracking information.

The general problem is to establish and/or enhance operational and system interoperability among multiple nations and/or organizations regarding tracking capabilities.

The specific problem for the Land Force Tracking Gateway Pattern is to simplify and improve the implementation of tracking-based interoperability.

The Land Force Tracking Gateway Pattern describes1 three interface profiles, two under a data push approach using TCP/IP (IP1) or UDP (IP2), and the other under a publish/subscribe approach using SOAP (IP3), based on the same Tracking Message Model, to establish near real-time forces Situation Awareness among different land forces and organizations in a federation, based on the following assumptions: • Each organization has a tracking capability, a means to communicate to the other systems

and entities, and a means to transfer available tracks to other systems and entities. • The organizations agree on a concept of operations (CONOPS) to share tracking information, • All organizations will establish an interconnection among their own networks.

1 See Section 1.5 Structure for detailed description.





Version 3.0

Page 5 / 24

1.2.2 Context Figure 1 synthesizes the key concepts discussed in this pattern in a land environment.

Figure 1. Land Force Tracking Gateway Context

(Source: Google Earth, with NCOIC markings)

The pattern becomes fully operational when all the entities have:

• A means to assess their position in the theaters of operations. • A common time reference. • A common spatial reference. • A means to communicate to the other entities. • A means to transfer position data to other entities with a need to know within time and

quality constraints dictated by the operations tempo (OPTEMPO) and characteristics (appropriate quality of service).

• A means to identify entities that is understandable to all the participants with respect to the significance of that entity and what its position information might imply (i.e., something more informative than entity “ID 72112”), and allows them to use that identity to obtain any other information about a specific entity that might be available to the participants—potentially from other systems/services to which they may have access.

• A means to possibly share “off-line” additional information on tracked entities (data augmentation), obtained by using and sharing unique identifiers.

This pattern has been used successfully in NATO coalition operations, but its usefulness is not limited to military operations. The pattern is relevant for mobile land-based entities in law enforcement and/or civil operations conducted in regional and local areas. It requires at least a national/organizational tracking capability within each nation/organization and IP connectivity.





Version 3.0

Page 6 / 24

1.3 Participants

1.3.1 Actors This pattern uses three roles: a sender, a receiver, and in some cases, gateways for security

purposes and mapping between different networks and two interaction modes push (or send/receive—IP1 and IP2) and publish/subscribe (IP3). The sender and the receiver are systems or subsystems within different operational entities. The sender and the receiver must belong to two or more different organizations implementing the tracking service with gateways. A third-party organization called the hub, implementing the tracking service, may be used as an intermediate. The Land Force Tracking Gateway participants are shown in Figure 2.

Figure 2. Land Force Tracking Gateway Participants

(Source: NCOIC-developed drawing)

NOTE: Major hub capabilities include the following:

• Avoid a loop in track forwarding. • Tracks buffering to cope with various input and output frequencies. • Multinational protocol adaptation. • Data augmentation. • Geographic filter. • Elimination of possibly duplicate tracks.

1.3.2 Interfaces The pattern allows the exchange of position information (also time and identity need to be

included as a minimum) between nations/organizations in a federation. The pattern relies on a data model (Tracking Message Definition) and three interface

profiles:

• IP1 two-way unicast reliable push (using TCP).





Version 3.0

Page 7 / 24

• IP2 one-way unreliable2 push (using UDP). • IP3 supports the provision of tracking data (in the XML message format) through a request-

response and publish-subscribe interaction (“smart-pull” functionality) (based on web services standards, see [REF Web Service]). It is well suited as an interface at the system-level service interoperability point (SIOP) between tracking systems/services and C2/SA systems/services. The IP1 profile is the mandatory profile, but for optimum interoperability, it is recommended

to implement all protocols.

1.4 Pre-Conditions Each organization has a tracking capability or obtains tracking information from an external

system, which collects and distributes position information according to preset rules and roles. Each organization subscribes and connects to a network, which in turn can exchange

information with the networks used by the other participants, as agreed to by all participants in the operation.

For specific network architecture, a configuration is required for both TCP/IP and UDP addressing. For the routing of messages, three different network setups with appropriate routing mechanisms are envisaged and shall be supported: • Routing between nodes within the same domain without diodes or guards between nodes. • Routing between nodes in different domains without diodes or guards between nodes. • Routing between nodes in different domains with diodes or guards between nodes using a

gateway and a mapping service. The protocols (IP1, IP2, and IP3) and the Tracking Message Model to be used should be

agreed to in the Service Level Agreement between organizations on an operational or individual mission basis.

Before deployment, the participants must agree on a CONOPS to solve all organizational, security, and technical issues outside the scope of this pattern. The following dimensions3 and corresponding questions must be addressed to support the CONOPS identification: • Force Joining Rules: What are the rules for an organization to join the federation? • Confidentiality and sensitivity rules

− Track Location Sensitivity: What levels of confidentiality are associated with different force types? Can specific recipients be released to or excluded?

− Restricted Areas: Is force location reporting sensitive to designated restricted areas? • Force Element and Track Types: What are the different types of force elements that could be

tracked? For example, satellites, submarines, consumer goods, NGOs, military entities, political representatives, bodyguards, etc.

• Track Types and Environment: What are the different types of locations over time that are to be captured and exchanged (i.e., tracks)? Underwater, air, space, ground, underground, etc.

2 “Unreliable” in a network concept means that data are not guaranteed in reception and even in quality. UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go mission without notice. In this particular case, the IP2 gateway takes care of the UDP packet reordering. While IP1 is more reliable than IP2, both are “fire and forget” protocols (i.e., no explicit receipt acknowledgment is included). 3 These dimensions are described in more detail as SCOPE Capability Domain Dimensions with some thresholds proposed in the [REF FFTI OD} document.





Version 3.0

Page 8 / 24

• Reporting Frequency and Latency: What range of reporting frequencies should be supported in a tracking interface? How current should the reported position be in tracking exchanges and should the exchange include an “as of” timestamp? See Section 3.5.

• Location Precision: What levels of precision and assurance are associated with force locations?

• Identity and Location Assurance: What measures are included for assuring the identity of a tracked force element and its reported location?

• Degrees of Mutual Interest: What degrees of common interest/goals, or willingness to support or collaborate toward achieving those goals, are required to be conveyed in force element tracking exchanges?

• Force Element Affiliation: How flexible is the force element affiliation representation (i.e., ownership or membership in one or more collective entities such as nationality, NGO, or social organization)?

• Representation Conventions: What standards/conventions are used for representing force element types, mutual interests, and affiliation over the network?

• Information Types Reported: What kind of additional information is reported/available from the tracking services?

• Tracking Purposes: What types of uses are the tracking service intended to support?

1.5 Structure Figure 3 illustrates the concepts around the Land Force Tracking Gateway.

Figure 3. Concepts Around Land Force Tracking Gateway


1.6 Behavior

1.6.1 Operational Sequence Figure 4 illustrates the tracking service behavior in an example of Land Force Tracking

Operational Sequence.

Land Force Tracking Gateway Pattern

FT System

Geospatial Reference

Tracking Messages

Network TCP/IP UDP

IP1 Protocol Interface

Profile


Profile

Relies on

defines

uses uses

Relies on

uses

XML

uses

Relies on CONOPS defines defines

Relies on

MIP/JC3IEDM MIP/ C2IEDM aDatP - 3 VMF LINK - 16

Studied mapping to


Profile

defines

Publish / Subscribe

SOAP

Legend : Dash Boxes are optional elements in the pattern

Land Force Tracking Gateway Pattern

FT System

Geospatial Reference

Messages

Network TCP/IP UDP


Profile


Profile

Relies on

defines

Relies on XML

uses

Relies on CONOPS defines defines

Relies on

MIP/JC3IEDM MIP/ C2IEDM aDatP - 3 VMF LINK - 16

Studied mapping to


Profile

defines

Publish / Subscribe

SOAP

Legend : Dash Boxes are optional elements in the pattern





Version 3.0

Page 9 / 24

Figure 4. Land Force Tracking Gateway Pattern Operational Sequence

(Source: NCOIC-developed drawing) In the context of a federation of organizations, working together in a disaster relief operation,

with firefighters (Organization D Red Cars), police (Organization A Grey Cars), border security (Organization C Blue, White, Green) and homeland security (Organization B):

Entity 6 uses the Tracking System C to exchange position information with other entities of Organization C such as Entity 4 and Entity 5.

The Tracking System C implements a tracking interface to exchange a given entity’s position with other tracking systems of other organizations (in Figure 4, Entity 3 of Organization D using Subsystem D). The Tracking System C plays the sender role and uses this interface to publish through the tracking networks.

Between Organization C and Organization B, there is a gateway between Organization B network and Organization C network for routing and filtering purposes.

Between Organization B and Organization A, there is a tracking gateway that transforms native tracking data into tracking messages.

Between Organization A and Organization D, there is a tracking gateway that transforms tracking messages into native tracking data..

The Tracking Subsystem A receives entity positions coming from the tracking networks and publishes them to designated entities such as Entity 1.

The Tracking Subsystem D plays the receiver role. The Tracking Subsystem D receives entity positions coming from the tracking networks and publishes them to its designated entities such as Entity 2 or Entity 3.

The Entity 3 receives Entity 4 position through its organizational Tracking Subsystem D. NOTE: IP1/IP2/IP3 is addressing system-to-system, not terminal-to-terminal, exchange:

IP1/IP2 only through agreed names and known IP addresses. IP3 also through DNS.





Version 3.0

Page 10 / 24

1.6.2 Collaboration The collaboration shall be between systems or subsystems. Tracking systems/services from

different suppliers or organizations/nations shall collaborate to provide a broad and persistent SA for all entities in the federation.

The pattern relies on a data subscribe and publish model to distribute position information about entities to other entities. The sender publishes information and the authorized receiver subscribes to it. The tracking gateway placed between the sender and the receiver is primarily used to identify the components that transform native tracking data of a system/service into tracking messages (and vice-versa). Then filtering capabilities could be added in the gateway, especially in the IP3 publish/subscribe solution such as geographic filter, redundancy filter, entity-level filter, history depth filter, and frequency filter. Finally, the tracking gateway can be placed at the boundary between two security domains, one containing data of different sensitivity levels and labeling or access control requirements from the other. (See SFIEG Pattern, Section 4.3.)

If two systems want to exchange information, each system involved shall build a Force Tracking Gateway following this pattern (see Figure 5).

Figure 5. Force Tracking Gateways and System Connection


Both gateways shall have a TCP exchange IP1 interface profile and thus be interoperable (see Section 3.4.1 Interfaces). • If both have built an IP2 interface profile, they can also use UDP exchange (IP2). • If only one has built an IP2 interface profile, they shall use only IP1 with TCP. • If only one has built an IP3 interface profile, it may use the IP3 as a consumer front end when

the producer is provided information with IP1 or IP2 (i.e., IP1/IP2 input - > IP3 query -> IP1/IP2 output).

Moreover, both tracking gateways need to be switched on to allow exchange between them, but one system connected/subscribing to its gateway can still receive data and be notified asynchronously, without having the other source tracking gateway connected, even in IP1.

Tracking Gateway A must never resend to System B tracks already received from System B in order to maximize the efficiency of the collaboration.

In the case where connectivity between A and B is established through a hub (see details in Section 3.1 Participants), the hub is positioned between the two gateways.

1.7 Post-Conditions The NCOIC C3 Interoperability IPT has developed an analysis called Friendly Force

Tracking Interoperability Operational Description (FFTI OD) [REF FFTI OD], which identifies generic and ideal capabilities as well as problems, adjacent domain objectives, scenarios, standards of interest, etc. This document [REF FFTI OD] can be used to place this pattern and any developments/implementation of this pattern into a wider context. This document contains 44 capabilities. The purpose of this section is to extract the relevant capabilities of the [REF





Version 3.0

Page 11 / 24

FFTI OD] to see how they could map to this pattern. The interest of this work is to provide a baseline to compare further patterns on this topic and to highlight the gaps between current pattern capability and one ideal; in other words, what it does and does not accomplish.

The following capabilities are extracted from the [REF FFTI OD] document. They are supported by this pattern at three different levels: strongly supported (3), generally supported (2), partially supported (1). The weighting rational explains to what extent and how this pattern supports this capability.

1.7.1 Exchange With Peer Force Elements Across or Between Organizations)

The following Capability C1 is strongly supported (3): − “Exchange this data with peer force elements in the same area, but belonging to different

‘system’ or ‘organization’ (i.e., across or between organizations), via interaction between higher level command chain systems (i.e., not directly between peer elements belonging to different command chains).”

The rational for such weighting is as follows: − This pattern proposes a clear solution to share force tracks between and across

organizations.

1.7.2 Exchange Between Nodes in a Single Organization The following Capability C2 is generally supported (2): − “Consider Force and Tracking system nodes within a single organization with

o Command/collection centers enabling control and filtering, dissemination, and aggregation of the ‘overall’ force tracking picture.

o Mobile terminal devices. o Communication entities enabling line of sight and/or beyond line of sight secure

exchange of tracks and able to operate while moving.” The rational for such weighting is as follows: − This pattern could be used within a single organization between different Operation

Centers when using in particular the IP3 mode4 and the Tracking Message Model5, but it is not the first intent.

1.7.3 Exchange With Peer Force Elements Within a Single Organization) The following Capability C3 is partially supported (1): − “Exchange the following data with peer force elements in the same area and command

chain (i.e., within a single organization): o Position of the tracked entity or action area of the tracked entity. o Identity of the tracked entity. o Date/time of the information sent by the tracked entity. o Free textual message. o Health status of the tracked entity as individual.”

The rational for such weighting is as follows:

4 See Section 1.5 Structure for detailed description. 5 See Section 1.5 Structure for detailed description.





Version 3.0

Page 12 / 24

− The content of the exchange (C3) is less supported in this pattern than the exchange topology (C1). The actual data described in the Tracking Message can be different in each system. The gateway will then have to provide an XML mapping capability from one model to another [REF XML]. For example, in NATO context, the two last bullets (free text message and health status) are not strictly part of the Tracking Message definition (see [REF D-Document]). Depending on the needs, attributes such as operational status, position uncertainty, and the source of the track description could be added.

To conclude, an important distinction between C1 and C3 is that in this case (C3), the organizations, systems, and development governance are often the same. This implies the possibility of having the same system, highly interoperable systems components, and lower (or absent) security boundaries having quite simple (or absent) interoperability problems.





Version 3.0

Page 13 / 24

2 Implementation

2.1 Expert Advice

2.1.1 Lessons Learned • The Land Force Tracking Gateway Pattern addresses tracking services interoperability at

information/application level. • It requires underlying communication infrastructure between systems to be interoperable. • IP1/IP2/IP3 requires IP communication services for data transport. It is not currently defined

to use specific (i.e., non-IP) tactical (radio) data communication services. • The SIOP where the tracking gateway is set up constitutes a security boundary, where

appropriate security guarding mechanisms (e.g., outbound distribution filters and inbound protection measures) have to be implemented.

2.1.1.1 Data Management The pattern assumes that all systems within the tracking network implement the same kind of

tracking system/service (e.g., land tracking, air tracking, land and air tracking, maritime tracking, etc.). Indeed, as the tracking gateway in the “push mode” (IP1) does not allow queries to filter incoming data, a tracking system may be overwhelmed by another tracking system through the tracking gateway (e.g., a land tracking system used to update hundreds of tracks every minute receiving data from an air tracking system used to update thousands of tracks every second). The receiver is responsible for implementing data management procedures to prevent/mitigate impact to system operations. Operational procedures and business rules are needed as part of the implementation to prevent track flooding. Implementation of a “smart pull” mode as specified by IP3 also can overcome this limitation.

2.1.1.2 GeoReferences If any of the participants uses a different coordinate system, there will be no chance to figure

out whether two entities will share the same space. In fact, several nations/organizations usually do not share their reference systems because of security issues.

In a federation environment, a net centric approach would either specify a priori that all systems use the same reference model as recommended in section Error! Reference source not found. Error! Reference source not found., or else allow/require that participating systems discover and negotiate which reference system each is using. This may be handled by the gateways used by the participants by providing a protocol for discovering and negotiating which coordinate system is being used by each participant. However, this suggested approach might not be feasible since conversion algorithms between different datums might not be available to all participants (e.g. specific country data).

WGS84 [REF WGS84] is the recommended reference system, which is applied when the global positioning system (GPS) is used. Various national datum (such as WGS84 [REF WGS84]) normally can be converted from one to another. The possible accuracy loss may be indicated by the converting gateway, usually on the order of 10-100 meters. Such accuracy normally is adequate for land tracking purposes.





Version 3.0

Page 14 / 24

2.1.1.3 Land, Air, Maritime Context The scope of the pattern is primarily land, as seen in the title of the pattern; however, the

rationale behind this choice is: what makes the Land Force Tracking Gateway not applicable to the air and maritime domains?

First, in the three domains, there are two major descriptive dimensions (see Section 3.2 Pre-Conditions), which have different thresholds depending on the domain: • Time dimension: Air tracks updates are required at the second level while land tracks

typically are adequately represented at the level of minutes, due to their much lower average velocities.

• Tracks number: the number of tracks to be managed by the system involved is not the same in air, maritime, and land domains. Track density (tracks per unit area or volume) is actually higher on land. On the other hand, air tracks usually are managed over a much larger volume/area than land tracks typically are. That may result in more air tracks in any one tracking system than typically occurs in a land tracking system. The more significant issue is that of air tracks having a more important third dimension (altitude)—something not usually recorded for land tracks, and not being stationary for any length of time, for the most part. The only way for an airplane to become stationary is for it to become a land track, helicopters aside. A truck can be stationary indefinitely—the only air track that can do that is an aerostat or similar platform. For maritime tracks, the major difference is the high level of containerization and the long distances involved (as well as less constrained by terrain other than land—also true of air tracks).

Second, the legacy standards in these domains may imply a need for mappings (Link 16, Automatic Identification System [AIS]).

From a protocol perspective, nothing prevents such other domains from using the IP1, IP2, and IP3 protocols and message model. It is a question of implementation to provide a technical infrastructure addressing their respective domain-dependent dimension values and also legacy standards mapping issues.

From a purely technical perspective, this pattern is adequate for maritime tracking and also very likely for air tracking (air tracking meaning the tracking of air platforms from a force management perspective—vice an engagement perspective).

But the “ownership” and championship of IP1, IP2, and IP3 has come from the land domain. This implies, since all known capability definition and experimentation has been land-driven, that NCOIC cannot ensure with a satisfying degree of validation that it could work for air and maritime tracking. Therefore, the decision of leaving this pattern only to the land domain is very sound.

2.1.2 Constraints The following constraints drive the design of the pattern: information sharing in a federation

environment and individual participant force tracking system/service optimization of bandwidth usage.

In a federation environment, each organization wants to control the distribution of information regarding the position of its own entities to protect its entities from adverse effects due to actions by another organization (e.g., competing truck delivery routes). The Force Tracking Gateway defines a checkpoint or outbound filter to control the distribution of position





Version 3.0

Page 15 / 24

information among tracking systems/services. This checkpoint is made unnecessary where there exists complete trust among the organizations in the federation.

A tracking service relies on finely tuned communications designed to collect and distribute entity position information. This usually means a tightly interwoven connection between information systems and telecommunications capabilities. For example, the use of a specific radio application program interface (API) to collect information on many entity positions quickly, or the use of a specific radio API to disseminate position information to a wide range of entities. The challenge is to facilitate effectively information exchange for two or more tracking systems/services using different means of telecommunications and different APIs. The recommended interoperability approach consists then in the definition of information/service interfaces at the application level, which can be based on different data transport layers. The Force Tracking Gateway is unnecessary if every entity in the federation uses the same tracking system/service and uses the same entity identification name space that includes all the entities of all participants using the tracking system. In addition, the tracking system/service used must support multiple national affiliations and support the Land Force Tracking Gateway pattern if participating entities are not all on the same network.

It is important to note that this pattern assumes the use of IP networks with sufficient bandwidth to accommodate the CONOPS information exchange requirement (see Section 3.2 Pre-Conditions).

2.2 Flexibility Implementation of this pattern focuses on the development of a Land Force Tracking service

set that implements the IP(N) profiles, which can be used as an add-on to military or civilian C2 systems or on any system that supports Land Force Tracking services.

The actual data described in the tracking message can be different in each system. The gateway should provide an XML mapping capability from one model to another.

At a minimum, IP1 is required. IP2 and IP3 are optional and can add additional capability as specified in the pattern.

As an option, the interoperability profiles can be implemented using the following guidelines: NFFI-IP1 (IP1) and NFFI-IP2 (IP2) of the [REF D-Document], and Service Interoperability Protocol (IP3) of the [REF Service Interoperability Protocol SIP3]

2.3 Known Uses There are at least 18 systems of many nations/industries that have implemented the protocols

referenced in this pattern (see [REF D-Document] and [REF Service Interoperability Protocol SIP3]).





Version 3.0

Page 16 / 24

2.4 Related Patterns The following existing and candidate patterns are described in Figure 6.

Figure 6. Related NCOIC Patterns


This pattern relies on an XML message format, and mapping between different information models and message format may be needed. Some mappings were studied with other message format standards in NATO in particular and could be of interest (see Figure 3):

• Command and Control Information Exchange Data Model (C2IEDM), by the Multilateral Interoperability Program (MIP) (see [REF MNIS]).

• Joint Consultation, Command and Control Information Exchange Data Model (JC3IEDM), by the Multilateral Interoperability Program (MIP): analysis, specified and experimented in 2008-2009 (see [REF MNIS]). JC3IEDM is an evolution of the C2IEDM standard.

• Allied Data Publication No 3 (AdatP-3): AdatP-3 OWNSITREP (analyzed in 2006), ADatP-3 New possible Message Text Format (MTF) (analyzed in 2009).

• Variable Message Format (VMF). • Link 16.

Such mappings are not addressed in this pattern, but should be addressed in the “parent” candidate pattern Resource Tracking Information Model Pattern, where a mapping and common information model would be discussed.

This pattern does not address communication issues since this should be discussed in the related “parent” candidate pattern Resource Tracking Communication Pattern.

This pattern does not address security issues since this should be discussed in the related “parent” candidate pattern Resource Tracking Security Pattern.

The International Rescue Beacon System is also a candidate pattern that may be used by forces to find and recover entities in a theater of operation, especially when operating in a





Version 3.0

Page 17 / 24

disaster relief role. In a similar way, other candidate patterns could be developed around AIS (see [REF AIS]) in the maritime domain, around radio frequency identification (RFID) in logistics, and around cell-phone based force tracking capabilities in the civil telecommunication domain.

The NCOIC Resource Tracking Information Exchange (RTIE) Capability Pattern is recommended to build open and evolving resource information exchange architectures. The Land Force Tracking Gateway Pattern can be used to refine the gateway element defined in the RTIE Pattern.

The Land Force Tracking Gateway may relate to the NCOIC Core Network Access (CNA) Pattern for the correct use of the underlying IP network to facilitate exchange between force elements that use different access networks to collect location information.

The Land Force Tracking Gateway may relate to the NCOIC Secure Formatted Information Exchange Gateway (SFIEG) Pattern for the management of different sensitivity levels for the information to be exchanged between two different access networks.

The Land Force Tracking Gateway may relate to the communications network and in particular to the exchange of information between different types of mobile tactical networks (Space Air Ground Maritime Mobility Network [SAGM MN] Pattern).

2.5 References These references are offered as optional supporting documents 1. [REF D-Document]: This document describes in detail the IP1 and IP2 protocols used in the

NATO Context and known as NFFI-IP1 and NFFI-IP2 under the following NATO reference: AC/322(SC/5)N(2006)0025 “Interim NFFI Standard for Interoperability of FTS.” This is often referred as “NATO NFFI D-Document” (or NFFI D-doc). NFFI stands for NATO Friendly Force Information. This document is available only to NATO and Partnership For Peace (PFP) nations. This document is not mandatory for conformance to this pattern (see Section 5.1.3 [REF D-Document] conformance).

2. [REF STANAG 5527]: The full description of the draft standard is available in the document STANAG 5527 Study Draft 1, version 1.1, 21 September 2006. This document contains the NFFI Interim Standard Information. STANAG 5527 has not yet been ratified by NATO. This document is available for NCOIC internal use only per the NATO release agreement of 3 July 2008, and can be requested through the NCOIC C3 Interoperability IPT chair. This document is not mandatory for conformance to this pattern.

3. [REF Service Interoperability Protocol SIP3]: This document describes in detail the IP3 protocols used in the NATO Context and known as SIP3 under the following NATO reference: NC3A Working Paper EPW002038-04 on “FFI Service Interoperability Profile 3 (SIP3) General Description (version 1.0.0)” and NC3A Working Paper EPW002038-05 on “NFFI Service Interoperability Profile 3 (SIP3) Technical Specifications (version 1.0.0).” This document is available only to NATO and PFP nations. This document is not mandatory for conformance to this pattern (see Section 5.1.4 [REF Service Interoperability Protocol SIP3] conformance).

4. [REF WGS84]: WGS84 is a DoD standard also adopted by NATO for the reference spheroid for the Earth that many modern maps are based on. GPS uses the WGS84 standard





Version 3.0

Page 18 / 24

for representing latitude, longitude, and altitude above the center of the Earth. It is also called Mil-Std-2401. This document is publicly available.

5. [REF FFTI OD]: The NCOIC FFTI Operational Description V0.8 document is an NCOIC internal working document that was used as a basis for identifying Friendly Force Tracking (FFT) Patterns. It identifies the context of use of FFT, the adjacent domains and different objectives, some scenarios of use, architecture concepts, the capabilities expected and the related problems, and the candidate standards. It can be retrieved by NCOIC members under the NCOIC C3 Interoperability IPT folder or upon request to the NCOIC.

6. [REF MNIS]: MIP-NFFI Interoperability Specification (MNIS) (v1. or most recent version) describes how to make a Multilateral Interoperability Program (MIP) system interoperable with a Force Tracker using NFFI. The NATO-MIP-WG – “MIP-NFFI Interoperability Specification” (MNIS v1) (15 December 2009), is expected to be proposed for standardization in early 2010 by the NATO FFT AHWG. This document is available only to NATO and PFP nations.

7. [REF XML]: Extensible Markup Language (XML) is a set of rules for encoding documents electronically. It is defined in the XML 1.0 and higher version specification produced by the W3C and several other related specifications; all are fee-free open standards. “Extensible Markup Language (XML) 1.1 (Second Edition) – Rationale and list of changes for XML 1.1.” W3C: http://www.w3.org/TR/xml11/#sec-xml11.

8. [REF SOAP]: SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of web services in computer networks. It relies on XML as its message format, and usually relies on other Application Layer protocols (most notably Remote Procedure Call (RPC) and HTTP) for message negotiation and transmission. SOAP can form the foundation layer of a web services protocol stack, providing a basic messaging framework upon which web services can be built.

9. [REF Web Service]: A web service is traditionally defined by the W3C as “a software system designed to support interoperable machine-to-machine interaction over a network.” It has an interface described in a machine-processable format (specifically Web Services Description Language [WSDL]). Other systems interact with the web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other web-related standards.

10. [REF AIS]: The AIS is a short-range coastal tracking public standard used on ships and by Vessel Traffic Services (VTS) for identifying and locating vessels by electronically exchanging data with other nearby ships and VTS stations. Information such as unique identification, position, course, and speed can be displayed on a screen or an Electronic Chart Display and Information System (ECDIS).





Version 3.0

Page 19 / 24

3 Verification

3.1 Conformance To determine compliance with this pattern, service providers must demonstrate conformance

to all of the mandatory requirements specified in the previous Section 1 Description, based on the terminology defined in the following and in the specific acceptance criteria defined by the NCOIC. Partial conformance can be allowed if a provider claims to be conformant, but does not demonstrate conformance according to the NCOIC process.

3.1.1 Terminology of Shall, Should, May, and Can in This Document This definition is completely borrowed without changes from the IEEE standard

http://standards.ieee.org/guides/style/section5.html. The word shall is used to indicate mandatory requirements strictly to be followed in order to

conform to the standard and from which no deviation is permitted (shall equals is required to). The use of the word must is deprecated and shall not be used when stating mandatory requirements; must is used only to describe unavoidable situations. The use of the word will is deprecated and shall not be used when stating mandatory requirements; will is only used in statements of fact.

The word should is used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred, but not necessarily required; or that (in the negative form) a certain course of action is deprecated, but not prohibited (should equals is recommended that).

The word may is used to indicate a course of action permissible within the limits of the standard (may equals is permitted to).

The word can is used for statements of possibility and capability, whether material, physical, or causal (can equals is able to).

A corresponding proscriptive language is then used to state the conformance type in the text: mandatory [SHALL], recommended [SHOULD], and which are optional [MAY] to be considered conformant.

3.1.2 Specific Acceptance Criteria The mandatory acceptance criteria to demonstrate that a building block follows the pattern

are as follows: • Use of underlying IP network (TCP profile). • Implementation of IP1. • Implementation of Tracking Messages.

The recommended acceptance criteria to demonstrate that a building block follows the pattern are as follows:

• Use of underlying IP network (UDP profile). • Implementation of IP2.

The optional acceptance criteria to demonstrate that a building block follows the pattern are as follows:





Version 3.0

Page 20 / 24

• Implementation of IP3. The following acceptance criteria are also described, with some limitations, when relevant:

3.1.2.1 Net-Centric Information Assurance Criteria It is required that data in a classified environment be marked for security classification

according to rules being expressed in a security policy valid for the environment in which the data are processed. For that reason the pattern does not specify the way a security requirement shall be met. Nevertheless, security markings are introduced as attributes in the [REF D-Document]. The security marking has not been tested sufficiently and the acceptability of the definition is not fully confirmed. Despite the success of the tests already conducted, more analysis of the marking definition and more experimentation are necessary.

Availability, integrity, authentication, confidentiality, nonrepudiation, and security-management are outside the scope of the pattern. The pattern relies on external mechanisms to enforce the information assurance.

3.1.2.2 Net-Centric Service Criteria This pattern recommends the use of Service-Oriented Architecture (SOA) principles (IP3),

but due to near real-time constraint, the protocols used are only TCP (IP1) or UDP (IP2). Note that service orientation does not necessarily imply use of web services or SOAP. For example, the DNS protocol uses TCP, but is a service (what the “S” stands for in DNS). Concepts of discovery and negotiation can still apply in near real-time contexts, but may require time-definite constraints. Common examples in use today are support for roaming in cell-phone networks.

3.1.2.3 Net-Centric Data Criteria The message format recommended by the pattern shall be an XML Schema and may be

based on an existing data model used by many Force Tracking Systems such as NFFI message XML (also named “NFFI Data Exchange Format [DEF]”). See [REF D-Document].

The geocoordinate reference system recommended is WGS84 [REF WGS84].

3.1.2.4 Net-Centric Transport Criteria This pattern shall rely on TCP or UDP over IP for IP1, IP2, and IP3. IP3 is based on SOAP,

which can also use other transport protocols.

3.1.2.5 Net-Centric Management Criteria The pattern does not define the organizational rules of the information published using this

pattern. Those must be defined by each federation and each nation/organization.

3.1.3 [REF D-Document] Conformance This [REF D-Document] constitutes the NFFI Standard for Interoperability of Friendly

Tracking System. It provides the technical specification of the NATO Friendly Force Information (NFFI) message definition and interface protocol, which relates to the Tracking Messages, IP1, and IP2 protocols described in this pattern.

The [REF D-Document] includes both recommendations (where the verb “should” is used) and specifications (where the verb “shall” is used).





Version 3.0

Page 21 / 24

The conformance to the [REF D-Document] is recommended, but not mandatory, to foster interoperability of systems and NCOIC Building Blocks and ease the implementation of Tracking Messages, IP1, and IP2 protocols.

Note: The document [REF STANAG 5527] can be used in place of the [REF D-Document].

3.1.4 [REF Service Interoperability Protocol SIP3] Conformance The [REF Service Interoperability Protocol SIP3] document provides the technical

specification of the SIP3 definition and interface protocol, which relates to the IP3 protocol described in this pattern.

Conformance to the [REF Service Interoperability Protocol SIP3] document is recommended, but not mandatory, to foster interoperability of systems and NCOIC Building Blocks and ease the implementation of IP3 protocols.

3.2 Verification One of the following approaches must be used as a way of indicating conformance to

specifications (in order of increasing strength):

1. A certificate under the hand of a responsible officer of the certifying organization that claims conformance for all requirements (as a whole).

2. A certificate under the hand of a responsible officer of the certifying organization that it has validated conformance with each requirement.

3. Objective evidence that confirms that the certifying organization has validated conformance with each requirement. This may be a freeform report or preferably one in the approved NCOIC format.

4. A test specification describing how conformance will be tested for each specified behavior.

5. A full and approved Verification and Validation Program involving tracing of requirements from inception to delivery through, design, manufacture, and testing

6. Three options for verification against other reference implementations plus options 1, 2, or 3 above: • Test with a previously certified Building Block. In this case, the previously certified

Building Block provider will provide the report of success. • Test with a former successful Coalition Warrior Interoperability Demonstration

(CWID) participant and receive a report of success from the CWID participant. • Test during CWID under the FFTI domain and provide the CWID report indicating

success.

4 Appendices

4.1 [REF Service Interoperability Protocol SIP3] Expert Advice This appendix describes what can be expected from SIP3 at the current stage of development.

SIP3 can be used to interconnect two force tracking systems with publish/subscribe functions.





Version 3.0

Page 22 / 24

A stable experimental specification of SIP3 (v 1.0) [REF Service Interoperability Protocol SIP3] has been defined and was tested in Coalition Warrior Interoperability Demonstration in 2009 (CWID09). SIP3 has not yet been standardized: • SIP3 provides store-and-forward, “subscribe-only” model of collaboration. • The publication part has not been included to keep it simple while being adequate to work

with IP1 and IP2. • The NFFI SIP3 Gateway provides an interface to an FFT server that already has FFT data

(e.g., received through IP1 or IP2). The publication part is not addressed in the profile specifications.

• The subscription part implements a WS-Eventing profile that delivers NFFI (XML) data. • A Request-and-Response functionality is also supported by SIP3. • For FFT-MIP Interoperability, it is recommended to follow the [REF MNIS]. The

Identification Association Management - Subordination Query Management service (IDAM-SQM) can be used to get the look-up between identifiers when using IP3 (NFFI track-id vs. MIP Block 3 keys). IDAM-SQM are purely experimental services that might not be standardized.





Version 3.0

Page 23 / 24

4.2 Acronym List AHWG Ad-Hoc Working Group AIS Automatic Identification System API Application Program Interface BB Building Block BFT Blue Force Tracking C2IEDM Command and Control Information Exchange Data Model CNA Core Network Access CONOPS Concept of Operations CWID Coalition Warrior Interoperability Demonstration DEF Data Exchange Format DoD Department of Defense ECDIS Electronic Chart Display and Information System FFI Friendly Force Information FFT Friendly Force Tracking FFTI Friendly Force Tracking Interoperability GPS Global Positioning System HTTP Hypertext Transfer Protocol IDAM-SQM Identification Association Management Subordination Query Management

(service) IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol IPT Integrated Product Team JC3IEDM Joint Consultation, Command and Control Information Exchange Data Model MIP Multilateral Interoperability Program MN Mobile Networking MNIS MIP-NFFI Interoperability Specification MTF Message Text Format NATO North-Atlantic Treaty Organization NC3A NATO C3 Agency NCOIC Network-Centric Operations Industry Consortium NFFI NATO Friendly Force Information NGO Non-government Organization NIF NCOIC Interoperability Framework NSD-RM NCOIC Interoperability Framework (NIF)Solution Description Reference

Manual OD Operational Description OPTEMPO Operations Tempo OWNSITREP Own Situation Report PFP Partnership for Peace RFID Radio Frequency Identification RPC Remote Procedure Call RTIE Resource Tracking Information Exchange SA Situational Awareness





Version 3.0

Page 24 / 24

SAGM Space, Air, Ground, and Maritime SCOPE Systems, Capabilities, Operations, Programs, and Enterprises SFIEG Secure Formatted Information Exchange Gateway SIOP Service Interoperability Point SIP Service Interoperability Protocol SME Subject Matter Expert SOA Service-Oriented Architecture SOAP Simple Object Access Protocol STANAG Standardization Agreement TCP Transmission Control Protocol UDP User Datagram Protocol VMF Variable Message Format VTS Vessel Traffic Services WSDL Web Services Description Language XML Extensible Mark-up Language

Documents

Land Force Tracking Gateway Network Centric Capability Pattern€¦ · 3/3/2010 · Resource Tracking Gateway, Asset Tracking Gateway, Friendly Force Tracking (FFT), Blue Force Tracking