Download Wing TV-WP2-D11 Netw.. - Celtic-Plus

Document related concepts

Cracking of wireless networks wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Airborne Networking wikipedia , lookup

List of wireless community networks by region wikipedia , lookup

Transcript
Project Report
Wing TV
Services to Wireless, Integrated, Nomadic, GPRSUMTS & TV handheld terminals
D11 – Wing TV Network Issues
Editor: Davide Milanesio, Rai
Abstract
This document contains guidelines for DVB-H network operators, and deals with the issues
relevant to DVB-H network planning.
Various network architectures are considered, including SFN, co-existence with DVB-T services
and use of hierarchical modulation. Planning tools and criteria are illustrated by means of a
number planning exercises. Improvement of the coverage by means of gap-fillers is also
considered, as well as handover mechanisms ensuring terminal mobility.
New channel models have been defined, especially for pedestrian reception, based on the
extensive Wing TV laboratory and field measurements. This allows to provide new inputs to link
budget calculations.
Finally, parameters for evaluating the required Quality of Service at the various sections of the
DVB-H network are described.
Project
Wing TV
for full publication
May 2006
Participants in project Wing TV are:
•
Åbo Akademi University Turku (AAU)
•
Antenna Hungaria
•
Dibcom
•
DIGITA OY
•
Elektrobit Ltd.
•
Ericsson AB
•
Fundació Privada Universitat I Tecnologia (FUNITEC) - Universitat Ramon Llull
•
Mier Comunicaciones S.A.
•
Nokia Corporation
•
Nozema Services
•
Philips Electronics Nederland B.V. Research
•
RAI – CRIT (Centro Ricerche e Innovazione Tecnologica)
•
Retevisión (abertis telecom group)
•
Rohde&Schwarz, Broadcasting Division
•
SIDSA
•
Tampere University of Technology (TUT)
•
TeamCast
•
Technical University Braunschweig, Institut für Nachrichtentechnik
•
Telefónica I+D (TID)
•
Thales Broadcast & Multimedia
•
T-Systems International GmbH Media&Broadcast
•
University of Turku (UTU)
Wing TV - Services to Wireless, Integrated, Nomadic, GPRS-UMTS & TV handheld terminals
WP2 Deliverable: Wing TV Network Issues
Editor: Davide Milanesio, Rai
Project coordinator: Fernando Lopez Creus, Retevision (Abertis telecom group)
CELTIC published project result
 2005 CELTIC participants in project Wing TV
Disclaimer
This document contains material, which is the copyright of certain CELTIC PARTICIPANTS, and
may not be reproduced or copied without permission.
All PARTICIPANTS have agreed to full publication of this document.
The commercial use of any information contained in this document may require a license from the
proprietor of that information.
Neither the PARTICIPANTS nor the CELTIC Initiative warrant that the information contained in the
report is capable of use, or that use of the information is free from risk, and accept no liability for
loss or damage suffered by any person using this information.
CELTIC Wing TV project report
page 3 (140)
Preface
Within the last few decades broadcast technologies have delivered a great amount of television
programs to the mass audience all over the world. Content digitalization together with transmission
systems have improved the number and quality of programs reconfiguring also audiovisual market.
Thanks to the advances in video compression techniques, nowadays it is possible to transmit real
time video services using a relative small bandwidth. If we consider the great penetration of
cellular terminals in the market, a new business opportunity also known as Mobile TV has arisen :
i.e. reception of television programs on cellular terminals. This new opportunity has created
important expectative that can be observed in the great activity carried up by different standard
organizations as DVB, ETSI, IETF, etc. Broadcast technologies are very attractive for this kind of
applications due to the use of high bandwidth channels. This enables them to deliver a great
number of high quality TV programs to all users provided of mobile terminals without limit on the
number of users that can enjoy of this services within the coverage area. Thus broadcast
technologies represent a cost-effective solution for the implementation of Mobile TV networks. In
cellular environments it will also be possible to interact with a return channel that can be
implemented through some cellular network as GPRS or UMTS. This way, broadcast and cellular
networks complement each other creating a wide range of interactive multimedia services around
digital television.
DVB-H (Digital Video Broadcasting Handheld) is the European digital broadcast standard, based
on DVB-T, targeted to mobile reception in handheld terminals. DVB-H introduces a power saving
mechanism and a new MAC-layer FEC (Forward Error Correction) which allow for a low power
consumption in the terminal and a robust channel coding, adapted to handheld reception. Thus
increasing system’s robustness and flexibility whereas maintaining “almost” complete compatibility
with DVB-T. The several DVB-H pilots launched all around the world show the great interest that
the DVB-H technology has generated. DVB-H is nowadays in a good position to become the main
standard for the broadcast of Mobile TV services.
The Celtic Wing TV project aims to contribute to the technical validation of the DVB-H technology
providing objective information about the performance of this technology for the different
configurations. Wing TV is composed by equipment manufacturers, operators and universities
from eight European countries that under the umbrella of the Celtic organization study the DVB-H
related issues from their different perspectives providing a broad and rich view to the project. The
performance information and the interoperability tests performed within the project will help
manufacturers to have competitive equipment fully compliant with the DVB-H standard.
Interoperability between equipment is basic for the success of DVB-H. The Wing TV project fully
believes that industry collaboration in standardization is one of the key elements in the innovation
process. The Wing TV project will deliver input to currently on-the-making DVB-H related
standardization bodies as DVB, MBRAI, ITU or IEC. The results of the project will also be used for
updating the DVB-H implementation guidelines, helping network operators, broadcasters and other
media industry players to deploy DVB-H networks and develop the content-to-mobile-users
business opportunity. The dissemination activities are also important for the widespread of the
DVB-H technology which is currently competing with other technologies in a increasing global
world.
 2005 CELTIC participants in project Wing TV
