Designing An

IP-Transport Network
For DTT

NID4083Owner: Damien Nagle

 Net Insight AB, 2012. All rights reserved. This document and the information contained herein is the
property of Net Insight AB and may not be copied, disclosed, reproduced or distributed in any way or
form, whether in whole or in part, without Net Insight’s prior written consent.
Table of Contents

1 ABSTRACT 3
2 DVB-T2: TYPICAL REQUIREMENT OF A DTT TRANSPORT LAYER 4
3 IMPLEMENTING DVB-T2 USING IP TRANSPORT 6
3.1 DESIGN CONSIDERATIONS AT IP TRANSPORT LAYER 7
3.1.1 Quality of Service (QoS).............................................................................................. 7
3.1.2 Multicast....................................................................................................................... 8
3.1.3 Scalability & Complexity.............................................................................................10
3.1.4 Network Protection..................................................................................................... 12
3.1.5 Additional Services; Primary Contribution & Other Distribution Services...................12
3.1.6 Service & Network Management................................................................................13
3.1.7 Network Roll-Out........................................................................................................ 15
3.1.8 Migration: Legacy to IP.............................................................................................. 15
4 SOLUTION PROPOSALS FOR THE TRANSPORT LAYER 16
4.1 SCENARIO A: ALL-IP DVB-T2 OVER MPLS 16
4.2 SCENARIO B: ALL-IP DVB-T2 OVER MSR 18
4.2.1 Quality of Service (QoS)............................................................................................18
4.2.2 Multicast..................................................................................................................... 18
4.2.3 Architecture................................................................................................................ 19
4.2.4 Network Protection..................................................................................................... 20
4.2.5 Additional Services; Primary Contribution & Other Distribution Services...................21
4.2.6 Service & Network Management................................................................................21
4.2.7 Network Roll-Out........................................................................................................ 22
4.2.8 GPS Independence.................................................................................................... 23
4.2.9 Example DTT Implementations..................................................................................23
5 Conclusions 25

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 2 of 25

1 Abstract
This document investigates the challenges of delivering a digital broadcast
service over traditional IP telecoms infrastructure. The primary goal is to analyze
best practice from within the IP data industry and compare it with the best
practice from the IP media industry.

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 3 of 25

2 DVB-T2: Typical Requirement of a DTT
Transport Layer
DVB-T (Digital Video Broadcasting – Terrestrial) is the most widely deployed DTT
(Digital Terrestrial Television) system worldwide, with more than 200 million
receivers deployed in over 60 countries. The DVB standard is defined by the DVB
project, an industry-led consortium of around 250-300 broadcasters,
manufacturers, network operators, software developers, regulatory bodies and
others. The DVB standards are published by the Joint Technical Committee of
European Telecommunication Standards Institute (ETSI), the European
Committee for Electrotechnical Standardization (ECES) and the European
Broadcasting Union (EBU).

There are presently two mainstream deployments the of DVB-T standards, DVB-
T and DVB-T2. DVB-T is widely deployed. The first DVB-T broadcasts started
already in 1997 (in UK and Sweden). The newer standard, DVB-T2, offers
significantly better technical performance and facilitates the introduction of
services with high data requirements like HDTV and 3DTV. In addition DVB-T2 is
the ideal solution when different service characteristics need to be supported in
one multiplex - e.g. high data rate for HDTV via roof top antennas combined
together with transmission to portable TVs with indoor antennas.

Presently, DVB-T2 is selected by countries at the beginning of their nationwide

(Digital terrestrial Television) implementation. With this regard it is important to
realize that DVB-T2 brings with it a need to carefully consider the digital dividend.
This valuable national resource can be maximized through careful frequency
planning. DVB-T and DVB-T2 consider this digital dividend within their
specifications. Generally speaking, the gains in spectrum efficiency are
dramatically increased should a Single Frequency Network (SFN) implementation
be integrated into the early planning phases.

This significant gain in spectrum efficiency requires a synchronization of time

information signals at all transmitters of a SFN-enabled DVB-T2 network. A
traditional way of providing this time information is to deploy a solution based on
the Global Positioning System (GPS). This freely available service does have its
limitations however. It has been found by some governments that TV and Radio
distribution are a matter of national security.

These nations states seeking complete control of this key infrastructure require
an alternative to satellite based time synchronization. Later in this document we
describe how a DVB-T2 SFN implementation can be achieved without
dependence on GPS or equivalent systems using Net Insight’s unique Time
Transfer technology.

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 4 of 25

Returning the DVB-T2 specification, it is important to observe that the DVB-T2
standard doesn’t define the transport network requirements at all. The following
figure shows the DVB-T2 architecture, as defined in DVB-T2 standards.

