C2 Systems use of MTF and Messaging

C2 System Layering

The diagram above shows how a modern C2 system is typically layered. Notes on each of the layers:

• C2 systems are generally specific to nations. They provide an interface to operators and provide a UI for operator interaction.
• MTFs (Message Text Formats) provide the primary mechanism to communicate between C2 systems. NATOs APP-11 library provides a large set of messages making use of the NATO ADatP-3 format, which has text (MTF) and XML (XML-MTF) variants. There are also other formats used such as OTH-Gold and national variants. MTFs are sometimes supported as private national developments in support of C2 systems. Systematic provide a COTS solution (IRIS Forms) which is widely used and integrated into C2 systems.
• MTFs are transported by messaging protocols. There is a messaging format layer, which has three major formats used: ACP 127; STANAG 4406; SMTP with RFC 6477 military extensions.
• These messages are transferred by a wide range of underlying protocols.
  • ACP 127
    • Serial Line
    • Direct to Modem (e.g., broadcast)
    • COSS (HF – STANAG 5066)
  • STANAG 4406
    • Annex A (fast links)
    • Annex E (constrained links, including HF with STANAG 5066)
  • SMTP/RFC 6477
    • SMTP (fast links)
    • CFTP/HMTP (basic HF with STANAG 5066)
    • MULE (RFC 8494 – Modern HF with STANAG 5066)

Isode provides full COTS product support for the lower two layers. This paper looks at how these lower layers can be used to support the upper two layers.

Historical Note

MTFs are a very simple text format that evolved in parallel with ACP 127, initially starting as a set of human operator conventions for exchanging structured information. MTFs use the ITA2 character set, so they can work with any ACP 127 circuit.

Operators were trained to compose and read MTF formats, and so essentially MTFs were simply a part of the messaging system with C2 functions performed implicitly. This has evolved incrementally, so that in modern systems MTFs are usually communicated between C2 applications rather than between messaging operators.

Isode Approach to MTF & C2

Isode provides messaging and HF COTS components and solution for both of the messaging layers. Isode does not provide MTF and C2 products and has no plans to do so.

Isode aims to provide flexible support to those providing MTF and C2 components, so that it is straightforward to make use of Isode messaging components in conjunction with these systems. This paper looks at how this is achieved.

C2 Provider Requirements

Requirements here will generally be driven by the C2 provider, which will often be a specific national development. C2 vendors can take a number of approaches to providing the MTF layer, including:

• Making it a part of the C2 system, so that the national C2 system has an integrated MTF implementation.
• Use of a third party components, such as Systematic IRIS Forms, which is designed to integrate with C2 systems and provides flexible UI to generate and parse MTFs.
• Custom support of a constrained number of MTFs, which might be achieved by bespoke development by a third party. MTFs have a simple format, so support of a single MTF is technically straightforward.  Focus on support of the MTFs actually needed may avoid the complexity of a generic solution.

Isode’s model is that C2 provider has an approach to create and process MTFs and that Isode’s role is to transport MTFs over a variety of bearers.

MTF Transport Requirements

A C2 system sending a MTF needs to set a number of messaging parameters, which are independent of the protocols used, including:

• Recipient or recipients. This is fundamental information.  Everything else is optional.
• Priority. This may be two priorities if recipients are separate as Action/Info.
• SICs. Subject Information Codes to categorize the information being sent.
• Handing or Message Instructions, to facilitate manual processing.
• Message type, to categorize the message, for example to associate with an exercise.
• DTG (Date Time Group) to specify validity time of information.
• Security Label

These parameters might be exposed to the operator, or completely hidden. An operator might click on a C2 button, which will generate a MTF associated with the button and other information (e.g., a selected location), leading to a generated message.

For a received MTF it will generally be desirable to make available the message sender and the information set by the sender. This facilitates correct processing of the arriving MTF.

MTF Handing in Different Messaging Protocols

ACP 127 is an unstructured protocol. When a MTF is transported by ACP 127 it becomes the whole message. Operationally, MTFs are often considered as the whole message, and when ACP 127 is converted to STANAG 4406 or SMTP this paradigm is repeated.

STANAG 4406 specifies a MTF body parts (ADatP-3) which provides a sensible structured approach to carrying MTFs. Isode’s M-Switch product supports this, including mapping to a MIME body part for SMTP messages and mapping to ACP 127 body part in a manner compatible with ACP 127 usage. Isode sees this as the preferable approach.

Harrier MMHS API

Isode provides the Harrier MMHS API, which supports MTF submission and retrieval from a C2 system. This can be used with both Web and server based C2 systems.

The Harrier MMHS API provides a simple and secure interface to the message transport, using JSON and WebSockets. By going through Isode’s Harrier product, submission and retrieval can be handled with a single connection and military attributes are supported.

To send a message, the C2 system will provide a MTF and messaging parameters encoded in JSON. This enables providing a simple C2 UI which can generate MTF and Message with the operator only providing those necessary parameters. It is possible that a single click action could cause a MTF to be sent.

On the receive side, MTF Handler will alert the C2 system to any new MTF Messages arriving. The C2 System will be able to retrieve new MTFs along with the associated messaging parameters. MTFs can then be handled and C2 display updated appropriately.

Direct use of Harrier

Isode provides a second approach to C2 integration, which is more aligned to historical message operator approach. The basic approach descirbed first can work with any C2 system.

1. Sending operator interacts with C2 system UI, leading to generation of a MTF File.
2. Harrier is Isode’s MMHS UI. It can read the MTF file and insert it into a message (either in-line or as attachment). The Harrier UI will allow the operator to set all messaging parameters.
3. Isode sending messaging server will convert message to desired protocol and transfer it to the receiving server.
4. Isode receiving server will deliver message to Harrier.
5. Harrier operator will show the new message. Harrier will detect that the message contains a MTF and offer to save the message to a file, which the operator will do.
6. C2 operator will then read in the MTF file and process it.

The Harrier operator experience is shown below:

It can be seen that a MTF has been received within a military message. Harrier has identified the MTF and provides a simple UI to download the MTF as an attachment that can then be viewed or otherwise processed by a C2 system.

Integration with Systematic IRIS Forms

Systematic IRIS Forms is a market-leading tool for hnadling MTFs.Harrier offers a direct integration with IRIS Forms that enables clean creation and display of forms within Harrier, illustrated in the following scrrenshots.

When composing a message, “Attach form to the message” within Harrier invokes IRIS Forms from within Harier to start creating a form

IRIS Forms capabilities are then used to create a form for sending in the message.

When a message is received by an ACP 127 recipient, you can see that te whole form gets converted into a legacy form.

When the message is received by Harrier, the form is displayed “inline” in the received using IRIS Forms.

This provides a clean way to handle forms in a Military Messaging environment.