Final Project Report (2)

Final Year Project

Channel Zapping Latency Reduction in IPTV Systems Final Year Project Report

Muhammad Zeeshan Ahmad BICSE 3

Nabil Ur Rehman BICSE 3

Final Year Project: Mid Defense Report Channel Zapping Latency Reduction in IPTV Systems

1

CERTIFCATE

It is certified that the contents and form of project report entitled “IPTV Channel

Zapping Latency Reduction using User Profiling and Channel Prediction”

submitted by Muhammad Zeeshan Ahmad and Nabil Ur Rehman has been found

satisfactory for the requirement of the degree.

Advisor: ___________________

Dr. Junaid Qadir

Co-Advisor: ___________________

Dr. Adeel Baig

Co-Advisor: ___________________

Dr. Hammad Majeed


2

DEDICATION

In the name of Allah, the Most Gracious, the Most Merciful

To Our Parents

&

Our Teachers


3

ACKNOWLEDGEMENTS

First of all we would like to pay our humble gratitude to Allah Almighty who

blessed us with His kindness to complete this project.

We are extremely thankful to Dr. Junaid Qadir for his support, keen interest

and supervision. We acknowledge the extreme involvement of our co-advisors Dr.

Adeel Baig and Dr. Hammad Majeed. Their valuable assistance, suggestions and

guidance helped us a lot in completing this project. We would like to express our

gratitude to Mr. Owais Malik for his valuable time and guidance to improve the

project.

We our extremely thankful to everyone who has a share in teaching and

grooming us during past four years of the degree. We are also thankful to PTCL NUST

CISCO Center of Excellence for IP Technologies and NUST School of Electrical

Engineering and Computer Science, Pakistan, for providing us with the opportunity to

enhance our technical skills by providing us with the superb environment for

learning.


4

Contents

LIST OF FIGURES ...................................................................... 6

LIST OF TABLES ....................................................................... 7

LIST OF ABBREVIATIONS ............................................................. 7

ABSTRACT .............................................................................. 8

1 INTRODUCTION ................................................................... 9

1.1 IPTV .......................................................................................................... 10 1.1.1 History ............................................................................................................................ 11 1.1.2 IPTV Architecture........................................................................................................... 11 1.1.3 How IPTV Works ............................................................................................................ 13

1.2 Major Challenges for IPTV ........................................................................ 14 1.2.1 Quality of Experience (QoE) .......................................................................................... 14

1.3 Zapping Time ............................................................................................ 14 1.3.1 Typical Channel Switching Process ............................................................................... 15

1.4 Current Market Trends ............................................................................. 15

2 RELATED WORK ................................................................. 17

2.1 Literature Survey ...................................................................................... 18 2.1.1 Factors involved in Zapping Time ................................................................................. 18 2.1.2 Approaches to reduce zapping time ............................................................................. 20

3 USER PROFILING AND CHANNEL PREDICTION .............................. 25

3.1 User Profiling ............................................................................................ 26

3.2 Channel Prediction ................................................................................... 27

3.3 Why Use User Profiling and Channel Prediction for IPTV Channel Zapping

Latency Reduction? ............................................................................................. 28

3.4 Literature Survey ...................................................................................... 28 3.4.1 IPTV viewing habits ...................................................................................................... 28 3.4.2 Approaches Studied ...................................................................................................... 32

3.5 Proposed Approach for User Profiling and Channel Prediction ............... 37


5

4 PROPOSED SOLUTION .......................................................... 40

4.1 Introduction.............................................................................................. 41 4.1.1 Architecture .................................................................................................................... 41 4.1.2 Working ......................................................................................................................... 43

5 IMPLEMENTATION ............................................................... 46

5.1 Quest for IPTV Simulators ........................................................................ 47 5.1.1 MythTV® ....................................................................................................................... 47 5.1.2 WatchiTV ....................................................................................................................... 48 5.1.3 Other Players ................................................................................................................. 49

5.2 Designing a Test Bed ................................................................................. 52 5.2.1 Why VLC? ...................................................................................................................... 52

6 RESULTS .......................................................................... 70

6.1 Learning and Experiences......................................................................... 71

6.2 Future Work ............................................................................................. 74

7 CONCLUSION ..................................................................... 75

8 BIBLIOGRAPHY ................................................................... 77


6

List of Figures FIGURE 1-1: TRADITIONAL IPTV ARCHITECTURE (5) ............................................................................................ 12 FIGURE 2-1: IGMP FLOW OF ADJACENT CHANNEL JOIN-LEAVE METHOD (15) .................................................... 21 FIGURE 2-3 FIGURE 2-4: BANDWIDTH ALLOCATION POLICY IN PREVIEW AND WATCHING MODE. BN IS

THE NTH BASE LAYER AND EN IS THE NTH ENHANCEMENT LAYER. ................................................................... 22 FIGURE 2-2: WORKFLOW USING RATING SERVER (15)......................................................................................... 22 FIGURE 2-5: WORKFLOW OF CONVENTIONAL IPTV SERVICE ............................................................................... 23 FIGURE 2-6: WORKFLOW WITH H.264 SCALABLE VIDEO CODING ........................................................................ 24 FIGURE 3-1: IPTV ARCHITECTURE ....................................................................................................................... 41 FIGURE 4-1: UNICAST USING VLC – NETWORK TOPOLOGY .................................................................................. 52 FIGURE 4-2: VLC PLAYER ................................................................................................................................... 53 FIGURE 4-3: OPENING A FILE .............................................................................................................................. 53 FIGURE 4-4: DIALOGUE BOX TO ENTER THE PORT NUMBER THROUGH WHICH THE UNICAST TRAFFIC

WILL PASS. .................................................................................................................................................. 54 FIGURE 4-5: AT SERVER, DIALOGUE BOX TO SET IP ADDRESS OF UNICAST RECEIVING CLIENT. .............................55 FIGURE 4-6: AT CLIENT SIDE, OPENING THE UNICAST STREAM BEING TRANSMITTED BY SERVER. ........................ 56 FIGURE 4-7: ENTER THE PORT NUMBER ON WHICH THE UNICAST STREAM IS BEING TRANSMITTED

FROM SERVER. ............................................................................................................................................. 56 FIGURE 4-8: MULTICASTING (28) ........................................................................................................................ 57 FIGURE 4-9: MULTICAST USING VLC – NETWORK TOPOLOGY ............................................................................. 58 FIGURE 4-10: OPENING A FILE FOR MULTICAST STREAMING ................................................................................ 59 FIGURE 4-11: DIALOGUE BOX .............................................................................................................................. 59 FIGURE 4-12: BROWSING A FILE TO STREAM ........................................................................................................ 60 FIGURE 4-13: ASSIGNING THE MULTICAST IP ADDRESS FOR STREAMING TO A PARTICULAR MULTICAST

GROUP .......................................................................................................................................................... 61 FIGURE 4-14: STREAM BEING TRANSMITTED TO MULTICAST GROUP ..................................................................... 62 FIGURE 4-15: OPENING THE NETWORK STREAM .................................................................................................. 62 FIGURE 4-16: ENTERING THE MULTICAST IP ADDRESS WHICH THE CLIENT SHOULD JOIN TO RECEIVE

MULTICAST STREAM .................................................................................................................................... 63 FIGURE 4-17: MULTICAST STREAM IS BEING DISPLAYED AT CLIENT‟S SYSTEM ....................................................... 64 FIGURE 4-18: FOUR DIFFERENT STREAMS BEING RECEIVED BY THE CLIENT AT HIGH QUALITY AND THE

AVERAGE BIT RATE OBSERVED IN THIS CASE WAS 5.215 MBITS PER SEC ........................................................ 65 FIGURE 4-19: OUR DESIGNED APPLICATION, WHICH USES VLC‟S FUNCTIONALITIES AND ACTS LIKE A

SET TOP BOX............................................................................................................................................... 66 FIGURE 4-20: SIMPLIFIED ARCHITECTURE OF OUR TEST BED IN CASE OF INTERNETWORK

TRANSMISSION. ........................................................................................................................................... 67 FIGURE 6-1: TIMELINE OF OUR FUTURE TASKS ............................................. ERROR! BOOKMARK NOT DEFINED.


7

List of Tables TABLE 2-1: COMPARISON BETWEEN CHANNEL ZAPPING REDUCTION TECHNIQUES ............................. 24 TABLE 3-1: COMPARISON OF USER PROFILING AND CHANNEL RECOMMENDATION TECHNIQUES ..... 37

List of Abbreviations IPTV Internet Protocol Television

QoE Quality of Experience

IGMP Internet Group Management Protocol

RTP Real Time Transport Protocol

VoD Video on Demand

DSLAM Digital Subscriber Line Access Multiplexers

STB Set Top Box

RAP Random Access Points


8

Abstract Internet Protocol Television – IPTV is a new form of traditional TV, in which TV

content is delivered using IP based networks which are managed to provide the

required level of quality of service and experience, security, interactivity and

reliability. Quality of Service (QoS) and Quality of Experience (QoE) are the two

major factors which need to be ensured in order to achieve IPTV customer

satisfaction. Channel zapping latency is the major problem which affects QoE for

IPTV users. In IPTV systems while switching channels, a delay occurs due to different

factors like IGMP Join/Leave latency, video steam encoding and decoding time,

network jitter and traffic load. These factors hinder the process of IPTV deployment at

large scale and pose scalability issues to IPTV. In order to solve IPTV channel zapping

latency problem, a number of approaches have been contributed by different

researchers but due to bandwidth limitation and video quality issues, every approach

has its own tradeoffs. In this report, an approach has been proposed which uses user

profiling and channel prediction along with video stream encoding at low bitrates.

The proposed approach, predicts some channels based on user profiles, which are

created based on user TV viewing history, and transmits predicted channels at low

bitrates, along with the requested channel. Proposed solution is still in its

development and implementation phase, so findings and contributions to the

problem domain so far, have been discussed in this report.


9

1 Introduction

In this chapter, we will discuss the basics

and pre requisites about Internet Protocol

Television - IPTV and related problem domain,

which a reader should know before proceeding

to further chapters. We will discuss a brief

history of IPTV, its architecture, introduction to

