The NATO Message Catalogue — formally Allied Data Publication 34 (ADatP-34) — is the normative reference for the data structures used in NATO command and control message exchange. It defines the information objects, their attributes, permitted value sets, and the relationships between them that underpin C2 message exchange across the Alliance. For software developers building systems that must exchange data with NATO C2 infrastructure or with national systems implementing NATO standards, ADatP-34 is a mandatory reference — and one that rewards careful study rather than superficial acquaintance.

What ADatP-34 Is and Its Role in NATO C2

ADatP-34 is published by the NATO Communications and Information Agency (NCIA) and is maintained as a living document with regular updates. It is formally titled the "NATO Message Catalogue" because it catalogues all message types used in NATO C2 operations: operational reports, orders, intelligence messages, logistics requests, air tasking orders, maritime situation reports, and many others. Each message type in the catalogue is specified with its data fields, data types, mandatory and optional elements, and business rules governing valid field combinations.

The Catalogue is used as the normative data source for two related but distinct purposes. First, it defines the messages that human operators send over NATO communications networks — the content and format of an operations report sent over the NATO SECRET WAN must conform to the ADatP-34 specification for that message type. Second, it provides the data model from which machine-readable data exchange formats are derived: the MIP (Multilateral Interoperability Programme) data model for ground force C2 data exchange is directly derived from ADatP-34 message content, as are the JC3IEDM (Joint Consultation, Command and Control Information Exchange Data Model) and its successor, the NATO C2 Information Exchange Data Model (NC2IEDM).

This dual role means that ADatP-34 knowledge is applicable both to developers building message handling systems (parsing and generating structured C2 messages) and to developers building data model implementations (designing database schemas or service APIs aligned with NATO data exchange standards).

Key Message Types: ORBAT, Tracks, CAS, Logistics

The Catalogue contains hundreds of message types. A practical implementation approach starts with the message types most relevant to the application domain. The most widely implemented message types fall into four categories.

Order of Battle (ORBAT) messages describe the composition and disposition of military forces — who is where, what equipment they have, and how units relate in the command hierarchy. The ORBAT message family includes the Unit Disposition Report (UDISREP), the Equipment Status Report, and the Commander's Appreciation of the Situation. ORBAT data drives the force display layer of any C2 application and is the primary input to strength calculations and logistics planning tools.

Track messages carry positional information for entities — vehicles, aircraft, vessels, and hostile contacts — in real-time or near-real-time. The track message family includes Air Situation Report (AIRSIT), Maritime Surface Summary (MARSURSUM), and the Ground Situation Report (GROUNDSIT). Track data is the primary input to the Common Operational Picture and is typically transmitted at high frequency (aircraft tracks every few seconds, ground entity tracks every 30–60 seconds depending on movement state).

Close Air Support (CAS) messages coordinate the employment of aircraft for ground support — one of the most protocol-intensive processes in joint operations. The CAS message family includes the Air Support Request (AIRSUPREQ), the CAS Brief, the BDA (Battle Damage Assessment) report, and the 9-line CAS brief format. CAS automation is a high-priority integration requirement for any joint fires application.

Logistics messages cover supply requests, medical evacuation coordination, maintenance requests, and supply status reporting. The logistics message family is large and complex, covering tactical logistics coordination from individual unit supply requests to theater-level sustainment planning. For developers, the most frequently implemented logistics messages are the Request for Supply (REQSUP), Supply Situation Report (SUPSIT), and MEDEVAC request messages.

Versioning reality: ADatP-34 editions are not backward compatible in all areas. A system built against Edition 5 may encounter Edition 7 messages from a coalition partner with changed field definitions or new mandatory elements. Defense software teams should implement message version detection as a core architectural feature — not an afterthought — and design message parsers to handle graceful degradation when encountering unknown fields from later editions.

Parsing and Serialization: Libraries and Approaches

ADatP-34 messages are expressed in multiple syntactic forms depending on the transport network and the era of implementation. Legacy NATO networks use Variable Message Format (VMF) — a compact binary encoding optimized for low-bandwidth tactical radio links. Modern IP-based networks increasingly use XML encoding conforming to the NATO XML Message Specification (NXMS), which provides the same message semantics as VMF but in a human-readable, schema-validated form. Developers may need to handle both forms, particularly in systems that bridge legacy radio-based networks with modern IP infrastructure.

For VMF parsing in C++ and Java, the primary commercial libraries are provided by Cubic Defense Systems and Northrop Grumman's Battle Management Solutions; open-source alternatives are limited and typically incomplete in message coverage. For XML/NXMS messages, standard XML processing libraries (libxml2 in C++, JAXB in Java, lxml in Python) are adequate, but the ADatP-34 XML schemas must be obtained from NCIA and referenced correctly in the parsing pipeline. Schema validation during parsing is mandatory for operational systems — silently accepting malformed messages creates data integrity problems that are difficult to diagnose in production.

Code generation from the XML schemas (using tools such as Apache XMLBeans or JAXB's xjc compiler) produces typed Java or C++ classes for each message type that eliminate manual field parsing and provide compile-time type safety for message field access. This approach is strongly recommended for new development; hand-coded parsers for ADatP-34 message types are expensive to maintain across catalogue editions.

Versioning Challenges with Different Catalogue Editions

ADatP-34 is updated regularly — the current edition as of 2026 is Edition 9. Each edition introduces new message types, modifies existing message structures, and occasionally deprecates or changes the semantics of existing fields. Coalition exercises routinely involve systems built to different catalogue editions, creating compatibility challenges that must be managed at the application layer.

The practical approach is to implement a message version negotiation layer: when a communications session is established with a peer system, the systems exchange catalogue edition capabilities and agree on the maximum edition they can both support. Messages are then generated at the negotiated edition level. This requires maintaining edition-specific message serializers — not just a single serializer updated to the current edition — which adds complexity but is unavoidable for systems that must interoperate with a diverse set of partner systems across the coalition.

Catalogue edition management is also a configuration management challenge: the ADatP-34 XML schemas for each edition must be version-controlled in the system repository, the parsing library must be edition-aware, and regression testing must cover interoperability with previous editions that partner systems may be running. Teams that treat catalogue edition management as a minor version control task routinely encounter integration failures in coalition exercises that are expensive to diagnose and correct under exercise time pressure.