Translation pending for RU — the English text below is canonical.

Use cases · 11 min read

Video wall for NOC: a reference architecture for 24/7 telco operations

Last updated: 2026-05-14

Most "video wall for NOC" marketing copy is a stock photo of operators in front of screens. The actual engineering question is narrower and more interesting: which feeds go on the wall, how do operators interact with them across shifts, what happens when the wall itself fails, and how does the whole thing integrate with the dozen tools the NOC team already uses to do their job. This article lays out a concrete reference architecture for a 24/7 telco NOC — source mix, operator pattern, failover, tooling integration, and BOM.

What makes a NOC wall different

A boardroom AV wall and a NOC wall solve opposite problems. The boardroom wall shows rehearsed content to a passive audience for a finite event. The NOC wall shows continuously updating operational state to a small rotating crew who interact with it for years. Four engineering consequences follow from that difference.

  • Source count is bigger and more dynamic. A typical Tier 2 telco NOC pushes 20-40 distinct sources at peak. The mix changes during incidents — a normally hidden Splunk panel becomes critical for 90 minutes, then disappears. The wall has to absorb that without re-cabling.
  • Operator interaction is constant but light. Boardroom walls are controlled by one presenter at most. NOC walls are touched by every operator on shift — usually through a workstation keyboard, not a tablet. Wall control has to feel like another tab in the operator's ticket tool, not a separate trip to a dedicated console.
  • Failover is non-negotiable. A NOC wall that goes black during an outage is worse than no wall at all — the operator has no fallback while the customer impact is highest. Architecture decisions cascade from this constraint.
  • Audit trail matters more than in any other deployment. When customer ops review post-incident, "what was on the wall at 02:47:13" can be the difference between accountable response time and finger-pointing. The wall has to log its own state, not just the sources it carried.

The source mix in a real telco NOC

The reference deployment we use as a baseline is a 16-display physical wall (4 high × 4 wide, mid-format LCD or fine-pitch dvLED) with the following typical source mix:

  • 4-6 NMS dashboard feeds — SolarWinds Orion, PRTG Network Monitor, Zabbix, or vendor-specific (Cisco DNA Center, Juniper Mist). Usually delivered as a browser source — the wall renders the live dashboard URL directly, no screenshot tooling involved.
  • 3-4 Grafana panels — graphs of throughput, latency, packet loss, infrastructure utilisation. Public-display playlists with auto-refresh are the canonical way to feed these.
  • 2-3 alarm / SIEM streams — Splunk Enterprise Security or Sentinel for cyber events, alongside a traditional fault management console.
  • 2-4 CCTV / facility cameras — physical-security feeds usually arrive as NDI or RTSP. Genetec / Milestone integrations often live here.
  • 1-2 KVM forwards into operator workstations — when a senior engineer wants to share a specific tool window (firewall console, IPAM, ticket system) on the shared wall. IP-KVM is the clean way; HDMI-capture is the legacy way.
  • 1 incident-board tile — a static or slowly-updating panel showing current high-severity tickets, shift handover notes, on-call rotation.

Sum: 12-16 active sources at idle, peaks of 20-25 during major incidents when the operator pulls in additional feeds. The right wall design absorbs the peak without operational tax — adding a source is a few clicks in the wall management UI, not a cable run.

Operator workflow patterns

Three patterns dominate how operators actually use the wall day-to-day.

Pattern 1 — Standing watch

The default view across an entire shift. The wall shows the baseline layout — NMS on the centre, Grafana along the top, SIEM bottom-left, CCTV bottom-right. Operators glance up periodically; the wall earns its keep by being instantly readable from any seat in the room.

Pattern 2 — Incident focus

Major event detected. One operator promotes the relevant source to a large centre tile, dims the surrounding panels, and the wall becomes a shared situational- awareness layer for the rest of the response team. Multiple operators can contribute — adding a fresh Grafana panel with the affected service, dropping in a terminal session via KVM, surfacing a ticket. This is where the "browser-based control" promise actually pays off — every operator can change the wall from their own keyboard.

Pattern 3 — Handover

Shift change. The incoming team needs to absorb context fast. A well-designed wall carries handover state — a recorded shift log on one tile, the pinned incident board on another, an "open items" view from the ticket system on a third. This is one of the underrated wins of software-defined walls: the layout can be a named scene that the outgoing team flips to at the end of shift.

The failover architecture

