Network

IP DSLAM

Live Encoder

Middleware

VOD ServiceCA Service

ATU-R STB TV

ATU-R STB TV

ATU-R STB TV

IPTVNetwork

Channel changing in the IPTV networkwhy is it sometimes slow, is there any way to optimize the scenario？

What happens during zapping, overview

In the IPTV environment changing channels or zapping, has great importance as this is very often regarded as the most important parameter used to judge the overall quality of the network seen from the end user perspective. Changing channels in a terrestrial TV network usually takes about ½ - 1½ second compared to IPTV where zapping times of more than 2 seconds often are seen. Even 2 seconds is considered a long wait and if you have zapping time of maybe 4 seconds you are facing the risk of loosing customers in this fast pace global information environment we are living in today. Customers expect a high service level and information being delivered prompt to their screen.

What takes place when the button of the remote control is pressed down to change the channel on the TV screen？ By looking into the technical aspects of this process it will be easier to understand what can be done in order to lower down the zapping times. But as always fine tuning parameters may have certain drawbacks.

The foundation for most IPTV is multicasting or the process of sending just one single video stream to a number of simultaneous receivers in order for them to get the TV signal at the same time, like in terrestrial TV networks.

IPTVNetwork

MULTICAST Network

Every single router in the network will sign up in order to receive the multicast stream by sending out an uplink join message in order for the next router on the uplink path to be aware that it should forward the particular multicast TV traffic stream further down the path. This is the same process in the last mile on the customer end.

In the core network multicast routers use IGMP(v2) to learn which groups have members on each of their attached network interfaces. A multicast router keeps a list of multicast group memberships for each attached network, together with a timer for each membership. When a host receives a General Query, it will set delay timer for each group it is a member of at the interface from which it received the query. When a router receives a Report, it will add the group being reported to the list of multicast group memberships on the network it received the report from, and set a timer for the membership. When a host wants to join a multicast group, it transmits an unsolicited Version 2 Membership Report for that group, in case it is the first member of that group on the network.

Central Server Asset ManagementBusiness Rules Billing

MiddleWare systemSTB

NVOD / LiveTV / TVOD / KOD

Multicasting

IPTVNetwork

By pressing a new channel button on the remote control the STB will send out a message in order to let the network know that a particular traffic stream should end and a new need to begin.

The first message is the IGMP Leave Group send to IP address 224.0.0.2, after this the Edge router or DSLAM will ask if there are more hosts in the receiving end who want to continue to receive this particular traffic stream. This message will be repeated 3 times in total. The message is called IGMP Membership Query. This allows the multicast router or IP DSLAM to detect if the STB still wants to receive any (GENERAL QUERY) or a specific multicast stream (GROUP-SPECIFIC QUERY)

Next the STB will ask the Edge router or DSLAM to let it join the new group by sending out the Membership Report in order to let the STB join a new multicast group and to reply to a query message of a multicast router

The duration of this process is less than 1 second.

Changing channel

From the moment the client sends out the IGMP join message in order to start receiving the MPEG-2 information from the requested IGMP group IP address on the new channel a short pause will take place. This is what we like to refer as the network fly time.

It takes about 65 to 300mS before the MPEG traffic will start arriving at the STB. The MPEG-2 or MPEG-4 is transported in UDP datagram where each UDP packet can carry up to 7 single transport streams of each 188bytes.

The MPEG is a continuous traffic stream thus the STB Decoder needs to find a reference point in this stream where it may synchronize from and start the actual decoding.

As ISO-13818 recommendation, the point will be PAT table and its PID value is equal to 0. The arrival of PAT (timing rate) will depend on encoder’s configuration.

The PAT table is also the table containing all program information ensuring the consumer receives updated program changes. The PAT table lists all the programs in the transport stream and associates each program with another PID, that holds a program map table (PMT) as its payload. PMT then list the actual Video, audio and eventual encryption information.

Network fly time

PSI > PAT > PMTPAT

PID=0x00PMT

PID=PID 1PCR

PID=PIDpVideo

PID=PIDvVideo

PID=PIDvAudio

PID=PIDa1Audio

PID=PIDa2

IPTVNetwork

The output from an MPEG-2 video encoder is called an Elementary Stream (ES). An Elementary Stream can be broken into smaller data blocks called Packetized Elementary Stream (PES). This is send as UDP traffic and each UDP packet may contain up to 7 MPEG-2 transport streams.