the problem domain i.e. channel zapping latency

in IPTV systems and major challenges to

deployment of IPTV at large scale.


10

1.1 IPTV

Since the conception of internet, its demand in every application is growing day

by day. No wonder, like every other services television is also getting attention. IPTV

is not a new concept as such. Early days of internet did not have enough bandwidth to

support entertainment quality media delivery. Hence Broadcast over IP network did

not become popular. The recent advancement in communication network and in

media compression techniques has now enabled network delivery of high quality

content.

Internet Protocol Television is a new form of television technology that uses the

existing IP network to deliver entertainment grade audio-video content to consumers.

[1] It uses video compression techniques to reduce the data to be transported to the

end user. And the compressed digital media is then transported to end users over a

standard IP network which is already in place for data services. This is called in

industry terms, Triple Play. Data, Voice and Video these three are the components of

the service. IPTV falls into the category of Video. The Key promises of IPTV System

are,

Integrated Service: Consumers prefer a reliable one-stop service from a

trusted provider.

Flexibility: Since the underlying infrastructure is general network the upper

layer is possible to be modified and altered without fiddling with the base.

Low Cost: IPTV Service being built on top of the existing data network

infrastructure the deployment cost is low.

As the border between broadcasting and IP communication is indistinct, the

convergence between broadcasting and IP communication is getting faster and faster.

IP communication companies recently attempt to advance to broadcasting market in

corporation with broadcasting or movie companies. Broadcasting and cable

companies are entering into high-speed internet service business. IPTV can support

not only passive broadcasting service but also active, intelligent and bidirectional

services such as VoD (Video on Demand), T (Television)-Commerce. Therefore IP

communication companies expect that IPTV will be the representative service which

can find a means of another huge earning. [2]


11

1.1.1 History

CU-SeeMe Video Conferencing Software1 enabled ABC‟s World News Now to

be the first television show broadcast over the internet in 1994. First live webcast was

started by Internet radio company AudioNet in January, 1998. [3]

In 1995, the term IPTV first appeared with the founding of Percept Software.

Precept designed and built an internet video product named "IP/TV". IP/TV was an

MBONE2 compatible Windows and UNIX based application that moved single and

multi-source audio/video traffic, ranging from low to DVD quality, using both unicast

and IP multicast RTP/RTCP.

In September 1999, a regional telecommunications operator in UK named

Kingston Communications, launched KIT (Kingston Interactive Television), an IPTV

over DSL broadband interactive TV service after conducting various TV and Video on

Demand (VoD) trials. The operator added additional VoD service in October 2001

with Yes TV. Kingston was one of the first companies in the world to introduce IPTV

and IP VoD over ADSL.

In 2006, AT&T launched its U-Verse IPTV service, comprising a national head

end and regional video-serving offices. AT&T offered over 300 channels in 11 cities

with more to be added in 2007 and beyond.

On March 2009, AT&T announced that U-verse had expanded to 100 or more

High Definition channels in every U-Verse TV market. While using IP protocols,

AT&T has built a private IP network exclusively for video transport. [4]

1.1.2 IPTV Architecture

Figure 1-1 illustrates generic IPTV system architecture to support applications

such as digital (broadcast) television and Video on Demand (VoD). This architecture

is based on the comprehensive architecture and services model specified in ITU

Recommendation H.610 and on the IPTV platform offered by industry leaders such as

Microsoft® Corporation.

1 CU-SeeMe is an Internet video-conferencing client. CU-SeeMe can make point to point video calls without a server or make multi-point calls through server software first called a "reflector" and later called a "conference server" or MCU. 2 Mbone (short for "multicast backbone") was an experimental backbone for IP Multicast traffic across the Internet. It is a virtual network built on top of the Internet; Invented by Van Jacobson, Steve Deering and Stephen Casner in 1992. The purpose of MBONE is to minimize the amount of data required for multipoint audio / video-conferencing.


12

Figure 1-1: Traditional IPTV Architecture [5]

1.1.2.1 Content Sources

It represents a functionality that receives video content from producers, and

other sources, encodes the content and, for VoD, stores content in an acquisition

database.

1.1.2.2 Service Nodes –

It represents a functionality that receives video streams in various formats,

then reformats and encapsulates them for transmission with appropriate Quality of

Service (QoS) indications to the wide-area network for delivery to customers. Service

Nodes communicate with the IPTV service for the subscriber, session and digital

rights management.

1.1.2.3 Wide Area Distribution Networks

This provides the distribution capability, capacity, quality of service and other

capabilities, such as multicast, necessary for the reliable and timely distribution of

IPTV data streams from the Service Nodes to the Customer Premises. The Core and

Access Networks include the optical distribution backbone network and the various

Digital Subscriber Line Access Multiplexers (DSLAMs) located at the central office or

remote distribution points.

1.1.2.4 Customer Premises Equipment (CPE)

In the IPTV context, the CPE device located at the customer premise provides

the broadband network termination (B-NT) functionality at a minimum, and may


13

include other integrated functions such as routing gateway, set-top box and home

networking capabilities.

1.1.2.5 IPTV Client

The IPTV Client is the functional unit, which terminates the IPTV traffic at the

customer premises. This is a device, such as a set-top box, that performs the

functional processing, which includes setting up the connection and QoS with the

Service Node, decoding the video streams, channel change functionality, user display

control, and connections to user appliances such as a standard-definition TV or

HDTV monitors [5].

1.1.3 How IPTV Works

In standard broadcast systems all of the channels are delivered to the STB in

the home (via Cable, Satellite or Terrestrial). There could be hundreds of channels, all

of which are delivered simultaneously. The STB tunes to the desired channel in

response to requests from the viewer‟s remote control. As a result of this local tuning

the channel changes are almost instantaneous. In order to preserve bandwidth over

the final link to the house, IPTV systems are designed to deliver only the requested

channel to the STB. In order to change channels, special commands are sent into the

Access network requesting a change of channel. There is a complex protocol exchange

(using IGMP “Leave” and “Join” commands) associated with this technique. This

exchange requires a finite time to complete and the time taken is heavily influenced

by transmission delays in the network which in turn has a direct impact on the

channel change timings of the system. In essence, in IPTV systems the channel

change is made in the network and not on the local STB. While preserving precious

last mile bandwidth this approach presents a number of challenges to the scalability

and usability of the system.

Broadcast TV makes use of IP Multicasts (and IGMP as mentioned) to deliver

the programming efficiently through the IP system. A Multicast is designed to allow

multiple users simultaneous access to the session. VoD employs unicast IP services

using the RTSP control mechanism. At the request of the viewer, the selected

programming is located from within the network (from a server) and a unique unicast

is setup to deliver the program to the user. This is in effect a private network

connection between the server and the viewer‟s STB. [6]


14

1.2 Major Challenges for IPTV

1.2.1 Quality of Experience (QoE)

The most important QoS metric that needs to be addressed in an IPTV

application are Delay and Packet Loss. For a pleasurable user experience the

requirements are quite stringent in this case. The metrics are more appropriately

termed as Quality of Experience (QoE). The main QoE parameters for any IPTV

platform can be classified into following categories.

1.2.1.1 Channel Switching

It refers to the delay between a new channel request and its display on the

monitor. Study shows the acceptable delay between a channel request by the user and

the appearance of the frame on the screen is 200 ms [2]. This will be discussed in

more detail in the following section.

1.2.1.2 Media Quality

The Quality of the media delivered, i.e. Sound and Video is of utmost

importance. Especially in a market where already conventional digital cable offers

High Definition (HD) content. For a standard entertainment quality experience one

can have no more than a single visual degradation over a period of 2 Hour.

1.2.1.3 Stability

The stability of the service is also very important as Television is one of the

most common forms of near real time applications. [7]

1.2.1.4 Security

Suitable access control and piracy prevention has to be ensured.

1.3 Zapping Time

Channel switching delay or channel zapping time is one of the key factors that

has been bothering service providers from the beginning of IPTV concept. It is still

hindering the process of large scale commercial deployment. In this section we will

describe the process of changing channel in a typical IPTV installation. Then we will

discuss the weak links in the process that is the source of the delays. In telephone

service, the call setup time has always been there. But TV has always presented the


15

users with the ability to switch channel instantaneously. Having that scenario, IPTV

cannot have an annoying blank in between channels.

1.3.1 Typical Channel Switching Process

There are a number of sequential steps involved in the process of switching

channel while watching television. [8]

User initiates a request.(Usually in the form of a button press on the remote)

If the channel is NOT already being transmitted to the STB (Set Top Box), it

translates the request into an IGMP Leave request and send to the network.

The End router responds with a IGMP Query or forwards the Leave message

to upper level routers. This continues till the server end is reached.

Next, the STB sends an IGMP Join request. It also propagates in the same

fashion.

Server node prepares a new stream for the requested channel and begins

transmission of the stream.

STB receives the stream from the network, performs buffering, decoding and

sends the picture to the television.

1.4 Current Market Trends

The market research report “Global IPTV: Market Analysis and Forecast to

2011” evaluates the current market trends of IPTV technology. It provides extensive

research and objective analysis of the global IPTV market, its performance and its

future prospects by analyzing the trends and developments in IPTV market across

different geographies, including Europe, North America and Asia-Pacific Regions.

The report is a work of thorough research on the global IPTV industry and

examines global as well as regional IPTV subscriber base, service revenue, ARPU,

broadband subscribers, and IPTV households among other market elements.

The key findings of this market analysis report are:

1. Currently, Europe is the largest and most active IPTV market but in future,

Asia-Pacific is expected to leave it behind as it will grow in terms of

subscribers, service revenue, infrastructure etc. The broadband penetration of

the region will fuel the growth.


16

2. American market is expected to be the most competitive IPTV market in the

world largely due to high existing pay-TV penetration, stiff prices and service

competition.

3. The worldwide IPTV subscribers are forecasted to reach to 103 Million in 2011

in which Americas and Western Europe are expected to be the biggest markets

on revenue per user basis.

4. Deployment of IPTV has been spurred by the explosion of broadband in

various high growth markets across the globe, such as Asia-Pacific. Along with

this, innovation, convergence and changing consumer behavior in North