page 4 (140)
CELTIC Wing TV project report
Executive Summary
DVB-H networks have to be designed to guarantee an adequate indoor service quality even using
handheld devices with low antenna gain. In order to achieve this goal, a new kind of broadcast
networks is needed, at the border between traditional broadcast networks and cellular mobile
networks. The special issues relevant to DVB-H involve both the network architecture principles
and the planning criteria and methods.
This document deals with the new issues, allowing the DVB-H network operators to have a clear
view of the available options and drawbacks, and also indicating possible strategies for re-use of
existing broadcast (DVB-T) networks. Moreover, a Wing TV channel model and a Wing TV set of
parameters for link budget calculations has been produced, contributing to the refinement of the
DVB-H Implementation Guidelines.
Planning a DVB-H network implies a good knowledge of the channel models in the various
reception conditions (i.e. indoor, pedestrian, in-car, etc.). While channel models for fixed and
vehicular reception were already available and only refinements were needed, pedestrian reception
has now been modelled for the first time on the basis of a huge number of measurements in
various environments, allowing for a reliable channel estimation.
Traditional planning tools for broadcast network are designed for field strength estimation at the
roof top, where domestic antennas for fixed TV services are installed. Instead, DVB-H services are
designed for handheld devices, leading to concepts typical of planning tools for cellular networks
(i.e. field strength estimation at 1.5 m), adapting the models to the architectural tissue of each town.
Different network topologies are considered, combining high power transmitters, typical of
traditional broadcast networks, with low power transmitters or repeaters, co-sited with cellular base
stations, covering the holes or reinforcing the indoor reception where needed. Planning exercises,
based on the defined link budget parameters, report on the various configurations and
performance.
Seeing that more sites are going to be considered on a DVB-H network, the use of on-channel
repeaters (gap-fillers) claims as the cost effective solution to massive extend and reinforce
coverage. But an improvement to the existing solutions (Echo Cancellation techniques) that are
technically feasible on-channel repeaters is required, as the environment conditions get harder
when they are moved closer to urban areas.
Co-existence with a DVB-T network is possible under certain conditions using hierarchical
modulation, which, on the other side, could be used for addressing devices with different QoS
constraints.
Dealing with mobility, another new feature with respect of DVB-T networks is handover. As DVB-H
receivers have a high mobility among the various cells, fast handover mechanisms have to be
implemented, i.e. including signal scan, or use of the NIT table and a list of alternate frequencies,
or use of cell information via TPS and NIT, or use of INT table with neighbour cells. Of course, the
network shall support these features, and this can have potential impact on the signal distribution.
The final objective of network planning is guaranteeing the required QoS in the covered area. QoS
has to be monitored in various sections of the network: some of these sections are common with
traditional DVB-T networks, some are specific of the DVB-H system.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 5 (140)
List of Authors
Esko Huuhka, Airi Silvennoinen (Digita),
Xavier Fustagueras, Eduard Gil (MIER),
Paolo Benvenuto Forni (Rai – Strategie Tecnologiche – Pianificazione delle Frequenze Terrestri e
Satellitari, Davide Milanesio (Rai-CRIT),
Carlos Pardo (SIDSA),
Fernando López (Retevision),
Maite Aparicio (Telefonica I+D),
Jukka Rinne (TUT),
Alejandro López (URL)
 2005 CELTIC participants in project Wing TV
page 6 (140)
CELTIC Wing TV project report
Table of Contents
Preface................................................................................................................................................ 3
Executive Summary............................................................................................................................ 4
List of Authors ..................................................................................................................................... 5
Table of Contents ............................................................................................................................... 6
Abbreviations .................................................................................................................................... 10
1 Introduction................................................................................................................................ 12
2 Channel models......................................................................................................................... 13
2.1
Introduction......................................................................................................................... 13
2.1.1
Parameter extraction................................................................................................... 13
2.1.2
Proposed models ........................................................................................................ 13
2.2
Pedestrian .......................................................................................................................... 14
2.2.1
Pedestrian Indoor........................................................................................................ 14
2.2.2
Pedestrian Outdoor ..................................................................................................... 14
2.3
Mobile................................................................................................................................. 15
2.3.1
Vehicular Urban .......................................................................................................... 15
2.3.2
Motorway..................................................................................................................... 15
2.4
Modelling of the Doppler spectra ....................................................................................... 15
2.5
Impulse noise ..................................................................................................................... 16
2.6
Concluding remarks ........................................................................................................... 17
3 DVB-H radio network engineering and network architecture .................................................... 18
3.1
Introduction......................................................................................................................... 18
3.2
DVB-H variants................................................................................................................... 18
3.2.1
DVB-H configuration ................................................................................................... 18
3.2.1.1
FFT size ............................................................................................................... 18
3.2.1.2
Guard interval ...................................................................................................... 18
3.2.1.3
Modulation ........................................................................................................... 19
3.2.1.4
Inner FEC (Forward Error Correction) ................................................................. 19
3.2.1.5
In-depth interleaver.............................................................................................. 19
3.2.1.6
MPE-FEC............................................................................................................. 20
3.2.1.7
Other aspects ...................................................................................................... 20
3.2.2
Selection of DVB-H modes ......................................................................................... 20
3.3
Planning parameters and tools .......................................................................................... 21
3.3.1
Propagation models .................................................................................................... 21
3.3.1.1
Propagation model 1............................................................................................ 22
3.3.1.2
Propagation model 2............................................................................................ 23
3.3.2
Tuning models ............................................................................................................ 23
3.3.2.1
Tuning of model 1 ................................................................................................ 23
3.3.2.2
Tuning of model 2 ................................................................................................ 25
3.3.3
Wing TV Link budget................................................................................................... 28
3.3.3.1
Portable Reception .............................................................................................. 28
3.3.3.2
Mobile Reception ................................................................................................. 29
3.3.3.3
Transmitter........................................................................................................... 29
3.3.3.4
Reference Receiver ............................................................................................. 29
3.3.3.5
Statistical Correction Factors............................................................................... 31
3.3.3.6
Height Loss .......................................................................................................... 32
3.3.3.7
Wing TV Link Budget ........................................................................................... 32
3.4
Planning exercises using existing infrastructure (both broadcasting and other) ............... 32
3.4.1
Exercise 1 (urban area) .............................................................................................. 32
3.4.1.1
Required field strength......................................................................................... 32
3.4.1.2
Planning exercise ................................................................................................ 33
3.4.2
Exercise 2 (urban area) .............................................................................................. 43
3.4.2.1
Required field strength......................................................................................... 43
3.4.2.2
Planning exercise ................................................................................................ 45
3.4.2.3
Planning exercise with estimation of field strength at user quota........................ 54
3.4.3
Exercise 3 (rural area) ................................................................................................ 55
3.4.3.1
Required field strength......................................................................................... 55
3.4.3.2
Planning exercise ................................................................................................ 55
3.4.4
Maximum SFN-areas of selected variants.................................................................. 61
3.4.4.1
Effect of the network type .................................................................................... 61
3.4.4.2
Effect of code rate................................................................................................ 61
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
4
5
6
7
page 7 (140)
3.4.4.3
Effect of the guard interval .................................................................................. 62
3.4.4.4
Effect of the required protection ratio .................................................................. 62
3.4.4.5
Effect of the required field strength ..................................................................... 62
3.5
Planning exercises using “ideal” network structure ........................................................... 62
3.5.1
Optimal antenna height / EIRP values ...................................................................... 62
3.5.2
Maximum SFN-areas of selected variants ................................................................. 65
3.6
Comparison of DVB-H and DVB-T networks structures .................................................... 65
3.6.1
DVB-H network ........................................................................................................... 65
3.6.2
DVB-T network ........................................................................................................... 66
3.7
Conclusions ....................................................................................................................... 67
Usability of repeaters in DVB-H networks................................................................................. 68
4.1
Introduction. Need of repeaters in DVB-H cellular networks ............................................. 68
4.1.1
Transmitters, transposers, regenerative repeaters and on-channel repeaters .......... 68
4.1.2
Cost saving and technical constraints ........................................................................ 69
4.2
On-channel repeaters (SFN) ............................................................................................. 70
4.2.1
The pros and cons of on-channel repeaters in DVB-H networks ............................... 70
4.2.2
Antenna coupling effect and isolation of installation .................................................. 70
4.2.3
Limits of current technology........................................................................................ 72
4.2.3.1
Longer distance echoes ...................................................................................... 73
4.2.3.2
Varying conditions ............................................................................................... 74
4.2.4
Conclusions ................................................................................................................ 75
Hierarchical modulation issues ................................................................................................. 77
5.1
Basics of hierarchical modulation ...................................................................................... 77
5.2
Usage of hierarchical modulation in DVB-H networks....................................................... 78
5.2.1
Mixing traditional DVB-T and DVB-H services ........................................................... 78
5.2.2
New scenario deploying “DVB-H only” hierarchical networks .................................... 78
5.2.2.1
Progressive degradation of the QoS ................................................................... 79
5.2.2.2
Multiformat/multidevice support .......................................................................... 79
5.2.2.3
Utilisation of LP stream for upgrading content carried within HP stream............ 80
5.2.3
Available bit-rates ....................................................................................................... 80
5.3
Performance with respect to non-hierarchical modulation ................................................ 81
5.3.1
Impact on DVB-H planning ......................................................................................... 83
5.4
Compatibility with current DVB-T receivers ....................................................................... 83
Service Information and handover issues................................................................................. 84
6.1
Basics of PSI/SI Tables ..................................................................................................... 84
6.2
PSI/SI in DVB-H Networks................................................................................................. 85
6.2.1
MPEG-2 PSI ............................................................................................................... 85
6.2.1.1
Program Association Table (PAT)....................................................................... 85
6.2.1.2
Program Map Table (PMT) ................................................................................. 85
6.2.1.3
Conditional Access Table (CAT) ......................................................................... 85
6.2.1.4
Transport Stream Description Table (TSDT) ...................................................... 86
6.2.2
DVB-SI........................................................................................................................ 86
6.2.2.1
Network Information Table (NIT)......................................................................... 86
6.2.2.2
Bouquet Association Table (BAT) ....................................................................... 86
6.2.2.3
Service Description Table (SDT)......................................................................... 87
6.2.2.4
Time and Date Table (TDT) ................................................................................ 87
6.2.2.5
Time Offset Table (TOT) ..................................................................................... 87
6.2.2.6
IP/MAC Notification Table (INT).......................................................................... 87
6.3
PSI/SI Tables and Handover in DVB-H Networks ............................................................. 88
6.3.1
Signal scan ................................................................................................................. 89
6.3.2
Use of NIT and frequency_list_descriptor .................................................................. 90
6.3.3
Cell identification via TPS and NIT ............................................................................. 90
6.3.4
Use of INT tables ........................................................................................................ 92
6.3.5
Time slice synchronization for seamless handover support....................................... 94
6.3.5.1
Phase shifting...................................................................................................... 94
6.3.5.2
IP Encapsulators synchronisation ....................................................................... 95
Quality of Service ...................................................................................................................... 96
7.1
Reference architecture ...................................................................................................... 96
7.1.1
Network (Reference points)........................................................................................ 96
7.1.2
Reference receiver (Reference points) ...................................................................... 96
7.2
QoS network parameters................................................................................................... 97
7.2.1
QoS on Transport Network......................................................................................... 97
7.2.1.1
RTP packet jitter.................................................................................................. 97
 2005 CELTIC participants in project Wing TV
page 8 (140)
CELTIC Wing TV project report
7.2.1.2
IP Packet Loss..................................................................................................... 97
7.2.2
QoS Parameters in IPE............................................................................................... 98
7.2.2.1
Channel Switching Delay..................................................................................... 98
7.2.2.2
Power Saving....................................................................................................... 98
7.2.2.3
Access Delay ....................................................................................................... 98
7.2.2.4
IP Encapsulation Delay........................................................................................ 98
7.2.2.5
IP Loss Data ........................................................................................................ 98
7.3
QoS Terminal side.............................................................................................................. 99
7.3.1
Physical and Link Layer parameters........................................................................... 99
7.3.1.1
C/N....................................................................................................................... 99
7.3.1.2
RSSI..................................................................................................................... 99
7.3.2
Specific DVB-H parameters ........................................................................................ 99
7.3.2.1
FER...................................................................................................................... 99
7.3.2.2
MFER................................................................................................................... 99
7.4
LIST OF QoS PARAMETERS.......................................................................................... 100
8 Conclusions ............................................................................................................................. 101
References ..................................................................................................................................... 102
Annex A - PSI / SI Tables syntax ................................................................................................. 104
A.1
PAT Syntax ...................................................................................................................... 104
A.1.1
Semantic definition of fields in program association section .................................... 104
A.2
PMT Syntax...................................................................................................................... 105
A.2.1
Semantic definition of fields in program map section ............................................... 105
A.3
CAT Syntax ...................................................................................................................... 106
A.3.1
Semantic definition of fields in conditional access section ....................................... 107
A.4
TSDT Syntax .................................................................................................................... 107
A.4.1
Semantic definition of fields in conditional access section ....................................... 107
A.5
NIT Syntax........................................................................................................................ 108
A.5.1
Semantic definition of fields in network information section ..................................... 108
A.6
BAT Syntax ...................................................................................................................... 110
A.6.1
Semantic definition of fields in bouquet association section..................................... 110
A.7
SDT Syntax ...................................................................................................................... 111
A.7.1
Semantic definition of fields in service description section....................................... 111
A.8
TDT Syntax ...................................................................................................................... 113
A.8.1
Semantic definition of fields in time date section ...................................................... 113
A.9
TOT Syntax ...................................................................................................................... 113
A.9.1
Semantic definition of fields in time offset section .................................................... 113
A.10
INT Syntax .................................................................................................................... 114
A.10.1
Semantic definition of fields in IP/MAC notification section .................................. 114
Annex B - Descriptors required in DVB-H .................................................................................... 116
B.1
Descriptors required in PMT for IPDC over DVB-H Networks ......................................... 116
B.1.1
Stream Identifier Descriptor ...................................................................................... 116
B.1.2
Data Broadcast ID Descriptor ................................................................................... 116
B.2
Descriptors required in TSDT for IPDC over DVB-H Networks ....................................... 117
B.2.1
Transport Stream Descriptor..................................................................................... 117
B.3
Descriptors required in NIT for IPDC over DVB-H Networks ........................................... 118
B.3.1
Network Name Descriptor......................................................................................... 118
B.3.2
Cell List Descriptor .................................................................................................... 118
B.3.3
Cell Frequency Link Descriptor................................................................................. 119
B.3.4
Linkage Descriptor .................................................................................................... 120
B.3.5
Terrestrial Delivery System Descriptor ..................................................................... 124
B.3.6
Time Slice And Fec Identifier Descriptor .................................................................. 126
B.4
Descriptors required in SDT for IPDC over DVB-H Networks ......................................... 127
B.4.1
Data Broadcast Descriptor........................................................................................ 127
B.4.2
Service Descriptor..................................................................................................... 129
B.5
Descriptors required in INT for IPDC over DVB-H Networks ........................................... 130
B.5.1
Target IP Address Descriptor.................................................................................... 130
B.5.2
Target IP Slash Descriptor........................................................................................ 131
B.5.3
Target IP Source Slash Descriptor ........................................................................... 131
B.5.4
Target IPv6 Address Descriptor................................................................................ 132
B.5.5
Target IPv6 Slash Descriptor .................................................................................... 133
B.5.6
Target IPv6 Source Slash Descriptor ....................................................................... 133
B.5.7
IP/MAC Platform Name Descriptor ........................................................................... 134
B.5.8
IP/MAC Platform Provider Name Descriptor............................................................. 135
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 9 (140)
B.5.9
IP/MAC Stream Location Descriptor ........................................................................ 135
B.5.10
Time Slice Fec Identifier Descriptor ...................................................................... 136
Annex C - DVB-H signalling example .......................................................................................... 137
 2005 CELTIC participants in project Wing TV
page 10 (140)
CELTIC Wing TV project report
Abbreviations
a.g.l.
Above Ground Level
a.s.l.
Above Sea Level
ATSC
Advanced Television System Committee
AWGN
Additive White Gaussian Noise
BAT
Bouquet Association Table
BD
Burst Duration
BS
Burst Spacing
CA
Conditional Access
CAT
Conditional Access Table
COFDM
Coded Orthogonal Frequency Division Multiplexing
CRC
Cyclic Redundancy Check
DTG
Digital TV Group
DVB-H
Digital Video Broadcasting – Handheld
DVB-T
Digital Video Broadcasting – Terrestrial
EIRP
Equivalent Isotropic Radiated Power
EIT
Event Information Table
e.m.
Electro-Magnetic
END
Equivalent Noise Degradation
ES
Elementary Stream
ETSI
European Telecommunications Standards Institute
FEC
Forward Error Correction
FFT
Fast Fourier Transform
GI
Guard interval
GM
Gain Margin
GO
Geometrical Optic
GPS
Global Positioning System
HP
High Priority
ID
IDentifier
INT
IP/MAC Notification Table
IP
Internet Protocol
IPDC
IP DataCast
ISI
Inter Symbol Interference
ITU-R
International Telecommunications Union – Radiocommunications
LOS
Line Of Sight
LP
Low Priority
MAC
Medium Access Control
MFN
Multi Frequency Network
MPE
Multi Protocol Encapsulation
MPEG
Motion Picture Expert Group
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
MR
Motorway Rural
NIT
Network Information Table
nLOS
Non Line Of Sight
PAT
Program Association Table
PCR
Program Clock Reference
PDA
Personal Digital Assistant
PDP
Power Delay Profile
PI
Pedestrian Indoor
PID
Program Identifier
PMT
Program Map Table
PO
Pedestrian Outdoor
PSI
Program Specific Information
QAM
Quadrature Amplitude Modulation
QCIF
Quarter Common Intermediate Format
QoS
Quality of Service
QPSK
Quaternary Phase Shift Keying
RF
Radio Frequency
rms
Root Mean Square
RSSI
Received Signal Strength Indication
SDT
Service Description Table
SFN
Single Frequency Network
SI
Service Information
TDT
Time and Date Table
TOT
Time Offset Dable
TPS
Transmission Parameters Signalling
TS
Transport Stream
TSDT
Transport Stream Description Table
TU
Typical Urban
UHF
Ultra High Frequency
UTC
Coordinated Universal Time
UTD
Uniform Theory of Diffraction
VHF
Very High Frequency
VU
Vehicular Urban
 2005 CELTIC participants in project Wing TV
page 11 (140)
page 12 (140)
1
CELTIC Wing TV project report
Introduction
DVB-H network planning will probably be the first activity where skills coming from both broadcast
operators and telecom operators are jointly needed.
In fact, DVB-H is a broadcast technology, where the same signal is distributed to any number of
terminals located in the coverage area of the transmitter, and there is no need for reducing the cell
radius in order to increase the number of connected users, as conversely needed in cellular
networks (e.g. GSM, UMTS).
However, DVB-H handheld terminals are likely to be quite similar to mobile phones (actually,
DVB-H will generally be one of the options available on mobile phones), and this implies limitations
and requirements in terms of reception capabilities (i.e. indoor or pedestrian reception and low
antenna gain) and mobility, all concepts well known to mobile operators.
As a consequence, planning a DVB-H network has to deal with new issues, and requires a different
approach with respect to DVB-T. For instance, in a typical case, broadcasting from a big transmitter
could not be enough, and the signal has to be reinforced by means of a number of other
transmitters or gap-fillers, eventually co-sited with mobile operators Base Stations.
The Wing TV Project has examined the various issues relevant to DVB-H networks, providing tools
for network operators and defining a channel model and a set of parameters for DVB-H link budget
calculations.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
2
Channel models
2.1
Introduction
page 13 (140)
In this Section the channel models, based on Elektrobit’s measurement results using Propsim
compatible radio channel characteristics for testing purposes, are presented. They are generated
from Turku measurements, where several receiver tests were performed [1].
This report includes the 12-tap channel models produced from the measurements and Doppler
spectra descriptions for each of the channels (pedestrian indoor, pedestrian outdoor, vehicular
urban and motorway), to avoid excessive complexity but still maintaining accurate modelling. Field
strength distribution related measurements, e.g. large-scale variations, leading typically to lognormal distribution analysis were not available due to relatively limited observations.
In the Turku two-transmitter network, four measurement scenarios were considered:
1.
Indoor measurements on Pedestrian speed (PI, 3 km/h),
2.
Pedestrian Outdoor (PO) at receiver speed 3 km/h,
3.
Vehicular Urban (VU) at 30 km/h receiver speed,
4.
Motorway Rural (MR) at 100 km/h speed.
TU6 model is applicable for higher speeds (i.e. fast trains).
2.1.1
Parameter extraction
The main parameters to be resolved from measured data are number of taps (with appropriate
power cut threshold), power delay profile (PDP) -exponent (when it is appropriate), maximum
excess delay, rms (root mean square) delay spread. These parameters will help to understand the
physical behaviour of the radio channel. Spatial dispersion (i.e. measurements were conducted
with SISO system) was not explicitly included in the treatment.
Derivation of the tapped delay line models is based on average power delay profiles for each
selected channel type. The individual multipath components are extracted from the measurements
using 30 dB power cut threshold. The PDPs were determined from the impulse response data by
dividing the data into smaller sets (time-wise) to satisfy the stationarity requirement. Then the
average PDP of each set was calculated and finally the PDPs from several measurements (from
the same environment) were averaged. Accurate 24 tap channel models were formed by visual
inspection from these averaged PDPs. One criterion in the selection process was the frequency
correlation of the taps: the selected taps should have a low frequency correlation on the bandwidth
of the receiver.
Reduction to 12 taps is accomplished by using localized delay and power estimation. The delay
axis is divided into groups or sub-regions allocated by the power concentration and the total
number of required taps. The more local power density the PDP has, the more densely the
sub-regions are located, hence providing enhanced accuracy for the modelling. For each segment,
mean delay value is calculated corresponding to tap delay. Special care has been used to maintain
possible SFN-structure of the profile. Consequently, the power of the tap is found by summing all
the multipath powers within segment. Finally power normalization is made, i.e., the largest tap has
value of 0 dB.
2.1.2
Proposed models
The measured data have been used to form four different channel models. Two of these,
Pedestrian Indoor and Pedestrian Outdoor, are especially relevant to the hand held reception, but
also the more mobile channels will give interesting comparison possibilities to the usual TUchannel. For the moment the exact modelling of the Doppler spectrum is still to be discussed
(TBD), but there is strong evidence that it is not Jakes type for all of the multipath components.
However, the defined Doppler spectra shown here reflect the current understanding in this matter.
 2005 CELTIC participants in project Wing TV
page 14 (140)
CELTIC Wing TV project report
2.2
Pedestrian
2.2.1
Pedestrian Indoor
Table 1 Pedestrian Indoor (PI 3 km/h)
Delay
(µs)
0.0
0.1
0.2
0.4
0.6
0.8
1.0
1.6
8.1
8.8
9.0
9.2
2.2.2
Power
(dB)
0.0
-6.4
-10.4
-13.0
-13.3
-13.7
-16.2
-15.2
-14.9
-16.2
-11.1
-11.2
Pedestrian Outdoor
Table 2 Pedestrian Outdoor (PO 3 km/h)
Delay
(µs)
0.0
0.2
0.6
1.0
1.4
1.8
2.3
3.4
4.5
5.0
5.3
5.7
Power
(dB)
0.0
-1.5
-3.8
-7.3
-9.8
-13.3
-15.9
-20.6
-19.0
-17.7
-18.0
-19.3
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
2.3
Mobile
2.3.1
Vehicular Urban
page 15 (140)
Table 3 Vehicular Urban (VU 30 km/h)
Delay
(µs)
0.0
0.3
0.8
1.6
2.6
3.3
4.8
5.8
7.2
10.8
11.8
12.6
2.3.2
Power
(dB)
0.0
-0.5
-1.0
-4.1
-8.8
-12.6
-18.6
-21.6
-24.6
-20.7
-18.2
-19.4
Motorway
Table 4 Motorway Rural (MR 100 km/h)
Delay
(µs)
0.0
0.5
1.0
1.8
2.5
3.1
3.9
4.8
5.5
6.4
7.0
9.0
2.4
Power
(dB)
0.0
-1.3
-3.4
-6.8
-10.2
-12.9
-16.3
-19.5
-21.7
-23.3
-24.2
-25.8
Modelling of the Doppler spectra
Two main types of Doppler spectra [3] will be used in the models:
•
The Gaussian spectrum is defined as
f2
G ( f ; σ ) = exp(− 2 ) ,
2σ
where σ is the standard deviation parameter of the spectrum.
•
The classical Doppler spectrum is given by
 2005 CELTIC participants in project Wing TV
page 16 (140)
CELTIC Wing TV project report
K ( f ; fD ) =
1
,
1 − ( f / f D )2
where fD is the maximum Doppler frequency.
The following Table 5 describes the simplified Doppler spectra proposed to be used with 12-tap
multipath model presented earlier. Here δ(f) is Dirac delta function.
Table 5 Simplified Doppler spectra
st
2.5
Spectrum for 1 tap
Spectrum for remaining taps
PI
0.1 G(f;0.08fD) + δ(f-0.5fD)
G(f;0.08fD)
PO
0.1 G(f;0.08fD) + δ(f-0.5fD)
G(f;0.08fD)
VU30
G(f;0.1fD)
K(f;fD)
MR100
G(f;0.1fD)
K(f;fD)
Impulse noise
The impulse noise waveforms proposed by the DTG II working group [4] is considered here. The
noise itself is generated by gating Gaussian noise by the waveform shown in Figure 1.
Burst n
Burst n + 1
Amplitude
BS
BD
PS
AP
PD
Time
Figure 1 Parameters related to DTG impulse noise model
The pulse duration (PD) defined to be 250 ns and the burst spacing (BS) is 10 ms. Six impulse
noise models (DTG1÷6) are defined in Table 6.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 17 (140)
Table 6 Impulse noise models
DTG#
Pulses per
burst
Minimum
pulse
spacing
(PS), µs
Maximum
pulse
spacing
(PS), µs
Effective
duration
(µs)
1
1
N/A
N/A
0.25
2
2
1.5
45
0.5
3
4
15
35
1
4
12
10
15
3
5
20
1
2
5
6
40
0.5
1
10
The pulse spacing should be uniformly distributed between the minimum and the maximum pulse
spacing. Within each burst duration (BD), there are 1 to 40 pulses depending on the model, as
indicated in the Table.
The impulse noise level, I, along with DVB-H signal level, C, and useful symbol duration, TU, can be
used to express windowed C/I as
 TU 
C
,
  = C − I+10log 
 I W
 TBS 
where TBS is burst duration in the same units as TU.
2.6
Concluding remarks
From the measurements we conclude following things.
First of all, the number of taps in radio channel is usually well over 20 per transmitter. It is clear that
the accurate radio channel test system must be able to simulate many paths (e.g. 12 or more),
even though the receiver would not use all the paths in the detection.
The Doppler was studied in this work. Main conclusion is that the spectrum is not necessarily Jakes
type, but other characteristics also exist. In rural motorway measurements we can see the Jakes
spectrum, indicating that the scatterer environment is equally distributed, but as we go into more
complex environments (indoor, suburban, urban), this does not hold anymore.
In this report, channel models for most of the typical DVB-H user scenarios are considered. It has
been found important to measure and model the time-variant behaviours of multipath components,
which in most of the cases deviate quite a lot from the conventionally used models.
 2005 CELTIC participants in project Wing TV
page 18 (140)
CELTIC Wing TV project report
3
DVB-H radio network engineering and network
architecture
3.1
Introduction
This Section analyses the main DVB-H parameters that have influence in the network planning.
Once the predictions have been compared with the measurements and prediction models have
been calibrated, several planning exercises performed are presented.
This allowed the definition of a Wing TV set of parameters for link budget calculations.
3.2
DVB-H variants
3.2.1
DVB-H configuration
The DVB-H standard [6] employs basically the modulation scheme of the DVB-T standard.
However, there are differences in the link and physical layers [7].
In the link layer, given the requirements for each system, DVB-H provides additional support for
mobile handheld reception. This includes battery saving through time-slicing and increased general
robustness and improved error resilience compared to DVB-T using MPE-FEC. In addition DVB-H
broadcasts sound, picture and other data using Internet Protocol (IP).
In the physical layer the differences are: changes in the DVB-H signalling in the TPS-bits,
introduction of the 4k mode and the optional use of in-depth interleaving.
The choice of the DVB-H configuration depends on the service requirements and the coverage
objectives.
In the following Table 7 the basic parameters of a DVB-H network are indicated:
Table 7 DVB-H configuration parameters
Parameter
FFT size
Guard interval
Modulation
Inner FEC
Interleaving
MPE-FEC*
Value
2k, 4k and 8k
1/4, 1/8, 1/16 and 1/32
QPSK, 16-QAM and 64-QAM
Convolutional code (1/2, 2/3, 3/4, 5/6 and 7/8)
Native, in-depth
1/2, 2/3, 3/4, 5/6 and 7/8
*MPE-FEC does not correspond to the physical layer but to the MPE encapsulation level
3.2.1.1
FFT size
The FFT size defines the number of carriers in which the information is divided: 2k (1705
modulated carriers), 4k (3409 modulated carriers) and 8k (6817 modulated carriers). The choice of
the FFT size has no impact on the capacity, but on the trade-off between mobile reception
(maximum speed) and SFN cell sizes. The 2k is the most suitable for mobile reception, whereas
the 8k gives the largest SFN cell size. The 4k is an intermediate solution.
3.2.1.2
Guard interval
The Guard interval can have a duration of 1/4, 1/8, 1/16 or 1/32. The guard interval is essential in
the case of multipath propagation, in case of natural echoes (buildings, mountains) or artificial
echoes (co-channel interference in a SFN network). The guard interval joint with the FFT size
determines the maximum distances between transmitters.
Table 8 shows the maximum distance between transmitters:
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 19 (140)
Table 8 Maximum distance between transmitters
Mode
8k
4k
2k
Guard Interval
Length
Cell radius
SFN (Km)
1/4
1/8
1/16
1/32
1/4
1/8
1/16
1/32
1/4
1/8
1/16
1/32
224 µs
112 µs
56 µs
28 µs
112 µs
56 µs
28 µs
14 µs
56 µs
28 µs
14 µs
7 µs
67.2
33.6
16.8
8.4
33.6
16.8
8.4
4.2
16.8
8.4
4.2
2.1
Guard intervals are added in order to prevent inter-COFDM symbol interference. For this matter,
the longer the guard interval (e.g. 1/4 vs. 1/32), the higher the immunity to ISI. Long guard intervals
benefit functionality on static channels (AWGN, P and F channels).
On the other hand, experience and simulations show that for mobile channels, short guard intervals
out-perform long ones. Shorter guard intervals have shorter delays between pilots and the channel
estimator can recover from faster Doppler changes. Lab results have shown that the improvement
of lower guard intervals on maximum Doppler is linear. As an example the Doppler performance
increases in a 25% in terms of Fdmax from a Guard Interval of 1/4 to 1/32 (see Table 9).
Table 9 Effect of Guard Interval on Doppler performance
GI
Fd/Fd(1/32) Fd/Fd(1/4)
1/4
1/8
1/16
1/32
3.2.1.3
0.80
0.90
0.95
1.00
1.000
1.125
1.188
1.250
Modulation
Each carrier of the DVB-H signal is modulated with one of the following modulation schemes:
QPSK, 16-QAM and 64-QAM. High order modulation provide more channel capacity, but are less
robust on front of Doppler effect and noise. Therefore, in general it will be necessary to consider
the trade-off between useful bit-rate and signal protection. In DVB-H only QPSK and 16-QAM
modulations are foreseen, due to the hostile reception conditions for handheld devices.
As an extension of the basic constellation, hierarchical modulation can be used, as described in
Section 4.
3.2.1.4
Inner FEC (Forward Error Correction)
DVB-T provides an inner code protection scheme based in convolutional codes. Five coding rates
can be considered: 1/2, 2/3, 3/4, 5/6 and 7/8. The insertion of redundant information provides
protection to the signal to cope with the hostile receiving conditions, but the price is a reduction of
useful bit-rate. Therefore it is necessary to consider the trade-off between signal protection and bitrate.
3.2.1.5
In-depth interleaver
An optional in-depth interleaver can be used to increase robustness of 2k and 4k carrier DVB-H
signals in noisy and mobile environments, using the memory of the 8k symbol interleaver to
effectively increase the 2k and 4k modes symbol interleaver depth and therefore improve reception
in fading channels.
 2005 CELTIC participants in project Wing TV
page 20 (140)
3.2.1.6
CELTIC Wing TV project report
MPE-FEC
The MPE-FEC combines the Forward Error Correction protocol and interleaving capacity to give a
more robust mechanism which improves both minimum C/N and maximum Doppler.
At moderate Dopplers (between 10 Hz and 90% of the maximum Doppler), the curve is very flat
and has a constant gain of 6 to 7 dB when compared to DVB-T with the same receiver. The
maximum usable Fd in DVB-H is closer to the Fdmax than in case of DVB-T due to the shape of the
curve.
At very low Dopplers (in the order of few Hz or less) the C/N-requirement will raise as the virtual
time interleaving of the MPE-FEC becomes shorter than the coherence time of the channel. The
actual Doppler frequency where this happens is dependent on the length of the time slice burst,
which is roughly equal to the time interleaving depth.
Note that the C/N-improvement is available even when MPE-FEC is applied to a non-mobile DVB-T
demodulator.
3.2.1.7
Other aspects
Other aspects that determine the configuration of a DVB-H network are:
•
Required bandwidth per programme. It depends on coding technique (MPEG-2, H.263, H.264,
etc.), subjective quality, associated audio and format (i.e. QCIF), etc.
•
Available spectrum. DVB-H can use both single frequency networks (SFN) and multiple
frequency networks (MFN) depending on the available spectrum.
•
Coverage targets. The conditions and environments (rural, urban, suburban) are different
depend on the type of reception. There are three possible reception scenarios: fixed roof-top
antennas, outdoor portable reception and indoor portable reception.
•
Service targets. The type of users and the reception conditions determine the configuration of
the DVB-H network.
3.2.2
Selection of DVB-H modes
There is a huge number of DVB-H modes if all possible modulation/error correction combinations
are taken into account. Table 10 shows the most probable DVB-H modes [8]. 64-QAM modes are
considered to be practical only in special cases because of required very high field strengths and
low maximum speeds in mobile reception in 8k mode.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 21 (140)
Table 10 Selection of possible DVB-H modes
Modulation
Code rate
Bit-rate
GI 1/4
MPE-FEC CR
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
64-QAM
64-QAM
64-QAM
64-QAM
64-QAM
1/2
1/2
1/2
1/2
1/2
2/3
2/3
2/3
2/3
1/2
1/2
1/2
1/2
2/3
2/3
2/3
2/3
1/2
1/2
2/3
2/3
2/3
4.98
4.98
4.98
4.98
4.98
6.64
6.64
6.64
6.64
9.95
9.95
9.95
9.95
13.27
13.27
13.27
13.27
14.93
14.93
19.91
19.91
19.91
1/2
2/3
3/4
5/6
7/8
2/3
3/4
5/6
7/8
2/3
3/4
5/6
7/8
2/3
3/4
5/6
7/8
5/6
7/8
2/3
3/4
5/6
True
bit-rate
GI 1/4
2.49
3.32
3.74
4.15
4.36
4.43
4.98
5.53
5.81
6.63
7.46
8.29
8.71
8.85
9.95
11.06
11.61
12.44
13.06
13.27
14.93
16.59
True
bit-rate
GI 1/8
2.77
3.69
4.16
4.61
4.84
4.92
5.53
6.14
6.46
7.37
8.29
9.21
9.68
9.83
11.06
12.29
12.90
13.82
14.51
14.74
16.59
18.43
The modes which are in red colour in Table 10 were considered to be the most probable and were
used in the planning exercises.
3.3
Planning parameters and tools
This Section considers three aspects regarding the radio planning:
•
The propagation models. To implement a mobile radio system, wave propagation models are
necessary to determine propagation characteristics for any arbitrary installation. The
predictions are required for a proper coverage planning, the determination of multipath effects
as well as for interference, which are the basis for the high-level network planning process.
•
Model tuning. The great complexity of the propagation mechanism makes difficult to have
accurate methods that can be adapted to all the different possible environments. The results
provided by the propagation methods must be considered as estimations that could be
corrected in certain circumstances. Most of the propagation models can be tuned based on
measurements campaigns in the coverage area. A tuning algorithm finds the parameters of the
calculation model that better adjust to the measurements.
•
Link budget. The link budget allows to fix the e.m. field strength level.
3.3.1
Propagation models
The mechanisms behind electromagnetic wave propagation are diverse, but can generally be
attributed to reflection, diffraction and scattering. The accuracy of the propagation model depends
on available cartography and its resolution (pixel size).
•
2D cartography: terrain height (raster) and terrain morphology (raster).
 2005 CELTIC participants in project Wing TV
page 22 (140)
•
CELTIC Wing TV project report
3D cartography: terrain height (raster), terrain morphology (raster) and shapes of buildings
(vectorial).
The type of available cartographic databases is a key factor that allows calculating the coverage
with the proper propagation model. On the other hand, the propagation models that can be used for
DVB-H planning could be classified on: empirical and deterministic models.
•
Empirical methods. These methods are based on measurements. Lee method.
•
Semi-empirical methods. These methods consider the joint between reflection, diffraction and
scattering and the results of the measurements. They need morphology and height information
of the terrain. COST 231, Okumura-Hata models.
•
Physical or deterministic methods. They are based on Ray Tracing Theory. Ray tracing-based
models can be used only if a precise and complete cartographic databases is available.
3.3.1.1
Propagation model 1
The propagation model used in Exercise 1 is based on Ray Tracing. This model uses an
approximation for Maxwell equations based on the Geometrical Optic (GO) and Uniform Theory of
Diffraction (UTD or GTD), which is valid when the obstacles are much greater than the wavelength.
The calculation of every reflection or diffraction point is carried out using a ray-tracing method
based on Snell’s law of reflection and Keller’s law of diffraction. A vector addition of the received
fields is carried out to obtain the total received field strength and, subsequently, the path loss along
a predetermined route.
Figure 2 Example of some ray geometry
The field contributions taken into account in the propagation calculation are the following:
•
Direct path ray (if LOS)
•
Reflected field in the floor
•
Field due to propagation over roofs
•
Reflected field in the facades (one or more reflections)
•
Field due to diffraction in streets corners.
The first three contributions are included in the plane orthogonal to the floor that links the
transmitter and the receiver. The rest of contributions are out of the orthogonal plane.
The main characteristic parameters of this model are described below:
•
Radio of calculus. The received field calculation is done inside a circle centred in the receiver’s
position. The radio of this circle is one of the calculation parameters.
•
Clutter correction. The model allows to take into account the additional losses caused when a
ray cross a building or a vegetation zone.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
•
page 23 (140)
These additional losses are modelled by this formula:
T = a + b*thickness
where a is a constant expressed in dB, b is a constant expressed in dB/m and thickness is the
thickness of the building’s wall or the vegetation zone expressed in meters.
•
Ray filter. The following parameters model the number of rays considered in the field
calculation:
o
Number of Diffractions and Reflections. This parameter models the he maximum number of
allowed diffractions and reflections for one ray.
o
Angular Resolution. This parameter models the angular accuracy for the ray tracing.
o
Minimum power. This parameter models the minimum allowed level for ray power. A ray
reaching below this value is not taken into account in the calculation.
o
Buildings roughness. It is used for reflection and diffraction rates calculation. The greater
the roughness the lower the reflected power.
o
Propagation. The calculation is divided between "in line of sight" and "no line of sight". A
diffraction rate in the vertical plane is also applied.
3.3.1.2
Propagation model 2
The propagation prediction method used in Exercise 3 is based on Canadian Research Centre
CRC-PREDICT® program. This VHF/UHF Propagation Prediction Program is used for estimating
radio signal strengths on terrestrial paths at VHF and UHF, given a transmitter location, power, and
a receiver location(s). Since transmission paths are often obstructed by terrain, CRC-PREDICT
operates concurrently with a machine-readable topographic database consisting of elevation and
surface codes; recorded at 25 m intervals.
When a path profile is present, the main calculation is that of diffraction attenuation due to terrain
obstacles. These obstacles are primarily hills, or the curvature of the earth, but can also include
trees and/or buildings. The presence and particular location of trees and buildings are considered
in the calculation. If the user is aware of a particular obstacle consisting of trees or buildings that
are not present in the terrain data, an additional loss estimate can be included. The diffraction
calculation is done by starting at the transmitting antenna and finding the radio field at
progressively greater distances. At each step, the field at a point is found by a numerical integration
over the field values found in the previous step. For long paths, tropospheric scatter becomes
important. CRC-Predict combines the tropospheric scatter signal with the diffraction signal.
The calculation can be done for different percentages of time, locations, or probability (time and
locations combined).
The original program has been modified in Digita for DVB-H calculations. The calculations are
made from all stations in SFN network to every calculation point and power sums of the field
strengths are calculated. The calculation points are produced with MapBasic interface program
where the calculation area is specified on map and the distance between points is given.
The field strength is calculated at the height of the nearest building or trees and special formulas
are added to the CRC program to calculate the height loss from calculation height to 1.5 meter
height. The height loss depends on the height of the near by buildings/trees as well as the distance
to the transmitter.
3.3.2
Tuning models
The objective of models tuning is to find the set of parameters that reduces the error planning. The
error planning is defined as the difference between the prediction and the measurements.
In the following points the results of the tuning of different propagation models are shown.
3.3.2.1
Tuning of model 1
This example is the result of the tuning of the particular model described in Section 3.3.1.1. The
parameters that are adjusted are:
 2005 CELTIC participants in project Wing TV
page 24 (140)
CELTIC Wing TV project report
•
Forward and backward correction factors.
•
Additional losses for the LOS link and nLOS link.
•
Correction factors on distance for LOS link and nLOS link.
•
Diffraction coefficient.
The broadcasting transmitter has the following characteristics:
•
EIRP: 67 dBm.
•
Antenna: Omnidirectional.
The measurements in the urban measured environment were:
Figure 3 Measurements
The coverage map generated with this model is the one represented in Figure 10.
The results of the model tuning are shown in Table 11:
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 25 (140)
Table 11 Comparison between measurements and predictions
Area
Nr of points
Mean difference *
Madrid
93869
0 dB
* Difference: measurements - predictions
Stdev of difference
8 dB
The calculated RSSI (dBm) variability with the distance appears in Figure 4.
Figure 4 RSSI (dBm)-Distance (m)
In the previous figure the tendency of the variability of the measurements with the distance also
appears. We could appreciate that the tendencies between the model and the measurements is
almost the same.
3.3.2.2
Tuning of model 2
A lot of DVB-H measurements were performed in Helsinki and Turku area. The raw measurements
were analysed and the mean value of 25 m measurements were used in the comparisons between
measured and calculated values. The calibration was iterative process. The predictions were
compared to the measurements and then the results were imported into MapInfo map. Then the
height loss formula was modified manually and new comparison was calculation was run. This
process was done several times until the results were not any more improved.
After the calibration the results shown in Table 12 were achieved.
Table 12 Comparison between measurements and predictions
Area
No. of points
Mean difference *
Helsinki
25374
1.7 dB
Turku
10843
1.9 dB
* Difference: measurements - predictions
St. dev. of difference
6.6 dB
7.4 dB
Majority of the measurements were done in urban areas. Figure 5 shows all the Helsinki area
measurements and the colours indicate the difference between measurements and predictions as
follows:
•
Red:
Measurement – prediction less than -5 dB
•
Yellow:
Measurement – prediction between -5 dB and +5 dB
 2005 CELTIC participants in project Wing TV
page 26 (140)
•
Green:
CELTIC Wing TV project report
Measurement – prediction more than +5 dB
Figure 5 Difference between measurements and predictions in Helsinki area.
Figure 6 Difference between measurements and predictions in Turku area.
Figure 7 shows the predicted Helsinki coverage area with the measurements. The colours indicate
field strengths as follows:
•
Yellow:
Field strength more than 76 dBµV/m
•
Red:
Field strength more than 70 dBµV/m
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 27 (140)
Figure 7 Comparison between measurements and predicted Helsinki coverage area
Figure 8 shows the predicted Turku coverage area with the measurements. The colours indicate
the same field strengths as in Helsinki case.
 2005 CELTIC participants in project Wing TV
page 28 (140)
CELTIC Wing TV project report
Figure 8 Comparison between measurements and predicted Turku coverage area
3.3.3
Wing TV Link budget
The link budget establishes the required equivalent field strength (dBu) to different scenarios [9]. In
the Wing TV it has been defined a link budget for a different combination of parameters (these
combinations are related with the measured modes). The different combinations are:
•
Bands: IV, V.
•
Scenario: Urban, suburban, rural.
•
With MPE-FEC.
•
Modulation and code rate: QPSK ½, QPSK 2/3, 16-QAM ½, 16-QAM 2/3.
•
Reception: Pedestrian, portable, and mobile
3.3.3.1
Portable Reception
Portable antenna reception is defined as the reception at no speed or very low speed (walking
speed) [9]:
•
Class A (pedestrian): outdoor reception at 1.5 m where a portable receiver with an attached
or built-in antenna is used.
•
Class B (indoor): ground floor indoor reception at 1.5 m. where a portable receiver with an
attached or built-in antenna is used.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
3.3.3.2
page 29 (140)
Mobile Reception
Mobile reception is defined as the reception at medium to high speed [9]:
• Class C: outdoor reception at 1.5 m with a moving DVB-H terminal where the receiver is
moved while being used. The typical case will be an antenna integrated in a car.
•
Class D: inside reception in moving objects like cars or vehicles (e.g. bus, train, etc.). The
DVB-H terminal is a handheld device.
In this Section, only class D reception with handheld terminal is considered, since it is expected to
be the most common receiving scenario in DVB-H mobile reception.
3.3.3.3
Transmitter
It is considered that transmitters are not perfect and introduce some degradation (Equivalent Noise
Degradation: END) to the DVB-H signal, which is estimated in 0.5 dB
3.3.3.4
Reference Receiver
Model
The Wing TV reference receiver performance is defined according to the reference model shown in
Figure 9.
Field
Strength
E
Antenna
Gain
Ga
Optional External
Antenna Connector
Only in DVB-H Receiver
Noise
Factor
F
Optional
GSM
Reject
Filter
LGSM
DVB-T
Demodulator
Input
Power
Pin
RF-Reference
point
DVB-H
Time
Slicing
TS-Reference
point
DVB-H
MPEFEC
FERReference
point
DVB-H
text
IP-Deencapsulation
MFERReference
point
IP-Out
IP-Reference
point
Figure 9 DVB-H Reference Receiver
Reference points are defined as follows [9]:
•
RF
•
Transport Stream
•
Frame errors before MPE-FEC (FER)
•
Frame errors after MPE-FEC (MFER)
•
IP
The Noise figure considered for a handheld terminal with a GSM transmitter is of 6 dB [10].
In the following, minimum C/N requirements in the various reception conditions are reported,
considering MPE-FEC 3/4. Performance without MPE-FEC are not reported, as they are not “flat”
with Doppler frequency; detailed performance with and without MPE-FEC, obtained in laboratory
and field trials, are reported in [11],[12],[13],[14].
Minimum C/N requirement in pedestrian channel
The Wing TV reference receiver defines the following minimum C/N values for pedestrian reception
using the PO3 channel model, as defined in Section 2 [15]:
 2005 CELTIC participants in project Wing TV
page 30 (140)
CELTIC Wing TV project report
Table 13 C/N Figures for pedestrian reception (PO3)
MPE-FEC
with (3/4)
QPSK 1/2
9.5 dB
QPSK 2/3
12.5 dB
C/N
16 QAM 1/2
15 dB
16 QAM 2/3
18 dB
All C/N values include the Implementation Loss.
Minimum C/N requirement in portable indoor channel
The Wing TV reference receiver defines the following minimum C/N values for portable indoor
reception using the PI3 channel model, as defined in Section 2 [15]:
Table 14 C/N Figures for portable indoor reception (PI3)
MPE-FEC
with (3/4)
QPSK 1/2
9.5 dB
QPSK 2/3
12.5 dB
C/N
16 QAM 1/2
15 dB
16 QAM 2/3
18 dB
Minimum C/N requirement in mobile channel
The Wing TV reference receiver defines the following minimum C/N values for mobile reception in
rural environment using the MR100 channel model or for urban vehicular using the VU30, as
defined in Section 2 [15]:
Table 15 C/N Figures for mobile reception (MR100 or VU30)
MPE-FEC
with (3/4)
QPSK 1/2
9.5 dB
QPSK 2/3
12.5 dB
C/N
16 QAM 1/2
15.5 dB
16 QAM 2/3
18.5 dB
The gain obtained by the MPE-FEC has been experimentally calculated by comparing the MFER
5% and FER 5% figures for several receivers. Typical MPE-FEC gains for pedestrian channels
(Doppler below 10Hz) are around 2 ÷ 5 dB. For mobile channels (tests were performed with a TU6
channel), MPE-FEC improvements were around 5 ÷ 9 dB.
Minimum Input levels
The receiver should have a Noise Figure better than 6 dB at the reference point at sensitivity level
of each DVB-T mode.
This corresponds the following noise floor power levels:
Pn = -99.2 dBm, [for 8 MHz channels, BW= 7.61 MHz]
Pn = -99.7 dBm, [for 7 MHz channels, BW= 6.66 MHz]
Pn = -99.4 dBm, [for 6 MHz channels, BW= 5.71 MHz]
Pn = -99.2 dBm, [for 5 MHz channels, BW= 4.76 MHz]
Antenna gain
If an external antenna is not used, the reception antenna is characterized for not having a
significant gain. The Wing TV reference receiver [15] defines the following gain for a terminal with
integrated antenna:
Table 16 Antenna gain
Antenna Gain (dBd)
Band IV (500 MHz)
-12
Band V (800 MHz)
-7
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
3.3.3.5
page 31 (140)
Statistical Correction Factors
Building Penetration Loss
The penetration loss are very difficult to estimate and are different depending on the type of
building and building material. Different studies have been performed in the frame of the Wing TV
project to study this issue:
•
Measurements done in the Spanish pilot mainly in residential buildings in urban areas yielded a
mean penetration loss of 11 dB and a standard deviation of 5.2 dB [16].
•
Taking into account the Italian measurements the mean penetration loss are of 11 dB.
•
Taking into account the results of the Finish pilot the indoor losses are between 11 and 16 dB.
In the link budget it is assumed a value of 11 dB with a standard deviation of 6 dB.
Vehicle Entry Loss
Taking into account the results of the Spanish pilot the vehicle losses are between 8÷9 dB. The
value used in the link budget is of 8 dB without considering standard deviation.
Body Loss
Body loss are commonly considered in radio-communication systems. A recommended values for
band IV and V would be between 2 and 3 dB. A DVB-H receiver could suffer of body loss in some
cases when the terminal is in the pocket. However for the visualization of TV services the terminal
will normally be more separated from the body so the effect of body loss are minor in comparison
to typical radio-communication systems. Body loss is not considered in the link budget.
Localization Correction Factors
The broadcast digital systems are characterized for having a very steep degradation of quality also
known as cliff effect. For this reason and to ensure a satisfactory reception it is necessary to
include statistical margins that take into account the statistical nature of the DVB-H signal and the
inaccuracy of planning tools.
ITU-R Recommendation P.1546-1 [17] gives a standard deviation for wide band signals of 5.5 dB.
This value is used here for determining the location correction factor for outdoor pedestrian
locations (class A) and for mobile class D. In the case of indoor class B reception it is combined
with the standard deviation of the penetration loss are combined by taking the square root of the
quadratic sum of the deviations. Table 17 shows the standard deviation values used in this chapter
to calculate the statistical margins:
Table 17 Standard deviation values
Type of reception
Pedestrian reception
Indoor reception
Mobile reception
Correction factor
5.5 dB
8.1 dB
5.5 dB
In portable reception to ensure a satisfactory service it is recommendable to ensure reception in
the range of 90÷95% of locations. To cope with mobile environment larger values are usually used.
For mobile reception it is recommendable to ensure reception in the range of 95÷99% of locations.
In this document a value of 95% in the edge of the area of coverage is used for all the cases.
The location correction factor is therefore:
Table 18 Statistical Correction Factor
Type of reception
Pedestrian, 90% location
Pedestrian, 95% location
Indoor, 90% location
Indoor, 95% location
Mobile 95% location*
Mobile 99% location*
*Class D reception
 2005 CELTIC participants in project Wing TV
Correction factor
7.1 dB
9.0 dB
10.4 dB
13.3 dB
9.0 dB
12.8 dB
page 32 (140)
3.3.3.6
CELTIC Wing TV project report
Height Loss
In case of using the curves provided by the ITU-R 1546 Recommendation for planning, it must be
taken into account that the curves are given for a receiving antenna height of 10 m a.g.l. DVB-H
services are basically planned for 1.5 m, so a height correction factor must be introduced. The
CEPT document [18] provides some values of height loss:
Table 19 Height Loss
Frecuency
Band IV
Band V
3.3.3.7
Rural
11 dB
13 dB
Height Loss
Suburban
16 dB
18 dB
Urban
22 dB
24 dB
Wing TV Link Budget
Table 20 reports the link budget for a QPSK 1/2, MPE-FEC 3/4 in Band IV and 8 MHz channel,
urban environment.
Table 20 Wing TV Link budget
Description
Rx. Noise Figure
Equivalent Noise Power
C/N
END
Antenna Gain
Effective Antenna aperture
Minimum equivalent Field Strength
Building Penetration Loss
Vehicle Entry Loss
Combined Standard deviation
Correction Factor 95% locations
Required equivalent Field Strength
Height Loss
Required equivalent Field Strength at 10 m
Units
dB
dBW
dB
dB
dBd
dB
dBu
dB
dB
dB
dB
dBu
dB
dBu
Pedestrian
6.0
-129.2
9.5
0.5
-12.0
-25.3
51.9
0.0
0.0
5.5
9.0
60.9
22
82.9
Indoor
6.0
-129.2
9.5
0.5
-12.0
-25.3
51.9
11.0
0.0
8.1
13.3
76.3
22
98.3
Mobile inside
6.0
-129.2
9.5
0.5
-12.0
-25.3
51.9
0.0
8.0
5.5
9.0
68.9
22
90.9
3.4
Planning exercises using existing infrastructure (both
broadcasting and other)
3.4.1
Exercise 1 (urban area)
3.4.1.1
Required field strength
This planning exercise takes into account the results of the tuning model described in Section
3.3.2.1.
The study was made considering an integrated antenna gain of -12 dBi and an omni-directional
antenna in transmission. The used frequency belongs to the UHF band IV (522 MHz). In the
following table, the values of required equivalent field strength (dBu) used in the planning exercise
are reported.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 33 (140)
Table 21 Required field strength (dBu)
Modes
QPSK 1/2 wo
QPSK 1/2 3/4
QPSK 2/3 wo
QPSK 2/3 3/4
16-QAM 1/2 wo
16-QAM 1/2 3/4
16-QAM 1/2 wo
16-QAM 1/2 3/4
Pedestrian
59.8
58.3
62.8
61.3
65.6
64.1
68.6
67.1
Indoor
64.2
62.7
67.2
65.7
70
68.5
73
71.5
Mobile
64.9
63.4
67.9
66.4
70.7
69.2
73.7
72.2
These values are slightly different from the values of Table 20
3.4.1.2
Planning exercise
The objective is to analyse the influence of the different configurations (modes, height and number
of transmitters) of the network in the percentage of coverage.
In the next Figures, the pedestrian and indoor coverage are shown for different scenarios.
Figure 10 Coverage prediction for a broadcast network (1 Tx, 2 kW)
 2005 CELTIC participants in project Wing TV
page 34 (140)
CELTIC Wing TV project report
Figure 11 Coverage prediction for a cellular network (30 Tx, 100 W)
•
Modes
In the following Figures, the different percentage of coverage in pedestrian and indoor reception,
taking into account the different considered variants, can be appreciated.
Figure 12 % Pedestrian (1 Tx)
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 35 (140)
Figure 13 % Indoor (1 Tx)
Figure 14 % Vehicular (1 Tx)
 2005 CELTIC participants in project Wing TV
page 36 (140)
CELTIC Wing TV project report
Figure 15 % Pedestrian (30 Tx)
Figure 16 % Indoor (30 Tx)
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 37 (140)
Figure 17 % Vehicular (30 Tx)
Figure 18 % Pedestrian (64 Tx)
 2005 CELTIC participants in project Wing TV
page 38 (140)
CELTIC Wing TV project report
Figure 19 % Indoor (64 Tx)
Figure 20 % Vehicular (64 Tx)
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 39 (140)
Figure 21 % Pedestrian (126 Tx)
Figure 22 % Indoor (126 Tx)
 2005 CELTIC participants in project Wing TV
page 40 (140)
CELTIC Wing TV project report
Figure 23 % Vehicular (126 Tx)
As expected, the use of 16-QAM penalizes the coverage degree that could be obtained.
Differences are bigger for indoor coverage than for outdoor or vehicular. Improvements from the
use of MPE-FEC tend to diminish with the transmission power for pedestrian and vehicular
coverage, while increase for indoor coverage.
It can be observed also that the main advantage of using multiple transmitters vs. a single
transmitter is the improvement of indoor coverage. For the same total transmission power in Watts,
1.2 kW, the percentage of indoor coverage increases from 33% in the best case for 1 transmitter to
nearly 90% for 126 transmitters.
However, for outdoor and vehicular coverage no major advantage is observed from the increase of
the number of transmitters once a certain threshold is surpassed.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
•
page 41 (140)
Height
The next Figures show the influence of the height of the transmitters. The calculations have been
performed for QPSK modulation with 1/2 coding rate and no MPE-FEC.
Figure 24 Height influence (1 Tx)
Figure 25 Height influence (30 Tx)
 2005 CELTIC participants in project Wing TV
page 42 (140)
CELTIC Wing TV project report
Figure 26 Height influence (126 TX)
Influence of the antenna height on coverage seems to depend in two factors: the ratio between the
height difference of the cases analyzed with respect to the total height; and the number of
transmitters. A large number of transmitters tend to limit the benefits of a higher antenna, as
coverage areas for each transmitter are smaller.
Due to the differences in the building heights and terrain, the benefits of increasing the antenna
height are more difficult to assess in real world scenarios.
•
Number of sites
The following Figures show the influence of the number of sites. The calculations have been
performed for QPSK modulation with 1/2 coding rate and no MPE-FEC.
Figure 27 Number of sites influence (pedestrian)
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 43 (140)
Figure 28 Number of sites influence (indoor)
Figure 29 Number of sites influence (vehicular)
Results are consistent with those indicated when dealing with modes.
3.4.2
Exercise 2 (urban area)
The planning algorithm used in this exercise is based on formulas and parameters described in
Section 11.2.2 of the DVB-H Implementation Guidelines [9].
3.4.2.1
•
Required field strength
Calculating the minimum field strength
The values of the minimum field strength have been calculated, considering a limited number of
service typologies and the more significant location coverage targets. In particular, the urban and
suburban areas are considered, with the aim of covering main cities.
 2005 CELTIC participants in project Wing TV
page 44 (140)
CELTIC Wing TV project report
In the simulations, maps describing the building continuity are used: the contiguous building tissue
has been considered as urban, the rest of the territory as suburban (the considered coverage area
includes some tens of km).
Indoor reception has been specifically addressed, considering a 70% location coverage as
acceptable.
Considering an integrated antenna gain of –10 dBi and frequency 500 MHz:
Aa = -25.3 dBm
2
The minimum equivalent field strength at the receiver input, considering a dedicated multiplex with
modulation QPSK 1/2, C/N min 9 dB and noise figure 7 dB, is:
Emin = 51.9 dB(µV/m)
Considering portable indoor reception at ground floor, applying the various correction factors, and
considering also an “enhanced” antenna (gain –5 dBi), the values for minimum field strength at
10 m are derived, relevant to indoor reception at ground floor, as reported in the following Table:
Table 22 Minimum planning field strength at 10 m [dB(µV/m)]
Portable indoor reception at ground floor, dedicated multiplex
Antenna
% loc
Suburban
Urban
Integrated
95%
93
99
Enhanced
95%
88
94
Integrated
70%
83
89
Enhances
70%
78
84
These values are slightly different from the values of Table 20
In case of “mobile inside” reception, a requirement of C/N at high speed 3 dB higher than at “urban”
speed has been considered, thus deriving different location percentages in the two cases, as
reported in the following Table:
Table 23 Minimum planning field strength at 10 m [dB(µV/m)]
Mobile inside reception, dedicated multiplex
Antenna
% loc – high speed
% loc – urban speed
Suburban
Urban
Integrated
96%
99
87.6
93.4
Enhanced
96%
99
82.6
88.6
Integrated
76%
90
81.6
87.6
Enhances
76%
90
76.6
82.6
These values are slightly different from the values of Table 20
•
Algorithm for estimation of the field strength at quota
The adopted model in case of broadcast networks derives the field strength at quota using the
following formula:
where Ad is the attenuation due to orographic obstructions, calculated using the Deygout method
to the rectified altimetry profile [19].
Various variants of the model are available, calculating the effect of the obstruction due to the
buildings by means of both detailed local maps and maps with statistical description of the
buildings, but they have not been used in the exercises.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
3.4.2.2
page 45 (140)
Planning exercise
The algorithm described above has been used in different exercises in various planning conditions:
•
Urban coverage with a high single transmitter on the hill
The characteristics of the transmitter are:
o
The hill transmitter is at 660 m a.s.l. (about 450 m above medium ground level on target
area )
o
Power: 8 kW.
o
Antenna: omnidirectional.
Transmitter
Figure 30 Indoor coverage at ground floor, 70% loc, enhanced antenna
Red: urban coverage; orange: suburban coverage; blue triangle: transmitter; green line: city border.
 2005 CELTIC participants in project Wing TV
page 46 (140)
CELTIC Wing TV project report
Transmitter
Figure 31 Indoor coverage at ground floor, 70% loc, integrated antenna; mobile inside, 76%
loc. with integrated antenna (or 96% loc. with enhanced antenna)
Red: urban coverage; orange: suburban coverage; blue triangle: transmitter; green line: city border.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 47 (140)
Transmitter
Figure 32 Indoor coverage at ground floor, 95% loc, enhanced antenna; mobile inside, 96%
loc. with integrated
Red: urban coverage; orange: suburban coverage; blue triangle: transmitter; green line: city border.
 2005 CELTIC participants in project Wing TV
page 48 (140)
•
CELTIC Wing TV project report
Urban coverage with a single transmitter in the city centre
The characteristics of the transmitter are:
o
It is sited on a high tower.
o
Power: 2.5 kW.
o
Antenna: Omnidirectional.
Figure 33: Indoor coverage at ground floor, 70% loc, enhanced antenna
Red: urban coverage; orange: suburban coverage; brown tower: transmitter; green line: city border.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 49 (140)
Figure 34 Indoor coverage at ground floor, 70% loc, integrated antenna; mobile inside, 76%
loc. with integrated antenna (or 96% loc. with enhanced antenna)
Red: urban coverage; orange: suburban coverage; brown tower: transmitter; green line: city border.
 2005 CELTIC participants in project Wing TV
page 50 (140)
CELTIC Wing TV project report
Figure 35 Indoor coverage at ground floor, 95% loc, enhanced antenna; mobile inside, 96%
loc. with integrated antenna
Red: urban coverage; orange: suburban coverage; brown tower: transmitter; green line: city border.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 51 (140)
Figure 36 Indoor coverage at ground floor, 95% loc, integrated antenna
Red: urban coverage; orange: suburban coverage; brown tower: transmitter; green line: city border.
 2005 CELTIC participants in project Wing TV
page 52 (140)
•
CELTIC Wing TV project report
Urban coverage with 4 transmitters
It has been considered a SFN network with 1 main transmitter on a high tower (2.5 kW,
omnidirectional) in the city centre and 3 external transmitters. All the transmitters considered have
the same ERP.
Figure 37 Indoor coverage at ground floor, 95% loc, integrated antenna
Red: urban coverage; orange: suburban coverage; brown tower: main transmitter; pink squares:
other transmitters; green line: city border.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 53 (140)
Figure 38 Indoor coverage at ground floor, 70% loc, integrated antenna; mobile inside, 76%
loc. with integrated antenna (or 96% loc. with enhanced antenna)
Red: urban coverage; orange: suburban coverage; brown tower: main transmitter; pink squares:
other transmitters; green line: city border.
•
Algorithm for estimation of the field strength at receiver quota
The preceding algorithm (estimation at quota, typically 10 m a.g.l.) is simple, but doesn’t properly
account for building obstruction, which is relevant in urban propagation, even considering different
building tissue class, or adding some grazing correction factor. Such an algorithm overestimates
coverage, and is unable to give detailed estimation of the coverage, but can successfully be used
in a first analysis step to set the locations for the main transmitters sites. In a successive step, in
order to obtain an affordable planning procedure, it is necessary to use more precise prediction
methods able to adequately considering building obstruction, putting into evidence lack of coverage
within the prescribed service area of the network considered. These methods (currently under
development at RAI – Strategie Tecnologiche – Pianificazione delle Frequenze Terrestri e
Satellitari) evaluate directly the field strength at the receiver quota, by accounting for the
attenuation due to the buildings between the transmitter site considered and each point of the
receiving area. Such more precise methods extract clutter information from detailed maps; in the
case of the mentioned algorithm, the clutter database can be mixed raster and vector, so in the
case of big cities where skyscraper can be present, these can be easily considered.
In order to use algorithms predicting field strength at receiver quota, it is necessary to derive the
field strength threshold Emin for the receiver at the user quota, properly considering the location
percentage for which the service has to be guaranteed:
Emin (fMHz, xlp %loc) = Emin (500MHz, 50 %loc) +20* Log10(fMHz/500) + Cl (xlp %loc) + Lb
where:
Cl : location correction factor (see Table 24)
Lb : outdoor-indoor attenuation
 2005 CELTIC participants in project Wing TV
page 54 (140)
CELTIC Wing TV project report
Table 24 Location correction factor vs. availability
Indoor service
location
percentage
µ
3.4.2.3
Indoor
correction
factor
C=µσ
C=µσ
(σ = 5.5 dB) (σ = 8.3 dB)
[%]
70
75
80
85
Outdoor
correction
factor
.52
.675
.84
1.05
[dB]
2.9
3.7
4.6
5.8
[dB]
4.3
5.6
7
8.7
Planning exercise with estimation of field strength at user quota
Figure 39 shows the predicted coverage at 1.5 m a.g.l., for location availability ≥ 85%, at indoor
ground floor. Red pixels relate to indoor coverage, green pixels to outdoor coverage, white pixels
indicate location in which the prescribed location availability threshold is not reached, i.e. the
predicted field strength is lower than the threshold field strength. Detailed estimation is evident
within the urban area of Turin (outside detailed clutter information was not used in this example).
Starting from such a result it is possible to easily locate transmitting sites of an integrated
transmitter network able to complete the coverage.
Figure 39 SFN DVB-H network of two transmitters, detailed building obstruction evaluation
at receiver quota (1.5 m) within Turin urban area. Indoor (≥
≥ 85% loc): red; outdoor: green;
service unavailability: white. Dark green: city border.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 55 (140)
3.4.3
Exercise 3 (rural area)
3.4.3.1
Required field strength
The purpose of this exercise was to simulate and study the effect of self-interference in SFN. Selfinterference occurs if the margin between the use signal level and the interfering signal level in
reception is smaller than the required protection ratio. The interfering signal is the one received
outside the guard interval.
The effect of self-interference was studied by comparing the simulation results of various network
structures and parameters in one allotment area sized SFN. The studied allotment area is a type of
rural area with lots of lakes. The differences in altitude on allotment area are remarkable.
In this study the used frequency belongs to the UHF band IV. The used modulation is 16-QAM and
FEC is 1/2. The guard interval (GI) is set to be 112 µs. The location probability is 95%. The
required protection ratio (PR) is 27 dB. The PR consists of C/N (17 dB) and probability margin
(10 dB). The types of reception are handheld mobile reception and integrated car antenna mobile
reception. The modified CRC (Communications Research Center) propagation model is used in
predictions.
The planning parameters are as follows:
Table 25 Planning parameters
Thermal noise power [dBW]
Noise figure [dB]
C/N [dB]
Antenna aperture [dBm²]
Min power density [dBW/m²]
Min field strength [dBµV/m]
Vehicle loss [dB]
Location correction [dB]
Required field strength,
planning parameter [dBµV/m]
Handheld mobile
reception
-135
5
17
-27
-86
60
6
9
75
Integrated car antenna
mobile reception
-135
5
17
-17
-96
50
0
9
59
These values are slightly different from the values of Table 20
3.4.3.2
•
Planning exercise
Reference network
The effects of various network types and parameters are studied with a reference network. The
reference network in this study is a type of large area network, which consists of two high power
stations (stations 1 and 7, ERPmax 10 kW) and 27 medium power stations (ERPmax 4 kW). The
used antenna heights (a.g.l.) are 30÷200 m. The antenna type is either omnidirectional antenna
(stations 1, 7, 9, 13, 15) or mast side mounted dipole antenna. The predicted reference network
coverage for handheld mobile reception is represented in Figure 40. In Figure 41 the predicted
coverage area for the integrated car antenna mobile reception is represented.
In the following Figures the yellow colour illustrates coverage area, in which the requirements for
the mobile reception are fulfilled. In green area the field strength requirement is fulfilled but selfinterference occurs.
 2005 CELTIC participants in project Wing TV
page 56 (140)
CELTIC Wing TV project report
Figure 40 Coverage area prediction for the reference network configuration, handheld
mobile reception
Figure 41 Coverage area prediction for the reference network configuration, integrated car
antenna mobile reception
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
•
page 57 (140)
1/4-Guard Interval
In this study case the guard interval was lengthened to 224 µs. Figure 42 represents the prediction
of the reference network for handheld mobile reception with the guard interval of 224 µs. The effect
of self-interference is eliminated by the longer guard interval and the coverage area was increased
by 17%. The same result was gathered with integrated car antenna mobile reception, represented
in Figure 43. The increase in coverage area was 61%. The disadvantage of using a long guard
interval is the loss in system capacity.
Figure 42 Coverage area prediction for the reference network configuration with the guard
interval of 224 µs, handheld mobile reception
 2005 CELTIC participants in project Wing TV
page 58 (140)
CELTIC Wing TV project report
Figure 43 Coverage area prediction for the reference network configuration with the guard
interval of 224 µs, integrated car antenna reception
•
Homogeneous network
Homogeneous network was structured by using uniform ASL antenna heights. The guard interval
was set to be 112 µs. All the stations were set to be medium powered with ERPmax 4 kW. Three
new stations were added on the plan (30÷32). The prediction for handheld mobile reception is
represented in Figure 44. As a result, the coverage area increased 7% in relation to the reference
network. The reduction of the interfered area was 37%. The coverage area prediction for integrated
car antenna mobile reception is represented in Figure 45. The coverage area was increased by
15% and the interfered area was decreased by 22%.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 59 (140)
Figure 44 Coverage area prediction of the homogeneous network configuration, handheld
mobile reception
Figure 45 Coverage area prediction of the homogeneous network configuration, integrated
car antenna mobile reception
 2005 CELTIC participants in project Wing TV
page 60 (140)
•
CELTIC Wing TV project report
Directional antennas
The purpose of this study case was to study the effect of directional antennas on mitigating selfinterference. One central station (1) was selected in the middle of the allotment area and equipped
using omni directional antenna. All other stations were equipped using the mast side mounted
antennas, which were directed away from the central station. The guard interval is 112 µs. The
calculated coverage area prediction for handheld mobile reception is showed in Figure 46. The
coverage area size for the handheld mobile reception remained the same as the coverage area
size in reference network. The size of interfered area was decreased by 38%. The prediction for
the integrated car antenna mobile reception is represented in Figure 47. The coverage area was
increased by 15% whereas the interfered area size was decreased by 28%.
Figure 46 Coverage area prediction for the network with directional antennas, handheld
mobile reception
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 61 (140)
Figure 47 Coverage area prediction for the network with directional antennas, integrated
car antenna mobile reception
3.4.4
Maximum SFN-areas of selected variants
The maximum size of SFN is limited by the self-interference occurring in a network. The
appearance and intensity of self-interference depends on variables, which are the type of network,
code rate, the guard interval, the required protection ratio and the required field strength. The
variables’ effect on the maximum size of SFN is evaluated in the following.
3.4.4.1
Effect of the network type
The types of SFN to be considered are:
1. Dense SFN (low-power and medium-power stations, i.e. ERP less than 10 kW),
2. Mini SFN (one high-power station, i.e. ERP greater than or equal to 10 kW, and at least one
low-power or medium-power station),
3. Large area SFN (more than one high-power stations with any low-power and medium-power
stations).
For the interference-free SFN, the most advantageous type of a network is a dense SFN. Due to
the lower powered stations, the occurring self-interference is limited compared to the interference
occurring in Mini SFN or Large area SFN.
3.4.4.2
Effect of code rate
The used code rate (FEC, MPE-FEC) affects the error tolerance in system. Strong coding can be
used to improve the system performance.
 2005 CELTIC participants in project Wing TV
page 62 (140)
3.4.4.3
CELTIC Wing TV project report
Effect of the guard interval
The maximum SFN area is achieved by using the longest GI 224 µs (see Section 0). The usable
guard interval lengths in a large SFN are 224 µs and 112 µs.
3.4.4.4
Effect of the required protection ratio
The required protection ratio depends on the reception type (pedestrian, mobile). The required
protection ratio in a mobile type of reception is greater than the required protection ratio in
pedestrian reception. As a result the self-interference is more probable to occur in a network stand
for the mobile reception than in a network stand for the pedestrian reception.
3.4.4.5
Effect of the required field strength
The required field strength is related to the reception type and environment. The different scenarios
for the DVB-H systems are fixed, pedestrian outdoor/indoor in urban/suburban/rural environment
and mobile in urban/suburban/rural environment. The coverage area and the interfered area are
maximized if the required field strength is low (see Section 0).
3.5
Planning exercises using “ideal” network structure
3.5.1
Optimal antenna height / EIRP values
The optimal antenna heights were studied in relation to various EIRP values (1 kW, 4 kW, 10 kW,
30 kW). The used antenna heights were 40÷200 m a.g.l. The study was carried out in different type
of environments. The environment types were city area on flat terrain, rural area on flat terrain and
rural area on hilly terrain.
The optimum can be found by examining the gathered coverage area and the estimated costs of
the coverage area in each study case.
Costs include energy, maintenance, equipment bay rent, rent of antenna position and depreciation
of investments.
•
City area, flat terrain
City area in flat terrain
80 dBuV/m
Area [km2]
2500
ERP 1kW
ERP 4kW
ERP 10kW
ERP 30kW
2000
1500
1000
500
0
0
50
100
150
Antenna height [m]
200
250
Figure 48 Predicted coverage area size, city area in flat terrain, indoor coverage
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 63 (140)
City area in flat terrain
80 dBuV/m
Costs
[units/km2]
9.0
ERP 1kW
ERP 4kW
ERP 10kW
ERP 30kW
8.0
7.0
6.0
5.0
4.0
3.0
2.0
1.0
0
50
100
150
Antenna height [m]
200
250
Figure 49 Estimated costs of the coverage area, city area in flat terrain, indoor reception
•
Rural area, flat terrain
Rural area in flat terrain
75 dBuV/m
Area [km2]
2500
ERP 1kW
ERP 4kW
ERP 10kW
ERP 30kW
2000
1500
1000
500
0
0
50
100
150
Antenna height [m]
200
250
Figure 50 Predicted coverage area size, rural area in flat terrain, mobile reception
 2005 CELTIC participants in project Wing TV
page 64 (140)
CELTIC Wing TV project report
Rural area in flat terrain
75 dBuV/m
Costs
[units/km2]
9.0
ERP 1kW
ERP 4kW
ERP 10kW
ERP 30kW
8.0
7.0
6.0
5.0
4.0
3.0
2.0
1.0
0
50
100
150
Antenna height [m]
200
250
Figure 51 Estimated costs of the coverage area, rural area in flat terrain, mobile reception
•
Rural area in hilly terrain
Rural area in hilly terrain
75 dBuV/m
Area [km2]
2500
ERP 1kW
ERP 4kW
ERP 10kW
ERP 30kW
2000
1500
1000
500
0
0
50
100
150
Antenna height [m]
200
250
Figure 52 Predicted coverage area size, rural area in hilly terrain, mobile reception
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 65 (140)
Rural area in hilly terrain
75 dBuV/m
Costs
[units/km2]
9.0
ERP 1kW
ERP 4kW
ERP 10kW
ERP 30kW
8.0
7.0
6.0
5.0
4.0
3.0
2.0
1.0
0
50
100
150
Antenna height [m]
200
250
Figure 53 Estimated costs of the coverage area, rural area in hilly terrain, mobile reception
3.5.2
Maximum SFN-areas of selected variants
The variables effecting on the maximum SFN area were discussed in Section 3.4.4. In this Section,
the aspects of the maximized SFN area are evaluated from an ideal network point of view.
According to the study presented in Section 3.5.1, the high-power stations are preferred when
covering a large area network. With high-power stations, large antenna heights are recommended.
At the same time, when using large antenna heights with high power stations, the occurrence of
self-interference in a network is remarkable.
To achieve the maximum sized SFN by using large antenna heights and high-powers, an efficient
way to mitigate the self-interference is required. The selection of system parameters, like rate of
the convolutional code, MPE-FEC and GI, has an impact on network performance. The error
tolerance of the system can be improved by using small code rate and long GI. The method
impacts on the system capacity.
The effect of self-interference can be mitigated using directional antennas. The disadvantages of
this method are the reduction in coverage area and the loss of SFN gain in the network.
The locally appeared interference can be affected with an artificial delay. The use of artificial delay
is not a way to remove the interference completely, in fact, without a carefully completed delay
strategy, unexpected problem areas might appear elsewhere in the network.
3.6
Comparison of DVB-H and DVB-T networks structures
The comparison of DVB-H and DVB-T networks structures is done with the calculated coverage
area predictions of both networks in one allotment area.
3.6.1
DVB-H network
The predicted DVB-H coverage area is represented in Figure 54. The yellow colour corresponds to
indoor coverage (min. 80 dBµV/m) whereas the red colour corresponds to successful mobile
reception (min. 75 dBµV/m). For the simulation purposes, the network was planned to cover the
city area and the main roads. Few dead spots, which are needed to be covered, can be seen along
the roads.
The ERPmax was 4 kW. Some gap-fillers were added on the plan in southern part of study area.
The total number of transmitters and gap-fillers is 30 (24 + 6).
 2005 CELTIC participants in project Wing TV
page 66 (140)
CELTIC Wing TV project report
Figure 54 Predicted coverage area for the DVB-H network, 24 Tx + 6 gap-fillers, indoor
reception (yellow), mobile reception (red)
3.6.2
DVB-T network
The predicted coverage area for the existing DVB-T network is shown in Figure 55.
The network structure differs from the DVB-H network structure remarkably. The coverage area of
DVB-T network is larger as the reception type is different: the signal is received with fixed roof-top
antenna 10 m above the ground. The required field strength is 55 dBµV/m (95% probability, yellow
area) or 49 dBµV/m (70% probability, red area).
The network consists of the main station (ERPmax 50 kW) and one gap-filler (ERPmax 0.1 kW).
Figure 55 Predicted coverage area for the DVB-T network, 1 Tx + 2 gap-fillers, fixed
reception: probability of 95 % (yellow) and probability of 70 % (red)
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
3.7
page 67 (140)
Conclusions
With respect to the models tuning:
•
The differences, in terms of mean and variance of the error, are not big.
With respect to the planning exercises:
•
From Exercise 1 (Section 3.4.1). From the point of view of the coverage, the same
transmission power provides a better coverage (especially indoors) the larger the number of
transmitters. Benefits from increasing antenna height are more difficult to assess in real-world
scenarios. The indoor coverage is most difficult problem to be dealt in the radio network
planning.
•
From Exercise 2 (Section 3.4.2). The influence of enhanced and integrated antennas in the
coverage is obvious. The urban coverage with enhanced antenna is bigger than the integrated
in any case. The coverage (as in Exercise 1) shows that the number of transmitters (in a SFN
network) increases the area of coverage.
•
From Exercise 3 (Section 0). The maximum size of SFN is limited by the self-interference
occurring in a network. The appearance and intensity of self-interference depend on variables,
which are the type of network, code rate, the guard interval, the required protection ratio and
the required field strength.
With respect to the optimal planning exercises.:
•
According to the study reported in Section 3.5.1, the high-power stations are preferred to be
used when constructing a large area network. With high-power stations, large antenna heights
are recommended. At the same time, when using large antenna heights with high power
stations, the occurrence of self-interference in a network is remarkable.
To achieve the maximum sized SFN by using large antenna heights and high-powers, an
efficient way to mitigate the self-interference is required. The selection of system parameters,
like rate of convolutional code, MPE-FEC and GI, has an impact on network performance. The
error tolerance of the system can be improved by using small code rate and long GI. The
method impacts on the system capacity.
The effect of self-interference can be mitigated using directional antennas. The disadvantages
of this method are the reduction in coverage area and the loss of SFN gain in the network.
 2005 CELTIC participants in project Wing TV
page 68 (140)
CELTIC Wing TV project report
4
Usability of repeaters in DVB-H networks
4.1
Introduction. Need of repeaters in DVB-H cellular
networks
Traditionally, planning of TV broadcast networks has been based on transmitters covering the most
densely populated areas, while, in order to extend massive coverage, repeaters have been used
for their lower cost and complexity.
With the transition to the terrestrial digital video broadcasting (DVB-T), and its possibility to operate
as a single frequency network (SFN), new types of transmitting equipments could be considered.
These different types of equipments can also be used to deploy DVB-H networks, if they include
the new features of DVB-H technology.
As concluded in Section 3, a higher number of low power broadcasting sites would in many cases
provide better and more stable coverage (especially indoor) than a low number of high power
broadcasting sites. In addition, a network based on high power stations have an added difficulty in
managing the planning of the SFN self interferences.
On the other side, as the number of emitting sites increases, there is more need for a repeater
solution that allows a cost-effective massive network deployment. This can be one of the key
factors to success on the deployment of a DVB-H network.
4.1.1
Transmitters, transposers, regenerative repeaters and on-channel
repeaters
Let’s recover the available options for DVB-T as starting point, reviewing shortly what are based
on:
•
Transmitters: Equipment that receives the TS baseband signal by means of a terrestrial link,
digital network or satellite link, and modulates it in COFDM before amplifying and broadcasting
it.
RF
ASI
TRANSMITTER
Figure 56 Transmitters configuration
•
Transposers: Equipment that receives the COFDM signal coming from a transmitter or from
another repeater, filters this incoming signal, amplifies and re-broadcast to a different channel
or band.
F1
F2
TRANSPOSER
Figure 57 Transposers configuration
•
Regenerative repeaters: Equipment that receives the COFDM signal coming from a
transmitter or from another repeater, decodes it to obtain the TS baseband signal in order to
modulate it again in COFDM, and finally amplifies and broadcast. The transmitted channel can
not be the same from the reception.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 69 (140)
F1
ASI
F2
REGENERATIVE
REPEATER
Figure 58 Regenerative repeaters configuration
•
On-channel repeaters: Repeaters where the output channel is the same than the input
channel. Therefore, they are suitable repeaters for SFN networks.
F1
F1
ON-CHANNEL
REPEATER
Figure 59 On-channel repeaters configuration
4.1.2
Cost saving and technical constraints
For each one of the equipment described in Section 4.1.1, the following cost saving and technical
constraints should be taken into account in order to deploy a DVB-H network.
•
Transmitters:
o
o
•
They suppose a high investment for low / middle power stations (modulators, GPS,
network adapter, transport network are needed, with the relevant costs of operation
and maintenance)
The use of more equipment decreases the reliability of the system.
Transposers:
o
They reduce the need of high cost equipment (e.g. modulators are not needed)
o
Less equipment supposes more reliability
But:
o
•
Low spectral efficiency (MFN)
Regenerative repeaters:
o
Possibility to introduce local content
But:
•
o
Need of more equipment (receiver, modulator, GPS)
o
Due the delay of the repeater, no SFN is possible (the signal at the output is out of the
guard interval)
On-channel repeaters:
o
They reduce the need of high cost equipment (e.g. modulators are not needed)
o
Less equipment supposes more reliability
o
High spectral efficiency (SFN)
But:
o
Conventional solution (with no extra devices) is limited in power (due the risk of
oscillation)
 2005 CELTIC participants in project Wing TV
page 70 (140)
4.2
CELTIC Wing TV project report
On-channel repeaters (SFN)
In a first evaluation, and considering as a general case the preference of an SFN network (with no
content differentiation), the use of on-channel repeaters would be the preferred option to deploy a
DVB-H network. But the limitation of conventional on-channel repeaters (this is, the output power
limitation due to lack of isolation) drastically limits the range of application.
An improvement to the limitation of on-channel repeaters has been the use of Echo Canceller
devices. The use of this solution is proved and already working for DVB-T on-channel repeaters,
allowing the deployment of this repeater on DVB-T networks.
But repeaters for DVB-H networks will move from the typical broadcast sites (on rural or mountain
areas with static environments and high towers) to urban sites with highly dynamic environments.
The use of standard echo cancellers for DVB-H on-channel repeaters has been tested within the
Wing TV laboratory and on field tests with these new environment conditions, obtaining the key
requirements needed for on-channel repeaters on a DVB-H network.
4.2.1
The pros and cons of on-channel repeaters in DVB-H networks
As it has been seen, the use of on-channel repeaters is preferred due to:
1. No need of a transport network (satellite link, microwave link, etc.) and related high cost
equipment.
2. The on-channel repeater output signal is on SFN.
3. No need of a GPS synchronisation system. The output frequency is the same as the input as
only one local oscillator is used for the down conversion and up conversion.
But transmitting at the same frequency that is received has several inconvenients:
1. A coupling path between transmitting and receiving antennas is established, having a feedback
system.
2. This feedback between antennas limits the maximum gain of the on-channel repeater to
guarantee the stability of the system. This restriction may lead to transmit very low output
power levels, reducing the coverage area.
3. As a feedback electronic system, it is susceptible to oscillate if the feedback conditions are
reached.
4. The output spectrum is degraded due the multiple echoes of a feedback system. This fact
affects reducing the sensibility, and so on the reduction of the coverage area.
4.2.2
Antenna coupling effect and isolation of installation
On Figure 60 the model for an on-channel repeater is shown. It is a feedback system, as part of the
transmitted signal is induced again to the input due the existing coupling path between transmitting
and receiving antennas.
B
Feedback Path
(i.e. Antennae Coupling)
RF
Received Signal
A
Delay
RF
Output Signal
Gap-Filler
Figure 60 On-channel Repeater diagram
Within the signal bandwidth, the on-channel repeater operates as an amplifier (gain A) followed by
a time delay cell of value (τ). The effect of the antenna coupling can be modelled as a feedback
network of gain B. In addition, the coupling path also has a time delay, but its value is much smaller
than the on-channel repeater delay (τ), so it can be disregarded.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 71 (140)
The transfer function of the system is:
H (ω ) =
A ⋅ e − jωτ
1 − A ⋅ B ⋅ e − jωτ
Another way to express the product A·B is as the gain margin, which can be defined as the
difference between the antenna isolation and the on-channel repeater gain:
Gain Margin (dB) = −20 log 10 ( AB )
Figure 61 shows the response of this system on the time domain.
Amplitude
Gain
margin
Time
τ
τ
τ
Figure 61 Impulse response of the On-channel Repeater system with feed-back.
It can be observed that the relative attenuation between one pulse and its following replica is equal
to the gain margin, and the delay between replicas is the delay value (τ), depending mainly on the
on-channel repeater delay. Therefore, the higher the τ value, and the smaller the gain margin, the
longer the overall impulse response of the complete system.
As a positive feedback system, the stability of the on-channel repeater is only guaranteed if the
gain of the loop is lower than 1 (A·B < 1, or in terms of gain margin, this should be less than 0 dB),
otherwise the system can oscillate.
On the other hand, the effect on the COFDM signal of the feedback loop produces a ripple on the
output spectrum, whose peak to peak amplitude can be calculated from the following expression:
 1 + AB 
Ripple (dBpp) = 20 log 10 

 1 − AB 
Figure 62 illustrates the ripple amplitude as function of the gain margin.
Output Ripple vers us G ain M argin
30
28
26
24
Ripple (dB peak -peak)
22
20
18
16
14
12
10
8
6
4
2
0
0
2
4
6
8
10
12
14
16
Gain M argin (dB )
18
20
22
24
Figure 62 Amplitude ripple vs. gain margin
 2005 CELTIC participants in project Wing TV
page 72 (140)
CELTIC Wing TV project report
It can be observed that as the gain margin gets close to 0 dB the ripple increases significantly. At
0 dB gain margin point the system is instable and becomes non operative.
On laboratory tests [14] it has been checked the recommended operation point for a conventional
on-channel repeater (this is with no extra devices) with positive values and above 10 dB. This
value is preferred in order to avoid an elevated ripple on the signal [9].
This restriction limits significantly the gain (and so on the output power) of the on-channel repeater,
as it has to be always 10 dB below the isolation between the antennas.
It should be taken into account that’ with regards to the type of sites of DVB-H repeaters, they will
be similar to the urban cellular-type sites (small and low masts) instead of broadcast-type sites (big
and tall towers) For DVB-H sites the distance between receiving and transmitting antennas will be
normally lower, and the isolation values should decrease.
So on it can be expected that the isolation between antennas will be rarely higher than 75 dB. This
limits the maximum gain value to be 65 dB. Having an example, with an input level of -40 dBm it
would mean an output power less of 25 dBm (316 mW), value that is far from coverage needs.
4.2.3
Limits of current technology
In order to improve this restriction, echo cancellers have been used in DVB-T on-channel
repeaters, allowing the deployment of this equipment to extend coverage on DVB-T networks.
These devices add extra decoupling and allow higher gain operation for the on-channel repeater.
The following illustration shows schematically the installation diagram for an on-channel repeater
on a typical broadcast site.
Isolation
Received signal
(Pin)
Transmitted signal
(Pout)
Figure 63 Broadcast type installation for an on-channel repeater
As it has been seen, the coupling between antennas through the direct path provokes a single
echo with the following replicas. In Figure 64 the laboratory test simulation for this scenario, where
the performance of a standard echo canceller is checked, is shown.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 73 (140)
1st
2nd
3rd
4th
Figure 64: Standard echo canceller performance on time domain with a single echo, without
(left) and with (right) echo canceller device
It can be seen on the above measurements the cancellation of the echo on the time domain. This
performance allows improving the restriction on the gain (i.e. output power) for on-channel
repeaters.
There are currently some solutions for echo cancellation available from different manufacturers.
Different performances are expected, but echo cancellation features from 5 dB to 12 dB are
achievable.
4.2.3.1
Longer distance echoes
As the installation of the on-channel repeater goes closer to urban areas, as it is expected in order
to guarantee mobile and indoor coverage for the DVB-H service, the environment for on-channel
repeaters is completely different.
In fact, from the different field tests performed on Wing TV Project [13],[14] it is shown that multiple
echoes can be received due to the reflection of the transmitted signal into different “objects” (i.e.
buildings).
The following illustration shows schematically this concept.
Multiple echoes feedback path
Received signal
(Pin)
Transmitted signal
(Pout)
Figure 65 Multiple echo scenario for an on-channel repeater
The following laboratory test shows the performance of the standard echo canceller devices when
multiple echoes are considered. At the left it can be seen the time domain response with no echo
cancellation, where the multiple echoes are present with the following replicas.
 2005 CELTIC participants in project Wing TV
page 74 (140)
CELTIC Wing TV project report
1st
2nd
3rd
Figure 66 Standard echo canceller performance on time domain with multiple echoes,
without (left) and with (right) echo canceller device
In this situation it can be seen on time domain measurements that standard echo canceller only
eliminates part of the echoes (measurement on the right). Specifically, it cancels the first part that
corresponds to the direct path signal from the transmitting antenna, but it doesn’t cancel the longer
distance (time) echoes.
So on, with the performance observed, the use of a standard echo canceller practically does not
improve the limitation of the on-channel repeater, as there are still some echoes remaining and the
gain will be still limited. Therefore the use of this equipment will hardly depend on the environment
conditions of each site. Echo cancellation solutions for DVB-H networks should deal with this type
of multi-echo environment.
4.2.3.2
Varying conditions
In the previous situation the objects considered to provoke multiple echoes for on-channels
repeaters were static. But it has also been observed on field measurements that some time
variations for the environment can be also produced, due to for example moving “objects” (trucks,
trains, etc.).
Figure 67 shows an on field time evolution for the gain margin (isolation).
Gain Margin time-evolution
GM time-evolution (detail)
8
8
6
6
4
4
2
2
GM
(d B ) 0
GM
(d B ) 0
-2
-2
-4
-4
-6
-6
-8
600
610
620
630
640
650
660
T im e (se c )
670
680
690
700
-8
690
691
692
693
694
695
696
T im e (se c)
697
698
699
700
Figure 67 Gain margin (isolation) time evolution on field
It can be observed that in shorts periods of time gain margin (and therefore isolation) can suffer a
variation of even 10 dB.
The following illustration represents this case:
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 75 (140)
Multiple echoes feedback path
Received signal
(Pin)
Transmitted signal
(Pout)
Figure 68 Multiple echo varying scenario for an on-channel repeater
With respect to the previous profile now the multiple echoes are amplitude variable.
Figure 69 Standard echo canceller performance with varying multiple echoes (Impulse
response without (left) and with (right) echo canceller device)
As it can be seen, the operation of a standard echo canceller with this profile does not eliminate all
the convolutions generated and even the first part of echoes is not cancelled. The processing time
that the echo canceller takes to calculate the cancelling values is too large. During this time, the
conditions have already changed.
Echo cancellation solutions for DVB-H networks should deal with this type of variable environment.
4.2.4
Conclusions
From the above analysis we can derive the following conclusions with regards to the use of onchannel repeaters:
•
A larger number of low power broadcasting sites would in many cases provide better and more
stable coverage (especially indoor) than a low number of high power broadcasting sites. In
addition, a network based on high power stations would have an added difficulty in managing
the planning of the SFN self interferences.
•
Considering the above, the on-channel repeater will be a useful element to improve the
coverage.
•
Without some support techniques as Echo Cancellation, the feasibility of the on-channel
repeater depends on the installation conditions (existing isolation between antennas), and
therefore it won’t be considered as a useful tool for a massive network deployment.
•
In general, DVB-H repeaters will be installed under different environments than DVB-T
repeaters, as they will move closer to urban sites. This provokes that conditions for on-channel
repeaters (and therefore for Echo Cancellation techniques) will be harder.
•
It has been seen in the field tests that on-channel repeaters with echo cancellation techniques
for DVB-H applications should deal with some specific environment conditions as:
o
High level of echo cancellation as the isolation between transmitting and receiving
antennas will be lower.
 2005 CELTIC participants in project Wing TV
page 76 (140)
CELTIC Wing TV project report
o
More capacity to cancel multiple objects reflections caused by multiple and longer
distances echoes.
o
Fast tracking speed system in order to assure performance under varying
conditions of urban areas.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
5
Hierarchical modulation issues
5.1
Basics of hierarchical modulation
page 77 (140)
The DVB-H standard, as well as DVB-T, is based on COFDM (Coded Orthogonal Frequency
Division Multiplexing), which uses thousands of narrow-band modulated carriers. The modulation of
each of the carriers can be QPSK, 16-QAM or 64-QAM.
As an extension of the basic constellation, hierarchical modulation can be used.
In hierarchical modulation, the possible digital states of the constellation (i.e. 64 states in case of
64-QAM, 16 states in case of 16-QAM) are interpreted differently than in the non-hierarchical case.
In particular, two separate data streams can be made available for transmission (see Figure 70,
relevant to 64-QAM): the first stream (HP: high priority) is defined by the number of the quadrant in
which the state is located (i.e. a special QPSK stream), the second stream (LP: Low Priority) is
defined by the location of the state within its quadrant (i.e. a 16-QAM or QPSK stream).
Figure 70 Constellation for hierarchical modulation
In example, with reference to Figure 70, we are still dealing with 64-QAM, but, in the hierarchical
interpretation, it is viewed as the combination of 16-QAM and QPSK modulation, and it is referred
to as “QPSK in 64-QAM”.
Moreover, a modulation parameter “α” can be chosen. Typical values are 1 (uniform modulation), 2
or 4 (non-uniform modulation).
Therefore, hierarchical modulation allows the transmission of two streams, having different bit-rates
and performance, in the same RF channel.
The sum of the bit-rates of the two streams is equal to the bit-rate of a non-hierarchical stream
using the same modulation (even if the net data rate is slightly lower, due to the double MPEG-2
TS overhead).
As regards performance, the better protected HP stream has about the same noise sensitivity as a
standard QPSK stream (an α factor of 2 can be chosen to improve the noise sensitivity of the HP
stream), with an impairment of 1÷2 dB due to the “noise-like” presence of the LP stream; the LP
 2005 CELTIC participants in project Wing TV
page 78 (140)
CELTIC Wing TV project report
stream has the same noise sensitivity as the overall scheme in case of α=1, and slightly impaired in
case of higher values of α.
5.2
Usage of hierarchical modulation in DVB-H networks
In the original view, hierarchical modulation was seen as valid solution to transmit the same stream
with two different ruggedness levels: a very robust HP stream, transmitted with low bit-rate, and an
high quality version of the same stream, transmitted on LP with higher bit-rate.
In this way, receiver in the coverage area of the LP stream can display the full quality video,
otherwise they switch to the limited quality version. However, as this solution poses special
requirements to the receivers and at the same time causes a duplication of the needed bandwidth
per TV program, it has not been used in real networks.
In fact, since 1998, DVB-T networks have been switched on in many European countries, and
other networks will be deployed soon, but hierarchical modulation at the moment is not used in any
of them.
However, the introduction of DVB-H could give new impulse to this feature, as it would allow to add
flexibility to the network configuration and re-use existing DVB-T networks, sharing their
multiplexes with DVB-H services.
DVB-H networks will be designed for different reception scenarios (i.e. portable, indoor, mobile,
etc.) with respect to fixed DVB-T reception with roof antenna. Therefore, thanks to hierarchical
modulation, it is possible to compensate the differences in the coverage areas of the two streams,
i.e.:
•
DVB-H on HP (i.e. for indoor coverage) and DVB-T on LP (i.e. for fixed reception),
•
DVB-H on both HP and LP, with different robustness and coverage areas.
5.2.1
Mixing traditional DVB-T and DVB-H services
Traditional proposals for using hierarchical modulation in DVB-H networks (Figure 71) mix
traditional DVB-T services (on the LP stream) with DVB-H services (on the HP stream).
DVB-H
services
TS
Time slicing
IP Encapsulator
Multiplexer
TS (HP)
Modulator &
Transmitter
TS
DVB-T
(MPEG2)
Multiplexer
TS (LP)
Figure 71 Mixing DVB-T and DVB-H services
Transmitting the DVB-H services on the HP stream gives higher robustness for mobile reception;
transmitting DTT MPEG-2 video services on the LP stream allows higher capacity for fixed
reception.
In this scenario, the 4k mode can not be used.
5.2.2
New scenario deploying “DVB-H only” hierarchical networks
A new proposal uses the hierarchical modulation in “DVB-H only” networks, in two possible ways:
•
Progressive degradation of the QoS
•
Multiformat/multidevice support
•
Utilisation of LP stream for upgrading content carried within HP stream
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 79 (140)
It has to be remarked that there is however some work to assess the impact of such scheme in
network planning, terminals implementation and IPDC standardisation (SPP, ESG, handover, etc.).
The authors would like to encourage all the actors to further assess all the possibilities that this
technology is offering.
5.2.2.1
Progressive degradation of the QoS
Digital transmissions are characterised by a rapid signal degradation, and with DVB-H this effect is
even more stressed. In order to guarantee a certain margin, that obliges the use of more robust
DVB-T/H modes and parameters: the price to pay is the decrease of the net bit-rate. MPEG-4 is
here the enabler since the service bit-rate could be as small as 128 kbit/s (for reasonably small
screens), so a number of services still enter in the Mux.
Let’s however use an example: a mobile phone with a PDA-like screen.
Receiving conditions are various: the mobile phone could be inside a building without windows in
the first floor - terrible conditions -, but it could well be outdoor at the bus stop where we have
excellent field strength.
When planning a traditional network, we have to consider the worse case, that is inside the
building: we use a very robust mode, lose bit-rate with redundancy and oblige to use 128 kbit/s as
service bit-rate.
Now, let’s have the hierarchical network example and let’s imagine a simulcast of services encoded
with different bit-rates (i.e. 128 kbit/s in HP stream and 384 kbit/s in LP stream).
The terminal could choose LP or HP depending on its locations and the receiving conditions.
It is well possible that there is more than 15 or 20 dB difference in the field strength in the situation
previously explained in our example, so the receiver, spite the integrated antenna, could receive
outdoor the LP stream and show a very good picture quality to the user, while keeping the service
alive when entering the 1st floor of the building, reducing the picture quality (HP stream).
In this scenario, we are using therefore hierarchical modulation to have a “progressive” degradation
of the QoS (Figure 72).
Quality
DTT - LP stream
analogue TV
DTT - HP stream
<C/N>
Figure 72 Progressive QoS degradation using hierarchical networks
5.2.2.2
Multiformat/multidevice support
There is another way of using hierarchical modulation with “DVB-H only” networks, keeping into
account that not all DVB-H capable devices will have the same characteristics, i.e. there are
devices with larger screens (therefore requiring higher service bit-rate) and the capability to have
external antennas or at least antennas with a higher gain than handheld devices.
In this scenario, LP stream (although requiring a larger C/N than HP stream) could be received by
some of the terminals thanks to the larger antenna gain and occasionally the better receiving
conditions (outdoor or indoor selecting the place where the antenna is located).
The idea is to use the LP stream to provide an upgraded service to those devices.
 2005 CELTIC participants in project Wing TV
page 80 (140)
CELTIC Wing TV project report
As an example, we could consider a portable PC with a DVB-H card, where clearly a service bitrate of 128 kbit/s is not sufficient. It could be a lengthy discussions whether in this case LP services
should be simultcast or different services than the ones in the HP stream and this document will not
enter such “business level of detail”.
Obviously, this scenario includes the previous one.
5.2.2.3
Utilisation of LP stream for upgrading content carried within HP
stream
In the dedicated DVB-H networks hierarchical modulation can be used to optimise bandwidth
usage when the same content is provided in two different bit-rates within the same signal.
Instead of using simulcasting, the content is encoded into two streams so that a first stream is
configured to be transmitted with the HP stream, and a second stream to be transmitted with the
LP stream. The first stream contains ‘normal’ bitrate service. LP stream is configured to contain
additional information for increasing the bit-rate of the first stream. Hence, the ‘normal’ bit-rate
service can be upgraded to higher bit-rate service by decoding upgrade data from the LP stream.
Figure 73 illustrates transmission scheme of the given scenario.
’normal bitrate’ stream
Content
service
system
HP TS1
Modulator
IPE
upgrade stream
Signal
LP TS2
Figure 73 Transmission scheme of the given scenario
It should be noted, that the transmission of content within HP and LP streams must be phaseshifted (as shown in Figure 74), since otherwise reception of such content would be limited only to
receivers which support simultaneous reception of HP and LP streams.
HP
LP
Figure 74 Phase-shifted transmission of content within HP and LP streams
It should be mentioned that the given scenario requires layered codec support from the receiver
and this should be acknowledged when such services are utilised.
5.2.3
Available bit-rates
Hierarchical modulation allows the transmission of two independent MPEG-2 Transport Streams in
the same RF channel, having different modulation schemes and code rates, and sharing the overall
bit-rate.
Table 26 reports the list of available bit-rates, for the HP and LP streams, in case of hierarchical
modulation and 8 MHz bandwidth, considering the possible modulation schemes and coding rate
(rows) and the possible values for guard interval Tg (columns). In case of 7, 6 or 5 MHz bandwidth,
those values have to be reduced proportionally.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 81 (140)
The sum of the bit-rates of the two streams is equal to the bit-rate of a non-hierarchical stream
using the same modulation (even if the net data rate is actually slightly lower, due to the double
MPEG-2 TS overhead).
The values reported in Table 26 are the “DVB-T bit-rates”, i.e. without considering any DVB-H
MPE-FEC. In case MPE-FEC is present, those values have to be reduced accordingly.
Table 26 Available bit-rates for DVB-T hierarchical modulation (8 MHz bandwidth)
Bit-rate (Mbit/s)
QPSK in 16-QAM
QPSK in 64-QAM
5.3
1/2
2/3
3/4
5/6
7/8
1/2
2/3
3/4
5/6
7/8
1/2
2/3
3/4
5/6
7/8
1/2
2/3
3/4
5/6
7/8
Gross
(incl. Tg)
6.22
8.29
9.33
10.36
10.89
6.22
8.29
9.33
10.36
10.89
6.22
8.29
9.33
10.36
10.89
12.44
16.59
18.67
20.74
21.77
1/4
4.97
6.63
7.47
8.29
8.71
4.97
6.63
7.47
8.29
8.71
4.97
6.63
7.47
8.29
8.71
9.95
13.27
14.93
16.59
17.42
1/8
5.53
7.37
8.30
9.21
9.68
5.53
7.37
8.30
9.21
9.68
5.53
7.37
8.30
9.21
9.68
11.06
14.75
16.59
18.43
19.35
1/16
5.85
7.80
8.78
9.75
10.25
5.85
7.80
8.78
9.75
10.25
5.85
7.80
8.78
9.75
10.25
11.71
15.62
17.57
19.52
20.49
1/32
6.03
8.04
9.05
10.05
10.56
6.03
8.04
9.05
10.05
10.56
6.03
8.04
9.05
10.05
10.56
12.06
16.09
18.10
20.11
21.11
HP
LP
HP
LP
Performance with respect to non-hierarchical
modulation
The performance of streams transported with hierarchical modulation is slightly impaired with
respect to non-hierarchical streams.
Table 27 and Table 28 report some values for this impairment with respect to non-hierarchical
modulation, in case of DVB-T signals, with Gaussian and Rayleigh channels, according to recent
simulation results performed by the TM-H Simulation Task Force. C/N at the reception threshold,
and C/N impairment with respect to non-hierarchical modulation are reported.
The impairments indicated in these Tables, together with DVB-H performance derived by means of
laboratory measurements in case of non-hierarchical modulation, can therefore allow to estimate
the DVB-H performance in case of hierarchical modulation streams.
 2005 CELTIC participants in project Wing TV
page 82 (140)
CELTIC Wing TV project report
Table 27 Hierarchical modulation performance – simulation results (QPSK in 16-QAM)
-4
Performance at QEF (BER 10 after Viterbi)
Gaussian
QPSK in 16-QAM
5.1
7.3
8.6
Impairment
(dB)
1.6
2
2.3
7.7
11.4
14.2
Impairment
(dB)
1.8
1.8
1.8
13.5
15.3
16.3
17.3
17.9
6.2
7.4
7
5.9
5.3
15.9
19.5
22.4
25.5
28.2
0.3
2
10.6
10.2
10.1
4.1
6
7.1
0.6
0.7
0.8
6.6
10.3
13.1
0.7
0.7
0.7
17.7
19.4
20.4
21.4
22
10.4
11.5
11.1
10
9.4
20.1
23.6
26.5
29.7
32.3
4.5
6.1
14.7
14.4
14.2
C/N (dB)
α=2
α=4
1/2
2/3
3/4
5/6
7/8
1/2
2/3
3/4
5/6
7/8
1/2
2/3
3/4
5/6
7/8
1/2
2/3
3/4
5/6
7/8
Rayleigh
C/N (dB)
HP
LP
HP
LP
Table 28 Hierarchical modulation performance – simulation results (QPSK in 64-QAM)
-4
Performance at QEF (BER 10 after Viterbi)
Gaussian
QPSK in 64-QAM
8.5
12.5
15
Impairment
(dB)
5
7.2
8.7
11.8
16.4
19.3
Impairment
(dB)
5.9
6.8
6.9
15.5
17.6
18.8
20
20.7
8,2
9,7
9,5
8,6
8,1
18.1
21.6
24.4
27.6
29.7
2.5
4.1
12.6
12.3
11.6
6.5
9.3
11.2
3
4
4,9
9.4
13.5
16.2
3.5
3.9
3.8
17.1
19.2
20.4
21.6
22.2
9.8
11.3
11.1
10.2
9.6
19.6
23.1
25.9
29.1
31.2
4
5.6
14.1
13.8
13.1
C/N (dB)
α=1
α=2
1/2
2/3
3/4
5/6
7/8
1/2
2/3
3/4
5/6
7/8
1/2
2/3
3/4
5/6
7/8
1/2
2/3
3/4
5/6
7/8
Rayleigh
C/N (dB)
HP
LP
HP
LP
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 83 (140)
At the moment, C/N data for the TU6 channel in case of hierarchical modulation are not available
from laboratory measurements. As a first approximation, they can be anyway calculated on the
basis of the C/N for non-hierarchical modulation, adding an impairment as reported in the previous
Tables.
5.3.1
Impact on DVB-H planning
The adoption of hierarchical modulation allows to share the same RF channel among two different
services, but, at the same time, it has an impact on DVB-H planning.
The values of impairment with respect to non-hierarchical modulation reported in Table 27 and
Table 28 allow to adjust the Wing TV planning exercises reported in Section 2:
•
The same results can be achieved by increasing the Tx power by the same amount of the
impairment, when possible
•
Case by case, the impairment causes a reduction in the coverage area, or keeping the same
coverage area, a reduction in the location percentage (e.g. QPSK 1/2 in 64-QAM, α=1: the
impairment is 5 dB, which means that nearly the same coverage area is achieved at 70% loc
instead of 90% loc.)
5.4
Compatibility with current DVB-T receivers
Investigations made on some commercial DVB-T Set-Top-Boxes showed that, unfortunately, many
of the consumer equipments currently available of the market are not able to correctly decode
hierarchical modulation streams: generally, only the HP stream is decoded, and not the LP stream.
This in principle could be a problem in case of introduction of hierarchical modulation for DVB-H
services sharing the same RF channel of DVB-T services.
According to the manufacturers, a software upgrade of the Set-Top-Boxes should be sufficient.
 2005 CELTIC participants in project Wing TV
page 84 (140)
6
CELTIC Wing TV project report
Service Information and handover issues
This Section compiles all the specification from the DVB-H standard regarding signalling and
Handover over DVB-H networks. References to Annex A and B can be found for details on table
and descriptors syntax.
6.1
Basics of PSI/SI Tables
Program Specific Information (PSI) defined in “ISO/IEC 13818-1” [22] provides information to
enable automatic configuration of the receiver to demultiplex and decode the various streams of
programs within the multiplex.
Service Information (SI) defined in “Digital Video Broadcasting (DVB); specification for Service
Information (SI) in DVB Systems” [23] consist of data needed to provide identification of services
and events for the user. In contrast with PSI, which give information only for the multiplex in which
they are contained (the actual multiplex), the additional information defined in SI can also provide
information on services and events carried by different multiplexes, and even on other networks.
Both PSI and SI tables are carried in MPEG-2 private table structures which are segmented into
sections and inserted into Transport Stream packets some with predetermined PIDs and other with
operator selectable PIDs.
The following applies to all PSI tables:
•
The section number of the first section of each sub table is 0x00.
•
The section number is incremented by 1 with each additional section of a sub table.
•
Any addition, the removal or change in content of any section within a sub table affects a
version number change. Two sequential transmissions of a sub table using the same version
number have the same number of sections, and the content and order of sections are identical.
The following applies to all SI tables
•
The section number of the first section of each sub table is 0x00.
•
The section number is incremented by 1 with each additional section of a sub table.
•
Time from the transmission of the last byte of a sub table section to the transmission of the first
byte of the next section of the same sub table is at least 25 ms.
•
Any addition, the removal or change in content of any section within a sub table affects a
version number change. Two sequential transmissions of a sub table using the same version
number have the same number of sections, and the content and order of sections are identical.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
6.2
PSI/SI in DVB-H Networks
6.2.1
MPEG-2 PSI
6.2.1.1
Program Association Table (PAT)
page 85 (140)
Program Association Table (PAT) provides the correspondence between a program_number and
the PID value of the Transport Stream packets which carry the DVB service definition. The
program_number is the numeric label associated with a DVB service. The overall table is contained
in one or more sections. It may be segmented to occupy multiple sections.
PAT is always delivered in the Elementary Stream with the PID 0x0000. For video and audio
coding in broadcasting applications based on the MPEG-2 Transport Stream it is recommended
that all sections of PAT are transmitted at least once in every 100 ms.
A DVB network transmits the PAT on every Transport Stream. The PAT contains no descriptors.
The program loop within PAT contains information about each DVB service within the actual
Transport Stream. If the program_number 0x0000 is announced, the corresponding network_PID
field is set to 0x10.
The program_number of each DVB service available within the Transport Stream is announced.
The corresponding program_map_PID indicates the PID of the PMT sub_table for the DVB service.
A PMT sub_table is carried within an Elementary Stream with PID value between 0x0020 ...
0x1FFE. PMT sub_tables may be spread over multiple Elementary Streams (i.e. PMT sub_table for
each DVB service may be delivered on a different Elementary Stream).
The PAT table does not contain multiple iterations of the program loop with the same value of the
program_number field (i.e. each program_number is announced only once).
PAT syntax is defined in Section A.1.
6.2.1.2
Program Map Table (PMT)
The Program Map Table (PMT) provides mappings between program numbers and the program
elements that comprise them. A PMT sub_table announces the mapping for a single DVB service.
Within a Transport Stream, a PMT sub_table is identified by the program_number. A PMT
sub_table is also referred to as a “program definition”. The PMT is the complete collection of all
program definitions (i.e. all PMT sub_tables) for a Transport Stream.
Each PMT sub_table is transmitted in exactly one section, where the section_number field is set to
0. Different PMT sub_tables may be delivered on different Elementary Streams.
Each PMT sub_table is delivered in an Elementary Stream on the PID announced in the PAT. For
video and audio coding in broadcasting applications based on the MPEG-2 Transport Stream it is
recommended that all transmitted sections of PMT are transmitted at least once in every 100 ms.
The program_number of each DVB program should be unique within the network. The PMT
sub_table for a particular DVB service is transmitted on the same Transport Stream as the referred
DVB service.
PMT syntax is defined in Section A.2.
Descriptors required in PMT for DVB-H are defined in Section B.1.
6.2.1.3
Conditional Access Table (CAT)
Conditional Access Table (CAT) provides information on the CA systems used in the multiplex.
CAT is always delivered in the Elementary Stream with the PID 0x0001.
CAT syntax is defined in Section A.3.
 2005 CELTIC participants in project Wing TV
page 86 (140)
6.2.1.4
CELTIC Wing TV project report
Transport Stream Description Table (TSDT)
Transport Stream Description Table (TSDT) provides information about the entire Transport
Stream, for example the type of target receiver (DVB, ATSC) or the kind of application (e.g. satellite
contribution link). All descriptors carried within the table apply to the entire Transport Stream. PAT
is always delivered in the Elementary Stream with the PID 0x0003. All transmitted sections of the
TSDT shall be transmitted at least every 10s.
TSDT syntax is defined in Section A.4.
Descriptors required in TSDT for DVB-H are defined in Section B.2.
6.2.2
DVB-SI
6.2.2.1
Network Information Table (NIT)
Network Information Table (NIT) conveys information relating to the physical organization of the
multiplexes/Transport Streams within a given DVB network, and the characteristics of the DVB
network itself. DVB networks are assigned individual network_id values, which serve as unique
identification codes for DVB networks. The allocation of these codes may be found in [26].
It is possible to transmit a NIT for other DVB networks in addition to the actual one. Differentiation
between the NIT for the actual DVB network (NIT_actual) and the NIT for other DVB networks
(NIT_other) is achieved using different table_id values.
The NIT is segmented into network_information_sections. Any sections forming part of an NIT are
transmitted in Transport Stream packets with a PID value of 0x0010. Any sections of the NIT which
describe the actual DVB network (that is, the DVB network of which the Transport Stream
containing the NIT is part of) have the table_id 0x40, and share the same table_id_extension
(network_id). Any sections of a NIT which refer to a DVB network other than the actual DVB
network take a table_id value of 0x41.
Each sub_table of the NIT is carried in an Elementary Stream with the PID 0x10. All transmitted
sections of a NIT are transmitted at least every 10 s.
The following applies to the transport_stream_loop:
•
Each iteration announces a DVB signal carrying a Transport Stream of the announced DVB
network.
•
Each Transport Stream belonging to the announced DVB network is announced.
NIT syntax is defined in Section A.5.
Descriptors required in NIT for DVB-H are defined in Section B.3.
6.2.2.2
Bouquet Association Table (BAT)
Bouquet Association Table (BAT) provides information regarding bouquets. A bouquet is a
collection of DVB services, which may traverse the boundaries of a DVB network. The BAT is
segmented into bouquet_association_sections. Any sections forming part of a BAT are transmitted
in Transport Stream packets with a PID value of 0x0011. The sections of a BAT sub_table
describing particular bouquet all have the bouquet_id field set to the value assigned to the bouquet
described in ETSI TR 101 162 [26]. All BAT sections take a table_id value of 0x4A.
BAT syntax is defined in Section A.6.
If linkage_descriptor with linkage type 0x0C is located in the NIT_actual of the DVB network, then
the IPDC DVB-H Network SHALL transmit BAT sub_table (table_id 0x4A) on each of the Transport
Streams referred by the linkage_descriptor. If NIT_actual does not carry linkage_descriptor with
linkage_type 0x0C, IPDC in DVB-H Receiver MAY ignore BAT, if present.
If linkage_descriptor with linkage type 0x0C is located in the NIT_actual of the DVB network, then
following descriptor type SHALL appear in the BAT:
•
Linkage_descriptor with linkage_type 0x0B
If the BAT carries linkage_descriptor(s) with a linkage_type of 0x0B, the following applies:
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 87 (140)
•
The descriptor(s) SHALL announce each DVB service carrying INT sub_table(s) within the
actual DVB network
•
Each of the descriptor(s) SHALL carry exactly one IP/MAC Notification Service Structure
announcing one or more IP/MAC Notification Services.
•
The list of IP/MAC Notification Services announced SHALL be complete. The list is complete if
all INT sub_tables within the DVB network are referred to by at least one linkage_descriptor
with a linkage_type of 0x0B.
6.2.2.3
Service Description Table (SDT)
Service Description Table (SDT) contains data describing the DVB services in the system, e.g. the
name of the DVB service, the service provider, etc. Each sub_table of the SDT describes DVB
services contained within a particular Transport Stream. Depending on the table_id, the services
are available on the actual Transport Stream or on other Transport Streams.
The SDT is segmented into service_description_sections. Any sections forming part of a SDT are
transmitted in Transport Stream packets with a PID value of 0x0011. Any sections of an SDT which
describe the actual Transport Stream (that is, the Transport Stream containing the SDT) have the
table_id value 0x42 with the same transport_stream_id and original_network_id. Any section of an
SDT which refer to a Transport Stream other than the actual Transport Stream takes a table_id
value of 0x46 with the same transport_stream_id and original_network_id.
The transmission of the SDT for the actual Transport Stream is mandatory. The SDT lists all DVB
services of the referred Transport Stream. All transmitted sections of the SDT for the actual
multiplex shall be transmitted at least every 2s.
The EIT schedule flag should be set to value 0x00, indicating that the EIT schedule information for
the DVB service is not present in the TS.
The running status should be set to value 0x04, indicating that the DVB service is currently running.
SDT syntax is defined in Section A.7.
Descriptors required in SDT for DVB-H are defined in Section B.4.
6.2.2.4
Time and Date Table (TDT)
The Time and Date Table (TDT) carries the UTC-time and date information. The TDT consists of a
single section. This TDT section is transmitted in Transport Stream packets with a PID value of
0x0014, and the table_id takes the value 0x70. Transmission of the TDT is mandatory, and it is
transmitted at least every 30 seconds.
TDT syntax is defined in Section A.8.
6.2.2.5
Time Offset Table (TOT)
The Time Offset Table (TOT) carries the UTC-time and date information and local time offset. The
TOT consists of a single section. This TOT section is transmitted in Transport Stream packets with
a PID value of 0x0014, and the table_id takes the value 0x73. Transmission of the TOT is optional.
If transmitted, it is transmitted at least every 30 seconds.
TOT syntax is defined in Section A.9.
6.2.2.6
IP/MAC Notification Table (INT)
The IP/MAC Notification Table (INT) is used to signal the availability and location of IP streams in
DVB networks. The INT describes the availability and location of IP streams. There may be one or
many INTs covering all IP streams of a DVB network. The INT is referenced by a
data_broadcast_id_descriptor with a data broadcast id of 0x000B, in the ES_info loop of the PMT.
Each IP platform having IP streams available within a Transport Stream, is announced in exactly
one INT sub_table in the same Transport Stream. The INT announces all IP streams available
within the actual Transport Stream. The INT may announce IP streams on other Transport Streams
as well. The INT may announce all IP streams on all Transport Streams of the DVB network that a
Receiver can access (by re-tuning).
 2005 CELTIC participants in project Wing TV
page 88 (140)
CELTIC Wing TV project report
INT sub_table SHALL announce each IP stream of the IP platform available on the actual
Transport Stream (i.e. target-loop SHALL contain a descriptor announcing the IP address of the
corresponding IP flow, and the corresponding operational-loop SHALL contain a descriptor
announcing the location of the IP stream within the actual Transport Stream).
INT sub_table SHOULD announce each IP stream of the IP platform available on the neighbouring
Transport Streams. Neighbouring Transport Streams are Transport Streams, which are transmitted
in geographically co-located, adjacent or intersecting cells.
INT syntax is defined in A.10.
Descriptors required in INT for DVB-H are defined in B.5.
Following descriptors MAY appear in target-loop:
•
target_IP_address_descriptor
•
target_IP_slash_descriptor
•
target_IP_source_slash_descriptor
•
target_IPv6_address_descriptor
•
target_IPv6_slash_descriptor
•
target_IPv6_source_slash_descriptor
nd
Each iteration of 2 loop of INT table SHALL contain at least one of the above listed targetdescriptors in target-loop.
Descriptor_length field of any descriptor in this loop SHALL NOT be set to "0" (i.e. the descriptor
SHALL signal at least one IP flow).
An IP flow SHALL NOT be announced in more than one iteration of 2
6.3
nd
loop of INT table.
PSI/SI Tables and Handover in DVB-H Networks
A mobile device, by its nature, is subject to move from one coverage cell to another (understanding
by coverage cell, the area in which there is coverage from one or more transmitters in SFN).
A major benefit of timeslicing is that the receiver may take advantage of the service off time to
apply a handover strategy. This period allows the receiver to look for services in the adjacent cells
while the current service is still being displayed.
One can basically distinguish between the following three cases:
1. Handover to the same Transport Stream (TS)
This case is straightforward since precise time synchronisation of a TS can easily be
accomplished via the same methods as Single Frequency Networks, i.e. via the use of the
DVB-SFN specification (using the MIP). Note that phase shifts (as described in clause 6.3.5.1)
are not appropriate in this case because any significant phase difference between different
versions of the same TS would introduce an unacceptable difference in delay, which would be
directly in opposition to seamless handover.
2. Handover to another TS - fixed phases of bursts
In this case systematic fixed phase shifts are used. Note that phase shifts as such in this case
do not introduce any difference in delay, since the content (i.e. the IP packets) of a particular
burst on a first TS (TS1) is only partly identical to any burst on a second TS (TS2). This
solution does not require any specific signalling - if the network operator sets up the network
with the appropriate phase shifts a receiver could always perform seamless handover even
without specific signalling. A receiver would know the difference between handover to the same
TS and handover to another TS by the TS Id which would be the same in a handover to the
same TS.
3. Handover to another TS - dynamic phases of bursts
This case is a very important case in the long term, since in mature DVB-H networks dynamic
phases will most probably be unavoidable sooner or later and it is desirable to enable
seamless handover also in this case. This is also possible without any specific signalling. A
receiver, which expects its new burst of TS1 at t=t1 could always move to the frequency of TS2
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 89 (140)
and wait there to see if any burst arrives before it has to go back to TS1 and receive the new
burst at t=t1. In a situation with completely random burst phases this would enable the receiver
to perform seamless handover with a fairly high probability. If the handover is not successful in
the first attempt (i.e. the receiver has to go back to TS1) it can try again one or more burst
cycles later, when the phases have shifted.
The receiver will detect the transition from one cell to another by detecting that signal strength has
dropped below an acceptable threshold. This detection may be achieved by various means, some
of them taking into account evaluation of the error rate.
When the receiver enters a new cell, it must tune to a new frequency and then confirm that the
multiplex is carrying the correct service.
Different strategies may be used to select such a new frequency; a non exhaustive list may be:
•
signal scan;
•
use of NIT and frequency_list_descriptor;
•
use of cell information via TPS and NIT;
•
use of INT table (for IP based services).
These mechanisms are based on relevant information inserted in the signal.
These different strategies are presented and discussed in the following sections.
6.3.1
Signal scan
This is the most basic strategy which can be initialized without specific broadcast information.
Signal scan is needed when the receiver holds no information of the existing DVB-H signals and
networks. Respectively, it can be used for updating the availability of DVB-H signals e.g. in case
where NIT_other is not supported by the network.
When the receiver holds no information of the available signals (i.e. it is started first time or after
been switched off and then moving long distance) it enters this process. The receiver may scan the
whole transmission band (e.g. 474 MHz to 698 MHz, [27]) or test specific frequencies, for instance
frequencies previously used to decode the same service (as an example, if the end user lives in
Paris, the greatest probability is that the receiver must tune to one of the frequencies used in
Paris). So the receiver tests a frequency, tries to lock to the signal and when locked, inspects the
Time Slicing indicator from TPS bits. If this is not available, the receiver discards the signal and
proceeds to next one. Once a signal with Time Slicing Indicator is found there are two options,
which depend on whether the signalling of NIT_other is supported by the network.
a)
NIT_other supported:
1.
Receiver inspects NIT_actual and NIT_other of the found signal and stores
announced signals as possible handover candidates.
2.
Scanning can be terminated and found signals can be used as handover
candidates or as input for different iterations enabled by other methods.
3.
Signal scan is no longer required if the following clauses are true:
a)
Receiver holds information of at least one DVB-H signal and is able to
access to it.
b)
b)
NIT_other is supported by the network that the signal is part of.
No NIT_other support:
1.
The receiver continues the scanning process until the end of frequency range (e.g.
until frequency 698 MHz). The set of scanned frequencies can be optimized based on the
found NIT_actual subtables of different networks.
2.
In order to have updated information of all available DVB-H signals and networks,
the receiver has to execute signal scan on regular basis. Even then, the discovery of other
available DVB-H networks succeeds only if the receiver is located on the coverage area of
these networks.
 2005 CELTIC participants in project Wing TV
