STANAG 5066, Profile for High Frequency (HF) Radio Data Communication, is a NATO standard defining a layered suite of protocols for beyond-line-of-sight (BLOS) HF radio data communication.
The STANAG 5066 protocol has been evolving since 2000 when it was first released. This first release standardised communication in narrowband HF channels with a limited number of stations. Later editions addressed growing network sizes using additional channel-sharing protocols and automatic channel selection using ALE. In the latest revision (Edition 4), the standard caters for wideband radios supporting channel bandwidths up to 48 kHz, providing data rates up to 240 kbps. Furthermore, the standard addresses routing, for partially connected networks, and security, for a transmission security.
The STANAG 5066 protocol ensures reliable data delivery over lossy HF channels, where corrupted data is automatically resent using an Automatic Repeat reQuest (ARQ) protocol. In broadcast-only networks, multiple stations can be addressed simultaneously, and data is repeated multiple times to reduce the probability of errors.
The STANAG 5066 protocol can also adapt to varying channel conditions by dynamically changing either the data rate or the channel. The stations continuously monitor the quality of the received and acknowledged data, and choose either higher or lower data rates during transmission. When channels deteriorate beneath an acceptable quality of service, the protocol can leverage the ALE function of the modem to switch to a different channel with potentially better channel conditions.
For multiple stations sharing a fixed frequency, access to the channel can be regulated using the CSMA listen-before-transmit protocol, or a Wireless Token Ring protocol. These protocols ensure that collisions are minimised, reducing the need for retransmissions.
Partially connected stations are also supported by means of a routing feature. Stations that do not have direct connectivity can still exchange data through other stations in the network.
The protocol caters for a large number of waveforms suitable for various deployment scenarios, such as shore-to-ship broadcast and ship-to-ship ARQ.
The versatility, efficiency and widespread availability of the STANAG 5066 protocols have led to their use in a large number of naval and strategic deployments. It supports both ARQ and non-ARQ (broadcast) communication and provides network-to-network data communications over HF by creating links and managing data transfer between nodes.
The STANAG 5066 makes provision for various data services, where each data service is assigned a specific data port on the S5066 protocol stack. These services run concurrently. The following table lists the available services:
| STANAG 5066 Services (Standard) | |
| Serial Messaging (ACP-127/COSS) | The COSS Client provides a simple messaging service for bandwidth-constrained networks. Suitable for ARQ and broadcast networks. The COSS Client is included in BRASS/BRE1TA and is widely deployed. COSS is retained in STANAG 5066 Edition 4. |
| Operator Chat (HF Chat) | Provides a very basic messaging service that can be used for informal point-to-point or broadcast communications. HF Chat requires minimal configuration and does not rely on additional software. This is an optional component. |
| Internet Chat (XMPP PEP, IP Client) | Future Service. |
| Push Email (CFTP and HMTP) | The CFTP and HMTP clients provide push email functionality over HF, which is required for BRASS / BRE1TA. The HMTP and CFTP clients are widely deployed. The CFTP Client supports compression and can optimise email transfer significantly. The HMTP Client does not use compression, and therefore supports “Delivery with Errors”, which allows partially received emails to still be passed on to the client. The Push Email service can be used to send emails either directly to the intended recipient or a central HF POP server. |
| Pull Email (HF POP) | Pull Email relies on a central server to host emails for the network. HF POP is typically deployed where it is expected that the network is not fully connected and nodes will not always be able to reach each other directly. Pull email allows clients to selectively download emails when convenient. |
| UDP/IP Data (HF IP Client) | The UDP service is provided using the HF IP Client, which is a BRE1TA/BRIPES requirement. UDP is a connectionless protocol with minimal overhead. Because of this, UDP applications are typically more prone to work over HF IP. UDP applications can leverage the bulk transfer of S5066, as there is no window that limits the data in any way. |
| TCP/IP Data (HF IP Client with IP PEP) | The TCP service is provided using the HF IP Client, which is a BRE1TA/BRIPES requirement. The performance of the TCP service is usually not very good over HF due to high latencies. The high latencies also typically limit the amount of queued data. When combined with the RapidM IP PEP, the performance of TCP is similar to that of UDP. The TCP service could be used for various services, including standard SMTP, FTP and HTTP. |
| STANAG 5066 Services (RapidM Proprietary) | |
| File Transfer (FTP PEP/RCOP) | The RapidM Proprietary FTP service is a proxy for COTS FTP Clients (e.g., FileZilla). The FTP Proxy can optimise the transfer of files using compression, as well as improve the file browsing experience presented to the COTS FTP Client. Future Service. |
| Web Browsing (HTTP PEP/RCOP) | The RapidM Proprietary Web Browsing Proxy is used with COTS Web Browsers (e.g., Firefox / Chrome). The Web Browsing Proxy optimises the transfer of web traffic by using lossless (e.g., text content), and lossy compression (e.g., reduced quality of images). Furthermore, the number of back and forth transmissions are reduced by fetching expected additional resources before they are requested by the browser. Future Service. |
Table 3: STANAG 5066 3 and 4 Services based on NATO BRASS, BRE1TA and BRIPES and RapidM Proprietary