Method and apparatus providing scalability for channel change requests in a switched digital video system

BACKGROUND

Presently, U.S. cable systems deliver hundreds of channels to some 60 million homes, while also providing a growing number of people with high-speed Internet access.

In 1989, General Instruments demonstrated that it was possible to convert an analog cable signal to digital and transmit it in a standard 6-MHz television channel. Using Motion Picture Expert Group (MPEG) compression, CATV systems installed today can transmit up to 10 channels of video in the 6-MHz bandwidth of a single analog channel. When combined with a 550-MHz overall bandwidth, this allows the possibility of nearly 1,000 channels of video on a system. In addition, digital technology allows for error correction to ensure the quality of the received signal.

In current Hybrid fiber-coaxial systems, a fiber optic network extending from the operator's central office carries all video channels out to a fiber optic node which services any number of homes ranging from 1 to 2,000 homes. From this point, all channels are sent via coaxial cable to each of the homes. Note that only a percentage of these homes are actively watching channels at a given time. Rarely are all channels being accessed by the homes in the service group.

In a switched video (SV) system, the unwatched channels do not need to be sent. In cable TV systems in the United States, equipment in the home sends a channel request signal back to a distribution hub (also referred to as a Switched Digital Video server or SDV server). If a channel is not currently being transmitted on the coaxial line, the distribution hub allocates a new Quadrature Amplitude Modulation (QAM) channel and transmits the new channel to the coaxial cable via the fiber optic node. For this to work, the equipment in the home must have two-way communication ability. Switched video uses the same mechanisms as Video on Demand (VOD) and may be viewed as a non-ending video on demand show that any number of users may share.

For a switched video system to work on cable systems, all digital television users in a subscription group must have devices capable of communicating to the distribution hub in a compatible manner. Switched video is sometimes abbreviated as SDV for switched digital video, or SVB for switched video broadcast.

Switched Digital Video technology enables Multiple System Operators (MSOs) to offer consumers a wider variety of programming while effectively managing Hybrid Fiber/Cable (HFC) network bandwidth. From a business perspective, SDV offers MSOs a number of key benefits. First, SDV is a cost-effective bandwidth management tool that immediately reduces HFC bandwidth requirements compared with traditional “linear” content delivery. Second, the SDV system bandwidth scales as a function of viewership rather than as a function of programs offered. Therefore SDV gives MSOs the ability to offer new programming tiers including premium sports, ethnic and other niche programming that drive customer retention and may drive new revenue through premium subscriptions. Third, SDV technology enables channel change times that are comparable to those in today's networks, so SDV services can be delivered transparently to consumers without a change in the television viewing experience, thereby eliminating concerns about viewer adoption that have plagued other new services. Finally, SDV systems capture very detailed viewership data in a secure manner that protects consumer privacy. This powerful information is used to optimize system performance, but it can also be used to optimize program offerings and lineups, and to enhance targeted advertising.

SUMMARY

Conventional mechanisms such as those explained above suffer from a variety of deficiencies. One such deficiency is that conventional SDV systems, the settop boxes immediately forward all channel change requests to an SDV server. This can result in the SDV server getting overloaded with channel change requests at certain times. For example, a large number of requests make take place when a particular popular program is about to start, for example when a digital Personal Video Recorder (PVR) is synchronized. As a result many viewers may request a channel change in order to view the popular program (e.g. millions of viewers switching to HBO at 9:00 p.m. on Sunday night to watch “The Sopranos”). In such a situation, the SDV server is inundated with channel change requests, causing a slowing down of SDV services between the SDV server and the corresponding settop boxes. The performance of the SDV server is a minor problem, the larger problem is the narrow upstream channels between the settop box and the SDV server become overloaded.

Embodiments of the invention significantly overcome such deficiencies and provide mechanisms and techniques that provide a buffering of channel change requests under certain conditions. In a particular embodiment of a method for providing scalability for channel change requests in a Switched Digital Video system, the method includes receiving a request for a channel change. The method further includes determining if a channel requested by the request for a channel change is currently being provided to the settop box as part of the block of channels being provided to the settop box. When the channel requested is being provided to the settop box then the transmission of the request can be buffered and delayed for a later time. On the other hand when the channel requested by the request for a channel change is not being provided to the settop box then immediately sending the request for a channel change to an SDV server in communication with the settop box.

Other embodiments include a computer readable medium having computer readable code thereon for providing channel change requests in a Switched Digital Video system. The compute readable medium includes instructions for receiving a request for a channel change at a settop box. The compute readable medium also includes instructions for determining if a channel requested by the request for a channel change is being provided to the settop box. The computer readable medium additionally includes instructions for when the channel requested by the request for a channel change is being provided to the settop box then buffering the request for a channel change for transmission of the request for a channel change at a later time as well as instructions for when the channel requested by the request for a channel change is not being provided to the settop box then immediately sending the request for a channel change to an SDV server in communication with the settop box.

