Final Project Report

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
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
1
IPTV Systems
DEDICATION
In the name of Allah, the Most Gracious, the Most Merciful
To Our Parents
&
Our Teachers
2
IPTV Systems
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.
3
IPTV Systems
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
4
IPTV Systems
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
5
IPTV Systems
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.
6
IPTV Systems
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
7
IPTV Systems
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.
8
IPTV Systems
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.
9
IPTV Systems
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]
10
IPTV Systems
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.
11
IPTV Systems
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
12
IPTV Systems
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]
13
IPTV Systems
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
14
IPTV Systems
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.
15
IPTV Systems
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]
16
IPTV Systems
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.
17
IPTV Systems
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
18
IPTV Systems
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.
19
IPTV Systems
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.
20
IPTV Systems
Figure 2-1: IGMP flow of Adjacent Channel Join-Leave Method

[15]
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.
21
IPTV Systems
Figure 2-2: Workflow using Rating Server [15]
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. B n 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
22
IPTV Systems
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]
23
IPTV Systems
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

Adjacent Random
Bandwidth Video
Approach Channel Channel
Consumption Quality
Selection Selection
Adjacent Channel
High Good Yes No
Join/Leave (Cho et al.)
Advanced Scheme to
Reduce IPTV Channel High Good Yes Yes
Zapping Time (Lee et al.)
Reducing IPTV Channel May be
Reduced
Switching Time Using Lesser than (Based on
video Yes
H.264 Scalable Video other two the pool of
quality
Coding (Younghee et al.) channels)
Table 2-1: Comparison between channel zapping reduction techniques
24
IPTV Systems
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.
25
IPTV Systems
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
26
IPTV Systems
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
27
IPTV Systems
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
28
IPTV Systems
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).
29
IPTV Systems
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
30
IPTV Systems
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.
31
IPTV Systems
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.
32
IPTV Systems
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
33
IPTV Systems
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
34
IPTV Systems
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
35
IPTV Systems
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.
36
IPTV Systems
Following is a comparison of above mentioned approaches:
Technique Pros Cons
Uses fuzzy logic to simulate human Currently this

intelligence and calculates user‟s recommender system;
preferences based on its activity. needs to be modified as an
Recommendation
IPTV channel predictor.
System Based on
Unlike other techniques, it evaluates
Fuzzy Logic
degree of user interest for particular Takes some time to
channel and then predicts channels predict sudden mood
based on the calculated values. changes
Uses three different sources to

gather information about user‟s
User modeling and Complex to implement
behavior.
Recommendation
based on 3 different High processing power
Can recommend more accurately
user models required
than the above mentioned
recommender system.
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
37
IPTV Systems
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
38
IPTV Systems
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
39
IPTV Systems
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.
40
IPTV Systems
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
41
IPTV Systems
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
42
IPTV Systems
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.
43
IPTV Systems
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.
44
IPTV Systems
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.
45
IPTV Systems
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.
46
IPTV Systems
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
47
IPTV Systems
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
48
IPTV Systems
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
49
IPTV Systems
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.
50
IPTV Systems
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.
51
IPTV Systems
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
52
IPTV Systems
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.
53
IPTV Systems
Figure 5-4: Dialogue Box to enter the port number through which the Unicast traffic will
pass.
Step4: Enter IP address of destination computer.
54
IPTV Systems
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.
55
IPTV Systems
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.
56
IPTV Systems
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
57
IPTV Systems
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
58
IPTV Systems
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
59
IPTV Systems
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.
60
IPTV Systems
Figure 5-13: Assigning the multicast IP address for streaming to a particular multicast
group
After clicking OK, it will start streaming the file.
61
IPTV Systems
Multicast Stream is being

transmitted and displayed at
server…
Figure 5-14: Stream being transmitted to multicast group
At Client Side
Step 1: Open network stream
Figure 5-15: Opening the network stream
62
IPTV Systems
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
63
IPTV Systems
Multicast stream being

received and displayed at
client‟s system…
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.
64
IPTV Systems
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.
65
IPTV Systems
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.
ActiveX Control for VLC
It displays video content…
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.
66
IPTV Systems
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.
67
IPTV Systems
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.
68
IPTV Systems
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.
69
IPTV Systems
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.
70
IPTV Systems
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
71
IPTV Systems
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
72
IPTV Systems
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.
73
IPTV Systems
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.
74
IPTV Systems
7 Conclusion
75
IPTV Systems
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.
76
IPTV Systems
8 Bibliography
77
IPTV Systems
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.
78
IPTV Systems
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.
79
IPTV Systems
80

Final Project Report

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Final Project Report

Diunggah oleh

Hak Cipta:

Format Tersedia

Final Year Project

Muhammad Zeeshan Ahmad

Dr. Junaid Qadir

Dr. Adeel Baig

Dr. Hammad Majeed

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

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

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

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

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

1.1 IPTV .......................................................................................................... 10

1.2 Major Challenges for IPTV ........................................................................ 14

1.3 Zapping Time ............................................................................................ 14

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

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

2.1 Literature Survey ...................................................................................... 18

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

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

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

3.4 Literature Survey ......................................................................................28

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

5.1 Quest for IPTV Simulators ........................................................................ 47

5.2 Designing a Test Bed ................................................................................. 52

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

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

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

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

Flexibility: Since the underlying infrastructure is general network the upper

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

In September 1999, a regional telecommunications operator in UK named

1.1.2 IPTV Architecture

Figure 1-1: Traditional IPTV Architecture [5]

1.1.2.1 Content Sources

1.1.2.2 Service Nodes –

1.1.2.3 Wide Area Distribution Networks

1.1.2.4 Customer Premises Equipment (CPE)

1.1.2.5 IPTV Client

1.1.3 How IPTV Works

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

1.2 Major Challenges for IPTV

1.2.1 Quality of Experience (QoE)

1.2.1.1 Channel Switching

1.2.1.2 Media Quality

1.3 Zapping Time

1.3.1 Typical Channel Switching Process

1.4 Current Market Trends

The key findings of this market analysis report are:

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

2.1 Literature Survey

2.1.1 Factors involved in Zapping Time

2.1.1.1 IGMP session joining for multicast delivery

2.1.1.3 Random access point acquisition

2.1.1.4 Audio-video synchronization

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

2.1.1.6 Key acquisition times in case of scrambled content.

2.1.2 Approaches to reduce zapping time