page 90 (140)
CELTIC Wing TV project report
The process a) is clearly the most optimal from the receiver point of view. The process b), in turn,
always requires a full frequency scan if the discovery of all new DVB-H signals and networks is to
be achieved. However, due to lack of NIT_other it still cannot always be guaranteed.
As a conclusion, in a multinetwork environment where NIT_other is not supported, signal scan may
be slow and inaccurate. However, in the "familiar" environment where availability of signals and
networks are based on empirical knowledge, the receiver can optimize it by limiting the number of
tested signals only to those of existing within the area. Hence, if NIT_other is not supported, this
last option would be retained for most receivers as it is easier to implement in existing hardware.
6.3.2
Use of NIT and frequency_list_descriptor
This process is described in detail in clause 4.5.4.1. of the "Guidelines for the implementation and
usage of SI" of TR 101 211 [28].
The mechanism is based on the tuning on alternative frequencies signalled in the NIT for the
current multiplex.
If we consider a receiver moving within the coverage area of one network, the receiver must
acquire the NIT actual table and in this table the frequency_list_descriptor in order to acquire the
frequencies used to broadcast the multiplex.
When the signal strength decreases below a preset threshold, the receiver tests one of the
frequencies of the list for the current multiplex, it tries to acquire synchronization on this frequency.
Optionally, it checks the time-slicing TPS bit for this frequency, avoiding the need to wait for
irrelevant information (especially SDT table) (this refinement may be used in the process described
in the previous section). It then acquires the SDT and checks the TS identification. If the desired
transport stream is not available it performs a new iteration of the same process. If the desired TS
is still not found, a different TS with the same SID may be looked for by referring to the NIT actual.
This process is rather fast, as it requires acquisition of a reduced amount of SI information, but
broadcasting this information is neither mandatory nor obvious to implement depending on the
network topology, even if it does not require any specific network implementation.
In the case when the receiver may move within different networks, the receiver may acquire
NIT_other tables in order to complement the alternative frequency list. The receiver is able to check
frequencies on other networks ; if the desired TS is not available the receiver may check all the TS
and test the service_list_descriptor on these TS in order to find the desired service, However, it
may be difficult to provide NIT_other tables, especially if the different networks are operated by
different operators.
As described in [28], this process may lead to tuning failures but may be improved by other means.
The first possibility is local SI insertion leading to identification of each cell as a different network; in
such a case the receiver only has to check the frequencies of the neighbouring cells, no longer
using the frequency_list_descriptor but the terrestrial_delivery_system_descriptor in the NIT "other"
sub-tables. This process is quicker but needs specific network implementation, i.e. insertion of SI
on all sites.
A further process relies on the use of two front-ends ; this process will not be described according
to cost considerations. It looks unrealistic for DVB-H receivers. Moreover, it should be noted that
use of frequency_list_descriptor, as described above, does not fit very well for DVB-H.
Frequency_list_descriptor indicates frequencies that convey an identical multiplex. However, even
if two multiplexes are not mutually identical, they may carry exactly the same set of services.
Hence if handover candidates are selected based on such information, a number of valid handover
candidates may be outruled.
Another possibility is the use of cell identification as described below.
6.3.3
Cell identification via TPS and NIT
This mechanism is based on the cell definition and signalling as described in TR 101 211 [28] and
in EN 300 468 [23].
The receiver acquires the cell identification and Time Slicing indicator transmitted in the TPS bits
and the cell-frequency_link_descriptor and the cell_list_descriptor transmitted in NIT. It should be
noted that when cell_id is provided in the TPS bits, which is always the case for DVB-H, both of
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 91 (140)
these descriptors shall be transmitted according to TR 101 211 [28]. In addition, the DVB-H
specification requires the cell list descriptor to be transmitted.
The cell_frequency_link_descriptor provides the frequencies used for the different cells of the
network i.e. it provides mapping between frequencies and cells. Furthermore, once the frequencies
are mapped with Transport Streams in transport_stream loop, mapping between cell and transport
stream can be provided.. The cell_list_descriptor provides a description of the coverage area of the
cells. In EN 300 468 [23], a cell is defined as a geographical area covered by the signals delivering
one or more transport streams by means of one or more transmitters. Cell coverage area, in turn, is
defined as a rectangle that encloses approximately all of the signal coverage of the signals that are
part of that particular cell. Thus, cell coverage area is dependent on the shape of the cell. The
shape of the cell, in turn, depends on the transmitters transmitting the signals and on the landscape
and environmental effect for the propagation of signals. The following figure illustrates an example
of the cell coverage area definition according to the EN 300 468 [23] where the omnidirectional
signal is transmitted by one transmitter and is not affected by the landscape or by any other
environmental factors.
DVB-T/H Transmitter
Ex
ten
to
f lo
ng
itud
e
ent
Ext
de
titu
a
l
of
Longitude & Latitude (Corner of
the spherical rectangle)
Figure 75 Cell coverage area in case of omnidirectional signal as defined in [23]
Parameter
Description
Extent of longitude
The extent of longitude of a spherical rectangle
describing the approximate coverage area of the
cell.
Extent of latitude
The extent of latitude of a spherical rectangle
describing the approximate coverage area of the
cell.
Longitude
Longitude of the corner of a spherical rectangle
describing the approximate coverage area of the
cell.
Latitude
Latitude of the corner of a spherical rectangle
describing the approximate coverage area of the
cell.
Table 29 Parameters related to cell coverage area
The receiver determines the neighbouring cells comparing the locations of the different cells (this
process may be helped and improved by use of GPS data if available). However, only approximate
signalling can be provided for the cell coverage area. It should be noted that, it even provides
erroneous information as it indicates that some areas beyond the actual cell coverage area
signalled as part of the cell. Furthermore, in the current method, there are no means for indicating
signal strength levels within the different areas of the cell coverage area. Hence, if cell coverage
information is used as the basis for selecting handover candidates it should always be followed
with more precise method (e.g. qualification of handover candidates on the basis of signal quality).
 2005 CELTIC participants in project Wing TV
