International Conference on Computing, Networking and Communications, Internet Services and Applications Symposium

On Zap Time Minimization in IPTV Networks

Matthew Long, Sridhar Radhakrishnan, Suleyman Karabuk, John Antonio School of Computer Science School of Industrial Engineering School of Computer Science University of Oklahoma University of Oklahoma University of Oklahoma Norman, Oklahoma 73019 Norman, Oklahoma 73019 Norman, Oklahoma 73019 E-mail: {mglong, sridhar}@ou.edu E-mail: [email protected] E-mail: [email protected]

Abstract—Digital television systems have a clear disadvantage state-of-the-art. These advantages include a) wherever Internet relative to analog systems in users’ quality of experience, most access is available, broadcast channels can be delivered and notably in the time required to change channels, or zap time. this eliminates the need for additional infrastructure (such as The goal of this research is to improve the performance of a multicasting IPTV network, both in user experience and in cable or satellite), b) the broadcast content can be viewed on resource consumption. We formulate the problem of assigning any device that has an Internet connection and appropriate IPTV clients to servers as an integer programming model, in video display without the need for specialized STB hardware, variants which minimize channel-change times, overall network and c) bandwidth can be conserved as only the users watching capacity consumption, or both. This problem is shown to be a particular channel need to receive it. Several organizations computationally hard, and the performance of the models is tested on problems of different sizes. Polynomial-time heuristics have set standards for implementing IPTV networks, including are presented which address a relaxed version of the problem, ETSI TISPAN, the DVB Project, and the Open IPTV Forum and the performance of these heuristics is measured. [2], [13], [1]. These standards define functionality, protocols, Index Terms—IPTV Networks, Multicast, Integer Program- and architectures for IPTV systems. IPTV standards typically ming, NP-Hardness include Video on Demand (VoD) functionality in addition to “broadcast” channels, but VoD is outside the scope of this I. INTRODUCTION paper. There has been explosive growth in video traffic on the While there are significant advantages to IPTV, it suffers Internet due to a combination of an increase in the number from long zap times. Imagine a user on a laptop computer of video content providers, ubiquity of devices capable of switching between broadcast channels. Each time the user viewing video content, and keen interest among the viewing switches to a different channel, a program on the laptop will public. Video on the Internet is either broadcast (e.g., NBC’s establish a connection to a server in the IPTV network and wait streaming of the Olympic Games) or provided on demand for the new channel to begin streaming from it. This delay is (e.g., Netflix and Hulu’s services). proportional to the network latency between the laptop and Cable companies deliver all broadcast channels to the end the contact server. Depending on the location of the server, system (e.g., a set-top box, or STB) at home and, depending this delay will vary, and the greater this delay, the lesser the upon the subscription criteria, a subset of these channels are Quality of Experience (QoE) for the end user. viewable by the end user. In this scheme the cable company The goal of this research is to improve QoE in an IPTV streams as many channels as can be accommodated on the network by minimizing zap time and bandwidth consumption. cable. This is true of satellite television, which also requires a Towards this goal, we consider a network of servers connected specialized STB to deliver content and delivers all broadcast to form a rooted tree (a multicasting tree) with network delay channels to the end system. The significant advantage of and bandwidth specified on each link, and a set of clients, systems that broadcast all channels is that the user experiences each of which requires a subset of the channels carried by the almost no delay when changing channels, as the content is tree. (Each client has a network delay defined between it and already being delivered to the user’s STB. The time interval each server.) One can imagine these intermediate servers to between the user keying in the change channel request and the be connected to end offices of Internet Service Providers and display of the contents of the new channel on the user’s screen hence be well-provisioned, with minimal server-to-server link is termed as the zap time. For analog cable and satellite tele- delays. The root of the tree is the server, r, that is the source of vision viewers, the zap time is insignificant. Digital broadcast all channels. Each intermediate node may duplicate the content systems require additional time to buffer and begin decoding it receives from its parent and send it to a subset of its children the compressed channel, and therefore have somewhat longer in the tree. To conserve bandwidth, a node only redistributes zap times. channels to those of its children who request them. If a server There has been a growing interest in delivering broadcast k is receiving a particular channel c, then all servers in the video channels through the Internet (or other IP networks). path from k to r have channel c, and can immediately satisfy Broadcast channels delivered via an IP network is termed any request for it. as IPTV. IPTV offers significant advantages over the current A client is an end system that has requests for a set of

