WO2013037032A1 - Method and system for managing bandwidth - Google Patents

Method and system for managing bandwidth Download PDF

Info

Publication number
WO2013037032A1
WO2013037032A1 PCT/CA2011/050549 CA2011050549W WO2013037032A1 WO 2013037032 A1 WO2013037032 A1 WO 2013037032A1 CA 2011050549 W CA2011050549 W CA 2011050549W WO 2013037032 A1 WO2013037032 A1 WO 2013037032A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
receiver
request
broadcast
multicast
Prior art date
Application number
PCT/CA2011/050549
Other languages
English (en)
French (fr)
Inventor
Lisa Etsuko KAMITAKAHARA
Antonio Colantonio
Sandip Singh
Nasir Mahmood ANSARI
Clinton Alexander Pierce SHERIDAN
Original Assignee
Rogers Communications Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Rogers Communications Inc. filed Critical Rogers Communications Inc.
Priority to CA2847703A priority Critical patent/CA2847703C/en
Priority to EP11872347.7A priority patent/EP2756685A4/de
Priority to PCT/CA2011/050549 priority patent/WO2013037032A1/en
Publication of WO2013037032A1 publication Critical patent/WO2013037032A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H20/00Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/42Arrangements for resource management
    • H04H20/423Transmitter side
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2347Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving video stream encryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H04N21/26216Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving the channel capacity, e.g. network bandwidth
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64723Monitoring of network processes or resources, e.g. monitoring of network load
    • H04N21/64738Monitoring network characteristics, e.g. bandwidth, congestion level