page 92 (140)
CELTIC Wing TV project report
This process is rather fast but it requires a specific network implementation, and a specific receiver
implementation, the required amount of SI information is larger if NIT other tables are used.
For all the processes described in the previous sections, the acquisition of the convenient IP
stream is done using INT tables.
Note that the frequencies signalled in NIT should include any possible offsets. For example, in case
of centre_frequency parameter, the signalling in the related descriptors must be updated each time
when centre_frequency changes.
6.3.4
Use of INT tables
This process is specific to IP streams carried on DVB-H networks. It may be used to improve the
above mechanism in the case of DVB-H services. According to its specificity, this process is further
detailed below.
Two IP streams carry the same IP datagram stream if all the following is true:
•
Source IP addresses are identical.
•
Destination IP addresses are identical.
•
IP streams are associated with the same IP platform.
•
Destination IP address is not in unicast range, or the IP streams are carried on different
transport streams.
Note that unicast IP streams (destination IP address is in unicast address range) in a single
transport stream are considered carrying different IP datagram streams. However, unicast IP
streams on different transport streams are considered carrying the same IP datagram stream.
If two IP streams carry the same IP datagram streams, a receiver may use any of the IP streams to
receive the particular IP datagram stream. A receiver may attempt to accomplish a soft handover
between such IP streams.
INT table consist of sub_tables, each for a particular IP platform (identified by platform_id). INT
always announces all IP streams on the actual transport stream. To support handover, INT
announces all IP streams on the actual cell and on all adjacent/intersecting cells. If INT does not
indicate a particular IP service being available on a particular transport stream, a receiver may
assume that the IP service is not available on the transport stream. Receiver should check the
availability of IP services on adjacent/intersecting cells every time when entering a new cell, as the
INT of each cell may not announce IP streams on transport streams that are not
adjacent/intercepting with the actual cell.
To announce an IP stream, INT contains one or multiple target descriptors (e.g.
target_IPv6_address_descriptor) in a target_descriptor_loop, and one or multiple IP/MAC
stream_location_descriptors (one for each IP stream carrying IP datagrams with announced
source/destination IP addresses) in the associated operational_descriptor_loop. For more
information on usage of INT, see Data Broadcasting specification [29].
To enable handover, it is essential that each INT sub_table available on a particular transport
stream is announced adding a linkage_descriptor with linkage_type 0x0B into the NIT or BAT
carried on the transport stream. If BAT is used, the NIT on the transport stream shall contain
linkage_descriptor with linkage_type 0x0C, announcing the BAT.
To better support reception of Time Sliced services, the INT_versioning_flag in the
IP/MAC_notification_info structure carried on the PMT announcing an INT shall be set to 1,
indicating that the PMT announces the version updates of the announced INT.
When receiving a particular IP service, a soft handover may be accomplished using the below
described procedure:
1. Receiver uses INT on the source transport stream to check for the availability of the IP service
(i.e. availability of IP datagram stream(s) carrying the IP service) on other (destination)
transport streams. If the INT does not announce the requested service (i.e. all IP datagram
streams carrying the IP service) on any other transport stream, soft handover may not be
accomplished.
2. Receiver checks for availability of the destination transport streams. If none the destination
transport streams are available (receiver cannot synchronize to the transport stream),
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 93 (140)
handover may not be accomplished. To check for the availability of a particular transport
stream, following procedure may be used:
a)
Receiver attempts to lock to the frequency announced in the NIT for the
requested transport stream. If locking fails, the transport stream is not
available. This typically occurs in large terrestrial networks, where different
frequencies are used in different areas.
b)
If lock succeeds, the receiver checks for the Time Slicing indicator from TPS
bits. If it indicates that signal carries DVB-H services, next the cell_id is
checked. Otherwise signal is discarded and next signal is proceed. If the
cell_id announced on TPS bits does not match with the cell_id announced in
NIT (on the source transport stream) for the requested transport stream, the
signal does not carry the transport stream. This typically occurs in large
terrestrial networks, where a particular frequency is used in different areas for
different purposes (e.g. two cells may use the same frequency, if the cells are
located far from each others).
c)
If the cell_id matches, receiver assumes that the signal carries the requested
transport stream, and the transport stream is available at the current location of
the receiver.
3. Receiver chooses the destination transport stream supporting the best signal-to-noise ratio,
and tunes to the signal carrying the transport stream.
4. Receiver uses the service_id (announced in the INT on the source transport stream) to find the
PMT sub_table, and the component_tag (announced in the INT on the source transport
stream) to get the PID of the elementary stream carrying the requested IP datagram stream(s).
5. Reception of the IP service (i.e. IP datagram stream(s) carrying the service) may continue on
the destination transport stream.
Requirements for the receiver
•
INT is checked every time when entering a transport stream.
Requirements for the network
•
Each transport stream of a cell has identical coverage area (otherwise the described process
may fail). Preferably only one transport stream per cell.
•
INT announces all IP stream on the actual and on all adjacent/intersecting cells.
•
INT is announced by adding linkage_descriptor with linkage_type 0x0B into the NIT on the
actual transport stream. The list of announced INTs is complete (i.e. all INTs of the actual
network are announced).
•
If the NIT cannot be used for announcing INTs, then the NIT contains linkage_descriptor with
linkage_type 0x0C, announcing BAT on the actual transport stream. The BAT contains
linkage_descriptor with linkage_type 0x0B. The list of announced INTs (in the BAT) is complete
(i.e. all INTs of the actual network are announced).
•
If a transport stream carries no INT (and therefore no IP streams), the NIT on the particular
transport stream should still announce INTs on other transport streams of the actual network. If
BATs are used to announce INTs, each NIT of the network should announce each such BAT
on the network.
Cell_id is mandatory for each cell where DVB-H services are delivered. The cell_id has to be
announced in TPS bits as well as in the DVB-SI.
The content of the NIT_actual is typically quasi-static, but may however sometimes change due to
network modifications and/or evolvement. A DVB-H capable receiver must therefore be able to
detect such changes.
The NIT_actual shall contain applicable delivery system descriptors for the actual delivery system.
To support re-transmission of multiplexes on different type of delivery systems, the DVB SI
specification allows non-applicable delivery system descriptors in the NIT_actual. However, when
DVB-H services are supported, the NIT_actual shall contain the applicable delivery system
descriptors for the actual delivery system. Also, the NIT_actual shall announce all multiplexes of
the actual delivery system, and it shall contain one or more cell_list_descriptors announcing cells
and subcells of the network. The list of announced cells and subcells shall be complete.
 2005 CELTIC participants in project Wing TV
