Traffic Modeling and Provisioning of a P2P-based VOD Architecture

Traffic Modeling and Provisioning of a P2P-based

VOD Architecture

Dr. Sami Saleh Alwakeel

College of Computer and Information Sciences, King Saud University, Riyadh, Saudi Arabia

Email: swakeel@ksu.edu.sa

Abstract— Building a scalable video on demand (VOD) architecture is essential for the optimization of the VOD service cost and to support a very large VOD content library. The peer-to-peer (P2P) VOD architecture works towards achieving this goal, by distributing the video files to the user's set-top boxes at the network edge. The details of such system, however, including numerous operational issues remain to be resolved.

This paper investigates the network bandwidth requirements of a peer to peer VOD service architectures system. A network mathematical model is developed to analyze the key-parameters that have influence on the P2P network bandwidth requirement. A comparison of a centralized system to the (P2P) VOD architecture bandwidth requirements as a function of video service multicast factor and files requests rate is also presented. The research results present a systematic study on the bandwidth provisioning in P2P VOD applications.

Index Term— VOD bandwidth provisioning, peer-to-peer (P2P) video-on-demand planning , VOD Models.

1. INTRODUCTION

Video-on-demand (VOD) is becoming as one of the increasingly popular media streaming services due to the recent advances in broadband Internet access technology. VOD networks are developed to deliver video files to distant users with minimal delay and free interactivity. [1]

Traditionally, the VOD service is build based on a centralized architecture. However, this architecture cannot provide the quality of service needed to a large population of users due to its limited outbound channel capacity from the server to the clients . Recently, a peer-to-peer (P2P) architecture is proposed to meet the challenge of providing live and interactive video broadcast to a large number of clients over a wide area. [2]. A peer-to-peer (P2P)-based architecture is an appropriate candidate for designing a scalable VOD services distribution architecture as the computing and bandwidth requirements is pushed toward the network clients side. Besides, it allows optimal use of the network resources by building multisource streams from neighbouring contributing clients to a requesting client. This in turns results the minimization of VOD request rejection rates for a very large content library [3].

To build a cost effective system , it is important to study how P2P network bandwidth could be provisioned in a managed broadband network and how to determine the bandwidth demand of multicast and interactive VOD surfing. This is essential since VOD content delivery process usually consumes large amounts of bandwidth, and imposes a heavy

burden on the network and the system resources. Thus, to optimally use and provision the network bandwidth resources is a main concern for VOD network providers . [3, 4]

1.1. Related work

A large number of research proposals have been concentrated to P2P VOD services distribution and on VOD live P2P streaming to very large numbers of clients . [5- 12] Many of these proposals aimed towards solving the VOD system scalability problem. [13] The goals of other P2P VOD system research studies were to maximize the aggregate throughput among all the VOD peers and to eliminate the redundant VOD packets delivery using various coding techniques.[2, 14- 15] Little research has been directed towards studying bandwidth and resources provisioning in VOD P2P network. Very few literatures cover the optimization of network resources (i.e., inbound and outbound link capacities and the required storage size) at clients STBs. In this paper, we study the bandwidth requirements problem in P2P VOD network architecture. The research goal is to provide a planning model to analyze the key-parameters that have influence on P2P network bandwidth. More specifically, this paper presents:

 A summary P2P system architecture and the key parameters that can be used to analyze the performance of VOD system deployment.

 An analytical model for planning of P2P VOD service traffic.

 A numerical solution for provisioning the communication network bandwidth , which is developed based on the model proposed in this paper. The remainder of this paper is organized as follows. In next section, we present the P2P architecture, components and access mechanisms that have been proposed for VOD networks, In Section III, we present the mathematical model developed to estimate the VOD network bandwidth requirements. In Section IV, we present a numerical analysis of the key parameters of the P2P network design and discuss the various results obtained. In the last section, we summarize the key issues and our main conclusions.

2.0 P2P VOD NETWORK COM PONENTS, ARCHITECTURE AND MECHANISM S

2.1. Basics of VOD system

A typical traditional VOD broadband network consists of a number of remote client clusters that communicate with the network‟s centralized head end servers through a broadband channel, which represent the backbone of the network; there are no local servers. All client requests are received by the head-end centralized server‟s router, and the vide-head end servers then retransmit the video data information to the destination clients via the outbound links.