America are working as driving forces for the IPTV industry. [9]


17

2 Related Work

In this chapter, we will discuss different

contributions made by other people in this

domain. As discussed in the previous chapter,

QoS and QoE are one of the major challenges for

IPTV. In order to deploy IPTV at a large scale

commercially, a satisfactory QoE and QoS has to

be achieved. Different contributions have been

made in this regard, but every approach has its

own tradeoffs. We will review and cite a number

of related later in this chapter.


18

2.1 Literature Survey

An extensive literature survey was carried out so that we could familiarize

ourselves with the problem domain and the latest advancements made so far. We will

discuss different approaches to achieve the goal of enhancing the QoS and QoE in

IPTV networks. There are a number of factors involved which cause channel zapping

latency. Those factors are discussed below.

2.1.1 Factors involved in Zapping Time

The delay between a user initiating a channel zapping request i.e. a user

pressing a button on remote control and the content actually being rendered on user‟s

monitor or TV screen, consists of different processing throughout IPTV network and

Set Top Box. Those major factors have been documented by Herald et al. [10] which

we will cover in the following section.

2.1.1.1 IGMP session joining for multicast delivery

Clients that want to join a multicast session indicate their interest by sending a

control packet (IGMP) [11] to the next router. If the multicast stream is not yet

available there, the router in turn sends the request to the next one. This is done until

the multicast stream is found and then the stream is forwarded down the chain.

Depending on the network architecture, this find-and-forward process can take up to

several hundred milliseconds but is typically below 100 ms. [12] [13]

2.1.1.2 Client stream buffering (network de-jitter buffer, video input buffer)

A delay occurs during the time the client fills its buffer before starting to

render. This delay is in the range of 0.5 to 2 seconds.

2.1.1.3 Random access point acquisition

I-frames serve as Random Access Points (RAP) to the stream where decoding

can be started. A delay occurs when tuning into a new stream, since the client has to

wait for a RAP to arrive before it can start decoding and displaying video. The delay

introduced by RAPs is in the range of 0.25 to 2 seconds.

2.1.1.4 Audio-video synchronization

In RTP streaming, every media, such as audio or video, is sent as a separate

elementary stream. To synchronize these streams, their timestamps have to be

related. This is done through RTCP sender reports that are sent periodically in


19

addition to each media stream. The sender reports link the media clock domain (the

RTP timestamps) with a clock domain common to all streams. At least one RTCP

sender report has to be acquired for each stream, to allow synchronized play-out of

the streams. The frequency and timing of RTCP reports also influence the initial play-

out delay, because many clients may not start rendering before synchronization has

been established. Following the recommendations of RFC 3550 [14] the RTCP sender

interval is about 0.25 seconds for a 1.5 Mbps media stream. However, this

recommendation can be further reduced in a system specification if required.

2.1.1.5 Mechanisms to minimize impact of packet-loss (forward-error

correction or re-transmission)

Additional delay is introduced, if re-transmission or Application Layer

Forward Error Correction (AL-FEC) is used to handle lost RTP packets. The AL-FEC

is typically applied to a block of packets to minimize overhead and increase the

interleaving depth. Packet loss within such a block can be compensated by the

additionally transmitted FEC data. To be able to use that data, decoding has to be

delayed until all packets of a block are received.

2.1.1.6 Key acquisition times in case of scrambled content.

If the content is encrypted, then the decryption keys must be acquired.

Generally it is not desirable to distribute keys too far ahead of need. An additional

delay introduced by the key management occurs, if the key for the initial I frame does

not arrive during the client buffering and random access point acquisition delay.


20

2.1.2 Approaches to reduce zapping time

Several approaches to overcome channel switching latency problem, have been

reviewed during literature survey. A comparison between these schemes has been

given later in this section.

Cho et al. proposed “Adjacent Group Join-Leave Method” for reducing

channel zapping latency. This method is based on an assumption that the bandwidth

of the access network between LHR and home gateway is large enough to accept

several TV traffic simultaneously. When IP STB requests join to new channel by

sending IGMP membership report message, home gateway sends not only IGMP

membership report message for the channel but also for the adjacent channels.

Therefore multicast stream for adjacent channels of current one always come to home

gateway. When IP STB requests join to adjacent channel, home gateway can forward

the corresponding multicast traffic immediately. [8] This approach can be helpful

only in the case when user switches to adjacent channels. It does not support random

channel change and offer the same amount of zapping latency as before. Moreover

this approach also requires large bandwidth for access network and it also needs

home gateway which has IGMP proxy function and it‟s useless for subscribers who

have only IPTV STB not home gateway. So, this approach is not a generic solution to

channel zapping problem.


21

In [15], Lee et al. refined Cho et al.’s work to make it support the random

channel selection. In this work, it is proposed that settop box instead of home gateway

manages adjacent channel multicast group list and handles IGMP Join and Leave

operation for adjacent channels. To reduce channel zapping time to random channels,

settop box queries expected channel list to rating server and handles IGMP Join and

Leave operation for the expected channels. Rating server gathers channel change

event from settop boxes and manages statistics for each settop box. In this method,

the adjacent channels are not only those channels which are physically adjacent to the

current channel, rather these are the expected channels which are most likely a user

can watch. If rating server receives a query message from a settop box, it obtains

expected channel list from managed statistics and responses the list to the settop box.

Settop box can obtain its expected channel information of specific time zone by

sending a query message to rating server periodically. This approach has advantage

over Cho et al.’s proposed approach by enabling random channel changing. But

tradeoffs attached with this approach are larger bandwidth for access network and

cold starting of rating server‟s expected list generation, as it needs to learn the user

interests over a reasonable period of time.

Figure 2-1: IGMP flow of Adjacent Channel Join-Leave Method [15]


22

In [16], a technique which involves H.264 scalable video coding has been

proposed in which the channels are split into two types of layers.

Base Layer

Enhancement Layer

Figure 2-3 Figure 2-4: Bandwidth allocation policy in preview and watching mode. Bn is

the nth base layer and En is the nth enhancement layer. [16]

Base Layer is actually the channel stream with H.264 scalable video coding. It

reduces the bitrate of channel stream and allows more channels to be transmitted at

the nearly same bandwidth required to transmit one high quality channel stream.

Enhancement Layer is the stream with high bandwith. It enhances Base Layer

that‟s why it is called Enhancement Layer.

These layers are used in different modes defined as

Figure 2-2: Workflow using Rating Server [15]


23

Preview Mode

Watching Mode

In preview mode, the base layers of several channels are transmitted

simultaneously and thus switched instantaneously between them. In normal watching

mode, the IPTV STB receives both layers and combines them to produce full-quality

video. When the user changes channel, the STB enters preview mode. Bandwidth is

then allocated to other channels to reduce the zap-time at the expense of picture

quality.

In preview mode, the base layer of the current channel is transmitted to the STB

and low-quality video is displayed. The channel manager also starts accumulating

base layer packets for these channels, which the user is deemed likely to select next, in

a channel pool. In preview mode, switching within the channel pool occurs

immediately. Then, when the channel manager decides that the user is likely to watch

the current channel for a while, the multiple base layers are replaced with the

enhancement layer to restore full picture quality. Change from watching to preview

mode takes less time than a change of channel at full quality.

Figure 2-5: Workflow of conventional IPTV Service [16]


24

Figure 2-6: Workflow with H.264 scalable video coding [16]

Experimental results using H.264 SVC confirm that fast channel switching can be

achieved with minimal loss of picture quality during normal viewing.

2.1.2.1 Comparison Between Above Discussed Schemes

Approach Bandwidth

Consumption

Video

Quality

Adjacent

Channel

Selection

Random

Channel

Selection

Adjacent Channel

Join/Leave (Cho et al.) High Good Yes No

Advanced Scheme to

Reduce IPTV Channel

Zapping Time (Lee et al.)

High Good Yes Yes

Reducing IPTV Channel

Switching Time Using

H.264 Scalable Video

Coding (Younghee et al.)

Lesser than

other two

Reduced

video

quality

May be

(Based on

the pool of

channels)

Yes

Table 2-1: Comparison between channel zapping reduction techniques


25

3 User Profiling

and Channel

Prediction

In this chapter, we will discuss different

techniques which have been contributed by

other researchers. We will also discuss how we

can use those techniques in our approach.


26

3.1 User Profiling

User profiling is a process of aggregating information about a user‟s personal

interests and making user profiles. User profile provides information about different

attributes that a user has. It is a computer representation of a user model which stores

description about user‟s characteristics. User profiles are very useful for many

different purposes in different applications. User profiling is used mostly in the

applications with human-computer interaction.

Online social networking websites, video sharing websites, search engines,

online auction and shopping websites etc. use user profiling to monitor the user‟s

activity and record their preferences in their user profiles to recommend the content

in which they are interested. Use of these techniques, is becoming very popular these

days because it enhances the interactivity for the users and bring the service providers

more revenues.

In case of IPTV, user profiles can be generated to store information about

user‟s interests, subscription packages, user‟s preferences and IPTV viewing behavior.

We can exploit the advantages of user profiling and channel prediction to reduce

channel zapping latency. We can keep monitoring the user‟s activity and record his

preferences in his user profile. Based on this information the viewing behavior can be

extracted and then channels can be predicted and pre-joined. To build user profile for

IPTV, we need to determine which data should be collected and how should we

process that data to get meaningful user profiles. There are different types of data

which can be collected and processed which are as follows:

Temporal and time-series database:

A temporal database is different from a traditional database. In a

temporal database every item has a time related value associated with it. The

association between temporal data items is more informative and meaningful.

For example if a person watches a certain channel x and jumps to channel b,

there is a basic association between both values and we can represent this

information as (channel x -> channel y) but if this information is stored in a

temporal database both channels will have some time related information

associated with them. So, we can get more insight from this data such as user

jumps from channel x to channel y during 12 pm to 1 pm daily. So this kind of

information can be stored in a user profile and based on this information our


27

system can pre-join the channel y‟s stream when user is watching channel x

during 12 pm to 1 pm. Temporal data gives us user‟s activity patterns which

can be used to determine user‟s habits of IPTV viewing.

IPTV Content and Usage Data:

There are different metrics which can be used to a user profile for