978-1-4673-0009-4/12/$26.00 ©2012 IEEE 713 channels. (For example, each client may have a set of favorite Cha et al. [7] and Qiu et al. [14] have investigated channel channels collected over time or a set of channels to which popularity dynamics in IPTV systems. Both papers used large it subscribes.) Each client has to connect to the appropriate channel-change datasets from actual IPTV networks. Cha server (introducing network delay) for each of its channel found that more than 60% of channel changes are linear; i.e., to requests. Now, given a multicasting tree as above and a set of the next- or previous-numbered channel. Both concluded that clients with channel requests, our goal is to find the appropriate channel popularity distributions resemble a Zipf distribution, server for each client to connect to for each of its channel with the few most popular channels accounting for most of requests. (Because bandwidth is a limited, potentially shared the viewing. Qiu’s main contributions were improved mathe- resource, specifying that every server carries every channel is matical models of user behavior, which have the potential to not an option.) improve simulations of IPTV systems in further research. We first develop a series of mixed integer programming (MIP) models of our problem. We then show that the problem II. PRELIMINARIES is NP-hard. We show the results of solving many problem The Client Assignment Problem (CAP) is defined as the instances. Toward a scalable solution to these problems, we satisfaction of a set of demands for channels (or, equivalently, provide polynomial-time heuristic algorithms for a relaxed channel requests) by assigning each demand to be fulfilled version of the problem, which take into consideration various by a node of a multicasting tree (i.e., an IPTV network). A tradeoffs between link capacity and zap time. These heuris- client’s channel requests need not be satisfied by the same tics have been evaluated empirically using many problem server; fulfilling requests from a client with different servers instances. can use fewer network resources or provide better zap time than fulfilling them with a single server. (A client could request A. Related Work multiple channels for a variety of reasons; e.g., picture-in- Zap time is the channel change time as perceived by picture or multi-channel recording.) Channels are assumed the viewer. Its primary components are multicast join time, to require equal bandwidth, so server-server link capacities network latency, buffering and decoding, error correction, and (bandwidths) are given in units of channels. Additionally, all access control [10], [17]. Zap time is a major factor in the components of zap time other than round-trip time are ignored viewer’s Quality of Experience (QoE): both shorter zap times (e.g., buffering and decoding delays). The CAP is an offline and consistency in zapping are preferred. problem; demands are unordered and are known in advance. A client needs to buffer a certain amount of data to decode CAP shares some characteristics with facility location and the channel stream; this buffer must begin with a random network flow problems, but differs from them in several ways. access point (RAP). A RAP is a block of the stream that is Facility location (FL) problems involve placing facilities to independent of the rest of the stream; e.g., an I-frame. (Most serve clients. The location of facilities (once placed) and video frames are not transmitted in full; displaying such frames clients are fixed. The cost of serving a client is a function requires reference to previous or subsequent frames.) There of the distance between the facility and the client. There are are two ways to reduce the time to fill the decoder’s buffer: multicommodity variants of FL, in which clients may demand the encoding of the stream could be changed such that less different kinds of goods or services, and capacitated variants, buffering is required, or the buffer could be filled faster. Video in which a facility’s ability to produce is limited. The critical encodings can be adjusted to balance bandwidth consumption difference between (multicommodity, capacitated) FL and a and buffering requirements by varying the frequency of RAPs multicasting IPTV network is that FL features no relation- within the stream. ship between facilities, while multicasting has dependencies Waiting for a RAP is a significant source of delay when between servers (i.e., a tree hierarchy). Additionally, facility changing channels; Begen at al. [6], [5] and Sasaki et al. location is performed in a metric space, but network delay [16] have addressed this issue with retransmission schemes. does not obey the triangle inequality and is therefore not a In both works, each channel stream is buffered, from the most metric. recent RAP, by retransmission servers, and is retransmitted to Network flow problems involve defining paths between a client just joining the channel. Begen’s scheme retransmits source and sink nodes in a graph, usually such that the total with a unicast burst, deferring multicast join until the burst cost of the paths (flows) is minimized. Variants include multi- is underway. Sasaki’s scheme sets up additional multicast commodity flow (MCF), in which different commodities share streams for retransmission, delayed by some constant factor link capacity (different commodities may consume different relative to the main stream. A client joining the main stream amounts of link capacity). Typical MCF problems rely on temporarily joins the retransmission stream, so its buffer fills mass balance constraints, which require that an intermediate more quickly than it otherwise would (any redundant data, node’s total input must equal its total output; however, this received from both streams, is discarded). Sasaki’s work was kind of constraint does not apply in computer networking, an tested in a production IPTV system, which showed an average environment in which the “commodities” are data, which may 0.5-second reduction in zap time. Begen’s tests, though not be trivially duplicated. real-world, showed a 65% decrease in mean zap time and a Applegate et al. have taken an approach similar to ours 60% decrease in the variation in zap time [6]. to placing content in VoD content distribution networks to