This solution suffers from very significant scalability problems, especially when scaled up for millions of potential users. Providing access to a large library of pre-encoded content using this approach requires enormous servers with enormous network connections [16].

2.2 Peer to peer network architecture

A peer to peer network architecture, consists of the components shown in Fig. 1. In this architecture, a large number of clients (or peers) interested in some video content cooperate with each other by exchange their stored video contents. The video content initially exists on a centralized head end server. The Network bandwidth from the centralized servers to the system clients are usually limited, and the inbound and outbound capacities of the clients are also typically asymmetric (i.e. the inbound rate is smaller than the download outbound rate). However, clients can enhance the system bandwidth by donating their own inbound and outbound bandwidths to the system. Thus, Peer to peer architecture utilizes

the numerous clients inbound and outbound links bandwidth and storage capacities available at clients set up boxes (STBs) to build an advanced VOD architecture based on multisource streaming from partners contributing STBs to a requesting STB. [16, 17]

The video distribution scheme acts as follow: The system central head-end server acts initially as an origin peer to search and download the requested content [16, 17]. The file video content is divided by the head-end server, into a number of segments, and are further divided into blocks which streamed by a different contributing STB to the requesting STB. This will reduce the limited STB uplink capacities in asymmetrical broadband networks. An initial video sequence block of each title in the centralized library is downloaded to all STBs, which allows any end user to instantly start playing the initial part of any content while the rest of the sequence is received through multisource streaming from other STBs. If a client wants to access a given live stream, it will first question a video hub office (VHO) controller whose address is known to all clients. This controller provides the client with the subset of active clients (typically less than 30 in our study) who are members of the multicast mesh network associated with that requested VOD stream. The client then exchange content and control messages with each of these clients through a video switching office (VSO) in its cluster area , and joins the mesh network established between these clients. Upon connection, each client nodes downloads all blocks it needs and receives complementary sub-streams from its multicast mesh network partners (peers) and has enough storage to keep all the blocks they have downloaded. The P2P mesh network membership changes as a result of client arrivals and departures, because clients periodically try to find new partners to increase their download rates. As a result, P2P architecture allows the s torage and streaming resources scale with the number of clients and provides a scalable video distribution solution able to cost-effectively support very large content libraries . [6, 16 and 17] In addition, it is expected that P2P will also reduce the channel-or alternatively video stream - change times in IPTV which is a major obstacle in IPTV services‟ wide adoption. [18]

3.0 P2P VOD NETWORK PLANNING STUDY AND MODELS

In this section, we describe the overall planning methodology of this research study, and describe various key-parameters modeling used, based on a functional view of a typical P2P network architecture described before.

1)

each other, and the arrival requests come from large numbers of client set-up terminals, the arrival process of normal requests, as well as of interactive requests, to each video storage server can be modelled as a Poisson process with average ratesnand  respectively. With this assumption, the distribution of the sum of k of independent identically distributed random variables, representing the request inter- arrival times, is then the Erlang distribution.

2)

Bandwidth provisioning is used to determine the VOD system bandwidth required for a „no blocking‟ service. The model is based on the Erlang-B formula with different values of blocking probability. Our study aim is to estimate the number of server's ports supported by the down channel from the video storage source to client setup box. In P2P the video source can be the origin central video server or another client setup box. Using the estimated number of source ports, determined from Erlang-B formula for the movie traffic, the VOD system bandwidth required is then simply determined by multiplying the movie rate (according to the movie being high definition (HD) or standard definition (SD) VOD movies) by the number of source ports. The total VOD system bandwidth demand equals the sum of the server ports in use times the movie bandwidth per port stream.

3)

The distribution of VOD movie requests generally follows a Zipf-like distribution, where the VOD movies have two classes: Popular and unpopular. The relative probability of a request for i (the most popular movie) is proportional to 1/i , with 0 < < 1, and typically taking on some value less than unity. [19]. The assumption here is that all blocks of a popular movie belonging to the popular class are stored in the mesh network of the client , and if needed by a given client , they can be downloaded from its mesh network partners.

For Zipf-like distributions, the cumulative probability that one of the k popular movies class is accessed (i.e. the probability of a movie request from the client mesh network) is given asymptotically by:

 k  k      and  (1 - )/V 1-