Definitions

  • the present disclosure relates to content delivery systems and, more particularly, to methods and systems for managing bandwidth in content delivery systems.
  • Content delivery systems such as cable television systems, satellite television systems and Internet protocol television systems (I PTV) often deliver content, such as television programming from a head end system which is operated by a service provider to one or more receivers operating within the content delivery system.
  • I PTV Internet protocol television systems
  • Such content delivery systems often have a limited amount of bandwidth available to deliver content.
  • wireless content delivery systems such as satellite television systems may be required to deliver signals within a specific portion of the wireless spectrum.
  • wired content delivery systems such as cable television systems, operate over a wired transmission medium which has a finite amount of usable bandwidth.
  • bandwidth for content delivery may be further limited where service providers provide other services in addition to content delivery system services.
  • service providers may operate a voice communication service and/or an Internet service over a transmission medium which they also use for content delivery system services (such as television delivery services).
  • content delivery system services such as television delivery services.
  • Each of these services may require bandwidth in the transmission medium, thus reducing the overall availability of bandwidth in the transmission medium.
  • FIG. 1 is a system diagram of an example content delivery system in accordance with example embodiments of the present disclosure
  • FIG. 2 is a system diagram of an example content delivery system in accordance with example embodiments of the present disclosure
  • FIG. 3 is a block diagram of an example head end system for use with a content delivery system such as the content delivery systems of FIGs. 1 and 2;
  • FIG. 4 is a block diagram of an example receiver for use with a content delivery system such as the content delivery systems of FIGs. 1 and 2;
  • FIG. 5 is a flowchart of a method for managing bandwidth in accordance with example embodiments of the present disclosure
  • FIG. 6 is a flowchart of a method for managing bandwidth in accordance with example embodiments of the present disclosure
  • FIG. 7 is a flowchart of a method for managing bandwidth in accordance with example embodiments of the present disclosure.
  • FIG. 8 is a flowchart of a method for managing bandwidth in accordance with example embodiments of the present disclosure.
  • the present disclosure describes a method of managing bandwidth in a content delivery system.
  • the method comprises: identifying two or more content items which are associated with at least some common content and which are temporally related; determining a relative priority of the least some of the identified content items; and allowing a receiver requesting the content associated with a lower priority content item to access a multicast associated with a higher priority content item.
  • the present disclosure describes a bandwidth management system.
  • the bandwidth management system includes at least one processor and a memory coupled to the at least one processor.
  • the memory has stored thereon processor executable instructions which, when executed by the processor cause the processor to: identify two or more content items which are associated with at least some common content and which are temporally related; determine a relative priority of the least some of the identified content items; and allow a receiver requesting the content associated with a lower priority content item to access a multicast associated with a higher priority content item.
  • processor executable instructions which, when executed by the processor cause the processor to: identify two or more content items which are associated with at least some common content and which are temporally related; determine a relative priority of the least some of the identified content items; and allow a receiver requesting the content associated with a lower priority content item to access a multicast associated with a higher priority content item.
  • FIG. 1 a block diagram of an example content delivery system 100 is illustrated in which example embodiments of the present disclosure may be applied.
  • the content delivery system 100 is configured to deliver content from a content source system to a content destination system.
  • the system from which content is delivered i.e. the content source system
  • the system receiving the content i.e. the content destination system
  • a media player such as a television
  • the content delivery system 100 is a broadcast television system which delivers television content such as broadcast television shows.
  • the content delivery system 100 is configured to deliver content over a broadcast or multicast domain 195 (which, for simplicity, will be referred to as a broadcast domain 195).
  • the broadcast or multicast domain 195 includes a plurality of receivers 104.
  • the broadcast domain 195 includes a first receiver 104a, a second receiver 104b, and a third receiver 104c.
  • the first receiver 104a, second receiver 104b and third receiver 104c are connected to the head end system 102.
  • the content delivery system 100 may provide a subscription based content delivery service in which each receiver 104 operating in the content delivery system 100 may be associated with a subscriber to the content delivery system 100. Each subscriber may be authorized to view specific content. For example, each subscriber may be authorized to view a specific set of broadcast streams associated with channels which the subscriber subscribes to.
  • the content delivery system 100 may deliver content to a plurality of subscribers associated with a plurality of receivers 104.
  • the head end system 102 may be owned and/or operated by a content service provider including a television service provider such as a cable television service provider and/or a satellite television service provider.
  • the head end system 102 broadcasts or multicasts content (such as television programming) to a plurality of receivers 104 located within a broadcast or multicast domain 195.
  • Multicasting content refers to sending content to two or more receivers 104.
  • Broadcasting content refers to sending content throughout the broadcast domain 195. Since such a broadcast may be received by two or more receivers, the term multicasting as used herein may also include broadcasting.
  • the receivers 104 are typically located in a location associated with subscriber, such as, for example, the home of a subscriber. Accordingly, in at least some example embodiments, the receivers 104 may be referred to as Customer Premises Equipment (CPE).
  • CPE Customer Premises Equipment
  • the receivers 104 may be connected to a media player, such as a television, on which content received at the receiver 104 may be displayed.
  • a receiver 104, or parts thereof may be internal to a media player (e.g. the television).
  • a receiver 104 may be a component of a television which is included in the television at the time of manufacture.
  • a receiver 104 may be an external receiver 104 which is connected to the media player (e.g.
  • the plurality of receivers 104 operating within the broadcast domain 195 may include, in at least some example embodiments, one or more set top boxes.
  • a set top box is a device which connects to a television (or other display) and an external source of signal, turning the signal into content which may be displayed on the television (or other display).
  • the term set top box includes devices which do not, necessarily, sit on top of a television. That is, the term set top box may refer to any device which is external to a television (or other display) and which receives an external signal, turns the signal into content and displays the signal on the display.
  • the receivers 104 operating within the broadcast domain 195 may also take other forms including, for example, a gaming console, a cable card, a personal computer, a tablet device, a smartphone, etc.
  • the receivers 104 may be any electronic devices at which content from a head end system 102 may be received.
  • the receivers 104 are connected to the head end system 102 through a transport medium 197 which may, in various embodiments, be a wired transport medium (such as coaxial cable and/or fibre optic cable) or wireless transport medium 197 (such as radio frequency (RF) based transport mediums).
  • the content delivery system 100 may, in various embodiments, be a wired television system 162 (FIG. 1), such as a cable television system, which delivers content to the receiver 104 over a wired transport 163 (such as coaxial cable and/or fibre optic cable), or a satellite television system 154 (FIG. 2) which delivers content to the receiver 104 over a satellite transport 155.
  • the content delivery system 100 may also be based on other broadcast or multicast based content delivery technologies and transport mediums apart from those specifically discussed herein.
  • the content delivery system 100 is a wired television system 162, such as a cable television system.
  • the head end system 102 and the receivers 104 operating within the broadcast domain 195 are connected via a wired transport 163.
  • the wired transport 163 may include a cable.
  • the wired transport 163 may, in various embodiments, include copper or other wires such as coaxial cable and/or may include an optical transport medium, such as fibre optic cables.
  • the head end system 102 and the receivers 104 are configured to permit downstream communications to the receivers 104 through respective transport mediums and protocols. More particularly, the head end system 102 and the receivers 104 are configured to permit content, such as television content, to be delivered to the receivers 104 for display on media players (such as a television) associated with respective receivers. Where the content delivery system 100 is a wired television system 162, such as a cable television system, the head end system 102 may deliver content to the receiver 104 through the wired transport 163.
  • the content delivery system 100 provides for upstream communications from one or more of the receivers 104 to the head end system 102.
  • upstream communications i.e. communications originating from a receiver 104 which are sent to the head end system 102
  • downstream communications are communications originating from the head end system 102 which are sent to one or more receiver 104.
  • upstream communications may operate on the same transport medium 197 and/or transport protocol as the downstream communications (downstream communications are communications originating from the head end system 102 which are sent to one or more receiver 104).
  • upstream communications i.e. communications originating from a receiver 104 which are sent to the head end system 102
  • downstream communications are communications originating from the head end system 102 which are sent to one or more receiver 104.
  • the receiver 104 may be configured to send upstream communications over a different transport medium than the transport medium from which downstream communications are received.
  • the head end system 102 and the receivers 104 used in the content delivery systems 100 described above provide for downstream communications from the head end system 102 to the receivers 104.
  • the head end system 102 and the receivers 104 are also configured to provide upstream communications from the receivers 104 to the head end system 102. Such upstream communications may permit the receivers 104 to communicate with the head end system 102.
  • Such upstream communications may, for example, be useful to provide on-demand services to a receiver 104, such as video on-demand services (which may be used to deliver specific video content on request), audio on-demand services (which may be used to deliver specific audio content on request) or application on-demand services (which may be used to deliver specific applications on request) to a receiver 104.
  • video on-demand services which may be used to deliver specific video content on request
  • audio on-demand services which may be used to deliver specific audio content on request
  • application on-demand services which may be used to deliver specific applications on request
  • the content delivery system 101 of FIG. 2 illustrates a satellite television system 154.
  • the content delivery system 101 of FIG. 2 includes a head end system 102 which is connected to a plurality of receivers 104 via a transport medium 197.
  • the head end system 102 and the receivers 104 may be of the types described above with respect to the content delivery system 100 of FIG. 1.
  • the head end system 102 may be configured to deliver content to receivers 104 operating within the broadcast domain 195 via a satellite transport 155.
  • the satellite transport 155 may include a satellite uplink 156 connected to the head end system 102.
  • the satellite uplink 156 (which may include a satellite dish) transmits data (including content) to a satellite 157 placed in orbit around the earth.
  • the satellite 157 then transmits content to a receiver 104 through a satellite downlink 158 (which may include a satellite dish) connected to the receiver 104.
  • the satellite television system 154 may also allow for upstream communications from one or more receivers 104 to the head end system 102.
  • communications originating from a receiver 104 may be sent to the head end system 102 through the satellite transport 155.
  • upstream communications may operate on a different transport medium and/or transport protocol as the downstream communications (i.e. communications originating from the head end system 102 which are sent to one or more receiver 104).
  • the satellite downlink 158 may capable of receiving data from the satellite 157 but may not be capable of sending data to the satellite 157.
  • upstream communications from the receiver 104 to the head end system 102 may be provided through an alternative transport medium such as a wired transport medium 159.
  • the wired transport medium 159 used for upstream communications in the satellite television system 154 comprises twisted pair wiring.
  • the wired transport medium 159 used for upstream communications may be a transport medium over which packet based communications may be transmitted.
  • the wired transport medium 159 may be any transport medium providing a connection to the Internet.
  • the receiver 104 and/or the head end system 102 of a content delivery system 100 (FIG. 1), 101 (FIG. 2) may be configured to communicate with one another over a wired transport medium which may include, for example, a coaxial transport medium, an optical transport medium (such as fibre optic cable), a twisted pair transport medium such as telephone cable (including, for example, a category 1 cable (Cat 1)) or an Ethernet cable (including, for example, a category 5 cable (Cat 5) or category 6 cable (Cat 6)) which may connect to the head end system 102 through a network, such as the I nternet.
  • the receiver 104 and/or the head end system 102 may be configured to communicate with one another over a wireless transport medium such as a radio frequency transport medium (including satellite based communications and/or WiFi).
  • the content delivery system 100 (FIG. 1), 101 (FIG. 2) includes a head end system 102.
  • the head end system 102 is configured to gather content (such as programming sources including source broadcast streams), decode, select and/or retransmit such content (such as video programming) to a distribution network, which includes one or more receivers 104.
  • the content which is delivered to the head-end-system 102 may include, for example, broadcast or multicast content (such as broadcast video) and on-demand content (such as pay-per-view content, including movies, special events, and other on-demand content).
  • the broadcast or multicast content which is delivered to the head end system 102 for broadcasting and/or multicasting live to receivers may be referred to as source broadcast streams.
  • the head end system 102 may include or connect to a content acquisition system 115.
  • the content acquisition system 115 of FIG. 3 is illustrated as a plurality of satellite dishes. Such satellite dishes may be configured to receive content from one or more satellites.
  • the content acquisition system 115 may be configured to receive content through other means instead of, or in addition to, the satellite dishes.
  • the content acquisition system 115 may include one or more antennas which receive radio frequency signals, such as signals transmitted through a terrestrial based network.
  • the content acquisition system 115 may be configured to receive content through a network, such as the Internet.
  • the content acquisition system 115 may be configured to receive content though a wired transport medium such as, for example, a cable.
  • the cable may, in some example embodiments, include a coaxial cable and/or a fibre optic cable.
  • the content received through the content acquisition system 115 may include, for example, broadcast content which may be received in streaming fashion from one or more television networks. Such content may be referred to as source broadcast streams.
  • the head end system 102 includes a content management system 117 which is configured to manage content received at the head end system 102 and/or deliver content to one or more receivers 104.
  • the content management system 117 may, in various embodiments, be configured to perform any one or more of the following tasks: gather content (such as programming sources) received from the content acquisition system 115, decode such content, select content for retransmission, encrypt content for transmission to the receivers, store content in the content store and/or transmit content to the receivers.
  • I n order to prevent unauthorized access to content (such as source broadcast streams), such content may be scrambled or otherwise encrypted.
  • the head end system 102 may receive scrambled and/or encrypted content (such as encrypted source broadcast streams). Such encrypted and/or scrambled content may, for example, be received at the content acquisition system 115.
  • the head-end system 102 may be configured to decrypt or decode such content.
  • the content management system 117 of the head end system 102 may be configured to perform such decryption and/or decoding.
  • the head end system 102 includes a content store 120 for storing content on the head end system 102.
  • the content store 120 may be comprised of computer based storage and may also be referred to as memory.
  • the memory includes non-volatile memory, such as flash memory.
  • the memory includes a solid state drive (SSD) and/or a magnetic storage, such as a hard disk drive (HDD). Other types of memory may be included in the storage instead of or in addition to those listed above.
  • the content management system 117 is configured to store at least some received content in the content store 120.
  • the content which is stored in the content store 120 may, for example, include on-demand content, such as video on-demand content.
  • Video on-demand content is video content which may be sent to a receiver 104 upon request from that receiver 104. That is, video on-demand is a service which allows viewers (i.e. subscribers) to receive and play video at their convenience. That is, video is delivered to a subscriber's receiver in response to a request being received from the subscriber. Such a request may be received via upstream communications from the receiver 104 to the head end system 102.
  • the content which is stored in the content store 120 may include other on- demand content such as, for example, audio on-demand content and/or application on- demand content.
  • Audio on-demand content may include audio files, such as music files, which may be delivered to a receiver 104 upon request from that receiver 104.
  • application on-demand content may include applications, such as games, utilities, etc., which may be delivered to a receiver 104 upon request from that receiver 104.
  • the head end system 102 may transmit content, such as video to subscribers over a network. In at least some embodiments, prior to such transmissions, the headend system 102 may encrypt the signal using its own encryption algorithm in order to prevent unauthorized access to the signal, such as eavesdropping and theft of service.
  • the content management system 117 of the head end system 102 may include subsystems and modules which are configured to perform or facilitate such transmission, formatting, modulation and/or encryption of content.
  • the content management system 117 of the head end system 102 may be configured to utilize digital technology to deliver digital content, such as video signals.
  • Digital video signals are signals which use digital video compression.
  • the content management system 117 may be configured to encode and transmit video signals according to a Quadrature Amplitude Modulation (QAM) format.
  • QAM is a modulation format which does not specify the format of the digital data being carried.
  • the format of the data being carried may, in at least some example embodiments, be based on an Advanced Television Systems Committee (ATSC) standard.
  • ATSC Advanced Television Systems Committee
  • the content management system 117 may be configured to use a Digital Video Broadcasting (DVB) based data format, such as Digital Video Broadcasting - Cable (DVB-C), to format the data being carried (such as video signals).
  • DVD Digital Video Broadcasting
  • the head-end system 102 may be configured to transmit data formatted according to a Motion Pictures Experts Group (MPEG) standard, such as an MPEG-2 or MPEG-4 digital audio/digital video stream.
  • MPEG Motion Pictures Experts Group
  • the content management system 117 may be configured to use QAM modulation on such data.
  • DVD-C2 Digital Video Broadcasting - Cable
  • the head end system 102 includes an on- demand server, such as a video on-demand (VOD) server 112.
  • the on-demand server may, in at least some example embodiments, be included in the content management system 117 of the head end system 102.
  • the on-demand server, such as the VOD server 112 may be configured to receive a request from a receiver 104 (i.e. via upstream communications from the receiver 104) to deliver content such as, for example, movies and other video, to the receiver 104.
  • the request includes unique identification information which allows the VOD server 112 to determine which content is associated with the request.
  • the VOD server 112 may retrieve the specified content from the content store 120 and deliver such content to the receiver 104. Since the VOD server 112 delivers the requested content only to the receiver 104 which requested it, the VOD server 112 may be referred to as a unicast server in at least some embodiments.
  • the head end system 102 includes other content servers instead of or in addition to the on-demand server described above.
  • the head end system 102 may include a multicast content server 110.
  • the multicast content server 110 is included within the content management system 117.
  • the multicast content server 110 may be configured to deliver content to two or more receivers 104. That is, the multicast content server 110 is configured to multicast or to broadcast content to two or more receivers 104. In at least some embodiments, the multicast content server 110 may be configured to broadcast content. I n such embodiments, the multicast content server 100 may also be referred to as a broadcast content server.
  • the multicast content server 110 may deliver broadcast content from the head end server 102 to a plurality of receivers 104 in the broadcast domain 195.
  • the content which is delivered by the multicast content server 110 may, in at least some embodiments, differ from the content which is delivered by the VOD server 112 in that content which is delivered from the multicast content server 110 may not be configured to start from the beginning of the content. That is, the multicast content server 110 may sim ply allow a subscriber to tap into (e.g. begin viewing) an ongoing content stream.
  • the multicast content server 110 receives source broadcast streams (i.e. via the content acquisition system 115) and multicasts or broadcasts such streams to receivers in real time or near real time.
  • the multicast content server 110 is used to deliver broadcast content while the VOD server 112 is used to deliver on-demand content.
  • the multicast content server 110 may be configured to deliver content to the receivers 104 using one or more transmission channels.
  • Each transmission channel may represent a specific range of frequencies.
  • the transmission channel may not, in all embodiments, be the same as a displayed channel. That is, receivers 104 may be configured to display a channel number as a displayed channel or virtual channel which does not necessarily represent the transmission channel associated with the displayed channel or virtual channel.
  • the head end system 102 and/or the receiver 104 may include a channel map 191 which associates displayed channels (e.g. virtual channels) with corresponding transmission channels (e.g. ranges of frequencies).
  • the channel map 191 may map the channel numbers which are displayed to a user in a user interface of the receiver 104 with transmission channels. As will be explained in greater detail below, in at least some embodiments, the channel map 191 may not have a one-to-one mapping of displayed channels (i.e. virtual channels) to transmission channels. More particularly, in at least some example embodiments, a transmission channel may be associated with and mapped to more than one displayed channel.
  • the head-end system 102 includes an interactive programming guide (IPG) server 114.
  • the IPG server 114 is configured to process metadata associated with content.
  • the metadata may be associated with on- demand content (such as the content which may be delivered by the VOD server 112) and/or broadcast/multicast content (such as the content which may be delivered by the multicast content server 110).
  • the metadata may, for example, be stored in a programming data store 130.
  • the programming data store 130 may include programming data such as the metadata associated with content and scheduling information.
  • the scheduling information associates at least one virtual channel with content and/or with metadata for that content.
  • the scheduling information may also include time and date information specifying the time and/or date when content will be available for broadcast/multicast.
  • the metadata associated with broadcast or multicast content may be referred to as broadcast metadata.
  • the I PG server 114 may be configured to retrieve at least some of the metadata from a metadata service provider and store such metadata in the programming data store 130 of the head end system 102.
  • the I PG server 114 may be configured to provide programming data to receivers 104. Such programming data may include, for example, the scheduling information and metadata.
  • the IPG server 114 may provide programming data regarding broadcast content (such as content available through the multicast content server 110) and may also be configured to provide programming data regarding on- demand content (such as content available through the VOD server 112) which is available for download to the receivers.
  • the IPG server 114 may be configured to provide to receivers 104 information regarding on-demand content stored in the content store 120. Such information may be referred to as on-demand content metadata. Metadata associated with broadcast content may be referred to as broadcast metadata.
  • the on-demand content metadata and the broadcast metadata may, for example, include a description of content associated with the metadata including, for example, a title, summary, viewing time, and/or price associated with the metadata.
  • the metadata may include other information instead of or in addition to the information specified above.
  • the head end system 102 may include one or more communication subsystems (not shown) which are configured to control communications between the head end system 102 and the receivers 104.
  • the specific design of the communication subsystems will depend on the transport mediums or transport protocols which are used for communications between the head end system 102 and the receivers 104.
  • the head end system 102 may be configured to control the allocation of fixed resources, such as bandwidth in the content delivery system 100 (FIG. 1), 101 (FIG. 2).
  • the head end system 102 may include one or more bandwidth management systems 116, 118 which are configured to manage bandwidth in the content delivery system 100 (FIG. 1), 101 (FIG. 2).
  • the VOD server 112 includes a VOD bandwidth management system 118 which is configured to manage bandwidth related to the delivery of on-demand content, such as video on-demand.
  • the multicast content server 110 includes a multicast bandwidth management system 116 which is configured to manage bandwidth related to the delivery of multicast/broadcast content.
  • multicast bandwidth management system 116 and the VOD bandwidth management system 118 are illustrated as separate features in the block diagram of FIG. 1, in various embodiments, these management systems 116, 118 may be combined together into a single bandwidth management system and/or incorporated into other features or systems of the head end system 102.
  • the multicast bandwidth management system 116 may, in some example embodiments, be a switched digital video (SDV) system.
  • SDV is a system in which channels are only transmitted if they are needed. That is, if no receivers 104 are tuned into a virtual channel, then the content associated with that virtual channel is not transmitted. Instead, content will only be transmitted if a receiver 104 requests the content.
  • a bandwidth management system 116, 118 may be configured to locate duplicate content which is being transmitted or which is scheduled for transmission or requested for transmission through more than one transmission channel at a related time. Efficiencies may then be realized to reduce the amount of bandwidth required to transmit such redundant content.
  • the multicast bandwidth management system 116 is configured to located redundancies in broadcast content.
  • two television channels associated with two distinct sources such as two networks or two regional stations associated with the same network
  • advertising/commercial content associated with the program may differ
  • the primary content i.e. the show itself
  • Such redundancies may exist, for example, when the content delivery system 100 includes a plurality of regional channels.
  • the content delivery system 100 may provide access to two or more television feeds associated with the same television network but with different regional stations.
  • the content delivery system 100 may provide access to two ABCTM feeds, each associated with a different region (e.g. one may be associated with Detroit and one may be associated with Buffalo). At least some of the content which is scheduled to air on both of these feeds may be the same at various times.
  • redundancies may exist where the content delivery system 100 provides access to source broadcast streams for networks associated with two different countries.
  • Canadian subscription based television systems such as cable television systems
  • U nited States television networks may be provided. In some instances, this may result in a situation where two networks associated with two different countries are broadcasting the same content at the same time.
  • the multicast ba ndwidth management system 116 is configured to identify at least some such redundancies and to remove some of the content from being transmitted. That is, the multicast bandwidth management system 116 may select one of the redundant streams of content to be of higher priority than another one of the redundant streams of content and may not transmit the lower priority redundant stream during the time when the redundancy exists. Instead, the multicast bandwidth management system 116 may allow receivers 104 which are requesting the content associated with the lower priority content stream to, instead, access the higher priority content stream.
  • the receivers 104 may be configured to appear to operate as though the redundant stream is still received.
  • the redundant content may be associated with multiple virtual channels.
  • an interactive program guide (IPG) subsystem 188 (FIG. 4) may separately display multiple virtual channels associated the redundant content.
  • multiple channel numbers may be input into the receiver 104 to access the same content stream. This permits a user of the receiver 104 to request the content which was removed from transmission. When this happens, however, the user is provided with the other content, which was not removed from transmission (i.e. the higher priority content stream)
  • a VOD bandwidth management system 118 may be used to realize bandwidth efficiencies in the transmission of on- demand content.
  • On-demand content is often unicast from the head end system 102 to the receiver 104 which requested it.
  • one or more of the prior unicasts of the content to those other receivers may be converted into a multicast of the content to two or more receivers which requested the same content. The receiver which recently requested the content will also be permitted to access the multicast.
  • any receiver which requires earlier portions of the content may store the multicast portion of the content in a local content store 189 until it is needed (i.e. until playback of the content reaches the point which is included in the multicast portion of the content).
  • the head end system 102 may unicast the portions of the content which preceded the multicast to any receivers which require this portion of the content. Such receivers may initially begin playback of the unicast content and may switch to the stored multicast content when playback reaches that portion of the content.
  • bandwidth management systems 116, 118 may also be referred to as resource management systems.
  • bandwidth management system 116, 118 will be discussed in greater detail below with reference to FIGs. 5 to 8.
  • the head end system 102 may not be physically or logically divided in the manner illustrated in FIG. 3. I n at least some em bodiments, components of the head end system 102 may be physically or logically separated from one another. In at least some embodiments, the head end system 102 may be physically separated and may, for example, include a super head end system and one or more regional or local head end systems. The super head end system and/or the regional or local head end systems may separately or collectively perform some of the functions described above with reference to FIG. 3.
  • the head end system 102 may be a modular solution in which various functions or features described herein are provided by various modules. Such modules may, for example, be rack mounted electrical devices and may interconnect with one another to collectively provide functions and features described herein.
  • one or more of the modules, features, systems or subsystems described herein may contain one or more processors and a memory having computer readable instructions stored thereon. The computer readable instructions may be executable by the processors and may cause the processors to provide functions described herein.
  • the example receiver 104 may be configured to receive content from the head end system 102 of FIG. 3.
  • Receivers 104 operating within the broadcast domain 195 may include features, systems and subsystems which interact with at least some of the features, systems and/or to subsystems of the head end system 102.
  • a receiver 104 include an interactive programming guide (IPG) subsystem 188.
  • the IPG subsystem 188 is configured to receive programming data from the IPG server 114 (FIG. 3).
  • the IPG subsystem 188 may display programming data on the media player 194 associated with the receiver 104 (such as a television).
  • the IPG subsystem 188 may allow a user of the receiver to interact with the IPG subsystem 188 through an input mechanism (such as a remote control) associated with the receiver 104.
  • the I PG subsystem 188 may be configured to display programming data (such as a schedule and metadata) for content which is available from the multicast content server 110 and/or display information (such as metadata) regarding on-demand content which is available from the VOD server 112.
  • the receiver 104 may also include a content delivery subsystem 182.
  • the content delivery subsystem 182 is configured to receive content from the head end system 102 via the transport medium 197 and to display received content on a media player 194 which is coupled to the content delivery subsystem 182.
  • the content delivery subsystem 182 may be configured to perform a plurality of content related tasks including, for example, decrypting received content, reformatting such content, displaying such content on the media player 194.
  • the media player 194 may be a television or other display.
  • the content delivery subsystem 182 may be configured to handle broadcast content and may also be configured to handle on-demand content.
  • the content delivery subsystem 182 may include a video on-demand (VOD) subsystem 186 which is configured to handle on-demand video content.
  • the Video on-demand (VOD) subsystem 186 allows a user to select content for presentation on-demand.
  • the VOD subsystem 186 allows a user to initiate a sending of content from the head end system 102 to the receiver 104 for display on a display associated with the receiver, such as a television. More particularly, the VOD subsystem 186 may be configured to receive a request for specific on-demand content to be delivered to the receiver 104.
  • the request may be received through an input mechanism (such as a remote control) associated with the receiver 104.
  • an input mechanism such as a remote control
  • a user of the receiver 104 may interact with a user interface of the receiver 104 using the input mechanism and may send a command to the receiver 104 via the input mechanism instructing the receiver to request the on-demand content from the head end system 102.
  • the VOD subsystem 186 may send a request for the specified content to the VOD server 112 of the head end system 102.
  • the VOD server 112 may retrieve the specified content and may send the specified content to the receiver 104 from which the request originated.
  • the VOD server 112 of the head end system 102 unicasts the on-demand content to the receiver 104.
  • the VOD server 112 may perform other functions, such as, for example, posting a VOD charge to an account associated with the subscriber who the receiver is associated with.
  • the receiver 104 then receives the selected content and may decrypt the received content and output the received content to the media player 194. That is, the content delivery subsystem 182 is configured to display the content on the media player 194 associated with the receiver 104.
  • the content delivery subsystem 182 may also include a multicast subsystem 184 which is configured to handle multicast content. More particularly, the multicast subsystem 184 may be configured to receive and process broadcast or multicast content which is sent from the head end system 102. The multicast subsystem 184 may be configured to decrypt received multicast content and to output the received content to the media player 194 (which may be a television). That is, the multicast subsystem 184 may be configured to display received multicast content on the media player 194 associated with the receiver 104. [0076] The multicast subsystem 184 may be configured to tune into broadcast content at the request of a user of the receiver 104.
  • a user may input a command to the receiver 104 using an input mechanism (such as a remote control) associated with the receiver 104 to instruct the receiver 104 to tune into specified content.
  • the receiver 104 may receive a command instructing the receiver 104 to tune to a specified virtual channel.
  • the multicast subsystem 184 may tune into the content associated with the command.
  • the multicast subsystem 184 may include a tuner 187.
  • the tuner 187 may be associated with channel map data 191 which may be stored in a data store of the receiver 104.
  • the channel map data 191 may map a virtual channel (i.e. the channel number displayed to a user in a user interface of the receiver 104) to a transmission channel (i.e.
  • At least some receivers may include or be associated with a user input mechanism such as a remote control.
  • the input mechanism may permit users to input commands to the receiver 104.
  • the input mechanism may permit users to interact with a user interface of the receiver 104.
  • users may, for example, use the input mechanism to navigate the interactive program guide provided by the I PG subsystem 188.
  • the input mechanism may allow users to input instructions to the receiver 104 to cause the receiver to receive specific content (i.e. by tuning to broadcast content using the tuner 187 or by sending an upstream request to the head end system 102 for on-demand content).
  • the input mechanism may be useful for inputting additional commands to the receiver 104 which are not specifically discussed herein.
  • the receiver 104 may be associated with a content store 189.
  • the content store 189 may be provided in a memory which may be internal or external to the receiver 104.
  • the content store 189 may be used for storing content, or parts thereof.
  • the content store 189 may be used to store on-demand content which is being sent by the head end system 102 to another subscriber in the broadcast domain 195.
  • the head end system 102 may stop unicasting the content to the first receiver 104 and may begin multicasting the content to both the first receiver and the second receiver 104. Since the second receiver requested the content at a time which was later than the first receiver, the second receiver may not be ready to display the multicasted content at the time it is received since the second receiver must first display the portion of the content which was transmitted to the first receiver before the second receiver requested the content. Accordingly, the second receiver may store the content in the content store 189 for further playback.
  • the content store 189 may also be used, in at least some embodiments (not shown), by a digital video recorder (DVR) subsystem included in the receiver 104.
  • the digital video recorder (DVR) subsystem may be configured to record received content. That is, the DVR subsystem may be configured to store received content in the content store 189 in response to a recording request received from a user via an input mechanism associated with the receiver 104.
  • the receiver 104 may include one or more communication subsystems (not shown) which are configured to control communications between the head end system 102 and the receivers 104. The specific design of the communication subsystems will depend on the transport mediums or transport protocols which are used for communications between the head end system 102 and the receivers 104.
  • any of the features of any of the subsystems included in the receiver 104 may be provided by other systems of the receiver 104 and any one or more of these features may be provided by other systems or subsystems of the receiver 104 not specifically discussed herein. More particularly, components, features or subsystems of the receiver 104 may not be physically or logically divided in the manner illustrated in FIG. 4.
  • FIG. 5 an example embodiment of a method 500 for managing bandwidth in accordance with example embodiments of the present disclosure is illustrated in flowchart form.
  • One or more application or module stored in memory of the head end system 102 may be configured to perform the method 500 of FIG. 5.
  • a bandwidth management system 116, 118 (FIG. 3) may be configured to perform the method 500 of FIG. 5.
  • one or more application or module in the head end system 102 and/or the bandwidth management system 116, 118 may contain computer readable instructions which cause a processor of the head end system 102 and/or a processor of the bandwidth management system 116, 118 to perform the method 500.
  • content items are related to a requested or planned transmission of content.
  • content items may, in some embodiments, comprise programming data for broadcast streams (such as scheduling data and metadata).
  • the bandwidth management system 116, 118 may use such programming data in order to determine whether there are any redundancies in the schedule. That is, bandwidth management system 116, 118 may determine whether there are any instances where there are two or more source broadcast streams received at a content acquisition system 115 of the head end system 102 which are both scheduled to deliver the same content at the same time.
  • a bandwidth management system 116, 118 may be configured to eliminate or reduce redundancies associated with the transmission of on-demand content.
  • content items may comprise requests for on-demand content which are received from two or more receivers 104 operating in the broadcast domain 195 (FIGs. 1 & 2).
  • the bandwidth management system 116, 118 attempts to identify instances where the same content has been requested by multiple receivers 104. Where a later request for content from a receiver 104 is received at the head end system 102 while the same content is being transmitted to a receiver 104 from which an earlier request for the same content was received, then a redundancy is identified.
  • both receivers i.e. the receiver which issued the earlier request and the receiver which issued the later request
  • a redundancy may be identified. Both receivers require the portion of the content being sent to the receiver which issued the earlier request.
  • content items associated with such redundancies may be identified.
  • a relative priority of at least some of the identified content items is determined. More particularly, at least one of the content items is selected as a higher priority content item.
  • a receiver requesting the content associated with a lower priority content item is allowed to access a multicast associated with a higher priority content item.
  • the content items represent programming data associated with source video feeds
  • a lower priority video feed may be eliminated from transmission. Instead, when a receiver would like to access the lower priority video feed, it may be forced to access the higher priority video feed.
  • a request for content which is received later than another request for the same content may be said to be a lower priority request than the earlier request.
  • the receiver 104 issuing the later request for the same content may be permitted to access a multicast of the content which is also being provided to the receiver issuing the earlier request.
  • the multicast bandwidth management system 116 is configured to located redundancies in broadcast content. For example, two television channels associated with two distinct source feeds (such as two networks or two regional stations associated with the same network) may be scheduled to air the same program at the same time. While in some cases advertising content (i.e. commercials) associated with the program may differ, in at least some cases, the primary content (i.e. the show itself) may be the same. [0092] Such redundancies may exist, for example, when the content delivery system 100 includes regional channels. For example, the content delivery system 100 may provide access to two or more television feeds associated with the same television network but with different regional stations.
  • the content delivery system 100 may provide access to two ABCTM feeds, each associated with a different region (e.g. one may be associated with Detroit and one may be associated with Buffalo). At least some of the content which is scheduled to air on both of these feeds may be the same at various times.
  • redundancies may exist where the content delivery system 100 provides access to television feeds for networks associated with two different countries.
  • Canadian subscription based television systems (such as cable television systems) may provide access to both Canadian television networks and U nited States television networks, both of which may broadcast the same primary content at the same time.
  • FIG. 6 an example embodiment of a method 600 for managing bandwidth in a multicast/broadcast system is illustrated in flowchart form. The method 600 of FIG. 6 may be used in order to eliminate or reduce at least some redundancies.
  • One or more application or module stored in memory of the head end system 102 may be configured to perform the method 600 of FIG. 6.
  • a bandwidth management system 116, 118 (FIG. 3) may be configured to perform the method 600 of FIG. 6. More particularly, one or more application or module in the head end system 102 and/or the bandwidth management system 116, 118 may contain computer readable instructions which cause a processor of the head end system 102 and/or a processor of the bandwidth management system 116, 118 to perform the method 600.
  • a multicast bandwidth management system 116 may be configured to perform the method 600 of FIG. 6.
  • two or more content items associated with common content and which are temporally related are identified.
  • this comprises identifying two or more broadcast streams in which at least some common content is scheduled for broadcast at a common start time. That is, the temporal relationship may require that the content items be associated with the same start time.
  • the common content may be a common television show, movie, sporting event, etc.
  • I n at least some em bodiments, such redundancies may be identified by parsing programming data associated with the broadcast streams.
  • the programming data includes metadata and may also include scheduling data.
  • the metadata for content associated with programming time slots may be parsed in order to identify instances where the same content is scheduled for broadcast on different source broadcast streams at the same start time.
  • the start time is the time when the content is scheduled to begin to be broadcast on the source broadcast stream.
  • Source broadcast streams are the broadcast feeds which are received at the head end system 102 (for example, via the content acquisition system 115).
  • the metadata may be parsed to identify feeds with common metadata.
  • any one or more of the following may be interpreted as indicia that the content being broadcast on different content feeds is the same: common program names, common episode names and/or episode numbers, and/or common or similar show descriptions. Other indicia may also be possible.
  • whether content associated with two or more broadcast streams will be said to be redundant will depend, at least in part, on a content-type associated with the content.
  • the bandwidth management system 116, 118 may be configured to ignore any news related content in step 502. Since news programming often varies from jurisdiction to jurisdiction, it may be erroneous to conclude that two instances of source broadcast streams which are scheduled to carry "News" are redundant.
  • Other content-types or features associated with content may also be used to exclude such content from being found to be redundant. That is, the bandwidth management system 116, 118 may be configured to exclude at least some content items (i.e. programming data) from being identified as being associated with redundant content (i.e. content which is scheduled to be broadcast on more than one broadcast stream at the same time) based on one or more exclusionary rules.
  • a relative priority of at least some of the content items associated with the redundant scheduled broadcast is determined. This may include, at 604, determining a relative priority based on prioritization data and/or quality.
  • Prioritization data is data which specifies one or more prioritization rules to follow when such redundancies are located. That is, the prioritization data specifies the relative priorities of two or more broadcast streams (including the source broadcast streams associated with the redundancy identified at 602). In at least some embodiments, the prioritization data specifies one or more broadcast streams which are to be preferred over one or more other broadcast streams.
  • the prioritization data may be signal substitution data.
  • Signal substitution data specifies that content items associated with one or more local broadcast streams are to be prioritized higher than content items associated with one or more foreign broadcast streams.
  • Signal substitution data may be used, for example, where the content delivery system 100 provides access to television feeds for networks associated with two different countries. For example, Canadian subscription based television systems (such as cable television systems) may provide access to both Canadian television networks and United States television networks.
  • Signal substitution data may specify that, when the same content is scheduled for broadcast on both a foreign broadcast stream and a domestic broadcast stream, then the content items associated with the domestic broadcast stream may be granted a higher priority than the content items associated with a foreign broadcast stream.
  • the relative priorities of the content items associated with the redundancy may be determined based on the signal quality of the source broadcast streams associated with these content items.
  • the signal quality may be measured by a signal quality sensor provided in the head end system 102.
  • a content item associated with a source broadcast stream having a higher signal quality may be granted a higher priority than a content item associated with a source broadcast stream having a lower relative signal quality.
  • a combination of these prioritization techniques may be employed at 604. For example, if the prioritization data specifies one or more rules, then these prioritization rules may be followed. However, where no such rules are specified, then the prioritization may be performed in accordance with the signal quality.
  • the bandwidth management system 116, 118 allows a receiver requesting content associated with a lower priority content item to access a multicast associated with the higher priority content item.
  • the multicast may be a broadcast.
  • this may include, at 606, mapping a virtual channel associated with a higher priority content item and a virtual channel associated with a lower priority content item to a common transmission channel during the time when the two or more content items are associated with at least some common content. That is, during the period of time when the broadcast streams were scheduled to include the same content, the broadcast stream which has been prioritized lower than the other broadcast stream (i.e. the broadcast stream which is associated with the lower priority content item) will be removed from being transmitted in the broadcast domain 195 (FIGs 1 and 2).
  • the multicast bandwidth management system 116 may select one of the redundant streams of content to be of higher priority than another one of the redundant streams of content and may not transmit the lower priority redundant stream during the time when the redundancy exists.
  • the bandwidth management system 116, 118 may be configured to allow receivers 104 which are requesting the content associated with the lower priority content stream to, instead, access the higher priority content stream.
  • the receivers 104 may be configured to appear to operate as though the redundant stream is still received.
  • the redundant content may be associated with multiple virtual channels.
  • an interactive program guide (IPG) subsystem 188 may separately display multiple virtual channels associated the redundant content.
  • IPG interactive program guide
  • a user of the receiver 104 may be unable to determine that one of the broadcast streams is no longer available.
  • the same content stream will be provided to the receiver 104. That is, in either case, the user will be directed to the same transmission channel.
  • the head end system 102 may provide a channel map 191 (FIG. 4) to the receiver 104.
  • the channel map 191 may map a virtual channel (e.g. the channel which is displayed to a user of the receiver) to a transmission channel (e.g. the frequency or range of frequencies used to transfer content associated with that virtual channel).
  • a transmission channel e.g. the frequency or range of frequencies used to transfer content associated with that virtual channel.
  • the channel map 191 may be a scheduled channel map. That is, the mapping of virtual channels to transmission channels may be time dependent and may vary over time. For example, when the redundancy on two broadcast streams ceases, each broadcast stream may again be granted a separate transmission channel and the channel map may then specify that the virtual channels associated with these items are again associated with different transmission channels.
  • the bandwidth management system 116 may operate within or in conjunction with a switched digital video (SDV) system.
  • SDV is a system in which channels are only transmitted if they are needed. That is, if no receivers 104 are tuned into a channel, then the content associated with that channel is not transmitted. I nstead, content will only be transmitted if a receiver 104 requests the content. Accordingly, in an SDV system when a user requests broadcast content on a receiver 104 (e.g. by tuning into a virtual channel), the receiver typically sends a signal to the head end system 102. If the broadcast stream associated with the request was not previously being transmitted (i.e.
  • the SDV system operating in the head end system 102 will activate that broadcast stream. That is, the SDV system will begin to transmit that broadcast stream in an available transmission channel. The SDV system may then inform the receiver 104 which requested the content of the transmission channel where that content is now located.
  • FIG. 7 at example embodiment of a further method 700 for managing bandwidth in a multicast/broadcast system is illustrated in flowchart form.
  • the method 700 of FIG. 7 may be used in order to eliminate or reduce at least some redundancies.
  • the method 700 of FIG. 7 may be provided within or used with an SDV system.
  • the method 700 of FIG.7 includes many features 502, 602, 504, 604 discussed above with reference to FIG. 6.
  • One or more application or module stored in memory of the head end system 102 may be configured to perform the method 700 of FIG. 7.
  • a bandwidth management system 116, 118 (FIG. 3) may be configured to perform the method 700 of FIG. 7. More particularly, one or more application or module in the head end system 102 and/or the bandwidth management system 116, 118 may contain computer readable instructions which cause a processor of the head end system 102 and/or a processor of the bandwidth management system 116, 118 to perform the method 600.
  • a multicast bandwidth management system 116 may be configured to perform the method 700 of FIG. 7.
  • a switched digital video (SDV) system may be configured to perform the method 700 of FIG. 7.
  • a request is received at the SDV system/bandwidth management system 116, 118 (at 702).
  • the request is received from a receiver 104 operating in the broadcast domain 195 (FIG. 1 and 2).
  • the request is a request to provide content associated with a lower priority content item. That is, the request is a request which is associated with the content removed from broadcast.
  • the SDV system/bandwidth management system 116, 118 provides content associated with the higher priority content item to the receiver 104.
  • the SDV system/bandwidth management system informs the receiver of the transmission channel where the content associated with the higher priority content item is being transmitted. That is, the SDV system/bandwidth management system 116, 118 instructs the receiver to tune into a frequency associated with the transmission channel used for transmitting the content associated with the higher priority content item. If this content was not previously being transmitted, the SDV system/bandwidth management system 116, 118 may first begin the transmission on an available transmission channel.
  • a VOD bandwidth management system 118 may be used to realize bandwidth efficiencies in the tra nsmission of on-demand content.
  • Redundancies may exist in the delivery of on-demand content where two receivers require common content or a common portion thereof.
  • On-demand content is often unicast from the head end system 102 to the receiver 104 which requested it. That is, in some systems, in response to each request for on-demand content which is received from a receiver 104, a head end system 102 will begin a separate unicast of the content to the receiver 104 which requested it.
  • a redundancy exists where one receiver requests content while another receiver is receiving the same content via unicast.
  • a bandwidth savings may be achieved by converting the unicast to the first receiver into a multicast to both receivers. That is, the fact that those requests relate to the same content and the fact that the second request was received while the content was still being sent to the first receiver results in a redundancy if the content is unicast in its entirety to both the first receiver and the second receiver. Since both receivers require the portion of the content which is yet to be delivered to the first receiver, this content may be multicast to both receivers and stored in local storage on the second receiver until it is needed.
  • FIG. 8 illustrates, in flowchart form, an example embodiment of a method 800 for managing bandwidth in an on-demand system.
  • One or more application or module stored in memory of the head end system 102 may be configured to perform the method 800 of FIG. 8.
  • a bandwidth management system 116, 118 (FIG. 3) may be configured to perform the method 800 of FIG. 8.
  • one or more application or module in the head end system 102 and/or the bandwidth management system 116, 118 may contain computer readable instructions which cause a processor of the head end system 102 and/or a processor of the bandwidth management system 116, 118 to perform the method 800.
  • an on-demand bandwidth management system 118 may be configured to perform the method 800 of FIG. 8. [00120] First, at 802, a request for on-demand content may be received at the head end system 102 from a receiver 104.
  • the content items comprise requests for content received from two or more receivers 104. These requests include the recent request received at 802.
  • the bandwidth management system 116, 118 determines whether the recent request (i.e. the request received at 802) is related to the same content as a prior request for on-demand content. That is, the bandwidth management system 116, 118 determines whether the receivers have requested the same content. The bandwidth management system 116, 118 also determines whether the recent request is timely in relation to the prior request for the same on-demand content.
  • the content will be considered to be timely and temporally related to the earlier request. That is, in at least some embodiments, two or more content items are determined to be associated with at least some common content and temporally related if a request for content is received from a receiver during the transmission of the same content to another receiver. In other embodiments, a further requirement may be required before a request may be said to be timely and temporally related to the earlier request. For example, in some embodiments, in order to be considered timely, the portion of the content which remains to be transmitted in relation to the earlier request must exceed a threshold.
  • the threshold may be a predetermined threshold and may be specified in terms of a time duration. For example, in order to be considered timely and temporally related to an earlier request, a later request must be received while the portion of the content which has not yet been transmitted to the receiver in relation to the earlier request is greater than a predetermined period of time (such as a predetermined number of minutes).
  • the requested content may be unicast to the receiver from which the later request was received (i.e. the receiver which sent the request received at 802).
  • a relative priority of at least some of the content items may be determined by the bandwidth management system 116, 118. That is, the requests may be prioritized.
  • the earlier request which is related to the same content as the later request is assigned a higher priority tha n a later request (at 806).
  • the bandwidth management system 116, 118 selects the request which was received from a receiver 104 which only requires a portion of the content which is also required by the other receiver 104.
  • This request will be the earlier of the requests identified at 502. Accordingly, at 806, the earlier of the requests identified at 502 is assigned a higher relative priority than the later of these requests. That is, a first request for content is assigned a higher priority than a second request for content if the first request for content was received prior to the second request for content.
  • the method 800 may then proceed to 506 in which the bandwidth management system 116, 118 allows a receiver requesting content associated with a lower priority content item to access a multicast associated with the higher priority content item.
  • 506 may include (at 810) initiating a multicast of content which was formerly unicast. That is, in order to realize an efficiency and reduce the amount of bandwidth required to transmit on-demand content, in at least some example embodiments, when on-demand content is requested by a receiver, if that same content is already being unicast then one or more of the prior unicasts of the content to those other receivers (i.e. the receivers associated with the higher priority request) may be converted into a multicast of the content to receivers which requested the same content. The receiver which recently requested the content will be permitted to access the multicast.
  • any receiver which requires earlier portions of the content may store the multicast portion of the content in a local content store 189 until it is needed (i.e. until playback of the content reaches the point which is included in the multicast portion of the content).
  • the head end system 102 may unicast the portions of the content which preceded the multicast to any receivers which require this portion of the content.
  • Such receivers may be configured to initially begin playback of the unicast content and then switch to the stored multicast content when playback reaches that portion of the content.
  • a further check is performed at 808 to ensure that the number of unicasts of the requested content exceeds a threshold.
  • the multicast at 506 will not be initiated where there was only one receiver which was previously receiving the content via unicast. Instead, the bandwidth management system 116, 118 may require that a greater number of receivers 104 are receiving the content before it will determine that the bandwidth savings in switching to a multicast of at least part of the content justify the switch. For example, in at least some embodiments, multicasting will only begin if there are already two unicasts of the same content. That is, multicasting will only begin if there will be at least three receivers 104 which will access the multicast. If the number of unicasts does not exceed the threshold, then the content may be unicasted to the receiver from which the request was received at 802.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
PCT/CA2011/050549 2011-09-12 2011-09-12 Method and system for managing bandwidth WO2013037032A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CA2847703A CA2847703C (en) 2011-09-12 2011-09-12 Method and system for managing bandwidth
EP11872347.7A EP2756685A4 (de) 2011-09-12 2011-09-12 Verfahren und system zur verwaltung der bandbreite
PCT/CA2011/050549 WO2013037032A1 (en) 2011-09-12 2011-09-12 Method and system for managing bandwidth

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CA2011/050549 WO2013037032A1 (en) 2011-09-12 2011-09-12 Method and system for managing bandwidth

Publications (1)

Publication Number Publication Date
WO2013037032A1 true WO2013037032A1 (en) 2013-03-21

Family

ID=47882476

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2011/050549 WO2013037032A1 (en) 2011-09-12 2011-09-12 Method and system for managing bandwidth

Country Status (3)

Country Link
EP (1) EP2756685A4 (de)
CA (1) CA2847703C (de)
WO (1) WO2013037032A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015017515A1 (en) * 2013-07-30 2015-02-05 Imvision Software Technologies, Ltd. A method and system for efficient transmission of over-the-top streams over fixed-line networks
US20150049762A1 (en) * 2013-08-13 2015-02-19 Imvision Software Technologies Ltd. Method and system for self-detection and efficient transmission of real-time popular recorded over-the-top streams over network communications
US9432731B2 (en) 2013-07-17 2016-08-30 Imvision Software Technologies Ltd. Method and system for detecting live over the top (OTT) streams in communications networks
US9674252B2 (en) 2013-07-17 2017-06-06 Imvision Software Technologies Ltd. System and method for efficient delivery of repetitive multimedia content

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003103292A1 (en) * 2002-05-30 2003-12-11 Telstra New Wave Pty Ltd Bandwidth allocation for video-on-demand
US6859839B1 (en) * 1999-08-06 2005-02-22 Wisconsin Alumni Research Foundation Bandwidth reduction of on-demand streaming data using flexible merger hierarchies
US20090100459A1 (en) * 2007-10-15 2009-04-16 Steven Riedl Methods and apparatus for revenue-optimized delivery of content in a network
US20100103950A1 (en) * 2007-03-15 2010-04-29 Maindata, Spol. S R.O. Way of bandwidth efficient distribution of multiple transport streams with partially same content

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7698724B1 (en) * 2003-05-15 2010-04-13 Cisco Technology, Inc. Convergence processor for media streams
US20080098446A1 (en) * 2004-08-11 2008-04-24 Vidiator Enterprises Inc, Multicast and Broadcast Streaming Method and System
US7979885B2 (en) * 2005-08-11 2011-07-12 Harmonic Inc. Real time bit rate switching for internet protocol television
US8112781B2 (en) * 2008-10-07 2012-02-07 General Instrument Corporation Content delivery system having an edge resource manager performing bandwidth reclamation
US8370520B2 (en) * 2008-11-24 2013-02-05 Juniper Networks, Inc. Adaptive network content delivery system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6859839B1 (en) * 1999-08-06 2005-02-22 Wisconsin Alumni Research Foundation Bandwidth reduction of on-demand streaming data using flexible merger hierarchies
WO2003103292A1 (en) * 2002-05-30 2003-12-11 Telstra New Wave Pty Ltd Bandwidth allocation for video-on-demand
US20100103950A1 (en) * 2007-03-15 2010-04-29 Maindata, Spol. S R.O. Way of bandwidth efficient distribution of multiple transport streams with partially same content
US20090100459A1 (en) * 2007-10-15 2009-04-16 Steven Riedl Methods and apparatus for revenue-optimized delivery of content in a network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2756685A4 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9432731B2 (en) 2013-07-17 2016-08-30 Imvision Software Technologies Ltd. Method and system for detecting live over the top (OTT) streams in communications networks
US9674252B2 (en) 2013-07-17 2017-06-06 Imvision Software Technologies Ltd. System and method for efficient delivery of repetitive multimedia content
WO2015017515A1 (en) * 2013-07-30 2015-02-05 Imvision Software Technologies, Ltd. A method and system for efficient transmission of over-the-top streams over fixed-line networks
US20150049762A1 (en) * 2013-08-13 2015-02-19 Imvision Software Technologies Ltd. Method and system for self-detection and efficient transmission of real-time popular recorded over-the-top streams over network communications
US10554707B2 (en) * 2013-08-13 2020-02-04 Imvision Software Technologies Ltd. Method and system for self-detection and efficient transmission of real-time popular recorded over-the-top streams over communication networks

Also Published As

Publication number Publication date
EP2756685A4 (de) 2014-12-03
CA2847703A1 (en) 2013-03-21
CA2847703C (en) 2016-10-18
EP2756685A1 (de) 2014-07-23

Similar Documents

Publication Publication Date Title
US8443408B2 (en) Method and system for managing bandwidth
US10856014B2 (en) Control plane architecture for multicast cache-fill
EP1909459B1 (de) Vorrichtung zum Empfangen eines adaptiven Rundfunksignals und Verfahren dafür
US7272227B1 (en) Delivery of data via omnidirectional digital transmission
US8494516B2 (en) Delivery of subscription services to roaming users through head end equipment
US8108901B2 (en) Managing access to high definition content
US8181210B2 (en) Method for delivery of deadline-driven content flows over a flow transport system that interfaces with a flow delivery system via a selected gateway
JP2003087765A (ja) 加入者端末への視聴情報提供装置
KR20090056848A (ko) 방송 수신기 및 맞춤형 방송 신호 수신 방법
EP2378771A2 (de) System, verfahren und computerlesbares aufzeichnungsmedium zur bereitstellung eines bidirektionalen dienstes in einer digitalen kabelrundfunkumgebung
CA2847703C (en) Method and system for managing bandwidth
US20120124628A1 (en) Method for requesting transmission of broadcast program and method for transmitting broadcast program
WO2014018568A1 (en) Method and system for providing on-demand and pay-per-view content through a hospitality system
US20130268989A1 (en) Method and system for dynamically alocating popular content
US20200322651A1 (en) System And Method For Delivering AV Content
US20220046303A1 (en) System And Method For Delivering AV Content
US20110173671A1 (en) Method and System for Providing Bidirectional Contents Service in Cable Broadcasting Environment, and Computer-Readable Recording Medium
KR20060133703A (ko) 통신과 방송의 통합형 서비스 제공 방법 및 그 장치
KR20100004276A (ko) Vod 예고편 채널을 운영하기 위한 iptv 서버부와iptv 시스템 및 방법
KR20110035647A (ko) 디스플레이장치 및 그의 버퍼링 방법
KR20110087813A (ko) Iptv 방송 수신기 및 애플리케이션 데이터 수신 방법
WO2010021861A1 (en) A method for delivery of deadline-driven content flows over a flow transport system that interfaces with a flow delivery system via a selected gateway

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11872347

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2847703

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2011872347

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2011872347

Country of ref document: EP