Synchronization architecture for DVB-H seamless handover Alejandro López González, Jordi Mas Bundio and Gabriel Fernández Ubiergo

GTAM-Grup de Recerca en Tecnologies Audiovisuals i Multimedia.

ENGINYERIA I ARQUITECTURA LA SALLE. UNIVERSITAT RAMON LLULL.

Quatre Camins 2, 08022 Barcelona (Spain)

Email: {alexl, jmas, gabrielf}@salle.url.edu

ABSTRACT

DVB-H standard is a broadcast transmission system for IP-

based services adapted to handheld devices capabilities.

The key challenges of the system are the strict reception

conditions and mobility. When a DVB-H receiver enters

into a new cell with different transmission frequency, in

order to maintain a selected service reception with no

interruption, the receiver must perform a seamless

handover process. This seamless handover can be achieved

if accurate synchronisation is assured within the

transmitting cells. This paper presents a synchronization

architecture offering seamless handover to services in a

DVB-H network. This architecture has been implemented

on an existing DVB-H platform, where specific laboratory

tests for seamless handover have been performed.

Index Terms— DVB-H, Seamless handover

1. INTRODUCTION

This work presents an architecture to perform seamless

handover in DVB-H networks. Firstly, the concept of

handover is presented and the architecture of the DVB-H

broadcast network. The main contribution of this work is

the proposed algorithm used to synchronize the DVB-H IP

encapsulators, as this is the main issue when performing

handover. Synchronization is specially important because

the receiving terminal needs to receive synchronized

signals from different cells that are transmitting different

contents except for a few services which are common in

several cells. Finally, the results of laboratory tests

performed in the scope in order to illustrate the validity of

the proposed approach.

2. DVB-H STANDARD

DVB-H standard [1] is based on a time-slicing scheme,

inspired in time division multiplexing (TDM). Significantly

reduction of average power consumption is reached in

DVB-H terminal. Time slicing strategy sends data in bursts

at intervals of time. Therefore, between bursts, other

elementary streams are allowed to share the bandwidth. In

this way, power saving is achieved in the receiver since the

receiving part is only active a fraction of time, when the

service burst is ‘active’.

Apart from power saving in terminals, time-slicing permits

seamless handover of services. During an off period, the

terminal can switch from one transport stream to another

with no interruption in the service display. As the receiver

stays active only for the fraction of time while the burst of

the requested service is received, the off time may be used

by the receiver to apply handover strategies.

2. HANDOVER CONSIDERATIONS

From the user experience point of view, we can

differentiate two types of handover in DVB-H [2]: non

seamless and seamless.

The first type, non seamless handover, is the one that

allows the user to keep on watching the same service while

he/she is moving through the cells of a DVB-H network.

To perform this, PSI/SI information is required to obtain

the location (Original Network Id, Transport StreamId,

Service Id and Component Tag) where the same service is

also available. Unfortunately, the process of scanning,

changing frequency and synchronizing to the new service

means unacceptable interruptions of service display to end

users.

The second type, seamless handover, includes the

functionality of handover but with the difference that, in

this case, the handover is performed in a transparent way

from the user experience point of view, which means that

the display of the video is not interrupted during the

handover process. This is achieved by means of IP

Encapsulator (IPEs) synchronization. This synchronization

must be achieved at two different levels: at time and at

content levels.

The first one, synchronization in time, is the

synchronization of the transmission time of the burst of the

service which is intended to handover. This is necessary

since the receiver expects to receive the next burst during

the handover process at the time signaled by the delta-T

field included in the Multi Protocol Encapsulation section

header.

The second one, synchronization in content, is the

synchronization of the content that is being encapsulated in

each burst, this means that the IP packets being

encapsulated by two different IP Encapsulators must be

exactly the same in both cases so that the receiver will not

miss any IP packet during the handover leading to a

seamless display during handover.

3. HANDOVER ARCHITECTURE

The handover architecture presented in this work describes

the architecture of the DVB-H network at TS level focusing

on the IP Encapsulators which are the elements that need to

be synchronized to perform handover. Figure 1 depicts de

proposed architecture.