where V is the total number of movies in the system [19]. Next, we estimate the probability (Pu) of a request for a movie that belongs to the unpopular class (i.e. does not exist in the mesh network setup boxes), and therefore should be obtained from the central head-end video server. For a VOD system with V total movies and k popular ones at the mesh network, the probability of a request for an unpopular movie stored in the head-end server is:

Pu =  k V  (2)

4)

The analytical methods for provisioning network links in this study assume steady state busy hour traffic for movie retrieval normal requests. In the steady state, multicasting is used by the network to reduce VOD traffic volumes. The network needs to deliver only one video stream (one video server port) for a group of viewers (multicast group) watching the same video or broadcast program segment. The steady state demand is therefore the total bandwidth of all video streams (or server ports) in use.

However, steady state normal request demand is usually disrupted by service interactive request and video channel surfing. One way the network can make VOD interactive changes fast is to send unicast stream (one per viewer) streams at higher than usual rates.[20] While interactive requests may be short-lived (say, a minute), each request superimposes a significant additional demand on top of the steady state demand. Thus, interactive request traffic demands that capacity planning and engineering must include interactive transient effects.

3.1 System bandwidth requirements for P2P VOD architecture:

In this section, we analyze the key-parameters that have influence on the P2P network bandwidth requirement. We carry a traffic analysis to determine the number of servers for a P2P /VOD architecture. The assumption is that the client will download the unpopular movies from high capacity centralized head end servers while the popular materials are downloaded from its multicast mesh network partners (peers) setup boxes.

We proceed as follow: Let

x = Number of VOD system cluster areas,

Z = Multicast factor (i.e. number of viewers who request the same multimedia movie within a short period of time, thus it can be served from the same server port),

h = Number of houses in VOD sys tem cluster service area,

Pu = probability of unpopular request. And is given by (2) as

Pu= 1- (k /V)

M = Number of mesh networks per cluster area

n= Average number of normal request attempts per movie per period per household,

 = Average number of interactive request attempts per movie per period per household,

tn = Holding time of a normal request for a movie in minutes,

ti = Holding time of an interactive request in minutes, and

T = Peak busy period in minutes.

P = Penetration of service in a VOD system cluster area, D = diversity factor between mesh networks in requesting unpopular movie. The maximum value is M and the average value is D=M/2

Mm = Traffic supported by mesh network peers in Earlang

[ 



] ( )

(3)

Mcm= Mesh Network Traffic supported by the broadband network from centralized head end servers

[



 ]

(4)

Now, the number of server ports (e.g. video streams ) needed by the VOD mesh network (Sm) to support traffic to a requesting client by a mesh peer to peer , can then be found

using the Erlang-B formula and the mesh network peers traffic (Mm) with a given blocking probability PB, where

(5)

Similarly using Mcm and the Erlang –B formula, we can find (Scm) the number of server ports needed by the VOD mesh network to support traffic downloaded from centralized head end servers through the broadband network. Thus,

ST = total number of server ports per mesh network = Sm+ Scm

Fig. 2. Centralized VOD FT T P Architecture.

The bandwi dth per mesh network is given by:

Wonm = ST * r : (6)

Where r is the movie stream rate (e.g. 3Mbps for SD movie),

To find the bandwidth per customer link we proceed as follow:

N = Number of connection links per mesh Network = n (n-1) / 2 assuming fully mesh connected network Sml = no of server ports per customer connection link = ST / N And

Wml = rate per customer connection link

= Sml * r (7)

To find the bandwidth per cluster broadband link we proceed as follow:

Ssc = no of server ports per cluster area broadband link = Scm * M

The cluster link bandwidth downloaded from central servers Wcsc can then be found by multiplying the corresponding number of ports with the movie bandwidth ( r). Therefore:

The cluster broadband link bandwidth = Wcsm = (Scm*M)*r

/D (8)

Using D= M/2 as average value for diversity, then Wcsm = 2*Scm*r

Finally the available bandwidth rate per household is given by:

Wmh = r*(SCm + Sm) /n = Wmh+Wcmh (9)

Overall system bandwidth from the ceteral servers is TWmh

= x * Wcsm (10)

3.2 Traffic provisioning model for a centralized architecture system