Since the transport network is not specified in the DVB-T2 standard, the operator
must take the initiative to implement a sufficiently competent technical
architecture. In essence, the transport network is the lowest common
denominator in building a working DVB-T2 network. The best multiplexers,
gateways and modulators will not ensure the expected level of DVB-T2 service, if
the transport network is not able to always provide 100% quality of service. The
easiest option for many newly created digital media operators when arriving to
this problem is to consult the telecoms industry and request a solution
corresponding to a 100% Service Level Agreement SLA.

Given the premise of having this potential QoS (Quality of Service) bottleneck at
the transport layer, a suitable strategy is to avoid implementing expensive layers
of monitoring and repairing technologies. The alternative is to prevent this
bottleneck and implement a transport layer that does not require complex
systems configuration and constant reengineering. This is particularly true where
the operator envisions service growth introduced through predictable change
management in its network.

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 5 of 25

3 Implementing DVB-T2 Using IP Transport
The DVB-T2 operator has to decide whichtransport technology should be
implemented. Most broadcast networks presently operating run over a robust and
predictable synchronous non-IP infrastructures. However, IP has many good
arguments in favor of it being suitable for future DVB-T2 implementations:

 IP links are becoming more widely available

 IP links are available at more flexible bandwidth rates then Synchronous
Digital Hierarchy (SDH) links
 IP is a future-safe standard, which will at the operational layer at least
converge all network services and administration
 IP equipment is getting more and more budget friendly. This allows it to
offer the operator the same unmanaged throughput but at a lower price
then alternative technologies, e.g. Next Generation Synchronous Digital
Hierarchy (NG-SDH), Dark Fiber
 IP interfaces are rapidly becoming common on more and more end-user
devices, e.g. Smart TVs. While this benefit is most evident at the
application level, the use of IP philosophy at the transport level reduces
the need to be overly concerned about technology interoperability in the
overall DVB-T2 network architecture.

When considering IP for implementation of a DVB-T2 transport network, there are

two different options:

1. All IP philosophy with IP Layer 3 and above isolated to the Access

Network
 In this case, head-end(s) and transmitters have IP interfaces. IP is
used in the radio-links to connect this equipment to the core
network. The core network transports IP traffic, but it doesn’t use IP
protocols to implement quality of service, multicasting, service
protection and so on.
2. All IP philosophy with IP Layer 3 and above present everywhere in the
Access Network and Core Networks
 In this case the core is implemented as well using IP, e.g. as a
MPLS network. IP protocols are being used for quality of service
(DiffServ, RSVP), multicasting (PIM), service protection (automatic
re-routing) and so on.

Net Insight has built the world’s first All-IP DVB-T2 network. The implementation
uses Nimbra, a Media Switch Router (MSR) from Net Insight. The operator,
Teracom, operates a nation-wide DVB-T2 network in Sweden since 2010. Today,
after two years of operations Teracom can confirm that the implementation has
been a resounding success, with the multiservice media operator delivering key

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 6 of 25

public services without any comprise on quality and innovation – all at a best-in-
class low operational cost.

We will describe principles of this implementation, but beforehand we should

have a look at the second option: the use of MPLS in the core transport network.
We will observe how MPLS is engineered to cope with the difference in QoS
required by DTT networks. Using this comparison mechanism we shall show how
an IP-Nimbra strategy solves the engineering issues which is otherwise a
permanent legacy problem of IP’s core architecture. This will in turn allow us to
better understand Teracom’s implementation of DVB-T2 with an all-IP
philosophy.
3.1 Design Considerations at IP Transport Layer

3.1.1 Quality of Service (QoS)

TV, or more specifically, high bandwidth or realtime-sensitive services

require a transport layer with 100% of QoS. Another way to look at this
100% figure is to consider it a guarantee that the service will be delivered.
Many core characteristics inherent to IP networking, including packet loss,
jitter, re-routing in the range of seconds, are not acceptable for TV
distribution. All of these characteristics need to be managed in order to
approach acceptable levels of transport QoS.

As a result, there are many technical and policy mechanisms for achieving
high QoS in IP networks. However it is correct to say that they have been
designed from the outset for application to data traffic and not for video
applications. The advent of Voice over IP (VoIP) communications brought
this issue to the forefront of operators’ minds. At that time, they were
looking to implement voice services at lower total cost of ownership by
combining it with their growing data traffic infrastructure. Some 15 years
later the industry debates this same business argument but now it is
related to video services.