Still other embodiments include a computerized device (e.g. a settop box), configured to process all the method operations disclosed herein as embodiments of the invention. In such embodiments, the computerized device includes a memory system, a processor, communications interface in an interconnection mechanism connecting these components. The memory system is encoded with a process that provides channel change requests in a Switched Digital Video system explained herein that when performed (e.g. when executing) on the processor, operates as explained herein within the computerized device to perform all of the method embodiments and operations explained herein as embodiments of the invention. Thus any computerized device that performs or is programmed to perform the processing explained herein is an embodiment of the invention.

Other arrangements of embodiments of the invention that are disclosed herein include software programs to perform the method embodiment steps and operations summarized above and disclosed in detail below. More particularly, a computer program product is one embodiment that has a computer-readable medium including computer program logic encoded thereon that when performed in a computerized device provides associated operations providing channel change requests in a Switched Digital Video system, as explained herein. The computer program logic, when executed on at least one processor with a computing system, causes the processor to perform the operations (e.g., the methods) indicated herein as embodiments of the invention. Such arrangements of the invention are typically provided as software, code and/or other data structures arranged or encoded on a computer readable medium such as an optical medium (e.g., CD-ROM), floppy or hard disk or other a medium such as firmware or microcode in one or more ROM or RAM or PROM chips or as an Application Specific Integrated Circuit (ASIC) or as downloadable software images in one or more modules, shared libraries, etc. The software or firmware or other such configurations can be installed onto a computerized device to cause one or more processors in the computerized device to perform the techniques explained herein as embodiments of the invention. Software processes that operate in a collection of computerized devices, such as in a group of data communications devices or other entities can also provide the system of the invention. The system of the invention can be distributed between many software processes on several data communications devices, or all processes could run on a small set of dedicated computers, or on one computer alone.

It is to be understood that the embodiments of the invention can be embodied strictly as a software program, as software and hardware, or as hardware and/or circuitry alone, such as within a data communications device. The features of the invention, as explained herein, may be employed in data communications devices and/or software systems for such devices such as those manufactured by Cisco Systems, Inc. of San Jose, Calif.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.

<figref idrefs="DRAWINGS">FIG. 1</figref> depicts a block diagram of a particular embodiment of a switched digital video system;

<figref idrefs="DRAWINGS">FIG. 2</figref> depicts a block diagram of a particular embodiment of a switched digital video system showing message flow for the system;

<figref idrefs="DRAWINGS">FIG. 3</figref> depicts a flow diagram of a particular embodiment of a method of performing channel change requests in accordance with embodiments of the present invention; and

<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates an example settop box architecture that performs channel change requests in accordance with embodiments of the invention.

DETAILED DESCRIPTION

Referring now to <figref idrefs="DRAWINGS">FIG. 1</figref>, an example Switched Digital Video system <b>10</b> incorporating embodiments of the present invention is shown. The system <b>10</b> includes a settop box <b>12</b> having an SDV client <b>14</b>. The settop box <b>12</b> is in communication with an SDV sever <b>18</b> and QAM <b>30</b>. The SDV server is in communication with an SDV manager <b>16</b> and a Session and Resource Manager (SRM) <b>20</b>. The QAM <b>30</b> is in communication with a Hub Internet Protocol/Gigabit Ethernet (IP/GbE) Switch/Router <b>28</b>, which in turn is in communication with a Headend IP/GbE Switch/Router <b>26</b>. The Headend IP/GbE Switch/Router <b>26</b> is also in communication with a Bulk Encryptor <b>24</b> and with an SDV staging processor <b>22</b>.

In a typical headend, content is received from multiple sources, including satellite, terrestrial off-air, fiber transport, storage media, IP data network and the like. The receiving equipment for these sources uses various standard or proprietary physical connections and interface standards. The SDV Staging Processor <b>22</b> performs multiple functions to groom the various sources for input to the SDV system <b>10</b>.

The SDV staging processor <b>22</b> translates the various source interfaces to User Datagram Protocol (UDP)/IP encapsulated packets carried in Ethernet frames. The SDV staging processor also converts any Variable Bit Rate (VBR) streams to clamped or Constant Bit Rate (CBR) streams. For some content, the staging processor <b>22</b> may convert one bit rate to another.

Further, the staging processor <b>22</b> converts any multi-program transport streams (MPTS) to single-program transport streams (SPTS), performs digital program insertions (DPI) to insert local ads into the source content, and performs segmentation of program streams into separate events for storage on a media subsystem.

