BRE1TA Mobile Unit Capabilities

This whitepaper looks at BRE1TA from the viewpoint of a Mobile Unit, typically a ship or aircraft, communicating over HF. The paper’s first aim is to provide a clear summary of the BRE1TA capabilities and additional capabilities that might be added. The paper is also looking to facilitate the procurement of Mobile Units that will correctly interoperate with BRE1TA shore systems. It does this in two ways:

1. By listing the Isode products needed to provide each of the services described.
2. By specifying the open standards needed to enable accurate procurement that will ensure interoperability.

Overall BRE1TA Model

The BRE1TA Model is illustrated by a screenshot from Isode’s Icon-Topo product. On the ground, there are multiple HF Access Points (HFAPs). Mobile Units (MUs) will communicate with an HFAP that provides a good-quality HF link. A BRE1TA system requirement is to provide the best HF communication to each MU and to optimize load sharing between HFAPs. This is achieved by assigning MUs to HFAPs with scheduled transfers between HFAPs.

This paper looks at the system from the MU perspective, avoiding the significant ground side complexities that will be covered in a companion white paper.

Note: The term HFAP is used here rather than the equivalent NATO term of Broadcast Control Station (BCS), as HFAPs are expected to do point-to-point and multicast communication as well as broadcast and may not do broadcast.

BRASS, BRE1TA, BRE2TA and BRIPES

NATO BRASS is a deployed system described in Isode’s white paper Isode’s Solution for BRASS (Broadcast and Ship to Shore). BRE1TA (BRASS Enhancement 1 Technical Architecture) is the new architecture described in this paper. BRE2TA is an anticipated upgrade that will add new capabilities, in particular, wideband HF.

NATO has procured a BRE1TA system, which is the BRIPES (BRASS IP Enhanced Software) package. This is being delivered to NATO by Leonardo (Italy) using the Isode products described in this paper. The BRIPES project includes the purchase of a shore system for each NATO nation using the Isode products in the BRIPES package.

Isode’s close relationship with the BRE1TA shore systems means that this paper can be definitive on MU requirements to interoperate with BRE1TA shore systems.

STANAG 5066 and Icon-5066

STANAG 5066, provided by Isode’s Icon-5066 product, is central to the operation of a BRE1TA MU.

Modern HF communication uses STANAG 5066 to provide a link layer between applications and the HF modem. STANAG 5066 provides multiplexing, so that multiple applications can share a single HF link, as shown above. The blue boxes show elements provided by Isode, and the green boxes show elements provided by an HF partner.

Icon-5066 is Isode’s STANAG 5066 product. There is a 1:1 ratio between Icon-5066 and modem/radio. Typically, an MU will have one HF radio used for STANAG 5066 and so will need a single Icon-5066. Large MUs, such as a large ship, can have separate Rx and Tx systems that enable support of multiple HF circuits, with each HF circuit needing a STANAG 5066 server. This would allow an MU to communicate with multiple HF networks at the same time.

Modems and Radios

The Isode product set provides everything needed above the modem. Icon-5066 is modem/ALE Unit independent, and a list of supported modems is provided on the Icon-5066 product page. Support for other modems can be added as needed.

A full MU BRE1TA solution needs STANAG 5066 and an underlying HF Modem and Radio subsystem.

The modem will need to support the STANAG 4539 waveform. STANAG 5069 will be needed if Wideband HF (BRE2TA) is used. While other waveforms are supported shore-side, a modern MU is unlikely to need them.

For ALE links, 3G ALE is recommended. 2G ALE is supported shore-side but not recommended. 4G ALE will be needed to support Wideband HF.

Conformance and Interoperability

Icon-5066 conformance is specified here. It supports everything needed for a BRE1TA MU.

The following STANAG 5066 Edition 4 Annexes are required:

• Annex A: SIS
• Annex B: CAS
• Annex C: DTS
• Annex D: Sync Serial Interface
• Annex S: SIS Access Protocol

There are additional requirements, based on the type of HF Network used.

For Skywave networks, ALE is recommended. This requires support for the ALE 1:1 option of Annex B with the IMPLICIT CAS-1 variant.

Fixed frequency networks may also be used, and this is recommended for surface wave networks. Fixed frequency requires use of a MAC protocol, and one or both of the followings is needed:

1. CSMA specified in Annex K is recommended for lightly loaded HF networks.
2. Wireless Token Ring Protocol specified in Annex L is recommended for busy HF networks.

Additional Icon-5066 Capabilities

