Edge Delivery on
Shared Virtual
Infrastructure.
Live streaming has reached a scale where existing delivery models are under real strain — from occasional large sporting events to regular live programming with predictable high-traffic windows, along with the rise of vMVPD services. The edge compute capacity exists across access networks and metro sites. What’s missing is a shared model — commercial, operational, technical — that lets content providers and CDNs use it on their own terms. The SVTA Edge Working Group is working to define it. This demo illustrates the concepts in the group’s draft Hosted Caches specification.
From one content provider to many access networks. Each shared edge server hosts workloads from multiple tenants — the content provider’s workloads (orange) run alongside others (blue) on the same compute.
Illustrating concepts from the SVTA Edge Working Group‘s draft Hosted Caches specification (work in progress) — the group’s initial focus for defining how content delivery workloads can run on shared edge infrastructure.
The capacity is there. The way to use it isn’t.
Content providers looking to get delivery infrastructure close to viewers today face a choice with no good answer for live streaming at scale:
Commercial CDNs are the default starting point — broad footprint, low integration cost, mature operations. But they offer limited reach into access networks, and delivery runs on the CDN’s stack, limiting adoption of newer low-latency protocols (MoQ, custom UDP, and others) and leaving less of the delivery path in the content provider’s hands.
When a commercial CDN isn’t the right fit, content providers turn to insourcing delivery — running their own cache program — as a strategic option, the path hyperscalers and large-scale content providers have been pursuing. Two complementary approaches exist: content peering arrangements from datacenters outside the access network, and dedicated bare-metal cache appliances placed inside it. Cache appliance programs are harder to scale out than their operators would like — network operators have finite appetite for hosting additional hardware at the edge, and practical limits on the number of cache vendors they’re willing to support, so each deployment tends to be negotiated site by site.
Either way — content peering or bare-metal appliances — a cache program carries heavy opex and an operational load that’s hard to justify for the sporadic traffic peaks live streaming produces. The capital is spent on steady-state delivery but sized for rare events.
No operating model for shared compute
Deploying a workload into someone else’s edge today means negotiating a bespoke arrangement every time. There’s no common understanding of roles, interfaces, or lifecycle — which is what the Edge Working Group is working to establish.
No multi-tenant edge services
Running delivery logic on shared infrastructure requires isolation, orchestration, observability, and routing services designed for many tenants at once. These don’t exist as a standard offering at the access edge today.
Control and protocol flexibility
Low-latency live, cloud gaming, and XR workloads increasingly rely on newer protocols — MoQ, custom UDP stacks, and others — and workload-specific logic. Commercial CDN footprints weren’t built to host tenant code or non-standard delivery paths, and content providers want more of the delivery under their own control, not less.
A multi-tenant operating model for the access edge.
The SVTA Edge Working Group was established in December 2024 to develop technical architecture for making better use of compute, storage, and network resources at the Internet edge. Its initial focus — the Hosted Caches specification, currently in draft — describes a shared, virtualised infrastructure layer where CDNs and content providers can deploy and operate their own delivery workloads, with workload isolation, lifecycle management, and low-latency connectivity to end users.
The draft proposes three collaborating roles — Tenant, Hosting Service Provider, and Network Operator — with the Hosting Service Provider a new role introduced by the framework to operate shared edge compute as a service to tenants. The draft is being developed collaboratively by contributors from network operators, CDNs, and infrastructure vendors, including 2you.io.
Three roles: Tenant (orange), Hosting Service Provider (blue), Network Operator (green). Source: SVTA Edge Working Group draft specification.
CDN or Content Provider
Deploys and operates delivery workloads — cache instances, protocol stacks, request logic — on infrastructure they don’t own. Retains full control over workloads, observability, and routing.
Shared edge platform operator
Operates the shared edge compute platform with tenant isolation, orchestration, and resource management. May be a network operator, a third party, or a partnership between them — the framework defines the interfaces, not who fills the role.
Access Network Provider
Provides high-capacity, low-latency connectivity between the hosted workloads and end users. Supports on-net, multi-network, and public edge deployment topologies.
Come see it running.
A working walkthrough of the draft Hosted Caches architecture — multi-tenant workload orchestration, isolation, observability, and request routing on distributed edge infrastructure. Best experienced in person, with a conversation. Not at NAB? Get in touch and we’ll set up a remote walkthrough.