Patent Application
20090031341
The present invention relates generally to a switched digital video system for distributing content to a subscriber over a system such as a satellite or cable television system, and more particularly to a switched digital video system in which the number of control messages such as channel change messages that are passed between the set top terminal and the on-demand system is reduced.
Switched digital video (SDV) refers to an arrangement in which broadcast channels are only switched onto the network when they are requested by one or more subscribers, thereby allowing system operators to save bandwidth over their distribution network. In conventional cable or satellite broadcast systems, every broadcast channel is always available to all authorized subscribers. In contrast, a switched digital video channel is only available when requested by one or more authorized subscribers. Also, unlike video on-demand, which switches a singlecast interactive program to a user, switched digital video switches broadcast streams, making each stream available to one or more subscribers who simply join the broadcast stream just as they would with normal broadcast services. That is, once a switched service is streamed to a subscriber, subsequent subscribers associated with the same service group as the first subscriber can tune to the same broadcast stream. The switched digital video will often share the same resource managers and underlying resources with other on demand services.
As noted, switched digital video is largely a tool to save bandwidth. From the subscriber perspective, he or she still receives the same broadcast video service when using a switched broadcast technique; ideally the user is not able to discern that the stream was switched at all. If each one of the digital broadcast channels is being watched by subscribers in the same service group, the switched digital video approach does not yield any bandwidth savings. However, a more likely situation statistically is that only a certain number of the digital broadcast channels are being watched by subscribers in the same service group at any given time. Those channels not requested by a subscriber need not be broadcast, thereby saving bandwidth.
One way to support switched digital video is to utilize the session manager to manage SDV and other sessions. For each channel change, the subscriber will set up a broadcast session with the session manager, which will determine if the requested channel is already being sent to the corresponding service group that the subscriber belongs to. The subscriber will be assigned to join the existing SDV session if the requested channel is available at the service group or assigned to a new SDV session if the requested channel is not available at the service group. The session manager will negotiate with the edge devices to allocate resources required for the session. The edge device (e.g., a digital modulator such as a QAM modulator) needs to dynamically retrieve the MPEG single program transport stream that carries the requested SDV program (likely via IP multicast) and generate the MPEG multiple program transport stream. As part of the session setup response message, the video tuning parameters such as frequency and MPEG program number are sent back to the subscriber to access the requested SDV channel.
Communication between the session manager and the subscriber is performed using an SDV Channel Change Message (CCM) protocol, which can be implemented as a proprietary protocol or using an open standard. Among other things, these protocols pass channel change requests from the subscriber to the session manager. The session manager responds by sending a message that includes the necessary tuning information to the subscriber. However, these protocols generate a large number of messages, which can consume a large amount of bandwidth, particularly when there are a relatively large number of subscribers requesting channel changes.
As detailed below, the number of channel change messages that need to be sent from a subscriber to the SDV manager or other appropriate entity is reduced by accumulating a history or log of channel changes that have been previously performed by the subscriber. In addition, the subscriber can access an SDV channel without sending a request to the SDV manager. This can be accomplished with the use of the active services list that is repeatedly transmitted to the subscriber terminals.
Some or even all of the hubs are connected to multiple users, typically via distribution networks such as local cable access networks (e.g., HFC networks). For simplicity of explanation only, each hub is shown as being connected to a distinct HFC network, which in turn communicates with end user equipment as illustrated. In particular hubs 130, 132 and 134 in
In addition to the switch or router 170, each hub can include an array of radio frequency transmitter edge devices such as edge QAM modulators 150. The number of edge devices 150 in each hub may vary as needs dictate. As used herein, the term “QAM” refers to modulation schemes used for sending signals over cable access networks. Such modulation schemes might use any constellation level (e.g. QAM-16, QAM-64, QAM-256 etc.) depending on the details of a cable access network. A QAM may also refer to a physical channel modulated according to such schemes. Typically, a single QAM modulator can output a multiplex of ten or twelve programs, although the actual number will be dictated by a number of factors, including the communication standard that is employed. The edge QAM modulators usually are adapted to: (i) receive Ethernet frames that encapsulate the transport packets, (ii) de-capsulate these frames and remove network jitter, and (iii) transmit radio frequency signals representative of the transport stream packets to end users, over the HFC network. Each transport stream is mapped to a downstream QAM channel. Each QAM channel has a carrier frequency that differs from the carrier frequency of the other channels. The transport streams are mapped according to a channel plan designed by the MSO that operates the network.
Each hub 130, 132 and 134 also includes an edge resource manager 160 for allocating and managing the resources of the edge devices 150. The edge resource manager 160 communicates with and receives instructions from the session manager located in the headend 110. In some case the edge resource manager and/or session manager can be located in the headend.
Headend 110 may also include a network DVR 240. The network DVR 240 stores content that can be transmitted to a set top terminal via a hub and access network in response to a user request to play a program stored on the DVR 240. Other user input requests are also serviced by network DVR 240, including, for example, requests to accelerate the playing of a program in the forward direction (e.g., cueing) and in the reverse direction (e.g., reviewing). The content is stored by the network DVR 240 upon a user request. The content may be provided to the network DVR 240 from any available content source, including, for example, content source 210.
Headend 110 may also include a variety of other components for offering additional services. For example, in
The edges devices 150 provide programming to the set top terminals using the downstream in-band channels. To communicate control information and the like with the headend 110 and/or the relevant hub, the set top terminals may use out-of-band (OOB) or DOCSIS channels or an IP tunnel or an IP connection and associated protocols. However, in some cases communication of control information and the like can be performed using in-band channels as well.
Control information that may be communicated over the out-of-band channels includes the aforementioned SDV channel change messages (CCM), which are used to pass channel change requests from the subscriber to the SDV manager 215 in the headend 110. In particular, the SDV manager 215 receives channel change requests for switched digital content from a set top terminal to bind that content to a session on one of edge devices 150 serving that set top terminal's service group. The channel change request message is generated by the SDV application (or its designated proxy) resident in the set top terminal in response to the subscriber's program channel request that is entered by the set top terminal's user interface. The SDV manager 215 responds to the set top terminal with the frequency and program number where that content may be found. The SDV manager 215 also receives channel change request messages for non-SDV (e.g., broadcast) channels in order to gather statistics that can be used to better understand subscriber activity and to provide information that can be used for targeted advertising and the like. Another reason to receive non-SDV channel changes is so that the SDV Manager knows when the set top terminals are no longer tuned to an SDV channel, thus allowing the SDV Manager to remove the SDV channel from the network to save bandwidth.
Reductions in the number of channel change messages that are sent from the set top terminal to the SDV manager 215 can be achieved both when the subscriber is changing from one broadcast channel to another, as well as when the subscriber is requesting an SDV channel on the active services list or changing from one SDV channel to another SDV channel on the active services list. In the case when the subscriber is first tuning to a broadcast channel or switching from one broadcast channel to another, the channel change information can be queued or accumulated in the set top terminal and sent at a substantially later time after some predetermined number of channel changes have been performed or after a predetermined amount of time has elapsed (e.g., 5-60 minutes). Alternatively, the accumulated channel change information can be sent whenever there is sufficient bandwidth available. In this way channel change information relating to broadcast channels need not be transmitted each and every time the subscriber makes such a channel change, thereby reducing the number of individual messages that need to be transmitted. Despite this reduction, the SDV manager 215 can still gather all the statistical information concerning subscriber activity that is obtained when a separate message is transmitted for each channel change.
If an SDV channel is not on the active services list, then a channel change message needs to be send in order for the subscriber to view the SDV programming.
Channel change messages can also be reduced not only when the subscriber is requesting a broadcast channel, but also when requesting an SDV channel. This can be accomplished by using the information that is repeatedly sent from the SDV manager to the set top terminals, which contains a list of all the active services currently streaming to each service group along with the tuning parameters required to access them. This repeating information is typically transmitted either in-band or out-of-band using a protocol such as the mini-carousel protocol (MCP). For example, in the case of the mini-carousel protocol, the MCP message sent to the set top terminals includes one entry for each active service (e.g., each SDV program). An illustrative format of the entry is as follows: (i) Bytes 0-3: Broadcast Program ID; (ii) Byte 4: Modulation Index (6=QAM-16, 7=QAM-32, 8=QAM-64, 12=QAM-128, 16=QAM-256); (iii) Bytes 5-7: Carrier Center Frequency/100; (iv) Bytes 8-9: MPEG Program Number; (v) TTL—Bytes 10-11 indicating the number of seconds for which the entry is valid. Of course, other protocols may be used instead of the MCP described above. One piece of information that is available in the entry for each service is the Time-To-Live (TTL), which specifies the expected remaining duration of an active service. For instance, the TTL may specify that a particular SDV channel will be available for, say, another 30 minutes.
Instead of transmitting a channel change messages when a subscriber requests an SDV program, the subscriber's set top terminal can use the information in the active service list to tune to the desired channel, assuming of course that the channel is included in the active service list. Assuming that the channel is in fact present in the list, the set top terminal can send the channel change information for the SDV program at a later time, similar to the case mentioned above when a broadcast channel is requested. However, a Channel Change Message will need to be sent shortly before (e.g., 15-30 seconds) expiration of the TTL for the requested SDV program. In this way the SDV manager can extend the TTL to ensure that the SDV program will continue to be available for the subscriber. When the TTL is extended, the SDV program can be made available on either the same or a different channel number and frequency, which information can be communicated to the set top terminal when the SDV manager responds to the channel change message.
The set top terminal can even change from one SDV channel to another SDV channel without sending a channel change message by using the information in the active service list in the manner described above, provided of course that the TTL for the variously selected SDV programs do not expire. In this case the set top terminal can accumulate a history SDV channel changes that can be subsequently transmitted to the SDV manager in a single message.
In some cases additional bandwidth savings can be achieved by ensuring that the channel change message sent by the set top terminal fits within a single packet. Previously, such messages often occupied multiple packets. For instance, in one particular example the packet payload size is limited to 34 bytes, whereas the channel change message requires 36 or more bytes. Various techniques may be employed to reduce the channel change message so that it will fit within the available 34 bytes of a single packet. For instance, unused space can be removed from the messages. The unused space may have been provided for byte alignment purpose or to reserve space for future use. Reducing the message to a single packet conserves both upstream bandwidth (because only one packet sent instead of two) and downstream bandwidth (because only one acknowledgment needs to be sent, instead of the multiple acknowledgements that are needed for multiple packets).
When a set top terminal includes two or more tuners, additional bandwidth savings can be achieved by sending only one message when two would have otherwise been sent. For instance, tuner usage messages are transmitted from the set top terminal to the SDV manager whenever the status of a tuner changes, such as when a tuner is used to record a program, when a tuner terminates a recording session, or when the tuner is used to acquire a Video-on-Demand (VOD) program. If a set top terminal includes two or more tuners, the status of each tuner can be transmitted in a single message instead of sending a different message for each tuner. For instance, a situation can arise in which a set top terminal having two tuners, one of which is being used as the foreground terminal and the other is being used as the background terminal (e.g., for PIP), swap their respective roles. Conventionally, each tuner would send its own status message indicating its change in status from foreground to background, and visa versa. Instead, however, a single tuner usage message can be transmitted simply indicating that the roles of each of the two tuners have been interchanged.
Referring to
The SDV application 304 is responsible for communicating SDV control messages (e.g., CCMs) between the set top terminal and the SDV manager. For this purpose the set top terminal hardware 416 includes a channel change history database 410 in which the accumulated channel change information can be stored until it is ready to be transmitted to the SDV manager.
The processes described above, including but not limited to those presented in connection with
Although various examples are specifically illustrated and described herein, it will be appreciated that modifications and variations thereof are covered by the above teachings and are within the purview of the appended claims without departing from the spirit and intended scope of the invention. For example, it should be noted that in some cases some or all of the functionality of the SDV manager 215 may be transferred to each of the hubs 130, 132 and 134. For example, as described below, channel change messages may be communicated between the set top terminals and the hubs.
