A High-Level Overview of a Television Campus with ST 2110

Summary

• Campus architecture: Single-fabric design with PTP, media, and control planes
• Sources & destinations: Cameras, encoders, playout as sources; monitors, decoders, recorders as destinations
• Media flows: ST 2110-20 (video), ST 2110-30 (audio), ST 2110-40 (ANC/data), all over RTP multicast
• PTP: IEEE 1588-2008 PTPv2 with grandmaster, boundary clocks, and sync to every device
• Switch orchestration: NMOS IS-06 / SDN for flow provisioning; IGMP, PIM, QoS on switches
• Switch design: VLANs, DSCP mapping, PTP-aware ports, and full configuration examples

Note: This article describes a full end-to-end ST 2110 television campus: timing (PTP), sources/destinations, switch orchestration, and concrete switch structures and configurations. It complements SMPTE ST 2110 basics, routing and switch config, NMOS control plane, and monitoring.

1. Introduction: What Is an ST 2110 Television Campus?

An ST 2110 television campus is a facility where live video, audio, and ancillary data are carried over IP using the SMPTE ST 2110 suite. Every device—cameras, switchers, monitors, recorders—is an IP endpoint. Timing is provided by PTP (IEEE 1588). Switches forward multicast RTP streams; orchestration (e.g. NMOS IS-06 or SDN) decides which flows go where.

This article targets broadcast IT / network engineers who already know the basics of SMPTE ST 2110, multicast, VLANs, and PTP. It does not introduce ST 2110 from scratch; instead, it focuses on campus-level architecture and flow diagrams you can reuse in real designs.

To build it correctly you need:

1. PTP everywhere so all streams share a common clock (ST 2110-10).
2. Sources that send ST 2110-20 (video), 2110-30 (audio), 2110-40 (ANC/data).
3. Destinations that receive and optionally combine these flows.
4. Switches with multicast (IGMP/PIM), QoS, and PTP support.
5. Orchestration to create and tear down flows (NMOS IS-06 or SDN) so sources and destinations are wired logically.

This article ties these into one design and gives concrete switch configs and Mermaid diagrams.

2. High-Level Campus Architecture

2.1 Three-Plane View

Think of the campus as three logical planes that share the same physical network:

• Control plane: NMOS (IS-04/IS-05) for discovery and connections; IS-06 or SDN for switch orchestration (which multicast groups/ports to enable).
• Timing plane: One PTP grandmaster; boundary clocks in the fabric so every link has accurate time (required for ST 2110).
• Media plane: Sources send RTP multicast; switches replicate to destinations; no single choke point.

2.2 End-to-End Block Diagram

Sources and destinations connect at the access layer; core switches do multicast routing and can host boundary clocks. Orchestration configures the core/access so that only the desired flows reach the right ports.

3. PTP (Timing) Architecture

ST 2110 requires synchronized time on every sender and receiver (ST 2110-10). That is done with IEEE 1588 PTPv2.

3.1 PTP Roles and Hierarchy

• Grandmaster: Top of the tree; typically GPS or redundant PTP source.
• Boundary clocks: Switch (or dedicated appliance) that has a PTP port toward the GM and downstream PTP ports toward other BCs or end devices. It terminates PTP on the upstream port and acts as master on the downstream ports.
• End devices: Cameras, NDs, monitors, etc., run PTP slave and lock to the nearest BC (or GM in small setups).

3.2 PTP and the Switch Fabric

Switches that run PTP can operate as:

• Boundary clock (BC): Recommended at aggregation/core so every downstream segment gets a local master and hop count stays low.
• Transparent clock (TC): Corrects residence time in PTP messages; optional, often used when the switch does not need to be the time master.

For a television campus, BC at core/aggregation is the usual choice. Diagram:

PTP is usually carried in a dedicated VLAN (e.g. VLAN 2) and optionally with DSCP 46 so QoS gives it highest priority.

4. Sources and Destinations

4.1 Source Types

Each flow is one RTP multicast stream (one destination IP + port). A “source” in the control plane (e.g. NMOS) often represents a device that can send one or more such flows.

4.2 Destination Types

4.3 Media Flow Types (Video, Audio, ANC)

• ST 2110-20: Uncompressed video (e.g. 1080p50 ≈ 1.2 Gbit/s per flow). Each video flow is one multicast group.
• ST 2110-30: Uncompressed PCM audio (AES67-compatible). Multiple audio channels can be in one or more flows.
• ST 2110-40: Ancillary data (closed captions, subtitles, VANC). Separate flow(s), often one per video or per channel.

All share the same PTP clock (ST 2110-10); receivers use RTP timestamps and PTP to present video/audio/ANC in sync.

4.4 Bandwidth Planning (Rules of Thumb)

For campus design, rough numbers are often enough to size uplinks and avoid oversubscription:

*Exact values depend on pixel format, bit depth, and protection schemes.
Audio (2110-30) is relatively small in bandwidth but large in multicast group count, which still matters for switch scale.

