Part 03 — Architecture, Deployment Modes and Transport BaselineLink to the section Part 03 — Architecture, Deployment Modes and Transport Baseline#

Maturity: Draft · Profiles: all

3.1 OverviewLink to the section 3.1 Overview#

flowchart TB
    accTitle: Three transport planes, one device interface
    accDescr: The UNIVIP Device connects the vehicle's native interface to a Client. HTTPS REST carries configuration and commands; a secure WebSocket carries telemetry, events, signaling and status; WebRTC carries live video to the Client.
    V["Vehicle controller, camera and payloads"] <-->|Native protocol or SDK| D["UNIVIP Device"]
    D <-->|Configuration and commands| R["HTTPS REST"]
    D <-->|Telemetry, events, signaling and status| S["Secure WebSocket"]
    D -->|Live video| W["H.264 / WebRTC"]
    R <--> C["UNIVIP Client: VMS, command platform or recorder"]
    S <--> C
    W --> C

The Device is a software role that can run in firmware, a controller or a gateway. The three planes serve different jobs: REST configures and commands, the session channel reports real-time state, and WebRTC transports media. REST can be forwarded over the session channel as described in §3.3.

UNIVIP has three planes:

JSON (RFC 8259, UTF-8) is the mandatory serialization on the configuration and real-time planes. A Protobuf binding will be published as a non-normative annex once the JSON model is stable (ADR-0005).

3.2 Deployment modesLink to the section 3.2 Deployment modes#

A device MUST behave identically toward clients regardless of mode. The mode is declared in the capability document (device.implementation_mode) for information only.

A gateway MAY represent many aircraft. Each aircraft is a distinct UNIVIP Device with its own device_id; the gateway MAY multiplex several devices over one session channel using the device_id member in every envelope (Part 05).

3.3 Connection directionLink to the section 3.3 Connection direction#

Per ADR-0001 the normative connection model is device-initiated:

1. The device is configured with (or discovers) the client's UNIVIP endpoint: an HTTPS base URL.
2. The device authenticates (Part 13) and opens the session channel to the endpoint.
3. The client reaches the device's REST resources through the client-hosted endpoint, which forwards each request to the device as a request envelope over the session channel and returns the device's response (Part 05 §5.5.1), or directly over HTTPS if the device also exposes a listener and the capability document says so (transports.rest.device_hosted).

To keep the REST surface identical in both cases, every REST path is relative to a base of the form /univip/v1/devices/{device_id}/.... A device that hosts its own listener serves exactly those paths; a client-hosted endpoint serves the same paths and forwards them. A device that does not host a listener MUST support the session proxy (transports.rest.session_proxy: true); a device that hosts one SHOULD support it too, because vehicles on cellular or satellite links are rarely reachable by inbound connections.

Devices on a local network SHOULD also announce themselves with DNS-SD (Part 05) so a client can discover them and supply the endpoint.

3.4 Timing and clocksLink to the section 3.4 Timing and clocks#

• All timestamps on the wire are RFC 3339 UTC with at least millisecond precision (2026-10-15T10:32:15.125Z).
• A device MUST maintain a clock disciplined by GNSS, NTP or PTP and MUST declare its time source and estimated accuracy in telemetry time.source and time.accuracy_ms.
• Media time to wall-clock mapping is defined in Part 09. Profile S requires that a client be able to place any telemetry sample on the media timeline to within 100 ms.

3.5 Multi-client and arbitrationLink to the section 3.5 Multi-client and arbitration#

A device MAY hold sessions with several clients simultaneously (for example a site VMS and a central command platform). Telemetry, events and media are available to all authorized clients. Control is arbitrated by control leases (Part 11); camera leases and vehicle leases are independent.

3.6 Relationship to ONVIFLink to the section 3.6 Relationship to ONVIF#

Where ONVIF defines an equivalent concept, UNIVIP keeps the semantics so that a gateway can expose one vehicle both as a UNIVIP Device and as an ONVIF device:

Full mappings are in Annex A.