Icon-Topo

HF networks provide Beyond Line of Sight (BLOS) coverage for thousands of miles, but a single HF network does not give global coverage. In order to provide communication between ground systems and Mobile Units (MUs) over a larger range, co-ordination between HF Networks is necessary. This white paper looks at what is needed to provide this mobility and how Isode’s Icon-Topo product provides this.

Isode whitepapers are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Application Level Routing

Icon-Topo works by routing at the application level, which optimizes performance over HF.

Why IP level Switching is not Viable for HF

Most mobile networks operate at the IP level. This gives a lot of flexibility and enables a wide range of applications to be used. This is a superficially attractive approach for HF, but the approach is not viable. The basic reason is that applications running over IP over HF will generally have terrible performance. This is described in the Isode whitepaper [Measuring and Analysing STANAG 5066 F.12 IP Client].

The poor performance of IP and TCP layers is compounded by the fact that standard IP application protocols are poorly optimized for HF, so optimized HF protocols have been developed for key applications. For example, there are a number of messaging protocols optimize for HF described in the Isode whitepaper [Messaging Protocols for HF Radio] and XMPP chat has optimized protocols described in Isode whitepaper [Operating XMPP over HF Radio and Constrained Networks].

It is vital to utilize this optimized performance and the only viable way to achieve this is by routing at the application level.

MU/HFAP/FAREP Architecture

There are three types entity used in the Icon-Topo architecture:

Mobile Unit (MU). This is something moving around with HF Communication. An MU is typically a ship or an aircraft.
HF Access Point (HFAP). This is a ground station that is transmitting and receiving HF. This may include broadcast HF.
Fixed Application Routing Entry Point (FAREP). This is a node to which entities that are not aware of MU location send messages to. The FAREP will send messages to the MU through the correct HFAP. Each MU is assigned to a single FAREP.

The key problem to consider is getting traffic from shore systems to an MU. There will be multiple HFAPs, which will typically be a long distance apart, sometimes in different countries. It is important to send traffic for an MU through the HFAP which is best positioned to communicate with the MU. MUs, HFAPs, and FAREPs collaborate based on shared information to make this happen.

Nodes outside the system of MUs/HFAPs/FAREPs are configured to route traffic for MUs to an appropriate FAREP. This enables systems outside to route traffic to any MU without needing any information on MU location. The FAREP will direct traffic to the “right” HFAP (referred to as the primary HFAP for an MU) which will send traffic onwards to the MU.

The above diagram shows how traffic from a strategic node (not aware of MU location) routes traffic from a Strategic Node, through FAREP and HFAP#1 to reach an MU. The FAREP isolates the Strategic Node from routing changes. When an MU switches primary HFAP from HFAP#1 to HFAP#2, routing is changed at FAREP, HFAPs and MU to reflect this, including sending queued traffic from HFAP#1 to HFAP#2.

The core model of routing from MU to shore is the same, but there is an additional option of “Associated HFAP” as shown in the following diagram.

The default approach is that the MU will communicate to shore using the Primary HFAP. However, if the MU determines that it cannot communicate with the primary HFAP, but can communicate with a designated Associated HFAP, it can manually change HF configuration to communicate with a selected Associated HFAP. The associated HFAP will be correctly configured to accept this traffic and route it to Strategic node through the FAREP.

It is anticipated that each FAREP will be operated by a country or international organization that has associated MUs. Countries will typically operate a number of HFAPs. The system is designed to support multiple countries collaborating, so that an MU from one country can have primary and associated HFAPs operated by different countries. This reflects that it is often impractical to achieve sufficient HF geographical coverage using only HF ground stations on national sites.

Icon-Topo Supported Protocols

The Icon-Topo architecture is based on application level switching, to enable optimized performance over the HF links. This section describes support.

Email

Email over IP networks makes use of SMTP (Simple Mail Transfer Protocol). On strategic networks, MUs would be configured in the Domain Naming System (DNS) so that traffic is routed to the correct FAREP. This would use the “MX Record” configuration approach. Configuration of email for systems outside the MU/HFAP/FAREP network is straightforward and simply needs the right DNS configuration.

Communication between FAREPs and HFAPs also uses SMTP. The correct routing is configured by Icon-Topo setting routing configuration in Isode’s M-Switch product.

