454. Based on this analysis, it was determined that the relevant IESs were STANAG 5500 (ADatP-3 XML-MTF format), STANAG 7149 (NATO Message Catalogue APP-11), STANAG 2183 (AAITP-6) and STANAG 2185 (AAITP-4).

455. In particular, it was determined that the structure of messages and the data elements contained within them were to be specified according to STANAG 5500 ADatP-3 following the XML-MTF format, and to be included within the STANAG 7149 Allied Procedural Publication 11 (APP-11), NATO Message Catalogue. The ASTWG developed the corresponding AST-XML-MTF message set, and are to be published later in 2012 with a new edition of APP-11.

456. The STF layers were applied to evolve the AAITP-6 and AAITP-4 specifications to ensure that the data bearing, routing and business rules layers were also covered. In particular, standards for the routing and means of bearing the actual messages appear in AAITP-6 (STANAG 2183) and the business rules are captured in AAITP-4 (STANAG-2185).

457. The Table captures this mapping to illustrate which layers of the STF are covered by which IES specifications.

458.

459.

460. As highlighted in the table, comparative analysis between the STF Layers and the Asset Tracking information exchange requirements highlighted the lack or incomplete definition related to the following:

461. The V&V of the STF Layers as applied to the AST COI did show that the layers provided the necessary components to analyze the information exchange requirements for Asset Tracking messages, and helped to identify gaps in the existing specifications to support that information exchange.

462. The V&V of the STF design rules, XML artefacts and methodology showed that it was able to be applied in the development of two new information exchange STANAGs (2183 and 2185) in support of supporting the Asset Tracking information exchange requirements.

463. Currently, the AST-XML-MTF messages and data elements have been captured in XML in-line with the STANAG 5500 XML-MTF Schemas, but not in-line with the STF XML Schemas. The capture of XML-based DED and MS are out-of-scope of STF Version 1.0, but the need for this has already been identified and captured within the STF Design Rules. It is envisioned that this will be provided in STF Version 2.0.

465. In the initial analysis of FFT information exchange, it was determined that the only specification available at the time was the NFFI "D" Document. This document was a C3B "Decision" Document that is meant to capture the NFFI format, which is the basic message format used to support FFT.

466.

467.

468. STF Conclusion: NFFI

469. A comparative analysis between the STF Layers and the NFFI "D" Document highlighted the lack of specifications related to the:

470. These gaps were brought to the attention of the Stakeholders. It was eventually decided to not use the NFFI "D" Document for the message definitions, but rather move along a different path and to align with the XML-MTF format, as agreed in STANAG 5500. Also, it was decided to develop a new STANAG, STANAG 5527, in-line with the STF so that the gaps could be filled.

471. Based on the decisions based on the STF Conclusions of Phase 1, in Phase 2 NATO began to capture the FFT-related messages in-line with STANAG 5500, with these new messages to be made available in the APP-11 NATO Message Catalogue. Effort was also undertaken to use the STF layered framework as a basis for developing the specification to support the FFT information exchange in STANAG 5527, where the specification for each layer is captured in different sections on the STANAG.

472. The V&V of the STF layers did show that the layers provided the necessary components to analyze the information exchange requirements for FFT, and helped to identify gaps in the existing specifications to support that information exchange.

473. The V&V of the STF design rules, XML artefacts and methodology showed that it was able to be applied in the development of a new information exchange STANAG 5527 in support of supporting the FFT information exchange requirements.

474. Overall, the V&V of the STF showed that

477. GMTI is used within the JISR community to detect and report on ground moving targets in support of the NOV-3 Operational Information Requirement to exchange Moving Target Indicator Exploitation Reports (IP660).

478. At the time of the analysis, the relevant documents to specify the information exchange of GMTI were the NATO Ground Moving Target Indicator Format (STANAG 4607), NATO STANAG 4607 Implementation Guide (AEDP-7) and the MAJIIC2 STANAG 4607 Implementation Guides (MAJIIC2 IG)

483. With MI, the relevant standard is STANAG 4609, which is aimed at promoting interoperability of present and future motion imagery systems within and among NATO nations. Similar to GMTI, MI system implementers have to rely on various implementation guides, the NATO Motion Imagery (MI) STANAG 4609 Implementation Guide (AEDP-8) and the MAJIIC2 STANG 4609 Implementation Guides, in particular, in order to achieve interoperable implementations. There is also a MAJIIC2 Business Rules document available that provides details on motion imagery information exchange interaction requirements, especially with respect on how to utilize the Coalition Shared Data servers.

484. In general, digital MI is composed of two major components, the Data Stream; and the Format. The Data Stream may actually be a set of "elementary" streams such as video, audio, metadata, and subtitles. Each stream type is processed by a specific encoder/decoder (CODEC). The Format is the protocol for transporting the streams through networks or in files. In STANAG-4609, formats available for MPEG2 are Elementary Stream (ES), Program Stream (PS), and Transport Stream (TS). PS and TS formats are capable of carrying multiple synchronized streams.

