Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

isode.com / whitepapers /

Packaging Military Messaging for HF Radio and other Low Bandwidth Links

Published on: 15th February 2007

Overview

The general requirements and protocol architecture for military messaging over low bandwidth communications are described in the Isode Whitepaper Military Messaging over HF Radio and Satellite using STANAG 4406 Annex E. This paper looks in more detail at how various server components are packaged together, investigating both software and hardware combinations, and showing how users and user agents fit into the system. The paper examines single user systems in detail, from both hardware and software perspective.

Overall Architecture

The diagram above shows the top level STANAG 4406 Annex E architecture for communication over HF Radio and other constrained bandwidth networks. Components of this diagram to note:

• LMTA: An MTA is an X.400 Message Transfer Agent, which is the basic store and forward message switching component of a STANAG 4406 military messaging system. An LMTA (Lightweight Message Transfer Agent) is an MTA that supports P1/Annex E and not 'Full Stack' P1. This is an MTA that works with other MTAs only in a constrained bandwidth environment.
• P1/Annex E: P1 is the X.400 P1 protocol. Used to communicate between two MTAs. P1/Annex E refers to the use of STANAG 4406 Annex E, used in conjunction with ACP 142, to carry P1 over a low bandwidth link in an optimal manner.
• Full Stack P1: This is the standard military and civil protocol used to carry P1 over a TCP connection. It is used over high bandwidth fixed line connections.
• TIA: TIA (Tactical Interface Agent) is an MTA that supports P1/Annex E and Full Stack P1. It is intended to switch messages between a tactical environment using P1/Annex E and a strategic environment using Full Stack P1.

Where an MTA is Needed

MTAs are always needed at the centre of a STANAG 4406 system for transferring messages, and will be associated with sites supporting users to provide for message submission and delivery. An MTA will typically support a medium or large number of users via User Agents (UAs) that provide the STANAG 4406 client interface to the end user. Typically, a user will run a UA on his/her PC, which will connect over a network to an associated MTA. In high bandwidth environments, MTAs usually run on separate servers and support many UAs.

This paper discusses solutions for low bandwidth environments where MTAs are used to support single UAs. This "single user MTA" setup seems odd, but is required because of the nature of MTA-to-MTA protocols, and features they have that are not supported in UA protocols. There are two specific capabilities:

1. Optimization for slow networks. STANAG 4406 Annex E in conjunction with ACP 142 is optimized for use over low bandwidth networks, addressing both data bandwidth and network latency issues. UA protocols are generally “chatty” and unsuitable for use over high latency networks.
2. EMCON support. A mobile system will often need to operate in EMCON (Emission Control) mode, where it receives data but does not send, in order to hide position. UA protocols are not suitable for supporting this.

Logical Packaging

This section looks at three logical packages of the Isode products to support STANAG 4406 Annex E deployments. It describes the groupings, and also references the names used by Isode for these product groups.

Fixed Gateway (TIA)

The above diagram shows Isode’s M-Switch X.400 product, configured as a TIA, interconnecting strategic and tactical networks. M-Switch X.400 supports various protocols by use of “channels”. The Full Stack P1 Channel comes as core part of M-Switch X.400, and the STANAG 4406 Annex E channel is an optional component.

Isode refers to this M-Switch X.400 Configuration as "STANAG 4406 Annex E Gateway (Fixed)".

Mobile Gateway

The above diagram shows a configuration which is technically identical to the TIA. However, rather than connected to a strategic network, this gateway configuration is part of a mobile deployment such as a ship or field HQ, and it connects between the radio network and a local messaging system that supports local users independent of the gateway. The local messaging system could be built using Isode servers, or it could be a different system using X.400 P1, such as Microsoft Exchange.

Isode refers to this M-Switch X.400 Configuration as "STANAG 4406 Annex E Gateway (Mobile)".

Server System (LMTA)

For a small mobile system, an LMTA architecture as shown above is a simpler and more natural choice than a gateway. STANAG 4406 UAs can connect in two ways to the LMTA:

1. Directly, by use of the X.400 P3 protocol.
2. Indirectly, making use of an X.400 Message Store, such as Isode’s M-Store X.400 and the X.400 P7 protocol. M-Store X.400 connects with M-Switch X.400 using X.400 P3.

Isode refers to this M-Switch X.400 and M-Store X.400 product combination as "STANAG 4406 Annex E Server".

Single User Systems

Many mobile military messaging systems will be single user systems, where a platoon, vehicle, or small ship is supporting a single client for formal email contact. As discussed, this single user system will need an MTA in order to work effectively with low bandwidth communications and to support EMCON. Single user systems introduce a number of management and packaging issues, and the rest of this paper is primarily focused on single user systems.

