AEDP-18 NATO standard ISR streaming services

What it is

AEDP-18, NATO Standard ISR Streaming Services, is the Allied Engineering Documentation Publication that specifies the "CSD Stream Server", the service through which NATO and coalition intelligence, surveillance and reconnaissance (ISR) systems share streaming sensor data. It covers three kinds of stream: motion imagery (full motion video), ground moving target indicator (GMTI) tracks, and Link 16 tactical data. It complements AEDP-17, NATO Standard ISR Library Interface, by adding a streaming-specific interface on top of that document's catalogue and query model, and both are proposed for agreement under STANAG 4559. This is Edition A, Version 1, promulgated 28 March 2018.

Unlike many of the standards in this catalogue, AEDP-18 is not a management-system or audit document. It is an engineering specification for software: it defines XML schemas, WSDL service contracts, data models and wire formats that a CSD Stream Server, a sensor feed, or an exploitation system has to implement. The organisation it reaches is whoever designs, builds or configures one of those components, typically a defence contractor or system integrator working on a coalition ISR programme, and it reaches that organisation through a contract or interoperability requirement that invokes STANAG 4559 or AEDP-18 directly, not through a general obligation.

Six interfaces around one server

A CSD Stream Server must support at least one of the three stream types and provides up to six interfaces. Five are mandatory: Publish, through which sensors declare a new Live Stream and post periodic metadata updates; Query, through which exploitation systems discover Live Streams and search Recorded Streams using the Boolean Query Syntax; Controller, through which exploitation systems request relay of a Live Stream or replay of a Recorded Stream; an NSILI Bridge, which records minimal proxy metadata in an associated NSIL library so a task or an intelligence report can be linked back to the stream it came from; and Replication, through which servers exchange metadata with each other so each holds a representation of the full stream catalogue for the coalition enterprise. The sixth, Notification, is explicitly optional, and its requirements apply only where a server chooses to implement it.

The data model, and what changes per stream type

Every metadata attribute in the CSD Stream Server Data Model falls into one of three categories: fixed by definition, fixed by business rule, or genuinely dynamic during the life of the stream. The Publish Interface enforces this distinction directly: a notification is discarded if it is missing a mandatory attribute, or if it tries to change an attribute the data model treats as fixed. A stream's status of NEW, CHANGED or OBSOLETE tells a receiving server whether a sensor is starting, updating or ending a stream, and every server must support the feature the document calls "<forward compatibility>", meaning it can accept and carry metadata extensions it does not itself define, without silently dropping them.

The three stream types are not interchangeable. Downloaded motion imagery must be encoded to the STANAG 4609 motion imagery standard, and replay follows the clip-boundary rules in AEDP-8 so a receiving client can begin decoding immediately. Downloaded GMTI data must be STANAG 4607-format binary data with no padding between packets, and on replay the releasability, mission and job segments must arrive ahead of the dwell data they describe. Link 16 is the outlier: because there is no single originating sensor, the local CSD Stream Server records Link 16 traffic automatically rather than through the Publish Interface, this version of AEDP-18 does not support replicating Link 16 metadata between servers at all, and there are no specific replay requirements for it. Getting these differences right matters for anyone building a server or client that has to handle more than one stream type.

Replicating metadata across the coalition network

Because a coalition ISR network spans multiple nations and sites, AEDP-18 spends a full annex on how CSD Stream Servers keep each other's catalogues in sync over a Wide Area Network. Every server must implement the Replication Service Interface, exchanging only the change in metadata since the last message rather than full state, and must support Bridgehead Routing so a message received from one peer is also forwarded to every other configured peer. Three deployment modes are mandatory to support: Standalone, with no outbound replication at all; Bridgehead, running in a full or partial mesh; and Read Only, accepting incoming replication only. The specification also sets a concrete non-functional requirement, a sustained throughput of up to 475,200 replication messages per day, derived from an example deployment of five motion imagery sensors updating once a second and five GMTI sensors updating every ten seconds, and it defines an eight-step process for bringing a new server into an existing network using a one-off synchronisation file rather than waiting for it to catch up organically.

The Stream Controller Service Interface, defined in a dedicated annex, is what an exploitation system actually calls to start or stop watching a stream: every operation must carry a username and password under the security profile from AEDP-19, replay of multiple streams together must preserve their original relative timing rather than playing them one after another, and a second call to stop a replay that has already stopped has no effect.

What AEDP-18 does not cover

AEDP-18 names no certification body, no notified body and no government surveillance scheme, and it does not describe an interoperability testing programme of its own; its only conformance language is the standard software-engineering convention of RFC 2119 key words (MUST, SHALL, SHOULD, MAY and so on), which an implementer applies to its own design. It also assumes, rather than defines, a working NSILI environment under AEDP-17 and the pub-sub and security services of AEDP-19, and it assumes sensors and exploitation systems that already produce or consume STANAG 4609, STANAG 4607 or STANAG 5516 data in the first place.

How you get it

AEDP-18 is published by the NATO Standardization Office. Like every NATO standardization document it is free of charge; the Standardization Document Database is the authoritative source, and NATO nations' own standardization authorities can also provide a copy. We credit NATO for the catalogue and neither sell nor host a copy ourselves.

Standards it references

• AEDP-17Binds
• AEDP-19Binds
• STANAG 4607Background
• STANAG 4609Background
• STANAG 5516Background