HF Prediction is used to select the best frequency for use by ALE. HF Prediction is provided by Icon-5066 and is a BRIPES-required additional capability for shore systems. Use of HF prediction is not needed for MU interoperability, but is expected to improve MU performance.

Icon-5066 provides ALE Frequency scheduling, to change frequencies used during the day so that only frequencies suitable for the time of day are used. This reduces ALE linking time. All ALE nodes on an HF Network need to use the same schedule. So, where frequency scheduling is used, it must be supported by all nodes on the ALE network.

Icon-5066 provides support for Wideband HF and 4G ALE, which are not a part of BRE1TA but are expected to be a BRE2TA component.

Crypto Bypass and Data Isolator

Icon-5066 is deployed in the BRE1TA architecture with sync serial crypto between Icon-5066 and the modem. Icon-5066 has a black side “Proxy Modem” component that controls and monitors the Modem/ALE unit. This is critical for the use of ALE and speed control.

Icon-5066 product includes both the red side server and the black side proxy modem. These can be deployed without a data isolator, with Isode’s M-Guard product, or with a different data isolator that supports the Guard Content eXchange Protocol (GCXP) and the Icon-5066 Application Profile.

Applications and Services Overview

A BRE1TA MU needs STANAG 5066. Several services can be run, and the choice will be dependent on the services required by the MU. For each service, this paper gives:

1. References to the description of the services.
2. The Isode product/products needed to support the service.
3. List of key interoperability standards needed to interoperate with a shore BRE1TA service.

The following services should be considered for each MU:

1. XMPP Chat (T-Chat)
2. Web Browsing (T-Web)
3. IP Services and C2.
4. Email (T-Mail).
5. Formal Messaging.
6. Directory
7. Mobility

XMPP & T-Chat

XMPP is the NATO standard for chat, often referenced as the JChat service. T-Chat is the BRIPES XMPP service. Details of XMPP over HF are given in the Isode white paper, Operating XMPP over HF Radio and Constrained Networks.

A BRE1TA MU will need Isode’s M-Link MU Server product for the number of users on the MU.

An XMPP Client will also be needed. There are two good options:

1. Isode’s Swift client. This is provided as part of the BRIPES shore package and may be purchased for MU usage.
2. JChat Client. This is widely used in the NATO JChat service and is provided free to NATO members.

Compliance

For a BRE1TA MU to correctly interoperate with shore systems, a number of XMPP standards are needed. Many of these are detailed in the M-Link Conformance section. They are not repeated here, as they are widely supported. There are three standards which are essential for interoperability, that are not widely supported. These are:

1. XEP-0365 – “Server to Server Communication over STANAG 5066 ARQ”
2. STANAG 5066 Annex W “SIS Layer Extension Protocol” (Ed5 draft). This is used by XEP-0365.
3. XEP-0258 – “Federated MUC for Constrained Environments”

 T-Web & Icon-PEP

BRIPES T-Web service is to provide Web browsing from MUs to shore, a pull service complementing the messaging push services. Detailed description in the Isode white paper “Providing Web Services over HF Radio”.

T-Web is provided by Isode’s Icon-PEP product.

Compliance

Icon-PEP MU BRE1TA interoperability with shore systems requires support for two STANAG 5066 Ed5 (draft) Annexes:

• Annex W: “SIS Layer Extension Protocol (SLEP)”
• Annex X: “HF-PEP: TCP Performance Enhancing Proxy Protocol ”

 C2 and other IP Services

Icon-PEP provides generic IP and TCP services over HF. Although BRIPES only uses this for T-Web, Icon-PEP provides a generic capability to run other IP services. It is anticipated that BRE2TA will add further protocols and support for shore systems.

C2 protocols, in particular Link-16 and TAK, are expected to be needed. Details in two Isode white papers:

• “Link-16 and other C2 protocols over HF Radio”
• “Operating TAK over HF Radio”

These capabilities are provided with Icon-PEP, so no additional Isode products are needed.

Email and T-Mail

T-Mail is the BRIPES Email service. The preferred BRE1TA protocol for email over HF is ACP 142 with MULE (RFC 8494).

The Isode products needed for a BRE1TA MU are:

1. M-Switch User Server with ACP 142 option. This provides message transfer.
2. M-Box. This provides message storage.

In addition, an email client is needed, which can be any client supporting the standard SMTP (submission) and IMAP (access) protocols. Options include:

1. This is being used on the BRIPES reference systems.
2. Although Isode’s Harrier product is oriented to provide MMHS, it can also be configured as a good and viable email client.