Consider DiffServ QoS. It offers excellent efficiency gains in that the traffic
in a particular traffic class (for example an Aggregated Forwarding AF
class) can utilize or ‘burst’ additional bandwidth that is unused by other
classes. This provides for greater efficiency/statistical gain when the
majority of traffic is bursty data traffic. Many modern telecom’s operators
utilize this technique to sell value-added business to business services.
The reasoning being that again the total cost of ownership for the operator
is reduced and the customer gains flexibility in requested throughput when
necessary. However, media/broadcast services are high-priority, high-
bandwidth constant bit-rate traffic with a low burst capability. Bursty traffic
is the polar opposite of constant bit-rate traffic. In this case, the efficiency
gains are greatly reduced. Even Over The Top (OTT) type services are not
bursty in nature, since only the initial request for the service generates a

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 7 of 25

 traffic burst, afterwards and for an indefinite period of time, the stream
shall be constant.

It is logical and correct to conclude that bursting to a higher capacity than

the anticipated constant bit rate will address QoS issues. The common-
denominator method to cope with QoS requirements in general-purpose IP
networks is overprovisioning. Overprovisioning addresses the problem by
giving it a wide berth and predicting that it will not reach the generous
operational limits assigned to it. While this policy initially helps to avoid
QoS problems of IP networks, it is both expensive on the capital and
business side for the network operator. No longer is it true that the
operator’s network can converge services at the packet layer and then
utilize the transport layer as a raw capacity commodity.

Where the operator does not have this consideration to make there
remains a significant issue on horizon - the issue of fault and change
management. An overprovisioning policy that does not include the long-
term growth of demands on the organization from its clients (internal or
external) is a risky investment. Very often, temporary solutions are needed
while a network upgrade in underway. For the business, it means that the
operator and their customer have to consider leased capacity from other
operators, even competitors.

So, we have established the importance of designing a digital broadcast

network in such a way that the transport network can provide the
guarantee of service delivery – i.e. 100% QoS.

Ideally, this shall be achieved without an overprovisioning policy, and

maintain network-assisted transparent and simple to change standard
operating policies. Namely, service-centric management, fault diagnostics
and network architecture engineering and planning.
3.1.2 Multicast

Broadcast services are implemented in transport networks by multicasting.

This method poses the premise that one or more sources shall have their
service matrix distributed to selected destinations. In practicality this refers
to the distribution chain between from head-end to transmitter. When
redundancy of this workflow is required the complexity of the multicast
service increase dramatically.

Reaction to failure at multicast tributary nodes adds considerable

complexity to the planning and operational responsibilities of the operator.
As a result a significant number of sophisticated technical and business
policies must be implemented at every point in the network. The
overarching responsibility for implementation of these policies in
contemporary data and voice networks falls to Multiprotocol Label
Switching.(MPLS).

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 8 of 25

 It is very important to note that the MPLS specificationenvisioned support
for point-to-point (unicast) connectivity.Multicast support is a relatively
recent addition and its status as a mature or event relevant technology to
digital broadcast is questionable. Consider MPLS Point to Multipoint Traffic
Engineering (P2MP TE), it was first released by IP only developer and
manufacturer Cisco to a limited set of devices in early 2009. Resultantly,
its adoption without closer scrutiny is an uncalculated risk.

Several multicasting protocols for IP networks are available for

consideration.Protocol-Independent Multicast (PIM) can be used in the
core to create distribution trees. Depending on the IP version, multicast
delivery can be controlled by Internet Group Management Protocol
(IGMP), if IPv4 is used.Should the operator require adherence to IPv6 then
Multicast Listener Discovery (MLD), is more appropriate. Both scenarios
require that the operator update their IPv4 to IPv6 migration policy so that
it is aware of these different technical approaches.

Today, most if not all, telecoms operators are running their IP multicast
services separate from their MPLS services.

While IP multicasting work perfectly well for non-retransmit-sensitive

applications, the standard IP multicasting solutions have an unacceptably
long restoration time with regards to the requirements of a digital
broadcastservice. Even in a simple network a node failure will lead to
recovery time of the PIM protocol of over 1 minute. Typically in the
broadcast industry it is common practice to see financial penalties
associated with broadcast outages. This is especially true where
advertising and major sporting events are the subject of the interruption.

Total Recovery Time 66,625 sec

OSPF Recovery Time 2,470 sec
PIM Recovery Time 64,027 sec
Join Latency Time 0,128 sec

Figure 1: DVB-T2 Architecture

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 9 of 25

3.1.3 Scalability & Complexity

Nation-wide digital broadcast networks are very large, with potentially

hundred’s of millions of end-users. However, the transport network is
solely concerned with the distribution of the service to the digital
transmitters. This only underlines the importance of a well functioning
transmitter serving a population area of hundred’s of thousands, even
millions of people. Consideration of this responsibility is a key element of
good network design. The scale of this responsibility coupled with the
gradual growth of digital broadcast services means that the transport layer
shall support this scaling factor as seamlessly as possible.

If one considers a digital broadcast deployment based upon MPLS, this