The output of the staging processor <b>22</b> may be unicast or multicast IP. In the case of encrypted streams, the staging processor outputs a unicast IP stream bound for the bulk encryptor <b>24</b>. In the case of an SDV stream for which encryption is not required, the staging processor may output a multicast stream directly into the switching network.

Since SDV streams are shared by multiple viewers, they are treated as broadcast streams for purposes of encryption. Since the encryption device is not aware of, and does nothing unique for individual viewers, encryption of SDV streams is most effectively centralized in the headend rather than integrated into edge modulators. This is most efficiently done with an IP network-attached Bulk Encryptor <b>24</b>. For encrypted switched streams, the bulk encryptor <b>24</b> receives IP unicasts and generates and sources the IP multicasts. It may also be used to generate multicasts for unencrypted streams to simplify network management if desired. The bulk encryptor <b>24</b> is implemented as a network attached device, so it is possible to migrate some or all bulk encryption to the network edge in order to accommodate future ad-insertion zones, without significant impact to the network design.

As in all HFC systems, the QAM modulator <b>30</b> enables the transmission of a multiplex of digital streams via a Radio Frequency (RF) carrier in an HFC spectrum channel. The digital streams may be composed of strictly MPEG transport packets, or could contain IP packets, as do QAMs used for Data Over Cable Service Interface Specifications (DOCSIS) Cable Modem Termination Systems (CMTSs). The SDV system <b>10</b> uses the QAM modulator <b>28</b> to request (join) and terminate (leave) IP multicasts, and to transmit programs as MPEG transport packets in RF. IP encapsulation is not used in the RF output of the QAM modulator <b>30</b>. Note that because IP multicast is used in the “core” of the SDV network, it is a straightforward extension of the system to continue IP transport to the end user. This can be accomplished through a CMTS in HFC access networks, or through another type of edge device for other access technologies, for example.

In the SDV system <b>10</b> described here, the QAM modulator <b>30</b> interfaces to an element manager for provisioning and control. Provisioning sets the output frequencies, modulation type, and Transport Stream Identifiers (TSID) on each output carrier and IP addresses of control and content ports. A control system or Session and Resource Manager <b>20</b> (SRM, described in detail below), which may be the same as the provisioning system, allocates QAM spectrum to various applications such as Video on Demand (VOD) and SDV. Spectrum may be allocated to the applications on the basis of entire QAM carriers (inter-carrier QAM sharing—sharing of bandwidth within a multi-carrier QAM modulator chassis) or even within QAM carriers (intra-carrier QAM sharing). Such allocation may be static or dynamic.

For any QAM carrier to be used for SDV, the modulator must support session-based input-to-output stream mapping, as opposed to table-based mapping. Upon request of the SDV server <b>18</b>, the SRM <b>20</b> allocates a number of “shell sessions” each with a session identifier (sessionID), a nominal bandwidth, and a RF carrier assignment. Content multicast address, program number, and actual bandwidth are not yet specified at this point; hence the name “shell” session, implying that this session is an empty reservoir or pipe to be filled with content at a later time.

By using this shell session mechanism, a portion of the available bandwidth on the edge QAM <b>30</b> is reserved for exclusive (albeit possibly temporary) use by the SDV (or other service) server <b>18</b>. This allows the SRM <b>20</b> to act as an arbitrator of edge QAM resource contention. It may seem redundant for a master controller (e.g., the SRM <b>20</b>) to allocate shell sessions for management by a subservient controller (e.g., the SDV server <b>18</b>), however, this capability is essential in the SDV application because of the real-time nature of SDV control traffic, and the volume of this traffic that is generated during the course of ordinary TV viewing. The ability of multiple real-time sub-controllers (SDV server, VOD server, etc.) to work within allocations of edge resource bandwidth relieves the master controller (SRM <b>20</b>) of the burden of time-critical high-volume tasks. This makes the system more reliable and more scalable while retaining the ability to share bandwidth dynamically between multiple services.

When it is required to provide a program to a user, or users, in a particular group of settops boxes <b>12</b>, or service group, the SDV server will select a shell session on a QAM modulator feeding that service group. By referring to the sessionID, the SDV server <b>18</b> will command the QAM modulator <b>30</b> to “bind” that session to a specific program content stream. The server references this content by its IP multicast address. It further provides a program number for use at the output of the QAM modulator <b>30</b>, and also logs the actual program bandwidth.

Upon receiving session binding information for a multicast that it is not already a member of, the QAM modulator <b>30</b> sends an Internet Group Management Protocol (IGMP)v3 “membership report” requesting to “join” the specified multicast group. At this point the edge switch-router receiving this request performs the actual switch of the content to the GbE port connected to that QAM modulator. The QAM modulator <b>30</b> receives this content, “de-jitters” it, multiplexes it with other content on the specified carrier, and modulates the composite digital stream for transmission to the service group. Session-based QAM modulators enable full intra-carrier QAM sharing. Carriers can be designated as “shared” between multiple applications. The SRM <b>20</b> will set up VOD sessions and/or shell session on a given QAM carrier upon request. The shell sessions on that carrier are then available for binding by the SDV server <b>18</b> at the same time that VOD sessions are available on the same carrier.