channel prediction. This data can be obtained through IGMP group JOINs and

LEAVEs. Information available in EPGs can be used to determine the genre of

the requested content which can further provide insights into user‟s interests.

Other channels having the same genre and similarities in the information

provided in EPG are also known and can be added to predicted channels list.

Usage of IPTV traffic can be monitored by following factors

o How long a channel was viewed

o What time was the channel changed

o What channel was requested

3.2 Channel Prediction

Channel prediction is the process of predicting those channels which the user is

most likely to watch. Those predicted channels are then pre-joined by the IPTV Home

Gateway. A strong channel prediction mechanism will lead our proposed approach to

useful results. User profiles are used to get the information about the user and based

on that information the content can be predicted. The term channel prediction is

same as channel recommendation or content recommendation. Recommender

systems also predict the content that would match a user‟s interests.

In our proposed approach, we consider following factors in order to make an

IPTV channel prediction.

1. Viewing Duration of particular channel/program

2. Frequency of channel switching

3. Viewing Time/Day of particular channel/program

4. Popularity of Programs/channels varying over time.

5. User preferences explicitly provided by user at the time of registration with

IPTV provider


28

This information can be obtained by monitoring user‟s IPTV viewing behavior

over the time and developing a system which keeps on evolving. The more

intelligent the systems is, the more accurate prediction it can make.

There are different techniques which can be implemented in order to develop

the learning ability of the system. Those techniques are called machine learning

techniques. Learning is the ability of the system through which it evolves over the

time. We have done some literature survey and our observations are discussed in

the later sections.

3.3 Why Use User Profiling and Channel Prediction for IPTV

Channel Zapping Latency Reduction?

As discussed earlier, there are number of factors which cause delay. Many of

those factors are inherent in IPTV and cannot be eliminated completely. So there is

need of some other solution which behaves independent of the underlying network

and those inherent factors. User Profiling and Channel Prediction gives a new

dimension to the solution of IPTV channel zapping latency problem. We can monitor

user‟s IPTV viewing behavior, aggregate user‟s preferences, build user profiles and

based on that information predict the channels which can be pre-joined. Once the

channels are pre-joined, a user will experience lesser zapping latency while switching

to a predicted channel.

A lot of research has also been done in the field of IPTV content

recommendation and that can be used as base for IPTV channel prediction.

3.4 Literature Survey

We have gone through different contributions made by other researchers in this

domain and studied different research papers which elaborate on the IPTV user

profiling and content recommendation. In this section we list down different

approaches studied and in the end mention their pros and cons.

3.4.1 IPTV viewing habits

In this section, we will present results of IPTV viewing habit presented in a

recent paper [17] which utilized a huge collection (over 200 GB worth of traces) of

IPTV channel switching logs from an operational backbone provider. Import findings

and terminologies discussed in this paper are discussed in the following section


29

Channel holding time:

Holding times is defined as the time between channel switching. Channel

holding time which represents viewers‟ attention span is affected by the program

length, advertisement intervals, and viewer‟s interest Figure 3-1 shows the Channel

Distribution Function of channel holding times, where the slope of curve changes

around 10 seconds and again around 1 hour, indicating different users‟ modes such as

surfing, viewing, or away. Accordingly, we consider channel holding times shorter

than 1 hour as active periods and those longer than 1 hour as inactive periods. As most

of the TV programs have short time interval between advertisements (on average 30

minutes), we expect the impact of program duration on channel holding time to be

low. Based on the defined notion of user activeness, it was observed that an average

user watches TV 2.54 hours a day and browses 20 channels.

Figure 3-1: Channel Holding Time

Channel Popularity:

Channel list can also be predicted on the basis of the most watched or favorite

channels of a particular region. Viewership of popular channels increases and

decreases monotonically with time. Viewership is maximum at prime time i.e. from

8pm to 10pm whereas it is very less in morning time when usually channels show

repeat telecasts. Figure 3-2 plots channel rankings against the number of viewers. The

distribution is Zipf-like for popular channels, and the popularity decays almost

exponentially for non-popular channels (ranked 30th or below).


30

Figure 3-2: Zipf-like (or 80-20 rule like) popularity

Temporal Correlation:

Figure 3-3 shows the time-of-day trend on the number of viewers. We

consistently observe strong peaks for particular times of day (e.g., 3 PM, 10 PM),

indicating that a significant fraction of users are correlated about when they watch

TV.

Figure 3-3: Number of viewers over time

Zooming Into Per-Program Viewing Behavior: Figure 3-4 Shows the viewer

share of the final match of the European Champions League. The program had four

semantic parts: first half, halftime, second half, and the award ceremony. A significant

fraction of viewers leave the channel during half-time and re-join later, reflecting

strong correlation in their behaviors. Also observe many viewers join or re-join the

program after the beginning of each part. We can predict TV channels/programs for


31

viewers based on these results. For example viewer having interested in sports would

most probably watch football match after 2nd half has started. So this factor could also

be taken into account while predicting a list of channels for a particular viewer.

Figure 3-4: Number of viewers over time

Channel sampling:

When watching television, people browse through a set of on-air programs

until they find something interesting [18]. Channel selection while listening to the

radio is similar; listeners sample and switch across multiple radio stations. Channel

selection involves two steps:

Sampling the content to decide whether to continue or stop watching the

channel.

Switching across multiple channels for repeated sampling until a desired

channel is found.

Consider a TV viewer changing channels after watching them for 5, 3, 10 seconds, and

20 minutes. We may interpret that the user sampled four channels before finding

something interesting. The problem of quickly finding the right channel becomes

harder as the number of channel offerings grows in modern IPTV systems.


32

Figure 3-5: Channel Sampling

Cha et al. have recently proposed a „hot list‟ approach to reduce unnecessary

channel sampling which will improve user experience by reduction in channel

zapping latency [18]. “Hot list” – a list of channels based on the real-time popularity

of content and the user‟s past streaming history– is generated to allow users to switch

amongst the channels recommended in the hotlist. In IPTV, this can be realized as an

alternative way to change channels, compared to the conventional linear (up or down)

changes. We have already seen that top channels in TV systems generally have a Zipf-

like popularity [19]. As users surf through the hotlist, they are likely to find interesting

programs with less number and time spent on sampling, which improves the user

experience. The hot-list can be organized on the basis of real-time popularity. The

hotlist can be customized for each geographical location as people living in the same

area tend to watch same kind of programs. This hotlist can be further refined on the

basis of individual watching behavior of viewer by recording his behavior for some

pre-defined time interval.

3.4.2 Approaches Studied

As there are different factors like IGMP Join/Leave, Network traffic load,

video stream encoding and decoding time, network jitter which cause IPTV channel

zapping latency and some of those factors are inherent in IPTV network so cannot be

completely eliminated. In this case user profiling and channel prediction can also give

a new dimension to channel zapping latency reduction. It is based on the idea that

there must be an algorithm which keeps recording the user behavior and maintains a

user‟s profile based on which it generates some predictions and pre-joins the

predicted channel‟s streams. This idea has already been used in the works of Lee et al.


33

in the form of rating server and Younghee et al. in the form of channel pool. But in

their work they do not mention the exact algorithm for channel prediction. A lot of

work has been contributed which explains the algorithms for TV content

recommendation. IPTV content recommendations can be used as channel

predictions. Some of those techniques have been listed in the following sections.

3.4.2.1 Rating Server Based Prediction

Lee et al. [15] present this technique which is based on using a rating server

which gathers information about channel change events from IP STB and manages

statistics for each STB. Based on those statistics a list of channels is predicted and

STB can obtain those predicted channels information by periodically sending a query

message to rating server. Those predicted channels streams can be transmitted to

STB. So, when a user changes to any channel within that list, he/she experiences low

channel zapping delay.

3.4.2.2 Fuzzy-Logic Based Prediction

Managing user profiles and based on those, generating accurate predictions

about user‟s preferences is quite difficult as human preferences are not as crisp as 1

and 0. So, it is very hard to distinguish whether a user likes or dislikes a particular

type of content. This kind of user‟s behavior can be illustrated by fuzzy logic.

Shi et al in [20], present an approach for TV content recommendation based

on the fuzzy logic. According to fuzzy logic we can assign any TV content category, a

decimal value between 0 and 1. Proposed approach presents multi-agent

recommendation architecture in which there is a central recommendation server

which has different units i.e. Fuzzy User Profile Database, Fuzzy Filtering Agent,

Fuzzy Recommendation Agent, Profiling Agent, and Interface Agent. Fuzzy User

Profile Database stores the fuzzy user profiles which contain user‟s information

related to different categories, genres. This information is used for recommending the

TV content. It also contains metadata related to the TV channels and content. Fuzzy

Filtering means to filter the live streams after matching its metadata with fuzzy user

profiles and then filtering the programs based on fuzzy threshold. Fuzzy

Recommendation is a list of programs recommended to user based on user‟s

preferences and fuzzy profile. Profiling agent keeps updating the information in fuzzy

user profiles based on the user preferences information recorded explicitly or

implicitly. Interface agent is module which handles the interactions with users. It


34

records the explicit preferences information provided by the user. It also records the

implicit information about user‟s preferences by monitoring user‟s activity.

According to proposed approach, a user profile can be represented by a vector

of 3 tuples namely Term, Like Degree and Weight. Term represents a category, genre,

program or channel. Like Degree represent the degree a user likes that feature and

Weight represents the importance of a certain feature.

UP = (t1, ld1,w1)… (tt, ldt,wt)… (tm, ldm,wm)

Interest Degree is calculated based on the Like Degree and Weight. Rules are

defined for different combinations of Like Degree and Weight. Value of Interest

Degree should be more than a threshold defined in order to recommend or predict the

program. Threshold value can be a crisp value or fuzzy.

Profiling agent keeps updating the values based on implicit or explicit user

preference observation.

Weighti‟ = Weighti + α .

Like-degreei‟ = Like-degreei + β .

Where:

WDi : Watched Duration

RDi : Real Time Duration

Θ: The threshold of the time duration

α, β : Constants to slow down the change of Weight and Like Degree. These are less

than 1.

This method of recommendation does not need to store user‟s viewing history

