# Cooperative Buffering Schemes for Time-Shifted Live Streaming of Distributed Appliances
## 1 Introduction  
With advances in computer technologies and networks, Internet-connected home appliances capable of providing various multimedia services have recently become prevalent. In particular, digital TVs with Personal Video Recorder (PVR) functionality can store broadcast programs in their built-in storage devices [1; 2; 3]. Thus, as long as live TV programs are stored during their broadcasting times, they can be kept time-shifted from live broadcast time without missing any parts of them. Thus, people can watch the TV programs they want at any desired time. However, there are limitations on the availability of time-shifted programs due to the limited number of reception channels and storage capacity. Since each PVR has a small number of tuners, the number of channels through which it can receive programs simultaneously is also small. The time-shifting hours of TV programs that PVRs can support are also limited since the programs already stored must be replaced with newly broadcast programs due to limited storage capacity. Accordingly, only parts of the programs that have already been watched or explicitly recorded can be time-shifted within the PVR's storage capacity. To overcome these limitations, PVRs connected to broadband receive broadcast programs from central servers even though they have not stored the programs in their storage space [4]. To provide these networked PVR services with a large number of concurrent users in real time, it is essential to provide sufficient network bandwidth and fast responses to interactive operations. To this end, large-scale Content Delivery Networks (CDNs) have been employed to minimize the transmission delay between clients and servers byplacing proxy servers close to clients [5; 6; 7]. CDNs can provide sufficient reliability and manageability for providing streaming services with a huge number of concurrent users without quality degradation, although they require a substantial investment in distributed CDN infrastructures to ensure timely delivery to the enormous users. It is also obvious that, as the number of users increases, ISPs or service providers must invest more in expanding resources including the number of servers and network bandwidth to accommodate the increased users. To mitigate the burden of CDN's increasing investment in infrastructure, we employ P2P technologies [8; 9; 10] where aggregate resources of the system scale with the number of users without additional investment for the services. Note that as more peers join the P2P systems, better resiliency and the faster data transmission can be provided because the peers bring network bandwidth, disk storage capacity, computing power, and memory resources together with them. This indicates that P2P systems are more scalable in terms of cost, compared to CDNs owned by ISPs or service providers, when expanding the service capacity of the systems. It is noted that they are also scalable in terms of the number of concurrent users. One popular commercial P2P live streaming system, PPLive, showed that it could use only 10 Mbps server bandwidth to serve 1.48 million concurrent users at a total consumption rate of 592 Gbps [11]. Thus, PVRs can share TV programs with each other over P2P networks at a low cost, providing a program distribution channel as an alternative to the unidirectional broadcasting network [12; 13]. It is also obvious that P2P technologies can provide a significant service cost reduction by minimizing server intervention. PVRs basically provide time-shifting functions such as pause/resume, skip-forward/backward, fast-forward/rewind so that users can quickly move to any playback position they want. To receive the data required for playback when moving to any position, a PVR should receive data from other PVRs playing back around the position. As shown in Figure 1, however, the popularity of live TV programs typically reaches the peak within several minutes after their broadcast times and exponentially decreases afterwards [14].