Standards mentioned

• Discovery and Registration: AMWA IS-04 (NMOS registry/query API).
• Connection Management: AMWA IS-05 (connect sender to receiver via SDP).
• Device Control: Open Methods, AMWA IS-12 (generic control API).
• Audio Channel Mapping: AMWA IS-08 (remap audio channels dynamically).
• Topology discovery: LLDP (Link Layer Discovery Protocol for network mapping).

Design steps:

• Select NMOS registry/controller: Open-source (nmos-cpp) or vendor (Evertz MAGNUM, Grass Valley Orbit).
• Plan flows: AMWA IS-04 for registration/discovery, IS-05 for connections, IS-08 for audio mapping, LLDP for topology.

Overall Timeline & Tips

• Total time: 2–3 months for a small facility; 6–12 months for large (design overlaps with build).
• Iterate & Test: Use JT-NM TR-1001-1 guidelines for interoperability; run JT-NM Tested gear.
• Common Pitfalls: Underestimate PTP/QoS setup (causes jitter); ignore security (vulnerable to hacks); skip monitoring (hard to debug).
• Order Rationale from Pyramid: Bottom-up ensures foundations (secure/configurable) support higher layers (sync/transport). But design all in parallel; build sequentially.
• This aligns with the pyramid's dependencie

Additional thoughts about proper use of the full stack

A true SMPTE ST 2110 facility cannot be built without any network or transport layers.

SMPTE ST 2110 is explicitly defined as a suite of standards for professional media over managed IP networks. The core of ST 2110 relies on IP (Internet Protocol) as the network layer and UDP (User Datagram Protocol) + RTP (Real-time Transport Protocol) as the transport/session layers to carry the separate essence streams (video, audio, ancillary data/metadata).

Why it's impossible to eliminate those layers

The standards (e.g., ST 2110-10 for system timing/transport fundamentals, ST 2110-20/21/30/40 for essence mapping) mandate carriage over UDP/IP.

Media is packetized into RTP/UDP/IP packets (often multicast) and transported across an Ethernet-based IP network infrastructure.

Synchronization uses PTP (IEEE 1588) over IP.

Description uses SDP (Session Description Protocol) embedded in signaling over IP.

Without the IP/UDP transport stack, there is no way to route, address, synchronize, or describe the streams as per the ST 2110 specs.

Removing network/transport layers would reduce it to something like raw Ethernet frames or a non-IP protocol — but that would no longer be ST 2110; it would be a proprietary or entirely different system (e.g., reverting to SDI or a custom non-IP transport).

Main restraints/limitations if you try to avoid "full" IP networking

In practice, people sometimes ask about "minimal" or "direct" setups, but these still require IP layers — just tightly controlled ones:

• No public Internet — ST 2110 requires a managed private IP network (low-latency, high-bandwidth, QoS-prioritized, PTP-capable, often non-routed L3 or pure L2 with multicast).
• No non-IP transports — Can't use SDI, ASI, or raw fiber without converters/gateways (which reintroduce IP internally for ST 2110 gear).
• Scale & flexibility severely limited without proper IP networking (e.g., no dynamic routing, NMOS discovery/connection via IS-04/05, multicast IGMP snooping/querier, PTP grandmaster redundancy).
• Interoperability lost — All ST 2110-compliant devices expect IP/UDP/RTP; stripping layers breaks vendor interoperability.
• Bandwidth & timing impossible to guarantee without IP QoS, PTP over IP, and proper network engineering.

In short: ST 2110 = IP-based by definition. A facility without network/transport layers (meaning no IP/UDP) simply cannot be ST 2110 — it would be a different technology altogether, losing all the benefits of IP media (separate essences, routability, scalability, NMOS control). If you're thinking of a hybrid or minimal-IP setup, it's still IP underneath.

What can be confusing is the use of the "PTP short stack" (or "short PTP stack"). In SMPTE ST 2110 contexts it refers to a simplified or hardware-accelerated PTP implementation where the device handles only the essential PTP functions required for basic synchronization, often offloaded to dedicated hardware (e.g., FPGA in NICs or endpoints) rather than running a full software PTP stack on the host CPU.

When it's used

• In high-performance ST 2110 endpoints (e.g., playout cards, cameras, multiviewers, or FPGA-based SMPTE 2110 NICs like those from Macnica, Deltacast, or Intel/Altera solutions).
• When the device needs precise, low-jitter timestamping for RTP packet generation/reception but doesn't require acting as a PTP boundary clock, transparent clock, or grandmaster.
• In setups prioritizing efficiency and low CPU load — common in production gear where the host CPU focuses on media processing (encoding/decoding) rather than networking/timing overhead.
• For non-PTP-master/slave complex roles — e.g., ordinary clocks (simple slaves) that just lock to a grandmaster without advanced features like best master clock algorithm (BMCA) processing or extensive profile negotiation.

Why it's used (advantages/restraints trade-offs)

• Performance & accuracy: Hardware timestamping (often at the PHY/MAC level) achieves sub-microsecond precision needed for ST 2110's tight timing (ST 2110-10 requires ~1 µs alignment for lip-sync across essences). Software PTP stacks can introduce jitter or delay.
• Resource efficiency: Offloads PTP to FPGA/ASIC → frees CPU/RAM, reduces power use, and avoids latency from kernel/user-space handling.
• Simplicity & cost: In leaf/end devices, a full PTP stack (with boundary/transparent clock support, multiple domains, advanced monitoring) is unnecessary overhead when the network already has dedicated grandmasters and PTP-aware switches.
• Restraints/limitations:
• Can't act as a PTP relay or boundary clock (no forwarding/syncing other devices).
• Limited to basic slave/ordinary clock behavior — no redundancy negotiation or complex failover.
• May not support all optional TLVs or profiles beyond SMPTE ST 2059-2 basics.
• In very large/redundant facilities, you still need full PTP stacks on grandmasters, boundary clocks (in switches), and monitoring tools.

Practical restraints for trying a "no-network" ST 2110 approach

• Impossible compliance — No vendor gear would interoperate without IP/UDP/RTP/PTP.
• No essence separation/routing — Video/audio/anc data stay bundled (like SDI), losing ST 2110's key benefit.
• No NMOS/IS-04/05 — Discovery, registration, and connections rely on IP.
• Sync falls apart — PTP needs IP; alternatives like genlock over coax revert to SDI-style.
• Bandwidth/scale issues — Uncompressed HD/UHD needs 1.5–12+ Gbps per stream; without proper IP QoS/multicast, it fails quickly even on point-to-point links.

In short: Use the short stack for edge/media endpoints that just need to stay locked to the facility's PTP grandmaster with maximum precision and minimal overhead. Full PTP stacks are for core timing infrastructure (grandmasters, switches) where advanced synchronization and resiliency features are critical. This is why many ST 2110 NICs advertise "integrated hardware PTP" — that's the short stack in action.