Vena is a service delivery platform that uses a graph database to distribute linear broadcast video around the UK. The graph model represents physical network resources, logical resources, services, and customers with relationships. This enables feasibility checking, resource reservation, service fulfillment, and service impact analysis when failures occur. The system aims to provide low latency, low jitter, high bandwidth distribution with automated service lifecycle management and customer self-service capabilities.

1. Use of Graph in VENA (a
smart broadcast network)
Greg Thomas - Senior Software Engineer
Ajit Dani - Principle Solution Architect

2. Contribution Distribution
What Media and Broadcast do? 2

3. What is Vena?
If you are watching ITV or C4 and soon any terrestrial TV
channel you are seeing Vena at work
• Vena is a service delivery platform for linear broadcast quality video distribution
around the UK
• Vena is a fully automated platform both in terms of commissioning equipment and in
allowing customers to order services
• Vena was created to provide best in class performance for media traffic, with;
▪ low latency
▪ low jitter
▪ high bandwidth
▪ Multicast point to multi-point
• Customer self serve for managing and tracking services

4. Opportunity – Renewal of obsolescent
infrastructure and management systems
BT Group | Public 4
Leverage this transformation to fulfil BT M&B key business objectives in terms of competitiveness, operational effectiveness and
data integrity
Area Opportunity IT System requirements KPIs
Increased competitiveness and Customer
Experience
• Decreased time to market by automated
service life cycle management
• Deploy a platform capable of supporting
the creation of innovative and competitive
service bundles for broadcaster
• Provide customers with simplified self
serve service ordering
• Modular functional architecture for
vertical and horizontal scaling.
• Adoption Microservices
• Model/Intent-driven network services.
• Service delivery times
• Market Share & Revenue
• Number of new services launched
• Number of new service bundles launched
Operational Effectiveness and Data Integrity • Decrease operational cost by minimizing
human intervention from service
fulfilment to assurance
• Data model structure to ensure real time
resource status
• Guarantee end to end view of services
• Closed loop automation
• E2E topology view
• Central Dynamic inventory
• Service, resources, live data correlation
for service management decisions
• Number of repair calls completed
• Cost reduction related to inventory
changes.

5. Architectural Principles
BT Group | Public 5
Layering Service view vs network view with
relationships between them
Service Fulfilment Service fulfilment needs real real-
time path computation which
needs to honour BT and customer
constraints
Operational response
Improvements
Avoid alarm fatigue for operations
- Provide an enriched and
correlated alarm to operations
rather than bombarding hundreds
of isolated and unrelated alarm
Resilience and reliability 99.999 %
Service Fulfilment Service fulfilment needs real real-
time path computation which
needs to honour BT and customer
constraints
Development flexibility Minimize lead time to build new
service types
Architectural complexity Minimize system integration costs
Top functional requirements Non-functional requirements

6. Layered model for Resource & Services
BT Group | Public 6
We wanted to create a layered inventory where we have
physical resources, logical resources, services and customers
with relationships, which enables
• Feasibility check of a service
• Reservation of resources
• Service Fulfilment
• Service Impact Analysis

7. Path Computation
BT Group | Public 7
Set up a path computation service to calculate a path from a
source to multiple destinations considering the following
constraints –
• Node and Link Diversity - The primary and protected paths cannot
use the same links and nodes
• Cost of the Link – which is a function of latency and bandwidth
• Bandwidth Optimization - for a tree, we split as late as possible so as
to optimize node and link bandwidth usage
• MPLS constraint – we don’t loop back to a node we visited when
calculating a path
The time between call and response needs to be in
milliseconds.

8. Service Impacts
BT Group | Public 8
The requirement here, was to create a "Service Impact
Analysis" service. The primary role of this service is to identify
which services are impacted for which customers and the type
of impact.
We want to expose this as a callable API. We want to then call
this API using the identifier of the node/link that failed.
This internally queries the database and calculates
• Services impacted
• The type of impact – e.g. is this a loss of resilience/loss of service
• Customers impacted
We can consolidate this information and instead of flooding ops
with hundreds of alarms, only send enriched and correlated
alarms.

9. Vena
~580 routers
• Juniper (core)
• Cisco (CPE)
• AppearTV (CPE)
~1000 links
▪ Mostly Openreach circuits
▪ Some in-building
connections
▪ A handful of microwave
connections
BT Group PowerPoint | 9
~770 live services
~2,300 total services
~10 events/second
▪ SNMP traps
▪ Syslog messages
~52,000 nodes
~384,000 relationships
Today:
▪ ITV
▪ UK Rugby
▪ Some Racing TV
Soon:
▪ Arqiva
▪ BBC
▪ More Racing TV
▪ … and more
BT’s network for broadcast media

10. Lessons Learnt
Beware clustering
▪ Neo4j is ACID compliant
▪ But also, eventually
consistent
BT Group | Public 10
SDN5 to SDN6 migration
▪ Think JPA
▪ Not lazily loaded, risk of
loading the entire graph
memory.
Performance
▪ Worth considering using
graph experts to review
queries and models