Streaming Multimedia Resources For Delivering Iptv Services

Published Date: 02 Nov 2017

Abstract----Cloud computing is a new infrastructure environment that delivers on the promise of supporting on-demand services in a flexible manner by scheduling bandwidth, storage and compute resources on the fly. In an on-demand video server environment, clients make requests for movies to a centralized video server. Due to the stringent response time requirements, continuous delivery of a video stream to the client has to be guaranteed by reserving sufficient resources required to deliver a stream. Hence there is a hard limit on the Number of streams that can be simultaneously delivered by a server. The server can satisfy multiple requests for the same movie using a Single disk I/O stream by sending the same data pages to multiple Clients (using the multicast facility if present in the system). In this paper, we seek to lower a provider’s costs of real-time IPTV services through a virtualized IPTV architecture and through intelligent timeshifting of service delivery.

INTRODUCTION

With the rapid growth of broadband deployment to homes, IP-based distribution of real-time television (IPTV) [1] is now a reality. The term IPTV refers to an array of video services (including "linear-TV", i.e., real-time programming, and video-on-demand) where the video is compressed, transmitted to subscribers over an IP packet data network, and played through high-speed communication networks by geographically distributed clients.

Due to stringent response time requirements, continuous delivery of a stream has to be guaranteed by reserving the resources needed for delivery (e.g. disk bandwidth, CPU) [1]. These resources are referred to as a logical channel in the paper. Hence there is a hard limit on the number of streams that can be simultaneously delivered by a server.

Consider how IPTV is delivered. For the purposes of this paper, we only address the use of IPTV for the delivery of linear broadcast TV. IPTV typically uses IP multicast to deliver the content, using a distinct multicast group for each TV channel. There are typically several hundred channels. The consumer’s set-top box "tunes" to a particular TV "channel" by joining the multicast group for that channel. There is a channel switching latency due to the time taken to join the multicast group and (more significantly) a time to wait for an I-frame and then fill up the play-out buffer for the new channel (to prevent underflow and the resulting jerky/stalled play out). The total channel switching latency can be several seconds, causing unacceptable quality of experience to users who may want to surf or browse channels. In contrast, with traditional over-the-air broadcasting, or cable-based analog systems that do not utilize a packetized video distribution, the set top box (STB) receives all the channels simultaneously. When the user changes channels, the STB immediately "tunes" to the new channel and begins displaying it on the screen. Hence the channel change time in such a system is minimal. But such systems are dramatically wasteful in the use of network resources to minimize this delay, techniques called "Instant Channel Change" (ICC) have been proposed.

Our goal in this paper is to take advantage of the difference in workloads of the different IPTV services to better utilize the deployed servers. For example, while ICC workload is very bursty with a large peak to average ratio, VoD has a relatively steady load and imposes "not so stringent" delay bounds. More importantly, it offers opportunities for the service provider to deliver the VoD content in anticipation and potentially out of- order, taking advantage of the buffering available at the receivers. We seek to minimize the resource requirements for supporting the service by taking advantage of statistical multiplexing across the different services - in the sense; we seek to satisfy the peak of the sum of the demands of the services, rather than the sum of the peak demand of each service when they are handled independently. Virtualization offers us the ability to share the server resources across these services.

In this paper, we aim a) to use a cloud computing infrastructure with virtualization to dynamically shift the resources in real time to handle the ICC workload, b) to be able to anticipate the change in the workload ahead of time and preload VoD content on STBs, thereby facilitate the shifting of resources from VoD to ICC during the bursts and c) solve a general cost optimization problem formulation without having to meticulously model each and every parameter setting in a data center to facilitate this resource .

Fig. 1 architecture diagram

The fig 1 shows the architecture diagram of an iptv services. This contains four modules i.e., data owner module, VOD server module, TPA server module and remote user module. a) The main role of the data owner is to store or upload the files on the cloud or VOD server. As an first step for enhancing security the data owner goes for encrypting the file that are needed to be stored on VOD server after encryption he goes for generating meta data. Upload the generated Meta data to TPA to enhance the security .b) the role of the VOD server module is to provide an space for the data owner to store the files, provides service to the requesting clients and generates an hackers alert to the mobile. c) The main role of the TPA server is to enhance data integrity on the files being stored on to the cloud server. d) The role of remote user is to access the information from cloud server weather he may be a valid user or a hacker

RELATED WORK