To compare the P2P bandwidth requirement with the centralized VOD system we need to estimate (Sc) the number of server ports supported by the VOD centralized network Sc can then be found using the Erlang-B formula, from the total calculated centralized network traffic (Mc) with a given blocking probability PB . The provisioning of the centralized VOD system bandwidth is determined as follow [21]: Let Mc = Total network traffic in Erlang for a centralized system.

=

[ 

 ]

P

M

S

M

L

m S

m

m L

L S

m

m





(

)

!

(

)

!

(11)

(11)

Where P = Penetration of service in a VOD system cluster

area,

(12)

And the required total centralized system bandwidth is Wc = Sc * r (13)

Bandwidth per cluster area can then be calculated by total system bandwidth Wcdivided by number of clusters x

Wclc = Bandwidth per cluster area = Wclc

= Sc * r/x = Wc / x (14)

3.2. 1 Centralized VOD customer link requirements

In this section, we analyze the traffic bandwidth per a centralized system customer link. Assuming fiber-to-the premises (FTTP) topology, as shown in Figure 2.0 each router in the path to customer, can serve multiple routers of the type below it. [20] The VOD network core router and cluster router deliver content to the edge of the network. The cluster router then forwards the video streams to An Optical Line Terminal (OLT), which in turn forwards the content to an Optical Network Unit (ONU) located close to house hold. Since each cluster area has (h) houses, and then each OLT will serve a maximum of h houses. The link from the cluster router to the OLT must therefore deliver content to h housing premises. While not all of them are customer to VOD network, it is reasonably expect to find (P * h) of VOD customers on an OLT, where as h and P as defined before.

Based on this architecture, we can estimate the required number of server ports per cluster link as:

Scc = no of server ports per cluster link (from VOD Core router to Cluster Router) in a centralized VOD system = Sc / x

And Scl = no of server ports per ONU connection link (from OLT to ONU)

= Sc /M* x where M is the number of ONUs in the cluster area.

The bandwidth per ONU is : Wonc = r *Sc/ (M * x)

(15)

and the allocated server ports per household (Wch) is given by

Sch = SC /(x *h* P)

and the allocated bandwidth per household (Wch) is given by

Wch = r* SC /(x *h* P) (16)

4. RESULTS AND PERFORM ANCE ANALYSIS

In this section we present the analysis results based on the developed traffic models. Our aim is to determine the VOD channel bandwidths per house hold required for a „no blocking‟ service. Our analysis assumes standard definition VOD (video and audio) movie resolutions and the key parameter values shown in table I.

TABLE I

KEY MODELING P ARAMETERS VALUES

n 1.5 i 4.00 T 420.00

tn 120.00 ti 6.00 M 30.00

r 3.00 Z 30.00 h 600.00

PB 0.01 X 250.00 P 0.40

n 8.00 N 28.00 Pu .1

The effects of the system parameters (such as the multicast factor, movie holding time, and the average number of requests arriving to the system during the peak period) on the required system VOD channel bandwidth are shown in Table II for both of the centralized system and the P2P network.

It is clear that the VOD system with P2P streams for this sample can reduce the required total central servers bandwidth to 5% (4217.21/86799.32=4.88%) of the bandwidth that a unicast centralized system (at z = 1) would use. Even with multicast streams (z = 30) for this sample, P2P can result good saving of the required central bandwidth further to 83% (2237.49/12901.42= 17.3%). In Fig. 3 and 4, we plot the relationship between service penetration rate, the total network bandwidth rate and the bandwidth per cluster link for P2P and central system. As Shown P2P allows great saving in both of the total servers bandwidth and the cluster link bandwidth needed to serve VOD system customers requests.

Fig. 3. T otal Bandwidth versus service penetration for P2P and VOD centralized system.

P

M

S

M

N

B

c S

c

c N

N S

c

c







(

)

!

(

)

!

0

P2P Central

0.00 5000.00 10000.00 15000.00 20000.00 25000.00

0.2 0.3 0.4 0.5 0.6 0.7

T

o

ta

l

B

a

n

d

w

id

th

i

n

M

b

p

s

Fig. 4. Cluster link bandwidth versus service penetration for P2P & centralized system.

In Fig. 5, we plot the relationship between the cluster link bandwidth and the interactive traffic request rate. As shown,