The PES is also synchronized to a timing clock, that is set between 3 and 30Hz, again the time stamp is about 0,5 Sec resulting in a maximum waiting time of about 0, 6Sec before the PES may be synchronized.

Packets in the same elementary stream all have the same PID, in order for the STB decoder (or de-multiplexer) to select the elementary stream(s) it wants and reject the rest. A packet continuity counter ensures that every packet that is needed to decode a stream is received.

The sync byte always contains a value of hexadecimal 47 (decimal 71). Reason for this is the original MPEG2 offspring in ATM with a cell size of 53, five bytes being used for header leaving 48 bytes for data, one byte is for CRC and the remaining 47 bytes may be used for user data. When an unlocked MPEG-2 receiver read the 47h value, it then expects another sync byte to arrive 188 bytes later.

The last thing that needs to take place is for the VBV (Video Buffering Verifier) buffer, at the STB to fill enough so an actual picture may be displayed on the TV monitor. Depending on the buffer size settings this may take take up to 0, 7Sec in average.

PATPID=0x00

PMTPID=PID 1

PCRPID=PIDp

VideoPID=PIDv

PMT 0

PMT 1

PMT 2

(Program Association Table)

(Program Map Table)

PID0

PCR PID0

Video PIDv

Audio 1 PIDa1

Audio 2 PIDa2

ECM PIDe

PID1

PID2

PMT n PIDn

PAT

PMT

PayloadHeader PayloadHeader PayloadHeader

Payload

Elementary Stream = MPEG-4 format

PES

Bits 24 (0x000001) 8 16

Payload Payload

PayloadPES Header

Packet start code prefix Stream id PES packet length Optional Header

188 bytes

IPTVNetwork

After having studied all the steps involved in changing the channel it is easily understood that this is a complicated process and many things may go wrong or cause delay. Best case based on the above values will be a zapping time of 2,5 Seconds. Is 2,5 seconds a value that your customers can accept as a best case meaning that you should not be surprised of a zapping time of say 4 seconds？

The next natural question is what can be done in order to bring down the zapping time？

During the exchange of IGMP massages you might consider configuring the edge router or IP-DSLAM to send out one single membership query instead of the 3 queries it is sending out by default. Since there only is one STB in the other end listening for the IGMP messages chances that it will not receive this multicast message is rather small.

By reconfiguring from 3 to 1 IGMP membership query you may reduce the IGMP part of changing channels from about 700mS to just 100mS.

As the network fly alias the TS sync time may be in the area of 65mS to 312mS this also opens an adjustment possibility.

Next the PSI and PES rate could be changed in order to get the synchronization time to come down as well. This is done at the encoder on parameters as: GOP Length Option or PES Header Option(Per GOP or Per Picture)

IGMP Leave

Membership Query Membership Query Membership Query

IGMP Join

Video Stream Arrives

Zap Time

STB

Fine tuning ups and downs

IP DSLAM / Router

IPTVNetwork

In the drawing below you see the complete exchange of messages

IGMP Leave Group 224.1.5.8:11111 Display Off

Edge Router or IPDSLAM

Network fly time

TS Sync time

PES Sync time

Filling VBV buffer

Display On

( 710ms)~~

( 100ms)

( 732ms)

~~

( 1~250ms)~~

( 1~300ms)~~

~~

( 65ms)~~

Membership Query

Membership Query

Membership Query

IGMP Join Group 224.1.5.10:11111

Arrival of First Packet

vbv_buffer / video_rate

PATPSI Rate=4Hz

PESPES Header Rate=3~30Hz

Zap Time

STB

}}}}

ANACISE TESTNOLOGY CORP.Fl. 3, No. 3, Alley 112, Ruei-Guang Rd., Neihu Dist., Taipei 114, Taiwan, R.O.C.

Tel : +886-2-2792-8880Fax : +886-2-2792-8058

E-mail : sales@anacise.comWeb : www.anacise.com

ANACISE TESTNOLOGY is a Taiwan-based company with HQ office in Taipei. We are at the forefront of helping our customers shape the changing broadband convergent technology landscape.

AnaCise's solutions enable network operators and service providers to better meet increasing demands for network availability and services. We accomplish this by providing market-driven test, measurement and monitoring solutions that accurately verify network performance, thus ensuring perfect telecommunications network planning and service continuity.

About AnaCise