STANAG 4406 Client

SAFEmail from Boldon James (click for more detail)

An essential component of a single user mobile system is the STANAG 4406 military messaging client. Isode recommends the SAFEmail.mil client from Boldon James based on Microsoft Outlook and shown above. SAFEmail.mil supports X.400 P7 and so can be used in conjunction with Isode’s M-Store X.400 Message Store, which is included in Isode's single user architecture.

Logical Architecture

The above diagram shows the structure of a single user system. The core of this system is M-Switch X.400 acting as an LMTA, with SAFEMail.mil connected via M-Store X.400. All of this operates on a single box.

Isode refers to this product combination (excluding SAFEmail.mil) as "STANAG 4406 Annex E Server (single user)".

Local Management

The typical end user of a single user system will not have MTA and server management skills. For the most part, the servers on the single user system can be treated as a “black box” by the end user and will work without user intervention.

One piece of functionality that is important is some basic message queue management by the user, shown above as "User Queue Management". Because links are slow, it may take a long time to send messages. This can be exacerbated by poor radio connections. It is important that the user can see which messages are queued up to be sent, using a simple tool equivalent to looking at a printer queue. It would also be desirable to be able to delete messages from the queue, in the event that the user identifies that an unsent message no longer needs to be sent.

Remote Configuration Management

Isode's approach to configuration is to store this in an LDAP/X.500 directory. The information stored in the directory includes:

1. Configuration information for the Isode servers.
2. Address book information for SAFEmail.mil, accessed by the associated Boldon James MasterKey product.

All of this information is stored as shadow information, replicated from a remote master directory. Typically, this information will be stable. In the event of changes needing to be made, these can be replicated over the wire from the master. DISP uses incremental replication, and so changes can be made efficiently. Replication can operate at a low priority, so that updates do not delay message traffic. Updates over the wire may be useful for a number of reasons, such as:

• To add information for a new recipient that the user may need to correspond with.
• Changes to routing information, for example to send messages via this system to another LMTA that cannot be directly reached from the base system.

Communications Hardware

To understand the hardware packaging issues for single user systems, it is useful to look at communication options.

HF Radios

A typical military HF Radio is shown above. This is a Harris radio used in the UK BOWMAN project. This unit weighs 4.5kg (without batteries) and has ranges as follows:

• Up to 32km using a Whip Antenna
• Up to 800km using a Near Vertical Incidence Antenna
• Virtually unrestricted range using a Skywave Antenna

This long range is a major benefit of using HF radio.

HF Modems

In order to support Annex E over HF Radio, a military grade modem is needed, supporting STANAG 4529 and STANAG 4285. In addition to the modem, support for STANAG 5066 "Profile for High Frequency (HF) Radio Communications". This is described in the Isode whitepaper STANAG 5066: The Standard for Data Applications over HF Radio.

The RM6 Modem from RapidM, illustrated above, is an example of what is needed.

VHF Radios

VHF Radios can be smaller. This BOWMAN system weighs 1.2kg, and has a range of 5km with whip antenna. The modems associated with this type of radio are appropriate for use with Annex E. Annex E is appropriate to use with VHF because:

• In many situations, the available bandwidth is low and will benefit from the optimizations provided by Annex E.
• EMCON capability can be important.

Satellite Communications

Military satellite communication, such as the UK Skynet 5 satellite, typically requires reasonably large communications hardware. Satellite bandwidth is higher and can operate without use of Annex E. However, if EMCON operation is desired, use of Annex E will be necessary. Annex E also provides superior performance over high latency networks and multicast capability. For these reasons, Annex E can be a good choice for use with Satellite networks.

Terminals

A messaging application will require an end user terminal. In many situations, ruggedized laptopswill be suitable. For some situations, more specialized terminals will be appropriate.

This is the PUDT (Portable User Data Terminal) for the UK BOWMAN deployment, which runs Microsoft Windows 2000.

Where to put the MTA

For a mobile system, the MTA and other servers need to run on a computer system. The Terminals used for this type of deployment appear to provide a suitably sized system. In most cases, it will make sense to run the server software on the Terminal, rather than introducing another system or using the modem.

Small Mobile Systems

For vehicle and larger systems, packaging a single user mobile messaging system based on STANAG 4406 is not a problem. The necessary components can be fitted in, without any particular issues.

For "man pack" configurations, care will be needed to bring together a set of components that meets both technical and operational requirements.

Conclusions

STANAG 4406 Annex E supports low bandwidth military messaging. It is important to have an MTA on the mobile system, in order to optimize bandwidth use and to support EMCON. This paper has shown the software configurations needed to support this, and that hardware configurations for small vehicles and larger systems are straightforward.