Compliance

The protocols needed for interoperability between a BRE1TA MU and shore are:

1. RFC 8494 “Email (MULE) over Allied Communications Publication (ACP) 142”.
2. ACP 142(A) “ P_Mul – A Protocol for Reliable Multicast in Bandwidth Constrained and Delayed Acknowledgement (EMCON) Environments”.
3. STANAG 5066 Annex Q “ACP 142”.

The BRIPES shore systems also support the older CFTP protocol, also known as BFEM (Battle Force Email). This can be used as an alternative, but it is functionally inferior to MULE over ACP 142, and the BRIPES system does not support MU Mobility for CFTP. The compliance is:

1. STANAG 5066 Annex V “COMPRESSED FILE TRANSFER PROTOCOL.”

Formal Messaging

Formal Messaging is the core BRE1TA service, providing support for both modern protocols and ACP 127 legacy compatibility. This is described in the Isode white paper “Isode’s Military Messaging Handling Solution“.

The Isode products needed for a BRE1TA MU are:

1. M-Switch User Server with the following options:
   • ACP 142
   • STANAG 4406
   • Profiler (to provide content-based distribution of organizational messages)
   • ACP 127
2. M-Box. This provides message storage.
3. Harrier: MMHS Client

Notes on ACP 127 messaging:

1. Broadcast Receive, including support for repair of corrupted messages, is handled by M-Switch User Server.
2. Ship-to-shore communication is recommended to be handled by COSS using an ALE circuit, which can be fully automatic. If ALE cannot be used, FAB reception is supported.

Compliance

The protocols needed for interoperability between a BRE1TA MU and shore are:

1. STANAG 4406 Annex E
2. ACP 142(A) “ P_Mul – A Protocol for Reliable Multicast in Bandwidth Constrained and Delayed Acknowledgement (EMCON) Environments”. CCEB
3. STANAG 5066 Annex Q “ACP 142”.
4. ACP 127G
5. NATO BRASS Specifications

Number of Servers

M-Switch, M-Box and Harrier are designed so that multiple services, including a mix of email of formal messaging, can be deployed on a single set of servers. Note that operational and security requirements may require that separate servers are used for email and formal messaging, and also that different security domains may require separate servers.

Directory

Every BRE1TA node needs to have a directory server supporting LDAP and following ACP 133. This is provided by Isode’s M-Vault product. For a BRE1TA MU, M-Vault is usually provided as part of Isode messaging and XMPP product bundles.

It is important to keep directories synchronized, as they are used to hold “global” information, in particular address books. Directory synchronization for a BRE1TA MU makes use of incremental directory synchronization using LDIF and File Transfer by Email.  This is described in the Isode white paper “Directory Replication by Email and over ‘Air Gap’”.

This synchronization needs two Isode products on BRE1TA MU:

1. M-Switch User Server, which includes File Transfer by Email capability.
2. Sodium Sync, which provides the incremental replication.

Compliance

Directory compliance is specified in

• COMMON DIRECTORY SERVICES AND PROCEDURES – ACP 133(D)

Directory synchronization uses:

• RFC 2849 “The LDAP Data Interchange Format (LDIF) – Technical Specification”
• Isode proprietary wrapping to ensure no data loss. This is a straightforward specification that could be shared or published.

MU Mobility and Icon-Topo

A key goal of BRIPES is to support MU mobility. The approach is described in the Isode white paper “Supporting Mobile Unit mobility over multiple HF Networks using Icon-Topo”.

Icon-Topo manages configuration update schedules by information stored in the directory. So, directory synchronization to the MU is essential to support MU mobility.

A BRE1TA MU can support automatic MU Mobility by use of Isode’s Icon-Topo product. Icon-Topo will update the configuration of the following Isode products on an MU:

• M-Switch User Server, to update email and formal messaging routing
• M-Link MU Server, to update XMPP routing.
• Icon-PEP to correctly route IP traffic to the correct shore station.
• Icon-5066 to correctly update ALE addressing

Compliance

Icon-Topo uses Isode-specified directory schema, as there is no suitable open standard available. This may be published in future as an open specification.

Notes on Procurement

A key goal of this white paper is to facilitate the procurement of BRE1TA MUs in a way that will ensure interoperability with shore systems. Isode experience is that procurements will underspecify requirements, leading to systems that do not interoperate. This paper has included two mechanisms that will help ensure interoperability:

1. Identification of the correct Isode products to procure; and
2. Specification of the correct compliance that is needed.