Why these numbers differ from SDI?

• SDI carries the full raster including blanking intervals (horizontal/vertical blanking) and often embedded audio and ANC in the same signal.
• ST 2110-20, on the other hand, carries only active video pixels; audio and ANC are split into separate 2110-30 and 2110-40 flows.
• That means a “2110-20 HD video flow” bit‑rate is the compressed equivalent of just the active picture portion of SDI, not the entire SDI payload.

So if you compare to “raw SDI line‑rate” numbers, ST 2110-20 bit‑rates may look slightly different; the table above is intentionally 2110‑centric (active video only) for campus bandwidth planning.

These rules of thumb help when:

• Sizing core uplinks: number of simultaneous HD/UHD flows per 10/25/100G link.
• Planning oversubscription: how many access switches or cameras a core link can safely aggregate.

Example campus sizing scenario

• 20 cameras (1080p50) → ~20 × 1.2 Gbit/s ≈ 24 Gbit/s of raw video.
• With playout and multiviewer traffic, you can plan for roughly 8–10 HD cameras per 25G access uplink without stressing the link.
• A 100G core uplink aggregating two such access switches can comfortably carry on the order of 40 HD flows, depending on how conservative you are with oversubscription and headroom.

5. Switch Orchestration (IS-06 / SDN)

Orchestration here means: telling the switches which multicast streams should be delivered to which ports (which sources are “connected” to which destinations).

5.1 Why Orchestration?

Without it, you would either:

• Use any-source multicast (ASM) and let every stream go everywhere (waste of bandwidth and CPU), or
• Manually configure static multicast routes and IGMP/MLD.

With orchestration (e.g. NMOS IS-06 or an SDN controller):

• The controller knows senders and receivers from NMOS IS-04/IS-05 (or another inventory).
• It pushes flow rules into the network: “replicate group G to port P only if there is a subscriber”.
• Result: source-based multicast (SSM) or constrained ASM so only requested flows hit each link.

5.2 Orchestration Architecture

• IS-05: Device-level “connect this receiver to that sender” (unicast or multicast).
• IS-06: Network-level “ensure this multicast group is forwarded to this switch/port”. The controller maps IS-05 connections to (group, port) and configures the fabric.

5.3 What the Controller Configures on Switches

Conceptually the controller programs:

1. Multicast group membership: Which ports should receive which (S,G) or (*,G).
2. QoS: DSCP or CoS for media vs PTP vs control (optional if already done by config).
3. ACL / security: Optional restrictions on who can send to which group.

So the switch structure (VLANs, QoS, PTP) is fixed by design; orchestration fills in the dynamic part (which flows go where).

5.4 IS-06 in Practice (Adoption Reality Check)

IS-06 exists and works, but calling it “widely deployed in the field” still has a few real-world hurdles:

• Specification maturity and adoption: IS-06 arrived later than IS-04/IS-05 and is still less consistently implemented. IS-04/IS-05 are effectively ubiquitous across major broadcast vendors; IS-06 is not at the same level yet.
• Inconsistent vendor support: Many mainstream switch vendors (e.g. Cisco, Arista, Juniper) do not “speak IS-06” natively. In practice you often need an SDN controller or middleware layer that translates IS-06 intents into OpenFlow/NETCONF/vendor APIs, which adds integration complexity.

What do facilities use today instead?

• Receiver-driven IGMP: When a receiver is activated (often via IS-05), the device itself issues IGMP joins/leaves; switches simply enforce IGMP snooping/querier and forward accordingly.
• Vendor-specific network automation: Some deployments use switch-vendor controllers and APIs (e.g. Cisco DNA Center, Arista CloudVision, etc.) to manage multicast and QoS policies.

IS-06 was designed to be a standard bridge between media orchestration and the network. In many real projects, that bridge is still built with a mix of receiver-driven multicast and vendor-specific SDN tooling.

When does IS-06 make sense? (rule of thumb)

• Consider IS-06 when you need multi-vendor orchestration, consistent end-to-end policy (who can subscribe to what), and you already operate (or can justify) a controller/middleware layer for the network.
• Receiver-driven IGMP may be enough for smaller/medium systems where “connect receiver → device joins multicast” covers most workflows and you want minimal integration complexity.
• Vendor-specific SDN can be a pragmatic choice when the fabric is largely single-vendor and you want deep switch features/telemetry with the least glue code.

Deeper dive: If you want IS-06 in the bigger NMOS picture (IS-04/IS-05 interactions, controller architecture, and implementation considerations), see the dedicated NMOS article: AMWA NMOS.

6. Switch Topology and VLAN Design

6.1 Typical Topology: Core + Access

• Core: High throughput, multicast routing (PIM), boundary clocks, link to grandmaster.
• Access: Ports for sources and destinations; IGMP snooping; optional PTP forwarding (if not BC).