In media streaming, the Internet’s intrinsic heterogeneity continues a challenging problem. End users may have different edge bandwidth for data receiving or forwarding, especially in large-scale streaming with hundreds of thousands of users. Description coding rates have straightforward impact to the delivery performance. If a description has a high coding rate, some network paths may not have enough bandwidth to support its delivery. The loss rate of the description will be high. On the other hand, if descriptions have low coding rates, the number of descriptions and accordingly the coding cost will be high. There are mainly three threads of related work, namely cloud computing, scheduling with deadline constraints, and optimization. Cloud computing has recently changed the landscape of Internet based computing, whereby a shared pool of configurable computing resources (networks, servers, storage) can be rapidly provisioned and released to support multiple services within the same infrastructure . Due to its nature of serving computationally intensive applications, cloud infrastructure is particularly suitable for content delivery applications.

Typically Live TV and VoD services are operated using dedicated servers, while this paper considers the option of operating multiple services by careful rebalancing of resources in real time within the same cloud infrastructure.

In an on-demand video server environment, clients make requests for movies to a centralized video server. Due to the stringent response time requirements, continuous delivery of a video stream to the client has to be guaranteed by reserving sufficient resources required to deliver a stream. Hence there is a hard limit on the number of streams that can be simultaneously delivered by a server. The server can satisfy multiple requests for the same movie using a single disk I/O stream by sending the same data pages to multiple clients by knowing the arrival pattern of the IPTV and VoD requests with their deadlines in the future. We wish to find the number of servers to use at each time so as to minimize the cost function. In this paper, we consider different forms of cost functions. We derive closed form solutions where possible for various cost functions.

INSTANT CHANNEL CHANGE (ICC) IN IPTV SYSTEMS

Current Approaches for ICC

We refer to the existing approaches for fast channel

Change (ICC) as "Unicast Instant Channel Change" or "Unicast ICC" and focus on one baseline approach. As shown

In Figure 2, when a client connects to the D-server, the Dserver begins unicasting data to the client, starting from an I frame in its buffer. The D-Server bursts the data at a higher rate than the nominal video bit rate.

Fig. 2: Unicast ICC

Unicast ICC scheme: uses accelerated unicast streams to fill the playout buffer, thus reducing the wait at the STB. Given this higher unicast rate, the set-top box (STB) buffer fills up faster than the nominal rate at which the multicast stream is transmitted. A multicast "join" is issued by the client after sufficient data is buffered in the playout buffer of the STB so that the buffer does not under-run by the time the multicast join completes and the subsequent multicast stream is received. The unicast stream is stopped once the playout buffer is filled to the desired level. Once the multicast join is successful, the client can start displaying video received from the multicast stream.

B. Our Proposed Approach: Multicast ICC

We propose a multicast-based Instant Channel Change (Multicast ICC) mechanism that reduces the channel switching latency, especially under high loads of channel change events. The approach makes the system scale better as the user population grows. The bandwidth demand is more predictable.

Figure 3 shows the mechanism of the Multicast Instant Channel change process: a) the channel change request for a particular channel results in a multicast join request being issued by the client. A join is issued for both the primary multicast stream as well as the secondary ICC multicast group for the channel change stream obtained by extracting the I frames from the primary stream. With IP multicast, the join progresses as far up the distribution tree as necessary, until it hits an "on-tree" node. b) The D-server transmits both the secondary channel change stream as well as the primary multicast channel if there is an outstanding channel change event for that channel. c)The first frame from the secondary ICC channel change stream is displayed on the screen by the client, without buffering, along with the audio, resulting in what we believe is an acceptable viewing experience, even though it is not necessarily full-motion. d) In the mean-time the higher quality, primary multicast stream fills the buffer. e) Once the buffer is filled up to the playout point, the client can start displaying the high quality picture from the playout buffer. Because of the time-offset between the secondary ICC channel change stream and the primary stream, when the buffer meets its threshold, the client (STB) can seamlessly switch to the buffered (primary) input without a user-perceived time-shift of the video.

. IMPACT OF COST FUNCTIONS ON SERVER REQUIREMENTS.

In this section, we consider various cost functions C(s1, s2, · , sT ), evaluate the optimal server resources needed, and study the impact of each cost function on the optimal solution.

Cost functions

We investigate linear, convex and concave functions (See Figure 4). With convex functions, the cost increases slowly

Fig.3: Steps of the Multicast ICC Scheme

