From BRASS to BRE1TAImproving HF Communications Now and in the Future

BRASS & current Naval HF Communication

BRASS systems are deployed by many NATO nations as part of their naval communication. A description of BRASS is given in the Isode white paper [Isode's Solution for BRASS (Broadcast and Ship to Shore)].

The BRASS service supports a single application: formal military messaging using the ACP127 protocol.

The core of a BRASS service is a continuous HF broadcast, typically at 300-1200 bps, going out to multiple ships. There is a flow of ACP 127 messages, with RECAP messages sent at hourly intervals. The broadcast will generally go out on several frequencies (typically four or five) to allow ships to select a frequency that works. The BRASS Service will use OTAM (Off The Air Monitoring) to select the best frequencies to broadcast on. Ships may be in EMCON, and so not able to respond to broadcast messages.

In addition to the core broadcast, the BRASS service makes use of three types of point to point link:

1. Ship to Shore. A special link that supports message flow from a ship to shore and request to re-send missing or corrupt messages. Frequency Assignment Broadcast (FAB) is used to allow ships to share a pool of HF frequencies for ship to shore communication.
2. Ship to Ship: to support direct communications between ships.
3. Maritime Rear Link (MRL).  A link between selected ships (usually "Command Afloat") and shore, supporting message flow in both directions.

Why HF is Important

BLOS communication between fixed shore stations and mobile units is important for Naval and Airborne communication. SATCOM is the increasingly dominant means of BLOS communication, with speed and reliability steadily increasing. SATCOM enables a wide range of real time and streaming services to be provided.

HF is a difficult communications medium with lower speeds than modern SATCOM. There are a number of critical reasons why HF is important:

• SATCOM does not reach all locations (e.g., Fjords and Polar Regions).
• Some countries cannot afford SATCOM services and do not wish to rely on commercial services.
• For SATCOM-Denied operation. Satellites are vulnerable to physical attack and jamming is straightforward.

For these reasons, most nations will wish to use HF services. It will often be configured as a back-up system that will switch in when SATCOM is not available.

It is important to maximize the service that can be achieved over HF and to move beyond the very basic core service provided by BRASS.

The Promise of BRE1TA & Wideband HF (WBHF)

NATO introduced the BRE1TA (BRASS Enhancement 1 Technical Architecture) in 2008, as a vision for moving the BRASS program forward to take advantage of HF technologies introduced since the original BRASS design. The BRE1TA Capability Vision and Strategy presented in February 2008 was:

1. Enhanced messaging: X.400 (STANAG 4406 Annex E) and Simple Mail Transfer Protocol (SMTP) over the air between shore & deployed forces.
2. Directory services in accordance with X.500/Allied Communication Publication (ACP) 133
3. Higher HF bandwidth and throughput with introduction of STANAG 4539 HF Data Modems
4. Support for Automated Radio Control (ARC) and Automated Link Establishment (ALE) through the introduction of STANAG 4538.
5. Provision of IP over HF services (e.g. Data/Web) in conformance with STANAG 5066

The first four goals have been demonstrated as achievable, and this paper looks at how they can be achieved. The BRE1TA vision of IP services and in particular IP mobility needs further work before it can be achieved. This is discussed in detail later.

Subsequent to the original BRE1TA, two key developments have occurred:

1. STANAG 5066 ed3 had introduced a framework for supporting multi-node networks and in particular Annex K (CSMA) and Annex L (Wireless Token Ring) that provide useful new capabilities for BRASS/BRE1TA type deployments.
2. STANAG 5069 has introduced wideband HF (WBHF) capabilities up to 240 kbps using 16 contiguous 3kHz channels and the HFXL alternative using non-contiguous channels.

These new and important developments have impacted thinking on moving BRASS forward.

The Oversell of IP Services & HF Reality

There are a number of factors that are creating some incorrect perceptions in the user community:

• The discussion of IP Services over HF.
• The discussion of ever increasing WBHF top speeds.
• Demonstrations, such as streaming video over IP over HF, which are cute but could not be usefully deployed.

This is leading to a sense that:

• HF can be a drop-in replacement for SATCOM (perhaps with some degradation); and
• There is no need to worry about applications over HF, as you can just use standard IP applications

This is not the case, and will be discussed in more detail later in this paper.

It is important that the HF community sets realistic expectations. Significant improvements can be achieved over the current BRASS service, but constraints and characteristics of HF mean that there are limits as to what is possible.

While a drop-in replacement for SATCOM is not achievable, significant improvements can be made over the current BRASS services. These are examined next.

Improved Performance

Moving to use STANAG 4539 3G Waveforms on narrowband links can significantly improve performance over the older waveforms used in BRASS, particularly on point to point links.

Automatic Link Establishment (ALE)

Current BRASS systems need a high level of operator support, in part to deal with ACP 127 and in part to handle link configuration and the associated frequency management. ALE can automate frequency selection and also replace the BRASS-specific FAB protocol.

There are various ALE standards. 2G (second generation) ALE is the most widely deployed. The original BRE1TA plan was to use 3G ALE, which has benefits but has not seen wide take-up. It may be sensible for BRE1TA deployments to start with 2G ALE and plan to shift to the new 4G ALE standard that is in development.

Applications

A key BRE1TA direction is to move beyond ACP 127 based formal messaging as the only BRASS service. Modern protocols can be used to provide a much improved military messaging service and new services can be added to the mix. HF is a way for applications to communicate and not an end goal. This section considers applications that can be deployed now.

Military Messaging

Formal military messaging is the only BRASS application provided by ACP 127. There are a number of downsides to using ACP 127:

• The way that ACP 127 works in BRASS needs a high level of operator support.
• Limited character set (including lack of lowercase letters).
• No Attachments.
• No Message Forwarding.
• No Acknowledgements (Delivery Reports or Read Receipts).
• Direct to modem mapping for broadcast means that messages can be corrupted.

These deficiencies can be addressed using ACP 142 “"P_Mul – A Protocol for Reliable Multicast Messaging in Constrained Bandwidth and Delayed Acknowledgement (EMCON) Environments". ACP 142 can be used over point to point, broadcast and multicast links using STANAG 5066 non-ARQ.

There are two protocols for military messaging that can be used over ACP 142:

1. STANAG 4406 Annex E over ACP 142 is the NATO standard for constrained bandwidth operation. It is also the original BRE1TA target.
2. MULE (Multicast Email) enables  SMTP messaging operates over ACP 142 with military extensions provided using RFC 6477 as described in Military Messaging (MMHS) over SMTP.

This provides two excellent options to move forward from ACP 127. Migration will best be handled by a server such as Isode M-Switch, which supports both the BRASS protocols and ACP 142.

Informal Messaging

Informal messaging (email) is a desirable service, currently provided over HF (but not a part of BRASS) using BFEM. MULE over ACP 142 is a good way to bring email into BRASS, with the following benefits over BFEM:

• Use of ACP 142 enables multicast operation and supports EMCON, thus enabling it to be a part of the core BRE1TA broadcast service.
• Integrates cleanly with STANAG 4406 messaging and shares STANAG 5066 configuration.
• Supports NOTARY, which enables control of Delivery Status Notifications, and in particular the ability to request positive DSNs for message tracking.
• Support 8BITMIME and BINARYMIME which will optimize performance for binary data.
• Removes the 128 MByte maximum message size, which will be important with move to WBHF.

Directory Synchronization

The BRE1TA plan includes support of [ACP 133 directory services]. Directory is a critical service for military communication and ACP 133 enables directory provision in a federated manner using LDAP or X.500 access.   

It would be inefficient to perform directory access over HF, so the sensible architecture is to have a directory server at each node, and to synchronize directory services over the HF link. So the service needed for BRE1TA is directory synchronization.

Directory Synchronization can be provided in a simple and efficient manner over messaging, as described in [Directory Replication by Email and over 'Air Gap]. It is straightforward to provide this service in BRE1TA using the core messaging service.

JChat/XMPP

Military Instant Messaging is a service that has grown significantly in importance since the original BRE1TA plan. The NATO standard for real time messaging and presence is XMPP, which is used in the NATO JChat service that used NATO’s JChat client and Isode’s M-Link server.

XMPP provides optimized operation over HF using XEP-0365: Server to Server communication over STANAG 5066 ARQ. This enables efficient XMPP operation over point to point and multi-node links. It seems highly desirable to include XMPP as a part of BRE1TA.

Broadcast and EMCON

Broadcast is the core element of a BRASS service and is expected to remain a key BRE1TA element, particularly to support EMCON services. It is often desirable or necessary for a mobile unit to maintain radio silence. Broadcast enables messages to be sent to such mobile units, which is not possible if ALE or ARQ is used.

Why Broadcast (without EMCON)

ALE provides a useful alternative to broadcast for non-EMCON services. It may be more efficient to use an ALE ARQ link from shore to ship in order to send a message, as a dedicated frequency can be allocated for the transmission, and performance optimized for that link.

However, there are cases where broadcast will be more efficient. Consider the case with large numbers of mobile units, a good broadcast signal, and relatively few frequencies available. Messages can be sent over the broadcast link, and there will be relatively few requests for resend as the link is good. Use of this static link may well be faster than setting up and tearing down lots of ALE links.

Use of broadcast for non-EMCON will be an alternative to ARQ that is available to BRE1TA system designers. The choice is certain to depend on a range of choices for the overall system (including: number of nodes and their location; anticipated traffic patterns; frequencies available).

EMCON

A broadcast service is needed to support nodes in EMCON. Where support of EMCON is needed, broadcast will be an essential part of a BRE1TA system.  

A broadcast system can also support mobile units that are not in EMCON, and also does not require the shore station to know if the mobile unit is in EMCON. Where a mobile unit is not in EMCON, message reliability can be ensured. For a mobile unit in EMCON there will always be some risk of message loss, but system parameters can be tuned to minimize this risk. Where a broadcast system is being provided for mobile units that are or may be in EMCON, it may well be desirable to also use it for other traffic.

The broadcast transmissions will use powerful shore based transmitters, and there may also be situations where a mobile unit can receive the broadcast, but is not able to establish a point to point link to shore. Broadcast is also helpful in this scenario, which is effectively an EMCON one.

STANAG 5066 non-ARQ

The current BRASS broadcasts are “direct to modem”, which has two big problems:

• There is no integrity checking, so message corruption can occur undetected; and
• The broadcast is dedicated to a single (ACP 127) application.

STANAG 5066 has a non-ARQ broadcast mode, which can address both of these problems. A checksum is applied to the non-ARQ data, to ensure data integrity and multiple applications can be supported over the broadcast. So shift to STANAG 5066 broadcast is a key change for BRE1TA.

Military Messaging

Although ACP127 cannot be operated over STANAG 5066 non-ARQ, this does not matter as ACP 142 support broadcast and EMCON operation over STANAG 5066 non-ARQ. Non-EMCON operation can also be supported, with ACP 142 acknowledgements being returned over ship to shore links.

As noted above, military messaging can be provided over ACP 142 using either STANAG 4406 Annex E (NATO and BRE1TA target) or MULE.

Informal Messaging (email)

The shift to STANAG 5066 non-ARQ for broadcast allows multiple services to be deployed over the broadcast. There is one service that can be deployed now.

Informal Messaging (email) can be supported over Broadcast/EMCON using ACP 142 and MULE. By operating this as a separate service to formal messaging, the whole service can be given a lower priority (technically STANAG 5066 Rank). This will ensure that formal messages do not get blocked or delayed by email.

Summary of What can be Deployed Now

The section summarizes the capabilities discussed in this paper to move beyond the current BRASS service, which are available to deploy.

Capability	Isode Product & Availability
Move to speeds up to 9600bps using STANAG 5439 waveforms	Available from most HF modem vendors.
ITU X.402	Message Handling Systems (MHS): Overall Structure. ISO/IEC 10021-2, 1999
ITU X.411	Message Handling Systems (MHS): Message Transfer System: Abstract Service Definition and Procedures. ISO/IEC 10021-4, 1999
ITU X.419	Message Handling Systems (MHS): Protocol Specifications. ISO/IEC 10021-6, 1999
ITU X.420	Message Handling Systems (MHS): Interpersonal Messaging System. ISO/IEC 10021-7, 1996

This list shows clearly that it is possible to make significant short term improvements over the current BRASS service.

Future Developments

This section looks at further HF capabilities that are not ready for general deployment.

Wideband HF

STANAG 5069 Contiguous Wideband HF (WBHF) and non-contiguous (HFXL) are exciting developments with a number of products on the market. Some key elements are missing to prevent a general interoperable solution. In particular:

• 4G ALE is needed.  US DoD is working on a standard.
• Changes to STANAG 5066 are needed to usefully support applications running over WBHF/HFXL. NATO is putting in place a Program of Work to address this. Isode has proposed changes to address the two key problems in [Data Rate Selection in STANAG 5066 for Autobaud Waveforms (S5066-EP4)] and [STANAG 5066 Large Windows Support (S5066-EP5)].

Duplex Operation

STANAG 5066 defines duplex operation. This is highly desirable and can be used for communication with ships large enough to provide effect separation between transmit and receive antennae. Work by Leonardo identified lack of clarity in the standard which needs to be addressed in an update to STANAG 5066. A solution to one problem identified is provided by the Isode proposed [Data Rate Selection in STANAG 5066 for Autobaud Waveforms (S5066-EP4)].  

Multi-node HF Networks

BRASS uses broadcast and point to point communication. STANAG 5066 Ed3 introduces two options to enable multiple nodes to share a single frequency. This can be helpful, as a BRASS system will be allocated a limited number of HF frequencies, and this gives another way to manage the frequencies. The options are:

• Annex K defines a CSMA (Carrier Sense Multiple Access) approach, which is a good choice where link utilization is low.  
• Annex L defines a Wireless Ring Token Protocol, which is a good choice when link utilization is high.

A multi-node network has an explicit set of nodes which may all transmit, as distinct from a broadcast network where there is a transmitter and no direct response from other nodes. This enables two possibilities not available in current BRASS:

1. It enables pairwise ARQ communication between each pair of nodes on the network. Operating in this manner can be much more efficient that each pair of nodes looking for a dedicated frequency using ALE and then dropping the link after transmission, particularly where there are very frequencies to use.
2. It enables multicast communication, using protocols such as ACP 142. This allows messages to be sent once to multiple destinations, with efficient acknowledgement. It can enable significant optimization for some traffic patterns.

Multi-node networks provide a new option for configuring BRE1TA networks.

Other Optimized Applications

The hardest characteristic of HF to deal with is high latency, which is a natural consequence of modem and link level approaches to optimize performance. To optimize application performance over HF, handshakes need to be minimized. This almost always requires special protocols, and so it is strongly recommended that such protocols are developed for all critical applications.

IP Services & Proxy Architecture

It would be impractical to optimize all applications to operate over HF and so it makes sense to have a way to run applications of lower importance directly over IP and to not require a special application protocol. STANAG 5066 specifies a mechanism to carry IP over HF, but unfortunately this is quite inefficient and performs very badly under load. A discussion of the problem and detailed description of the solution is given in the Isode White Paper [Architecture for IP Application Services over HF Radio: Point to Point, Multicast and Broadcast].

The solution is a Proxy Architecture using a TCP PEP (Performance Enhancing Proxy) and a UDP Proxy. Such a pair of proxies will support all common IP applications, which invariably use either TCP or UDP. This proxy architecture needs to be standardized and product availability, before IP Applications can be effectively deployed in a BRE1TA environment.

Voice

Voice is a critical communication service. In current HF environments, links are used to transfer either Data or Voice (at any one time). This makes excellent sense at 2400 bps.

VOIP (Voice over IP) is the IP standard for Voice. For a fast duplex WBHF link, use of VOIP can work well, particularly in conjunction with a UDP Proxy.

For an intermediate speed link (e.g 19,200 bps), VOIP is not going to perform well and will also be problematic for a (common) half duplex link. However, it is also wasteful to dedicate a link of this quality to Voice. It would be desirable to have a STANAG 5066 standard that supports Voice, and also allows some data to be transferred at the same time. Isode recommends that NATO consider this.

New Broadcast/EMCON Services

Use of STANAG 5066 non-ARQ broadcast enables multiple applications to be deployed over the broadcast.    This requires protocols that can work in broadcast and EMCON mode, which excludes most applications using their standard protocols.

XMPP can be deployed point to point over HF using XEP-0365. It seems desirable to extend this capability to enable MUC (Multi-User Chat) Rooms to be shared over broadcast and with EMCON mobile units.  

Some specialized C2 protocols operate over UDP and IP Multicast. These could be used over broadcast/EMCON using a UDP Proxy.

There are likely to be other services which are desirable to provide over broadcast and EMCON. To do this, appropriate protocols may need to be developed.

Summary of Future Developments

Capability	Dependencies	Isode Product
WBHF	Needs a 4G ALE standard for interoperable deployment and STANAG 5066 extensions Vendor-specific options available now.	Icon-5066 supports S5066-EP4 and S5066-EP5 as interim.
STANAG 5066 Duplex	STANAG 5066 Updates.	Icon-5066.
CSMA Multi-node links (Annex K)	Products approximating to Annex K available.	Icon-5066 (Full Annex K Planned).
Token Ring Multi-node links (Annex L)	Only known Annex L implementation is not generally available.	Icon-5066 (Annex L Planned)
IP Services to support applications without HF (S5066) support	Some support available, but performance will generally be poor.  May work usefully in some specific situations. Standardization of middle-layer proxy protocols is desirable.	Icon PEP (future product)
New Applications over STANAG 5066 Broadcast / EMCON	Needs per-application standardization.	No current plans. XMPP broadcast product possible

Conclusions

This paper has described how HF services can be improved to move beyond current deployed BRASS capabilities and why this is important. It has set out what can be deployed now and anticipated future development.