as it keeps track of user‟s activity and continuously updates numerical values in his

user profile against all the terms which he likes or dislikes. This technique can still be

refined to work for predicting IPTV channels User Model Based Prediction

Above mentioned technique introduced the use of fuzzy logic for

recommending IPTV content, Addrissono et al. in [21] further elaborate on the user


35

modeling and recommendation techniques for personalized electronic program

guides. Their work presents a model which records user‟s preferences through

different information sources which are explicit user preferences, stereotypical user

preferences and user‟s TV viewing behavior.

Explicit User Preference Model - User may specify his interests at the time of

registration with the IPTV service provider. User may specify his interests into

different IPTV content categories using different options (e.g. High, Medium or Low).

User would also specify demographic information (e.g. Age, Profession etc.) related to

him/her. Based on this information model, predictions are made. Each prediction has

a confidence value attached which represents the uncertainty present in the

prediction. User specified preferences have confidence value 1.

Stereotypical User Model – This model basically relies on the information

gathered through different surveys and user behavioral studies. Different kinds of

user roles are specified as stereotypes in a knowledge base. Every stereotype has

different features which may or may not be related to the description of the

stereotype. Each feature has its importance ranging between 0 and 1. A feature which

is irrelevant to the stereotype has importance equal to 0. Every feature has another

facet called value which represents the percentage of users fitting in the specified user

role. Predictions are made based on the information provided in this model.

Dynamic Model – This model gathers information of user behavior

dynamically. It is assumed that the system is intelligent enough to track user actions

and predict channels according to the user habits. Bayesian Network is used to model

user preferences. In the network, the context variables are associated to the

conditions in which the user preferences for the TV programs may occur. A context is

characterized by temporal conditions represented by the DAY and VIEWING TIME

variables. For each user Bayesian Network is initialized with some initial value which

is updated on fixed intervals based on user behavior.

new_prob=(prev_prob * prev_exper + learn_rate) new_exper

Where

learn_rate is the learning rate of the user`s observed action


36

prev_prob and prev_exper are the probability and the experience of the node, before

the occurrence of the action.

new_exper = (prev_exper + learn_rate) is derived from the previous experience by

taking into account the learning rate of the observed action.

This technique is quite intelligent in order to recommend IPTV content

because it gathers information through different sources and based on that

information the recommendations are made. If this recommendation system is used

to predict IPTV channels to pre join, it can make more accurate predictions than the

previous technique.

Lee et al.‟s approach has advantage over Cho et al.‟s approach [8] by reducing

random channel changing time. Tradeoff attached with this approach are larger

bandwidth for access network and cold starting of rating server‟s predicted channels

list generation, as it needs to learn the user interests over a reasonable period of time.


37

Following is a comparison of above mentioned approaches:

Technique Pros Cons

Recommendation

System Based on

Fuzzy Logic

Uses fuzzy logic to simulate human

intelligence and calculates user‟s

preferences based on its activity.

Unlike other techniques, it evaluates

degree of user interest for particular

channel and then predicts channels

based on the calculated values.

Currently this

recommender system;

needs to be modified as an

IPTV channel predictor.

Takes some time to

predict sudden mood

changes

User modeling and

Recommendation

based on 3 different

user models

Uses three different sources to

gather information about user‟s

behavior.

Can recommend more accurately

than the above mentioned

recommender system.

Complex to implement

High processing power

required

Table 3-1: Comparison of User Profiling and Channel Recommendation Techniques

3.5 Proposed Approach for User Profiling and Channel Prediction

We have proposed a solution to represent user profile based on continuous

behavior monitoring of viewer. As interest of viewer cannot be represented by a

Boolean value, fuzzy logic is used to represent user interest. Our system keeps on

updating the information in fuzzy user profiles based on the user‟s viewing behavior.

Our work is simplification of Shi et al who represent user profile by a vector of 3

tuples named like degree, weight and Term. We have simplified this approach and are

using only weight to represent user profile. Shi et al calculate weight based on user

watching time. Our approach considers various factors to calculate weight which

reflects viewer interest. Weight is calculated on the basis of

Viewer watching time

Frequency of visiting a channel

Time of day


38

System monitors viewer behavior continuously and weight is calculated after fixed

time interval. Each user has its own database at her home gateway which contains

weight value for every channel and another temporal and time series database which

contains channel number, watch time and time of day on the basis of which weight is

calculated.

After every t time interval, weight values are recalculated and replaced in the

database.

The formula for calculating weight is given below:

Where:

: constant which slows down the change of Weight ( value between 0 and 1 )

c : constant value dependant upon time of day

c= 0.1 12:00 am time 12:00 pm

c=0.3 12:00 pm time 8:00 pm

c=0.6 8:00 pm time 12:00 am

: Watch duration of a channel

: Total watch duration of all channels

: Frequency of channels visits to a particular channels

:Total number of visits on every channel in time interval t

Values of c show that a viewer watching a channel in prime time is given more

importance while calculating weight than that of a channel being watched during day

time.

In this approach as the time passes by, the value of weight keeps on getting

close to accurate value. As system learns viewer behavior, weight value increases or


39

decreases gradually to represent user interest for a particular channel. The more the

value of weight, the more user has interest in particular channel.

Advantages of our approach:

Unlike the approach presented by Shi et al, we have only one term on the basis

of which we will calculate user interest. So our solution is more light weight

than of Shi et al and our performance increases by a factor of 3.

The change in viewer interest is known as interest drift. Our system continues

to learn with time and gradually updates the weight values with time so

interest drift problem is eliminated in our case. Even if user drifts from his

interest, system will able to get over it.

Accuracy is improved to calculate user interest as we are not only depending

upon one factor. Frequency of channel visits and time of day make our

approach more accurate while calculating user interest


40

4 Proposed

Solution

In this chapter, the discussion is

based on the progress of our contribution

in this domain. A solution to channel

zapping problem is proposed keeping in

view the advantages and shortcomings of

previous approaches.


41

4.1 Introduction

Our proposed solution is mainly inspired from related works by Lee et al. [15]

and Younghee et al. [16]. In contrast to their approach, we are proposing to reduce

channel zapping using user profiling. User profiling will be used to predict a list of

channels which a user can most likely switch to. All the predicted channel streams

would be transmitted at very low data rate; we‟ll refer to it as Preview Mode. This‟ll

help in transmitting predicted channel streams along with the channel being watched

currently.

4.1.1 Architecture

Our proposed solution is based on the following simplified architecture of

traditional IPTV.

Figure 4-1: IPTV Architecture


42

4.1.1.1 Server

Server is the entity where all the processing, encoding and transmission of

video content, user billing information and Electronic Program Guide (EPG)

generation is done. It is located at IPTV Headend.

4.1.1.2 Core Network

It is the same optical network which is used by traditional IPTV.

4.1.1.3 Multicast Router

In the Access Network, multicast router performs IGMP Joining and Leaving

requested by STBs. It forwards the multicast traffic down the network to STB through

DSLAM and Home Gateway.

4.1.1.4 Home Gateway

As in Cho et al.’s work, Home Gateway acts as proxy function for STB. In our

proposed architecture Home Gateway has some more importance. We intend to bring

some more intelligence to Home Gateway, which would help in pre-joining the

multicast channel groups based on prediction. Prediction algorithm would run here at

Home Gateway and it would request the server with different streams. All the pre-

joined streams would come to Home Gateway and based on user request, it forwards

the stream to STB.

A database is located at the Home Gateway, which maintains the user profiles,

channel information like genre (e.g. Music, Movies, News etc), rating (e.g. PG-13, PG-

18, R etc), user‟s channel viewing history, list of related channels which is generated

against each channel. At the time of registration user is asked to mention his interests

in registration form. Based on these interests we refine the results of our prediction.

Predicted Channels List based on user profiling information is also generated

using information collected by user activity logs. User profiles are evaluated using

different type of metrics e.g. Frequency of viewing a channel, Duration of stay on a

certain channel etc. A final list of predicted channels is generated which contains

common entities of predicted channel list and related channel list. The resulting

dataset is then again refined based on the interest mentioned by the user initially.

Only the channels that match user‟s interests are included in the final predicted list.

Our Predicted channel list consist of channel multicast address, genre, and time spent


43

by user on this channel during last 3 hours. Only that channel will be predicted which

has maximum view time.

Home Gateway then requests the server for transmission of predicted channel

streams i.e. two adjacent channels and one channel from predicted list along with the

channel being currently viewed by user.

4.1.1.5 Set Top Box

Set Top Box – STB is the customer premises device which receives, buffers,

decodes and displays the content on the TV screen. It is the only device in IPTV

network which has direct interaction with the user.

4.1.2 Working

In our proposed architecture, as explained earlier Home Gateway contains

information about the users and channels. Every channel is transmitted to a different

multicast group as traditional IPTV. Every channel has a Related Channels List

against it in the database, which is generated on the basis of information associated

with the channel. It is generated at the initial stages of IPTV network deployment. The

purpose of creating that list is to predict some channels which a user is most likely of

watch while watching a certain channel e.g. if a user is watching GeoNews he is most

likely of watching ExpressNews or AajNews. User activity is continuously updated in

database at Home Gateway, every time user sends an IGMP Join/Leave request for a

particular channel. Monitoring is done by keeping a close eye on how frequently user

watches a particular channel and how long a user stays on that channel. By using

above information along with related channel information and user‟s previous history

of watching behavior, user‟s profile can be updated in the database. Based on user

profile information a list of channels is generated which are predicted. In prediction

there are different metrics like frequency of visiting a channel, duration of watching

the channel. These metrics have their own weightage which lead to generation of

predicted channels list e.g. we can assign low weightage to frequency of visiting a

certain channel and high weightage to watching a channel more than 20 minutes. So,

if there is a channel which has been less frequently visited but every time user visited

that channel he stayed there for more than 20 minutes, then this channel has more

chances of being liked by user than a channel which has been frequently visited but

watched for a very little time.


44

As generation of user profiles through the information stored in User Activity

Logs at every channel change requires excessive processing at the server end, so that‟s

why we decided to distribute the intelligence of channel prediction and user profiling

at the Home Gateway level of IPTV Network.

During runtime, to get a list of channels which should be requested by Home

Gateway along with a particular channel, both lists of related channels and predicted

channels would be compared and a common set of channel streams would be

requested.

Below we show typical channel change scenarios according to our proposed solution:

4.1.2.1 Channel Zapping Scenario

Following is the example of channel change scenario discussed step by step:

Before Channel Change Request

1. Let‟s assume, user is watching any random channel e.g. Channel 10.

2. The Predicted Channels List, generated against Channel 10 in the database

located at Home Gateway, contains Channels 12, 17, 32.

3. Streams of Channels 10, 12, 17 and 32 are being transmitted from server.

4. Channel 10 is being transmitted with good quality whereas Channels 12, 17

and 32 are being transmitted at a very low data rate with H.264 scalable video

coding.

5. Multicast Router is forwarding these streams down to Home Gateway which

only forwards the required stream i.e. Channel 10 down to STB.

Switching to Channel within the Predicted List

1. If user initiates an IGMP request to switch to Channel 12.

2. Home Gateway is already receiving the Channel 12 stream, so it instantly

forwards the stream to STB and delay of IGMP Joining/Leaving is overcome.

3. At first, the stream forwarded to STB is at low data rate with lower quality.

4. If the user is just changing the channel within the Predicted Channel List,

there will be very less zapping delay and user would not notice that.

5. If the user stays at Channel 12 for about e.g. ~5 seconds, Home Gateway

assumes user might want to watch the Channel 12, so it requests the server to

rescale the channel stream to high quality and scale down Channel 10.


45

6. Home Gateway updates the user activity log, whenever a channel is requested

by the STB.

7. Home Gateway resolves the channel request without needing to forward it to

higher level in the network.

8. Now, user is watching Channel 12.

So, in our solution, the channel zapping delay is largely minimized when user

switches within predicted channels. This is because the predicted channel streams are

already received at Home Gateway and at the time of channel change, Home Gateway

forwards that stream to STB.

Switching to a Channel outside Predicted List

If user has requested a channel change outside the predicted list which is,

according to our assumption, less likely when the Prediction is strong, he would

experience same amount of delay as for traditional IPTV.


46

5 Implementation

In this chapter, we will discuss

implementation process of our project. For

starting implementation we first started with a

quest for IPTV simulators or players which could

help us in implementing our proposed solution.

We reviewed a number of players and their

details are discussed later in this chapter. To

implement the proposed solution and testing the

different concepts like multicasting, unicasting

and video stream encoding schemes, as we had

to transmit videos at lower bitrates, rescale them

and encode them using different encoding

schemes we decided to use an open source video

player called VLC. Details will follow later in

chapter.


47

5.1 Quest for IPTV Simulators

For testing our results, we needed a simulator which could simulate all the

activities within IPTV network. We went through a couple of simulators but none of

them were free of cost.

5.1.1 MythTV®

MythTV is a free Linux application which turns a computer with the necessary

hardware into a network streaming digital video recorder, a digital multimedia home

entertainment system, or Home Theater Personal Computer. It can be considered as a

free and open source alternative to Tivo or Windows Media Center. [22]

Myth TV is known to work on Linux and Mac OS X (PowerPC and Intel).

MythTV comes in a separate Linux distribution called Mythbuntu. It does not run on

Windows.

MythTV has a number of capabilities. The television portion allows you to do the

following:

You may pause, fast-forward and rewind live Television.

You may install multiple video capture cards to record more than one program

at a time.

You can have multiple servers (called "backends"), each with multiple capture

cards in them. All scheduling is performed by the Master Backend, which

arbitrates which recording will be performed by each device. All recording

requests are managed by the Master Backend, so you can schedule a recording

from any client.

You can have multiple clients (called "frontends" in MythTV parlance), each

with a common view of all available programs. Any client can watch any

program that was recorded by any of the servers, assuming that they have the

hardware capabilities to view the content; a low-powered frontend will not be

able to watch HDTV, for example. Clients can be diskless and controlled

entirely by a remote control.

You may use any combination of standard analog capture card; MPEG-2,

MJPEG, DVB, HDTV, USB and firewire capture devices. With appropriate


48

hardware, MythTV can control set top boxes, often found in digital cable and

satellite TV systems.

Program Guide Data in North America is downloaded from

schedulesdirect.org, a non-profit organization which has licensed data from

Tribune Media Services. This service provides almost two weeks of scheduling

information. Program Guide Data in other countries is obtained using

XMLTV. MythTV uses this information to create a schedule that maximizes

the number of programs that can be recorded if you don't have enough tuners.

[23]

5.1.1.1 Using MythTV for IPTV Simulations

First of all, MythTV is a personal video recorder, which is used to bring

interactive functionalities like Play/Pause/Rewind live content, record live shows and

store to a personal computer. When we are watching live TV in Myth, we are actually

watching content which has first been written as a file to the hard disk. That is why we

can pause or rewind live TV in MythTV. While watching live TV, myth TV first reads

from the file that is written, decodes it then displays on the screen. Whenever a

channel is changed the old file is removed and a new file created. The fact that this

takes a couple of seconds is responsible for the gap we see in between channel

changes. [24] When MythTV is used with STB then there is an extra lag because of

STB`s delay due to buffering. Average channel zapping latency in MythTV is 4-5