Communication between HFAPs and MUs (and between MUs) needs to use a protocol optimized for HF, as described in the Isode whitepaper [Messaging Protocols for HF Radio]. Where possible, Icon-Topo will use MULE which operates over ACP 142 which in turn operates over STANAG 5066, for the reasons set out in the white paper. This will generally be the case with systems being driven by Icon-Topo, as Isode’s M-Switch will be used with Icon-Topo. There is also support for MUs not using Icon-Topo and communicating with the CFTP protocol.

Formal Military Messaging (MMHS)

Formal military messaging, referenced in this paper as Military Message Handling System (MMHS) is a key service and Icon-Topo supports this with a similar architecture to the one described for email. NATO specifies STANAG 4406 as the modern protocol to support MMHS. Icon-Topo uses the STANAG 4406 Annex A for the high speed links and STANAG 4406 Annex E over ACP 142 and STANAG 5066 for HFAP/MU communication.

Icon-Topo with M-Switch can also provide MMHS using SMTP based protocols as an alternative to STANAG 5066, as described in the Isode whitepaper [Military Messaging (MMHS) over SMTP].

Icon-Topo also provides shore side support for ACP 127 broadcast, enabling movement of MUs between different boadcast services. Note that MU configuration in support of this is manual.

Technically, it would also be possible to use ACP 127 protocols with Icon-Topo. This is not currently planned due to the technical difficulties of modifying ACP 127 routing. It seems preferable to achieve MU mobility using modern protocols.

Directory Services

Directory services are critical for a range of military services and are fundamental to Icon-Topo operation. Standard directory protocols, in particular LDAP and X.500 are not suitable for efficient operation over HF. So the approach taken for directory services is to replicate directory data to all systems and then use local access to directories with LDAP (Lightweight Directory Access Protocol). The replication approach over HF is built on the messaging approach described.

Each Icon-Topo managed node (MU, HFAP, FAREP) runs an M-Vault server (Isode’s directory server product), which contains both general purpose information such as White Pages information and configuration/operational information in support of Icon-Topo.

Directory replication on shore (all HFAPs and FAREPs) is done with M-Vault multi-master replication of all information. This enables data modification from any shore node.

Replication to MUs is done using Sodium Sync incremental replication over email, to share a subset of this information needed by each MU. This is expected to be all the provisioned users and roles, plus information from Icon-Topo necessary for the MU. This provides an up to date read-only copy of the relevant data in each MU. The details of this replication is described in the Isode whitepaper [Directory Replication by Email and over 'Air Gap'].

XMPP (Instant Messaging)

XMPP (eXtensible Message and Presence Protocol) is the NATO protocol family to provide instant messaging and presence (“Chat”) services. It is becoming increasingly important operationally.

The approach is analogous to messaging, with XMPP Server to Server protocol (S2S) being used for the fast shore links. HFAP/MU links use "XEP-0361: Zero Handshake Server to Server Protocol” plus "XEP-0365: Server to Server communication over STANAG 5066 ARQ” described in more detail in the Isode whitepaper [Operating XMPP over HF Radio and Constrained Networks].

This architecture requires a communication chain of multiple XMPP servers, described as “XMPP Trunking” which is not standard XMPP architecture, but is crucial for deployment with constrained networks and cross domain. It is further described in the Isode whitepaper [Providing XMPP Trunking with M-Link Peer Controls].

Web Browsing and other IP Services

Not every application can have a dedicated optimized application protocol. Isode’s Icon-PEP product supports two options for operating over STANAG 5066.

IP Applications using STANAG 5066 IP Client. In principle, this can be used for any IP application, but in practice needs to be limited to selected applications such as DNS and ICMP Ping, as performance will be poor for most applications.
TCP applications using HF-PEP: STANAG 5066 TCP Performance Enhancing Proxy Protocol (S5066-APP9). This enables effective operation over a wide range of common services, in particular Web browsing and other applications running over TCP and HTTP.

These services are described in more detail in the Isode whitepaper [Measuring and Analysing HF-PEP for TCP communication and Web Browsing over HF].

Icon-PEP works by connecting IP Subnets using IP Routers. It can be seen from the above diagram that MU connectivity is supported using HFAP only – there is no need for the FAREP.

When this is configured without MU mobility, IP routing is typically handled by static routes, with the MU having a fixed default route to shore and shore IP routing fixed to correctly route through the HFAP.