714 minimize bandwidth consumption and storage consumption present in MZ, MZCB, and MBCZ, is an upper bound on [4]. However, unlike their model, the servers in our problem the zap time for satisfied demands. From the input data and are strictly hierarchical, and channels are distributed by mul- the values of these variables, the zap time for each demand ticasting, rather than unicasting. and overall bandwidth consumption can be calculated for a There are four variants of CAP, which are discussed in given solution. Section III. These variants minimize maximum zap time, total bandwidth consumption, or a combination of the two A. Variant MB: Minimize bandwidth consumption objectives. The first variant of the CAP minimizes the overall band- III. IP MODELS width consumption of the network. This variant is the model as stated above. Let C be the set of clients, where |C| = m. Let S be the |S| = n n ≤ m K set of servers, where and . Let be the set of B. Variant MZ: Minimize maximum zap time channels, where |K| = p. Let M = mnp. Let Tij be the link capacity between two servers i and j, in units of channels. Let The second variant of the CAP minimizes the maximum zap server 0 be the root server. Let p : S\{0}→S yield the parent time, over all clients and all channels. This variant assigns of a server, and let s : S → 2S yield the successors of a server. clients so as to achieve the best overall performance/QoE, Let ci be the capacity of server i. Let Zijk be the zap time regardless of cost (i.e., network resource consumption). This z for client i to receive channel k from server j. (These values variant has an additional integer variable, , and the additional are calculated from server-server and server-client latencies.) constraint (6) that the zap time for any demand does not exceed z Let dik =1if client i demands channel k, and 0 otherwise. . Let yijk =1if server i sends channel k to server j, and ∀i ∈ C, j ∈ S, k ∈ K : xijkZijk ≤ z (6) 0 otherwise. Let xijk =1if client i receives channel k from z server j, and 0 otherwise. The IP formulation of CAP is then The objective function of this variant is ; i.e., the upper bound on zap time over all demands. as follows:    Minimize yijk i∈Cj∈Sk∈K C. Variant MZCB: Minimize maximum zap time, controlling Subject to bandwidth consumption  ∀i ∈ C, k ∈ K : d = x The third variant of the CAP combines the concerns of cost ik ijk (1) and performance, giving priority to cost (bandwidth consump- j∈S tion). This variant is equivalent to MZ, with the additional  constraint (7) that the network’s bandwidth consumption must ∀j ∈ S\{0} ,k∈ K : yjlk ≤ Myp(j),j,k (2) l∈s(j) remain “close” to the optimal value as determined by MB.  This is accomplished by adding a constraint to MZ that limits bandwidth consumption to less than or equal to MB’s optimal ∀i ∈ C, j ∈ S\{0} : xijk ≤ Myp(j),j,k (3) B t k∈K bandwidth, , plus a tolerance percentage .   ∀j ∈ S : y ≤ T p(j),j,k p(j),j (4) yijk ≤ (1 + t) B (7) k∈K i∈Cj∈Sk∈K  ∀j ∈ S : xijk ≤ cj (5) As in MZ, the objective function of MZCB is z, the upper i∈Ck∈K bound on zap time over all demands. Constraint 1 ensures that each channel demand is satisfied D. Variant MBCZ: Minimize bandwidth consumption, control- by one server. Constraints 2 and 3 control channel propagation ling zap time (i.e., they ensure a path to the root for each server for every channel it carries). The root server, as the source of all The fourth variant of the CAP, like the third, addresses both channels, is excluded from both of these constraints. (M is an the performance and the cost of the solution. This variant pri- upper bound on the sums in constraints 2 and 3.) Constraint oritizes zap time (QoE) over bandwidth consumption. MBCZ 2 requires that a server must be receiving a channel in order has constraint 6, and an additional constraint (8), which limits to send it to another server. Constraint 3 requires that a server maximum zap time to less than or equal to MZ’s optimal sending a channel to a client must be receiving that channel maximum zap time, Z, plus a tolerance percentage t. from its parent server. Constraint 4 ensures that server-to- z ≤ (1 + t) Z server channel capacities are respected. Constraint 5 ensures (8) that servers’ outgoing channel capacities are respected.    MBCZ’s objective function is yijk (total band- The x- and y- variables of a solved problem instance encode i∈Cj∈Sk∈K an optimal propagation of channels from the root server to width consumed by sending channels between servers), as in other servers, and from servers to clients. The z variable, MB.