seconds [25] where as some users have also reported delay upto 10 seconds [26]. So,

there is not point of using MythTV to reduce channel zapping latency as it has zapping

delay of its own.

5.1.2 WatchiTV

WatchiTV is the first complete solution in the industry, to run on a notebook

PC emulating the IPTV client, for verification of VoD channel request as well as EPG

changing delay. WatchiTV assists us throughout optimizing and troubleshooting the

IPTV environment. [27]

WatchiTV contains several measuring items, including STB Simulator, STB

Booting Monitor and MPEG measurement.

Key Applications


49

Presentation session

o IPTV client access and EPG scan.

Application session

o H.264, MPEG4 and MPEG-2 transport stream measurement.

IP transportation

o IPTV system performance.

Miscellaneous

o STB initialization monitoring. [28]

Like WatchiTV, all other simulators also cost very high so instead of buying

one, we decided to build our own application which could simulate IPTV network

activities to reduce channel switching time. Before this, we studied about different

IPTV players which could be used to solve our problem. Myth TV was one of them,

which was studied thoroughly and following were the findings.

5.1.3 Other Players

While searching for different players which could have potential usage in IPTV

simulations, we had following criteria:

1. Player should have the capability to simulate all the components of IPTV

architecture, i.e. IPTV Media Server, Multicast Router, Home Gateway and

IPTV STB.

2. Support for encoding video streams using different codecs at Media Server

and transmission at different data rates.

3. Should be open source and free of cost.

We explored the following players for potential usage in our IPTV simulations.

1. Linux Media Center Edition:

LinuxMCE is a free and open source software platform designed to

allow a computer to act as a home theater PC (HTPC), personal video

recorder, and home automation system (21). It allows control of everything in

the home, from lighting and climate to surveillance cameras and home

security. It even includes a full-featured VOIP-compatible phone system with


50

video conferencing (22). As LinuxMCE does not follow point 1 and 2 of our

criteria, it is not suitable for IPTV simulations.

2. Microsoft TV IPTV Edition:

Microsoft TV IPTV edition is a non-standard IPTV platform for

accessing both on-demand as well as live television content over a 2-way IP

network, coupled with DVR functionality. It is to be used with cable networks

that have an IPTV infrastructure. It is offered by Microsoft as a whole solution

for IPTV service providers like AT&T. As it is a licensed and proprietary

solution developed by Microsoft we cannot modify it for IPTV simulations in

our project.

3. Microsoft Media-room:

The latest update of the Microsoft TV IPTV Edition platform software,

is intended for use in a STB to access on-demand as well as live TV

programming on a Microsoft IPTV network. Microsoft Media-room includes

all the features of Microsoft TV IPTV Edition, including support for on-

demand and live video, video recording and time shifting, and interactive

program guide with integrated search and scheduled recording. It includes the

ability to record two HD streams while watching two SD streams

simultaneously (23). As Microsoft Media-room is latest update of Microsoft

TV IPTV Edition, explanation for why we are not using it is same as for

Microsoft TV IPTV Edition.

4. Linux4.tv:

Linux4.TV comprises of open-source interactive set-top box

technologies based on the National Semiconductor Geode™ SC1200

integrated processor and SP1SC10 development platform which provide a

complete suite of open-source drivers, applications, plug-ins, and toolkits that

form the foundation of a feature-rich interactive set-top box system. (24) It

requires specific hardware i.e. National Semiconductor Geode™ SC1200

integrated processor and SP1SC10 development platform and moreover

Linux4.tv Set Top Box Open Source Project is outdated and required resources

listed on linux4.tv are not available anymore.


51

5. OpenTV:

OpenTV is a middleware proposed by a company of the same name.

OpenTV is widely adopted by broadcasters, operators, and device

manufacturers around the world; it is used in more than 106 million digital

STB and TVs (25). OpenTV supports near video-on-demand (NVoD)

applications, impulse pay-per-view (IPPV) and allows downloading of data or

applications. OpenTV is extensively documented and also provides a „software

development kit‟ (SDK). The SDK, an integrated interactive application

development environment for OpenTV middleware, assists developers in

creating applications using the C language that can use the complete

functionality of an OpenTV-enabled STB (26). OpenTV itself is a proprietary

solution for IPTV and has been adopted by a number of IPTV service

providers. Its SDK can be used to develop interactive services for IPTV like

games, educational purposes but it is not suitable for our project domain in

which we need to reduce the channel zapping delay.


52

5.2 Designing a Test Bed

As described earlier in section 5.1, we could not find an IPTV simulator which

meets our requirements; we decided to design our own IPTV test bed. For this

purpose we chose VideoLAN Player‟s API to get basic functionalities of video

encoding, multicasting and streaming. The reason due to which we chose this API has

been explained in the following section.

5.2.1 Why VLC?

VLC provides rich functionalities like streaming on LAN using different

protocols i.e. RTP, UDP, RTSP, and HTTP. Video can be transcoded. It can unicast

and multicast video streams on network. We used its unicast and multicast features

