« 上一頁繼續 »
ALLOCATION OF RESOURCES TO DELIVER MEDIA CONTENT USING A COMBINATION OF STATIC AND DYNAMIC RESOURCES
IP-based WANs are becoming an increasingly feasible mechanism for delivering media resources to users. Such media resources can include movies, music, and so forth. IP-based media delivery services can potentially offer functionality that is more flexible and interactive compared to traditional cable-based solutions. Further, IP-based media delivery services can potentially offer many more channels compared to traditional cable-based solutions.
However, IP-based media delivery services may also present new technical and business-related challenges. For instance, a service may wish to offer a large number of channels to entice users to subscribe to the service. The service may increase its channel offerings by proportionally increasing the number of resources dedicated to providing respective channels. Yet the cost of a service also proportionally increases with the addition of new server resources. It may therefore be an expensive proposition to provide a large number of channels.
For at least the above-identified reasons, there is a need for more satisfactory approaches to delivering media items to users.
A strategy is described for allocating resources of an operations center to provide a collection of channels. The strategy uses static resources to provide relatively popular channels and dynamic resources to provide relatively unpopular channels. The strategy can separately perform this allocation for different regions served by the operations center. Through this provision, the strategy can reduce the cost of delivering media content by making more efficient use of a limited number of resources, while still providing a relatively large number of channels.
In another exemplary implementation, the operations center includes plural tiers, including a backend tier associated with acquisition functionality and a front-end tier associated with delivery functionality. The acquisition functionality receives and performs preliminary processing on media content. The delivery functionality facilitates the transfer of the media content to client devices, such as by bursting the media content to the client devices upon channel tune events. In this environment, the strategy can separately perform resource allocation for each tier. For example, the strategy can provide: a first group of highly popular channels using a combination of static backend resources and static front-end resources; a second group of moderately popular channels using a combination of static backend resources and dynamic front-end resources; and a third group of relatively unpopular channels using a combination of dynamic backend resources and dynamic front-end resources.
Additional exemplary implementations and attendant benefits are described in the following.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 shows an exemplary multi-tiered system for delivering media items to users, employing a collection of static resources and dynamic resources.
FIG. 2 shows a table that identifies one exemplary strategy for allocating static and dynamic resources to channels based on the popularity of the channels.
FIG. 3 shows exemplary processing functionality for implementing any aspect of an operations center shown in FIG. 1.
FIG. 4 shows exemplary processing functionality for 5 implementing any aspect of a client device shown in FIG. 1.
FIG. 5 shows an exemplary procedure that explains one manner of operation of the system of FIG. 1.
The same numbers are used throughout the disclosure and figures to reference like components and features. Series 100 10 numbers refer to features originally found in FIG. 1, series 200 numbers refer to features originally found in FIG. 2, series 300 numbers refer to features originally found in FIG. 3, and so on.
15 DETAILED DESCRIPTION
This disclosure sets forth a strategy for delivering media content to users over a set of channels using a collection of static resources and a collection of dynamic resources. The
20 static resources are used to provide relatively popular channels in a dedicated manner. The dynamic resources are used to provide less popular channels on an on-demand basis (e.g., only when users request such channels).
The term "media content" as used herein has broad conno
25 tation. Media content can refer to video content, audio content, still image content, program-related content (e.g., gamerelated content), and so forth, or any combination thereof. For example, media content can correspond to television programs, movies, music, and so forth. The term "media item"
30 refers to a particular instance of media content, such as a particular television program, movie, song, and so forth.
The term "channel" refers to any provision for delivering media content. As will be described, in an IP-based media delivery solution, a channel may be associated with a net
35 work-accessible address through which a client device may receive media content.
This disclosure includes the following sections. Section A describes an exemplary system for delivering media content to client devices. Section B describes an exemplary procedure
40 that explains the operation of the system of Section A. A. Exemplary Systems
As a preliminary note, any of the functions described with reference to the figures can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual pro
45 cessing, or a combination of these implementations. The term "logic, "module," "system" or "functionality" as used herein generally represents software, firmware, hardware, or a combination of the elements. For instance, in the case of a software implementation, the term "logic," "module," "system,"
50 or "functionality" represents program code that performs specified tasks when executed on a processing device or devices (e.g., CPU or CPUs). The program code can be stored in one or more computer readable memory devices.
More generally, the illustrated separation of logic, mod
55 ules, systems, and functionality into distinct units may reflect an actual physical grouping and allocation of software, firmware, and/or hardware, or can correspond to a conceptual allocation of different tasks performed by a single software program, firmware program, and/or hardware unit. The illus
60 trated logic, modules, systems, and functionality can be located at a single site (e.g., as implemented by a processing device), or can be distributed over plural locations.
The terms "machine-readable media" or the like refers to any kind of medium for retaining information in any form,
65 including various kinds of storage devices (magnetic, optical, static, etc.). The term machine-readable media also encompasses transitory forms for representing information, including various hardwired and/or wireless links for transmitting the information from one point to another. A.l. System Overview
FIG. 1 shows an exemplary system 100 for delivering media content to users. The system 100 includes an opera- 5 tions center 102 that supplies the media content to a plurality of client devices (such as representative client device 104) via delivery network 106. The system 100 will be described in generally top-down fashion.
The operations center 102 includes multiple tiers, includ- 10 ing a backend tier that provides acquisition functionality 108 and a front-end tier that provides delivery functionality 110. The purpose of the acquisition functionality 108 is to receive media content from information sources 112, and to optionally perform preliminary processing on the media content. 15 The purpose of the delivery functionality 110 is to perform various services in connection with the delivery of the media content to the representative client device 104. Although only two tiers in the delivery infrastructure are shown, the operations center 102 can include additional tiers for performing 20 other roles associated with the processing and delivery of media items. Further, note that FIG. 1 shows the various components of the operations center 102 as being co-located at a single site. However, the operations center 102 can also be distributed over plural sites, where such sites can be admin- 25 istered by a single entity or plural different entities.
Starting with the acquisition functionality 108, this functionality 108 can receive media content from various information sources 112 using any transfer technique. In one technique, the acquisition functionality 108 can receive the media 30 content by a streaming mode of transfer. In another technique, the acquisition functionality 108 can receive the media content by a bulk file mode of transfer. In another technique, the acquisition functionality 108 can receive the media content by manual transfer of computer readable media, and so on. 35 The information sources 112 can represent cable sources, satellite sources, terrestrial antenna broadcast sources, Internet-based sources, other network sources, and so forth.
The acquisition functionality 108 can perform various preliminary processing on the received media content. Such 40 preliminary processing can involve converting the media content into a format suitable for delivery to the client device 104. The preliminary processing can also involve applying various types of rights management protection to the media content (e.g., to prevent unauthorized consumption of the media con- 45 tent).
In one particular mode of delivery, the acquisition functionality 108 uses a multicasting technique to deliver media content. One such multicasting technique is the Internet Group Management Protocol (IGMP)). In a multicasting 50 technique, the acquisition functionality 108 can provide a tree of distribution nodes for delivering a media item from an ultimate source. A client device can "tune" to receive this media item by "taping into" an appropriate node in the distribution tree. Here, the terms "channel" and "tune" are vir- 55 tual counterparts to physical channels and tune events associated with a conventional broadcast or cable environment. More specifically, in an IP environment, a channel is associated with an address through which a client device may receive media content, rather than a prescribed segment of a 60 physical frequency spectrum. In an IP environment, a client device "tunes" to receive this media content by connecting to an appropriate address, rather than adjusting a physical tuner to receive a signal being broadcast over a prescribed frequency segment. 65
In terms of physical implementation, the acquisition functionality 108 can comprise various resource sets, such as
resource set 114, resource set 116, and so on. Each resource set may comprise a collection of functionality used to acquire and process media content received from the information sources 112. More specifically, in one exemplary implementation, different resource sets may serve different respective geographic regions. For example, one or more resource sets may serve a group of users located in the California San Francisco bay area, while one or more other resources sets may serve a group of users located in the Seattle area, and so on. Each resource set can include various equipment, such as one or more servers, one or more data storage units, various network-related resources, and so forth. The network-related resources can comprise various communication links, routing mechanisms, interfaces, and so on.
Turning now to the delivery functionality 110, this functionality 110 can facilitate the transfer of media content to the client device 104. Different systems may use the delivery functionality 110 in different ways. One exemplary system may use the delivery functionality 110 to transmit media content in unicast fashion. In a unicast mode of transmission, the delivery functionality 110 provides a dedicated stream of media content (provided by dedicated server resources) to a single client device. Alternatively, the operations center 102 can deliver the media content to the client devices in multicast fashion. As stated above, in the multicast mode of transmission, the operations center 102 can provide the media content through a tree of distributionnodes. In either the unicast mode or transmission or the multicast mode of transmission, the acquisition functionality 108 can act as the ultimate source of the media content. For instance, in the unicast mode, the delivery functionality 110 can serve as an intermediary, that is by acting as a multicast recipient with respect to the media content provided by the acquisition functionality 108, and by acting as a unicast provider with respect to a downstream client device.
In another implementation, the delivery functionality 110 can deliver media content using a combination of unicast communication and multicast communication. For example, the delivery functionality 110 can deliver a media item to the client device 104 in unicast fashion when the client device 104 first tunes to a particular channel. To facilitate quick acquisition of the content, the delivery functionality 100 can provide this unicast stream at a burst rate (which is greater than the nominal or steady state rate of the stream). After a predetermined period of time, the client device 104 can transition from the unicast stream to an established multicast stream (where both unicast stream and multicast stream pertain to the same media content). Co-pending and commonly assigned U.S. patent application Ser. No. 10/010,200 (the '200 Application), entitled, "ACCELERATED CHANNEL CHANGE IN RATE-LIMITED ENVIRONMENTS," naming the inventors of Geoffrey R. Smith et al., filed on Dec. 10, 2004, provides further exemplary details regarding one protocol for delivering media content using a combination of unicast and multicast techniques. The '200 Application is incorporated by reference herein in its entirety.
The delivery functionality 110 can also perform a role in receiving retry requests from the client device 104 and sending retry packets to the client device 104 in response to these requests. Co-pending and commonly assigned U.S. patent application Ser. No. 11/012,891 (the '891 Application), entitled, "RETRY STRATEGIES FOR USE IN A STREAMING ENVIRONMENT," naming the inventors of Dustin L. Green et al., filed on Dec. 15, 2004, provides further exemplary details regarding one exemplary protocol for performing retry operations in a media distribution system. The '891 Application is incorporated by reference herein in its entirety.