page 94 (140)
CELTIC Wing TV project report
For each multiplex announced in the NIT_actual, terrestrial_delivery_system_descriptor and
cell_frequency_link_descriptor shall be present. If the multiplex is available on multiple frequencies
within the network, the other_frequency_flag in the terrestrial_delivery_systen_descriptor shall be
set. The list of announced frequencies in the cell_frequency_link_descriptor shall be complete.
To better support handover between networks supporting DVB-H services , the presence of
NIT_other for each adjacent networks is proposed.
The INT table shall announce all IP streams on the actual multiplex. To support handover, the INT
shall also announce all IP streams on all adjacent cells of the actual network. In addition, it is
proposed that the INT also announces IP streams on adjacent cells on other networks.
It is proposed that the time_slice_fec_indicator_descriptor is placed in INT, so that a receiver may
detect the support for time-slicing on adjacent cells before accomplishing a handover.
Note that a receiver can accomplish handover only if it knows the requested service is available on
another multiplex and/or frequency. Therefore it is vitally important that a multiplex announces the
content of adjacent multiplexes by means of INT announcing IP streams on adjacent cells, that all
frequencies of each multiplex are announced in the NIT_actual, and that the geographical locations
of each cell is announced in the NIT_actual.
This process will be rather fast as the amount of frequencies to test will be reduced, it requires
broadcasting of specific SI information (but such information will be mandatory for DVB-H
networks) and as such it may require a relatively large amount of SI information.
6.3.5
Time slice synchronization for seamless handover support
When a terminal changes from one DVB-H cell to another, ideally it should be able to seamlessly
continue receiving the current service in the new cell without any packet loss, assuming that the
service is available in both cells. A cell in this context is a subsystem that may consist of one or
several transmitters sending entirely identical content on the same frequency (Single Frequency
Network, SFN). Within a cell, no handovers are necessary. When designing the network cells
without regard to the phase constellation of the time slices of the corresponding services in
adjacent cells, seamless handovers may not be possible.
Assuming that the transmitters of two cells are fed by an IP stream containing a certain service and
have their own DVB-H encoders (MPE, time slicing, ...), IP network delay and packet jitter which
may be different for two transmitters of different cells transmitting the same service have to be
taken into account. So, if the time slices of the two transmitters will be sent out at the same time,
they may contain not exactly the same data and therefore cause packet loss when realizing
handovers. This problem is even worsened if the slices of one service in adjacent cells overlap as
they can only be decoded in total.
6.3.5.1
Phase shifting
To overcome the previously mentioned problems, a static phase shift between the two cells may be
applied (“Phase Shifting”). In this case, the phase shift should be at least the maximum time of the
time slice plus the time the terminal needs for synchronization to the new stream. Figure 76
illustrates how the overlapping of IP packets (one example marked in grey in the Figure) ensures
loss-free handovers.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 95 (140)
IP packet
IP feeding
stream to cell 1
5
6
DVB-H
time slice
Signal of
cell 1
IP feeding
stream to cell 2
Signal of
cell 2
4
4
5
7
8
1
0
9
1
1
1
2
1
3
1 2 3 4 5 6
6
7
1
4
7 8 9
8
9
1
0
1 2 3
1
1
1
2
1
3
1
4
4 5 6 7 8 9
t
Phase shift
Figure 76 Phase shift principle (time axis not to scale)
In real networks, more than two cells have common borders, so more than two different phase
shifts are needed. With four different phase shifts loss-free handover between any two cells will be
possible, no matter how the shape of the cells might be (mathematical four colour problem).
Depending on the cell shape, e.g. with a hexagonal one, it might be possible to use less different
phase shifts. The design of a “phase shift map” is very similar to frequency planning in cellular
communication networks.
Next figure illustrates how the time slices of a service have to be phase shifted in four adjacent
cells in order to allow seamless handovers. It was taken into account that the terminal needs a
synchronization time to tune to the signal of the new cell and starts receiving the corresponding
service. Additionally, a safety margin was added in order to deal with possible time slice jitter.
Safety margin
Sync. time
Time slice
Cell 1
Cell 2
Cell 3
Cell 4
t
Figure 77 Phase shift planning
6.3.5.2
IP Encapsulators synchronisation
Another option to fix this issue is to synchronize all the IP Encapsulators in such a way that all
transmitted time slice bursts in all the cells have the same content and are transmitted
simultaneously.
This kind of solution would remove the requirement of the minimum amount of phase shifting, and it
would become possible to choose burst time and cycle time more independently.
Note: The description of how this synchronization can be implemented is out of scope of this
document.
 2005 CELTIC participants in project Wing TV