Fig. 5. Cluster link Bandwidth versus interactive traffic for VOD P2P and centralized system.

TABLE II

TOTAL BANDWIDTH REQUIRED FOR CENTRALIZED IP/VOD SYSTEM AND

P2P NETWORK (MB/S)

Multi C ast Facto r Z

C e ntralized VOD Architecture Syste m

P2P VO D Archite cture

B andwid th per cluster link Wclc B andwid th per househol d Wch Total Central Network B andwid th Wc B andwid th per cluster link Wcsm B andwid th per househol d (Wmh)

Total Network B andwid th TWmh

1 347.20 1.45

86799.3

2 8.95 4.27 4217.21

30 51.61 0.215

12901.4

2 8.95 1.743 2237.49

35 50.15 0.209

12536.5

6 8.88 1.724 2220.09

40 49.05 0.204

12262.9

0 8.83 1.710 2206.86

45 48.20 0.201

12050.0

3 8.79 1.699 2196.46

50 47.52 0.198

11879.7

3 8.75 1.690 2188.06

55 46.96 0.196

11740.3

9 8.72 1.683 2181.15

the increment of the interactive traffic, (i.e. increment of λi due to movie surfing), has a stronger impact on central system cluster bandwidth, compared to P2P system.

In Fig. 6, we plot the relationship between the available bandwidth per ONU mesh community and the service penetration rate for central and P2P systems respectively. For this, the central system has a lower bandwidth compared to P2P system due to the Peer to peer architecture utilization of the numerous clients links bandwidth and storage capacities available at clients set up boxes.

Fig. 6. Bandwidth per ONU/mesh network versus service penetration rate.

In Fig. 7, the relationship between the available bandwidth per household and the service penetration rate for central and P2P systems respectively. For this, the central system has a lower bandwidth compared to P2P.

Fig. 7. Bandwidth per house hold versus penetration service rate.

The bandwidth per house hold of the system is also dependent on the interactive traffic rate for a given service penetration and multicasting as shown in Fig. 8.

Fig. 8. Bandwidth per household versus movie requests per period per house

P2P Central, 0.00 20.00 40.00 60.00 80.00 100.00

0.2 0.3 0.4 0.5 0.6 0.7

B a n d w id th p e r C lu st e r li n k in M p b s

Se rvice Penetration

P2P Central 0.00 10.00 20.00 30.00 40.00 50.00 60.00 70.00

2.5 3.0 3.5 4.0 4.5 5.0

C lu st e r L in k B a n d w id th i n M b p s

Interactive Requests per movie per period per house

P2P Central 0 5 10 15 20

0.2 0.3 0.4 0.5 0.6 0.7

M e sh l/ O N U B a n d w id th M b p s

Se rvice Penetration

0.2 0.3 0.4 0.5 0.6 0.7

Ba n d w id th p er h o us e ho ld i n M b p s Service Penetration P2P Central, 0.00 0.50 1.00 1.50 2.00

2.5 3.0 3.5 4.0 4.5 5.0

B a n d w id th p e r h o u se h o ld i n M b p s

4.1 Comparison of architectures results and analysis. The comparison of the centralized system bandwidth requirements to the P2P system as a function of the multicast factor can be deduced from Table II. From the numerical results shown in table, we can see that a VOD cent ralized system, with more interactive unicast streams, requires a much larger overall system bandwidth channel when compared to the P2P VOD system. The P2P architecture is less efficient when looked at from the required bandwidth per household (see Figure 7). However , this not reflected on a huge bandwidth requirement on cluster links nor on the overall system bandwidth due to content exchange between mesh network clients. We therefore, can conclude that to produce designs that aim towards minimizing network costs and that also respect quality constraints, a P2P system is the better choice.

5. CONCLUSION

This paper presents a planning and bandwidth provisioning methodology for an P2P based on a functional view of a typical P2P network architecture with a steady -state peak hour traffic. Traffic models based on Erlang analysis were developed for the proposed P2P system , and for the a centralized servers systems. The impact of tuning of multiple key system parameters such as penetration rate, interactive traffic rate , and multcasting factor were investigated in detail.

The comparison of the centralized multimedia server system to the P2P system showed that P2P server approach provides better scalability through mesh networks nodes cooperation whenever there is a demand growth. Besides , P2P can result a large saving of more that 80 %. For the required system bandwidth.