Figure 1. DVB-H network architecture for seamless handover

based on Master-Slaves

The network is composed by a number of cells transmitting

transport streams on different frequencies. Offering

seamless handover capability means that some selected

services are being transmitted at the same time in different

cells or transport streams that PSI/SI information is being

transmitted accordingly to perform handover and that burst

transmission times and contents are synchronized for the

handover services. In this way, service handover can be

performed at the border between two cells which remaining

imperceptible to the user.

An IPE hierarchy is established for this purpose. One of the

IPEs must have the Master role and the rest of IPEs have

the Slave role. The Master IPE will be the time and content

reference in order to synchronize the rest of IPEs. It must

be noted that the same reference clock needs to be used by

all IPEs to achieve synchronization between them. This is

done by means of NTP synchronization protocol, which

allows achieving synchronization precisions in the order of

DeltaT granularity (10ms).

In the proposed solution, IPEs with handover services are

connected by an IP network which is the unique tool

required to synchronize all the IPEs. For handover services,

Master IPE and Slave IPEs will establish a synchronization

protocol by means of IP packets messages. In these IP

packets, information like encapsulation burst time and IP

encapsulated content is going to be sent. It must be noted

that synchronization system needs a transitory period in

which all Slave IPEs get synchronized respect to Master

IPE. Once synchronization is achieved, the system will be

continuously checking the synchronization state between

IPEs in order to correct possible delays. These delays can

be due to one or both of the following reasons: small

variations in clock between Master and Slaves and

variations in the clocks of each IPE DVB-ASI Transport

Stream generation devices.

The message synchronization protocol between IPEs has

the following rules: Master IPE informs the rest of IPEs

about time in which handover services are being sent as

well as the encapsulated content in every moment. Due to

small variations in clock of each IPE DVB-ASI Transport

Stream generation device, the basic rule is that all IPEs

(Master and Slaves) will transmit at the slowest rate of all

of them. This means that small delays can be inserted

during transmission in order to resynchronize all the

elements, these delays can occur in Slaves IPEs but also in

Master IPE.

4. HANDOVER ALGORITHM

The algorithm for IPE synchronization is divided in two

steps: synchronization in time and synchronization in

content. The first step to be achieved by a Slave IPE is

synchronization in time, once it is synchronized in time, the

Slave IPE proceeds to synchronize in content. After this

‘transitory period’, the system passes to ‘permanent period’

where there is a constant monitoring of variations of

synchronization in time and in content between Master and

Slaves.

4.1. Time synchronization

This is the first step to be accomplished by Master and

Slaves in order to be synchronized. This synchronization is

based on DVB-H configurations between Master and

Slaves with the same Time Slice Cycle, that means that the

period of time between bursts is the same for Masters and

Slaves.

Firstly, Master IPE is constantly announcing to Slave IPEs

burst transmission time information to make possible the

process of synchronization in time. This message

announces the time when every burst is sent. It is called

“HANDOVER MASTER TIME INFO”.

All Slaves IPEs are listening to “HANDOVER MASTER

TIME INFO” messages from Master. At this stage, there is

a difference between Slave burst transmission and Master

burst transmission, so they are not synchronized.

Synchronization in time algorithm begins separating the

problem in two parts, according to positive or negative

delay between Master and Slave bursts. In the first case, the

Slave burst is advanced with respect to Master burst. If

time difference between Master and Slave bursts is less

than a certain threshold “HANDOVER

SYNCHRONIZATION MARGIN” (5ms) time

synchronization state is assumed, so no time correction

process is needed. Otherwise, a time correction must be

done. In order to avoid continuous delays due to the

tolerance of the system, delays are inserted only after the

delay is considered to be stable. The stability state is

considered to be achieved when there is a delay during a

consecutive number of DVB-H cycles “MAX ALARM

COUNTER HANDOVER” (5). When this occurs, a delay

is inserted in the Slave.

dMasterSlave = tBURST MASTER – tBURST SLAVE

if dMasterSlave > 0 (Slave burst in advance with regard to Master burst)

if dMasterSlave > HANDOVER_SYNCHRONIZATION_MARGIN