issue of scaling to requirements both present and future is
underestimated.The additional planning and management required to
establish MPLS-based multicast networks creates complexity. This
complexity grows exponentially when multicast servicesare introduced at
the same rate as the growth of available IP capacity. In order words, where
no long-term overprovisioning policy is adopted then the potential to
introduce change to multicast services according to business needs is
severely impacted.

Change is possible but it is in fact limited to the willingness of organization

to re-engineer pre-existing mission critical services to accommodate the
new requirements. Typically, this is a very expensive exercise that relies
on core expertise and admission that the original network budget does not
cover this new cost.

If we consider the best practice approach, the following capabilities must

be implemented as horizontal policies across the entire MPLS network.
Each policy feature below is a complex group of functions that must be
carefully planned, implemented and maintained on an ongoing basis.

Implementation (typically a one-time configuration on all routers):

 Unicast and multicast fast conversion for IP/MPLS
 Source-specific multicast (SSM)

Continuous Planning and Maintenance:

 MPLS Traffic Engineering (if not already deployed)
 DiffServ QoS – optimized for business and media/broadcast
video services
 DiffServ aware Traffic Engineering (DS-TE)
 Point-to-Multipoint Traffic Engineering (P2MP TE) with Label
Switched Multicast (LSM)
 MPLS TE Fast Re-Route (FRR)
 Multicast only Fast Re-Route (MoFRR)

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 10 of 25

 As you can see, the above policy framework is multilayered and most likely
to be maintenance intense with at least one policy owner required to be on
the payroll on a permanent basis. This does not even consider the
expertise required to implement the policy framework’s directives.

Consider again that this complexity is just for multicasting of premium data
services. When the additional requirements ofdigital broadcast transport
are added (including,QoS, network protection, service scalability) the
network planning then becomes so complex that the risk of costly mistakes
is at its absolute maximum.

To emphasize this premise once again, strict management of this high risk
becomes a number one priority for the operations organization that choses
to work with MPLS going forward.

The following picture from Cisco shows that the windowsof

opportunityregarding engineering of MPLS engineering solutions for video
transport are limited and heavily loaded with risk.

Figure 3: Perils of MPLS Engineering (Source: Cisco)

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 11 of 25

3.1.4 Network Protection

Best-practicenetwork design of the digital broadcast transport layer must

expose appropriate mechanisms to protect the services. This is in case of
network, link, node and/or service interface failures. Restoration of a
national Television and Radio service in different fault scenarios must
happen in the range of milliseconds. From the content rights holder’s point
of view any potential impact on the service transmission shall never
acceptable if it is measured in seconds.

An unique case of network failure is when the primary source of all

services suffers a complete failure.The head-end as it is called must be
able tosignal and activate to a secondary head-end to resume insertion
and extraction of primary services into the network.This too requires a very
fast restoration of the distribution tree.

In this specific scenario, it is important to consider that the service

distribution tree must be reconstructed in real time and the network should
be able to receive the new routing instructions next to instantaneously.
Additional new link or node faults shall be dealt with automatically and the
distribution tree shall be adapted accordingly.

To summarize, efficient mechanisms for protection of the primary head-

end service matrix considered as one of the standard design principles.

Automatic routing and restoration that is measured in minutes or tens of

minutes shall never be acceptable to the digital broadcast industry as part
of adequate network architecture.
3.1.5 Additional Services; Primary Contribution & Other Distribution
Services

DVB stands for Digital Video Broadcasting, but almost all DVB network
infrastructures provide TV distribution services (the broadcast), and video
and audio contribution services. In essence the same network
infrastructure is used for the whole of the content production workflow.
This practical workflow may be realtime, neartime or based on non-linear
editing techniques (e.g. file transfer). Contribution services are typically
used to distribute and package localized TV and radio content. This is
particularly true for news and current affairs programming.

In a nation-wide DVB network one must now consider the contribution

requirements generated by the need to connect to regional TV studios,
stadia, government buildings and media affiliates and content production
partners.

Even if contribution is not the prime requirement of the first phase of a new
DVB network, it’s crucial to consider an impact of contribution services on

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 12 of 25

 the transport layer of the DVB network since they are an essential part of
the digital broadcaster’s content production work flow.

From the operator’s perspective, the best case scenario envisions the
possibility to introduce this essential workflow without any need to revisit
the design or QoS policy of the network. Certainly, it is correct to say that
the operator should notconsider the procurement of additional transport
equipment.

Consider this as a key design goal – the investment shall be capable

ofaggregating all services at the transport layer without additional
engineering or financial outlay. If one plans for DVB-T2
servicestransportthen it is prudent to consider the whole business
environment of the digital broadcaster also. This means that the transport
layer infrastructure shall have potential to enable all the data and media
interfaces necessary to support all forms of video, audio and IP-media
workflows that will be needed for the long-term future of the organization.
3.1.6 Service & Network Management

