US20110154420A1 - Data Feed Resource Reservation System - Google Patents

Abstract

An embodiment of a method includes receiving a subscription request specifying one or more destination sites to receive a video feed and respective times at which to deliver the video feed to each of the one or more destination sites over a terrestrial network, wherein respective delivery times are within a publication time range in which the video feed will be available, and configuring available resources to deliver the requested video feed to the one or more destination sites at the respective times.

Description

COPYRIGHT NOTICE
• Contained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office files or records, but otherwise reserves all rights to the copyright whatsoever. Copyright © 2009Level 3 Communications, LLC.
TECHNICAL FIELD
• Embodiments presently disclosed generally relate to delivery of video feeds. More specifically, embodiments herein relate to delivery of video feeds using a subscription service.
BACKGROUND
• Television content and other data is often distributed over terrestrial networks, such as the Internet. Television broadcasters, for example, may transmit video feeds over a network of an Internet service provider (e.g., a wholesale network service provider). Video feeds (e.g., television programs) are often distributed to different local markets by transmitting the video feeds between locally based broadcaster stations, which may be affiliates of each other in different metropolitan markets. In this manner, for example, a television program from a FOX™ television station in one city could be made available to stations in other cities via the Internet. Unfortunately, conventional systems for distributing video (or other data) feeds over terrestrial networks have various shortcomings.
• In a typical arrangement, a television distributor's site is interconnected with an Internet service provider network at an interconnection point. Through the interconnection point, video feeds can be transmitted and received by the distributor via the service provider network. Conventionally, an interconnection point includes individual video loops for each of the transmitted and received video services, as well as separate channels for data services. This arrangement has resulted in a number of drawbacks and limitations related to the manner in which data and video feeds are distributed over terrestrial networks.
• One problem relates to lack of scalability of conventional systems. The use of individual video loops and data channels at distributors' sites has prevented distributors from taking advantage of economies of scale that could otherwise exist. In this regard, addition of a new video service over the Internet, for example, often cannot take advantage of already existing infrastructure or systems, due to the inflexible infrastructures at distributors' sites. For example, in conventional systems, if a video distributor wants to provide another video service, another separate video channel typically must be installed at the distributor's site.
• In addition, conventional systems have been characterized by inefficient use of bandwidth. For example, often a high rate data channel, such as a full 270 Megabit/sec (Mbps) data rate channel, is used to transmit low bit rate data such as Asynchronous Serial Interface (ASI) traffic. In addition, for each additional destination that receives a data feed from a single source, the outgoing bandwidth consumed from the source increases. For example, sending a 20 Megabit/sec video feed to 20 destinations requires the customer to have at least a 400 Megabit/sec or faster connection. This inefficient use of bandwidth is related to the lack of scalability of conventional systems—conventional systems cannot rapidly adapt to changes in network bandwidth conditions to thereby use existing bandwidth in an efficient manner. As such, growth in, and use of, video services over terrestrial networks, such as the Internet, have been inefficient, limited, cumbersome and inflexible.
• It is with regard to the foregoing problems and other problems that embodiments of the present invention have been developed.
SUMMARY
• Embodiments presently disclosed generally relate to data feed resource reservation systems and methods. Further, embodiments include systems and methods for time-based routing of data over a terrestrial network using a resource reservation scheme. A reservation system is provided through which resources can be reserved for the distribution and receipt of data feeds such as video feeds. The reservation system includes an interface for receiving reservation parameters and a scheduling system for scheduling available resources to deliver and receive data feeds. Accordingly, resources, such as bandwidth, are reserved for delivering data feeds prior to actual data feed delivery, based on a time-based scheduling scheme.
• In at least one embodiment, a video feed can be scheduled for publication within a time frame. An entity, such as, but not limited to, a local broadcaster, may subscribe to the video feed by submitting a subscription request. One or more destinations may be specified in the subscription request. A different delivery time may be specified, respectively, for one or more of the destinations. A scheduling system receives the subscription request and determines if sufficient resources are available to deliver the video feed to the one or more destinations at the respective delivery times. Prior to the specified delivery time(s), available resources are scheduled (e.g., reserved) for delivery of the video feed at the specified delivery time(s). The scheduled resources are configured for video feed delivery and released after the delivery time(s).
• An embodiment of a method of managing delivery of a video feed over a terrestrial network includes receiving a subscription request specifying one or more destination sites to receive the video feed and respective times at which to deliver the video feed to each of the one or more destination sites, wherein respective delivery times are within a publication time range in which the video feed will be available. The method further includes configuring available resources to deliver the requested video feed to the one or more destination sites at the respective times. Further still, the method may include receiving a publication request specifying the publication time range.
• An embodiment of the method may further include identifying one or more available resources that are available at the respective delivery times. Configuring available resources may include reserving one or more ports of a replicator to deliver the requested video feed at the respective delivery times. The method may further include determining whether there is sufficient bandwidth on one or more ports of a video feed delivery device to deliver the requested video feed at each of the one or more delivery times. The method may further include sending a rejection message if there is insufficient bandwidth available to deliver the requested video feed at a requested delivery time. Still further, the method may include sending a reservation confirmation message confirming that resources are available to deliver the requested video feed if sufficient bandwidth is available.
• An embodiment of a method may further include de-allocating the available resources after delivery of the requested video feed. Configuring available resources may include determining if resources are available to deliver the requested video feed at each of the one or more delivery times, and if resources are not available to deliver the requested video feed to one of the one or more destination sites, and resources are available to deliver the video feed to the other one or more destination sites, configuring only the available resources to deliver the video feed to the other destination sites at the respective delivery times.
• An embodiment of a system for managing delivery of video feeds over a terrestrial network includes a resource scheduler operable to reserve available resources at one or more requested times for delivering a video feed to respective one or more requested destinations and a configuration module operable to configure the available resources for delivering the video feed to one or more destinations at the respective times at which resources are available. The resource scheduler may be further operable to release available resources after the one or more requested delivery times. The resource scheduler may be further operable to receive a publication request specifying a publication time window in which the video feed will be available for delivery.
• Still further, the resource may be operable to receive a subscription request specifying one or more requested delivery times and respective one or more destinations. The resource scheduler may be further operable to determine whether each of the one or more requested delivery times are within the publication time window. Still further, the resource scheduler may be operable to determine whether sufficient resources are available at an origination location and each of the one or more destinations at the respective delivery times. Further still, the resource scheduler may be operable to choose a destination location from among a plurality of destination locations to which the video feed can be delivered.
• Further yet, the resource scheduler may choose the destination location based on zones of locations. The resource scheduler may further provide an online interface for subscribing to video feeds to be published. The online interface may present video feeds that will be published. The online interface may be configured to receive subscriptions to one or more selected video feeds.
• An embodiment of a computer implemented method for managing delivery of a data feed over a terrestrial network includes receiving a publication request specifying a publication time frame within which the data feed will be available for publication, receiving a subscription request to subscribe to the data feed, the subscription request specifying a destination to receive the data feed and an associated delivery time to deliver the data feed at the destination, reserving available bandwidth at the specified delivery time if the specified delivery time is within the publication time frame, and denying the subscription request if the specified delivery time is outside the publication time.
• An embodiment of a computer program product may include one or more computer-readable media. The computer-readable media may have computer executable instructions encoded thereon. The computer executable instructions may be executed by a general purpose or specific purpose computer to carry out processes described herein. Computer-readable media may comprise storage media.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 illustrates an example network environment suitable for carrying out data feed resource reservation according to an embodiment.
• FIG. 2 illustrates an example network environment suitable for carrying out data feed resource reservation and data feed delivery over a terrestrial network according to the embodiment ofFIG. 1.
• FIG. 3 illustrates ports of a network adapter unit, which is operable to transmit and receive data feeds.
• FIG. 4 illustrates an example system for carrying out data feed resource reservation according to an embodiment.
• FIG. 5 illustrates an example subscription or publication request according to an embodiment.
• FIG. 6 illustrates an example user interface for entering subscription or publication request details according to an embodiment.
• FIG. 7 illustrates an example user interface for entering subscription and/or publication request parameters according to an embodiment.
• FIG. 8 illustrates an example user interface presenting an example reservation request confirmation according to an embodiment.
• FIG. 9 illustrates an example user interface presenting reservation request confirmation details according to an embodiment.
• FIG. 10 illustrates an example user interface for searching for scheduled data feed publications, which may be subscribed to according to an embodiment.
• FIG. 11 illustrates an example user interface presenting scheduled data feed publications in response to the search requested through the user interface ofFIG. 10 according to an embodiment.
• FIG. 12 is a flow chart illustrating an example algorithm for carrying out data feed resource reservation according to an embodiment.
• FIG. 13 is an example block diagram of a computer system configured with a data feed resource scheduling application and process according to embodiments herein.
DETAILED DESCRIPTION
• Embodiments presently disclosed generally relate to scheduling delivery of data over a terrestrial network. More specifically, embodiments herein relate to time-based routing of video feeds. A video feed can be scheduled for publication within a time frame. An entity, such as, but not limited to, a local broadcaster, may subscribe to the video feed by submitting a subscription request. One or more destinations may be specified in the subscription request. A different delivery time may be specified, respectively, for one or more of the destinations. An embodiment of a system receives the subscription request and determines if sufficient resources are available to deliver the video feed to the one or more destinations at the respective delivery times.
• One or more embodiments include systems and methods for time-based allocation of resources, such as circuit bandwidth, to one or more data types that can be communicated over a terrestrial network. A circuit can include one or more ports, and typically includes multiple ports. Each port provides a certain amount of bandwidth, which can be allocated to the various data types. Data types can include data services, video feeds, management data and others. A system can allocate bandwidth to a video feed at a specified time in the future on a particular circuit. In an embodiment, data services are adjusted (e.g., reduced) on the particular circuit based on quality of service (QOS) settings in the network devices. In these or other embodiments, management data is transmitted across different circuits on a management network.
• In some embodiments, allocation of bandwidth can involve reserving a port on the circuit at a specified time. The system further keeps track of how much bandwidth has been reserved for each port. When a maximum amount of bandwidth has been reserved on a port at a given time, no more bandwidth can be allocated on that port at that time. Available bandwidth can be allocated to various data types until the maximum amount of bandwidth is reached. In this manner, use of limited bandwidth on circuits can be adapted prior to delivery of data in order to efficiently use the bandwidth. In one embodiment, unallocated bandwidth will be used by the data service and if there isn't any available bandwidth, then data service traffic is suspended until bandwidth becomes available again.
• Various embodiments relate to creating a community of interest within which video or other data feeds can be shared among members of the community of interest. Members may be related to each other in some way, such as, but not limited to, as affiliates of a larger organization. Alternatively, or in addition, members may include one or more entities that are not affiliates of a larger organization. In cases where the community of interest includes affiliates, data feeds may be shared via one or more private ports of data delivery devices of the affiliates. In cases where the community of interest includes non-affiliates, data feeds may be shared via one or more public ports of the members of the community of interest.
• An embodiment includes a system operable to perform time-based routing of video or other data feeds over a terrestrial network. In these embodiments, a publication request may be received that specifies a time window within which a video feed will be published in the future. An embodiment of the system maintains a schedule of video feeds to be published. Entities, who may or may not be members of a community of interest, can subscribe to the video feeds. An entity can submit a subscription request which requests that a video feed be delivered to one or more destinations at one or more respective times. The system may validate the subscription request by, for example, checking whether the one or more respective times are within the time window specified by the publication request.
• In an embodiment, the system further checks that sufficient resources, such as bandwidth, are available at the respective times at the video feed origin and the one or more destinations. The check for sufficient resources may involve determining whether sufficient bandwidth is available at an origin (e.g., an origination circuit) to transmit the video feed within the specified publication time. For example, the system may determine if a port is available at the origin at the specified time, which can provide sufficient bandwidth to deliver the requested video feed. If sufficient resources are not available, a notification is generated that indicates that the resources could not be reserved. If sufficient resources are available, available resources are reserved.
• In various embodiments, available resources are reserved for publication and delivery of video feeds at specified subscription times. Resources include, but are not limited to, bandwidth, ports, circuits, channels and/or other resources that are used to deliver a video feed from an origin to a destination. Reservation of resources can involve configuring one or more video feed delivery devices to deliver and/or receive a scheduled video feed at a given time. Configuring resources may involve making the resources operational to perform a given function. For example, one or more ports on a core replicator device may be reserved to transmit the scheduled video feed at the given time. After the video feed(s) is/are delivered at the specified time(s), the reserved resources are released. Releasing resources involves making the resources available for use in other video feed deliveries. Once released, the resources may be reserved for other publications and subscriptions.
• An embodiment of a system provides a user interface through which publication requests and subscription requests can be submitted. The user interface may be web-based. In a web-based embodiment, users may access the interface via a public network, such as the Internet, or private network, such as an intranet or virtual private network. Users who may access the interface may be members of a community of interest.
• In at least one embodiment, through a user interface a user can specify an origin of a video feed, from which the video feed will be published. The user may also specify one or more destinations to which the video feed is desired for delivery. The origin and destinations may be specified by location (e.g., city and state) and/or circuit (e.g., circuit identifier(s)). In one embodiment, if no destinations are specified, the request is considered to be a publication request. A publication request is a request for resources for publishing a video feed from a specified origin at a specified time.
• According to one or more embodiments, a system can deliver a video feed to a single destination or multiple destinations. In the case of multiple destinations, the video feed may be transmitted multiple times over multiple channels to the multiple destinations. The multiple transmissions of the video feed may be at one or more different times or the same time. Transmission of the video feed to multiple destinations may be carried out using replication. Replication involves regenerating a published video feed on one or more channels to multiple destinations.
• In one embodiment, replication of a published data feed allows for simultaneous delivery of multiple data feeds. For example, a single data feed may be simultaneously reproduced on multiple separate channels to multiple respective destinations. Replication may be carried out at one or more locations relative to a data feed delivery network, including, but not limited to, in a core of the network, on an edge of the network and/or at a data feed distributor's premises. Delivery of multiple data feeds can involve simultaneous (e.g., in parallel) delivery of two or more of the data feeds and/or sequential (e.g., serial) delivery of the data feeds.
• FIG. 1 illustrates anexample network environment100 suitable for time-based routing of data feeds through a terrestrial network according to at least one embodiment. The network environment includes one or more sites102 that can generate (e.g., publish) and/or receive data feeds from other sites102. The data feeds are transmitted, at least in part, over a terrestrialdata delivery network104. In at least one embodiment,data delivery network104 is an infrastructure of routers (not shown), data channels (e.g., fiber), and/or other network devices, that form a packet based communication network. In one embodiment, thecommunication network104 is an Internet protocol (IP) network that uses a multiprotocol label switching (MPLS) protocol.
• Sites102 are locations between which data, such as, but not limited to, video feeds, can be communicated. For example, a site102 may be a local network broadcasting station. The sites102 are typically geographically distributed. For example, site102A may be located in Los Angeles and site102B may be located in New York. As such, theterrestrial network104 typically spans a geographic area that includes multiple locations of the various sites102. Although only three sites102 are shown inFIG. 1, it will be understood by those of skill in the art that numerous other sites may communicate via thenetwork104 in actual operation.
• The sites102 include resources for producing and handling various types of data. For example, in the case of video, a site102A may have video capture equipment, such as video cameras (not shown). Sites102 also include data delivery and reception equipment configured to transmit and receive data, respectively, from other sites102. In various embodiments, such as the embodiment shown inFIG. 2, the data delivery and reception equipment at each site102 includes a network adapter unit operable to format data for delivery over theterrestrial network104. Of course the resources available at each site102 to deliver and receive data are not unlimited. For example, each site102 is typically limited to a maximum bandwidth for transmitting data at any given time.
• As discussed, sites102 may generate (e.g., publish) data feeds, such as, but not limited to, video feeds. A data feed is generally an identifiable set of one or more units of related data having a beginning and an end. Other sites102 may wish to subscribe (described further below) to published data feeds to thereby receive the published data feeds at a selected destination site or sites. Due in part to limited resources at each site102, a resource reservation scheme is employed to manage use of limited resources. In one embodiment of the reservation scheme, resources are reserved in advance to carry out the delivery of data feeds across theterrestrial network104 at specified times. As such, the reservation scheme provides for time-based routing of data feeds over theterrestrial network104.
• In one embodiment, anadministrative network106 is provided which supports resource scheduling. Theadministrative network106 may be a public or private network. For example, in one embodiment theadministrative network106 is the public Internet. In another embodiment, theadministrative network106 is a private intranet. In yet another embodiment, theadministrative network106 is a virtual private network. Theadministrative network106 provides an infrastructure for reserving resources for routing of data feeds in a time-based fashion.
• In one embodiment, theadministrative network106 includes one or more web servers or other server computers, which provide a user interface and maintain a schedule of resource reservations. Users at sites102 can log into the web server and request resources for publication of a specified data feed, as well as subscribe to a published data feed. Subscribing to a published data feed refers to requesting delivery of the published data feed at one or more specified destinations at one or more respective specified times. Theadministrative network106 server computers determine if resources are available at the associated sites and reserves available resources, if any. In this manner theadministrative network106 servers manage the use of resources, such as bandwidth, to carry out time-based routing of the data feeds.
• With further regard to sites102, in some embodiments, each site102 can be included in one or more communities of interest. Members (or associates) of a community of interest can share data feeds between each other. Members of a community of interest may or may not be affiliates of a larger organization. For example, in a given community of interest all the members may be FOX™ affiliates of the FOX™ corporation. In another case, some of the members may be affiliates of a larger organization, while other members may not be affiliates of the larger organization. For example, the community of interest may include multiple FOX™ affiliates and an ESPN™ site and a CNN™ site.
• In some embodiments, sites102 can be included in defined zones, such aszone108. The zones may be a logical, geographic or other relationship between sites102. For example, some sites102 that are located in the western United States may be in a Western zone. Similarly, other zones could be a Central zone, an Eastern zone, a Southern zone, a Northeastern zone and/or a Midwestern zone.Zones108 may be useful for determining a preferred publishing point for a data feed. For example, a data feed to be delivered to a site102 in a Western zone may be published from one of the Western sites102. Thezones108 may be prioritized, whereby a more proximate zone has a higher priority than other zones. Other logical prioritization schemes may be employed.
• As discussed further below, each site102 includes one or more data delivery devices, such as a network adapter unit, discussed further below.FIG. 3 is discussed here for ease of discussion. Eachdata delivery device212 includes a number ofports302, such as are shown inFIG. 3. Theports302 can be designated as public or private.Private ports304 can be used by sites that are members of the same community of interest, andpublic ports306 can be used by any sites. For example, a FOX™ affiliate site may have twoprivate ports304 and eightpublic ports306. In this example, other members of the FOX™ community of interest may subscribe (subscribing is described below) to a data feed on one of theprivate ports304 of the FOX™ affiliate, while another site such as a CNN™ site, may subscribe to a data feed from one of thepublic ports306 of the FOX™ affiliate.
• FIG. 2 illustrates anetwork environment200 showing network components that can be used to provide a data feed resource reservation and managed delivery service according to the embodiment ofFIG. 1. InFIG. 2, component details of one of the sites,site202A, are shown according to a particular embodiment. Other sites, such as202B through202N, typically included similar components as those shown insite202A. In general,site202A is in operable communication with components of avideo delivery network204 and anadministrative network206.
• In the illustrated embodiment, a coder/decoder (CODEC)210 atsite202A is operable to receive unencoded data from a data feed source208 (e.g., a video camera, a data feed repository and/or others). Unencoded data may be video data that comprises a video feed.CODEC210 encodes the data into an encoded format. An example of aCODEC210 is a Motion Picture Experts Group (MPEG) video encoder/decoder, but theCODEC210 is not limited to an MPEG codec. In one embodiment theCODEC210 receives uncompressed data and compresses the data into an Asynchronous Serial Interface (ASI) format. In the illustrated embodiment a network adapter unit (NAU)212 receives encoded video data and formats the data into Gigabit Ethernet (Gig-E) format.
• In some embodiments, depending on the protocol and format used by thevideo delivery network204, one ormore transmission adapters214 are included to format the Gig-E signal from theNAU212 for transmission over thevideo delivery network204. In one embodiment, thetransmission adapter214 converts or formats the Gig-E signal from theNAU212 into one or more of a digital signal 3 (DS3), optical carrier 3 (OC3) or OC12 format, which can be communicated over thevideo delivery network204. One or more embodiments also support OC-48 or OC-192, as well as Ethernet at 10 Megabits/sec (Mbps), 20 Mbps, 30 Mbps, 40 Mbps, 50 Mbps, 100 Mbps, 200 Mbps, 300 Mbps, 400 Mbps, 500 Mbps, 600 Mbps and 1 Gigabit/sec (Gbps).
• Other data services are not data feeds, but are carried over the network. Such data services may supplement data feeds, such as video feeds. Examples of data services include, but are not limited to, electronic programming guide data, closed captioning, or other services. Such other data services may be introduced through thetransmission adapter214. Such data services may be included in data feeds transmitted by thetransmission adapter214. Atransmission adapter214 is not necessary in embodiments where the Gig-E signal from theNAU212 can be communicated directly over thevideo delivery network204 without any additional formatting or conversion.
• In at least one embodiment, theNAU212 has multiple ports for communicating data. In one embodiment, the number of ports is ten.FIG. 3 is discussed here again to further illustrate the use of ports on theNAU212.FIG. 3 is an elevation view of anexample NAU212 according to a particular embodiment. TheNAU212 includes tenphysical ports302. Each port can handle or provide a maximum bandwidth. In other words, there is limited bandwidth available through theNAU212 at any given time. All of theports302 form acircuit308. The bandwidth of thecircuit308 is the sum of the bandwidth of all theports302.
• Thephysical ports302 may include one or moreprivate ports304 and one or morepublic ports306.Private ports304 can be subscribed to by other sites202 that are members of a community of interest.Public ports306 can be subscribed to by other sites202 that are not members of the same community of interest.
• Continuing again with the embodiment shown inFIG. 2, arouter216 ofsite202A is communicably coupled to theNAU212 and thetransmission adapter214. Therouter216 provides management data to thetransmission adapter214. Management data from therouter216 may be incorporated into signals that are transmitted over thevideo delivery network204 by the transmission adapter.
• Thevideo delivery network204 includes areplicator218. The replicator includes numerous ports and is in communication with numerous sites202. The replicator is operable to receive a data feed fromtransmission adapter214 and retransmit the data feed to one or moreother sites202B,202N. Thereplicator218 is configurable (e.g., by a configuration module, discussed further below) to route data feeds to selected sites at specified times. Thereplicator218 may reproduce data feeds in a serial or parallel manner. For example, thereplicator218 can reproduce multiple data feeds simultaneously (e.g., parallel) to different destination sites and/or thereplicator218 can reproduce multiple data feeds one after the other (e.g., serially), or a combination of serial and parallel. For example, in a serial subscription scenario, the publication may be a 30 minute publication. In this scenario a first subscription may run for 10 minutes, followed by another subscription for 15 minutes.
• In an embodiment,site202A further includes acomputer220 that is in operable communication with areservations interface222 of theadministration network206. Thecomputer220 can have stored in memory an executable browser application, with which a user can navigate to one or more web-based reservation interfaces222 provided by a web server of theadministration network206. Through theinterface222, the user can submit publication requests and subscription requests and the user can be notified as to whether or not the requests are fulfilled.
• Aresource scheduler224 receives request data from the reservations interface and attempts to find available resources among the devices at sites202 and theterrestrial network204, with which to fulfill the requests. Theresource scheduler224 can reserve available resources to deliver the data feed that is the subject of the publication or subscription request. Further, the scheduler can adapt the use of available bandwidth to achieve an efficient use of bandwidth for delivery of video feeds. By identifying available resources for carrying the associated data feed at specified time(s), the scheduler performs time-based routing of the data feed.
• Theresource scheduler224 is further operable to release resources after they have been used to fulfill a publication or subscription request. Releasing resources may involve de-allocating the resources. For example, de-allocating the resources may involve marking resource identifiers in memory in such a way as to indicate the resources are no longer allocated to the previous data feed delivery event, and that the resources are available for use. An example embodiment of a resource scheduler is shown inFIG. 4 and discussed in detail below.
• If sufficient resources are determined to be available to satisfy a request, aconfiguration module226 configures the available resources according to the schedule. Theconfiguration module226 is in communication with devices (e.g.,NAU210 and replicator218) at the sites202 and theterrestrial network204 in order to configure them. Theconfiguration module226 may also be operable to deconfigure or reconfigure the devices after the delivery of each scheduled video feed.FIG. 4 illustrates example modules according to one embodiment of a data feed resource reservation system.
• FIG. 4 is a module diagram illustrating anexample system400 for carrying out data feed resource reservation in accordance with an embodiment. The data feedresource reservation system400 may be incorporated in an administrative network, such as administrative network206 (FIG. 2) or other architecture. In general, the data feedresource reservation system400 is operable to receive subscription and publication request parameters and, based on the parameters, schedule available resources for delivery of the data feed.
• In general, areservations interface402 receivesrequest parameters404 and outputsreservation status notifications406. In one embodiment, the reservations interface402 is a user interface that a user can access through a computer. For example, the reservations interface402 can be a web-based interface accessible by users through a network. In one embodiment the reservations interface402 presents one or more user screens through which parameters can be entered and data can be displayed. Example user interface screens are shown inFIGS. 6-11, which are described in detail further below.
• In another embodiment, the reservations interface402 is an application interface program through which other computer programs or processes can enterreservation parameters404. In this embodiment, parameters may be obtained from another source, such as a user interface or a repository of parameters that is separate from thesystem400.
• In one embodiment,reservation parameters404 can include but are not limited to user identification, customer identification, zone, circuit identifier(s), bandwidth or time specifications. The reservation parameters are used by the reservations interface402 to form areservation request408, which may be a publication request or a subscription request. An embodiment of areservation request408 is shown inFIG. 5.
• In the embodiment shown inFIG. 5, thereservation request408 includes an origination circuit identifier (ID)502, which identifies a circuit from which a video feed is to be published. The identified origination circuit can be specified in a publication request or a subscription request. In either case, the user can specify theorigination circuit502 through a user interface. In the case of a subscription request, theorigination circuit502 is a circuit that has been previously reserved via a publication request.
• As discussed below in detail with reference toFIGS. 6-11, a publication reservation can be searched for through a user interface. When the desired publication is found, it can be selected through the user interface for use in creating and submitting a subscription request. By selecting a scheduled publication, the corresponding origination circuit is selected.
• Continuing withFIG. 5, thereservation request408 includes one or more destination circuit IDs504 if thereservation request408 is a subscription request. If the reservation request is a publication request, thereservation request408 generally does not include destination circuit IDs504. As discussed further below with reference toFIGS. 6-11 a user can specify the one or more destination circuit IDs504 through a user interface. The destination circuit(s)504 indicate the circuit(s) and location(s) where the publication is to be transmitted.Origination circuit ID502 and destination circuit ID(s)504 generally specify a circuit at a location, such as a given city.
• In an embodiment, thereservation request408 includes anorigination start time506A and anorigination end time506B associated with the identifiedorigination circuit502. For example, if therequest408 is a publication request, theorigination start time506A and theorigination end time506B specify the start and end times, respectively, of the publication to be published via the identifiedorigination circuit502.
• Therequest408 further includes one or more destination circuit start times508 and one or more destination circuit end times510 associated with the respective destination circuit(s)504. If therequest408 is a subscription request, thefirst start time508A and thefirst end time510A correspond to the time frame for delivery of the publication to thefirst destination circuit504A, the second start time508B and the second end time5108 correspond to the time frame for delivery of the publication to thesecond destination circuit504B, if any, and so on, up todestination circuit N504N, if more than one destination circuit is specified.
• In the embodiment ofFIG. 5, the reservation request includes abandwidth parameter512. The bandwidth parameter specifies the desired bandwidth for the publication. The desired bandwidth is the user specified bandwidth for the published video feed. If the publication is reserved at 8 Megabits/second (Mbps), then by default all subscription reservations will be at 8 Mpbs. In one embodiment, the requested bandwidth is reserved up to the maximum bandwidth that the origination or destination circuit can provide.
• As discussed further below, a user can specify a name (or other identifier) for a reservation. When booking a publication reservation, the user is able to provide a name for the reservation. For example a customer could give a reservation the name “Test Reservation”. The name is intended to be useful to the customer for the customer to distinguish between reservations.
• Continuing with the embodiment illustrated inFIG. 4, thereservation request408 is sent to ascheduler410. Thescheduler410 parses the reservation request and uses one or more reservation parameters in therequest408 to determine if sufficient resources are available to satisfy the requested publication or subscription. Thescheduler410 accesses a number of sets of data to determine if sufficient resources are available and schedule reserved resources. To illustrate, some data sets that may be used include port/circuits412,CODECs413,bandwidth414,schedule416, customer/affiliate sites418 andzones420. These data sets are discussed in detail further below.
• In one embodiment, thescheduler410 generates areservation response422 in response to thereservation request408. If thescheduler410 identifies available resources to satisfy therequest408, theresponse422 confirms that resources are available and/or the available resources have been reserved. Theresponse422 may identify the particular resource(s) that have been reserved. If insufficient resources are available to satisfy therequest408, the response indicates that resources are not available to satisfy the request.
• In some embodiments, theresponse422 can indicate partial satisfaction of therequest408, when only part of therequest408 can be satisfied (e.g., sufficient resources are available for less than all specified destination circuits). For example, when a subscription request specifies multiple destinations, theresponse422 may indicate that the request can be satisfied for some of the destinations, but that the request cannot be satisfied for other(s) of the destinations. The reservations interface402 outputs the confirmation/denial based on the reservation response. When part or all of arequest408 cannot be satisfied, the user can resubmit reservation parameters. For examplenew reservation parameters404 may be submitted that specify a different time for delivery of a requested video feed.
• Referring again to the various data sets, ports/circuits412 includes a list of ports and/or circuits at sites (e.g., sites202) and/or devices (e.g., replicator218) on a terrestrial network (e.g., network204). Thescheduler408 can identify available ports and/or circuits for use in scheduling data feed transmissions using the ports/circuits data set412.CODECs413 specify one or more coding and decoding formats that data can be converted to and from.Bandwidth data set414 includes bandwidths of associated ports and/or circuits of the ports/circuit data set412. Thescheduler408 can use the ports/circuits412 and associatedbandwidths414 to allocate bandwidth available on the ports and/orcircuits412 to requested publications and subscriptions.
• In some embodiments, for example, the scheduler can read the specified bandwidth and circuit from arequest408 and then read the maximum bandwidth for the specified circuit from thebandwidth data set414. If the requested bandwidth is greater than the maximum bandwidth of the specified circuit, then the request cannot be fulfilled. Otherwise, the request might be fulfilled if the specified circuit is not already overscheduled, as indicated by the times/schedule416.
• In one embodiment, time/schedule416 includes dates and times associated with reserved resources, such as port, circuits and bandwidth. For example, the time/schedule416 can be a calendar or other time-based register of circuit/port identifiers and/or bandwidths used on those circuits/ports at various days and times. Customer/affiliatesites data set418 identifies customers and/or affiliate sites, such as broadcasters, who can submit reservation requests and communicate via the terrestrial network.Zones data set420 includes a list of zones (e.g., geographical or logical) associated with one or more sites in the customer/affiliatesites data set418.
• In one embodiment thescheduler408 uses the customer/affiliate sites418 to identify communities of interest and/or to determine if a particular port can be used by a requester. For example, a requester that is not an affiliate of a site from which a publication is being requested typically cannot reserve a private port of the specified site. The scheduler therefore determines from the customer/affiliate sites418 whether particular ports can be reserved by each requester. The scheduler can determine if the requester is in particular zone, as indicated inzones data set420, to thereby determine a preferred publication site from which to transmit a requested video feed.
• In at least one embodiment, aconfiguration module424 is in communication with thescheduler408 and terrestrial network devices, such asNAU212 and/orreplicator218. Theconfiguration module424 is operable to configure the terrestrial network devices according to theschedule416. Thescheduler408 sendsconfiguration messages426 to theconfiguration module424 to notify theconfiguration module424 of scheduled events, times and/or reserved resources. For example,configuration messages426 may identify a port and/or circuit to be configured to transmit or receive a video feed at a certain time. Based onconfiguration messages426, theconfiguration module424 generates one or more configuration commands428, which are transmitted to associated terrestrial network devices to thereby configure the devices to transmit or receive at scheduled days/times.
• Turning toFIGS. 6-11, there are shown a number of user interfaces for submitting publication and subscription parameters. In one embodiment, the user interfaces are provided by a reservation web-server based in a network, such as administration network106 (FIG. 1). Users based at sites (e.g., sites102,FIG. 1) can log into the reservation web-server via a computer, such ascomputer220 ofFIG. 2. As discussed above, the computer may execute a browser application that enables the user to navigate to web page interfaces such as those shown inFIGS. 6-11.
• Turning toFIG. 6, there is shown auser interface600 through which reservation details can be entered in anorder detail tab601. A company name can be selected in acompany name field602. The company name corresponds to the customer for which the reservation is being requested. Using a drop down arrow of thecompany name field602, a list of company names is presented from which the user can select. The general location associated with the reservation may be selected as either domestic or international using adomestic radio button604 and aninternational radio button606. In this embodiment, international refers to locations outside the United States. Other embodiments do not includedomestic radio button604 orinternational radio button606.
• A unique reservation name can be entered in areservation name field608. A reference purchase order (PO) associated with the reservation can be entered in areference PO field610. Acategory field612 enables the user to enter/select a category associated with the reservation. By clicking on the drop down arrow of thecategory field612, a list of possible categories is presented. In one embodiment, possible categories include entertainment/programming, news, production/advertisements, video conference, other, and unknown.
• Start time field(s)614 enable the user to enter the start date and the start time of the reservation. End time field(s)616 enable the user to enter the end date and end time of the reservation. In one embodiment reservations are booked using a 24-hour clock system, wherein midnight start of day (12:00 AM) is entered as 00:00, noon/12:00 PM is entered as 12:00, and midnight end of day is entered as 24:00. In this embodiment end date and time does not exceed 24 hours.
• In the illustrated embodiment, feed type is entered using alive radio button618 and a tape radio button620.Live radio button618 should be selected if the reservation corresponds to a live video feed; tape radio button620 should be selected if the reservation corresponds to a taped video feed.
• Through a service field622 a service type can be selected. In one embodiment digital service is selected if core replicator/publish and subscribe functionality are used. Through an event type field624 a type of event can be selected. In one embodiment, ASI OCA can be selected, for example, if core replicator/publish and subscribe functionality are used.
• In the illustrated embodiment, bandwidth (e.g., bit rate) of the reserved video feed is entered/selected in abandwidth field626. Through anapproximate end field628, an approximate end time can be entered. In one embodiment, a 15 minute approximate end time is allowed for reservations less than 60 minute and a 30 minute approximate end is allowed for reservations 60 minutes or more.
• In one embodiment, through atime zone field630, the time zone of the reservation can be selected. In anote field632, notes may be entered to further explain the reservation. In one embodiment, any entered notes appear on a customer confirmation letter for the customer's use.
• In one embodiment, atemplates button634 can be selected to choose a reservation template. A reservation template includes preset parameters. Areset button636 can be selected to reset parameters previously entered in the fields. In the illustrated embodiment anext button638 can be selected after the order detail parameters have been entered. Upon selecting thenext button638, a “From/To”tab640 is presented.
• An embodiment of the From/To tab640 is shown inFIG. 7. Through the From/To tab640 origin circuit/location parameters and destination circuit/location parameters can be entered. Through anorigin location field702, the location (e.g., city and state of origin site) of the origin circuit can be selected. Through anorigin circuit field704, an origin circuit identifier can be selected. The origin location and origin circuit correspond to the location and circuit, respectively, from which the associated video feed will be published. Through anaudio channel field706A, the number of audio channels can be indicated for the origin circuit video feed. Through asignal format field708A a signal format can be selected for the origin circuit video feed. In one embodiment, the signal format may be ASI or others.
• In the illustrated embodiment, an in-net sites checkbox710 can be checked to display only sites of the company that is making the reservation. In other words, “in-network” refers to member sites of the community of interest for which the reservation is being made. In one embodiment, only private ports/circuits will be shown if the in-net check box is checked. If the in-net check box710 is not checked, public ports/circuits appear in addition to the private ports/circuits. If the in-net check box710 is unchecked, the user can view every circuit that the user/company has permission to view (e.g., public, private, in-network).
• In the illustrated embodiment, acore replicator checkbox712 enables the user to designate whether the associated video feed will be distributed via a core replicator (e.g.,replicator218,FIG. 2). In one embodiment, thecore replicator checkbox712 is checked by default. The corereplicator check box712 allows the user to create ‘core replicator’ or ‘publication’ reservations so that other sites can subscribe to the publications as desired. If thecore replicator checkbox712 is checked, then destinations do not need to be selected. When the user is submitting only a publication reservation, the user should check (i.e., select) thecore replicator checkbox712 to opt for core replication or publication. Abook button714, discussed further below, can then be selected to submit the publication reservation.
• If the reservation request that is being created is a subscription request, destination parameters, such as sites/locations, are also specified through the from/totab640. In the illustrated embodiment, destination locations and circuits can be selected through one or more destination location fields716 and destination circuit fields718, respectively. In the illustrated embodiment, the destination location fields716 and destination circuit fields718 are drop down lists of options that can be selected by the user. For each destination location and circuit, there is an associated audio channel field706 and signal format field708, through which the user can select an associated audio channel and signal format, respectively.
• In one embodiment, anadd button720 can be selected to add another destination. When the user selects theadd button720, another set ofdestination location field716,destination circuit field718, audio channel field706 and signal format field708 are presented. The user can use the added fields to enter parameters of the additional destination that is to receive the video feed.
• In the embodiment ofFIG. 7, a save astemplate button722 enables the user to save all currently entered reservation parameters as a template. Once saved as a template, the user can later retrieve the template parameters in future request submissions. Aback button724 enables the user to return to theorder details tab601. Areset button726 can be selected to reset the parameter fields. In one embodiment, selection of thereset button726 clears data from all fields on the from/totab640. After all desired origination and destination parameters are entered, the user can select thebook button714 to submit the reservation request parameters.
• After the user clicks thebook button714, areservation status tab802 is presented, as shown inFIG. 8, according to one embodiment. Thereservation status tab802 shows the status of the reservation request. Possible statuses are success and failed. In the example shown inFIG. 8, the shown reservation requests are successful, meaning resources were able to be reserved and the reservation was scheduled consistent with the requests. Thereservation status tab802 presents one or more reservation identifiers, such as reservation numbers804, uniquely identifying respective reservation requests.
• In the illustrated embodiment, certain reservation information is shown in association with the reservation numbers804, such as, the status806 (e.g., success, fail, confirmed, unconfirmed, pending, etc.),customer name808,reservation name810,start date812,end date814, orhub specification816. In this embodiment, thereservation name810 corresponds to the reservation name designated in reservation name field608 (FIG. 6). The reservation number804 can be selected by the user. For example, the reservation number804 may be embodied in a selectable hyperlink. When the user clicks on (e.g., selects with a mouse pointer,818), a reservation request confirmation is generated.
• In one embodiment, illustrated inFIG. 9, thereservation request confirmation902 is presented in a popup window within thereservation status tab802. Thereservation confirmation902 presents numerous details about the reservation request, such as, but not limited to, customer name, reservation name, confirmation number, purchase order number, start date, start time, end date, end time, contact information (e.g., phone number, fax number name), service type, product, event, bandwidth, origination location, and destination location (if any). In one embodiment, when the user clicks on the reservation number804, theconfirmation902 including reservation details is sent to the user through some delivery means, such as regular mail, electronic mail, or text messaging.
• FIG. 10 illustrates auser interface1000 through which publication reservations can be searched. Theuser interface1000 includes asearch tab1002 through which a user can enter one or more publication reservation criteria. Previously scheduled publications are searched to find publications that correspond to the publication criteria entered by the user in thesearch tab1002. For example, the user can enter a time frame by entering a “from” date and a “to” date. The from date is entered in a “from”date field1004 and the to date is entered in a “to”date field1006.
• In the illustrated embodiment ofFIG. 10, the user can enter a reservation ID in areservation ID field1008. The user may select a reservation status using areservation status field1010. The user may also select a site using areservation site field1012. In the case ofID field1008status field1010, andsite field1012, the default condition is “ALL”, meaning a reservation matches the search criteria, regardless of reservation ID, status, and site, if other criteria match. In the illustrated embodiment, acompanies field1014 is used to specify company search criteria.
• When the user has entered the publication reservation search criteria, the user can select a submitbutton1016 to submit the search criteria and begin the search for publication reservations that match the search criteria. By selecting areset button1018, the user can reset (e.g., clear) all search criteria fields. After clicking on the submitbutton1016, publication reservations that are found that meet the entered criteria are presented to the user.
• An embodiment of a publication reservationsearch results summary1102 is shown inFIG. 11. In general, the publicationreservation search results1102 list publication reservations that match the one or more search criteria entered (or defaulted to) on thesearch tab1002 ofFIG. 10. Through the interface ofFIG. 11, the user can subscribe to publication reservations that are presented among the one or more search results. By selecting (e.g., clicking on) aback button1104, the user can go back to the searchcriteria specification tab1002 ofFIG. 10 to change search criteria.
• With further regard to the search results, in one embodiment, search results are presented in the form of a table1102. In the illustrated embodiment, the search results table1102 includes customer name (or name abbreviation)1106,reservation ID1108,reservation name1110,reservation status1112, starttime1114,end time1116, andorigin location1118 for each publication reservation found in the search. In addition, adestination button1120 and/or asubscribe button1122 can also be presented for each publication reservation.
• In an embodiment, by selecting adestination button1120, the user can view existing subscription reservations associated with the related publication reservation. When thedestination button1120 is selected, another tab or window (not shown) is presented that lists the destinations (e.g., locations and circuits) to which the publication will be transmitted. Other destination parameters may also be shown.
• In an embodiment, by selecting asubscribe button1122, the user can enter subscription request parameters to subscribe to the associated publication. In this embodiment, when the user selects asubscribe button1122, an order detail tab (e.g.,order detail tab601 or from/to tab640) or related subscription parameter entry window is presented. The user can then specify subscription request parameters. After the user has entered subscription parameters, a scheduling application attempts to schedule resources for routing the requested subscription (e.g., video feed) based on time parameters and other specified parameters (e.g., bandwidth).
• FIG. 12 is a flow chart illustrating anexample algorithm1200 for carrying out data feed resource reservation according to an embodiment. The steps shown inFIG. 12 may be carried out by a video feed subscription system such as the system shown inFIG. 4, or a similarly configured system. The order of operations in thealgorithm1200 may be altered from the order shown inFIG. 12, depending on the particular implementation. In addition, depending on the implementation, one or more steps may be optional. For example, althoughFIG. 12 shows an operation for receiving a publishing request and scheduling the publishing request, these steps need not be performed in thealgorithm1200. Rather, steps related to handling publishing requests may be performed, for example, in a different process and/or by a separate system.
• Turning now to the details of thealgorithm1200, a receivingoperation1202 receives a publish request. The publish request may take the form shown inFIG. 5, described above. Alternatively, the publish request may take a different form. Generally, the publish request is a request to make a data feed, such as a video feed, available for publication at or within some specified time (e.g., a time frame). The publish request specifies other parameters of the publication, such as, but not limited to, bandwidth, resources (e.g., origination circuit) to be used, publication start and end time, public/private port, location of publication or a zone of publication.
• Ascheduling operation1204 schedules the data feed publication requested in requestingoperation1202 if resources are available for publishing the data feed. An embodiment of thescheduling operation1204 determines whether resources are available. For example, thescheduling operation1204 may determine whether one or more ports are available on data transmission equipment located at one or more sites. In this and/or other embodiments, thescheduling operation1204 progresses through a prioritized scheme, in which sites in higher priority zones are checked first for resources.
• In at least one embodiment, thescheduling operation1204 selects ports of data transmission equipment based on the bandwidth required for transmission. In this and/or other embodiments, thescheduling operation1204 selects one or more ports based on whether the ports are designated as public or private and/or whether the publication request specifies a public or private port.
• In one embodiment of thescheduling operation1204, the user can specify the origin and destination circuits that the public/private port designation comes into play. Certain public and/or private ports may be available for the user to select from, while other ports may not be available, depending on whether the user has permission to subscribe to those ports. The user is only enabled to select from ports that are available to the user. For example, if user A at customer A isn't granted the ability to book to a private port for customer B, then user A at Customer A will not be provided the option to select customer B's private circuit/port in the GUI to request that as an origin or destination.
• Another receivingoperation1206 receives a subscription request. The subscription request specifies a scheduled publication. In some embodiments, the subscription request is in the form shown inFIG. 5 and described above, although other forms of the subscription request may be used. In some embodiments, the subscription request includes one or more parameters, including, but not limited to, a specified publication, bandwidth, origination circuit, one or more destination circuits, and one or more respective start and end times.
• Anotherscheduling operation1208 schedules the subscription request if sufficient resources are available. In one embodiment, thescheduling operation1208 first validates the subscription request. Validating the subscription request typically involves determining if the format and parameters of the subscription request are proper. For example, the one or more start and end times may be validated to ensure that they fall within the start and end time of the specified publication to which the subscription request is subscribing.
• With further regard toscheduling operation1208, in one embodiment, resource assignments begin at the termination point of the publish request. The scheduling system keeps track of where the publication terminates (on which Core Replicator device). In this embodiment the requested publication is then routed and confirmed before any subscriptions to the publication are confirmed.
• In an embodiment of thescheduling operation1208, if the subscription request is valid, thescheduling operation1208 determines if sufficient resources are available to transmit the specified published data feed according to parameters of the subscription request. In an embodiment, thescheduling operation1208 performs time-based routing of data feed. Time-based routing involves reserving resources for delivery of the data feed prior to delivery of the data feed. For example, a particular amount of bandwidth can be reserved on particular port. Reserving the bandwidth or other resource can involve specifying the amount of reserved bandwidth on a port in memory (e.g.,port412, bandwidth414 (FIG. 4)).
• An embodiment of thescheduling operation1208 iterates through each of one or more specified destination circuits and respective start and end times, checking whether one or more ports on data transmission devices have sufficient available bandwidth at the specified times to transmit the data feed. This may involve checking a schedule (e.g., schedule416 (FIG. 4)) of prior port reservations to determine how much bandwidth has been reserved on the ports of the specified destination circuit(s) at the specified time(s). A particular amount of bandwidth that is available may be reserved. As such, port or circuit bandwidth can be allocated on a time basis.
• In one embodiment, if thescheduling operation1208 determines that the subscription request is valid and sufficient resources are available, the available resources are reserved. If resources are not available for a subscription request, or for a portion of a subscription request, a notification is sent that indicates the inability to reserve resources for the subscription request or the portion of the subscription request. For example, if the subscription request specifies eight destination circuits with eight respective start and end times, and resources are available for only seven of the eight destinations at the specified times, a message is sent indicating that the eighth request cannot be satisfied. In this example, confirmations are sent confirming that the first seven requested subscriptions have been reserved. Accordingly, embodiments allow for partial subscription confirmation, wherein if one part of a subscription request cannot be satisfied, other parts of the subscription request are not denied for which resources are available.
• A configuringoperation1210 configures the scheduled publication resources that were reserved inscheduling operations1204 so that the reserved resources publish the data feed(s) at the scheduled time(s). Anotherconfiguration operation1212 configures subscription resources that were reserved inscheduling operation1208 so that the scheduled resources will transmit and receive the published data feed(s) at the scheduled time(s). In some embodiments, the configuringoperation1210 and configuringoperation1212 provision the data feed transmission and reception devices at the origination and one or more destinations to transmit and receive, respectively, the published data feed.
• A releasingoperation1214 releases the reserved subscription resources after transmission and reception of the published data feed. Another releasingoperation1216 releases the reserved publication resources after transmission of the published data feed. In some embodiments, the releasingoperations1214 and1216 each occur as a step for each publication/subscription process. In another embodiment, the releasingoperations1214 and1216 each occur as a periodic batch operation in which the resource reservation schedule is periodically reviewed and reservations older than the current time are removed from the schedule.
• FIG. 13 is a schematic diagram of acomputer system1300 upon which embodiments of the present invention may be implemented and carried out. For example, one ormore computing devices1300 may be configured to schedule subscription and reservation requests and reserve available resources to deliver data feeds based on the requests.Computer system1300 generally exemplifies any number of computing devices, including general purpose computers (e.g., desktop, laptop or server computers) or specific purpose computers (e.g., embedded systems).
• According to the present example, thecomputer system1300 includes a bus1301 (i.e., interconnect), at least oneprocessor1302, at least onecommunications port1303, amain memory1304, aremovable storage media1305, a read-only memory1306, and amass storage1307. Processor(s)1302 can be any known processor, such as, but not limited to, an Intel® Itanium® orItanium 2® processor(s), AMD® Opteron® or Athlon MP® processor(s), or Motorola® lines of processors.
• Communications ports1303 can be any of an RS-232 port for use with a modem based dial-up connection, a 10/100 Ethernet port, a Gigabit port using copper or fiber, or a USB port. Communications port(s)1303 may be chosen depending on a network such as a Local Area Network (LAN), a Wide Area Network (WAN), or any network to which thecomputer system1300 connects. Thecomputer system1300 may be in communication with peripheral devices (e.g.,display screen1330, input device1316) via Input/Output (I/O)port1309.
• Main memory1304 can be Random Access Memory (RAM), or any other dynamic storage device(s) commonly known in the art. Read-onlymemory1306 can be any static storage device(s) such as Programmable Read-Only Memory (PROM) chips for storing static information such as instructions forprocessor1302.Mass storage1307 can be used to store information and instructions. For example, hard disks such as the Adaptec® family of Small Computer Serial Interface (SCSI) drives, an optical disc, an array of disks such as Redundant Array of Independent Disks (RAID), such as the Adaptec® family of RAID drives, or any other mass storage devices may be used.
• Bus1301 communicatively couples processor(s)1302 with the other memory, storage and communications blocks. Bus1301 can be a PCI/PCI-X, SCSI, or Universal Serial Bus (USB) based system bus (or other) depending on the storage devices used.Removable storage media1305 can be any kind of external hard-drives, floppy drives, IOMEGA® Zip Drives, Compact Disc-Read Only Memory (CD-ROM), Compact Disc-Re-Writable (CD-RW), Digital Video Disk-Read Only Memory (DVD-ROM), etc.
• Embodiments herein may be provided as a computer program product, which may include a machine-readable medium having stored thereon instructions, which may be used to program a computer (or other electronic devices) to perform a process. The machine-readable medium may include, but is not limited to, floppy diskettes, optical discs, CD-ROMs, magneto-optical disks, ROMs, RAMs, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions. Moreover, embodiments herein may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., modem or network connection).
• As shown,main memory1304 is encoded with a data feed resource reservation application1350-1 that supports functionality as discussed herein. For example, data feed resource reservation application1350-1 can include thereservations interface402, thescheduler408 and/or theconfiguration module424 ofFIG. 4. Data feed resource reservation application1350-1 (and/or other resources as described herein) can be embodied as software code such as data and/or logic instructions (e.g., code stored in the memory or on another computer readable medium such as a disk) that supports processing functionality according to different embodiments described herein.
• During operation of one embodiment, processor(s)1302 accessesmain memory1304 via the use of bus1301 in order to launch, run, execute, interpret or otherwise perform the logic instructions of the data feed resource reservation application1350-1. Execution of data feed resource reservation application1350-1 produces processing functionality in data feed resource reservation process1350-2. In other words, the data feed resource reservation process1350-2 represents one or more portions of the data feed resource reservation application1350-1 performing within or upon the processor(s)1302 in thecomputer system1300.
• It should be noted that, in addition to the data feed resource reservation process1350-2 that carries out operations as discussed herein, other embodiments herein include the data feed resource reservation application1350-1 itself (i.e., the un-executed or non-performing logic instructions and/or data). The data feed resource reservation application1350-1 may be stored on a computer readable medium (e.g., a repository) such as a floppy disk, hard disk or in an optical medium. According to other embodiments, the data feed resource reservation application1350-1 can also be stored in a memory type system such as in firmware, read only memory (ROM), or, as in this example, as executable code within the main memory1304 (e.g., within Random Access Memory or RAM). For example, data feed resource reservation application1350-1 may also be stored inremovable storage media1305, read-only memory1306, and/ormass storage device1307.
• Example functionality supported bycomputer system1300 and, more particularly, functionality associated with data feed resource reservation application1350-1 and data feed resource reservation process1350-2 is discussed above in detail with reference toFIGS. 1-12.
• In addition to these embodiments, it should also be noted that other embodiments herein include the execution of the data feed resource reservation application1350-1 in processor(s)1302 as the data feed resource reservation process1350-2. Thus, those skilled in the art will understand that thecomputer system1300 can include other processes and/or software and hardware components, such as an operating system that controls allocation and use of hardware resources.
• In another embodiment, the reservations interface402 (FIG. 4) is hosted on one or more Windows™ Virtual Machines (VMs), thescheduler410 executes on one or more Unix Solaris™ 10 servers, theconfiguration modules424 run on Hewlett Packard™ servers running the Hewlett Packard Unix operating system, and the databases run on one or more Unix Solaris 10™ servers.
• As discussed herein, embodiments of the present invention include various steps or operations. A variety of these steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the operations. Alternatively, the steps may be performed by a combination of hardware, software, and/or firmware. The term “module” refers to a self-contained functional component, which can include hardware, software, firmware or any combination thereof.
• Various modifications and additions can be made to the example embodiments discussed herein without departing from the scope of the present invention. For example, while the embodiments described above refer to particular features, the scope of this invention also includes embodiments having different combinations of features and embodiments that do not include all of the described features. Accordingly, the scope of the present invention is intended to embrace all such alternatives, modifications, and variations together with all equivalents thereof.