REFERENCES

[1] Frederic T houin and Mark Coates, "Video-on-Demand Networks: Design Approaches and Future Challenges", IEEE Network Magazine, March/April 2007.

[2] Yifeng He, Ivan Lee, and Ling Guan , “ Distributed T hroughput Maximization in P2P VoD Applications “ , IEEE T ransaction on Multimedia , Vol. 11, No. 3, April 2009

[3] Abdelhamid Nafaa, Sean Murphy, and Liam Murphy, “ Analysis of a LargeScale VOD Architecture for Broadband Operators: A P2P -Based Solution” , IEEE Communications Magazine December 2008. [4] D.E. Smith, Walfham, "IP T V Bandwidth Demand: Multicast and Channel Surfing", IEEE International Conference on Computer Communications INFOCOM 2007. Anchorage, AK, May 2007.

[5] Agrawal, D.; Beigi, M.S.; Bisdikian, C.; Kang-Won Lee , “ Planning and Managing the IPT V Service Deployment” . 10th IFIP/IEEE International Symposium on Integrated Network Management, 2007. Volume 25 , Issue 21, May 2007 Page(s):353 – 362

[6] S. Annapureddy et al., “ Exploring VoD in P2P Swarming Systems,” Proc. INFOCOM ‟07,Anchorage, AK, May 2007, pp. 2571 –75. [7] T . T . Do, K. A. Hua, and M. A. T antaoui, “ P2VoD: Providing fault

tolerant video-on-Demand streaming in peer-to-Peer environment,” in Proc. IEEE ICC, Jan. 2004, vol. 25, no. 1, pp. 119 –130.

[8] H. Chi, Q. Zhang, J. Jia, and X. Shen, “ Efficient search and scheduling in P2P -based media-on-demand streaming service,” IEEE J. Select. Areas Commun., vol. 3, no. 6, pp. 1467 –1472, Jun. 2006. [9] Y. Cui, B. Li, and K. Nahrstedt, “ oStream: Asynchronous streaming

multicast,” IEEE J. Select. Areas Commun., vol. 22, no. 1, pp. 91–106, Jan. 2004.

[10] J. Li, “ Peerstreaming: An on-demand peer-to-peer media streaming solution based on a receiver-driven streaming protocol,” in Proc. IEEE MMSP, Oct. 2005, pp. 1–4.

[11] X. Liao et al., “ AnySee: Peer-to-Peer Live Streaming,” Proc. IEEE INFOCOM ‟06, Barcelona, Spain, Apr. 2006, pp. 1 –10.

[12] M. Hefeeda et al., “ PROMISE: Peer-To-Peer Media Streaming Using Collectcast,” Proc. ACM MULT IMEDIA ‟03, Berkley, CA, Nov. 2003, pp. 45–54.

[13] V. Janardhan and H. Schulzrinne, “Peer Assisted VoD for Set -Top Box Based IP Network,” Proc. ACM SIGCOMM ‟07 Wksp. Peer-to-Peer Streaming IP -T V, Kyoto, Japan, Aug. 2007, pp. 335 –39. [14] Y. Shen, Z. Liu, S. S. Panwar, K. W. Ross, and Y. Wang, “ Streaming

layered encoded video using peers,” in Proc. ICME, Jul. 2005. [15] X. Xu, Y. Wang, S. P. Panwar, and K. W. Ross, “ A peer-to-Peer

video-on-Demand system using multiple description coding and server diversity,” in Proc. IEEE ICIP, Oct. 2004, vol. 3, pp. 1759 –1762. [16] A. Nafaa, S. Murphy, and L. Murphy, "Analysis of a large-scale IP/VOD architecture for broadband operators: a P2P -based solution", Communications Magazine, IEEE, Volume 46, Issue 12, December 2008, pp. 47-55.

[17] M. M. Hefeeda, B. K. Bhargava, and D. K. Y. Yau, “ A Hybrid Architecture for Cost -Effective On-Demand Media Streaming,” Computer Networks, vol. 44, 2004, pp. 353 –82.

[18] Begen, A. Glazebrook, N. Steeg, W. “ Reducing Channel-change T imes with the Real –T ime transport Protocol” , IEEE Internet Computing , Volume: 13, Issue: 3 , June 2009 p: 40-47