if Counter > MAX_ALARM_COUNTER_HANDOVER

InsertDelay(dMasterSlave)

Counter = 0

else

Counter++

else

Synchronized in time

Counter = 0

else if dMasterSlave < 0 (Slave burst delayed with regard to Master burst)

if |dMasterSlave| > HANDOVER_SYNCHRONIZATION_MARGIN

&& First Synchronization

Delay Slave to next Master burst

else if |dMasterSlave| > HANDOVER_SYNCHRONIZATION_MARGIN

if Counter > MAX_ALARM_COUNTER_HANDOVER

SendMessagetoMaster(dMasterSlave)

Counter = 0

else

Synchronized in time

Counter = 0

Figure 2. Slave algorithm for synchronization in time

The way a delay is inserted in the output TS of an IPE

consists in sending null transport stream packets at the end

of the Time Slice cycle. The amount of null transport

stream packets is calculated from desired delay time and

bitrate of output signal (DVB-ASI). In this case, delay time

to be used is the temporal delay between Master burst and

Slave burst. Therefore, Master and Slave bursts are going

to be synchronized in time.

In the second case, the Slave burst is delayed with respect

to Master burst. If time difference between Master and

Slave bursts is less than a certain threshold “HANDOVER

SYNCHRONIZATION MARGIN” (5ms), as in the

previous case, time synchronization state is assumed, so no

time correction process is needed. Otherwise, a time

correction process must be started in two possible ways:

1. If it is in ‘transitory state’ of time synchronization, a

time correction will be applied. This time correction is

a delay in Slave burst. The time delay corresponds to

the needed time in order to synchronize Slave burst

with the immediately subsequent Master burst (next

Master burst from the one used to calculate time

difference between Master and Slave bursts).

2. If it is in ‘permanent period’ of time synchronization, a

different time correction will be applied. In this case, a

control counter is also used to evaluate the number of

consecutive times that the correction process is needed.

If counter exceeds the threshold “MAX ALARM

COUNTER HANDOVER” (5) an IP packet message

“HANDOVER SLAVE TIME INFO” is sent to Master

IPE announcing that Master burst must be delayed to

get synchronization in time.

Master IPE is constantly listening to IP packet messages

sent by Slave IPEs announcing if Master burst must be

delayed in order to synchronize to Slaves. The Master’s

criteria to insert a delay is to buffer all requests from Slaves

for delay during a sample period, and insert the maximum

delay request received during the last sample period. The

sample period is considered to be a number of DVB-H

cycles “LOOPS TO LOCK TO SLAVES” (15). Then,

Master and Slave bursts are synchronized in time.

4.2. Content synchronization

This is the second step to be accomplished by Master and

Slaves in order to be synchronized. The aim of this process

is to have Master and Slave IPEs encapsulating the bursts

for the handover services with exactly the same content.

This means that the IP packets encapsulated by a Slave in a

certain burst will be exactly the same (not less and no

more) as the IP packets encapsulated by the Master.

Master IPE is constantly announcing the content of each

burst of a handover service that is being encapsulated. This

message “HANDOVER MASTER CONTENT INFO”

contains encapsulation information for every IP flow (each

combination of destination address and destination port is

considered to be a different IP flow). To optimize IP traffic

generation, this message only contains the first and last

packet for every IP flow that is being encapsulated in that

service.

The Slaves that are synchronized in time are constantly

listening to “HANDOVER MASTER CONTENT INFO”

messages. The process to synchronize the Slave to the

Master in content can be divided in two steps: buffer

synchronization in content and synchronization of frame

transmission.

The aim of the first step, buffer synchronization in content,

is to have input IP buffers before IP encapsulation process

in the same state and position in Master and Slaves. To

achieve this, the Slave buffers every IP flow in independent

buffers (rather than in a single buffer as done in Master

IPE). Therefore, finding which IP packets have to be

encapsulated for each flow is easy, as every flow

corresponds to a different buffer. The process consists of

two parts: first, to skip all IP packets previous to the known

first IP packet in the buffer, and second, to encapsulate

from the known first IP packet to the known last IP packet

in the buffer. Finally, all the IP flow packets of a service