Consider that we have only now arrived to the question of operational

maintenance. The complexity of service design and policy control in the IP-
MPLS environment indicates that we need a powerful manager of
managers to addresses the growing hierarchy of mechanisms required to
deliver guaranteed QoS, reliable restoration and predictable change
management (new service introduction).

Disappointingly, this is where the ubiquity of the IP philosophy has yet to

deliver. Due to the multilevel complexity of IP networking combined with
the requirement of digital broadcasting, we are left with a system that
assumes least-worst-case-scenario responsibility at the highest level.

What this means in practicality is that the manager of managers at the top
level passes the responsibility of solving the problem increasingly
downwards in the hierarchy once problems occur.

For video services, management of such networks rapidly becomes very

complex and a service level diagnosis is almost impossible without human
interpretation of the many management layers unique interpretation of the
issue.

We shall consider how Cisco addresses this tricky issue of management of

many systems by describing an example monitoring solution, in this case
Cisco VAMS (Video Assurance Management Solution).

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 13 of 25

 Figure 4: Monitoring of video transport network of an IP vendor (Source: Cisco)

This comprises the following four management systems (plus 3rd-party

video probes):

1. Cisco Information Centre (CIC) provides the service

management/manager of manager layer
2. Cisco ROSA NMS monitors video head end/adaption devices
3. Cisco Multicast Manager (CMM) monitors linear broadcast/IP
multicast
4. Cisco Adaptive Network Abstraction (ANA) is the router Element
Management System (EMS)

Each of these management systems is complex and expensive to deploy

and operate. They are ‘loosely integrated’ products from disparate product
families within Cisco. This means a holistic service aware approach is non-
existent. In its place, a layer of policy aggregations at the presentation
level creates the representation of the service’s status.

Even if one assumes that this presentation layer offers satisfactory

diagnostic and reporting tools one must consider the extensive, complex
systems integration project that is required simply to get these systems
working together.

Finally, when one realizes that this behemoth architecture only provides
basic monitoring capabilities, i.e. other systems are also needed for
network provisioning, planning, etc., then it becomes very difficult to
endorse this approach to managing a digital broadcast network.

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 14 of 25

3.1.7 Network Roll-Out

An overlooked but important consideration is the ability to roll out the

chosen transport layer relatively quickly. In many countries the roll-out of
DVB is combined with the analog switch off (ASO) and digital dividend.
The deadline for ASO is usually set by the government in partnership with
neighboring states and thusly, is tied to political commitments. Changing
these dates is not easy or quickly done.

Therefore it’s crucial to ensure that each and every part of the DTT project
can be rolled-out smoothly. The transport network is no exception in this
regard. In fact, given its prominence in being the lowest common
denominator in guaranteeing QoS, it is essential that this component is
100% operational as soon as possible.

As described underSection 3.1.3 “Scalability and complexity”, a DTTroll-

out using MPLS can easily end up in a network re-design
and/orsignificantly time-expensive traffic re-engineering.In neither case, is
the final and stable result guaranteed to hold up to future the introduction
of additional services, such as contribution or additional multiplexes.
3.1.8 Migration: Legacy to IP

Where DVB-T2 is being implemented in an existing DVB-T environment

(either country-wide or in some regions with DVB-T), the transport network
will not likely be IP-based. It is much more probable that Synchronous
Digital Interfaces (SDI) or Asynchronous Digital Interfaces (ASI) are in use.

The associated professional grade equipment is often extremely reliable

and well embedded in the company’s technology culture.

With this in mind, it’s important to take into account an appropriately

efficient migration strategy. How can the operator gain the benefits of IP
without negatively impacting the live services currently on air using ASI
and SDI?

When answering this question, the operator can assign the selected
transport layer to support this migration scenario e.g. by requiring legacy
digital media interfacessuch as MPEG-TS over ASIas well as future-safe
IP media services over Ethernet.

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 15 of 25

4 Solution Proposals for the Transport Layer

4.1 Scenario A: All-IP DVB-T2 Over MPLS

If the DVB operator decides to use a MPLS core network for the DVB transport,
we propose to use a media service architecture shown in Figure 5. Media Access
devices (MA) together with Media Switch Routers (MSR) form a media service
overlay network on top of the IP/MPLS core.

This architecture provides two major benefits; a true service-aware media

network together with enhanced QoS and performance of the IP network.
Services, unicast and multicast, can be provisioned on demand and different
protection mechanisms can be applied per service independently of the core. The
media service layer should also have the capability to provide performance
monitoring both per service end to end for SLA validation as well as per IP
connectivity link for fault location. Services supported should include not only IP
but also native video and audio services such as ASI, 3G/HD/SD-SDI, AES,
MADI, etc.

MA Media
MSR
Service
MSR MA
MA Network
MSR