The approach taken for MU mobility is the Icon-Topo will control the MU Icon-PEP so that it always directs traffic to the Primary HFAP. IP routing on the MU will be configured to send all shore traffic (i.e., to other IP subnetworks) to Icon-PEP (MU). Icon-PEP (HFAP) has a Network Address Translation (NAT) capability enabled to support mobility. This NAT function means that shore destinations will see traffic from IP addresses associated with the HFAP and so can correctly route traffic back to the MU.

This approach enables MU initiated traffic to work when MUs move between HFAPs. This direction is the most important. It makes sense to enable an MU user to access a Web site on shore. There is much less motivation for a shore based user to access a Web system on an MU.

Options for Supporting Shore Initiated Services

There are no current plans to support shore initiated services. There are a number of options if this becomes important:

Define a new application protocol to work directly over STANAG 5066 and to use the FAREP/HFAP architecture as appropriate.
To layer the application service over an application that supports shore initiation (e.g., Messaging or XMPP).
To have Icon-Topo configure shore based routing so that IP can be routed to MU IP Subnets through the correct HFAP. This is possible, but adds significant complexity. It also relies on correct IP routing between HFAPs, which may be problematic for HF in different countries or domains.

HF Networks and Frequency Management

The diagrams so far have shown simple HF connection between HFAPs and MUs. MUs and HFAPs are connected by HF Networks, which may be either:

Fixed frequency, possibly with frequency set changing over time.
ALE with a set of frequencies, possibly changing over time.

When there is MU mobility, connection of MUs to HF Networks will change over time. MUs will typically have a single active HF system and connect to one HF Network only. Icon-Topo does allow for MUs with multiple HF Network connections (e.g., a large ship).

HFAPs will generally use separate Receive and Transmit sites, which enables an HFAP to support multiple HF Networks. HFAPs will typically configure HF Networks with suitable parameters and antenna configurations to support target areas and MUs. So when an MU is connected to an HFAP, it will be necessary to also specify the HF Network used.

For an HFAP, each HF network will have a different STANAG 5066 server. Application routing to an MU needs to include selection of the correct STANAG 5066 server. When ALE is used on an HF Network, the STANAG 5066 server needs to be configured with STANAG 5066 to ALE Address mapping for each of the MUs that are on the network (primary HFAP) or may be on the network (associated HFAP). Similarly the associated ALE unit needs to be configured with correct ALE addresses. Icon-Topo will drive configuration of Icon-5066 (Isode’s STANAG 5066 server) which in turn will drive ALE Unit configuration.

Switching to SATCOM and Fast Links

Icon-Topo is designed for supporting MU connectivity over HF. There will be times when an MU has a fast IP link to shore, which might be SATCOM or a fast connection when the MU is in a base location. To support HF, it is important to design a system which will work for HF – it is not viable to switch HF into a system designed for high speed operation. For an HF system it is sensible and desirable to be able to switch to using a fast link when available.

Icon-Topo provides this by an “At Base / SATCOM” option for each MU. When selected, this is applied immediately and will route traffic using fast protocols between HFAP and MU. This provides a straightforward mechanism to utlilize fast links when they are available.

Schedules and Information Sharing

Why Schedules?

Icon-Topo function is based on schedules of changes. When routing changes happen, the timing and ordering of these changes matters. If you get this wrong, there will be traffic loss and routing loops. This means that change timing needs to be carefully co-ordinated.

While systems on shore have fast and reliable communication, HF communication to MUs can be slow and unreliable. The approach to deal with this is to schedule changes in the future and to have a “freeze time” controlling the minimum time in the future that a change is allowed to be scheduled. This “freeze time” allows time for changes to propagate over HF to every affected MU. The exact value of “freeze time” needs to be chosen long enough to ensure reliable propagation and short enough to give operational flexibility. It is envisaged that a “freeze time” of around an hour will be appropriate for typical configurations.

The above screenshot shows how an operator using Icon-Topo can see the schedule of an MU that is moving between a sequence of HFAPs. Note that the scheduled time of each move is shown, and the HF Network used to connect the MU to the HFAP. This schedule allows all nodes to reconfigure routing at the same time. In order to prevent routing loops due to clock skew, the exact time of change for different node types and applications is slightly staggered around this time.

Scheduled move can be added with a forms based or geographical user interface. Icon-Topo will enforce “freeze time” so that changes must be scheduled in the future. Icon-Topo also enforces a minimum time interval between changes, so that changes will generally be grouped.

