Military Messaging over HF Radio and Satellite using STANAG 4406 Annex E

Summary

Military Messages often need to be transferred over low bandwidth networks, in particular HF Radio and Satellite Networks. The two military specifications for this type of messaging environment are NATO's STANAG 4406 Annex E and ACP 142 developed by the CCEB (Combined Communications-Electronics Board – AU, CA, NZ, US, UK).

This paper describes scenarios that require these special technologies, and then gives an overview of the technologies and how they address the technical problems.

The Technical Challenges

There are a number of basic technical challenges that arise from military messaging deployments, some of which are particularly relevant to constrained communications channels. These are summarized below and will be illustrated in the scenarios described subsequently.

1. Low bandwidth. Many of the communication channels used are very slow, down to as little as 75 bits per second. With bandwidth this constrained, it is imperative that protocols make efficient use of it.
2. High latency. Very often, slow links have long round trip times. Satellite links are usually faster, but have very high latency. To work well in high latency environments, protocols should be “non-blocking” as much as possible.
3. High error rates. Typical communication channels will often have high error rates, and applications must be robust to this.
4. Multicast. Many of the communication channels used are inherently multicast (e.g., radio, satellite). Messages are often sent to multiple destinations, and it is desirable that protocols can take advantage of the multicast nature of the underlying media. To some extent, this can compensate for low bandwidth.
5. EMCON (Emission Control). Deployed units will in many situations wish to not broadcast signals, in order to help hide their location. The situation where signals can be received but not sent is referred to as EMCON. It is important to be able to send messages to a unit in EMCON.
6. Priority. Formal military communications have an associated priority (precedence). In a low bandwidth environment, it is easy for message queues to build up, and so it is critical to have mechanisms which will ensure that the highest priority messages get through first.

Scenarios

This section considers a number of scenarios where the technologies described here are important. It is not intended to be an exhaustive list.

Surface Fleet Communication

Naval communication is a major target. Although communication could flow from the strategic environment directly to task force ships using broadcast radio, this is not generally the approach used. When ships are deployed as part of a task force, communication will generally go to the designated command ship (usually a larger surface unit with the necessary command, control and communication equipment).

At the strategic level, messages may come from a COMCEN (Communications Centre) on shore or directly from originators in the strategic environment. Maximum support of messages direct from originators is desirable.

Messages are then relayed onwards to the other ships in the task force, often using the same communications technology as in ship to shore. The above scenario shows use of Satellite to reach the command ship and broadcast HF (high frequency) radio for communication with the other units in the task force. Multicast can be used for communication from the command ship to the other ships. In EMCON, messages can be received from shore or from other vessels, but not transmitted between ships or back to shore. More complex situations may arise with individual vessels in EMCON.

In general, a ship would have quite a number of potential internal message recipients, and the external message communication needs to be connected with the internal messaging infrastructure.

Submarine Communication

Communication with submarines introduces a number of special requirements. Submarines may make use of higher bandwidth channels when they are on the surface. They will also use VLF (very low frequency) radio, which has a data rate of around 300 bits per second. VLF radio has the advantage that it will penetrate below the surface for a moderate distance, and so can be used by a submarine without surfacing.

When submarines dive below the level of VLF penetration, they will be out of all communication, and so this leads to three basic states: full communication; EMCON; no communication. These need to be managed, and shore systems will be most effective if they understand the current state of communication, a situation also relevant to the previous scenario. This is achieved by planned timing of communication status, which is shared between submarine and shore.

Army Deployment

The army has similar requirements. Typically, there will be high bandwidth communication to field HQ. Communication to field units may be bandwidth constrained, and there may be requirement for EMCON. In some situations, store and forward messaging is useful, for example to send key information (e.g., map data) or to send a formal message in preference to voice communication.

In the scenario illustrated above, there is no direct communication from field HQ to a second field unit., but messages can be relayed by use of the messaging system in the first field unit. This relay needs to be fully automated, and not require manual intervention at the first field unit.

Special Forces

Another requirement is to support special forces operatives. It will often be desirable or essential to have radio silence (EMCON), but to retain the ability to listen and to receive messages.

STANAG 4406 and ACP 142 Protocol Architecture

The above diagram shows a STANAG 4406 Annex E messaging architecture, with protocols down to the ACP 142 level. Mappings below ACP 142 to support Satellite and HF Radio are described later.

STANAG 4406 Messaging

STANAG 4406 defines a family of protocols to support military messaging, based on the ITU X.400 Standards.

