Isode’s Solution for BRASS (Broadcast and Ship to Shore)

What is BRASS?

HF Radio is an important naval communication channel for Beyond Line Of Sight (BLOS) communication. Although SATCOM is increasingly used for BLOS communication, HF is an important alternative for various reasons, including:

• Operation in SATCOM-denied environments
• As a back-up to SATCOM
• To support operational situations where it is desirable or essential to avoid use of SATCOM

The central part of BRASS is broadcast of messages from transmitters on shore to be received by all ships. This is a continuous stream of data, which will typically be transmitted over multiple HF frequencies at the same time, providing an uninterrupted data flow from ship to shore (and avoiding the delays and overheads of alternating ARQ transmission).

Using broadcast for shore to ship HF transmission is a sensible approach as many messages need to go to multiple ships and this approach takes natural advantage of the broadcast nature of HF transmission. This is particularly important given the limited HF bandwidth.

A key goal of BRASS is to give a high probability of message reception by ships which are in EMCON (Emission Control) and cannot transmit data.

The other part of BRASS is point to point transmission. There are three related types of transmission, which will usually operate over STANAG 5066 ARQ in modern deployments:

• Ship to Shore. In this type of link, data flows only from Ship to Shore. These links are set up from a pool of allocated frequencies. There are two types of data sent over this link:
  • Messages sent from Ship to Shore.
  • Requests for retransmission of broadcast messages.
• Maritime Rear Link (MRL). This is a special Ship/Shore link using a separately allocated HF frequency and with messages flowing in both directions.
• Ship to Ship. A link between ships with messages flowing in both directions.

On shore, transmitters and receivers are at separate locations (at least a few miles apart). The primary reason for separate locations is that it enables simultaneous transmission and reception, and avoids receiver interference from nearby transmitters. It enables simultaneous broadcast on multiple frequencies, operation of multiple Ship/Shore channels and use of antennae optimized for either reception or transmission.

The application for the BRASS infrastructure is Military Messaging, also called Organizational Messaging and High Grade Messaging. BRASS uses ACP 127 messaging technology.

Transmission will often be slower than 2400 bps, typically using STANAG 4285 waveform at 600 bps to ensure low risk of message loss to all ships. This is important to support EMCON operation.

This paper describes the capabilities of BRASS, and looks at how BRASS services are integrated with other military messaging services.

Isode Strategy for BRASS

Isode’s strategy for BRASS has four elements:

1. To provide a Commercial Off The Shelf (COTS) product offering for all of the elements “above HF Modem” necessary to support a BRASS system.
2. To support BRASS and the necessary protocols and capabilities for interoperability.
3. To support modern technologies to provide BRASS functionality and enable migration from BRASS to use newer technologies and follow modern standards for organizational messaging.
4. To be fully aligned to emerging new NATO (in particular BRE1TA (BRASS Enhancements 1 Technical Architecture) and related standards for military messaging.

This white paper is focused on describing Isode’s BRASS solution. Alignment and migration to newer technologies and support of new services is covered in Isode’s white paper HF Vision, Road Map & Products.

Isode Core Components for BRASS

The Isode product set contains a number of core components which are an essential part of the Isode BRASS solution, but are not specific to BRASS. Isode’s messaging servers, and in particular the M-Switch product, are central to Isode’s BRASS offering. These servers enable message switching, message storage, authorization, audit and tracking. There are three basic families of protocol supported, with conversion between them:

1. ACP 127 is the central application for BRASS. Support includes operation over STANAG 5066.
2. STANAG 4406 is the NATO standardized successor to ACP127, fully supported by the Isode server set. This includes ACP 142 multicast operation over STANAG 5066.
3. SMTP with Military Extensions. Isode has argued that SMTP is the best direction for future military messaging, and has worked to help standardize necessary elements. M-Switch can support ACP127/STANAG 4406 services using SMTP, including operation over ACP142 and STANAG 5066 following the MULE specification of RFC 8494.

Icon-5066 is Isode’s STANAG 5066 server which provides a link layer service for HF Radio, sitting between modem and application. Isode’s applications optimized for HF Radio work over STANAG 5066.

Harrier is Isode’s military messaging Web client.

This family of products gives a complete military messaging solution for HF Radio operating “above modem”. The rest of this paper looks how this is being extended to support HF broadcast and BRASS deployment.

Supporting BRASS

This diagram below shows a basic configuration of M-Switch operating ACP127 over STANAG 5066 with M-Switch and Icon-5066, reflecting the base capabilities described in the previous section. This section looks at how these capabilities are extended to provide the full BRASS functionality.

ACP127 Broadcast

ACP127 is a simple text format and there are no protocol exchanges, so basic transfer over broadcast is quite similar to normal transmission. However, there are some important differences and for this reason M-Switch allows configuration of three types of ACP127 peer:

1. Standard: Normal transfer not involving broadcast, with peer configured as the remote system.
2. Broadcast Sender: A special broadcast peer, typically as shore system. It will be configured as a peer that broadcasts to multiple receivers.
3. Broadcast Receiver: A peer which will be usually configured as the broadcast receiver, typically on a ship.

The format of message sent over a broadcast link is slightly different to standard ACP127, with national and NATO variants. This may include stripping out some of the standard ACP127 lines. This is provided as a configuration option.

In addition to the ACP127 messages, a special “recap” message is sent at intervals (typically every hour). These recap messages give a list of all the messages for the last hour and the recipients for each message. M-Switch supports NATO and Italian format recap messages. Each broadcast receiver (ship) looks at this message to identify any message(s) not received with recipients on the ship. The ship will then use the ship to shore channel to send out an ACP127 service message indicating the messages that have not been received. In the event of a recap message being missed, the ship will wait for a subsequent recap message. The Broadcast Sequence Numbers (BSN) (equivalent to standard ACP127 Channel Sequence Numbers) information in the recap message received can be used to determine the BSN range covered by the missing recap message(s). The ship will then send to shore a service message indicating any message not received. This mechanism ensures that each ship will receive all of the messages destined for it.

Message retransmission is also possible over the broadcast link.

1. For each priority, a configurable number of mandatory retransmissions is allowed. This will typically be set to zero for lower priority messages and to a small number for the highest priority messages. This retransmission will reduce chance of message loss and the need for a receiver to request retransmission. A minimum time interval between these retransmissions can be configured to help avoid all of the transmissions of a given message being lost due to a single long “bad patch”. This is supported in M-Switch.
2. Where there is nothing else to transmit, it will often be preferable to retransmit messages rather than to not transmit anything. M-Switch will retransmit recent messages, with a maximum per-message retransmission count configured by priority, so that higher priority messages can be re-transmitted more aggressively. This will be supported in a future release.

M-Switch also support periodic transmission, so that broadcast traffic can be scheduled at specific times, which is important for submarine communication.

The final special capability for broadcast is to deal with gaps in transmission. If there is nothing to transmit, the broadcast channel will transmit a special message at intervals (typically every two minutes). This anticipated transmission will help receivers detect loss of the broadcast signal, and alert operators if there is an outage.

Ship to Shore

Ship to shore channels are special for several reasons:

• Traffic (messages and service messages) only flow from ship to shore.
• Connections are always initiated by the ship.
• Service messages sent relate to the broadcast channel (not to the ship to shore channel)

To enable this, the ACP127 routing on ship is set up to route messages (including service message) to shore via a ship to shore circuit. On shore, routing to each ship will go over the broadcast.

A limited pool of HF Frequencies is used for ship to shore links which need to be shared between the ships. Newer systems can use Automatic Link Establishment (ALE) to share these frequencies using COSS (ARQ) to reliably transmit messages to shore. Older systems use Frequency Availability Broadcast (FAB).

Frequency Availability Broadcast

Frequency Availability Broadcast (FAB) sometimes also known as CARB is an older system to share frequencies for ship to shore. This section describes Isode’s FAB solution.

FAB (Frequency Assignment Broadcast) uses a 75 bps broadcast service to communicate channel availability and message status to ships, enabling them to select a free channel for ship to shore communication and to receive acknowledgement for transfer of messages to shore.

The M-Switch FAB Server which generates the FAB broadcast sits black side and communicates directly to the modem through an async serial interface. The FAB Service may communicate with a remote SNR Monitor for each FAB circuit, which listens to the FAB circuit at a remote location and reports on SNR. Icon-5066 provides such a monitor using a simple TCP protocol. This enables FAB reporting on link quality.

Communication of FAB status comes from the M-Switch ACP 127 Service (red side), and is protected by a Data Isolator such as Isode’s M-Guard product. This communication uses M-Switch defined XML messages. It enables red side operators to communicate status and to include “SVCLINE” messages. The values used can be constrained to a specified list, in order to prevent covert channel.

For ship to shore channels using ARQ (STANAG 5066) shore side FAB operation is automatic.

For direct to modem links, shore side operators use the MConsole ACP 127 view which controls the ACP 127 Channel. This communication provides status information on each of the shore side configured ACP 127 FAB Circuits that can received ship to shore traffic (through a crypto).

Other Links

There are a number of other link types which M-Switch can support, note briefly in this section

• A Maritime Rear Link (MRL) is a normal (bidirectional) ACP127 over HF link, used to communicate between a specific ship and shore. This will typically use a dedicated link.
• Ship to Ship bidirectional links can also be used. This may be between ships that receive the broadcast or to support ships that do not receive broadcast messages.
• HF Broadcast can also be used between ships to share messages, using similar mechanisms to broadcast from shore. This will most commonly be used between ships in a Task Group communicating with HF Surface Wave.
• Ship to Ship links and broadcast may be used for messages initiated on a ship. They can also be used to relay broadcast messages, either automatically or with operator intervention.

Direct to Modem

STANAG 5066 is used for some parts of BRASS but not everywhere. In particular the broadcast link does not usually use STANAG 5066 and sometimes other links do not. In these cases, the ACP127 stream (usually encrypted) is sent directly over the modem.

For direct to modem, M-Switch ACP127 connects directly to a serial port or indirectly to serial port via a serial hub as described later. This enables direct ACP127 over modem operation.

Off The Air Monitoring (OTAM)

Not using a link layer means that a receiving ACP127 application may get data errors, as there are no checksums at any layer. STANAG 5066 checksums would ensure that only valid data gets through. The number of checksum failures will also allow the receiving system to monitor link quality.

Where a broadcast transmission is getting a significant number of errors, action needs to be taken. Possible actions are:

1. Reduce transmission speed; or
2. Transmit on a different frequency.

For BRASS systems with additional frequencies allocated, changing to transmit on a new frequency is an excellent strategy.

When operating direct to modem it is non-trivial to determine when a given frequency has an error rate that is too high. OTAM is the approach used to address this. An ACP127 broadcast sender (operating “direct to modem”) will send the transmitted ACP127 data stream to an OTAM process.

The broadcast will be received at a land site that will be “Skywave distance: from the transmitter, at a location that would be expected to have similar reception/propagation characteristics to a ship. This transmission will be processed (as for a ship) and the receive stream fed back to the OTAM process.

The OTAM process can compare the transmit and receive data streams. If they vary by more than a configurable amount (i.e., corresponding to a bit error rate on the received stream) then the OTAM process will flag this to a management process. The management process will use this information to change transmit frequency.

One OTAM process may be used to monitor multiple broadcast streams. This is done by using a switch on the receive streams, so that each one is fed in turn to OTAM. This stream switching is controlled by the management process, so that it can infer (based on timing) which stream an error reported by the OTAM process refers to. Stream switching is transparent to the OTAM process.

Isode M-Switch supports OTAM on multiple broadcast channels and a special MConsole view for monitoring OTAM, shown below.

ACP127 Correction

Although OTAM will be used to help avoid very high error rates, the receiving ACP127 system will get data errors in a direct to modem configuration. An approach is needed to deal with such errors, of which there are two types.

The first type of error is where the link data error leads to the ACP127 message being modified in a way that leads to the received data being invalid format. M-Switch will handle this by a special ACP127 correction process with a GUI interface used by an operator trained to correct ACP127 messages, which are text format. This operator interface will present the ACP127 message exactly as received. If some parts of the message can be parsed, the results of this parsing will be shown. The operator will be able to edit the message to fix up the problems caused by data errors, and then verify using the UI that the modified message parses correctly. The operator will then be able to inject this modified message into M-Switch for normal processing.

Isode M-Switch provides a mechanism to send messages that cannot be handled automatically by SMTP or STANAG 4406 to an operator, together with a GUI allowing for correction.

The second type of error is where the link data error modifies the message in a way that does not impact ACP127 inbound processing (e.g., where an error is in the main message body). A simple approach, which is often used in practice, is to automatically process the message and for the message recipient to deal with any message corruption in the way they best can. The alternative is to pass every message to an operator for correction, so that a skilled operator can fix up errors prior to transmission to final recipients. The M-Switch capabilities to do this are described later.

Gateways to STANAG 4406 and Military SMTP

ACP127 is an old protocol with a range of functionality and reliability issues inherent to the design. Isode’s approach to ACP127 is to keep it on the edge of Isode’s system wherever possible. ACP127 is supported where necessary for interoperability, which is a significant part of the BRASS solution. M-Switch supports ACP127 gateways to STANAG 4406 and SMTP with military messaging extensions.

STANAG 4406 is the NATO standard for military messaging and provides comprehensive functionality in a resilient manner. SMTP can be extended to provide equivalent functionality as described in [Military Messaging (MMHS) over SMTP].

By converting from ACP127 functionality to SMTP or STANAG 4406 where possible, it enables the M-Switch based solution to provide generic capabilities using modern protocols and minimize the use of ACP127. In particular, this approach enables use of SMTP and STANAG 4406 based clients, which avoids the difficulties of using older ACP127 clients.

General Message Correction and Vetting

ACP127 systems were deployed into an environment with high levels of human operator support. There is a “fire and forget” expectation that if an error is made in sending a message, then a human operator will fix it up en-route. Modern messaging systems put much more emphasis into ensuring that messages are correct when they are sent, which minimizes the requirement for human intervention. Even when interfacing primarily with modern systems, there is an expectation of capability for correction and vetting in a system handling ACP127.

BRASS has an additional requirement in that messages are being sent out over a very slow link, and it is important to only use the link for traffic that is vital and will not overload the link. So there need to be mechanisms for appropriate vetting of the traffic that is sent over the link and to strip out information that is not needed.

M-Switch provides vetting and correction capabilities to address these requirements. Both of these have a Web interface to make it convenient for operators to operate from any location. These interfaces operate on messages within the M-Switch queue, and so provide a reliable approach that does not take the messages away from the core switching of M-Switch: they are held in the queue while operator actions occur.

Correction is generally applied to messages that would not be delivered correctly “as is”. Some examples:

• Invalid recipient address
• Message too large (policy)
• Security Label does not match policy of message destination.
• Digital signature does not verify correctly
• No valid SICs (Subject Indicator Codes)

The correction interface allows the operator to modify the message, in the context of the reason for M-Switch being unable to process the message “as is’. Vetting may be applied to all messages, or to messages which match specific criteria, such as:

• Messages to a specific destination
• Messages larger than a given size
• Messages with security label not matching a specific security clearance

The vetting interface simply allows the operator to view each message and make a decision to allow the message or to not allow it.

Use of Newer and Faster HF Waveforms

Older BRASS systems use the STANAG 4285 waveform, which has a maximum speed of 2400 bps. It is desirable to shift to using the newer third generation STANAG 4539 waveform, which is very widely supported (most modern modems will support both of these waveforms) and goes up to 9600 bps. A key benefit of STANAG 4539 is that it is “auto baud” which means that the sender can choose a speed and the receiver will adapt. This enables speed change without complex agreement and enable faster transmission in good conditions.

Going faster is clearly desirable; it will reduce delays when there are high traffic loads and enable larger messages and new applications. Beyond STANAG 4539 it may also make sense to consider the new Wideband HF (WBHF) which will enable transmission at up to 240 kbps.

In order to make best use of higher speeds, it will also make sense to introduce variable speed transmission. This will enable faster transmissions when conditions allow, but also slow down to “safe” speeds when conditions (at least for some receivers) need it.

Comparison with other BRASS Solutions

Some BRASS deployments are provided by custom code developed for a single BRASS deployment. Others make use of source code package (the BICC software) funded by NATO and available for NATO BRASS deployments. Neither of these options provides a good approach for moving forward to newer services.

Conclusions

Isode supplies key components for a BRASS solution including an ACP127 Gateway for message exchange with STANAG 4406 and SMTP systems (with support for operation over STANAG 5066), Icon-5066 (a STANAG 5066 server) and the Harrier military messaging client.