page 96 (140)
7
CELTIC Wing TV project report
Quality of Service
The object of this Section is to define the Wing TV QoS parameters for the DVB-H technology.
Quality of Service has been subject of study by many organizations as ETSI, DVB or ITU. Wing TV
has not studied in depth QoS as it is not the main object of the Project, since the studies are
centred in the physical and link layer without performing any subjective testing.
The object here is to provide a proposal of the most relevant QoS parameters at the different
levels. QoS parameters are important for defining the quality of the received signal at different
points. They are used, for example, to define the conditions of handover, or, in the case of an
encapsulator, to manage the bandwidth allocation or the quality of the input IP streams. QoS must
be guaranteed and managed in different parts of the transmission and receiving chain.
In this document the parameters are divided into three groups:
•
IP Encapsulator: QoS parameters managed by the IP DVB-H encapsulator (IPE);
•
IP Transport Network: QoS parameters in a generic transport network;
•
Terminal side: QoS parameters measured by a DVB-H receiver.
7.1
Reference architecture
7.1.1
Network (Reference points)
The next Figure defines the network reference points from the encapsulator to the transmitter.
Network
adapter
Distribution
DCN
network
DVB-H IP
Encapsulator
IP Reference point
(encapsulator)
DVB-H
Receiver
Network
adapter
Ts Reference point
(encapsulator)
DVB-H
Transmitter
Ts Reference point
(transmitter)
RF Reference point
(transmitter)
Figure 78 Network reference points
There are the following reference points:
•
IP Reference point (encapsulator)
•
TS Reference point (encapsulator)
•
TS Reference point (transmitter)
•
RF Reference point (transmitter)
7.1.2
Reference receiver (Reference points)
The next Figure shows the DVB-H reference receiver model [9] with the reference points:
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
Field
Strength
E
Antenna
Gain
Ga
page 97 (140)
Optional External
Antenna Connector
Noise
Factor
F
Optional
GSM
Reject
Filter
LGSM
Input
Power
Pin
Only in DVB-H Receiver
DVB-T
Demodulator
RF-Reference
point
DVB-H
Time
Slicing
TS-Reference
point
DVB-H
MPEFEC
FERReference
point
DVB-H
IP-Deencapsulation
IP-Out
text
MFERReference
point
IP-Reference
point
Figure 79 DVB-H reference receiver model with reference points
The QoS parameters can be measured in the reference points defined in the reference receiver [9]:
•
RF-Reference point
•
TS-Reference point
•
FER Reference point
•
MFER Reference point
•
IP-Reference point
7.2
QoS network parameters
7.2.1
QoS on Transport Network
This Section includes the QoS parameters for a transport network based on IP technology [24].
7.2.1.1
RTP packet jitter
•
Name: RTP Packet jitter
•
Point: IP Reference point / Ts Ref. point (encapsulator)
•
Description: the variation of the delay between the RTP streaming source and the device. The
peak to peak jitter implies that the deviation in the network delay must be in the range
-J/2≤ d ≤ +J/2. The receiver should fulfil the Real Time Interface Specification (ISO/IEC
13818-9) with t-jitter = 20 ms. The maximum peak to peak jitter should be of 40 ms.
•
Impact / Influence: packet loss can cause image artefacts in the receiver.
7.2.1.2
IP Packet Loss
•
Name: IP Packet Loss
•
Point: IP Reference point / Ts Ref. point (encapsulator)
•
Description: Ratio of IP packets lost. It is recommended one image artefact per hour. The error
ratio that results from this quality level depends on the Transport Stream bit-rate. For example,
for a TS of 4 Mbit/s with 7 TS packets for every IP packet, one error per hour it is equivalent to
-6
an IP packet error ratio of kles than 1·10 .
•
Impact / Influence: packet loss can cause image artefacts in the receiver.
 2005 CELTIC participants in project Wing TV
page 98 (140)
CELTIC Wing TV project report
7.2.2
QoS Parameters in IPE
7.2.2.1
Channel Switching Delay
•
Name: Channel Switching Delay
•
Point: Ts Reference point (encapsulator)
•
Description: Time switching from channel A to channel B. It is measured as the period of time
between last TS packet of burst A and last TS packet of burst B.
•
Impact / Influence: direct impact on the time that the receiver needs to switch from channel A to
channel B.
7.2.2.2
Power Saving
•
Name: Power Saving
•
Point: Ts Reference point (encapsulator)
•
Description: Power Saving in channel A. It is measured according to the following equations:
•
Bd
Burst Duration (seconds)
Bs
Burst Size (bits)
Bb
Burst Bitrate (bits per second)
Cb
Constant Bitrate (bits per second)
Ot
Off-time (seconds)
St
Synchronization Time (seconds)
Ps
Power Saving (per cent)
Dj
Delta-t Jitter (seconds)
Bd =
Ot =
Ps =
Bs
Bb × 0,96
Bs
Cb × 0,96
(1 -
- Bd
(Bd + St + (3/4 × Dj)) × Cb × 0,96
Bs
) × 100 %
Impact / Influence: it affects the duration of the battery of the receiver while the receiver is
tuned on channel A.
7.2.2.3
Access Delay
•
Name: Access Delay to channel A
•
Point: Ts Reference point (encapsulator)
•
Description: Access to packets from new stream on new time-slice burst.
•
Impact / Influence: direct impact on the time that the receiver needs to start receiving channel
A.
7.2.2.4
IP Encapsulation Delay
•
Name: IP Encapsulation Delay in channel A
•
Point: IP Reference point (encapsulator) / Ts Reference point (encapsulator)
•
Description: time between the time point when an IP packets arrives in the IPE and the time
when this IP packet goes out of the IPE in TS packets.
•
Impact / Influence: delay inserted by the broadcast network.
7.2.2.5
IP Loss Data
•
Name: IP Loss data in channel A
•
Point: IP Reference point (encapsulator) / Ts Reference point (encapsulator)
•
Description: Ratio between the output IP rate at the TS Reference point and the input IP rate at
the IP Reference point (encapsulator) of all the IP flows part of channel A. Measured as:
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 99 (140)
 IPRateTS 
IPLossData = 100 ⋅ 1 −

 IPRateIP 
•
Impact / Influence: If the IP rate at the IP reference point exceeds the maximum allowed bitrate configured for a service, the IP encapsulator will discard IP packets.
7.3
QoS Terminal side
7.3.1
Physical and Link Layer parameters
7.3.1.1
C/N
•
Name: Carrier to Noise Ratio
•
Point: RF-Reference point
•
Description: A measure of the received carrier strength relative to the strength of the received
noise. High C/N ratios provide the quality of reception of the communication channel.
•
Impact / Influence: Direct influence in the detected signal quality. High C/N ratios, depending
to the adopted modulation of the OFDM carriers, provide better quality of reception and
generally higher communication reliability, than low C/N ratios.
7.3.1.2
RSSI
•
Name: Received Signal Strength Indicator
•
Point: RF-Reference point
•
Description: Indicates the strength of the incoming (received) signal in a receiver. In
communication systems, it is usually expressed in dBm.
•
Impact / Influence: Direct influence: influence in the detected quality of the signal as it is related
with the C/N ratio.
7.3.2
Specific DVB-H parameters
7.3.2.1
FER
•
Name: Frame Error Rate
•
Point: FER-Reference point
•
Description: DVB-H specific QoS parameter defined as the ratio of the number of erroneous
frames and total number of received frames [25]. It is recommended to analyse at least 100
frames to provide sufficient accuracy,
FER[%] =
•
Number of Erroneous Frames × 100
Total Number of Frames
Impact / Influence: Influence in the quality of the received signal. It is agreed to use a 5%
MFER criteria as the degradation point of the DVB-H service. The service reception quality at
the 5 % MFER degradation point may not meet the QoS requirement in all cases [9].
7.3.2.2
MFER
•
Name: MPE-FEC Frame Error Ratio
•
Point: MFER-Reference point
•
Description: DVB-H specific QoS parameter defined as the ratio of the number of erroneous
frames after MPE-FEC correction and total number of received frames [25]. It is recommended
to analyse at least 100 frames to provide sufficient accuracy,
 2005 CELTIC participants in project Wing TV
page 100 (140)
CELTIC Wing TV project report
MFER[%] =
•
Number of Erroneous Frames (after MPE - FEC correction) × 100
Total Number of Frames
Impact / Influence: influence in the quality of the received signal. It is agreed to use a 5%
MFER criteria as the degradation point of the DVB-H service. The service reception quality at
the 5 % MFER degradation point may not meet the QoS requirement in all cases [9].
7.4
LIST OF QoS PARAMETERS
PARAMETER
DESCRIPTION
QoS POINT
Encapsulator (IPE)
Channel Switching delay
Time switching from channel A to channel B
Ts Ref. point (encapsulator)
Power saving
Power Saving in channel A
Ts Ref. point (encapsulator)
Access delay
Access to packets from new stream on new
time-slice burst
Ts Ref. point (encapsulator)
IP encapsulation delay
Time between the time point when an IP
IP Ref. point (encapsulator) /
packets arrives in the IPE and the time when
Ts Ref. point (encapsulator)
this IP packet goes out of the IPE in TS packets
IP Loss Data
Ratio between the output IP rate at the Ts
Reference point and the input IP rate at the IP
Reference point (encapsulator) of all the IP
flows part of channel A
IP Ref. point (encapsulator) /
Ts Ref. point (encapsulator)
RTP packet jitter
the variation of the delay between the RTP
streaming source and the device
IP Ref. point (encapsulator) /
Ts Ref. point (encapsulator)
IP Packet Loss
Ratio of IP packets lost
IP Ref. point (encapsulator) /
Ts Ref. point (encapsulator)
Transport IP network
Terminal side
C/N
A measure of the received carrier strength
RF-Reference point
relative to the strength of the received noise.
RSSI
A signal or circuit that indicates the strength of
the incoming (received) signal in a receiver.
(The signal strength indicator on a cell phone
display is a common example)
RF-Reference point
FER
DVB-H specific QoS parameter defined as the
ratio of the number of erroneous frames and
total number of received frames
FER-Reference point
MFER
DVB-H specific QoS parameter defined as the
ratio of the number of erroneous frames after
MPE-FEC correction and total number of
received frames
MFER-Reference point
Table 30 List of QoS parfameters
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
8
page 101 (140)
Conclusions
This document deals with the issues relevant to DVB-H network architecture and planning.
In particular, the amount of data coming from laboratory and field trials, carried out in the
framework of the CELTIC Wing TV Project, allows to define and validate new and more precise
channel models, especially for pedestrian reception, and to fine-tune the DVB-H link budget
calculations
In particular, a common set of planning parameters has been defined, according to the various
reception conditions. Application of these parameters to proper planning tools allows to evaluate
the optimal network architecture for deploying the DVB-H services in any specific condition.
These results will be an input to the DVB-H Implementation Guidelines.
 2005 CELTIC participants in project Wing TV
page 102 (140)
CELTIC Wing TV project report
References
[1]
Wing-TV: “Finnish field trial report”, Internal report, April 2006.
[2]
W.C. Jakes ed.: “Microwave Mobile Communications”, Wiley, New York, 1974.
[3]
Commiss. Euro. Communities: “Digital Land Mobile Radio Communications – COST 207“,
ECSC-EEC-EAEC Brussels, Luxembourg, 1989.
[4]
J. Lago-Fernandez and J. Salter: “Modelling impulsive interference in DVB-T”, EBU
Technical Review, July 2004.
[5]
T.S. Rappaport: “Wireless communications”. Prentice Hall. 1996.
[6]
ETSI EN 302 304: "Digital Video Broadcasting (DVB); Transmission System for Handheld
Terminals (DVB-H)". November 2004.
[7]
ETSI EN 300 744: “Digital Video Broadcasting (DVB); Framing structure. channel coding and
modulation for digital terrestrial television”. June 2004.
[8]
Wing TV: “Selection of DVB-H Modes for further work in Wing TV”, WP6, Nokia.
[9]
ETSI TR 102 377: “Digital Video Broadcasting (DVB); DVB-H Implementation Guidelines”.
[10]
“Mobile and Portable DVB-T Radio Access Interface Specification”, EICTA / TAC /
MBRAI-02-16.
[11]
Wing TV: “Wing TV common Laboratory Tests”, WP4 deliverable D4, 2006.
[12]
Wing TV: “Wing TV Companies lab tests”, WP4 deliverable D5, 2006.
[13]
Wing TV: “Wing TV Common Field Trials”, WP5 deliverable D6, 2006.
[14]
Wing TV: “Wing TV Companies field trials”, WP5 deliverable D7, 2006.
[15]
Wing TV: “Wing TV Reference Receiver description”, WP3 deliverable D3, 2006.
[16]
Wing TV: “Spain Field Trial Report”, WP5 Internal Report PF3.
[17]
ITU-R 1546: “Method for point-to-area predictions for terrestrial services in the frequency
range 30 MHz to 3000 MHz”.
[18]
CEPT/FM-PT24(04) 034 Annex 3 Draft: "Planning Configurations and Reference Networks
for DVB-T".
[19]
ITU-R 526: ‘Propagation by diffraction’.
[20]
A. Schertz. C. Weck: “Hierarchical modulation – the transmission of two independent DVB-T
multiplexes on a single frequency”. EBU Technical Review. 2003.
[21]
CEPT: “Planning and Introduction of Terrestrial Digital Television (DVB-T) in Europe”,
December 1997.
[22]
ISO/IEC 13818-1: "Information Technology - Generic Coding of Moving Pictures and
Associated Audio Recommendation H.222.0 (systems)".
[23]
ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information
(SI) in DVB Systems".
[24]
ETSI TS 102 034: "Digital Video Broadcasting (DVB); Transport of MPEG2 base services
over IP", February 2003.
[25]
ETSI TR 102 401: “Digital Video Broadcasting (DVB); Transmission to Handheld Terminals
(DVB-H); Validation Task Force Report”, May 2005.
[26]
ETSI TR 101 162: "Digital Video Broadcasting (DVB); Allocation of Service Information (SI)
codes for DVB systems".
[27]
EICTA/TAC/MBRAI-02-16:
Specification”.
[28]
ETSI TR 101 211: “Digital Video Broadcasting (DVB); Guidelines on implementation and
usage of Service Information (SI)”.
“Mobile
and
Portable
DVB-T
Radio
Access
Interface
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 103 (140)
[29]
ETSI EN 301 192: “Digital Video Broadcasting (DVB); DVB specification for data
broadcasting”.
[30]
ISO 639-2: "Code for the representation of names of languages - Part 2: Alpha-3 code".
[31]
ISO 8859-1: "Information technology - 8-bit single-byte coded graphic character sets - Part 1:
Latin alphabet No. 1".
[32]
IETF RFC 1112 (1989): "Host extensions for IP multicasting".
[33]
IETF RFC 2464 (1998): "Transmission of IPv6 Packets over Ethernet Networks".
 2005 CELTIC participants in project Wing TV
page 104 (140)
CELTIC Wing TV project report
Annex A - PSI / SI Tables syntax
A.1
PAT Syntax
Syntax
program_association_section() {
table_id
section_syntax_indicator
'0'
reserved
section_length
transport_stream_id
reserved
version_number
current_next_indicator
section_number
last_section_number
for (i=0; i<N;i++) {
program_number
reserved
if(program_number == '0') {
network_PID
}
else {
program_map_PID
}
}
CRC_32
}
No. of bits
Mnemonic
8
1
1
2
12
16
2
5
1
8
8
uimsbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
bslbf
uimsbf
bslbf
uimsbf
uimsbf
16
3
uimsbf
bslbf
13
uimsbf
13
uimsbf
32
rpchof
Table 31 Program Association Section Syntax
A.1.1 Semantic definition of fields in program association section
table_id -- This is an 8 bit field, which shall be set to 0x00.
section_syntax_indicator -- The section_syntax_indicator is a 1 bit field which shall be set to '1'.
section_length -- This is a twelve bit field, the first two bits of which shall be '00'. It specifies the
number of bytes of the section, starting immediately following the section_length field, and
including the CRC. The value in this field shall not exceed 1021
transport_stream_id -- This is a 16 bit field which serves as a label to identify this Transport
Stream from any other multiplex within a network. Its value is defined by the user.
version_number -- This 5 bit field is the version number of the whole Program Association Table.
The version number shall be incremented by 1 whenever the definition of the Program Association
Table changes. Upon reaching the value 31, it wraps around to 0. When the current_next_indicator
is set to '1', then the version_number shall be that of the currently applicable Program Association
Table. When the current_next_indicator is set to '0', then the version_number shall be that of the
next applicable Program Association Table.
current_next_indicator -- A 1 bit indicator, which when set to '1' indicates that the Program
Association Table sent is currently applicable. When the bit is set to '0', it indicates that the table
sent is not yet applicable and shall be the next table to become valid.
section_number -- This 8 bit field gives the number of this section. The section_number of the first
section in the Program Association Table shall be 0x00. It shall be incremented by 1 with each
additional section in the Program Association Table.
last_section_number -- This 8 bit field specifies the number of the last section (that is, the section
with the highest section_number) of the complete Program Association Table.
program_number -- Program_number is a 16 bit field. It specifies the program to which the
program_map_PID is applicable. If this is set to 0x0000 then the following PID reference shall be
the network PID. For all other cases the value of this field is user defined. This field shall not take
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 105 (140)
any single value more than once within one version of the program association table.
program_number may be used as a designation for a broadcast channel, for example.
The
network_PID -- network_PID is a 13 bit field specifying the PID of the Transport Stream packets
which shall contain the Network Information Table.
program_map_PID -- program_map_PID is a 13 bit field specifying the PID of the Transport
Stream packets which shall contain the program_map_section applicable for the program as
specified by the program_number. No program_number shall have more than one
program_map_PID assignment.
CRC_32 -- This is a 32 bit field that contains the CRC value that gives a zero output of the registers
in the decoder after processing the entire program association section.
A.2
PMT Syntax
Syntax
TS_program_map_section() {
table_id
section_syntax_indicator
'0'
reserved
section_length
program_number
reserved
version_number
current_next_indicator
section_number
last_section_number
reserved
PCR_PID
reserved
program_info_length
for (i=0; i<N; i++) {
descriptor()
}
for (i=0;i<N1;i++) {
stream_type
reserved
elementary_PID
reserved
ES_info_length
for (i=0; i<N2; i++) {
descriptor()
}
}
CRC_32
}
No. of bits
Mnemonic
8
1
1
2
12
16
2
5
1
8
8
3
13
4
12
uimsbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
bslbf
uimsbf
bslbf
uimsbf
uimsbf
bslbf
uimsbf
bslbf
uimsbf
8
3
13
4
12
uimsbf
bslbf
uimsnf
bslbf
uimsbf
32
rpchof
Table 32 Program Map Section Syntax
A.2.1 Semantic definition of fields in program map section
table_id -- This is an 8 bit field, which in the case of a TS_program_map_section shall be always
set to 0x02.
section_syntax_indicator -- The section_syntax_indicator is a 1 bit field which shall be set to '1'.
section_length -- This is a 12 bit field, the first two bits of which shall be '00'. It specifies the
number of bytes of the section starting immediately following the section_length field, and including
the CRC. The value in this field shall not exceed 1021.
program_number -- program_number is a 16 bit field. It specifies the program to which the
program_map_PID is applicable. One program definition shall be carried within only one
TS_program_map_section. This implies that a program definition is never longer than 1016 bytes.
 2005 CELTIC participants in project Wing TV
page 106 (140)
CELTIC Wing TV project report
version_number -- This 5 bit field is the version number of the TS_program_map_section. The
version number shall be incremented by 1 modulo 32 when a change in the information carried
within the section occurs. Version number refers to the definition of a single program, and therefore
to a single section. When the current_next_indicator is set to '1', then the version_number shall be
that of the currently applicable TS_program_map_section. When the current_next_indicator is set
to '0', then the version_number shall be that of the next applicable TS_program_map_section.
current_next_indicator -- A 1 bit field, which when set to '1' indicates that the
TS_program_map_section sent is currently applicable. When the bit is set to '0', it indicates that the
TS_program_map_section sent is not yet applicable and shall be the next
TS_program_map_section to become valid.
section_number -- The value of this 8 bit field shall be always 0x00.
last_section_number -- The value of this 8 bit field shall be always 0x00.
PCR_PID -- This is a 13 bit field indicating the PID of the Transport Stream packets which shall
contain the PCR fields valid for the program specified by program_number. If no PCR is
associated with a program definition for private streams then this field shall take the value of
0x1FFF. The PCR Field may be set to 0x1FFF indicating that no PCR is associated with the
program.
program_info_length -- This is a 12 bit field, the first two bits of which shall be '00'. It specifies the
number of bytes of the descriptors immediately following the program_info_length field.
stream_type -- This is an 8 bit field specifying the type of program element carried within the
packets with the PID whose value is specified by the elementary_PID. The values of stream_type
important for DVB-H are specified in the following table:
Value
0x05
0x90
Description
IP/MAC Notification Service
IPDC over DVB-H Networks
Table 33 Stream Type assignment in DVB-H
elementary_PID -- This is a 13 bit field specifying the PID of the Transport Stream packets which
carry the associated program element.
ES_info_length -- This is a 12 bit field, the first two bits of which shall be '00'. It specifies the
number of bytes of the descriptors of the associated program element immediately following the
ES_info_length field.
CRC_32 -- This is a 32 bit field that contains the CRC value that gives a zero output of the registers
in the decoder after processing the entire program association section.
A.3
CAT Syntax
Syntax
CA_section() {
table_id
section_syntax_indicator
'0'
reserved
section_length
reserved
version_number
current_next_indicator
section_number
last_section_number
for (i=0; i<N;i++) {
descriptor()
}
CRC_32
}
No. of bits
Mnemonic
8
1
1
2
12
18
5
1
8
8
uimsbf
bslbf
bslbf
bslbf
uimsbf
bslbf
uimsbf
bslbf
uimsbf
uimsbf
32
rpchof
Table 34 Conditional Access Section Syntax
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 107 (140)
A.3.1 Semantic definition of fields in conditional access section
table_id -- This is an 8 bit field, which shall be always set to 0x01.
section_syntax_indicator -- The section_syntax_indicator is a 1 bit field which shall be set to '1'.
section_length -- This is a 12 bit field, the first two bits of which shall be '00'. It specifies the
number of bytes of the section starting immediately following the section_length field, and including
the CRC. The value in this field shall not exceed 1021.
version_number -- This 5 bit field is the version number of the whole conditional access table. The
version number shall be incremented by 1 modulo 32 when a change in the information carried
within the CA table occurs. When the current_next_indicator is set to '1', then the version_number
shall be that of the currently applicable Conditional Access Table. When the current_next_indicator
is set to '0', then the version_number shall be that of the next applicable Conditional Access Table.
current_next_indicator -- A 1 bit indicator, which when set to '1' indicates that the Conditional
Access Table sent is currently applicable. When the bit is set to '0', it indicates that the Conditional
Access Table sent is not yet applicable and shall be the next Conditional Access Table to become
valid.
section_number -- This 8 bit field gives the number of this section. The section_number of the first
section in the Conditional Access Table shall be 0x00. It shall be incremented by 1 modulo 256
with each additional section in the Conditional Access Table.
last_section_number -- This 8 bit field specifies the number of the last section (that is, the section
with the highest section_number) of the Conditional Access Table.
CRC_32 -- This is a 32 bit field that contains the CRC value that gives a zero output of the registers
in the decoder after processing the entire program association section.
A.4
TSDT Syntax
Syntax
TSDT_section() {
table_id
section_syntax_indicator
'0'
reserved
section_length
transport_stream_id
reserved
version_number
current_next_indicator
section_number
last_section_number
for (i=0; i<N;i++) {
descriptor()
}
CRC_32
}
No. of bits
Mnemonic
8
1
1
2
12
16
2
5
1
8
8
uimsbf
bslbf
bslbf
bslbf
uimsbf
bslbf
uimsbf
bslbf
uimsbf
uimsbf
32
rpchof
Table 35 Transport Stream Description Section Syntax
A.4.1 Semantic definition of fields in conditional access section
table_id -- This is an 8 bit field, which shall be always set to 0x03.
section_syntax_indicator -- The section_syntax_indicator is a 1 bit field which shall be set to '1'.
section_length -- This is a 12 bit field, the first two bits of which shall be '00'. It specifies the
number of bytes of the section starting immediately following the section_length field, and including
the CRC. The value in this field shall not exceed 1021.
 2005 CELTIC participants in project Wing TV
page 108 (140)
CELTIC Wing TV project report
transport_stream_id -- This is a 16 bit field which serves as a label to identify this Transport
Stream from any other multiplex within a network. Its value is defined by the user.
version_number -- This 5 bit field is the version number of the whole conditional access table. The
version number shall be incremented by 1 modulo 32 when a change in the information carried
within the CA table occurs. When the current_next_indicator is set to '1', then the version_number
shall be that of the currently applicable Conditional Access Table. When the current_next_indicator
is set to '0', then the version_number shall be that of the next applicable Conditional Access Table.
current_next_indicator -- A 1 bit indicator, which when set to '1' indicates that the Conditional
Access Table sent is currently applicable. When the bit is set to '0', it indicates that the Conditional
Access Table sent is not yet applicable and shall be the next Conditional Access Table to become
valid.
section_number -- This 8 bit field gives the number of this section. The section_number of the first
section in the Conditional Access Table shall be 0x00. It shall be incremented by 1 modulo 256
with each additional section in the Conditional Access Table.
last_section_number -- This 8 bit field specifies the number of the last section (that is, the section
with the highest section_number) of the Conditional Access Table.
CRC_32 -- This is a 32 bit field that contains the CRC value that gives a zero output of the registers
in the decoder after processing the entire program association section.
A.5
NIT Syntax
Syntax
network_information_section(){
table_id
section_syntax_indicator
reserved_future_use
reserved
section_length
network_id
reserved
version_number
current_next_indicator
section_number
last_section_number
reserved_future_use
network_descriptors_length
for(i=0;i<N;i++){
descriptor()
}
reserved_future_use
transport_stream_loop_length
for(i=0;i<N;i++){
transport_stream_id
original_network_id
reserved_future_use
transport_descriptors_length
for(j=0;j<N;j++){
descriptor()
}
}
CRC_32
}
No. of bits
Identifier
8
1
1
2
12
16
2
5
1
8
8
4
12
uimsbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
bslbf
uimsbf
bslbf
uimsbf
uimsbf
bslbf
uimsbf
4
12
bslbf
uimsbf
16
16
4
12
uimsbf
uimsbf
bslbf
uimsbf
32
rpchof
Table 36 Network Information Section Syntax
A.5.1 Semantic definition of fields in network information section
table_id: Table id takes the value 0x40 if the present Network Information section refers to the
actual network or 0x41 if the present Network Information section refers to other network.
section_syntax_indicator: The section_syntax_indicator is a 1-bit field which shall be set to "1".
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 109 (140)
section_length: This is a 12-bit field, the first two bits of which shall be "00". It specifies the
number of bytes of the section, starting immediately following the section_length field and including
the CRC. The section_length shall not exceed 1 021 so that the entire section has a maximum
length of 1 024 bytes.
network_id: This is a 16-bit field which serves as a label to identify the delivery system, about
which the NIT informs, from any other delivery system.
version_number: This 5-bit field is the version number of the sub_table. The version_number shall
be incremented by 1 when a change in the information carried within the sub_table occurs. When it
reaches value 31, it wraps around to 0. When the current_next_indicator is set to "1", then the
version_number shall be that of the currently applicable sub_table defined by the table_id and
network_id. When the current_next_indicator is set to "0", then the version_number shall be that of
the next applicable sub_table defined by the table_id and network_id.
current_next_indicator: This 1-bit indicator, when set to "1" indicates that the sub_table is the
currently applicable sub_table. When the bit is set to "0", it indicates that the sub_table sent is not
yet applicable and shall be the next sub_table to be valid.
section_number: This 8-bit field gives the number of the section. The section_number of the first
section in the sub_table shall be "0x00". The section_number shall be incremented by 1 with each
additional section with the same table_id and network_id.
last_section_number: This 8-bit field specifies the number of the last section (that is, the section
with the highest section_number) of the sub_table of which this section is part.
network_descriptors_length: This 12-bit field gives the total length in bytes of the following
network descriptors.
transport_stream_loop_length: This is a 12-bit field specifying the total length in bytes of the TS
loops that follow, ending immediately before the first CRC-32 byte.
transport_stream_id: This is a 16-bit field which serves as a label for identification of this TS from
any other multiplex within the delivery system.
original_network_id: This 16-bit field gives the label identifying the network_id of the originating
delivery system.
transport_descriptors_length: This is a 12-bit field specifying the total length in bytes of TS
descriptors that follow.
CRC_32 -- This is a 32 bit field that contains the CRC value that gives a zero output of the registers
in the decoder after processing the entire program association section.
 2005 CELTIC participants in project Wing TV
page 110 (140)
A.6
CELTIC Wing TV project report
BAT Syntax
Syntax
bouquet_association_section(){
table_id
section_syntax_indicator
reserved_future_use
reserved
section_length
bouquet_id
reserved
version_number
current_next_indicator
section_number
last_section_number
reserved_future_use
bouquet_descriptors_length
for(i=0;i<N;i++){
descriptor()
}
reserved_future_use
transport_stream_loop_length
for(i=0;i<N;i++){
transport_stream_id
original_network_id
reserved_future_use
transport_descriptors_length
for(j=0;j<N;j++){
descriptor()
}
}
CRC_32
}
No. of bits
Identifier
8
1
1
2
12
16
2
5
1
8
8
4
12
uimsbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
bslbf
uimsbf
bslbf
uimsbf
uimsbf
bslbf
uimsbf
4
12
bslbf
uimsbf
16
16
4
12
uimsbf
uimsbf
bslbf
uimsbf
32
rpchof
Table 37 Bouquet Association Section syntax
A.6.1 Semantic definition of fields in bouquet association section
table_id: 0x4A.
section_syntax_indicator: The section_syntax_indicator is a 1-bit field which shall be set to "1".
section_length: This is a 12-bit field, the first two bits of which shall be "00". It specifies the
number of bytes of the section, starting immediately following the section_length field and including
the CRC. The section_length shall not exceed 1 021 so that the entire section has a maximum
length of 1 024 bytes.
bouquet_id: This is a 16-bit field which serves as a label to identify the bouquet. Allocations of the
value of this field are found in [26].
version_number: This 5-bit field is the version number of the sub_table. The version_number shall
be incremented by 1 when a change in the information carried within the sub_table occurs. When it
reaches value 31, it wraps around to 0. When the current_next_indicator is set to "1", then the
version_number shall be that of the currently applicable sub_table defined by the table_id and
bouquet_id. When the current_next_indicator is set to "0", then the version_number shall be that of
the next applicable sub_table defined by the table_id and bouquet_id.
current_next_indicator: This 1-bit indicator, when set to "1" indicates that the sub_table is the
currently applicable sub_table. When the bit is set to "0", it indicates that the sub_table sent is not
yet applicable and shall be the next sub_table to be valid.
section_number: This 8-bit field gives the number of the section. The section_number of the first
section in the sub_table shall be "0x00". The section_number shall be incremented by 1 with each
additional section with the same table_id and bouquet_id.
last_section_number: This 8-bit field specifies the number of the last section (that is, the section
with the highest section_number) of the sub_table of which this section is part.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 111 (140)
bouquet_descriptors_length: This 12-bit field gives the total length in bytes of the following
descriptors.
transport_stream_loop_length: This is a 12-bit field specifying the total length in bytes of the TS
loop that follows.
transport_stream_id: This is a 16-bit field which serves as a label for identification of this TS from
any other multiplex within the delivery system.
original_network_id: This 16-bit field gives the label identifying the network_id of the originating
delivery system.
transport_descriptors_length: This is a 12-bit field specifying the total length in bytes of TS
descriptors that follow.
CRC_32 -- This is a 32 bit field that contains the CRC value that gives a zero output of the registers
in the decoder after processing the entire program association section.
A.7
SDT Syntax
Syntax
service_description_section(){
table_id
section_syntax_indicator
reserved_future_use
reserved
section_length
transport_stream_id
reserved
version_number
current_next_indicator
section_number
last_section_number
original_network_id
reserved_future_use
for (i=0;i<N;i++){
service_id
reserved_future_use
EIT_schedule_flag
EIT_present_following_flag
running_status
free_CA_mode
descriptors_loop_length
for (j=0;j<N;j++){
descriptor()
}
}
CRC_32
}
No. of
bits
Identifier
8
1
1
2
12
16
2
5
1
8
8
16
8
uimsbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
bslbf
uimsbf
bslbf
uimsbf
uimsbf
uimsbf
bslbf
16
6
1
1
3
1
12
uimsbf
bslbf
bslbf
bslbf
uimsbf
bslbf
uimsbf
32
rpchof
Table 38 Service Description Section syntax
A.7.1 Semantic definition of fields in service description section
table_id: Table id takes the value 0x42 if the present Service Description section refers to the
actual TS or 0x46 if the present Service Description section refers to other TS.
section_syntax_indicator: The section_syntax_indicator is a 1-bit field which shall be set to "1".
section_length: This is a 12-bit field, the first two bits of which shall be "00". It specifies the
number of bytes of the section, starting immediately following the section_length field and including
the CRC. The section_length shall not exceed 1021 so that the entire section has a maximum
length of 1 024 bytes.
transport_stream_id: This is a 16-bit field which serves as a label for identification of the TS,
about which the SDT informs, from any other multiplex within the delivery system.
 2005 CELTIC participants in project Wing TV