715 Require: tree, demands, latencySS, latencyCS, outcap IV. NP-HARDNESS OF CAP Ensure: xs, ys The NP-hardness of CAP is proved by reduction from the 1: initialize xs, ys {initialized to zero} 2: demandList ← demands grouped by channel optimization version of minimum set cover, along the lines of 3: sort demandList in ascending order of size {size is measured in number the argument used in [15]. Set cover is the problem of, given of clients} X F X 4: calculateZapTimes(tree, latencySS, latencyCS, outcap) a finite set and a family of subsets of such that every |demandList| > 0 X F 5: while do element of belongs to at least one subset in , finding a 6: d ← demandList.pop() {get last (largest) demand} minimum-cardinality covering C ⊆ F such that X = s 7: s ← bestServer() {server with greatest remaining capacity, ignoring s∈C capacity constraints} [8]. The optimization version of minimum set cover is known 8: makeAssignment(d, s) to be NP-hard [11]. 9: end while The reduction is accomplished by transforming set cover Figure 1. Greatest Residual Capacity (GRC) algorithm to a special case of CAP Variant 4 (MBCZ). The set X is mapped to the set of clients in CAP. The set F of subsets of X is mapped to the set of servers in CAP; there is an additional channel. BZ is an online algorithm, which processes clients F server, the root, which is not mapped to any member of . in arbitrary order, recalculating zap times after each client’s The root is the parent of every other server. The root has zero channel requests have been fulfilled. (Satisfying a client’s capacity (i.e., it cannot serve clients), and each other server has requests is assumed to be an atomic operation.) capacity equal to the cardinality of its corresponding member of F . Each link between servers has one unit of capacity and B. Best Zap Time in Path (BZP) zero zap time. The zap time between the client mapped to The goal of BZP is to compromise between minimizing x ∈ X f ∈ F x ∈ f and the server mapped to is zero if , and bandwidth consumption and reducing zap times. It takes ad- is one otherwise. There is one channel, which is demanded by vantage of the digital nature of the channels being distributed: all clients. if server i is sending channel k to a client, channel k is CAP Variant MBCZ minimizes the total bandwidth con- available to every server on the path from i to the root of the sumed by satisfying all demands, while maintaining a maxi- server tree, at no additional bandwidth cost. For each group of mum zap time within a certain tolerance of its optimal value. clients who want channel k, BZP finds the server s that gives For this reduction, the tolerance is 0%; e.g., the maximum zap the least zap time for that set of clients. Then, each client time must be equal to its optimal value. Minimizing maximum requesting k is assigned to receive k from the server in the zap time, for this special case, means maintaining zero zap path from s to the root which gives the best zap time. time for all clients; this means that the client mapped to x ∈ X can only connect to the server mapped to f ∈ F if x ∈ f. C. Greatest Residual Capacity (GRC) Minimizing the total bandwidth consumed, in this case, is The Greatest Residual Capacity (GRC) heuristic is a equivalent to minimizing the size of the cover, because each straightforward adaptation of the Longest Processing Time server corresponds to a set that can contribute to the cover, (LPT) heuristic for multiprocessor job scheduling. LPT assigns and each server will consume either zero bandwidth, if not each job, in non-increasing order of processing time, to the used, or one bandwidth, if it is used in the cover (because processor with the greatest remaining capacity. GRC addresses there is only one channel, and a channel is transmitted at most bandwidth (link capacity) consumption by grouping demands once between any pair of servers). Because any instance of set by channel and assigning each such group (from largest to cover can be represented as an instance of CAP (MBCZ), it is smallest) to the server with the most remaining capacity. concluded that CAP (MBCZ) is at least as hard as minimum Figure 1 shows the GRC algorithm. set cover; i.e. it is NP-hard. RCAP is equivalent to Extendible Bin Packing (EBP) if V. T HE RELAXED CAP link capacities are ignored. An item is equivalent to a group of Toward a fast approximation algorithm for CAP, we relax demands for the same channel, as long as the group is assigned the problem by removing link and node capacity constraints. to a server as a unit. A bin with a capacity is equivalent This makes the problem significantly easier, primarily due to a server node which can serve a maximum number of to the removal of the link capacity constraints, which, as demands. Exceeding the capacity of a bin is equivalent to bundling constraints, are known to increase the difficulty of assigning more clients to a server than that server can serve. network flow problems [3]. We present three polynomial-time Dell’Olmo and Speranza show that the Longest Processing heuristic algorithms for the relaxed CAP (RCAP): BZ, BZP, Time (LPT) heuristic approximates√  EBP to within a perfor- 2 2 − 2 and GRC. BZ addresses zap time, GRC addresses bandwidth mance ratio of [9]; therefore, GRC achieves the consumption, and BZP addresses both zap time and bandwidth same performance on CAP if only node capacity is considered. consumption. VI. PERFORMANCE EVALUATION A. Best Zap Time (BZ) The CAP models’ performance was tested for increasing The Best Zap Time heuristic assigns each channel request problem sizes. For these tests, the server and client counts to the server which gives the least zap time for that client and were set at 5 and 20 respectively, then scaled by 1.25 after each