For a mix of VOD and SDV, the SRM <b>20</b> continues to function as the primary resource manager, but the SRM <b>20</b> dynamically apportions parts (sessions) of the bandwidth of an individual QAM RF carrier (intra-carrier QAM sharing) to the SDV server <b>18</b> (described in detail below), which, for SDV purposes, communicates directly with the settop boxes and performs bindings on the QAM shell sessions and bandwidth that it has been allocated. The SDV server <b>18</b> uses an extension to the Time Warner Session Setup Protocol (SSP) to request, from the SRM <b>20</b>, shell sessions on a QAM feeding a given service group. The SRM <b>20</b> identifies available bandwidth on the service group QAM, and provides shell session space to the SDV server <b>18</b> thereby reserving bandwidth on the QAM modulator for exclusive use by the SDV server <b>18</b>. In the reply from the SRM <b>20</b>, the SDV server <b>18</b> is given the control IP address of the QAM <b>30</b> so that the SDV server <b>18</b> may directly control session bindings. Prior to granting QAM shell session space (and thereby bandwidth) to the SDV server <b>18</b>, the SRM <b>20</b> sets up the actual shell sessions on the selected QAM in order to prepare it for binding requests from the SDV server <b>18</b>. The QAM is not told what server may request these bindings since they may come from a primary or a backup SDV server <b>18</b>. Since the SRM <b>20</b> is the master bandwidth controller in the system, the SRM <b>20</b> may need to recover bandwidth previously assigned to the SDV server <b>18</b>. The SRM <b>20</b> may do so by sending a Bandwidth Reclamation Request to the SDV server <b>18</b> for a specified service group. Upon receipt of such a request, the SDV server <b>18</b> initiates a QAM session teardown request for sufficient shell session bandwidth to cover the reclamation.

The SDV server <b>18</b> is part session manager in that it directly receives and processes settop box channel change requests. It is also part resource manager in that, for its allocation of QAM shell sessions, it can bind and thus assign those to real programs for transmission to the service groups. The SDV server <b>18</b> receives channel change requests for switched content from a settop to bind that content to a session on a QAM feeding that settop's service group, and responds to that settop box with the frequency and program number where that content may be found. The SDV server <b>18</b> also fields channel change request messages for non-SDV broadcast channels in order to gather anonymous usage statistics and understand activity.

The SDV server <b>18</b> can anticipate spectrum demand for SDV and request shell sessions from the SRM <b>20</b> before running out of available QAM bandwidth. In the absence of new shell sessions from the SRM <b>20</b>, the SDV server <b>18</b> reallocates existing bandwidth in order to provide for active users at the expense of inactive ones. Conversely, if the SDV server <b>18</b> recognizes that it is controlling bandwidth in excess of its anticipated requirements, then the SDV server <b>18</b> may initiate session teardown requests to the SRM <b>20</b> in order to return the excess bandwidth to the total system pool. This give and take process is ideally arbitrated by a central controller (global SRM) in the context of business rules.

The ebb and flow of edge resource allocation can be volunteered by the servers of various contending services or forced upon them by the SRM <b>20</b>. The SDV server <b>18</b> generates a repeating (carousel) file containing a list of services currently streaming to each service group, and the tuning parameters required to access them. This “mini-carousel” serves as a redundant tuning mechanism, and in some cases (such as the presence of contention in the upstream communications path) serves to improve channel change response time. The mini-carousel technique applies to any SDV system where the control path is independent of the media path or where the latency or reliability of interactive signaling may degrade while the media remains usable. Each service group requires a unique mini-carousel, which may be replicated in each of the QAM RF carriers and/or may employ other delivery methods. This typically low-bandwidth (150 kbps) stream allows the settop box to tune already-streaming programs in the absence of two-way communication. This makes the SDV system very reliable in the face of impaired two-way connectivity, and is critical for launch of SDV in the presence of non-responding settop boxes.

The SDV server <b>18</b> requires connection to both the control network, for communication with other network elements including the clients, and also to the content routing network in order to make the mini-carousel IP multicast available to SDV client via the content-carrying QAM modulators. In order to prevent settop boxes from accessing incorrect content due to outdated information in the mini-carousel, the server must manage program numbers for SDV ensuring that no two programs share the same program number.

SDV servers <b>18</b> may be deployed in the headend or distributed at remote hubs. Since the multimedia content streams are independent of the SDV communications and control, centralizing the servers does not require separate content streams per service group. Unlike VOD, transport system cost does not appreciably increase based on SDV server location, as long as the switch-routers are distributed to the hubs.