Claims (20)

1. A method of managing delivery of a video feed over a terrestrial network, the method comprising:

receiving a subscription request specifying one or more destination sites to receive the video feed and respective times at which to deliver the video feed to each of the one or more destination sites, wherein respective delivery times are within a publication time range in which the video feed will be available; and

configuring available resources to deliver the requested video feed to the one or more destination sites at the respective times.

2. The method ofclaim 1, further comprising receiving a publication request specifying the publication time range.

3. The method ofclaim 1, further comprising identifying one or more available resources that are available at the respective delivery times.

4. The method ofclaim 1, wherein configuring available resources comprises reserving one or more ports of a replicator to deliver the requested video feed at the respective delivery times.

5. The method ofclaim 1, further comprising determining whether there is sufficient bandwidth on one or more ports of a video feed delivery device to deliver the requested video feed at each of the one or more delivery times.

6. The method ofclaim 5, further comprising sending a rejection message if there is insufficient bandwidth available to deliver the requested video feed at a requested delivery time.

7. The method ofclaim 6, further comprising sending a reservation confirmation message confirming that resources are available to deliver the requested video feed if sufficient bandwidth is available.

8. The method ofclaim 1, further comprising de-allocating the available resources after delivery of the requested video feed.

9. The method ofclaim 1, wherein configuring available resources comprises determining if resources are available to deliver the requested video feed at each of the one or more delivery times, and if resources are not available to deliver the requested video feed to one of the one or more destination sites, and resources are available to deliver the video feed to the other one or more destination sites, configuring only the available resources to deliver the video feed to the other destination sites at the respective delivery times.