716 100 MB size step. The networks used were random trees. Ten channels MZ MZCB were used. Each link in a server tree had [1, 10] units of MBCZ capacity. Server-server and server-client links had [16, 32]ms 10 and [32, 64]ms latency, respectively. Each client requested   two d d of the ten channels, at random. Each server had [ n , 2 n ] d 1

units of capacity, where is the total number of demands in the Time (s) problem instance. The tolerance used for variants MBCZ and

MZCB was 10%. At each size step, 50 CAP instances were 0.1 generated, and each was solved using the Gurobi Optimizer [12]. Problem generation, optimization, and result aggregation 0.01 were performed by Python code, which interacted with Gurobi 10 via its Python API. Figures 2 - 4 show the mean runtime, mean Size of problem (servers) maximum zap time, and mean bandwidth consumption at each Figure 2. Mean runtime by CAP variant (95% confidence intervals shown) size step, with 95% confidence intervals. The time required to optimize CAP instances grows exponentially as problem size 250 MB MZ increases (Figure 2), with variant MZCB’s runtime growing 240 MZCB MBCZ the most quickly. 230

The difference between MZ’s bandwidth consumption and 220

MBCZ’s (Figure 4) shows that allowing maximum zap time to 210 exceed its optimal value by a small amount (10% in this case) 200 can reduce network resource consumption by a large amount Zap time (ms) 190 (approximately 50% in this case). There is a similar difference 180 between MB’s and MZCB’s bandwidth consumption, but it is 170 not as pronounced. 160 Heuristics BZ, BZP, and GRC were used to solve 50 150 4 5 6 7 8 9 10 11 CAP instances (ignoring capacity constraints) with 10 servers Size of problem (servers) and 40 clients, and two random channel requests per client. Figures 5 and 6 show maximum zap time and bandwidth Figure 3. Mean maximum zap time by CAP variant (95% confidence intervals consumption distributions, respectively. BZ gives the best zap shown) times and the worst bandwidth consumption, while GRC gives the worst zap times. While BZP consumes less bandwidth than GRC, it violates server capacity constraints to a greater In Section V, we introduced heuristic algorithms for a relaxed degree than does GRC; it may therefore be less useful as a CAP. Finally, in Section VI, we show the performance of the basis for approximating optimal solutions to CAP. (Though CAP models and of the heuristics for the relaxed CAP. not discussed in detail in this paper, we have found that In an actual IPTV network, channels may be introduced solutions to RCAP by these algorithms, used as initial states, at multiple levels of the network (for example, local news in some cases significantly improve the quality or speed of channels will be introduced at the local level, not at the the optimizer’s solutions. BZP, however, was shown to have national level). Representing this capability in an updated CAP no significant effect on the final solution’s maximum zap time, would increase the verisimilitude of our model. Removing the bandwidth consumption, or optimizer runtime.) assumption that all channels require equal bandwidth would Finally, the runtime of the optimizer on all four CAP also increase the usefulness of the CAP. variants was compared to the runtime for BZ, BZP, and GRC CAP as formulated in Section III is an offline problem; for problems of larger sizes. (Again, there are four clients it assumes that the network is initially idle, and that de- for each server.) As seen in Figure 7, optimizing CAP is mands are unordered and are known ahead of time. This computationally expensive, while solving RCAP is much less is a simplification, as actual television channel changes are so. Included in this plot are runtimes for optimizing RCAP, to spontaneous and unpredictable. Zap times are precalculated for illustrate the difficulty added to the problem by the link and each combination of client, server, and channel. The channel server capacity constraints. BZ’s (online) runtime grows more component is not needed unless there is some initial state. quickly than that of the other heuristics, though more slowly Adding initial state (i.e., starting with non-idle network) is than that of the optimizer; this is caused by the recalculation easily accomplished by adding constraints to fix some x- and of zap times after satisfying each client’s demands. y-variables. This approach could be iterated in order to apply the optimizer to an online CAP. However, optimization is too VII. CONCLUSIONS time-consuming to be used in practice, in this kind of system. We have formulated the Client Assignment Problem (CAP) A fast approximation algorithm for the CAP would allow much as an integer programming model (in four variants) in Section larger simulations to be performed, and could potentially be III, and in Section IV, we have shown CAP to be NP-hard. applied to improve the performance of an actual IPTV system.