The user interface for control of the SDV servers and system is in the SDV Manager <b>16</b>. The SDV manager <b>16</b> provides a means for operator configuration of the service group assignments and various settings for the SDV servers. The interface between the manager and servers is Simple Network Management Protocol (SNMP). The SDV Client <b>14</b> is a software component that should be fully integrated in the resident application (navigation guide) of an SDV-enabled settop box <b>12</b> in order to make the SDV service transparent to the user. The SDV client <b>14</b> enables the settop box <b>12</b> to communicate to the SDV server <b>18</b> using the SDV Channel Change Message Interface Specification.

Referring now to <figref idrefs="DRAWINGS">FIG. 2</figref>, the system interfaces for the SDV system <b>10</b> of the present invention are shown. The SDV Channel Change Message (CCM) Interface Specification 32 is used between the SDV server <b>18</b> and the SDV client <b>14</b> running on the settop box <b>12</b>. This interface provides a mechanism for changing SDV channels, and also for notifying the system of channel changes to and between non-SDV channels. The SDV CCM <b>32</b> operates in conjunction with the mini-carousel. The SDV server <b>18</b> issues mini-carousel messages <b>34</b> at a periodic rate to convey a list of available services and the tuning information required to receive those services. Available services are those programs currently streaming in the digital service carriers offered to the client. When the user requests a channel change, and the requested service is listed as available in the mini-carousel, the client will select the service using the information obtained from the mini-carousel. When the confirm message is received, the client will re-select the service if the tuning information received in the confirm message differs from the current selection (frequency, modulation format, MPEG program number) state.

The mini-carousel operates between the SDV server <b>18</b> and the SDV client <b>14</b> running on a settop box <b>12</b>. This interface provides a method of distribution of tuning information from the SDV server <b>18</b> to the SDV client <b>14</b> to enhance channel change operation. The mini-carousel carries information about the programs that are currently being carried in the SDV service. It also carries the IP addresses of primary and backup SDV servers used by the SDV client to communicate with the SDV server <b>18</b>. The SDV server <b>18</b> originates the mini-carousel. It generates an IP multicast containing the mini-carousel and sends it to the closest content router (e.g., Hub <b>28</b>).

Upon initializing, the SDV server <b>18</b> will acquire sessions on specific QAM frequencies in all SDV service groups. Through this initialization process and subsequent operation, the SDV server <b>18</b> learns the QAM frequencies that are available to SDV and binds a shell session on each of these frequencies to the mini-carousel IP multicast. The initial mini-carousel will include the topology information for the service group, i.e., the IP addresses of the primary and secondary SDV servers as well as the “listen port”, the UDP port on the SDV server <b>18</b> to which the SDV client <b>14</b> delivers channel change requests. Subsequently, the SDV server <b>18</b> will add program tuning information for all programs.

Upon initialization, the SDV client <b>14</b> scans QAM frequencies in its service group to acquire the mini-carousel data. From the mini-carousel, the SDV client <b>14</b> extracts registration and communication information including the IP address of the SDV server <b>18</b>, topology information (service group ID), client configuration parameters, and SDV channel map (tuning) information, and stores this information locally. The SDV client <b>14</b> extracts these parameters every time it acquires the mini-carousel data. If any of these parameters changes, the SDV client <b>14</b> performs re-registration with the SDV server <b>18</b>.

The SDV client <b>14</b> also acquires and re-reads the mini-carousel each time a channel change request is made while the associated tuner is tuned to an SDV QAM frequency. If the version number of the mini-carousel has changed, the SDV client <b>14</b> will refresh its locally stored tuning information with the current information.

Upon initialization of the system <b>10</b>, and after provisioning by the SDV manager <b>16</b>, the SDV server <b>18</b> requests from the SRM <b>20</b> the initial bandwidth required for each of its service groups. The request and response <b>36</b> is done using the Session Setup Protocol Extension for Server Initiated Setup, an extension message set to DSM-CC. The bandwidths requested serve as an initial condition for each service group. More bandwidth may be requested from the SRM <b>18</b> as required by demand for unique SDV services. When less bandwidth is required for extended periods, the SDV server <b>18</b> may release some bandwidth back to the SRM's pool. The initial bandwidth requested and the minimum bandwidth maintained per server is user settable.