485. We have mapped the content of those implementation guides to the STF horizontal layers in the table below.

489. The work of the TDLXMLS focused on STANAG 5516, and in particular Edition 6, while keeping the generic aspect into account when applying the methodology on the other STANAGs.

490. The STF was applied to capture the following aspects of the information exchanges:

491. Results have been achieved so far for the Data Element Dictionary and Message Structure with on-going effort to capture the TDL Processing in the form of the Transactions as defined by STANAG 5516 Ed6. The structure of these Transactions offer a generic approach to model the overall message exchange between systems which is believed to be applicable to other information exchanges as well.

492. To fulfill the STF Operational Cross-COI layer, the Data Forwarding as defined in STANAG 5616 between Link 11/11B and Link-16 Systems is used. This is on-going effort and will also result in feedback to the STF.

493. The STF Data Bearer and Routing layers are, for Link 16, addressed in several ways. Traditionally, Link-16 uses radio frequency (RF) to exchange its J-messages within line-of-sight, although emerging technologies, such as IP and UHF SATCOM, provide the means to pass Link 16 data over long-haul protocols beyond line-of-sight. The traditional RF mechanism is defined in the MIDS standard while the JREAP (Joint Range Extension Application Protocol) standard (STANAG 5518) governs the IP and SATCOM transport. In particular, the JREAP standard defines its own message set and data elements to define the transport level protocol for the exchange of Link 16 J-messages. The JREAP messages and data elements are captured via the STF XML Schemas as well, requiring additional support in the XML Schema to indicate the nesting of Link 16 messages withing the JREAP messages. This enhancement will be retrofitted in the STF XML Schema in version 2. Worthwhile to note is that some of the Link 16 Data Elements are reused within the JREAP DED. Capturing the specific business rules of JREAP is a further action which have to support and tie in with the overall Link 16 business rules.

494. Additionally, the Link-16 Implementation Requirements have been captured in XML with a corresponding XML Schema which will need to be retrofitted in the STF as currently no generic STF XML Schema is provided yet.

496. Link 22 is being developed by the NATO Improved Link Eleven (NILE) Program. The goals of the development of Link 22 included the replacement of Link 11, complementing Link 16 and improvement of the Allied interoperability. As such, the Link 22 Data Elements and the Message Structure reuses many of the Link 16 ones contributing to increased standardisation and interoperability.

497. The Link 22 tactical messages and its data elements have been captured using the same XML Schemas as for Link 16. This provided the opportunity to perform an automatic comparision between the two resulting in a number of differences. Both the XML documents and the outcome of the comparison have been provided to the NILE community. Additional work on the messages and data elements used in the transport layer have been captured by NCI Agency-CapDev.

499. Link 1 is a point-to-point, duplex, non-encrypted, digital NATO Tactical Data Link (TDL) Standard for the automatic exchange of Track and Strobe data, combined with link and data management messages. It's governed by STANAG 5501 which mainly describes the various messages (S-series) and data elements. The S-series messages are bit-based, fixed length and can be easily captured in the STF XML Schemas. This has actually been done by NCI Agency to demonstrate the usage of the STF on other TDLs.

501. Variable Message Format (VMF) provides a message catalogue of K-series messages described in STANAG 5519 which is the covering STANAG (to be ratified) for MIL-STD 6017. Together with a header message (described in MIL-STD 2045-47001) and bearer (MIL-STD 188-220) it constitutes a tactical data link. From an STF perspective, this is an interesting format as it clearly separated the STF layers in different standards: one for the message catalogue (DED and Message Structure layers), one for the header (Routing layer) and one for the bearer (Bearer layer). Furthermore, by nature the messages or a variable length, requiring the STF XML Schemas to support also these types of messages.

502. Even though the current STF version 1.0 does not cater for variable length messages, some experimentation have been done by NCI Agency to extend the XML schemas in preparation of version 2.0. Initially, the various Data Elements of VMF have been captured which has shown to be possible and result in XML instance documents that could be used for documentation purposes and verifications. Because of the nature of the structure of VMF messages, the XML Schema will require extensions to allow for optional DataField and Group of DataFields, and for repetitions of a DataField and a Group of DataFields. This will be added, taking backwards compatibility into account, to the XML Schemas for STF version 2.0.

504. Over-the-horizon Targeting Gold (OTH-Gold) is a text-based message format, mainly used in the maritime domain. It provides for a message set similar in structure and syntax to ADatP-11 Message Text Format (MTF) messages, with slant-delimited fields making up line-based Sets that are grouped into Messages. It's governed by the "Operational Specification for Over-the-horizon Targeting Gold" published by USA Navy Center for Tactical Systems Interoperability.

505. The STF XML Schemas governing text-based information exchanges have been used to capture the Data Element Dictionary and Message Structure of OTH-Gold, although it's not a NATO STANAG. This demonstrated the following: