BRASS (Broadcast and Ship to Shore) is an approach used by Navies, particularly in NATO countries, to communicate between Ships and Shore using HF Radio. This whitepaper gives an overview of BRASS and then describes the Isode strategy and solution for this area. It looks at how Isode’s products can support the protocols and interoperability for currently deployed BRASS systems and move them forward to state of the art capabilities that extend the services offered over BRASS.

BRASS capabilities are now available in Isode’s R16.4 preview release. This paper looks at these capabilities.

Creative Commons License

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 Ship to Shore transmission. There are three related types of transmission, which will usually operate over STANAG 5066 ARQ:

  • 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 primary application for the BRASS infrastructure is Military Messaging, also called Organizational Messaging and High Grade Messaging. In the future, it may well make sense to run additional applications over BRASS.

Current BRASS deployments make use of older technology, referred to in this paper as "Legacy BRASS". In particular, this includes:

  • STANAG 4285 HF Waveform (up to 2400 bps).
  • ACP127 Messaging.
  • Transmission will often be slower than 2400 bps, typically 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 Legacy BRASS, and looks at how the BRASS architecture can utilize and be improved by use of current messaging and HF technologies. The broadcast architecture of BRASS is a sensible long term approach for naval HF communication, but a shift to modern technologies is highly desirable.

    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 Legacy BRASS and the necessary protocols and capabilities for interoperability.
    3. To support modern technologies to provide BRASS functionality and enable migration from Legacy 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.

    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. ACP127 is the central application for legacy 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.

    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 client. Harrier is available as a Web application and for Android devices.

    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 Legacy 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 functionality of Legacy BRASS.

    ACP127 Broadcast

    ACP127 is a quite 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 can be 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. R16.4 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 R16.4.
    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.

    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. These frequencies are shared using the Frequency Availability Broadcast (FAB) mechanism. This is a special broadcast message that is sent out on the ship to shore channels, indicating the frequencies available and the noise level on each channel.

    When a ship wants to connect to shore, it will simply pick one of the available channels. Once a channel is in use the FAB broadcast message is updated to reflect this, so that other ships do not pick the same channel. FAB provides a simple mechanism for ships to automatically share a limited number of frequencies.

    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 releases from R16.4 support 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 Web 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 releases from R16.4 provide 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.

    Circuit Management API

    Isode supplies components "above modem" to provide the Message Processing Subsystem of a BRASS deployment. The full solution will comprise of many other components, in particular an HF Subsystem with Modems, Crypto, Radios and Antennae. The HF Subsystem will comprise many components at many sites. A BRASS system will enable configuration of elements of the HF Subsystem in a flexible manner to build "Circuits". This section looks at how the Isode elements are configured into such circuits.

    Connection to the HF Subsystem will be done by Icon 5066 or directly from the ACP127 channel. Although Icon 5066 can use TCP connections to modern modems and crypto, use of serial ports is the most likely approach. These connections can be made directly (e.g., using a server with multiple devices connected to COM: ports). A more flexible approach is use of a Serial Hub, which is a device used to connect multiple serial devices. Icon 5066 then connects to the Serial Hub using TCP, and the Serial Hub will connect Icon 5066 to the desired serial device (Modem or Crypto).

    The Isode end point of a circuit will be either an ACP127 peer or an ACP142 channel. These end points need to be connected through Icon 5066 to the HF Subsystem. Isode OTAM processes also need to be connected.

    Circuit configuration needs to deal with both HF Subsystem and Message Processing System. This is handled by a "Circuit Management" management tool shown above. To facilitate integration of this tool with the Isode provided Message Processing System, Isode provides the M-Switch HF Circuit Management (MHFCM) API". The MHFCM API provides the following capabilities:

    • Discovery of the configuration of M-Switch, ACP127, OTAM and Icon 5066. The core configuration is managed by Isode tools. This discovery process allows the circuit management to correlate the overall view of circuits with the Isode configuration.
    • Configure key parameters relevant to circuits, in M-Switch and Icon 5066.
    • Configure serial port/serial hub connections in Icon 5066 and ACP127, to enable circuits to be able to correctly link to the HF subsystem.
    • Enabling/Disabling M-Switch ACP127 circuits, so that circuits are only active when they are fully connected.
    • Passing up alerts from OTAM when link quality falls below the configured target level.

    The MHFCM API allows control of the Isode products are part of an integrated BRASS deployment.

    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 legacy 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.

    Improving BRASS with Newer Technologies

    So far we've focused on how legacy BRASS works and how this will be supported with M-Switch, including messaging gateway to STANAG 4406 and SMTP Messaging. Now we look at improving BRASS systems with newer technologies.

    Use of STANAG 5066 non-ARQ

    An important change that seems reasonably straightforward and will give significant benefits is to use STANAG 5066 for all links and in particular the non-ARQ service for broadcast. There are a number of advantages:

    • All data is check-summed. This avoids issues with corrupted messages.
    • Applications can be multiplexed over a link or broadcast. For example ACP127 and ACP142 can be sent together. This will be helpful for transition and service evolution, as well as introducing new applications (discussed below).
    • Multiple destinations can be addressed through a single modem, as each peer has a specific STANAG 5066 address. This may allow a more static hardware configuration, with routing handled dynamically in software.

    The data checksums will ensure that data is transferred correctly. For ARQ, any errors will be corrected rapidly. For non-ARQ, this may have impact on service as messages which would have previously been sent through (with errors) will now be rejected. Dealing with this issue using modern messaging protocols is discussed in the next section. To minimize this issue with ACP127, it may be desirable to retransmit messages more, particularly to ensure low message loss in EMCON. M-Switch provides retransmission options to enable this.

    When switching to non-ARQ for broadcast, there will also be a need to replace the OTAM mechanism. This can be done by monitoring at receiver site only, and recording the Frame Error Rate (FER) on a received data stream. Icon 5066 will provide a capability to monitor this.

    STANAG 4406 & SMTP over ACP142

    ACP127 is a very old protocol providing Military Messaging, a service referred to by other names including Organizational Messaging. There are newer and better ways to provide this service:

    • STANAG 4406. The NATO standard for military messaging.
    • SMTP with military extensions. SMTP is very widely deployed, and can be extended to provide military messaging as described in [Military Messaging over SMTP].

    It is highly desirable to fully replace ACP127 with modern protocols that can provide the same base service and a range of extended services.

    STANAG 4406 defines operation over HF Radio, described in the Isode whitepaper [Military Messaging over HF Radio and Satellite using STANAG 4406 Annex E] . The key protocol layer for operating over HF is ACP142 "P_Mul – A Protocol for Reliable Multicast Messaging in Constrained Bandwidth and Delayed Acknowledgement (EMCON) Environments".

    ACP142 is defined so it can carry messaging protocols other than STANAG 4406, and Isode has defined an approach to use SMTP with ACP142 in [Messaging Protocols for HF Radio].

    Use of ACP142 is the key technology shift for BRASS, and it is important to note that it can be used to support both STANAG 4406 and SMTP messaging. ACP142 is designed to support messaging over broadcast links, and so is ideal for BRASS. It provides very efficient message transmission, including data compression.

    An important design choice of ACP142 is that every message is acknowledged, so that the cumbersome ACP127 recap mechanism can be replaced. These (small) acknowledgements will lead to more ship to shore traffic, but there are other benefits of regular communication discussed later. The acknowledgements will ensure that missing messages are retransmitted quickly (avoids the one hour delay of the recap cycle) and also avoids the overhead of retransmitting messages that have been received by all ships. This feature can only be used when not operating in EMCON,

    ACP142 also supports the flexible EMCON (Emission Control) operation and will deal with ships that for operational reasons are not transmitting. It will make additional transmissions of each message to help ensure timely reception. ACP142 also provides Forward Error Correction (FEC), which is particularly helpful for long messages in EMCON mode. By adding redundancy at the application level, correct reception is still possible is some PDUs are corrupted. This can be a useful optimization to decrease message latency in light of occasional PDU loss and avoid the need to wait for a complete message retransmission.

    Message Encryption

    ACP127 uses offline encryption technology and the CODRESS format, with interfaces typically by paper tape. Although implied in current procurements, the necessary technology does not appear to be easily available.

    Requirements for encryption can be addressed by moving to modern messaging protocols. M-Switch supports encryption for SMTP (using S/MIME) and STANAG 4406 (following Annex B) messaging using Cryptographic Message Syntax technology with options to encrypt and decrypt at the boundary as described here. Moving to modern messaging appears to be the best way to support message encryption.

    Messaging Management

    There are a range of desirable messaging management functions that M-Switch can provide. These include:

    • Message Archive. M-Switch can archive all messages it handles.
    • Message Audit Database. M-Switch records all message information, which may also be stored in an audit database. MConsole provides a GUI interface onto the audit database and message archive to support message tracking.
    • Fire and Forget. Use of modern message protocols allows use of end to end acknowledgements, which in turn enable detection of lost messages. M-Switch supports this as described in the whitepaper [Using Message Acknowledgements for Tracking, Correlation and Fire & Forget].
    • Message Transfer View. When operating over fast networks, message queues rarely build up, and message delays can be usefully monitored in the default MConsole operator view. For slow networks, queues can easily build up under normal operating conditions. MConsole Message Transfer View gives an operator view of this and control of messages in the queue, for example to delete messages from the queue. Isode provides two variants of this view, one oriented towards ACP142 and the other to ACP127.
    • ACP127 Circuit monitoring allows detailed monitoring of ACP127 circuits.

    Use of Newer and Faster HF Waveforms

    BRASS currently uses the STANAG 4285 waveform, which has a maximum speed of 2400 bps. It would be straightforward 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 120 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.

    A simple mechanism to work out the best speed would be to make measurements on a land-based receiving station at suitable distance in a similar manner to OTAM. A more sophisticated approach would be for each ship to use the ship to shore link to send information on link quality for each of the different broadcast frequencies. This has a number of advantages:

    • It will allow a calculation based on all receivers.
    • It can allow for a model where ships use the "best frequency", so speed needs to consider only the ships using a given frequency.
    • It gives a framework for more sophisticated use of the various frequencies and sending different traffic over the multiple broadcast frequencies.

    When ships are operating in EMCON, it will be important to choose broadcast transmission speeds where there is high confidence of successful message transfer. The approaches discussed here can enable mixed EMCON and normal operation, and may also enable sharing of resources between BRASS and general purpose message transmission over HF.

    Improving Ship to Shore Links

    There will be a limited number of HF channels available for use with ship to ship and ship to shore traffic. There needs to be an approach to use these channels efficiently and automatically. Three directions are identified which may be sensible directions for BRASS.

    1. Use standard HF Automatic Link Establishment (ALE). There is a sophisticated set of standard protocols which much deployment experience. It makes sense to utilized this.
    2. Develop an ALE approach specific to BRASS, drawing on standard ALE, and aspects of the BRASS configuration which enable specific optimizations. In particular:
      • The broadcast channel would allow for easy sharing of frequency availability information, using a protocol like FAB. This protocol could run over STANAG 5066 non-ARQ and be multiplexed with organizational messaging and other applications.
      • The broadcast channel could be used to share reservation time slots, to avoid conflicts from ship-oriented transmissions.
      • The separate transmit site would enable frequency sounding of multiple frequencies to occur in parallel with transmissions of messages on other frequencies.
    3. Use STANAG 5066 Annex L, which defines a wireless ring token approach that allows multiple nodes to share a single frequency. It would be possible to set up one or more rings, each comprising the shore and a set of ships. This would allow sharing of a limited set of frequencies. A benefit of this approach is that it would enable flexible transmission, including multicast, between all ring members.

    It seems highly desirable to explore this topic further and to investigate new approaches for improving ship to shore and ship to ship communication.

    Larger Messages

    Legacy BRASS is based on organizational messaging using ACP127. This paper has looked at how the central organizational messaging service can be moved to use modern messaging standards. Improving speed and ship to shore communications will enable a number of other services.

    Faster links will enable larger messages, and in particular messages with attachments. It will be straightforward to exchange documents and images. At the faster HF speeds it should also be possible to send short videos and voice messages as attachments to messages.

    XMPP and Operator Order Wire

    Instant messaging and group chat is an increasingly important military communication. This is described on the Military Instant Messaging page. XMPP can be supported over HF using STANAG 5066, as described in the Isode whitepaper [M-Link Support for XMPP over Constrained Networks]. Adding this capability to BRASS seems highly desirable.

    STANAG 5066 provides a basic chat capability, called "Operator Order Wire" in the original STANAG 5066 specifications and BRASS documents and called "Operator Chat" in more recent versions of STANAG 5066. This allows operators to communicate in a simple manner. This capability is mandatory in many recent BRASS requirements.

    Isode provides this capability in its STANAG 5066 Console tool. This would be a simple way to address the requirement.

    Isode's M-Link product supports a direct gateway to HF Operator chat, connecting to STANAG 5066 using SIS and mapping the gateway to XMPP, which is the NATO standard for real time chat. This enables use of a fully capable XMPP client such as Isode's Swift Client or NATO's JChat. It enables multiple users on each node to see the chat. We see this as a superior approach to addressing the requirement.

    WBHF and Video

    When BRASS is able to move to WBHF speeds, this will open up further possibilities. In particular, it should be possible to stream video over the BRASS broadcast. Use of STANAG 5066 would enable video to be multiplexed with other services.

    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.

    The BICC software is provided free of charge for NATO BRASS projects. However, it would have high costs for a system integrator attempting to use it for several reasons: the BICC software comprises around 30 programs and 70 drivers written in Visual Basic 6.0 (unsupported by Microsoft since 2008) running on Windows 2003 (support ends in 2015); and there is no vendor support. As well as being expensive to deal with, the BICC software does not provide a path to move forward.


    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. As well as supporting legacy BRASS functions, Isode's products feature newer technologies including use of ACP142 and Message Encryption.