page 112 (140)
CELTIC Wing TV project report
version_number: This 5-bit field is the version number of the sub_table. The version_number shall
be incremented by 1 when a change in the information carried within the sub_table occurs. When it
reaches value "31", it wraps around to "0". When the current_next_indicator is set to "1", then the
version_number shall be that of the currently applicable sub_table. When the
current_next_indicator is set to "0", then the version_number shall be that of the next applicable
sub_table.
current_next_indicator: This 1-bit indicator, when set to "1" indicates that the sub_table is the
currently applicable sub_table. When the bit is set to "0", it indicates that the sub_table sent is not
yet applicable and shall be the next sub_table to be valid.
section_number: This 8-bit field gives the number of the section. The section_number of the first
section in the sub_table shall be "0x00". The section_number shall be incremented by 1 with each
additional section with the same table_id, transport_stream_id, and original_network_id.
last_section_number: This 8-bit field specifies the number of the last section (that is, the section
with the highest section_number) of the sub_table of which this section is part.
original_network_id: This 16-bit field gives the label identifying the network_id of the originating
delivery system.
service_id: This is a 16-bit field which serves as a label to identify this service from any other
service within the TS. The service_id is the same as the program_number in the corresponding
program_map_section.
EIT_schedule_flag: This is a 1-bit field which when set to "1" indicates that EIT schedule
information for the service is present in the current TS. If the flag is set to 0 then the EIT schedule
information for the service should not be present in the TS.
EIT_present_following_flag: This is a 1-bit field which when set to "1" indicates that
EIT_present_following information for the service is present in the current TS. If the flag is set to 0
then the EIT present/following information for the service should not be present in the TS.
running_status: This is a 3-bit field indicating the status of the service as defined in the following
table:
Value
0
1
2
3
4
5 to 7
Meaning
undefined
not running
starts in a few seconds (e.g. for video recording)
pausing
running
reserved for future use
Table 39 Running Status coding
For an NVOD reference service the value of the running_status shall be set to "0".
free_CA_mode: This 1-bit field, when set to "0" indicates that all the component streams of the
service are not scrambled. When set to "1" it indicates that access to one or more streams may be
controlled by a CA system.
descriptors_loop_length: This 12-bit field gives the total length in bytes of the following
descriptors.
CRC_32 -- This is a 32 bit field that contains the CRC value that gives a zero output of the registers
in the decoder after processing the entire program association section.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
A.8
page 113 (140)
TDT Syntax
Syntax
time_date_section(){
table_id
section_syntax_indicator
reserved_future_use
reserved
section_length
UTC_time
}
No. of bits
8
1
1
2
12
40
Identifier
uimsbf
bslbf
bslbf
bslbf
uimsbf
bslbf
Table 40 Time Date Section syntax
A.8.1 Semantic definition of fields in time date section
table_id: 0x70.
section_syntax_indicator: This is a one-bit indicator which shall be set to "0".
section_length: This is a 12-bit field, the first two bits of which shall be "00". It specifies the
number of bytes of the section, starting immediately following the section_length field and up to the
end of the section.
UTC_time: This 40-bit field contains the current time and date in UTC and MJD. This field is coded
as 16 bits giving the 16 LSBs of MJD followed by 24 bits coded as 6 digits in 4-bit BCD.
EXAMPLE:
A.9
93/10/13 12:45:00 is coded as "0xC079124500".
TOT Syntax
Syntax
time_offset_section(){
table_id
section_syntax_indicator
reserved_future_use
reserved
section_length
UTC_time
reserved
descriptors_loop_length
for(i=0;i<N;i++){
descriptor()
}
CRC_32
}
No. of bits
Identifier
8
1
1
2
12
40
4
12
uimsbf
bslbf
bslbf
bslbf
uimsbf
bslbf
bslbf
uimsbf
32
rpchof
Table 41 Time Offset Section syntax
A.9.1 Semantic definition of fields in time offset section
table_id: 0x73.
section_syntax_indicator: This is a one-bit indicator which shall be set to "0".
section_length: This is a 12-bit field, the first two bits of which shall be "00". It specifies the
number of bytes of the section, starting immediately following the section_length field and up to the
end of the section.
UTC_time: This 40-bit field contains the current time and date in UTC and MJD. This field is coded
as 16 bits giving the 16 LSBs of MJD followed by 24 bits coded as 6 digits in 4-bit BCD.
EXAMPLE:
93/10/13 12:45:00 is coded as "0xC079124500".
descriptors_loop_length: This 12-bit field gives the total length in bytes of the following
descriptors.
 2005 CELTIC participants in project Wing TV
page 114 (140)
CELTIC Wing TV project report
CRC_32 -- This is a 32 bit field that contains the CRC value that gives a zero output of the registers
in the decoder after processing the entire program association section.
A.10 INT Syntax
Syntax
IPMAC_notification_section(){
table_id
section_syntax_indicator
reserved_future_use
reserved
section_length
action_type
platform_id_hash
reserved
version_number
current_next_indicator
section_number
last_section_number
platform_id
processing_order
platform_descriptor_loop()
for (i=0;i<N;i++){
target_descriptor_loop()
operational_descriptor_loop()
}
CRC_32
}
No. of bits
Identifier
8
1
1
2
12
8
8
2
5
1
8
8
24
8
uimsbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
uimsbf
bslbf
uimsbf
bslbf
uimsbf
uimsbf
uimsbf
bslbf
32
rpchof
Table 42 IP/MAC Notification Section syntax
A.10.1 Semantic definition of fields in IP/MAC notification section
table_id: 0x4C.
section_syntax_indicator: The section_syntax_indicator is a 1-bit field which shall be set to '1'.
section_length: This is a 12-bit field. It specifies the number of bytes of the section, starting
immediately following the section_length fields and including the CRC. The section_length shall not
exceed 4 093 so that the entire section has a maximum length of 4 096.
action_type: Identifies the action to be performed. Coded according to the following table:
Action_type
0x00
0x01
0x02 to 0xFF
Specification
Reserved
Location of IP/MAC Streams in DVB Networks
Reserved for Future Use
Table 43 Action Type Coding
platform_id_hash: The platform_id_hash is formed by XORing all three bytes of the platform_id
together to form a single byte value (platform_id_hash = platform_id[23..16] ^ platform_id [15..8] ^
platform_id [7..0]).
version_number: This 5-bit field is the version number of the sub-table. The version_number shall
be incremented by 1 when a change in the information carried within the sub_table occurs. When it
reaches value 31, it wraps around to 0. When the current_next_indicator is set to '1', then the
version_number shall be that of the currently applicable sub_table defined by the table_id,
platform_id and action_type. When the current_next_indicator is set to '0', then the version_number
shall be that of the next applicable sub_table defined by the table_id, platform_id and action_type.
current_next_indicator: This 1-bit indicator, when set to '1' indicates that the sub_table is the
currently applicable sub_table. When the bit is set to '0', it indicates that the sub_table sent is not
yet applicable and shall be the next sub_table to be valid.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 115 (140)
section_number: This 8-bit field gives the number of the section. The section_number of the first
section in the sub_table shall be "0x00". The section_number shall be incremented by 1 with each
additional section with the same table_id, platform_id and action_type.
last_section_number: This 8-bit field indicates the number of the last section (that is, the section
with the highest section_number) of the sub_table of which this section is part.
platform_id: This is a 24 bit field which serves as a label to identify a given IP/MAC platform.
Allocation of the value of this field are found in the TR 101 162 [26].
processing_order: Indicates the sequence in which to perform actions. If the INT requires more
than one action this field can be used to indicate the order to perform these actions. Coded
according to table below. In the same sense, if more than one INT sub-table is available for the
same platform_id, this field can be used to set up a priority in the resolution of the IP/MAC
addresses.
processing_order
0x00
0x01 to 0xFE
0xFF
Specification
First action
Subsequent actions (ascending)
No ordering implied
Table 44 Processing Order Coding
CRC_32 -- This is a 32 bit field that contains the CRC value that gives a zero output of the registers
in the decoder after processing the entire program association section.
Syntax
platform_descriptor_loop(){
reserved
platform_ descriptor_loop_length
for (i=0; i<N1; i++)
platform_descriptor()
}
No. of bits
4
12
Identifier
bslbf
uimsbf
Table 45 Platform Descriptor Loop
Syntax
target_descriptor_loop(){
reserved
target_ descriptor_loop_length
for (i=0; i<N1; i++)
target_descriptor()
}
No. of bits
4
12
Identifier
bslbf
uimsbf
Table 46 Target Descriptor Loop
Syntax
operational_descriptor_loop(){
reserved
operational_ descriptor_loop_length
for (i=0; i<N1; i++)
operational_descriptor()
}
Table 47 Operational Descriptor Loop
 2005 CELTIC participants in project Wing TV
No. of bits
4
12
Identifier
bslbf
uimsbf
page 116 (140)
CELTIC Wing TV project report
Annex B - Descriptors required in DVB-H
B.1
Descriptors required in PMT for IPDC over DVB-H Networks
B.1.1 Stream Identifier Descriptor
The stream identifier descriptor must be used in the PSI PMT to label component streams of a
DVB-H service. The stream identifier descriptor shall be located following the relevant
ES_info_length field.
Syntax
No. of bits
stream_identifier_descriptor(){
descriptor_tag
descriptor_length
component_tag
}
8
8
8
Identifier
uimsbf
uimsbf
uimsbf
Table 48 Stream Identifier Descriptor
Semantics for the stream identifier descriptor:
descriptor_tag: 0x52.
component_tag: This 8-bit field identifies the component stream for associating it with a
description given in a component descriptor. Within a program map section each stream identifier
descriptor shall have a different value for this field.
B.1.2 Data Broadcast ID Descriptor
The stream identifier descriptor must be used in the PSI PMT to label component streams of
IP/MAC Notification Service.
Syntax
data_broadcast_id_descriptor(){
descriptor_tag
descriptor_length
data_broadcast_id
for(i=0; i < N;i++ ){
id_selector_byte
}
}
No. of bits
Identifier
8
8
16
uimsbf
uimsbf
uimsbf
8
uimsbf
Table 49 Data Broadcast ID Descriptor
Semantics of the data broadcast id descriptor:
descriptor_tag: 0x66.
data_broadcast_id: This 16-bit field identifies the data broadcast specification that is used to
broadcast the data in the broadcast network. IP/MAC Notification Services must be signalled with
data_broadcast_id 0x000B.
id_selector_byte: For the purpose of application selection the id_selector_byte(s) might be used.
The definition of the id_selector_byte(s) of the data_broadcast_id_descriptor will depend on the
data broadcast id. Note that the id_selector_bytes may differ from the selector_bytes of the
corresponding data_broadcast_descriptor.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 117 (140)
Data Broadcast Id descriptor selector byte definition for IP/MAC Notification Table:
Syntax
IP/MAC_notification_info(){
platform_id_data_length
for(i=0; i < N;i++ ){
platform_id
action_type
reserved
INT_versioning_flag
INT_version
}
for(i=0; i < N;i++ ){
private_data_byte
}
}
No. of bits
Identifier
8
uimsbf
24
8
2
1
5
uimsbf
uimsbf
bslbf
bslbf
uimsbf
8
Table 50 IP/MAC Notification Info (id_selector_bytes from Data Broadcast ID Descriptor)
Semantics of the data broadcast id descriptor:
platform_id_data_length: This field specifies the total length in bytes of the following platform_idloop.
platform_id: This is a 24-bit field which serves as a label to uniquely identify this IP/MAC platform.
Allocations are specified in TR 101 162 [26].
action_type: This is an eight-bit field that shall be equal to the action_type field defined in the INT
as indicated in the following table:
Action_type
0x00
0x01
0x02 to 0xFF
Specification
Reserved
Location of IP/MAC Streams in DVB Networks
Reserved for Future Use
Table 51 Action Type Coding
INT_versioning_flag: if it is set to 0 no relevant versioning information is carried in the version
field. If it is set to 1 the INT_version field shall reflect changes in the INT.
INT_version: If the INT_version_flag is set to 1, the version shall be incremented on each change
of the INT and shall be the same as the version_number in the INT section header.
private_data_byte: This is an 8-bit field, the value of which is privately defined.
B.2
Descriptors required in TSDT for IPDC over DVB-H Networks
B.2.1 Transport Stream Descriptor
The transport stream descriptor, being transmitted in the TSDT only, may be used to indicate the
compliance of a transport stream with an MPEG based system, e.g. DVB.
Syntax
transport_stream_descriptor(){
descriptor_tag
descriptor_length
for (i=0;i<N;i++){
byte
}
}
Table 52 Transport Stream Descriptor
 2005 CELTIC participants in project Wing TV
No. of bits
Identifier
8
8
uimsbf
uimsbf
8
uimsbf
page 118 (140)
CELTIC Wing TV project report
Semantics for the transport stream descriptor:
descriptor_tag: 0x67.
byte: This is an 8-bit field. For identification of DVB Transport Streams the descriptor_length field
shall be set to the value 0x03 indicating three following bytes. The three bytes shall contain the
values 0x44 , 0x56, 0x42 (ASCII: ”DVB”).
B.3
Descriptors required in NIT for IPDC over DVB-H Networks
B.3.1 Network Name Descriptor
The network name descriptor provides the network name in text form. The descriptor shall appear
exactly once in the first descriptor loop. The descriptor should contain the name of the DVB
network not an empty string.
Syntax
network_name_descriptor(){
descriptor_tag
descriptor_length
for (i=0;i<N;i++){
Char
}
}
No. of bits
Identifier
8
8
uimsbf
uimsbf
8
uimsbf
Table 53 Network Name Descriptor
Semantics for the network name descriptor:
descriptor_tag: 0x40.
char: This is an 8-bit field. A string of char fields specify the name of the delivery system about
which the NIT informs.
B.3.2 Cell List Descriptor
This descriptor is used to list the cells of a terrestrial DVB network. The descriptor shall be present
in the first descriptor loop. The cell and subcell list shall be complete. The descriptor may appear
more than once within the descriptor loop.
Syntax
cell_list_descriptor(){
descriptor_tag
descriptor_length
for (i=0;i<N;i++){
cell_id
cell_latitude
cell_longitude
cell_extend_of_latitude
cell_extend_of_longitude
subcell_info_loop_length
for (i=0;i<N;i++){
cell_id_extension
subcell_latitude
subcell_longitude
subcell_extend_of_latitude
subcell_extend_of_longitude
}
}
}
No. of bits
Identifier
8
8
uimsbf
uimsbf
16
16
16
12
12
8
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
8
16
16
12
12
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
Table 54 Cell List Descriptor
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 119 (140)
Semantics of the cell list descriptor:
descriptor_tag: 0x6C.
cell_id: This is a 16-bit field which uniquely identifies a cell.
cell_latitude: This 16-bit field, coded as a two’s complement number, shall specify the latitude of
the corner of a spherical rectangle that approximately describes the coverage area of the cell
0 15
indicated. It shall be calculated by multiplying the value of the latitude field by (90 /2 ). Southern
latitudes shall be considered negative and northern latitudes positive.
cell_longitude: This 16-bit field, coded as a two’s complement number, shall specify the longitude
of the corner of a spherical rectangle that approximately describes the coverage area of the cell
0 15
indicated. It shall be calculated by multiplying the value of the longitude field by (180 /2 ). Western
longitudes shall be considered negative and eastern longitudes positive.
cell_extend_of_latitude: This 12-bit field, coded as an unsigned binary number, shall specify the
extend of latitude of a spherical rectangle that approximately describes the coverage area of the
cell indicated. It shall be calculated by multiplying the value of the extend_of_latitude field by
0 15
(90 /2 ).
cell_extend_of_longitude: This 12-bit field, coded as an unsigned binary number, shall specify
the extend of longitude of a spherical rectangle that approximately describes the coverage area of
the cell indicated. It shall be calculated by multiplying the value of the extend_of_longitude field by
0 15
(180 /2 ).
subcell_info_loop_length: This 8-bit field gives the total length in bytes of the following loop that
describes the subcells.
cell_id_extension: This 8-bit field is used to identify a subcell within a cell.
subcell_latitude: This 16-bit field, coded as a two’s complement number, shall specify the latitude
of the corner of a spherical rectangle that approximately describes the coverage area of the subcell
0 15
indcated. It shall be calculated by multiplying the value of the latitude field by (90 /2 ). Southern
latitudes shall be considered negative and northern latitudes positive.
subcell_longitude: This 16-bit field, coded as a two’s complement number, shall specify the
longitude of the corner of a spherical rectangle that approximately describes the coverage area of
the subcell indicated. It shall be calculated by multiplying the value of the longitude field by
0 15
(180 /2 ). Western longitudes shall be considered negative and eastern longitudes positive.
subcell_extend_of_latitude: This 12-bit field, coded as an unsigned binary number, shall specify
the extend of latitude of a spherical rectangle that approximately describes the coverage area of
the subcell indicated. It shall be calculated by multiplying the value of the extend_of_latitude field
0 15
by (90 /2 ).
subcell_extend_of_longitude: This 12-bit field, coded as an unsigned binary number, shall
specify the extend of longitude of a spherical rectangle that approximately describes the coverage
area of the subcell indicated. It shall be calculated by multiplying the value of the
0 15
extend_of_longitude field by (180 /2 ).
B.3.3 Cell Frequency Link Descriptor
The cell frequency link descriptor must be used in the Network Information Table (NIT) to describe
a DVB-H network. It gives a complete list of cells and identifies the frequencies that are in use in
these cells for the multiplex described. This descriptor shall appear for the Transport Stream in the
transport_stream_loop to list all the frequencies where the TS is available within the DVB network.
The list of announced frequencies shall be complete.
 2005 CELTIC participants in project Wing TV
page 120 (140)
CELTIC Wing TV project report
Syntax
No. of bits
Identifier
cell_frequency_link_descriptor(){
}
descriptor_tag
descriptor_length
for (i=0;i<N;i++){
cell_id
frequency
subcell_info_loop_length
for (i=0;i<N;i++){
cell_id_extension
transposer_frequency
}
}
8
8
uimsbf
uimsbf
16
32
8
uimsbf
uimsbf
uimsbf
8
32
uimsbf
uimsbf
Table 55 Cell Frequency Link Descriptor
Semantics for the cell frequency link descriptor:
descriptor_tag: 0x6D.
cell_id:. This is a 16-bit field which uniquely identifies a cell.
frequency: This 32-bit field identifies the main frequency that is used in the cell indicated. The
coding
is
according
to
the
coding
of
the
centre_frequency
in
the
terrestrial_delivery_system_descriptor.
subcell_info_loop_length: This 8-bit field gives the total length in bytes of the following loop that
indicates the frequencies used in subcells.
cell_id_extension: This 8-bit field is used to identify a subcell within a cell.
transposer_frequency: This 32-bit field identifies the frequency that is used by a transposer in the
subcell indicated. The coding of the frequency is according to the coding of the centre_frequency in
the terrestrial_delivery_system_descriptor.
B.3.4 Linkage Descriptor
The NIT actual shall contain a linkage descriptor with a linkage type 0x0B or 0x0C.
•
Linkage_type 0x0B is used to announce the DVB services containing INT sub_table(s) (i.e.
IP/MAC Notification Services). If a linkage_descriptor with linkage_type 0x0B is available in the
NIT_actual, the following applies:
o
o
The list of announced IP/MAC Notification Services is complete, meaning that all
IP/MAC Notification Services within the actual DVB network are announced. For each
IP/MAC Notification Service, all IP platforms for which an INT sub_table is available
within the DVB service are announced.
o
The descriptor may appear more than once in the loop.
o
The descriptor(s) shall announce each DVB service carrying INT sub tables within tha
actual DVB network.
o
Each descriptor(s) shall carry exactly one IP/MAC Notification Service Structure
annopuncing one or more IP/MAC Notification Services.
o
•
The descriptor is located in the first descriptor loop.
The list of IP/MAC Notification Services announced shall be complete. The list is
complete if all INT sub table within the DVB network are referred to by at least one
linkage descriptor with a linkage type 0x0B.
Linkage_type 0x0C is used to announce an INT Notification NIT/BAT, i.e. NIT or BAT
sub_table containing a linkage_descriptor with linkage_type 0x0B. This descriptor applies to
each TS not carrying any IP flows. If a linkage_descriptor with linkage_type 0x0C is available in
the NIT_actual, the following applies:
o
The descriptor is located in the first descriptor loop.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
•
o
The list of announced INT Notification NIT/BAT sub_tables is complete, meaning that
all INT Notification NIT/BAT sub_tables within the DVB network are announced.
o
The descriptor may appear more than once in the loop.
Linkage_type 0x04 is used to announce Transport Streams within the DVB network that
contain full network SI and bouquet SI. If a linkage_descriptor with linkage_type 0x04 is
available in NIT_actual, the following applies:
o
•
The NIT and BAT tables within Transport Stream referred contain complete description
of the actual DVB network.
Linkage descriptor_type 0x09 is used to announce System Software Update service and
conveys the location of the transport stream carrying a system software update service within a
network or bouquet respectively. If the descriptor is used the following applies :
o
•
page 121 (140)
The descriptor shall be carried in the first loop of the NIT or in the first loop of a
specifically identified BAT (called system softwareupdate BAT).
Linkage descriptor_type 0x0A is used to define a pointer to a transport stream carrying a
system software update BAT or NIT with detailed signalling information about system software
update services.
 2005 CELTIC participants in project Wing TV
page 122 (140)
CELTIC Wing TV project report
Syntax
linkage_descriptor(){
descriptor_tag
descriptor_length
transport_stream_id
original_network_id
service_id
linkage_type
if (linkage_type ==0x08){
hand-over_type
reserved_future_use
origin_type
if (hand-over_type ==0x01
|| hand-over_type ==0x02
|| hand-over_type ==0x03){
network_id
}
if (origin_type ==0x00){
initial_service_id
}
for (i=0;i<N;i++){
private_data_byte
}
}
else if (linkage type == 0x0B){
platform_id_data_length
for (i=0;i<N;i++){
platform_id
platform_name_loop_length
for (i=0;i<N;i++){
ISO_639_language_code
platform_name_length
for (i=0;i< platform_name_length;i++){
text_char
}
}
}
for (i=0;i<N;i++){
private_data_byte
}
}
else if (linkage type == 0x0C){
table_type
if (table_type == 0x02){
bouquet_id
}
}
else {
for (i=0;i<N;i++){
private_data_byte
}
}
}
No. of
bits
Identifier
8
8
16
16
16
8
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
4
3
1
bslbf
bslbf
bslbf
16
uimsbf
16
uimsbf
8
bslbf
8
uimsbf
24
8
uimsbf
uimsbf
24
8
bslbf
uimsbf
8
uimsbf
8
bslbf
uimsbf
16
8
bslbf
Table 56 Linkage descriptor
Semantics for the linkage descriptor:
descriptor_tag: 0x4A.
transport_stream_id: This is a 16-bit field which identifies the TS containing the information
service indicated.
original_network_id: This 16-bit field gives the label identifying the network_id of the originating
delivery system of the information service indicated.
service_id: This is a 16-bit field which uniquely identifies an information service within a TS. The
service_id is the same as the program_number in the corresponding program_map_section. If the
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 123 (140)
linkage_type field has the value 0x04, then the service_id field is not relevant, and shall be set to
0x0000.
linkage_type: This is an 8-bit field specifying the type of linkage e.g. to information.
Linkage_type
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
0x09
0x0A
0x0B to 0x7F
0x80 to 0xFE
0xFF
Description
reserved for future use
information service
EPG service
CA replacement service
TS containing complete Network/Bouquet SI
service replacement service
data broadcast service
RCS Map
mobile hand-over
System Software Update Service
TS containing SSU BAT or NIT
reserved for future use
user defined
reserved for future use
Table 57 Linkage type coding
private_data_byte: This is an 8-bit field, the value of which is privately defined.
hand-over_type: This is a 4-bit field specifying the type of hand-over.
Hand-over_type
0x00
0x01
0x02
0x03
0x04 to 0x0F
Description
reserved for future use
DVB hand-over to an identical service in a neighbouring country
DVB hand-over to a local variation of the same service
DVB hand-over to an associated service
reserved for future use
Table 58 Hand-over type coding
origin_type: This is a flag specifying in which table the link is originated.
Origin_type
0x00
0x01
Description
NIT
SDT
Table 1:
Table 59 Origin type coding
network_id: This is a 16-bit field which identifies the terrestrial network that supports the service
indicated.
initial_service_id: This is a 16-bit field which identifies the service for which the hand-over linkage
is valid.
platform_id_data_length: This field specifies the total length in bytes of the following platform_idloop.
platform_id: This is a 24-bit field containing a platform_id of the organization providing IP/MAC
streams on DVB transport streams/services. Allocations of the value of platform_id are found in the
TR 101 162 [26].
platform_name_loop_length: This 8-bit field defines the length in bytes of the following platform
name loop.
ISO_639_language_code: This 24-bit field contains the ISO 639-2 [30] three character language
code of the language of the following platform name. Both ISO 639-2/B and ISO 639-2/T may be
used. Each character is coded into 8 bits according to ISO 8859-1 [31] and inserted in order into
the 24-bit field.
 2005 CELTIC participants in project Wing TV
page 124 (140)
CELTIC Wing TV project report
platform_name_length: This 8-bit field specifies the total length in bytes of the following
platform_name.
text_char: This is an 8-bit field.
private_data_byte: This is an 8-bit field, the value of which is privately defined.
table_type: This is an 8-bit field containing a flag pointing either to the IP/MAC Notification BAT or
NIT.
Value
0x00
0x01
0x02
0x03 to 0xFF
Description
Not defined
NIT
BAT
Reserved for future use
Table 60 Table type coding
bouquet_id: This is a 16-bit field which serves as a label to identify the bouquet described by the
IP/MAC Notification BAT.
B.3.5 Terrestrial Delivery System Descriptor
Each iteration of the second descriptor loop contains exactly one delivery_system_descriptor
(terrestrial_delivery_system_descriptor in case of IPDC DVB-H Network), announcing the physical
parameters for the concerned Transport Stream. If the announced Transport Stream is available in
multiple frequencies, the other_frequency_flag is set to 1. In which case, either
frequency_list_descriptor or cell_frequency_link_descriptor is also available.
Syntax
terrestrial_delivery_system_descriptor(){
descriptor_tag
descriptor_length
centre_frequency
bandwidth
reserved_future_use
constellation
hierarchy_information
code_rate-HP_stream
code_rate-LP_stream
guard_interval
transmission_mode
other_frequency_flag
reserved_future_use
}
No. of bits
Identifier
8
8
32
3
5
2
3
3
3
2
2
1
32
uimsbf
uimsbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
Table 61 Terrestrial Delivery system Descriptor
Semantics for terrestrial delivery system descriptor
descriptor_tag: 0x5A.
centre_frequency: The centre_frequency is a 32-bit uimsbf field giving the binary coded frequency
value in multiples of 10 Hz. The coding range is from minimum 10 Hz (0x00000001) up to a
maximum of 42 949 672 950 Hz (0xFFFFFFFF).
bandwidth: This is a 3-bit field specifying what is the bandwidth in use.
bandwidth
000
001
010
011 to 111
bandwidth value
8 MHz
7 MHz
6 MHz
reserved for future use
Table 62 Signalling format for the bandwidth
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 125 (140)
constellation: This is a 2-bit field. It specifies the constellation pattern used on a terrestrial delivery
system according to:
constellation
00
01
10
11
constellation characteristics
QPSK
16-QAM
64-QAM
reserved for future use
Table 63 Signalling format for the possible constellation patterns
hierarchy_information: The hierarchy_information specifies whether the transmission is
hierarchical and, if so, what the α value is.
hierarchy_information
000
001
010
011
100 to 111
α value
non-hierarchical
α=1
α=2
α=4
reserved for future use
Table 64 Signalling format for the α values
code_rate: The code_rate is a 3-bit field specifying the inner FEC scheme used according to
table 43. Non-hierarchical channel coding and modulation requires signalling of one code rate. In
this case, 3 bits specifying code_rate according to table 44 are followed by another 3 bits of value
'000’. Two different code rates may be applied to two different levels of modulation with the aim of
achieving hierarchy. Transmission then starts with the code rate for the HP level of the modulation
and ends with the one for the LP level.
code_rate
000
001
010
011
100
101 to 111
description
1/2
2/3
3/4
5/6
7/8
reserved for future use
Table 65 Signalling format for each of the code rates
guard_interval: The guard_interval is a 2-bit field specifying:
guard_interval
00
01
10
11
guard interval values
1/32
1/16
1/8
¼
Table 66 Signalling format for each of the guard interval values
transmission_mode: This 2-bit field indicates the number of carriers in an OFDM frame.
transmission_mode
00
01
10 to 11
description
2k mode
8k mode
reserved for future use
Table 67 Signalling format for transmission mode
other_frequency_flag: This 1-bit flag indicates whether other frequencies are in use. The value
“0” indicates that no other frequency is in use, “1” indicates that one or more other frequencies are
in use.
 2005 CELTIC participants in project Wing TV