IP/MPLS
Core

Transport

Figure 5: The service-aware media network allows operators to offer their customers truly
managed media services with guaranteed QoS

The media service layer could be realized with different technologies and
products. Net Insight’s approach is unique in that it has the ability to handle all
media services individually within the IP network.

This capability means that the operator can provision, monitor and protect each
service on demand end-to-end across the IP network, making the network media
service aware. By measuring packet loss and jitter in real time and on all
intermediate links, the health of the underlying network is monitored to allow SLA

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 16 of 25

reporting and fault location per link, visibility that is not possible using classic data
routers as MSRs.

In addition, Net Insight is able to deliver 100 % Quality of Service for media-rich
network traffic. This is accomplished in two ways. Net Insight’s Nimbra MSR
ensures zero packet loss within each node thanks to its lossless routing and
improves the quality of the IP network traffic with QoS enhanced links.

In contrast to using data routers in media networks, the Nimbra MSR performs
lossless routing. This means that as traffic moves through the MSR from ingress
port to egress port, the Nimbra never loses a packet, hence never introduces any
QoS degradation. This is ensured by performing resource allocation per service
from input to output and by a complete resynchronization of all traffic in every
node. In a Nimbra MSR the buffering is done per service and not per priority
class as in an IP/MPLS router meaning that the resources are dedicated and not
shared between the services.

With QoS enhanced links, Net Insight’s MSR takes action on each IP hop to
enhance the quality of the traffic between two adjacent MSRs as it travels on the
core IP network. The Nimbra MSR performs forward error correction (FEC) to
reduce packet loss, traffic shaping to facilitate resource allocation and SLA
assurance for the IP core network, and resynchronization to reduce end-to-end
jitter and wander.

Service-Centric Network Management

QoS Enhanced Links QoS Enhanced Links QoS Enhanced Links

Lossless Lossless
Routing Routing

Figure 6: The Nimbra MSR enables service-centric network management and ensures QoS
through unique features such as lossless routing and QoS enhanced links.

When using data routers as MSRs, FEC is only applied at the Media Access
devices at the edge of the network. The Nimbra MSR on the other hand performs
forward error correction on every intermediate IP link. While an end-to-end FEC
scheme may result in unrecoverable packet loss in the FEC matrix, Net Insight’s
solution means that lost packets can be recovered as soon as they appear link by
link, which means less overhead is needed for the FEC matrix resulting in higher
bandwidth utilization overall. Since error correction is performed on the
aggregated IP flow rather than per service, i.e. at a higher bit rate, the delay is
also reduced.

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 17 of 25

The Nimbra MSR also reshapes and resynchronizes the traffic at every MSR
hop. This means that before sending the traffic to the next MSR, the traffic is
reshaped to Constant Bit Rate (CBR). This makes it easier for the IP/MPLS core
router to handle the traffic and not have overflow in its buffers. In fact it also
improves the QoS for lower priority traffic since it will not suffer from being
temporarily starved by bursty high priority traffic. When using a data router MSR
reshaping is not done, instead the traffic becomes burstier for every router it
passes, eventually resulting in packet loss.

4.2 Scenario B: All-IP DVB-T2 Over MSR

Net Insight has implemented the worldwide first all-IP DVB-T2 network for the
national DVB-T2 operator Teracom in Sweden. In this solution Nimbra MSR
use IP interfaces to connect head-ends and transmitters, as well as for radio-
links, while in the core network Nimbra network runs directly on top of fiber
network.

This solution has a number of advantages over a full MPLS solution in the
core:
 It is more cost-effective
 It is less complex, allowing an easier design and a faster roll-out
 It is easier to manage

4.2.1 Quality of Service (QoS)

In section 4.1 we have described how allocation of separate channels to

different service, per-hop Forward Error Correction (FEC), per-hop
traffic re-shaping and re-synchronization ensure 100% of Quality of
Service.

The ability to split available bandwidth into channels of 0.5 Mbps

granularity ensures as well optimal network utilization, unmatched by
alternative solutions.
4.2.2 Multicast

The network uses multicasting protocol of Nimbra. Transmitters with

Nimbra 310 use IGMP to join multicasting groups. The use of IGMP
allows creation of n+1 QAM schemes, increasing service availability.

Nimbra’s multicast doesn’t have the problems of PIM in situations of

links and node failures. The following figure should be compared with
the recovery time of a MPLS/PIM network, shown in the previous
chapter.

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 18 of 25

 Total Recovery Time 2,128 sec
MSR Recovery Time 2,0 sec
OSPF Recovery Time 0,000 sec
PIM Recovery Time 0,000 sec
Join Latency Time 0,128 sec
X

Figure 7: Multicast recovery time in a simple network using Nimbra MSR

4.2.3 Architecture

The following picture shows the architecture of an implementation of an

