Patent Application
20090158273
The subject-matter relates-generally to-content-distribution,-and-more particularly to systems and methods for automatically selecting and downloading software for content distribution system client receivers on a network.
Content distribution systems for televisions and other types of video/audio systems have evolved into complex systems that interact through networks. These types of systems can even use the Internet and telephone systems to distribute content. For example, a television content distribution system for multiple dwelling units can utilize Internet Protocol (IP) for the delivery of television content and services. These systems can be comprised of one or more gateway server devices that interact with different types of settop box (STB)-client receivers. Thus, there can be hundreds of receivers of different types and models that need to be updated and/or maintained on a regular basis. For example, operational software may need to be downloaded from a server to various receiver clients to keep the clients up-to-date. This leads to several problems. Namely, to figure out what models need the software from the server device and to identify what STB models/versions are supported by the server device. If the correct version is determined, then a process must figure out how to connect the server and client so that the software can be downloaded. Often this is time critical. For example, if a power failure occurs, it is likely that most STB-client receivers will attempt to come-up at the same time and all attempt to download software at once. Thus, the process needs to be quick in order to handle this type of en mass downloading.
IP multicast techniques are leveraged to facilitate in identifying software and to facilitate in downloading the software from a server to a client of a content distribution system. The clients monitor multicasts from a server and utilize a master/slave hierarchy technique to assist in requesting desired software blocks. The server sends out multicasts with payloads that identify, for example, manufacturers and model numbers of client receivers for whom the server has the software for. The client receivers can then listen and download the payloads that pertain to their specific models, dynamically connecting to the appropriate server, as necessary. The master/slave technique allows only a master client receiver to request software blocks. Once fulfilled, the master status can be passed to another client receiver to request software blocks. The client receivers determine which software blocks are needed based on the multicast information (e.g., manufacturer, model number, software version, etc.) from the servers and on the basis of prior software-blocks downloaded. This allows a diverse grouping of client receivers to quickly download needed software in an orderly manner.
The above presents a simplified summary of the subject matter in order to provide a basic understanding of some aspects of subject matter embodiments. This summary is not an extensive overview of the subject matter. It is not intended to identify key/critical elements of the embodiments or to delineate the scope of the subject matter. Its sole purpose is to present some concepts of the subject matter in a simplified form as a prelude to the more detailed description that is presented later.
To the accomplishment of the foregoing and related ends, certain illustrative aspects of embodiments are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles of the subject matter can be employed, and the subject matter is intended to include all such aspects and their equivalents. Other advantages and novel features of the subject matter can become apparent from the following detailed description when considered in conjunction with the drawings.
The subject matter is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the subject matter. It can be evident, however, that subject matter embodiments can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the embodiments.
As used in this application, the term “component” is intended to refer to hardware, software, or a combination of hardware and software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, and/or a microchip and the like. By way of illustration, both an application running on a processor and the processor can be a component. One or more components can reside within a process and a component can be localized on one system and/or distributed between two or more systems. Functions of the various components shown in the figures can be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software.
When provided by a processor, the functions can be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which can be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and can implicitly include, without limitation, digital signal processor (“DSP”) hardware, read-only memory (“ROM”) for storing software, random access memory (“RAM”), and non-volatile storage. Moreover, all statements herein reciting instances and embodiments of the invention are intended to encompass both structural and functional equivalents. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).
The systems and methods disclosed herein allow clients such as, for example, settop box receivers to efficiently recognize and/or request operational software it needs from a gateway server device. This is accomplished automatically via self-identification which then permits efficient downloading of software and boot-up of the receiver. Multicast messaging is used as a delivery mechanism to at least one receiver which, in turn, determines whether software information located in the multicast message has value to that particular receiver. If the software is valuable to that receiver, it can download the software found in the multicast message. This allows the same message to be sent to a multitude of receivers without the server attempting to distinguish between receiver types (e.g., different manufacturers, models, software versions, etc.).
The receiver software component 102 listens to the multicast messages and determines whether or not the multicast message contains information pertinent to its associated receiver 106. For example, if the multicast message contains a different manufacturer than the receiver 106, the receiver software component 102 can ignore the message. However, if the manufacturer and model match the receiver 106, the receiver software component 102 can check what software version is contained in the multicast message and download it if it is needed. Thus, the receiver software component 102 automatically ‘self-identifies’ and downloads software if it passes certain requirements. This alleviates the server 104 from having to have knowledge of exactly what clients (e.g., manufacturers, models, software versions, etc.) are on a given network. The software can be quickly distributed via the multicast messages and those clients that need the software listen and download it as required. The receiver software component 102 can also establish a hierarchy of master/slaves between clients and only allow additional software requests by a master client. Once a master client (e.g., receiver/receiver software component) has downloaded its software, it can let the server pass the master client status to another client that still requires software not yet distributed via the multicast messages. The server 104 can accept requests from the receiver software component 102 and provide specifically requested software to be multicast to the clients.
In
The multicast component 208 can read the multicast messages sent by the server 204 and pass its message contents to the software download component 210. The message contents can include parameter and/or payload information such as time, date, software version, manufacturer, model, and/or software blocks and the like. The software download component 210 assesses the information received from the multicast component 208 to determine if software contained in the multicast message is relevant to the receiver 206. For example, in some instances, the software download component 210 can check not only manufacturer and model but also determine whether the software version is older or newer than that currently loaded on the receiver 206. Depending on the situation, the software download component. 210 can allow only software upgrades (i.e., newer versions), only software downgrades (i.e., older versions), and/or allow both upgrades and downgrades but not overwrite identical software already loaded into the receiver 206 and the like. Parameters employed by the software download component 210 to determine what is relevant to the receiver 206 can be controlled locally (e.g., user input, factory settings, etc.) and/or remotely (e.g., commands sent from the server 204, etc.).
Looking at
Typical content/service distribution systems are comprised of gateway server devices and several different types of STB-client receivers. There can be hundreds of receivers of different types and models that need to be able to download, for example, their operational software from the server device. Some models can self-start the software from flash, whereas many need to download their operational code (to RAM) every time they boot (power-up) which requires a means by which the STBs can easily identify themselves to the server device and request the appropriate software. In case of an unfortunate event such as a power-interruption, it is likely that many STB-client receivers will come-up at the same time trying to download the same software. Instances disclosed herein resolve these issues by allowing the receivers to automatically self-identify and determine which software is appropriate in the server's multicasted messages. By utilizing these instances, for example, IP STB receivers can download the software efficiently, using static and/or dynamic IP addresses. The dynamic model-identification and download-server identification substantially increases overall efficiency and is friendly to the operators involved in the equipment provisioning.
The following is meant to be an example and is not meant to limit instances disclosed herein to specific restrictions on protocol, interfaces, and/or payload/message structure, etc.
The typical multicast address used by the SAP announcements is 239.255.255.255, port 9875, which is per RFC 2364/IANA. The STB receiver can keep comparing its model/manufacturer ID with the one that is announced, for a specific duration. For example, if a match is found and the advertised image size is greater than zero, and the advertised version number is not equal to a pre-determined value, then the receiver can generate and/or request the filename in the format of, for example, “midMM_XXXX.bin” from a download-server, where MM can be, for example, a two digit manufacturer ID and XXXX can be, for example, a four digit model ID of the receiver. If a match is not found, the STB can still request the image from a server-device, in which case the request can be routed to another head-end device, via the first server-device. For example, the Trivial File Transfer Protocol. (TFTP) can be used by the STB receivers to download its operational software image. The TFTP multicast option can be utilized, for example, to provision for large scale, simultaneous downloads (such as after a building power outage). Additionally, the TFTP block size option can be utilized to reduce the amount of TFTP ACKing that must occur to complete the transfer successfully. The connection can be made dynamic, since the STB-clients can get the download-server device address via the SAP announcements in the previous stage. A subsequent decision to flash the downloaded code and/or to run directly from RAM can depend on the model ID of the STB. In other instances, the server that provides the SAP information can differ from the server that provides the appropriate download. The techniques disclosed herein do not restrict instances to utilizing a single server for all functionality and/or download services.
In view of the exemplary systems shown and described above, methodologies that can be implemented in accordance with the embodiments will be better appreciated with reference to the flow charts of
In
In
In
In
It should be noted that instances herein can also include information sent between entities. For example, in one instance, a data packet, transmitted between two or more devices, that facilitates content/services distribution is comprised of, at least in part, information relating to content/service distribution receiver software relayed to content/service distribution receivers via a multicast message.
It is to be appreciated that the systems and/or methods of the embodiments can be utilized in content and/or service distribution facilitating computer components and non-computer related components alike. Further, those skilled in the art will recognize that the systems and/or methods of the embodiments are employable in a vast array of electronic related technologies, including, but not limited to, computers, broadcast content/service receivers, and/or mobile devices, and the like.
What has been described above includes examples of the embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the embodiments, but one of ordinary skill in the art can recognize that many further combinations and permutations of the embodiments are possible. Accordingly, the subject matter is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.