6.2 VLAN Plan

A scheme with separate video and audio VLANs:

This separation keeps video+ANC and audio on different broadcast domains while still allowing a common QoS and multicast model.

6.3 VLAN Diagram

Trunk ports between core and access carry VLANs 2, 100, 101, 200; access ports for devices are either untagged in one VLAN or trunk with allowed VLANs.

Note on redundancy: This article focuses on a single-fabric, non‑redundant design for clarity. Full redundancy (ST 2110‑7 seamless protection switching, dual A/B fabrics, dual PTP grandmasters) will be covered in a separate article.

7. Switch Configuration (End-to-End)

Scope note: The configuration below is intentionally a skeleton to support the campus diagrams in this article. For a deeper, switch-focused walkthrough (IGMP/QoS/PTP/VLAN patterns and routing considerations), see: Switch Configurations and Routing Mechanisms in SMPTE 2110 Networks.

Below is a single switch configuration sketch that fits into the campus above. It assumes a Cisco-style CLI; syntax may vary (e.g. Arista, Juniper). The goal is: PTP, multicast, QoS, VLANs.

Vendor-neutral note: CLI syntax here is illustrative. Exact commands and features differ across vendors (Cisco, Arista, Juniper, etc.); always adapt to your platform and software version.

7.1 Base: Hostname, Management, NTP (optional)

1
2
3

hostname ACCESS-SW1
ip domain-name campus.local
ntp server 10.0.0.1 prefer

7.2 VLANs

1
2
3
4
5
6
7
8

vlan 2
 name PTP
vlan 100
 name VIDEO
vlan 101
 name AUDIO
vlan 200
 name CONTROL

7.3 PTP (if this switch is a boundary clock)

1
2
3
4
5
6
7
8

ptp mode boundary
ptp domain 127
ptp priority1 128
ptp priority2 128
clock source ptp
ptp source ip 192.168.2.1
interface range TenGigabitEthernet1/0/1-24
 ptp enable

If the switch is not a BC, only enable PTP forwarding (transparent or disable BC) on ports toward the PTP master and toward devices.

7.4 IP (for PTP and management)

1
2
3
4
5
6
7
8

interface Vlan2
 description PTP
 ip address 192.168.2.10 255.255.255.0
 no shutdown
interface Vlan200
 description CONTROL
 ip address 192.168.200.10 255.255.255.0
 no shutdown

7.5 Multicast (IGMP Snooping + Querier)

Required so the switch only forwards multicast to ports that have requested it (and so orchestration/IS-06 can control who gets which flow).

1
2
3
4
5
6

ip igmp snooping
ip igmp snooping querier
ip igmp snooping version 3
vlan configuration 100,101
 ip igmp snooping
 ip igmp snooping querier

7.6 QoS: Class Maps and Policy

Map DSCP to queues and give PTP and media priority:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

class-map match-any PTP
 match ip dscp 46
class-map match-any VIDEO
 match ip dscp 34
class-map match-any AUDIO
 match ip dscp 26
class-map match-any ANC
 match ip dscp 18

policy-map MEDIA-POLICY
 class PTP
   priority level 1 percent 1
 class VIDEO
   priority level 2 percent 70
 class AUDIO
   bandwidth percent 15
 class ANC
   bandwidth percent 5
 class class-default
   bandwidth percent 9

Apply to ports facing devices and uplinks:

1
2
3
4
5
6
7
8

interface TenGigabitEthernet1/0/1
 description CAMERA-1
 switchport mode trunk
 switchport trunk allowed vlan 2,100,101,200
 mls qos trust dscp
 service-policy output MEDIA-POLICY
 ptp enable
 no shutdown

7.7 Trunk to Core

1
2
3
4
5
6
7
8

interface TenGigabitEthernet1/0/23
 description TO-CORE-1
 switchport mode trunk
 switchport trunk allowed vlan 2,100,101,200
 mls qos trust dscp
 service-policy output MEDIA-POLICY
 ptp enable
 no shutdown

This gives you one consistent switch structure: VLANs 2 (PTP), 100 (media), 200 (control); QoS; IGMP snooping; PTP on all media/PTP ports.

8. End-to-End Flow: One Channel from Source to Destination

8.1 Scenario

• Source: Camera 1 → one 2110-20 (video), one 2110-30 (audio), one 2110-40 (ANC).
• Destination: Monitor wall subscribes to Camera 1 (video + audio + ANC).
• Orchestration: Controller has already created an IS-05 connection and pushed IS-06 flow so the monitor’s switch port receives the three multicast groups.

8.2 Flow Diagram

8.3 End-to-End Component Summary

9. Summary Checklist

Use this as a design checklist for an ST 2110 television campus:

With this, you have a single end-to-end ST 2110 campus: timing (PTP), media (video/audio/ANC), switch structure and configuration, and orchestration, all aligned and ready for production use.

10. Common Issues and Quick Checks