all-IP DVB-T2 transport network.

Regional / Stand-by
Head-end

TV studio

Head-end

10 Gbps
Digital TV
Digital TV
Radio
Radio
Media Networking
Media Networking

TV studio
Stadium

Figure 8: Architecture of all-IP Nimbra-based transport network for DVB

distribution, digital radio broadcast, media networking and live events
contribution

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 19 of 25

 The backbone network has a number of Nimbra 680 nodes connected
over fiber-links. Nimbra 680 has been selected, as the backbone links
have 10 Gbps bandwidth. The DVB operator uses this bandwidth to
connect TV studios, broadcasters and live sport events. If less
bandwidth is sufficient, a smaller Nimbra (e.g. 360 or 380) can be used.

Nimbra 680 typically forms the high-capacity backbone layer of a

Nimbra network, aggregating and switching traffic from Nimbra 300
series access nodes. Nimbra 680 features:

 40 or 80 Gbps redundant switch planes

 > 1 Terabit per second switching capacity per rack
 8 slots for plug-in traffic interfaces
 Up to 112 OC-192/STM-64 interfaces per rack
 Up to 448 OC-48/STM-16 interfaces per rack

The 8-port Gigabit Ethernet module of Nimbra 680 supports

channelization of connections down to N x 0.5 Mbps at full 8 x 1 G
wirespeed. Features include 802.1Q VLAN separation, 802.1p and IP
DiffServ user priorities, and Metro Ethernet Forum E-Line, E-LAN and
E-Tree support.

There is a Nimbra 310 at each transmitter site. Nimbra 310 is used as

well at radio-links. Nimbra 310 is the price-attractive access node of the
Nimbra family. It has a number of access interfaces like ASI, SDI,
Ethernet and AES/EBU. Nimbra 310 supports IGMP, as well the time-
transfer feature, allowing an implementation of DVB-T2 without GPS.

There are two head-ends, the main head-end at the central site and the
stand-by head-end at a remote location.

The network management system from Net Insight called Nimbra Vision
is used for management of the Nimbra network.
4.2.4 Network Protection

Nimbra has a number of mechanisms to ensure service protection. At

network failure, the Nimbra network will try to re-establish the service.
Re-establishment time depends on network topology and complexity,
but typical value is between ~100ms and ~2 seconds. Prioritized
channels are re-established first. The routing for service re-
establishment can be dynamic or static, or a combination of both.

Nimbra supports as well 1+1 protection where the signal is sent in the
network over two diverse paths. At the egress we can combine the “hot”
and “hot standby” paths without any visual degradation of data during
network failures. This is realized using Net Insights hitless protection

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 20 of 25

 where the two signals in the network are synchronized at the egress so
that no data loss occurs during the failure.

A special case is head-end protection. Nimbra network keeps a mirror of

the multicasting tree from the main head-end. Standby connections are
configured but disabled to save network capacity. Nimbra’s network
management system, Nimbra Vision, is used to set up the head-end
protection. It can be specified when the stand-by connections are
activated, in case of site-, node-, board- or signal-failure.
4.2.5 Additional Services; Primary Contribution & Other Distribution
Services

4.2.5.1 Content Contribution

A nation-wide DVB network will always require to solution to add easily
local TV content to the national TV. In the described architecture this is
done by sending content from all local centers to the main centre,
where the local content is edited and inserted into the multiplexer. The
alternative solution is to edit and insert local content at the local centers.
The advantage of the centralized solution lies in the lower cost, as
fewer resources are needed (only at the main site). The de-centralized
solution may still be the preferred option in a large country with a high
number of local centers. Nimbra can support both alternatives:

 For the centralized solution Nimbra enables a very efficient transport

of uncompressed video in SDI from local centers to the main studio
 For the de-centralized solution Nimbra allows an insertion of local
content at any point in the network

In any case a Nimbra network can be used for tape-less production, as TV

studios can easily exchange uncompressed video. Nimbra network is used
as well for efficient transport of live sport-events.

4.2.5.2 Digital Radio

Nimbra has a number of interfaces, inc. AES/EBU and Ethernet.
Nimbra’s access node can be connected to digital radio module, with
AES/EBU interface transporting the digital radio, and Ethernet interface
transporting RDS data. Nimbra supports as well E1, which is necessary
for DAB transport.

The transport of digital TV and radio can be done in the same Nimbra
network, which greatly lowers the CAPEX and OPEX required to
implement digital radio.
4.2.6 Service & Network Management

The management of Nimbra network is done using Nimbra Vision, a

sophisticated network management system. Some of the features of
Nimbra Vision include:

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 21 of 25

  Auto-discovery of devices
Nimbra Vision automatically discovers installed nodes and links in the
network.
 Topological device maps