are encapsulated in a MPE-FEC frame. Then, Slave IPE

generates MPE-FEC frames with the same IP flow content

as Master IPE.

At this point, the Master and the Slaves are sending bursts

at the same time points and the content of these bursts are

the same between Master and Slaves. However, the

sequence of bursts and time points of transmission in the

Master and Slaves may not have frame synchronization, as

the example shown in Table 1. Therefore, next step is to

synchronize the frame transmission. From the example in

Table 1 it is clear that the Slave needs to be delayed 2

cycles in order to be synchronized to Master. This is done

by comparing frame number identification which is

included in “HANDOVER MASTER CONTENT INFO”

message. This process is started only when the buffers of

the Slave are synchronized, then the Slave would detect the

delay of N bursts between Master and Slave. Then the

Slave would insert a delay of N time slice cycles (in the

case of the example it would be 2 time slice cycles).

Table 1. Example of possible burst sequences before synchronize frame transmission

Master Slave

Burst Time Burst Time

Z 0.0 B 0.0

A 2.0 C 2.0

B 4.0 D 4.0

C 6.0 E 6.0

D 8.0 F 8.0

Finally, once time and content synchronization is reached

Master and Slaves are constantly checking for possible

delays in order to be corrected by the process described.

5. RESULTS

The presented algorithm and architecture has been

implemented on a real IPE [3], [4]. The results of this work

have been tested in laboratory sessions measuring the

difference in time and content between Master and Slaves

for handover services.

The results presented here measure the histogram of the

synchronization time difference between Master and Slave.

The variation between the different modes is based on the

“HANDOVER SYNCHRONIZATION MARGIN”

parameter which is set from 5ms to 8ms in steps of 1ms.

Figure 3. Results of laboratory tests for time difference between

Master and Slave bursts in four modes.

Table 2. Results of laboratory tests

Test HANDOVER

SYNCHRONIZATION

MARGIN

Average

difference

(ms)

Standard

deviation

mode 1 5 ms 0,004 0,00276

mode 2 6 ms 0,002 0,00564

mode 3 7 ms 0,003 0,00325

mode 4 8 ms 0,004 0,00319

If time difference between Master and Slave bursts is below

this value then time synchronization state is assumed. In

Figure 3, mode 1, the most restrictive test, represents the

best result as it presents an average difference of 4ms

(<5ms) with the lowest standard deviation. Although mode

2 presents a smaller average difference between Master and

Slave bursts (2ms), it has the worst standard deviation

which means less stability in synchronization state.

6. CONCLUSIONS

This work has presented a proposal of architecture and the

algorithm to follow by IPEs in order to offer seamless

handover capabilities in DVB-H networks.

Although the presented architecture aims to be generic for

any IPE, it has been implemented on a real IPE and

laboratory tests have been performed. The results obtained

provide enough accuracy at delta-T announcement in Time

Slicing which validates the architecture proposed. The

results also prove that synchronization in content is also

possible by means of the proposed algorithm.

7. FUTURE WORK

Future works is planned to be in combination of statistical

multiplexing with handover capabilities in DVB-H

networks and also on vertical handover between DVB-H

and DVB-SH networks.

8. ACKNOWLEDGMENTS

This work has been developed in collaboration with the

Spanish company “SIDSA” in the scope of the FURIA

project (FIT-3305032-2006-6). We would like to thank

SIDSA and the Spanish “Ministerio de Industria Turismo y

Comercio” for its support in this work.

9. REFERENCES

[1] ETSI EN 302 304: “Digital Video Broadcasting

(DVB); Transmission System for Handheld Terminals

(DVB-H)”.

[2] Digital Video Broadcasting (DVB); IP Datacast over

DVB-H: Implementation Guidelines for Mobility,

ETSI, April 2007.

[3] Efficient IP Encapsulation in a DVB-H platform. A.

López and G. Fernández. Proceedings of IBC’2006,

Amsterdam, September 2006.

[4] Efficient media delivery over mobile terminals using

DVB-H. A. López and G. Fernández. Proceedings of

ISCE 2006, St. Petersburg, July 2006.