Bandwidth requests are for contiguous “groups” of the provisioned “fundamental bandwidth unit”, in this case 625 kbps. An example may be a request for 36 “units” of 625 kbps for a total contiguous bandwidth allocation of 22.5 Mbps. This does not mean that the SDV server <b>18</b> is in any way constrained to use this bandwidth for services of 625 kbps or any other number. What it does is provide a total bandwidth in bits per second for the SDV server <b>18</b> to manage as required. For example, this bandwidth could be used for one High Definition (HD) service at 15 Mbps, plus two Standard Definition (SD) services at 3.75 Mbps. It could also be used for six SD services at 3.75 Mbps. It could also be used for one HD service at 22.2 Mbps and one audio service at 300 kbps. There is no requirement to use the bandwidth in multiples of the fundamental unit. No “quanta” of bandwidth is required or implied.

When requesting session bandwidth for service groups, the SDV server <b>18</b> also provides a session identifier or session ID for each session in the group. To maintain unique session IDs in the system, the requester uses its own Media Access Control (MAC) address as the leading bytes in the session identifier (ID).

Prior to granting bandwidth to the SDV server <b>18</b> for QAM <b>30</b>, the SRM <b>20</b> sets up a shell session <b>38</b> for each session ID granted. The SRM <b>20</b> grants the bandwidth the SDV server <b>18</b> has requested for a particular service group. Note that the SDV server <b>18</b> has no knowledge of what QAM modulators feed the service group for which this request is being made. When the bandwidth is granted the QAM chassis and carrier on which it is granted is identified by control IP address and transport stream Identifier (TSID). Applications, such as SDV learn the control IP address and TSIDs of resources currently available to those applications only upon those resources being granted through Server Interactive Session Request messaging. The SRM <b>20</b> is not obligated to grant all bandwidth requested by the SDV server <b>18</b>. The SRM <b>20</b> is the master controller of bandwidth and may be driven by business rules to allocate bandwidth to applications. Those applications may request at will, but will have to function gracefully with what has been granted. The goal of bandwidth initialization is to provide an SDV server <b>18</b> with an allocation of contiguous bandwidth for each service group, along with enough session IDs such that it can use that bandwidth in the granularity required.

An example of a basic channel change operation will now be described. Once groomed and encrypted streams are available, the SDV server has requested an initial allotment of bandwidth and session IDs from the SRM, and settop boxes have initialized, the system <b>10</b> is primed for channel change requests. When an SDV capable settop box <b>14</b> seeks to receive switched content, it sends a channel change request to its assigned SDV server's IP address (channel change request <b>32</b>). In the channel change request <b>32</b>, the settop box <b>14</b> specifies the desired service (for example “Channel 8”), and includes the service group number that was automatically discovered. Upon receiving a channel change request <b>32</b> from a settop box <b>12</b> within a specified service group, the SDV server <b>18</b> will look to see if the requested content is already available to the service group. If so, the SDV server <b>18</b> simply responds to the settop box <b>12</b> providing the required tuning information, including frequency, modulation type and program number. If the requested content is not already available to the service group, then the SDV server <b>18</b> will make it available. The SDV server <b>18</b> looks for available bandwidth on a QAM modulator belonging to that service group. The SDV server <b>18</b> considers the bandwidth of the requested service and attempts to intelligently allocate the bandwidth such as to maintain contiguous bandwidth for future requests of low and high bandwidth services.

Once a particular QAM carrier with available bandwidth has been selected for the requested service, the SDV server uses Session Binding messages <b>40</b> to specify the content for an existing session ID. For example, the SDV server <b>18</b> tells QAM <b>30</b> to “bind” the appropriate session ID to a service to be found at specified multicast addresses, which requires 15 Mbps of bandwidth. The bandwidth supplied at binding will likely not be the same as the bandwidth specified when the shell session was created. The bandwidth (in bits per second) supplied at binding is the actual bandwidth to use for purposes of de-jittering and bit rate accounting. QAM <b>30</b> is probably one carrier in a chassis supplying other carriers to other service groups. The QAM modulator chassis containing QAM <b>30</b> may already be receiving “SDV Channel 8” and transmitting it to a different service group on a different carrier. In this case, this stream must now be sent to the new requesting service group as well. Thus the QAM modulator <b>30</b> acts as the service “switch” in this case.

In the case where the QAM chassis is not already receiving SDV Channel 8 for another service group, then that QAM chassis must request to receive that content from the network. It does this by issuing an Internet Group Management Protocol (IGMP)v3 “Membership Report” <b>42</b> to the edge switch-router <b>28</b> requesting to “join” the IP multicast for that content. In this case, the “switching” of the switched service occurs in the network switch-router <b>28</b> and flows into the QAM <b>30</b> by way of path <b>4</b>, and through the QAM <b>30</b> to the settop box <b>12</b> as shown by path <b>46</b>.