Use of Directory for Information Sharing

Icon-Topo stores its information in M-Vault which provides a replicated LDAP/X.500 and ACP 133 compliant directory service. This provides a flexible way to store the necessary information, in a manner that can be replicated efficiently to MUs, as described above.

Icon-Topo UI controls information in the directory, which can then be used to update application configuration.

Schedules Layer in Directory

In order to store schedules in the directory, Icon-Topo defines a “schedules layer”, which can wrap information following the directory information model inside a special entry that includes schedule information. This layer allows addition, deletion and modification of scheduled objects, so that time of change can be controlled. The user of this layer can then determine information status at a given time. It can also determine when information is scheduled to change, so that updates can be applied at the correct time.

The directory sees these objects as special Icon-Topo directory entries. The Icon-Topo products see these objects as normal directory entries with an associated validity time.

Configuring Applications

The above diagram shows how the two Icon-Topo servers work. The Icon-Topo Configuration Server provides a Web interface onto the directory that enable status to be viewed and changes to be made. Multiple Icon-Topo Configuration Servers can access the directory, to provide service at multiple locations. Because it provides a Web interface, Web Browsers at multiple locations can access a single Icon-Topo configuration server. This gives deployment flexibility. Clients accessing Icon-Topo Configuration Server are authenticated, with authorization at various levels (including read only) assigned to users.

An Icon-Topo Update Server needs to run on every MU, HFAP and FAREP, in order to update the applications according to the schedules. The Icon-Topo Update Server will read schedule information from the directory and apply this to the local configuration of the following Isode products:

M-Switch (all nodes). Updates ACP 142 routing information and choice of STANAG 5066 server to support both Email and MMHS services. ACP 127 broadcast information is also updated.
M-Link (all nodes). Updates XMPP routing information and choice of STANAG 5066 server.
Icon-PEP (MUs only). Updates configuration to point at primary HFAP. (planned)
Icon-5066 (HFAPs and MUs). Updates HF Network and ALE information. Icon-5066 updates ALE Unit and Radio configurations. (planned)

MU Location and Movement

The best choice of primary and associated HFAPs for an MU is dependent on MU and HFAP location. While HFAPs have fixed location, MUs move around. Icon-Topo knows MU location, which is shown to the operator. There are a number of ways in which MU location and expected movement can be provided. The simplest model is based on external knowledge and operator input through Icon-Topo of the following parameters:

Location (latitude and longitude) at a specified time.
Speed and direction of travel.

Icon-Topo can display this information on all nodes and use it to derive a best estimate of current location.

A second approach is to have the MU communicate its location to shore and have this loaded into the directory. Speed and direction of travel can be specified, or inferred from a sequence of location readings.

A third approach would be to make use of planned course, which may be more complex than simple travel at one speed in one direction. This would need integration between appropriate planning systems and Icon-Topo.

Operator Experience

Icon-Topo provides a Web interface, with different authorization levels, so that the UI can be used for both monitoring and control by different operators.

MU/HFAP/FAREP Configuration

The key components managed by Icon-Topo are MUs, HFAPs, and FAREPs. Icon-Topo provides a form-based interface to configure settings from each of these elements. This is the information needed to configure information in the system components driven by Icon-Topo that changes as MUs move.

Geographical Visualisation

Icon-Topo also provides a Map view that gives a geographical view. This can be scrolled and rotated to provide a convenient view. HFAPs are shown, with variable diameter “ring”, which shows clearly HFAP location and gives a sense of the geographical coverage. MUs are also shown on the map, including:

Current estimated location.
Last reported location.
Direction of travel.
Points where HFAP change is made.

This enables visualization of what is going on. The map can also be used to set location and direction/speed of an MU. It can also be used to schedule change of primary HFAP, with selection based on direction of travel and selection of time in future using a slider. This facilitates easy switching of HFAP, based on anticipated transition between coverage of two HFAPs.

Conclusions

This whitepaper has described how Icon-Topo supports MU mobility, enabling scheduled switching of MUs between HFAPs to provide best connectivity between MUs and shore systems. It enables use of HF optimized protocols between HFAP/MU and supports this communication in a manner that means location of MU is transparent to strategic systems.

Supporting Mobile Unit mobility over multiple HF Networks using Icon-Topo