STANAG 4406 specifies an end to end message protocol for communicating between a pair of messaging clients, which are referred to as User Agents (UA). This end to end protocol is based on the X.400 P2 Interpersonal Messaging Protocol, extended by the P772 protocol defined in STANAG 4406 that provides enhancements for military service capabilities and military body parts.

STANAG 4406 messages are switched by store and forward message switches, which are referred to as Message Transfer Agents (MTA). When MTAs communicate over a high speed network they use the X.400 P1 Protocol, which has a mapping onto TCP/IP referred to as "full stack". The TIA and LMTA are special types of MTA, which are described in more detail later. The diagram above shows MTA and MTA (TIA) communicating using

A UA may communicate directly with an MTA using X.400 P3, or indirectly by a Message Store (MS) using X.400 P7. Both options are shown above. Further information on use of a Message Store is given in the Isode Whitepapaer Why X.400 is good for high reliability messaging.

STANAG 4406 Annex E

STANAG 4406 Annex E defines a light weight alternative to (full stack) X.400 P1 for communicating between a pair of MTAs. This is shown in the diagram above, communicating between the MTA (TIA) and MTA (LMTA).

STANAG 4406 Annex E specifies operation over ACP 142. which is described below. Annex E uses the core format of X.400 P1, but replaces the “full stack” mapping with a light weight mapping that comprises:

1. A simple protocol that provides the necessary services over ACP 142, and minimizes overhead. This provides a block of data to ACP 142 that encapsulates the X.400 P1 information.
2. Annex E provides general purpose data compression, that helps reduce data transfer volume for protocol, addressing information, and general data transferred (e.g., text). This compression complements application specific compression techniques (e.g., map and image compression).
3. Distributed operation procedures for an X.400 MTA, to correctly integrate with EMCON and multicast.

The key functions of Annex E are to reduce to a minimum the amount of data transmitted, and to integrate ACP 142 multicast and EMCON functionality into an X.400 MTA.

ACP 142

ACP 142 "P_Mul – A Protocol for Reliable Multicast Messaging in Constrained Bandwidth and Delayed Acknowledgement (EMCON) Environments" is a CCEB standard for multicast and EMCON support, specifically designed ’s STANAG 4406 Annex E.

ACP 142 is an end to end protocol, that can map onto various underlying transport mechanisms described later. It works to transfer data reliably from one system, to one or more recipient systems. A brief summary of how it works is as follows:

1. It works out the address to use for the set of intended recipients. There are three options:
   • Single recipient (Unicast). ACP 142 is fundamentally a multicast protocol, and unicast is a special case. For Unicast, the standard address of the recipient is used.
   • Static multicast. Here a multicast address is assigned to a fixed set of recipients. This is useful for very small networks, and for frequently used combinations of recipients in larger networks. A static multicast address can be used without any special negotiation.
   • Dynamic multicast. Each sender has a set of multicast addresses reserved for dynamic multicast. ACP 142 allows the sender to negotiate a specific set of recipients to be associated with one of these addresses. This allows dynamic multicast to be used for an arbitrary set of recipients.
2. The sender breaks up the data to be sent into a fixed number of packets, and communicates the number of packets to be sent.
3. The sender then starts sending out data packets, at a rate appropriate to the underlying communication channel.
4. In non-EMCON, each recipient will communicate back to the sender a list of packets that it has not received. This will allow the sender to retransmit lost packets, and to efficiently complete transfer of the data to all recipients.
5. In EMCON mode, a recipient will not be able to send any data back to the sender. In this situation, the sender will simply retransmit the entire message at intervals, to maximize the likelihood that all packets are correctly received.
6. ACP 142 is aware of STANAG 4406 (six level) message priority. Higher priority packets are always sent first by ACP 142. This means that a higher level message will naturally "overtake" a lower priority message that is partially transmitted.

The details are more complex, but the essence of how ACP 142 works is quite straightforward. It can be seen that ACP 142 provides the core EMCON and multicast functionality needed.

LMTA and TIA

Annex E defines protocols and procedures for integrating an X.400 MTA with ACP 142. Annex E defines two basic configurations of MTA.

1. LMTA (Lightweight MTA). This is an MTA where the only external communication makes use of P1/Annex E. An LMTA is appropriate for a ship where all internal communication goes direct to the LMTA.
2. TIA (Tactical Interface Agent). This is an MTA which makes use of P1/Annex E to communicate with LMTAs (or other TIAs). It will also communicate with "full stack" P1 to other MTAs, to enable LMTAs to be interconnected to a general X.400 network.

Isode's M-Switch X.400 can act either as an LMTA or as a TIA. This is a configuration choice, and there is no product difference between TIA and LMTA.