Prior to receiving the first channel change request from a specific settop box, the SDV server <b>18</b> has no knowledge of that settop box. The SDV server <b>18</b>, as an independent application, does not tap into any database of settop boxes nor their authorizations. As the SDV server <b>18</b> receives channel change requests from settop boxes, it learns about those settop boxes and enters them into its database. From that point on, the SDV server <b>18</b> expects to hear future channel change requests, or if none, periodic activity reports from those settop boxes. In order to keep its database free of records for inactive settop boxes, if after a specified time the SDV server <b>18</b> has not heard an activity report, it deletes the settop box from its database.

The SDV client <b>14</b> is responsible for not requesting a channel change to services for which it is not authorized. If the SDV client did send such a channel change request, the SDV server <b>18</b> would return tuning information and otherwise respond normally. The client, however, would not be able to decrypt and display any encrypted services for which it is not authorized.

The Basic Channel Change Sequence described above covered the case in which there was sufficient unused shell session bandwidth to cover channel-change requests to content that was not already on a service group. It also covered the case where the content was already available to the service group. There can be a situation wherein a channel-change request is received for content not already available to a service group, and there is insufficient available shell-session bandwidth. In this case the SDV server <b>18</b> may immediately issue a server interactive session request to the SRM <b>20</b> for more shell session bandwidth. This request may be identical to the requests made during initialization of the SDV server <b>18</b>. However, instead of using increments of the “fundamental bandwidth unit”, the SDV server <b>18</b> may elect to request a session or sessions for exactly the bandwidth required in order to expedite the grant. If available, the SRM <b>20</b> may grant additional shell session bandwidth, and the channel-change will then proceed as described above.

Due to business rules, other use of the available narrowcast bandwidth, or heavy use of all edge QAMs, the SRM <b>20</b> may reject the request for additional shell sessions. In this case, the SDV server <b>18</b> must review its rules and last user-activity on its existing managed bindings, and decide whether to terminate an existing binding and reuse if for the current request, or to cause the settop box <b>12</b> to display a message reporting the temporary unavailability of the requested service.

When a channel change is requested by a user, a channel change request is sent out at the time the user tries to change the channel. The settop box is able to check if the channel is already available to the user by way of the mini-carousel tuner table. As such, an immediate change request may not be required, however a channel change request is needed at some point in time as the SDV server needs to know how many users are interested in the channel and also for accounting purposes.

There may be a situation when a large number of channel change requests occur together (referred to as a “flash mob” of channel changes), for example at a top of an hour or when a commercial occurs. In such a situation, the SDV server may become inundated with channel change requests, causing a slowing down of SDV services between the SDV server and the corresponding settop boxes. The performance of the SDV server is not the only potential bottleneck, but also the narrow upstream channels between the settop box and the SDV server become overloaded. Further, the flash mob of channel change requests that are directly user generated are not a prime threat, but instead the flash mob of channel changes produced by Personal Video Recorders (PVRs) or the like can contribute to the delay in providing the channel change requests to the SDV server.

By way of embodiments of the present invention, a buffering of channel change requests under certain conditions is performed. In a particular embodiment of a method for providing channel change requests in a Switched Digital Video (SDV) system, the method includes receiving a request for a channel change at a settop box. The method further includes determining if a channel requested by the request for a channel change is currently being provided to the settop box. When the channel requested by the request for a channel change is being provided to the settop box then the request for a channel change is buffered for transmission of the request for a channel change at a later time. On the other hand, when the channel requested by the request for a channel change is not being provided to the settop box then the request for a channel change is sent immediately to an SDV server in communication with the settop box.

The buffering of one or more request for a channel change for transmission of the request for a channel change at a later time may further include grouping together multiple requests for a channel change and transmitting the multiple requests for channel change together (also known as “packing” channel change requests). This may further include sending the multiple requests for a channel change after a predetermined period of time has elapsed, which also serves to reduce jitter. Additionally, it is common for a user to ‘channel surf’ wherein the user cycles through channels in a sequential manner. In this mode the transmit delay can be made higher than usual as the user can be expected to continue changing channels.

In some situations, the requests for a channel change can be anticipated, and the requests sent from the settop box to the SDV server before a flash mob of channel change requests occurs. The anticipation of a channel change request can be based on a prior history associated with a particular settop box or due to an occurrence of an event which draws a large number of viewers such as the Super Bowl. Additionally, if an inbuilt PVR has a scheduled recording, the settop box and/or server knows that a channel change needs to occur in the future.

A flow chart of a particular embodiment of the presently disclosed method is depicted in <figref idrefs="DRAWINGS">FIG. 3</figref>. The rectangular elements are herein denoted “processing blocks” and represent computer software instructions or groups of instructions. The diamond shaped elements, are herein denoted “decision blocks,” represent computer software instructions, or groups of instructions which affect the execution of the computer software instructions represented by the processing blocks.