10. A system for managing delivery of video feeds over a terrestrial network, the system comprising:

a resource scheduler operable to reserve available resources at one or more requested times for delivering a video feed to respective one or more requested destinations; and

a configuration module operable to configure the available resources for delivering the video feed to one or more destinations at the respective times at which resources are available.

11. The system ofclaim 10, wherein the resource scheduler is further operable to release available resources after the one or more requested delivery times.

12. The system ofclaim 10, wherein the resource scheduler is further operable to receive a publication request specifying a publication time window in which the video feed will be available for delivery.

13. The system ofclaim 12, wherein the resource is further operable to receive a subscription request specifying one or more requested delivery times and respective one or more destinations.

14. The system ofclaim 13, wherein the resource scheduler is further operable to determine whether each of the one or more requested delivery times are within the publication time window.

15. The system ofclaim 13, wherein the resource scheduler is operable to determine whether sufficient resources are available at an origination location and each of the one or more destinations at the respective delivery times.

16. The system ofclaim 13, wherein the resource scheduler is further operable to choose a destination location from among a plurality of destination locations to which the video feed can be delivered.

17. The system ofclaim 16, wherein the resource scheduler chooses the destination location based on zones of locations.

18. The system ofclaim 13, wherein the resource scheduler provides an online interface for subscribing to video feeds to be published.

19. The system ofclaim 18, wherein the online interface presents video feeds that will be published and wherein the online interface receives subscriptions to one or more selected video feeds.

20. A computer implemented method for managing delivery of a data feed over a terrestrial network, the method comprising:

receiving a publication request specifying a publication time frame within which the data feed will be available for publication;

receiving a subscription request to subscribe to the data feed, the subscription request specifying a destination to receive the data feed and an associated delivery time to deliver the data feed at the destination;

reserving available bandwidth at the specified delivery time if the specified delivery time is within the publication time frame; and

denying the subscription request if the specified delivery time is outside the publication time.

Images