and played streams on network.

Some functionalities like unicast and multicast streaming were tested to get

started before actual application development. Those tests and proofs of concepts like

comparison between unicast and multicast have been shown below.

5.2.1.1 Unicast

Unicast is the term used to describe communication where a piece of

information is sent from one point to another point. In this case there is just one

sender, and one receiver.Unicast transmission, in which a packet is sent from a single

source to a specified destination, is still the predominant form of transmission on

LANs and within the Internet. All LANs (e.g. Ethernet) and IP networks support the

unicast transfer mode.

We tested VLC for unicast video transmission within same network. We used

following network topology for unicast:

Figure 5-1: Unicast using VLC – Network Topology


53

At Server Side:

Step1: Open VLC player.

Figure 5-2: VLC Player

Step2: Open file that you want to stream.

Figure 5-3: Opening a file

Step3: Set Stream Output settings.


54

Figure 5-4: Dialogue Box to enter the port number through which the Unicast traffic will

pass.

Step4: Enter IP address of destination computer.


55

Figure 5-5: At Server, Dialogue Box to set IP address of unicast receiving client.

At Client Side:

Step5: At Client Side open network stream options.


56

Figure 5-6: At client side, Opening the unicast stream being transmitted by Server.

Step 6: Connect to the same port (mentioned on server) to play streamed content.

Figure 5-7: Enter the port number on which the Unicast stream is being transmitted from

server.

Results for Unicast using VLC Player

Video was streamed on LAN and we noticed a delay of about 1 second between

the sent and received video.


57

Network was monitored using Ethereal Network Analyzer and different rates

of bandwidth were noticed for different compression techniques provided by VLC.

5.2.1.2 What is multicast?

Multicast is a norm implemented in all modern network hardware (switches,

routers ...). It provides an intelligent manner to send a stream to a dynamic group of

machines. If one wants to use multicast, he has to make sure that all the network

hardware support it.

In multicast streaming, the stream is sent to a multicast IP address (the IP

addresses reserved for this purpose are from 224.0.0.0 to 239.255.255.255). Then,

any machine on the network can join the multicast group by sending a request on the

network, and it will automatically receive the stream. When it sends a request to leave

the group, it will automatically stop receiving the stream. The advantage of multicast

streaming is that only the machines that want to receive the stream actually receive it,

and the streaming server only sends one stream even if there are multiple clients

receiving it. [29]

Figure 5-8: Multicasting [30]

Why Multicast?

Unicast connections are widely used for transmission over internet. It is

affordable making different connections with every user connected to a certain web

page but when sending or receiving audio and video content, which needs huge

amount of bandwidth as compared to web applications where only data is being sent

or received, creating unicast connection with each user receiving the same audio or

video stream becomes impractical and unaffordable choice as it requires so many

unicast links with high bandwidth. So, to address this kind of problem, multicast is

the best option. As in multicast, server transmits one stream of certain audio or video


58

content to a multicast IP address and then only those nodes which are members of

that multicast group can receive that video or audio content.

Demonstration of Multicast:

For demonstration of multicast using VLC we used following network topology

which is shown below:

Figure 5-9: Multicast using VLC – Network Topology

At server side

Step1: Open VLC player


59

Figure 5-10: Opening a file for multicast streaming

Figure 5-11: Dialogue Box

Step 2:

Browse a file that is to be transmitted, check the stream output checkbox and

click on the Settings button


60

Figure 5-12: Browsing a file to stream

Step 3: Set the options before starting the stream. Check UDP, enter the multicast

group IP address and port number.


61

Figure 5-13: Assigning the multicast IP address for streaming to a particular multicast

group

After clicking OK, it will start streaming the file.


62

Figure 5-14: Stream being transmitted to multicast group

At Client Side

Step 1: Open network stream

Figure 5-15: Opening the network stream

Multicast Stream is being

transmitted and displayed at

server…


63

Step 2: Check UDP/RTP Multicast and enter the Multicast Group IP Address to join

the Multicast group to receive Multicast stream.

Figure 5-16: Entering the multicast IP address which the client should join to receive

multicast stream

After clicking OK, it will start receiving multicast stream


64

Figure 5-17: Multicast stream is being displayed at client’s system

Results

Client can register with more than one multicast groups at the same time. In

this way, it can receive more than one stream but different instances of VLC have to

be initialized.

As a test case, 4 multicast streams were generated from server end and

received at the clients. To access those streams the client has to join the multicast

group associated with that stream. To analyze bandwidth consumption we used

Ethereal. We figured out that sending 4 high quality multicast streams will consume

5.215 Mbps bandwidth.

We used bandwidth limiter software i.e. NetLimiter Pro 2, to limit the

bandwidth up to 2 Mbps. At 2 Mbps, we managed to transmit 4 streams, i.e. 3 streams

encoded through h.264 codec at 32 Kbps bit rate and video scaled down to 0.25 of the

original size. The 4th stream was, according to our proposed approach, the requested

channel a user wants to watch. It was transmitted as MPEG-2 stream with good

quality.

Multicast stream being

received and displayed at

client‟s system…


65

This test was also carried out by encoding the 3 streams using MPEG-4 at 32

Kbps and scaled down to 0.75 of the original size. MPEG-4 provides good quality at

even lower bitrates. So, we received the streams with improved quality. The requested

channel stream was also encoded with MPEG-4 at 768 Kbps and 512 Kbps. At 768

Kbps, an acceptable video quality received but sometimes, jitter occurred whereas at

512 Kbps, video quality dropped a little but the requested channel stream received

smoothly with other 3 low quality streams.

Figure 5-18: Four different streams being received by the client at high quality and the

average bit rate observed in this case was 5.215 Mbits per sec

Application was decided to be developed in Visual Studio .NET using C#, as

we had found C# wrapper for libvlc. Libvlc is a library provided online by VLC‟s

developer team. An ActiveX control of VLC was used in our test bed application which

provided all the functionalities of VLC.


66

5.2.1.3 Developing IPTV Application

After demonstrating this unicasting and multicasting using VLC on the same

network, we proceeded to design our own IPTV test bed. So, a .Net application was

designed which would act just like a set top box. For this we studied, VLC source code

and using C# wrapper for libvlc (an open source library provided by VLC), created the

application which could receive multicast streams of channels on a network and it

also provided an ease of channel switching by actually switching (Joining/Leaving)

multicast groups. This simulated an IPTV STB.

Figure 5-19: Our designed application, which uses VLC’s functionalities and acts like a Set

Top Box

5.2.1.4 Features of designed application

Channel buttons

Every channel buttons is associated with a multicast stream. By clicking this

button, a user can join a particular multicast stream.

private void button6_Click(object sender, EventArgs e)

{

vlcUserControl1.AddAndPlay(@"udp://239.255.1.1:1234", "");

vlcUserControl1.Play();

}

VlcUserControl1.AddAndPlay adds a multicast stream to user‟s current playlist.

ActiveX Control for VLC

It displays video content…


67

vlcUserControl1.Play () plays the multicast stream that is recently added in the

playlist of user.

Up/Down buttons

These buttons are made to simulate the adjacent channel switching time. By

clicking these buttons, we can switch to the next multicast stream being transmitted

by the server.

Stop Button

Pressing this button will stop the multicast stream that is being received. The

function used to implementing this functionality is vlcUserControl1.Stop ()

5.2.1.5 Multicasting from one networks to another

Currently we are working on forwarding the multicast stream from one

network to other. This will be done by making a PC act as soft router. Refer to Figure

5-20.

Figure 5-20: Simplified architecture of our test bed in case of internetwork transmission.


68

Step 1: Assigning multiple IP addresses

As we had only one Network Interface Card in the machine so we decided to

make two logical interfaces (one for each network).

ifconfig eth0:1 10.3.12.1 netmask 255.255.255.0 up

ifconfig eth0:2 10.3.13.1 netmask 255.255.255.0 up [31]

Step 2: Configuring the Kernel

We studied different approaches to configure the kernel. As it was our first

experience so we found it pretty difficult to find the appropriate way to configure it.

Four ways to configure kernel are:

Editing the .config file

Make config

Make menuconfig

Make xconfig

We used „make config‟ which is a program that asks us for a yes/no/module for

about 500 options in the kernel. We need to enable following features to get multicast

routing to work. [32]

CONFIG_IP_MULTICAST=y

CONFIG_IP_ROUTER=y

CONFIG_IP_MROUTE=y

CONFIG_NET_IPIP=y

Step 3: Re-compiling and installing the kernel

After configuring the kernel, it was recompiled and installed. „Make install‟

command was used to compile and install it.

Step 4: Installing routing daemon MROUTED

We downloaded the files into /tmp and untared them in /usr/src. Following

command were used to perform this operation.


69

cd /usr/src

tar xvzf /tmp/mrouted-3.9-beta3.tar.gz

gunzip /tmp/mrouted_3.9-beta3-1.diff.gz | patch -p0

5.2.1.5.1 Issues while compiling Mrouted

We could not manage to fix the error that we are encountering while

compilation of mrouted. After this process, we will configure the routing table to route

multicast traffic from one network to another. As there is not much documentation

available for mrouted, so we are also studying other routing daemons such as PIMD,

SMCROUTE to solve this problem.


70

6 Results

In this chapter, we will summarize the learning,

experiences and results recorded during our

progress so far. Later in this chapter, we will

include details about our future work in this

project.


71

6.1 Learning and Experiences

In this section we will summarize our learning and experiences so far in our

project. An extensive literature survey has been carried out. We have been reviewing

different research works, online resources and documentations to work out the

channel zapping latency problem. We have identified major factors which cause the

channel zapping latency. We have learned the basics of IPTV networks. In this regard,

we reviewed different architectures and approaches followed by other researchers

which have been discussed in Related Works chapter.

1. In order to solve the channel zapping latency problem, the major requirement

was to devise a theoretical solution and then implement and test the

theoretical concepts. We have devised a proposed solution which is based on

user profiling and prediction. We reviewed existing work and identified their

short comings. Every approach has its own tradeoffs. So, we took inspiration

from advantages of other approaches and tried to address their short comings.

2. To start working on channel zapping latency problem in IPTV systems, we first