page 126 (140)
CELTIC Wing TV project report
B.3.6 Time Slice And Fec Identifier Descriptor
The time_slice_and_fec_identifier_descriptor may appear in a NIT actual sub_table. When located
in the first descriptor loop, the descriptor applies to all elementary streams with stream type 0x90
within all transport streams announced within the sub-table. When located in the second descriptor
loop, the descriptor applies to all elementary streams with stream type 0x90 within the specific
transport stream, this descriptor overwrites any descriptors in the first descriptor loop.
Syntax
No. of bits
Identifier
8
8
1
2
2
3
8
4
4
uimsbf
uimsbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
8
bslbf
time_slice_fec_identifier_descriptor(){
descriptor_tag
descriptor_length
time_slicing
mpe_fec
reserved_future_use
frame_size
max_burst_duration
max_average_rate
time_slice_fec_id
for (i=0;i<N;i++){
id_selector_byte
}
}
Table 68 Time Slice and FEC Identifier Descriptor
Semantics for time slice fec identifier descriptor
descriptor_tag: Shall be set to value of 0x77.
descriptor_length: This 8-bit field specifies the number of bytes of the descriptor immediately
following this field.
time_slicing: This 1-bit field indicates, whether the referenced elementary stream is Time Sliced.
The value "1" indicates Time Slicing being used, and the value "0" indicates that Time Slicing is not
used.
mpe_fec: This 2-bit field indicates, whether the referenced elementary stream uses MPE-FEC, and
which algorithm is used.
value
00
01
10 to 11
MPE FEC
MPE FEC Not used
MPE FEC Used
reserved for future use
Algorithm
n/a
Reed Salomon(255, 191, 64)
reserved for future use
Table 69 MPE FEC Algorithm
reserved_for_future_use: This 2-bit field shall be set, when not used, to "11".
frame_size: This 3-bit field is used to give information that a decoder may use to adapt its
buffering usage. The exact interpretation depends on whether Time Slicing and/or MPE-FEC are
used. In case Time Slicing is used (i.e. time_slicing is set to "1"), this field indicates the maximum
number of bits on section payloads allowed within a Time Slice burst on the elementary stream. For
MPE sections, bits are counted over ip_datagram_data_bytes or LLC_SNAP field (whichever is
supported), excluding any possible stuffing_bytes. For MPE-FEC sections, bits are counted over
rs_data_bytes. When MPE-FEC is used (i.e. mpe_fec is set to 0x1), this field indicates the exact
number of rows on each MPE-FEC Frame on the elementary stream. If both Time Slicing and
MPE-FEC are used on an elementary stream, both constraints (i.e. the maximum burst size and
the number of rows) apply. If time_slice_fec_id is set to "0", the coding of the frame_size is
according to the table below. If time_slice_fec_id is set to any other value, coding of the frame_size
is currently not defined.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
Size
0x00
0x01
0x02
0x03
0x04 to 0x07
page 127 (140)
Max Burst Size
512Kbits=524288 bits
1024 Kbits
1536 Kbits
2048 Kbits
reserved for future use
MPE FEC Frame Rows
256
512
768
1024
reserved for future use
Table 70 Size coding
max_burst_duration: This 8-bit field is used to indicate the maximum burst duration in the
elementary stream. A burst shall not start before T1 and shall end not later than at T2, where T1 is
the time indicated by delta-t in the previous burst, and T2 is T1 + maximum burst duration. If the
time_slice_fec_id is set to "0", the indicated value for maximum burst duration shall be from 20 ms
to 5,12 s, the resolution is 20 ms, and the field is decoded according to the following formula:
Maximum burst duration = (max_burst_duration + 1) × 20 ms
If the time_slice_fec_id is set to any other value than "0", the coding of the max_burst_duration is
currently not defined. When time_slicing is set to '0' (i.e. Time Slicing not used), this field is
reserved for future use and shall be set to 0xFF when not used.
max_average_rate: This 4-bit field is used to define the maximum average bit rate in MPE section
payload level over one time slicing cycle or MPE-FEC cycle and it is given by:
Cb =
BS
TC
where Bs is the size of the current Time Slicing burst or MPE-FEC Frame in MPE section payload
bits and Tc is the time from the transport packet carrying the first byte of the first MPE section in the
current burst/frame to the transport packet carrying the first byte of the first MPE section in the next
burst/frame within the same elementary stream.
Note that when MPE-FEC is used, the RS data is not included in Bs.
Bit_rate
0000
0001
0010
0011
0100
0101
0110
0111
1000 to 1111
description
16Kbps
32Kbps
64Kbps
128Kbps
256Kbps
512Kbps
1024Kbps
2048Kbps
reserved for future use
Table 71 Coding for max_average_rate
time_slice_fec_id: This 4-bit field identifies the usage of following id_selector_byte(s). Currently
no use is defined, and this field shall be set to value 0x0, and id_selector_byte(s) shall not be
present. Note that this field affects on coding of frame_size, max_burst_duration and
max_average_rate fields on the actual descriptor, and the address field of real-time parameters on
the referred elementary stream.
id_selector_byte:
The
definition
of
the
id_selector_byte(s)
time_slice_fec_identifier_descriptor will depend on the time_slice_fec_id.
B.4
of
the
Descriptors required in SDT for IPDC over DVB-H Networks
B.4.1 Data Broadcast Descriptor
The descriptor shall be present for each component carrying one or more MPE section streams
within the DVB service.
 2005 CELTIC participants in project Wing TV
page 128 (140)
CELTIC Wing TV project report
Syntax
data_broadcast_descriptor(){
descriptor_tag
descriptor_length
data_broadcast_id
component_tag
selector_length
for (i=0; i<selector_length; i++){
selector_byte
}
ISO_639_language_code
text_length
for (i=0; i<text_length; i++){
text_char
}
}
No. of bits
Identifier
8
8
16
8
8
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
8
uimsbf
24
8
bslbf
uimsbf
8
uimsbf
Table 72 Data Broadcast Descriptor
Semantics for data broadcast descriptor
descriptor_tag: Shall be set to value of 0x64.
data_broadcast_id: This 16-bit field identifies the data broadcast specification that is used to
broadcast the data in the broadcast network. It should take the value 0x0005 to signal MPE.
component_tag: This optional 8-bit field has the same value as the component_tag field in the
stream identifier descriptor that may be present in the PSI program map section for the stream on
which the data is broadcast. If this field is not used it shall be set to the value 0x00.
selector_length: This 8-bit field specifies the length in bytes of the following selector field.
selector_byte: This is an 8-bit field. The sequence of selector_byte fields specifies the selector
field. The syntax and semantics of the selector field shall be defined by the data broadcast
specification that is identified in the data_broadcast_id field. The selector field may contain service
specific information that is necessary to identify an entry-point of the broadcast data.
ISO_639_language_code: This 24-bit field contains the ISO 639 [30] three character language
code of the following text fields. Both ISO 639.2/B and ISO 639.2/T may be used. Each character is
coded into 8 bits according to ISO 8859-1 [31] and inserted in order into the 24-bit field.
text_length: This 8-bit field specifies the length in bytes of the following text describing the data
component.
text_char: This is an 8-bit field. A string of "char" fields specifies the text description of the data
component.
Data Broadcast descriptor selector byte definition for Multiprotocol Encapsulation Info
Structure:
•
MAC_address_range SHALL be set to value of 0x01, indicating that only MAC_address_6 in
the header of MPE sections carried within the referred component contains valid MAC-address
information.
•
MAC_IP_mapping_flag SHOULD be set to '1', indicating that it uses the IP to MAC mapping as
described in RFC 1112 [32] for IPv4 multicast addresses, and RFC 2464 [33] for IPv6 multicast
addresses.
•
alignment_indicator SHALL be set to '0', indicating that alignment of 8 bits is used.
•
max_sections_per_datagram SHALL be set to value of 0x01, indicating that each IP datagram
is carried in exactly one MPE section.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 129 (140)
Syntax
multiprotocol_encapsulation_info(){
MAC_address_range
MAC_IP_mapping_flag
alignment_indicator
reserved
max_sections_per_datagram
}
No. of bits
Identifier
3
1
1
3
8
uimsbf
bslbf
bslbf
bslbf
uimsbf
Table 73 Data Broadcast Descriptor Selector Bytes
Semantics for multiprotocol encapsulation info
MAC_address_range: This 3-bit field shall indicate the number of MAC address bytes that the
service uses to differentiate the receivers according to the following table:
MAC_address_range
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
valid MAC_address bytes
reserved
6
6,5
6,5,4
6,5,4,3
6,5,4,3,2
6,5,4,3,2,1
reserved
Table 74 MAC Address Range coding
MAC_IP_mapping_flag: This is a 1-bit flag. The service shall set this flag to "1" if it uses the IP to
MAC mapping as described in RFC 1112 [32] for IPv4 multicast addresses and RFC 2464 [33] for
IPv6 multicast addresses. If this flag is set to "0", the mapping of IP addresses to MAC addresses
is done outside the scope of the present document.
alignment_indicator: This is a 1-bit field that shall indicate the alignment that exists between the
bytes of the datagram_section and the Transport Stream bytes according to table 8.
reserved: This is a 3-bit field that shall be set to "111".
max_sections_per_datagram: This is an 8-bit field that shall indicate the maximum number of
sections that can be used to carry a single datagram unit.
B.4.2 Service Descriptor
The descriptor shall be present. Service Type shall be set to 0x0C (Data Broadcast Service) for
IPDC over DVB-H Networks.
Syntax
service_descriptor(){
descriptor_tag
descriptor_length
service_type
service_provider_name_length
for (i=0;i<N;I++){
char
}
service_name_length
for (i=0;i<N;I++){
char
}
}
Table 75 Data Broadcast Descriptor
 2005 CELTIC participants in project Wing TV
No. of bits
Identifier
8
8
8
8
uimsbf
uimsbf
uimsbf
uimsbf
8
uimsbf
8
uimsbf
8
uimsbf
page 130 (140)
CELTIC Wing TV project report
Semantics for service descriptor
descriptor_tag: Shall be set to value of 0x48.
service_type: This is an 8-bit field specifying the type of the service. It shall be coded according to
the next table:
Service_type
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
0x09
0x0A
0x0B
0x0C
0x0D
0x0E
0x0F
0x10
0x11 to 0x7F
0x80 to 0xFE
0xFF
Description
reserved for future use
digital television service
digital radio sound service
Teletext service
NVOD reference service
NVOD time-shifted service
mosaic service
PAL coded signal
SECAM coded signal
D/D2-MAC
FM Radio
NTSC coded signal
data broadcast service
reserved for Common Interface Usage
RCS Map [ref. to RCS]
RCS FLS [ref. to RCS]
DVB MHP service
reserved for future use
user defined
reserved for future use
Table 76 Service Type Coding
service_provider_name_length: This 8-bit field specifies the number of bytes that follow the
service_provider_name_length field for describing characters of the name of the service provider.
char: This is an 8-bit field. A string of char fields specify the name of the service provider or
service.
service_name_length: This 8-bit field specifies the number of bytes that follow the
service_name_length field for describing characters of the name of the service.
B.5
Descriptors required in INT for IPDC over DVB-H Networks
B.5.1 Target IP Address Descriptor
•
The use of target_IP_slash_descriptor or target_IP_source_slash_descriptor instead is
RECOMMENDED.
•
Note that this descriptor can contain maximum of 62 IPv4_addr fields.
•
IPv4_addr_mask field indicates the bits significant in each IP address announced in the
following IPv4_addr fields within the descriptor.
•
This descriptor refers to every IP flow with any source address and any of the announced
destination address.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 131 (140)
Syntax
target_ip_address_descriptor(){
descriptor_tag
descriptor_length
IPv4_addr_mask
for (i=0;i<N;I++){
IPv4_addr
}
}
No. of bits
Identifier
8
8
32
uimsbf
uimsbf
uimsbf
32
uimsbf
Table 77 Target IP AddressDescriptor
Semantics for Target IP Address descriptor
descriptor_tag: Shall be set to value of 0x09.
IPv4_addr_mask: A 32-bit field that specifies the IPv4 mask.
IPv4_addr: A 32-bit field that specifies an IPv4 unicast/multicast/broadcast address. The IPv4
address is fragmented into 4 fields of 8 bits where the first byte contains the most significant byte of
the IPv4 address (dotted decimal notation).
B.5.2 Target IP Slash Descriptor
•
Note that this descriptor can contain maximum of 51 IPv4_addr fields.
•
IPv4_slash_mask indicates the number of significant bits in the corresponding IPv4_addr,
starting from the msb.
•
This descriptor refers to every IP flow with any source address and any of the announced
destination address.
Syntax
target_ip_slash_descriptor(){
descriptor_tag
descriptor_length
for (i=0;i<N;I++){
IPv4_addr
IPv4_slash_mask
}
}
No. of bits
Identifier
8
8
uimsbf
uimsbf
32
8
uimsbf
uimsbf
Table 78 Target IP Slash Descriptor
Semantics for Target IP Slash descriptor
descriptor_tag: Shall be set to value of 0x0F.
IPv4_address: A 32 bit field that specifies an IPv4 unicast/multicast/broadcast address. The IPv4
address is fragmented into 4 fields of 8 bits where the first byte contains the most significant byte of
the IPv4 address (dotted notation).
IPv4_slash_mask: An 8 bit field that specifies the IPv4 mask in slash ("/") or shortform notation,
e.g. 192.168.37.1/24.
B.5.3 Target IP Source Slash Descriptor
•
Note that this descriptor can contain maximum of 25 IPv4_addr fields.
•
IPv4_source_slash_mask indicates the number of significant bits in the corresponding
IPv4_source_addr, starting from the msb.
 2005 CELTIC participants in project Wing TV
page 132 (140)
CELTIC Wing TV project report
•
IPv4_dest_slash_mask indicates the number of significant bits in the corresponding
IPv4_dest_addr, starting from the msb.
•
This descriptor refers to every IP flow with any of the announced source address and any of
the announced destination address.
Syntax
target_ip_source_slash_descriptor(){
descriptor_tag
descriptor_length
for (i=0;i<N;I++){
IPv4_source_addr
IPv4_source_slash_mask
IPv4_dest_mask
IPv4_dest_slash_mask
}
}
No. of bits
Identifier
8
8
uimsbf
uimsbf
32
8
32
8
uimsbf
uimsbf
uimsbf
uimsbf
Table 79 Target IP Source Slash Descriptor
Semantics for Target IP Source Slash descriptor
descriptor_tag: Shall be set to value of 0x10.
IPv4_source_address: A 32 bit field that specifies an IPv4 unicast/multicast/broadcast source
address. The IPv4 address is fragmented into 4 fields of 8 bits where the first field contains the
most significant block of the IPv4 address (dotted notation).
IPv4_source_slash_mask: An 8 bit field that specifies the IPv4 mask in slash ("/") or shortform
notation e.g. IP address/subnetmask.
IPv4_dest_address: A 32 bit field that specifies an IPv4 unicast/multicast/broadcast destination
address. The IPv4 address is fragmented into 4 fields of 8 bits where the first field contains the
most significant block of the IPv4 address (dotted notation).
IPv4_dest_slash_mask: An 8 bit field that specifies the IPv4 mask in slash ("/") or shortform
notation e.g. IP address/subnetmask.
B.5.4 Target IPv6 Address Descriptor
•
The use of target_IPv6_slash_descriptor or target_IPv6_source_slash_descriptor instead is
RECOMMENDED.
•
Note that this descriptor can contain maximum of 14 IPv6_addr fields.
•
IPv6_addr_mask field indicates the bits significant in each IPv6 address announced in the
following
IPv6_addr
fields
within
the
descriptor.
IPv6_addr_mask
value
ffff:ffff:ffff:ffff:ffff:ffff:ffff:ff00 would indicate that the 8 lsb of the IPv6_addr value are to be
ignored.
•
This descriptor refers to every IP flow with any source address and any of the announced
destination address.
Syntax
target_ipv6_address_descriptor(){
descriptor_tag
descriptor_length
IPv6_addr_mask
for (i=0;i<N;I++){
IPv6_addr
}
}
No. of bits
Identifier
8
8
128
uimsbf
uimsbf
uimsbf
128
uimsbf
Table 80 Target IPv6 AddressDescriptor
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 133 (140)
Semantics for Target IPv6 Address descriptor
descriptor_tag: Shall be set to value of 0x0A.
IPv6_addr_mask: A 128-bit field that specifies the IPv6 mask.
IPv6_addr: A 128 bit field that specifies an IPv6 address. The IPv6 address is fragmented into 16
fields of 8 bits where
the first byte contains the most significant byte of the IPv6 address.
B.5.5 Target IPv6 Slash Descriptor
•
Note that this descriptor can contain maximum of 15 IPv6_addr fields.
•
IPv6_slash_mask indicates the number of significant bits in the corresponding IPv6_addr,
starting from the msb. IPv6_slash_mask_value 120 would indicate that the 8 lsb of the
IPv6_addr value are to be ignored.
•
This descriptor refers to every IP flow with any source address and any of the announced
destination address.
Syntax
target_ipv6_slash_descriptor(){
descriptor_tag
descriptor_length
for (i=0;i<N;I++){
IPv6_addr
IPv6_slash_mask
}
}
No. of bits
Identifier
8
8
uimsbf
uimsbf
128
8
uimsbf
uimsbf
Table 81 Target IPv6 Slash Descriptor
Semantics for Target IPv6 Slash descriptor
descriptor_tag: Shall be set to value of 0x11.
IPv6_address: A 128 bit field that specifies an IPv6 unicast/multicast/anycast address. The IPv6
address is fragmented into 8 fields of 16 bits where the first field contains the most significant block
of the IPv6 address (dotted notation).
IPv6_slash_mask: An 8 bit field that specifies the IPv6 mask in slash ("/") or shortform notation
e.g. IP address/subnetmask.
B.5.6 Target IPv6 Source Slash Descriptor
•
Note that this descriptor can contain maximum of seven (7) IPv6_addr fields.
•
IPv6_source_slash_mask indicates the number of significant bits in the corresponding
IPv6_source_addr, starting from the msb.
•
IPv6_dest_slash_mask indicates the number of significant bits in the corresponding
IPv6_dest_addr, starting from the msb.
•
This descriptor refers to every IP flow with any of the announced source address and any of
the announced destination address.
 2005 CELTIC participants in project Wing TV
page 134 (140)
CELTIC Wing TV project report
Syntax
target_ipv6_source_slash_descriptor(){
descriptor_tag
descriptor_length
for (i=0;i<N;I++){
IPv6_source_addr
IPv6_source_slash_mask
IPv6_dest_mask
IPv6_dest_slash_mask
}
}
No. of bits
Identifier
8
8
uimsbf
uimsbf
128
8
128
8
uimsbf
uimsbf
uimsbf
uimsbf
Table 82 Target IP Source Slash Descriptor
Semantics for Target IP Source Slash descriptor
descriptor_tag: Shall be set to value of 0x12.
IPv6_source_address: A 128 bit field that specifies an IPv6 unicast/multicast/anycast source
address. The IPv6 address is fragmented into 8 fields of 16 bits where the first field contains the
most significant block of the IPv6 address (dotted notation).
IPv6_source_slash_mask: An 8 bit field that specifies the IPv6 mask in slash ("/") or shortform
notation e.g. IP address/subnetmask.
IPv6_dest_address: A 128 bit field that specifies an IPv6 unicast/multicast/anycast destination
address. The IPv6 address is fragmented into 8 fields of 16 bits where the first field contains the
most significant block of the IPv6 address (dotted notation).
IPv6_dest_slash_mask: An 8 bit field that specifies the IPv6 mask in slash ("/") or shortform
notation e.g. IP address/subnetmask.
B.5.7 IP/MAC Platform Name Descriptor
This descriptor is to be used to provide the name of the IP/MAC platform. It must appear in platform
loop.
Syntax
IP/MAC_platform_name_descriptor(){
descriptor_tag
descriptor_length
ISO_639_language_code
for (i=0;i<N;I++){
text_char
}
}
No. of bits
Identifier
8
8
24
uimsbf
uimsbf
uimsbf
8
uimsbf
Table 83 IP/MAC Platform Name Descriptor
Semantics for IP/MAC Platform Name descriptor
descriptor_tag: Shall be set to value of 0x0C.
ISO_639_language_code: This 24-bit field contains the ISO 639-2 [30] three character language
code of the language of the following platform name. Both ISO 639-2/B and ISO 639-2/T may be
used. Each character is coded into 8 bits according to ISO 8859-1 [31] and inserted in order into
the 24-bit field.
EXAMPLE: French has 3-character code "fre", which is coded as:
'0110 0110 0111 0010 0110 0101".
text_char: This is an 8-bit field. A string of "text_char" fields specifies the platform name.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 135 (140)
B.5.8 IP/MAC Platform Provider Name Descriptor
This descriptor is to be used to provide the provider name of the IP/MAC platform. It must appear in
platform loop.
Syntax
IP/MAC_platform_provider_name_descriptor(){
descriptor_tag
descriptor_length
ISO_639_language_code
for (i=0;i<N;I++){
text_char
}
}
No. of bits
Identifier
8
8
24
uimsbf
uimsbf
uimsbf
8
uimsbf
Table 84 IP/MAC Platform Provider Name Descriptor
Semantics for IP/MAC Platform Provider Name descriptor
descriptor_tag: Shall be set to value of 0x0D.
ISO_639_language_code: This 24-bit field contains the ISO 639-2 [30] three character language
code of the language of the following platform name. Both ISO 639-2/B and ISO 639-2/T may be
used. Each character is coded into 8 bits according to ISO 8859-1 [31] and inserted in order into
the 24-bit field.
EXAMPLE: French has 3-character code "fre", which is coded as:
'0110 0110 0111 0010 0110 0101".
text_char: This is an 8-bit field. A string of "text_char" fields specifies the platform name.
B.5.9 IP/MAC Stream Location Descriptor
Each
iteration
of
2nd
loop
of
INT
table
SHALL
contain
at
least
one
IP/MAC_stream_location_descriptor in operational-loop, providing the location of IP streams. Given
location SHALL NOT occur more than once within each iteration of 2nd loop of INT table.
Syntax
IP/MAC_stream_location_descriptor(){
descriptor_tag
descriptor_length
network_id
original_network_id
transport_stream_id
service_id
component_tag
}
No. of bits
Identifier
8
8
16
16
16
16
8
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
Table 85 IP/MAC Stream Location Descriptor
Semantics for IP/MAC Stream Location descriptor
descriptor_tag: Shall be set to value of 0x13.
network_id: This is a 16-bit field which serves as a label to identify the delivery system from any
other delivery system. Allocations of the value of this field are found in TR 101 162 [26].
original_network_id: This 16-bit field gives the label identifying the network_id of the originating
delivery system.
 2005 CELTIC participants in project Wing TV
page 136 (140)
CELTIC Wing TV project report
transport_stream_id: This is a 16 bit field which serves as a label for identification of the present
document from any other multiplex within the delivery system.
service_id: This is a 16 bit field which serves as a label to identify this service from any other
service within the TS. The service_id is the same as the program_number in the corresponding
program_map_section.
component_tag: This 8-bit field identifies the component stream for associating it with a
description given in a component descriptor. Within a program map section each stream identifier
descriptor shall have a different value for this field.
B.5.10 Time Slice Fec Identifier Descriptor
If this descriptor is present in target_loop, it indicates that all Elementary Streams referred within
this loop after this descriptor are time-sliced with parameters announced in this descriptor.
Descriptor applies from the next IP/MAC_stream_location_descriptor (if any) to the end of the
current iteration of the loop or to the next time_slice_fec_identifier_descriptor, which ever comes
first.
Syntax is defined in Section B.3.6.
 2005 CELTIC participants in project Wing TV
CELTIC Wing TV project report
page 137 (140)
Annex C - DVB-H signalling example
This Annex presents a real example from a Transport Stream generated with an IP Encapsulator.
This is a simple example where five IP Flows of two different platforms are transported and
signalled into single TS over four DVB-H Services and themselves over two DVB Services. In the
example, the reader can follow the process from the discovering of DVB-H services by Linkage
Descriptor in NIT table until the location of the IPMAC Streams by the Network Id, Original Network
Id, Transport Stream Id, Service Id and Component Tag. In order to simplify, a single TS has been
used.
The TS example (Signalling.ts) described in this section can be downloaded from the Wing TV FTP
site.
The TS contains 4 DVB-H services and is described in the following figure:
Bitrate
6638212bps
0x03E9
0x03EB
0x03E8
0x03EA
PIDs
Signalling (PAT, PMT, NIT, SDT, TDT, TSDT, INT)
IP0
512
Rows
IP1
IP2
512
512
Rows Rows
0,167 0,167 0,167
IP3
225.6.7.8:1234 500000bps, Pfr 1
225.6.7.9:1234 500000bps, Pfr 1
225.6.7.10:1234 500000bps, Pfr 2
225.6.7.11:1234 500000bps, Pfr 2
225.6.7.12:1234 500000bps, Pfr 2
1024
Rows
0,334
IP0
…
6510000bps
t
1,564
DVB
Service S
DVB
Service S2
Figure 80 TS example
STEP 1:
Linkage descriptor of type 0x0B is found on NIT signalling IP/MAC Notification Services. These
IP/MAC Notification Services could be located in other TSs. However, in the example everything is
carried in the same TS. Also, a linkage descriptor of type 0x0C could be found signalling an
IP/MAC Notification BAT or NIT. This option has not been used in the example.
STEP 2:
In the TS carrying IP/MAC Notification Services, PID of INT Tables can be found by
DataBroadcastIdDescriptor of type 0x000B and IP/MAC notification info structure.
STEP 3:
Linkage between IP/MAC Stream (Source Address, Destination Address, IPv4, IPv6) and IP/MAC
Stream Location can be found out by target descriptors and operational descriptors
(IPMACStreamLocationDescriptor). From there, Network Id, Original Network Id, Transport Stream
Id, Service Id and Component Tag carrying the desired IP/MAC Stream can be found. This can be
again placed in the same or different TS which in this case is in the same TS to simplify the
example.
The following pages show in detail the PSI/SI signalling in this example required in DVB-H
Networks.
Note: Descriptors “Cell Frequency Link Descriptor” and “Time Slice FEC Identifier Descriptor” are
missing in NIT table in Signalling.ts.
 2005 CELTIC participants in project Wing TV
page 138 (140)
PAT
TS Id
0x0001
PN 0x0000 PID 0x0010 (NIT)
PN 0x0001 PID 0x0064
TSDT
“DVB”
PN 0x0002 PID 0x0065
STEP 2
ES StreamType 0x05 PID 0x01F4 DataBroadcastIdDescriptor 0x000B INT Pfrm 1
PMT
PN
0x0001
ES StreamType 0x90 PID 0x03E8 StreamIdentifierDescriptor ComponentTag 0
ES StreamType 0x90 PID 0x03E9 StreamIdentifierDescriptor ComponentTag 1
ES StreamType 0x05 PID 0x01F5 DataBroadcastIdDescriptor 0x000B INT Pfrm 2
PMT
PN
0x0002
ES StreamType 0x90 PID 0x03EA StreamIdentifierDescriptor ComponentTag 2
ES StreamType 0x90 PID 0x03EB StreamIdentifierDescriptor ComponentTag 3
From NIT Linkage Descriptors
NIT
NId
0x0001
PID 0x0064
Cell List Descriptor
Network Name Descriptor “Network Name”
Linkage Descriptor TSId 0x0001 ONId 0x0001 SId 0x0001 PfrmId 0x0001 DemoServices
Linkage Descriptor TSId 0x0001 ONId 0x0001 SId 0x0002 PfrmId 0x0002 DemoServices2
TSId 0x0001 ONId 0x0001 QPSK 650MHz
SDT
TSId
0x0001
TDT
SId 0x0001
Data Broadcast Descriptor Component Tag 0 IP0
Data Broadcast Descriptor Component Tag 1 IP1
Service Descriptor (Data Broadcast Service) Service Name “S”
SId 0x0002
Data Broadcast Descriptor Component Tag 2 IP2
Data Broadcast Descriptor Component Tag 3 IP3
Service Descriptor (Data Broadcast Service) Service Name “S2”
 2005 CELTIC participants in project Wing TV
STEP 1
PID 0x0065
CELTIC Wing TV project report
From PMT DataBroadcast Id Descriptor
Platform Descriptor Loop
INT
Pfrm Id 1
PID 0x01F4
IP/MAC Platform Name Descriptor “DemoServices”
IP/MAC Platform Provider Name Descriptor “LaSalle”
Target Descriptor Loop
Operational Descriptor Loop
Target Descriptor Loop
Operational Descriptor Loop
TargetIPSlashDescriptor 225.6.7.8
TimeSliceAndFECIdentifierDescriptor Frame Size 512 MaxBurstDuration 180ms MaxRate 512Kbps
IPMACStreamLocationDescriptor NId 0x0001 ONId 0x0001 TSId 0x0001 SId 0x0001 CTag 0x00
TargetIPSlashDescriptor 225.6.7.9
TimeSliceAndFECIdentifierDescriptor Frame Size 512 MaxBurstDuration 180ms MaxRate 512Kbps
IPMACStreamLocationDescriptor NId 0x0001 ONId 0x0001 TSId 0x0001 SId 0x0001 CTag 0x01
From PMT DataBroadcast Id Descriptor
IP/MAC Platform Name Descriptor “DemoServices2”
Platform Descriptor Loop
IP/MAC Platform Provider Name Descriptor “LaSalle”
STEP
INT
Pfrm Id 2
PID 0x01F5
Target Descriptor Loop
Operational Descriptor Loop
Target Descriptor Loop
Operational Descriptor Loop
 2005 CELTIC participants in project Wing TV
3
TargetIPSlashDescriptor 225.6.7.10
TimeSliceAndFECIdentifierDescriptor Frame Size 512 MaxBurstDuration 180ms MaxRate 512Kbps
IPMACStreamLocationDescriptor NId 0x0001 ONId 0x0001 TSId 0x0001 SId 0x0002 CTag 0x02
TargetIPSlashDescriptor 225.6.7.11
TargetIPSlashDescriptor 225.6.7.12
TimeSliceAndFECIdentifierDescriptor Frame Size 1024 MaxBurstDuration 340ms MaxRate 1024Kbps
IPMACStreamLocationDescriptor NId 0x0001 ONId 0x0001 TSId 0x0001 SId 0x0002 CTag 0x03
page 140 (140)
CELTIC Wing TV project report
 2005 CELTIC participants in project Wing TV