Nodes and links are presented in an easy-to-use, dynamic topological
map displaying status, capacity and network topology.
 Fault management
The status of nodes and links are indicated by their colors in the map.
An alarm summary view displays the total number of alarms, according
to severity, while an alert browser lists all network alarms with powerful
search and filtering functions.
 Performance monitoring
Performance monitoring presents G.826 reports generated by the
network elements. It also collects link usage data and plots statistics.
 Service provisioning
Easy end-to-end provisioning of services is possible by selecting the
originating and terminating nodes from the map. Automatic and
predefined routing options are available.
 Head-end protection
Redundancy of Nimbra head-end nodes is enabled by configuring
primary and secondary connections. In the event of signal or node
failure, Nimbra Vision will activate the secondary connection.
 Pre-emption
In network failure situations, or during service provisioning, Nimbra
Vision may allow high-priority services to be established or rerouted by
pre-empting low-priority services.
 End-user sub networks
Fine-grained authorization of operations and managed objects to users
and groups allow operators to let their customers view, manage and
provision services in only “their” part of the operator’s network.
4.2.7 Network Roll-Out

The powerful built-in features of Nimbra allow a relatively rapid design and
rollout of a DVB network. Different nation-wide deployments have been
done with Nimbra according to very tight schedules or even ahead of time.
The rollout is usually done by a local partner of Net Insight.

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 22 of 25

4.2.8 GPS Independence

The Time Transfer option of the Nimbratransport platform allows highly

accurate distribution of real time over the same network that carries the
video signals. At the head end site the transport equipment will receive the
same reference signals (1PPS and 10MHz) as the SFN adapter. These
synchronization signals could be provided by any high-precision clock
source e.g. an atomic clock or a GPS receiver backed up by an atomic
clock. The time and frequency synchronization is distributed through the
transport network and at the transmitter site the transport equipment will
deliver the same synchronization interfaces to the Sync subsystem that
was previously delivered by a GPS receiver.
This solution is used in different countries to operate DVB networks
without any use of GPS at all. However, this can be used as well as a
complement to GPS or other satellite-based time-synchronization systems
(e.g. the Russian GLONASS system) in order to enhance the robustness
and resilience of the UTC distribution.

4.2.9 Example DTT Implementations

Nimbra has been used in a number of DVB networks worldwide. The list
includes:
 Argentina – Customer name not revealed (national)
 Belgium – VRT (national)
 China – CQTV (regional)
 Cyprus – ΡΙΚ (CyBC) (national)
 Cyprus – Velister (national)
 Denmark – BSD (national)
 Estonia – Levira (national)
 Finland – Digita (national)
 Germany – T-Systems (national)
 Germany – West DeutscherRundfunk, (regional)
 Ireland – RTE (national)
 Italy – RAS (regional)
 Japan – Customer name not revealed (regional)
 Lithuania – LRTC (national)
 Luxemburg – BCE (national)
 Mauritius – MCML (national)
 Morocco – SNRT (regional)
 Netherlands - KPN Broadcast (national)
 Norway - Telenor Norkring (national)
 Poland – Emitel (national)
 Slovakia – Towercom (national)
 Slovenia – Norkring (national)
 South Korea - Korean Telecom (national)

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 23 of 25

  Sri Lanka – Customer name not revealed (national)
 Sweden – Teracom (national)

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 24 of 25

5 Conclusions
The media andtelecoms industries are long time partners. The emergence of
DTT services being delivered over core telecoms networks is a validation of this
important partnership.

However, a potential test of this partnership is the quality of the service delivered
by the chosen technology as well as the difficulty and cost required to get these
new digital media services up and running to the required standard.

It is important for both the operator and the broadcaster to be satisfied with the
move to digital broadcasting.

Two courses of action have been defined in this paper.

In the first course, it has been observed that due to the prevalence of deployed
MPLS networks, an appropriate strategy is to adapt these existing networks using
a media-service-aware layer that can engineer, repair and adapt the underlying
network to its optimal suitability to carrying DTT services.

The second opportunity available to the industry is to deploy a core MSR network
where an investment in an MPLS core infrastructure can be avoided. This offers
the benefit of being the lowest cost and at the same time, the highest quality
option.

In both topology scenarios, deploying a MSR architecture is a clean and efficient

solution. MSRs from Net Insight provide a solution, unparalleled in cost-efficiency
whilst keeping operational cost at a minimum by decreasing complexity.

Thetechnical and businesschallenges facing the operator and the broadcaster

seeking to introduce a national DTT service are immense. This paper concludes
that an all-IP DTT service is a viable investment and can also be a best in class
technical solution. The key element to achieving this dual outcome is to plan the
strategic positionof the MSR transport network in advance.

NID4083_1.4.1: Designing An IP-Transport Network For DTT Page 25 of 25