Supporting Small Systems

For a large unit, such as a ship that has multiple users, it is natural for the system to contain an MTA (LMTA or TIA). The MTA will enable local message distribution and give a natural external interface. For small systems, typically supporting only one user, Isode recommends the following architecture:

This approach uses an LMTA on the same machine as the mail client. The LMTA would have a very simple local and routing configuration. The benefits of this approach are:

1. There are no changes to the mail client needed to support a bandwidth constrained environment.
2. The LMTA is optimized to handle the constrained communication channel, and can efficiently manage retransmission and other procedures.

For a modern platform, and efficient MTA such as Isode M-Switch X.400, there is little functional or system overhead in having an MTA on the local system.

Supporting Different Networks

ACP 142 and STANAG 4406 Annex E can be used over multiple network technologies. This paper looks at use of Satellite Networks and HF Radio.

Satellite Networks

Satellite networks provide IP, and so full stack P1 could be used over TCP/IP. This may be done, but in many situations there are the following advantages to using STANAG 4406 Annex E and ACP 142:

1. Satellite networks are often quite slow, and the performance advantages of Annex E to reduce data volumes can be beneficial.
2. Satellites have high latency, and ACP 142 is optimized for high latency networks.
3. For messages sent to multiple destinations, ACP 142 allows the broadcast capability of the satellite to be used, which is desirable to optimize overall network use.
4. ACP 142 supports recipients in EMCON, which is not possible with protocols operating over TCP.

ACP 142 makes use of UDP (User Datagram Protocol) to operate directly over IP. This configuration can work over any IP network, making use of IP multicast. To support multicast, multicast support is necessary in all of the routers used. The example here shows a satellite connection between a pair of routers. This reflects a typical configuration, as in general the MTA will not be connected directly to a satellite router.

HF Radio

HF Radio is important for military communications, because of its effectively unlimited range. Applications running over HF Radio use STANAG 5066, which is described in the Isode white paper STANAG 5066: The Standard for Data Applications over HF Radio.

The diagram above shows the protocol stack used over HF Radio. The protocol architecture has ACP 142 operating directly over STANAG 5066. This direct mapping is optimized, and handles priority, as the priority of each ACP 142 packet is mapped on STANAG 5066 priority. This is important if multiple applications are operation over one modem/radio.

A key capability of STANAG 5066 is that it enables multiple applications to share a single modem/radio. STANAG 5066 applications connect by a STANAG 5066 standard protocol to a single STANAG 5066 server associated with the modem/radio. This also allows the application to run on a different computer and connect to the STANAG 5066 server over TCP/IP. This is convenient for large deployments. For small deployments, all components may run on a single system.

Handling Multiple Communication Channels

The paper so far has primarily considered use of a single constrained bandwidth communication channel. This section shows that many real deployments have multiple communication channels.

A ship will typically have two or more communication channels: HF Radio and Satellite. The combinations in use will depend on threats:

• Both channels in EMCON.
• Both channels active.
• One channel in EMCON. Typically Satellite channel will be in EMCON, because it has a stronger signal and is more visible. However, the "pencil beam" nature of the satellite and location of threat may lead to HF channel in EMCON and satellite active.

When both channels are open, use of Satellite may be preferred (higher bandwidth) or use of HF radio (lower cost), or a more complex preference dependent on messaging load.

With a headquarters unit, the EMCON status is simpler (as it would never be in EMCON), but there may be many more channels, for example to support multiple satellites with different ships reached through different satellite services. Other shore based systems, such as Special Operations could be in EMCON. It can be seen that these multi-channel scenarios add some significant complexity.

Multi-Hop Routing

The initial scenarios showed situations where a message needs to be sent from TIA to LMTA and then on to another LMTA. This multi-hop routing can be important where there is not direct connectivity from TIA to an LMTA. A good STANAG 4406 Annex E solution should support multi-hop routing.

Further Reading

This paper has described STANAG 4406 Annex E from a scenario and protocol architecture perspective. Another Isode white paper, Packaging Military Messaging for HF Radio and other Low Bandwidth Links provides a different perspective, looking at hardware and how component products are grouped together.

What Isode Provides

Isode's military messaging solution is summarized on the web page: Military Message Handling Systems (MMHS). Details of Isode's product architecture to address STANAG 4406 Annex E and the scenarios described in this document are set out in the Isode white paper The Architecture of Isode’s STANAG 4406 Annex E Solution.

Conclusions

This paper has set out the STANAG 4406 Annex E and ACP 142 technologies, how they are used to support military messaging.