Alternatively, the processing and decision blocks represent steps performed by functionally equivalent circuits such as a digital signal processor circuit or an application specific integrated circuit (ASIC). The flow diagrams do not depict the syntax of any particular programming language. Rather, the flow diagrams illustrate the functional information one of ordinary skill in the art requires to fabricate circuits or to generate computer software to perform the processing required in accordance with the present invention. It should be noted that many routine program elements, such as initialization of loops and variables and the use of temporary variables are not shown. It will be appreciated by those of ordinary skill in the art that unless otherwise indicated herein, the particular sequence of steps described is illustrative only and can be varied without departing from the spirit of the invention. Thus, unless otherwise stated the steps described below are unordered meaning that, when possible, the steps can be performed in any convenient or desirable order.

Referring now to <figref idrefs="DRAWINGS">FIG. 3</figref>, a particular embodiment of a method <b>100</b> of providing scalability for channel change requests in a Switched Digital Video (SDV) system is shown. The method <b>100</b> begins with processing block <b>102</b> which discloses receiving a request for a channel change. In certain embodiments this can include, as shown in processing block <b>104</b>, receiving an anticipated request for a channel change.

Processing continues with decision block <b>106</b> wherein a determination is made regarding whether the channel requested by the channel change request is currently being provided to the settop box. Channels are provided as groups of channels to the settop box in SDV systems. The channel requested might be one of the channels of the block of channels already provided to the settop box.

When the determination in decision block <b>106</b> is that the channel being requested by the channel change request is being provided to said settop box, as shown in processing block <b>108</b> a buffering of the request for a channel change for transmission of the request for a channel change at a later time occurs. Processing block <b>110</b> states that in certain scenarios, it may be possible to group together (pack) multiple requests for a channel change and transmitting the multiple requests for channel change together. This serves to decrease load on the SVD server as the SDV server can process the requests in one group rather than in individual packets. As shown in processing block <b>112</b>, this transmitting of multiple requests for a channel change together reduces channel change request jitter.

Processing continues with processing block <b>114</b> which recites transmitting the request for a channel change at a later time. As shown in processing block <b>116</b> the transmitting the request for a channel change at a later time comprises sending the request for a channel change after a predetermined period of time has elapsed.

Referring back to decision block <b>106</b>, when the determination is that the channel being requested by the channel change request is not being provided to the settop box, then processing continues with processing block <b>118</b>. Processing block <b>118</b> recites immediately sending the request for a channel change to an SDV server in communication with said settop box.

Embodiments of the present invention, by caching the current channel change requests and jittering and packing the requests, the scalability and response time of the SDV device can be increased during flash mobs of channel change requests and also in general usage. The present invention serves to separate the time-independent information from stale information and provided prioritized processing of the time-dependent information.

<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates example architectures of a computer system that is configured as a settop box <b>240</b>. In this example, the settop box includes an interconnection mechanism <b>211</b> that couples a memory system <b>212</b>, a processor <b>213</b>, and a communications interface <b>214</b>. The communications interface <b>214</b> allows the settop box <b>240</b> to communicate with external devices or systems. The memory system <b>212</b> may be any type of computer readable medium that is encoded with an application <b>255</b>-A that represents software code such as data and/or logic instructions (e.g., stored in the memory or on another computer readable medium such as a disk) that embody the processing functionality of embodiments of the invention as explained above. The processor <b>213</b> can access the memory system <b>212</b> via the interconnection mechanism <b>211</b> in order to launch, run, execute, interpret or otherwise perform the logic instructions of the applications <b>255</b>-A for the settop box in order to produce a corresponding process <b>255</b>-B. In other words, the process <b>255</b>-B represents one or more portions of the application <b>255</b>-A performing within or upon the processor <b>213</b> in the settop box.

It is to be understood that embodiments of the invention include the applications (i.e., the un-executed or non-performing logic instructions and/or data) encoded within a computer readable medium such as a floppy disk, hard disk or in an optical medium, or in a memory type system such as in firmware, read only memory (ROM), or, as in this example, as executable code within the memory system <b>212</b> (e.g., within random access memory or RAM). It is also to be understood that other embodiments of the invention can provide the applications operating within the processor <b>213</b> as the processes. While not shown in this example, those skilled in the art will understand that the computer system may include other processes and/or software and hardware components, such as an operating system, which have been left out of this illustration for ease of description of the invention.

Having described preferred embodiments of the invention it will now become apparent to those of ordinary skill in the art that other embodiments incorporating these concepts may be used. Additionally, the software included as part of the invention may be embodied in a computer program product that includes a computer useable medium. For example, such a computer usable medium can include a readable memory device, such as a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having computer readable program code segments stored thereon. The computer readable medium can also include a communications link, either optical, wired, or wireless, having program code segments carried thereon as digital or analog signals. Accordingly, it is submitted that the invention should not be limited to the described embodiments but rather should be limited only by the spirit and scope of the appended claims.