[19] L. Breslau et al., "Web Caching and Zipf-like Distributions: Evidence and Implication", Proc. IEEE INFOCOM 99, New York, March 1999, pp.126-34.

[20] Donald E. Smith , “ IP TV Bandwidth Demand: Multicast and Channel Surfing” , Proc. IEEE INFOCOM ‟07, 2007 , pp 2546 - 2550 [21] Sami S Alwakeel , “ Bandwidth Provisioning Models for a Large Scale

Fig. 3. T otal Bandwidth versus service penetration for P2P and VOD centralized system.

Fig. 4. Cluster link bandwidth versus service penetration for P2P & centralized system.

P2P Central

0.00 5000.00 10000.00 15000.00 20000.00 25000.00

0.2 0.3 0.4 0.5 0.6 0.7

To

ta

l B

a

n

d

w

id

th

i

n

M

b

p

s

Service Penetration

P2P Central

0.00 10.00 20.00 30.00 40.00 50.00 60.00 70.00 80.00 90.00 100.00

0.2 0.3 0.4 0.5 0.6 0.7

B

a

n

d

w

id

th

p

er

C

lu

st

er

li

n

k

i

n

M

b

p

s

Fig. 5. Cluster link Bandwidth versus interactive traffic for VOD P2P and centralized system

Fig. 6. Bandwidth per ONU/mesh network versus service penetration rate.

P2P Central

0.00 10.00 20.00 30.00 40.00 50.00 60.00 70.00

2.5 3.0 3.5 4.0 4.5 5.0

C

lu

st

er

li

n

k

B

a

n

d

w

id

th

in

M

b

p

s

Interactive Requests per movie per period per house

P2P

Central

0 2 4 6 8 10 12 14 16 18 20

0.2 0.3 0.4 0.5 0.6 0.7

M

es

h

l/

O

N

U

B

a

n

d

w

id

th

i

n

M

b

p

s

Fig. 7. Bandwidth per house hold versus penetration service rate.

Fig. 8. Bandwidth per household versus movie requests per period per house

P2P

Central

0.00 0.50 1.00 1.50 2.00 2.50

0.2 0.3 0.4 0.5 0.6 0.7

B

a

n

d

w

id

th

p

er

H

o

u

se

h

o

ld

in

M

B

Service Penetration

P2P

Central,

0.00 0.20 0.40 0.60 0.80 1.00 1.20 1.40 1.60 1.80

2.5 3.0 3.5 4.0 4.5 5.0

B

a

n

d

w

id

th

p

er

h

o

u

se

i

n

M

b

p

s

Cluster Router

Router

Head-End VOD Servers

Core Router

Router

Head-End

Switch

Request Traffic Control Traffic VOD Traffic

Fig 1. Peer to Peer VOD Architecture

VSO

Peer

Network

Client STB

Peer Swi tch

Switch

VHO Controller Client

STB

Peer Swi tch

Switch

Client STB

Peer Swi tch

Fig. 2. Centralized VOD FT T P Architecture

TABLE I

KEY MODELING P ARAMETERS VALUES

n 1.5 i 4.00 T 420.00

tn 120.00 ti 6.00 M 30.00

r 3.00 Z 30.00 h 600.00

PB 0.01 X 250.00 P 0.40

TABLE II

TOTAL BANDWIDTH REQUIRED FOR CENTRALIZED IP/VOD SYSTEM AND P2P NETWORK (MB/S)

Multi Cast Factor Z

Centralized VOD Architecture System P2P VOD Architecture

Bandwidth per cluster

link

Wclc

Bandwidth per household

Wch

Total Central Network Bandwidth

Wc

Bandwidth per cluster

link

Wcsm

Bandwidth per household

(Wmh)

Total Network Bandwidth

TWmh

1 347.20 1.45 86799.32 8.95 4.27 4217.21

30 51.61 0.215 12901.42 8.95 1.743 2237.49

35 50.15 0.209 12536.56 8.88 1.724 2220.09

40 49.05 0.204 12262.90 8.83 1.710 2206.86

45 48.20 0.201 12050.03 8.79 1.699 2196.46

50 47.52 0.198 11879.73 8.75 1.690 2188.06