needed to understand the basic concepts of IPTV networks, multicasting, user

profiling and prediction. We studied IPTV architecture and identified its

major components. After that we came up with a solution which followed

traditional IPTV architecture with a few modifications according to our

proposed solution. We brought intelligence of channel prediction and user

activity monitoring at Home Gateway level so that IPTV Media server does not

have to add extra functionality and processing for monitoring a large number

of users.

3. For implementation of our proposed solution, we explored potential IPTV

simulators and different players which could have potential usage in IPTV

simulations. We learnt about MythTV and tried to explore its potential usage

in IPTV simulation, but as discussed earlier in the section 5.1.1, MythTV was

not a suitable solution to our problem. MythTV is a personal video recorder

which we studied in quite detail. We installed a Linux distribution called

„MythBuntu‟ which is specially made for MythTV users. Also, we explored

different features of MythTV including interfacing it with PTCL Smart TV.

Unfortunately MythTV does not support any cable TV network in Asia so we

could not use Myth TV with PTCL Smart TV. Moreover, as discussed earlier,

we found that MythTV is a Personal Video Recorder, so we discontinued


72

studying it further as its functionality is clearly different from our problem

domain. As, we could not find a simulator or player which could help us

simulate our proposed solution as discussed in Implementation chapter, we

decided to design our own IPTV Test bed which we could build and modify

according to our needs. In this regard, we found VLC Player, which could help

us in simulating our IPTV test bed. We studied VLC‟s online documentation

and decided to use it, as it provided us the facility to encode the video stream

using different encoding techniques at different data rates and support for

multicast transmission and it is also open source software. Moreover, we also

found C# wrapper of libvlc (a library which contains all the functionality of

VLC), so, we started developing our project using C# in Visual Studio .NET.

4. We started studying VLC player which provides rich functionalities like

streaming on LAN using different protocols i.e. RTP, UDP, RTSP, and HTTP.

We experimented a lot with VLC and transmitted different streams using

different bitrates. Network analyzer software like Ethereal and Wireshark

were used to monitor bandwidth consumption in the network while the

transmission is being carried on. As our proposed approach requires multiple

streams of lower bitrates to be transmitted to the home gateway, so we needed

to know about the number of channels that could be transmitted to home

gateway with acceptable video quality. In this manner, we tested VLC

multicast streaming with multiple streams with different combinations of

video qualities and number of streams as described in Results section of

section 5.2.1.2.

5. Building a .NET application to simulate IPTV STB was another experience. We

chose VLC Player‟s API to get basic functionalities of video encoding,

multicasting and streaming. Using c#, we designed an application which could

change channels randomly, switch to adjacent channels and play/pause

streams.

6. Another task was to send a multicast stream from one network to another. As

we did not have access to router, we decided to use our Linux machine as a

soft router. We had only one Network Interface Card in the machine so we

decided to make two logical interfaces (one for each network). Setting up a

secondary IP was another significant learning. Also while configuring,

compiling and installing the kernel we had to face many issues which were


73

resolved by taking help from blogs, online communities, tutorials and our

advisors.

7. Although our project was mainly focused on how to transmit predicted

channel streams to user‟s home gateway within limited bandwidth, we also did

quite thorough literature survey of techniques for user profiling and channel

prediction and how those techniques can be used to predict more accurately. It

was a great experience of learning about a new domain and developing

concepts about it. As a result, we also developed a technique for channel

prediction which has been discussed in Chapter 3.

8. Finally, we have submitted a review paper to get published, which includes all

the techniques studied during our project. In the paper, we have also

recommended the techniques and solutions for different scenarios. Writing a

review paper was another good learning experience which highly improved

our technical writing skills.

9. Apart from all the technical skills, we also learned problem solving skills and

writing skills, which helped us in devising a proposed solution for IPTV

zapping problem and properly document our findings. It has been very helpful

in developing a sense of professionalism inside us. It has also developed a

sense of reviewing other‟s research works and then finding their positive and

negative points. This project provided us the exposure to learn about 2

different domains i.e. IPTV networks and User Profiling and Channel

Prediction.


74

6.2 Future Work

In this project, we have surveyed different techniques which range from

removing the delay using video compression and core network techniques to user

profiling and channel prediction techniques. Our review paper also aggregates in one

place all our findings and our reviews about different techniques. As mentioned

earlier we have recommended the use of different approaches for different scenarios,

e.g. if bandwidth is not an issue then Lee et al.’s rating server based technique suits

best but when bandwidth is limited than Younghee et al.’s technique of H.264

scalable video coding along with some strong prediction technique suits best.

Our research work can be extended in mainly 2 different domains which we have

mentioned earlier; the IPTV network delay reduction using core network optimization

techniques and User Profiling and Channel Prediction techniques. Research in the

latter domain can also result helpful to research in the domain of IPTV Content

Recommendation.

As we faced a lot of problems while finding for an IPTV testbed or simulator

which could be used to implement the IPTV network and we could test our findings.

But we could not find one so we started to build our own IPTV testbed which

simulates and help in demonstrating proof of our concept for our proposed technique.

So, another extension to this project can be building an IPTV testbed which can be

helpful in testing different kind of techniques and act as a simulator which can also be

a helpful tool for innovation in IPTV domain.


75

7 Conclusion


76

We identified our problem domain, learned the basics of IPTV architecture,

reviewed related research work, proposed our solution to overcome channel zapping

latency which uses user profiling and channel prediction, implemented a basic IPTV

architecture, developed an application which simulates the channel zapping scenario,

aggregated all the distributed information in this domain into a survey paper and

submitted it to get published. This whole process has provided us a great opportunity

to learn IPTV and networking concepts like multicasting, routing in a single network

and different networks, user profiling and hands on experience of working with

networks using UNIX based environment like Linux, problem solving skills and

technical writing. This work has established firm grounds for others to continue their

contribution in this problem domain.


77

8 Bibliography


78

1. [Online] http://en.wikipedia.org/wiki/IPTV.

2. Intelligent Pre-fetching to Reduce Channel Switching Delay in IPTV Systems.

Mandal, S. K. and Mburu, Micheal.

3. [Online] http://economictimes.indiatimes.com/articleshow/msid-589392,prtpage-

1.cms.

4. [Online] http://www.att.com/gen/press-

room?pid=4800&cdvn=news&newsarticleid=26580.

5. [Online]

http://www.juniper.net/solutions/literature/white_papers/iptv_multicast.pdf.

6. A Guide to IPTV: The Technologies, the Challenges and How to Test IPTV .

7. Agilent Technologies, Validating IPTV service quality under realistic Play

network conditions, Europe Next Generation Network Test. 2006.

8. Improvement of Channel Zapping Time in IPTV Services Using the Adjacent

Groups Join-Leave Method. Cho, Chunglae, et al.

9. [Online] http://www.researchandmarkets.com/reports/c76699.

10. Optimizing channel change time in IPTV applications. Fuchus, Herald and

Farber, Nikolaus.

11. RFC 3306, “Internet Group Management Protocol, Version 3 (IGMPv3)”. October

2002.

12. Technologies, Agilent. "How Network Conditions Impact IPTV QoE“. [Online]

2007. www.cp.literature.agilent.com/litweb/pdf/5989-6143EN.pdf.

13. TR-126, DSL Forum Technical Report. Triple-play Services Quality of Experience

(QoE) Requirements. Dec. 2006.

14. 3550, RFC. “A Transport Protocol for Real-Time Applications”. July 2003.

15. Advanced Scheme to Reduce IPTV Channel Zapping Time. Lee, Jieun, et al.

16. Reducing IPTV Channel Switching Time using H.264 Scalable Video Coding. Lee,

Yonghee, et al.

17. On Next-Generation Telco-Managed P2P TV Architectures. M. Cha, P. Rodriguez,

S. Moony, and J. Crowcroftz. 2008.

18. Channel Selection Problem in Live IPTV Systems. M. Cha, K Gummadi, and P.

Rodriguez.,. 2008.


79

19. A Measurement Study of a Large-Scale P2P IPTV System. Hei, et al.,. IEEE

Transactions on Multimedia.

20. Xiaowei, S. An Intelligent Recommendation System Based on Fuzzy Logic.

Information in Control, Automation and Robotics I. s.l. : Springer Netherlands,

2006, pp. pp. 105-109.

21. Ardissono, Liliana, Gena, Cristina and Torasso, Pietro. User Modeling and

Recommendation Techniques for Personalized Electronic Program Guides.

Personalized Digital Television – Targeting Programs to Individual Viewers,

volume 6 of Human-Computer Interaction Series, chapter 1. s.l. : Kluwer Academic

Publishers, pp. 3--26.

22. [Online] http://en.wikipedia.org/wiki/MythTV.

23. MythTV-HowTo.

24. [Online] http://www.MythTV.org/wiki/Frequently_Asked_Questions.

25. [Online] http://en.wikibooks.org/wiki/MythTV/Extras.

26. [Online] http://threebit.net/mail-archive/MythTV-users/msg15353.html.

27. [Online] http://www.pds-test.co.uk/pdf/BR-WatchiTVPortable-Q207Rev2.pdf.

28. [Online] http://www.pds-test.co.uk/products/watchitv.html.

29. [Online] http://tldp.org/REF/VideoLAN-Quickstart/x536.html.

30. [Online] http://en.wikipedia.org/wiki/Multicast.

31. [Online] http://linux-ip.net/html/basic-changing.html.

32. [Online] http://www.jukie.net/~bart/multicast/Linux-Mrouted-

MiniHOWTO.html.

33. [Online] http://tldp.org/HOWTO/Multicast-HOWTO-1.html.

34. [Online] http://www.linuxmce.org.

35. Linux MCE. Wikipedia. [Online] http://en.wikipedia.org/wiki/Linux_MCE.

36. [Online] http://en.wikipedia.org/wiki/Microsoft_Mediaroom.

37. [Online] http://linux4.tv.

38. OpenTV. Wikipedia. [Online] http://en.wikipedia.org/wiki/OpenTV.

39. [Online] http://www.opentv.com.

40. [Online] http://www.MythTV.org/wiki/Frequently_Asked_Questions.


80

Documents

Final Project Report (2)