Ver 1.0 - 17 Aug 2025

Data Link Unique Identifiers and Cross Reference

Introduction

Link-16, VMF and CoT are all data links (or pseudo data links) that provide multiple functions. The main and most common function is dissemination of own position.
Each of these links uses a different method to uniquely identify entities such as platforms, units, individuals and tracks.
Moving Friendly Position information between these different links requires the use of a Cross Reference Table (aka Buddy List in HUNTR).

Background

Link-16 = J-Series Messages as defined in MIL-STD-6016

Link-16 messages are defined in MIL-STD-6016. They are known as the J-Series Messages.
A platform's own position message is called a PPLI (Precise Participant Location Information) and has a different message name depending on the type of platform.
Specifically an Aircraft's PPLI is called J2.2, a ground point is a J2.5, a ground track sis a J2.6, surface PPLI is J2.3 and a Subsurface PPLI is a J2.4
Every participant in a Link-16 network is uniquely identified by a JTIDS Unit (JU) number. JUs are assigned via OPTASK LINK Message. They are Octal.
Surveillance tracks and some other entities are identified by a track number.
An example JU is an octal number such as 172.

J-Series messages were originally designed to be transmitted over a TDMA RF network. They are fixed length BIT oriented messages where data fields that are not used are still sent with the message but are marked as No Statement

MIL-STD-3011 defines how to send J-Series messages over SATCOM (JREAP-A), serial links (JREAP-B) and IP Networks (JREAP-C).
JREAP uses a JREAP Management protocol (also defined in MIL-STD-3011) using X-Series messages to exchange signaling information between JREAP nodes. Every J-Series message sent over an IP network has a JREAP header prepended to it. A single JREAP-C message may contain multiple J-Series messages although the usual case in my experience is one J-Series message per JREAP-C packet.
JREAP-C can use TCP, as well as unicast or multicast UDP.

VMF (Variable Format Message) = K-Series as defined in MIL-STD-6017

VMF messages are defined in MIL-STD-6017. They are known as K-Series Messages.
A platform or entity's Own Position message is called a K5.1. A single K5.1 message may contain the position information for 1 to 64 entities. When it contains more than one position report it maybe referred to as an aggregated K5.1

K-Series messages are almost always preceded by a MIL-STD-2045-47001 Header. For some VMF over CNR nets another standard (MIL-STD-188-220) is involved. However 188-220 is not used for VMF over IP.

In VMF every participant is uniquely identified by a Unit Reference Number (URN). URNs are 24 bit numbers assigned by NORTHCOM. Canada has been assigned a block of URNs and within DND these are allocated by JTDLMC.
In the Canadian Army URNs are assigned to Platforms at Orbat Creation time.
RCAF URNs are (or should be) assigned via OPTASK Link.
An example URN is just a number such as 5,740,000

K-Series messages are designed to be transmitted over low bandwidth VHF nets. Often these are multiplexed voice and data nets (look up V/UHF Line of Sight (VULOS) waveform used by PRC-152/117 and ARC-210). Thus K-Series messages are designed to be small as possible.

When VMF is sent over IP networks a single packet will contain a MIL-STD-2045-47001 header and a K-Series message. Unlike JREAP there is no additional signaling required for VMF over IP. By default VMF over IP is via multicast on 225.0.0.5:1541.

Because VMF messages are kept small the system is augmented with a URN Lookup table. The ULT is defined in MIL-STD-6017. The URN Lookup Table has a row for each URN of some mission or Orbat. The columns provide additional information about a given URN such as Symbol Code, Long and Short Names, Nationality and environment (Army, AirForce, Navy etc). A K5.1 message only identifies the position report as belong to a URN but tells nothing about who that URN is. The lookup table provides this additional information.

CoT (Cursor On Target) = XML Event Schemas as defined in MIL-STD-6090

CoT messages are defined in MIL-STD-6090. They do not have a lettered name like J or K.
An entity's own position message in CoT is called a Position Location Information (PLI).

Every message on CoT is an 'event' and every event has a UID field. The UID is Globally unique name for the
information in this event. UIDs are text strings. MIL-STD-6090 does not specify how to generate a UID, however systems are encouraged to utilize industry standard 128-bit universally unique identifiers (UUID).
Example UID:

uid="d55f2b45-7567-4ca0-81b2-e12fb34e1267"
Different types of CoT messages are called sub-schemas

MIL-STD-6090 standard does not mandate a specific network protocol to use when transmitting CoT messages.

CoT protocol was developed fundamentally to be easy to implement. There are no BIT level data manipulations, no packing restrictions and each data item included in the message is labelled via text (pure XML) or index number (Protobuf).

CoT messages are relatively large XML documents. A PLI can be 600 bytes in size. A couple years ago Google's Protobuf protocol was added to CoT. Protobuf is an industry standard way to encode XML messages as smaller packages. A CoT PLI message converted to Protobuf is about half the size of it's XML version.

In TAK the default CoT SA channel is multicast on 239.2.3.1:6969.

Interoperability

Interoperability between any two or three of these message sets is usually managed through a cross-reference table. Cross reference tables are not defined by any MIL-STD so are always developed by software OEMs.
For example HUNTR introduces the notion of a Buddy List. Sitaware HQ uses a Orbat table. Other OEMs use a cross reference table under the hood but may not explicitly present it to the user.
They are all the same: They have a set of columns and a set or rows. Each row represents a single tactical entity (an aircraft, ship, armoured vehicle, dismounted soldier). There is at least one column for each Data Link subject to cross reference. For example there will be a column for JU, URN, and CoT UID. Other columns may include Call Sign, Console Label, MIL-STD-2525 SIDC, elements of the URN Lookup table, JC3IEDM Entity ID for Sitawaware etc.

The cross reference table is more or less an expanded version of the URN Lookup table mentioned in the VMF section above.

VMF URN Lookup tables are typically created before the start of a mission as part of the planning process. This is the case for the Canadian Army.

Some Cross Reference tables, on the other hand may be partially built prior to a mission but can and are updated in real time during a mission. For example the Buddy List in HUNTR can be updated automatically or manually.

Example use:

Example (simplified) Buddy List

A K5.1 PA message arrives on a VMF link. The URN in that message is 5760201. The application looks 5760201in the buddy list and finds that it represents a LAV6. That LAV6 has a JU of 46543. The application creates a new J2.0 message and populates it with the JU from the buddy list and sends it out over the air. An aircraft receives this J2.0 which it then displays as a friendly symbol on its map.

Similarly a JTAC is receiving PLI messages from ATAK. His application looks up the PLIs in a buddy list and using the JU and URNs in that list is able to forward J2.0 to CAS aircraft over Link-16 and K5.1 to Fire Support Coordination Centre over CNR.

Extra

Both VMF and CoT use symbol codes from MIL-STD-2525.

MIL-STD-2525C is a normal evolution of MIL-STD-2525B where individual map symbols can be defined by a 15 digit Symbol IDentification Code (SIDC).

MIL-STD-2525D (June 2014) is a major revision, almost new version, of the standard that uses 21 digit codes. The Canadian Army currently uses Rev C (15 digit SIDC).