Initially and subsequently grows faster. For concave functions, the cost increases quickly initially and then flattens out, indicating a point of diminishing unit costs (e.g., slab or tiered pricing). Minimizing a convex cost function results in averaging the number of servers (i.e., the tendency is to service requests equally throughout their deadlines so as to smooth out the requirements of the number of servers needed to serve all the requests). Minimizing a concave cost function results in finding the external points away from the maximum (as shown in the example below) to reduce cost. This may result in the system holding back the requests until just prior to their deadline and serving them in a burst, to get the benefit of a lower unit cost because of the concave cost function (e.g., slab pricing). The concave optimization problem is thus optimally solved by finding boundary points in the server-capacity region of the solution space.

EXPERIMENTS

We set up a series of experiments to see the effect of varying firstly, the ICC durations and secondly, the VoD delay tolerance on the total number of servers needed to accommodate the combined workload. All figures include a characteristic diurnal VoD time series (in pink) and a LiveTV ICC time series (in blue). Based on these two time series, the

Optimization algorithm described in section 3 computers.

Fig. 4: Cost functions

The minimum number of concurrent sessions that need to be accommodated for the combined workload. The legends in each plot indicate the duration that each VoD session can be delayed by. Figure 7 shows the superposition of the number of VoD sessions with a periodic LiveTV ICC session. The duration or the pulse width of the ICC session is 15 seconds (i.e. all ICC activity come in a burst and lasts for 15 seconds). We now compute the total number of concurrent sessions that the server needs to accommodate by delaying each VoD session from 1 second to 30 seconds in steps of 5 seconds. It is observed that as VoD sessions tolerate more delay the total number of sessions needed reduce to the point (15 sec delay) at which all ICC activity can be accommodated with the same number of servers that are provisioned for VoD. On the other hand, if the VoD service can afford only 1 second delay, the total number of sessions that need to be accommodated is roughly double (LiveTV ICC peak in red + VoD peak (blue)). Figure 7 shows a similar effect; the only difference here is that the Live TV ICC pulse width is now 30 seconds. Figure 8 and 9 shows the total number of concurrent sessions needed to accommodate the combined workload of

VoD and LiveTV ICC requests. The traces are obtained from an operational IPTV environment in a relatively large VHO. We note that as VoD requests are delayed up to 30 seconds the total server bandwidth reduces by about 17.5%. In all there is a 21.67% saving in server bandwidth compared to sum of the peaks and 17.5% saving compared to peak of the sum with a 30 sec wait time allowed for VoD. In the previous experiments we computed the minimum number of concurrent sessions that need to be supported based on observations over the entire day. Figure 10 shows the minimum number of concurrent sessions needed based on optimizing every half hour. Note that the peak number of sessions still coincide with Figure 9. However, as the load reduces, the numbers of concurrent sessions that need to be supported also reduce, thus tracking the diurnal pattern. As mentioned before, when the VoD service tolerates more delay (from 1 sec to 30 sec) the server requirements also diminish. The use of virtualization enables us to track the composite demand pattern throughout the day and thereby allocating just the right number of servers needed to service the total number of ongoing concurrent sessions. Figure 7 shows similar observations, however, the LiveTV ICC trace is synthetically generated that peaks for 30 seconds every half hour.

SUMMARY AND CONCLUSIONS

We studied how IPTV service providers can leverage a virtualized cloud infrastructure and intelligent time-shifting of load to better utilize deployed resources. Using Instant Channel Change and VoD delivery as examples, we showed that we can take advantage of the difference in workloads of IPTV services to schedule them appropriately on virtualized infrastructures. By anticipating the LiveTV ICC bursts that occur every half hour we can speed up delivery of VoD content before these bursts by prefilling the set top box buffer. This helps us to dynamically reposition the VoD servers to accommodate ICC bursts that typically last for a very short time.

Our paper provided generalized framework for computing the amount of resources needed to support multiple services with deadlines. We formulated the problem as a general optimization problem and computed the number of servers required according to a generic cost function. We considered multiple forms for the cost function (e.g., min-max, convex and concave) and solved for the optimal number of servers that are required to support these services without missing any deadlines. We implemented a simple time-shifting strategy and evaluated it using traces from an operational system. Our results show that anticipating ICC bursts and time-shifting VoD load gives significant resource savings (as much as 24%). We also studied the different parameters that affect the result and show that their ideal values vary over time and depend on the relative load of each service. Mechanisms as part of our future work.