A 24/7 NOC wall has three obvious failure modes and a fourth one most architectures miss.

  • Wall controller fails. Standard answer: hot-spare controller in N+1 with shared storage on the source configuration. Cutover is sub-30-second once detected.
  • One display fails. Modern displays warn before they fail outright; the wall management software should support marking a tile as offline and reflowing the layout around the gap until the spare display arrives. A wall that leaves a black rectangle at 02:00 because one panel died is a wall the operators stopped trusting at 02:01.
  • Network to a source fails. The corresponding tile shows the last frame for a configurable timeout, then visibly tags itself as "stale" — not black, not the cached frame masquerading as live. The operator needs to see at a glance that this panel is no longer current data.
  • The wall management UI itself fails while the wall keeps running. This is the underrated failure mode. If operators cannot reach the management interface during an incident, they cannot promote sources, change layouts, or surface the right context. The wall keeps showing what it was already showing, which is sometimes worse than nothing. The fix: management plane redundancy at the same N+1 level as the compositor.

Integration with the NOC tool stack

The wall is one screen in a NOC that already has fifteen other tools. The integration patterns that actually work in 2026:

  • PRTG, SolarWinds, Zabbix — public-display URLs with token-based auth, refreshed every 30-60 seconds. The wall renders the dashboard as a browser source.
  • Grafana — kiosk-mode URLs with anonymous-org tokens. Same browser-source pattern, with the additional trick of using Grafana playlists to rotate through a set of panels on a single tile.
  • Splunk Enterprise Security / Sentinel — both expose kiosk-mode dashboards. Splunk has real-time view modes that work naturally as wall tiles.
  • Genetec Security Center, Milestone XProtect — these integrate either as RTSP feeds (most flexible) or via the VMS's own "video wall" plugin (more locked to the VMS family but tighter integration with the alarm system). RTSP is the cleaner long-term answer.
  • Ticket systems (Jira Service Management, ServiceNow, Zendesk) — embedded dashboard views. The "open priority-1 incidents" tile is usually a saved filter rendered through the ticket system's own web UI.
  • SIP / Teams / Zoom call displays — for distributed NOCs, an active conference bridge is often a permanent tile during major incidents. Browser-based call clients handle this without extra hardware.

BOM and 5-year TCO

Applying the math from the TCO breakdown article to this specific 16-display NOC scenario:

  • 16 displays: €32,000- 48,000 in LCD panels, or €60,000- 120,000 in fine-pitch dvLED depending on pitch and brand. Same on either software or hardware architecture — displays are not the differentiator.
  • Software-defined wall (Craft Wall reference): €2,500 perpetual licence + €3,500 primary server (Ryzen 7 + RTX 4070 + 64 GB RAM) + €3,000 hot-spare server in N+1 + €1,500 KVM-over-IP endpoints for two operator workstations. Year-0: ≈ €10,500. Year-1-to-5 ongoing: ≈ €1,500/year on commodity-hardware refresh. 5-year ex-display TCO: ≈ €18,000.
  • Hardware-controller wall (Datapath / Matrox / Barco reference): €15,000-25,000 controller, €6,000 capture cards for 16 sources, €3,000 hot-spare, €4,500/year support contract. Year-3 refresh on EOL'd component: add €10,000-15,000. 5-year ex-display TCO: €55,000-90,000.

The TCO inversion is roughly 4-5× in favour of the software stack for this deployment shape. The article-level general result holds at the project- specific level.

Where Craft Wall fits in a NOC build

The reference deployment above is the canonical Craft Wall use case. The source mix (NMS, Grafana, SIEM, CCTV, KVM, browser-rendered dashboards), the operator workflow (browser control, named scenes, multiple operators contributing), and the failover model (N+1 commodity Linux, displays reflow around failed panels) match Craft Wall's architecture cleanly. The price point sits well below the hardware-controller alternatives and the per-display subscription alternatives. For a Tier 2 telco or a multi-site MSP standing up a new NOC wall in 2026, this is the cleanest match in the market.

It is not the right fit for every NOC. Tier 1 carriers with sub-frame latency requirements on operator KVM, defence and intelligence facilities with FPGA- hardware tender clauses, and 15-20 year support-horizon procurements should evaluate Barco CTRL, WEY smartVISUAL, or other Tier 1 hardware options alongside the software-defined route.

Read next: the TCO breakdown for the BOM math in detail, IPMX vs ST 2110 vs SDVoE for the AV-over-IP transport question, and the interactive TCO calculator for your specific source / display / operator count.

Related reading