717 35 50 MB GRC MZ BZ MZCB BZP MBCZ 30 40

25

30

20

20 Number of Problems 15

Network capacity consumption (channels) 10 10

5 0 4 5 6 7 8 9 10 11 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 Size of problem (servers) Link Capacity Consumed (channel)

Figure 4. Mean bandwidth consumption by CAP variant (95% confidence Figure 6. Bandwidth consumption distributions for BZ, BZP, and GRC intervals shown)

100 MB 50 MZ GRC MZCB BZ MBCZ BZP MB-relaxed MZ-relaxed MZCB-relaxed 10 MBCZ-relaxed 40 GRC BZ BZP

30 1 Time (s)

20 Number of Problems 0.1

10

0.01 1 10 100 0 Problem size (servers) 0 1 2 3 4 5 6 7 8 9 10111213141516171819202122232425262728293031323334353637 Maximum Zap Time (ms * 10) Figure 7. Mean runtime (per problem) for CAP model variants and RCAP Figure 5. Maximum zap time distributions for BZ, BZP, and GRC heuristics

REFERENCES [10] H. Fuchs and N. Farber. Optimizing channel change time in iptv applications. In Broadband Multimedia Systems and Broadcasting, 2008 [1] Open iptv forum service and platform requirements v2.0, 12 2008. IEEE International Symposium on, pages 1 –8, 31 2008-april 2 2008. [2] Etsi ts 182 027 v3.5.1 iptv architecture: Iptv functions supported by the [11] Michael R. Garey and David S. Johnson. Computers and Intractability: ims subsystem, 3 2011. A Guide to the Theory of NP-Completeness. W. H. Freeman and [3] Ravindra K. Ahuja, Thomas L. Magnanti, and James B. Orlin. Network Company, 1979. Flows. Prentice Hall, 1993. [12] Gurobi Optimization. Gurobi optimization (http://www.gurobi.com/). [4] David Applegate, Aaron Archer, Vijay Gopalakrishnan, Seungjoon Lee, [13] DVB Project. Dvb-iptv standards. and K. K. Ramakrishnan. Optimal content placement for a large-scale http://www.dvb.org/technology/standards/. vod system. In Proceedings of the 6th International COnference, Co- [14] Tongqing Qiu, Zihui Ge, Seungjoon Lee, Jia Wang, Qi Zhao, and Jun Xu. NEXT ’10, pages 4:1–4:12, New York, NY, USA, 2010. ACM. Modeling channel popularity dynamics in a large iptv system. In Pro- [5] A.C. Begen, N. Glazebrook, and W. Ver Steeg. A unified approach ceedings of the eleventh international joint conference on Measurement for repairing packet loss and accelerating channel changes in multicast and modeling of computer systems, SIGMETRICS ’09, pages 275–286, iptv. In Consumer Communications and Networking Conference, 2009. New York, NY, USA, 2009. ACM. CCNC 2009. 6th IEEE, pages 1–6, Jan. 2009. [15] R. Ravi and A. Sinha. Multicommodity facility location. In Proceedings [6] Ali Begen, Neil Glazebrook, and William Ver Steeg. Reducing channel- of the fifteenth annual ACM-SIAM symposium on Discrete algorithms, change times with the real-time transport protocol. IEEE Internet SODA ’04, pages 342–349, Philadelphia, PA, USA, 2004. Society for Computing, 13(3):40–47, May-June 2009. Industrial and Applied Mathematics. [7] Meeyoung Cha, Pablo Rodriguez, Jon Crowcroft, Sue Moon, and [16] C. Sasaki, A. Tagami, T. Hasegawa, and S. Ano. Rapid channel Xavier Amatriain. Watching television over an ip network. In IMC zapping for iptv broadcasting with additional multicast stream. In ’08: Proceedings of the 8th ACM SIGCOMM conference on Internet Communications, 2008. ICC ’08. IEEE International Conference on, measurement, pages 71–84, New York, NY, USA, 2008. ACM. pages 1760 –1766, may 2008. [8] Thomas Cormen, Charles Leiserson, Ronald Rivest, and Clifford Stein. [17] Peter Siebert, Tom N. M. van Caenegem, and Marcel Wagner. Analysis Introduction to Algorithms. McGraw-Hill Book Company, 2 edition, and improvements of zapping times in iptv systems. IEEE Transactions 2001. on Broadcasting, 55:407–418, 2009. [9] P. Dell’Olmo and M. G. Speranza. Approximation algorithms for partitioning small items in unequal bins to minimize the total size. DISCRETE APPLIED MATHEMATICS, 94(1-3):181 – 191, 1999.

718