KR101193098B1 - A method and system for allocating receiving resources in a gateway server - Google Patents

Abstract

The disclosed embodiment is directed to a method and apparatus for allocating resources in an efficient manner within a gateway service device. The apparatus comprises a gateway server or head end units 14a, 14b connected to a plurality of end user terminals 22a-22n. Gateway servers 14a and 14b include a controller 70 for managing allocation of received resources used to provide services to end user terminals 22a-22n. The method includes receiving 304 a service request, comparing the request to a service that is already in use 308, and if a match is found, finalizes the updated data stream containing new information about the service. Providing 314 to user terminals 22a-22n.

Description

A METHOD AND SYSTEM FOR ALLOCATING RECEIVING RESOURCES IN A GATEWAY SERVER}

This application claims the benefit of 35 U.S.C. §119 of provisional application 60 / 641,880, filed January 5, 2005 in the United States.

The present invention is directed to having a gateway server including a plurality of received resources dynamically allocate such resources to a client based on a resource conservation method.

This section is intended to introduce the reader to various aspects of the prior art, which may relate to various aspects of the present invention described below and / or claimed. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Thus, it should be understood that such sentences should be read in this respect and not as admissions of the prior art.

As most people know, satellite television systems like DirectTV have become much more widespread in the past few years. In fact, since the introduction of DirectTV in 1994, more than 12 million US homes have become satellite TV subscribers. Most of these subscribers live in single-family homes, which are relatively easy to install and connect with satellite dish antennas. For example, a satellite dish antenna may be installed on the roof of the house.

However, many potential subscribers live or temporarily live in multi-dwelling units ("MDUs"), such as hotels or high-rise apartment buildings. Unfortunately, there are additional challenges involved in providing satellite TV service to individual generation units within the MDU. Providing and connecting one satellite dish antenna per generation can be unrealistic and / or very expensive. For example, in a high-rise apartment building with 1,000 apartments, it may be impractical to mount 1,000 satellite dish antennas on the roof of the building. Some of the prior art systems have avoided this problem by converting digital satellite television signals into analog signals that can be transmitted to multiple generations over a single coaxial cable. However, these systems offer limited channels, degrade quality compared to all-digital systems, and cannot provide a familiar satellite TV experience for users living in single-family homes.

Directly distributing services such as satellite signals to individual residential places within the MDU can provide a similar experience as in single-family homes, but can also be difficult. For example, the distribution of satellite signals from dish antennas requires special distribution devices and wiring that are often not found in MDU residential facilities. The cost to retrofit this residential facility can be high.

It is also possible to create a system that allows each residential unit to receive a service using dedicated resources for receiving signals, where such resources are located remotely. For example, the main tuning function may be located in the central control room, and a unique signal or service may be sent to each living unit. This connection can be made using Ethernet or coaxial cable, which can be distributed throughout the building. In general, for a system for distributing video content, each end user should have a dedicated tuning and decoding circuit for that system. This can be costly and inefficient, especially for large MDU establishments.

Therefore, it is desirable to develop a system that can limit the number of circuits used as receive resources that may exist within a central location. In addition, a solution for managing tuning resources that allows the use of the minimum number of tuning resources in the system to maximize operational performance and provide the lowest cost is desirable.

The disclosed embodiment is directed to a method and apparatus for allocating received resources. The apparatus includes a head-end or gateway server unit that receives a plurality of signals and outputs a series of data streams provided to a plurality of STBs located in a facility such as an MDU. The apparatus further includes a set of receiving resources within the head-end unit, with a receiver for receiving the request signal and a controller for processing the request signal and managing the use of the receiving resource. The method includes a process for allocating received resources used by the head end unit to provide the service requested by the STB. The method comprises the steps of receiving a request signal for a service from an STB, comparing this request for one service with a service already provided, and if a match is found between the newly requested service and the currently provided service, Establishing a shared use of one of the receiving resources already providing the requested service.

Advantages of the present invention may become more apparent upon reading the following detailed description and referring to the drawings below.

1 is a block diagram of an exemplary satellite television on the IP system of the present invention.

2 is another embodiment of an exemplary satellite television on the IP system illustrated in FIG.

3 is a block diagram of an exemplary satellite gateway of the present invention.

4 is a flow diagram of an exemplary method for allocating a receiving resource, such as a tuner, in a satellite gateway of the present invention.

The features and advantages of the present invention will become more apparent from the following description given by way of example.

One or more specific embodiments of the invention will be described below. In an effort to provide a brief description of these embodiments, not all features of an actual implementation are described herein. In the development of any such actual implementation, as in any engineering or design project, the developer achieves specific goals, such as compliance with system-related and business-related constraints, which may vary from implementation to implementation. A number of implementation-specific decisions must be made to accomplish this. In addition, while such development efforts may be complex and time consuming, it should nevertheless be appreciated that it is an ever-presenter of design, fabrication, and manufacturing to those skilled in the art having the benefit of this disclosure.

First, referring to FIG. 1, a block diagram of an exemplary satellite television on an IP system, according to one embodiment, is described and generally designated by reference numeral 10. As described, the system 10 serves as an end user device with one or more satellite dish antennas 12a through 12m, a head-end unit or gateway server such as satellite gateway 14, IP distribution network 20, and the like. It may include one or more set top boxes (“STBs”) 22a through 22n. However, those skilled in the art will recognize that the embodiment of the system 10 described in FIG. 1 is only one potential embodiment of the system 10. As such, in alternative embodiments, the described components of system 10 may be rearranged or omitted, or additional components may be added to system 10. For example, via mirror modification, system 10 may be configured to distribute non-satellite video and audio services.

Satellite dish antennas 12a-12m may be configured to receive video, audio, or other types of television-related data transmitted from satellites orbiting the earth. As described further below, in one embodiment, satellite dish antennas 12a-12m are configured to receive DirecTV programming on the KU band from 10.7 to 12.75 gigahertz (“GHz”). However, in an alternative embodiment, the satellite dish antennas 12a-12m may be other types of direct broadcast satellites ("DBS") or television receive-only: dish antenna network signals, ExpressVu signals, StarChoice signals, or the like. "TVRO") signal. In another non-satellite based system, satellite dish antennas 12a-12m may be omitted from system 10.

In one embodiment, the low noise-to-block converter (“LNC”) within the satellite dish antennas 12a-12m receives input signals from satellites orbiting the earth and converts the input signals to 950 and 2150 MHz (“MHz”). Convert to a frequency in the L band between "). As described in more detail below with respect to FIG. 2, each of the satellite dish antennas 12a-12m receives one or more input satellite TV signals with special polarizations on a particular frequency (referred to as transponders) to receive these satellite signals. Can be configured to convert to L band signals or transport streams, and each L band signal or transport stream itself represents a transport stream for one program, often referred to as a single program transport stream (SPTS). Or may refer to multiple transport streams multiplexed together, referred to as multiple program transport streams (MPTS). Each program stream can then represent an audio and / or video signal. Additionally, each one of the SPTSs may be used to distinguish other streams contained within the MPTS, and may also include the form of an identifier, such as a program identifier (PID) that may be used with the SPTS.

The satellite dish antennas 12a-12m may be configured to transmit L band signals to a head-end unit or gateway server, such as satellite gateway 14. In alternative non-satellite embodiments, the head-end unit may be a cable television receiver, a high definition television receiver or other video distribution system.

The satellite gateway 14 includes a satellite tuning, demodulation and demultiplexing module 16 and an internet protocol (IP) wrapper module 18. Module 16 includes a plurality of receive resources, which may include tuners, demodulators, and demultiplexers for converting the modulated and multiplexed L-band signals transmitted from satellites 12a-12m into a plurality of data streams ("SPTS"). Wherein each of the plurality of data streams carries a service (eg, television channel video, television channel audio, program guide, etc.). In one embodiment, module 16 is configured to receive a particular L-band signal from a larger group of L-band signals received by satellite dish antennas 12a-12m. Module 16 then processes this signal to create a new single program transport stream for all services received by this module 16. However, in an alternative embodiment, module 16 may generate a transport stream only for all services or subsets of those services received by satellite dish antennas 12a-12m.

Although the received resources described herein include circuits such as tuners, demodulators, and demultiplexers that perform tuning, demodulation and demultiplexing functions, these received resources may be separated or processed by other means, including digital means. Function may also be involved, or may involve processing a signal received in another time slot or on a separate input cabling. Any of these functions may be performed by module 16.

The satellite tuning, demodulation and demultiplexing module 16 may send the SPTS to the IP wrapper module 18. In one embodiment, the IP wrapper module 18 repackets the data in the SPTS into a plurality of Internet Protocol (IP) packets suitable for transmission on the IP distribution network 20. For example, IP wrapper module 18 may convert DirecTV protocol packets in the SPTS into IP packets. IP wrapper module 18 also receives server requests from STBs 22a-22n and multicasts IP SPTS to the STBs 22a-22n that requested this particular service (i.e. one or more on the IP address). Broadcast to STBs 22a-22n.

In alternative embodiments, IP wrapper module 18 may also be configured to multicast IP SPTS for services not requested by one of STBs 22a-22n. For example, a particular receiving resource produces the output of five SPTSs, and only one of these SPTSs is actually requested. However, an additional one of the SPTSs is multicast IP for reasons related to the need to provide this particular service. It should be noted that modules 16 and 18 are just one exemplary embodiment of satellite gateway 14. In alternative embodiments as described below with respect to FIGS. 2 and 3, the functionality of modules 16 and 18 may be redistributed or integrated between various suitable components or modules.

The IP distribution network 20 may include one or more routers, switches, modems, splitters, or bridges. For example, in one embodiment, the satellite gateway 14 may be connected to a master distribution frame (“MDF”), the MDF is connected to an intermediate distribution frame (“IDF”), and the IDF is coaxially connected to an Ethernet bridge. Connected to the cable, the Ethernet bridge is connected to a router connected to one or more STBs 22a-22n. In another embodiment, IP distribution network 20 may be an MDF connected to a digital subscriber line access multiplexer ("DSLAM"), which is connected to a DSL modem connected to a router. In another embodiment, the IP distribution network may comprise a wireless network, such as an 802.11 or WiMax network. In this type of embodiment, the STBs 22a-22n may include a wireless receiver configured to receive multicasted IP packets. Those skilled in the art will recognize that the embodiments described above are merely illustrative. As in alternative embodiments, many suitable forms of IP distribution networks may be used in the system 10.

The IP distribution network 20 may be connected to one or more STBs 22a-22n. The STBs 22a-22n may be any suitable type of video, audio, and / or other data receiver capable of receiving IP packets such as IP SPTS on the IP distribution network 20. It will be appreciated that the term "STB" as used herein does not include only devices that can be placed on a television. Rather, the STBs 22a-22n are any device or apparatus that acts as an end user device in dwelling, internal or external to a television, display, or computer, which may be configured to function as described herein. Such a device or apparatus may include, but is not limited to, a video component, a computer, a wireless telephone, or other form of video recorder. In one embodiment, the STBs 22a-22n may be DirecTV receivers configured to receive services, such as video and / or audio, over Ethernet ports (among other inputs). In alternative embodiments, the STBs 22a-22n may be coaxial cable, twisted pair, copper conductors, or I.E.E.E. It may be designed and / or configured to receive transmissions that are multicast wirelessly over a wireless standard such as the 802.11 standard.

As discussed above, system 10 may receive video, audio and / or other data sent to satellites in space and process / transform such data for distribution on IP distribution network 20. have. Referring now to FIG. 2, another embodiment of an exemplary satellite television on IP system 10 is shown. Each of the satellite dish antennas 12a-12c may be configured to receive signals from one or more satellites that orbit. Those skilled in the art will appreciate that satellites and signals transmitted from satellites are often referenced by orbital slots in which the satellites are located. For example, satellite dish antenna 12a is configured to receive signals from DirecTV satellites arranged in 101 degree orbit slots. Similarly, satellite dish antenna 12b receives signals from satellites arranged at 119 degrees, and satellite dish antenna 12c receives signals from satellites arranged in orbit slots of 110 degrees. In alternative embodiments, satellite dish antennas 12a-12c may receive signals from a plurality of other satellites represented in various orbital slots, such as 95 degree orbital slots. In addition, satellite dish antennas 12a-12c may be configured to receive satellite signals with polarization. For example, the satellite dish antenna 12a is configured to receive a signal polarized to the left (indicated by " 101L " in FIG. 2) and also polarized to the right (indicated by " 101R ").

As described above with respect to FIG. 1, satellite dish antennas 12a-12c may receive satellite signals in the KU band and convert them into L band signals transmitted to satellite gateway 14. However, in some embodiments, the L band signal generated by the satellite dish antennas 12a-12c may be merged into fewer signals or split into more signals before reaching the satellite gateway 14. . For example, as illustrated in FIG. 2, the L-band signal from satellite dish antennas 12b and 12c is left polarized from the transport stream from the satellite at 110 degrees and from the satellite at 119 degrees. can be incorporated by switch 24 into a single L band signal comprising a stream.

System 10 may include a plurality of 1: 2 dividers 26a, 26b, 26c and 26d to split the L band signal transmitted from satellite dish antennas 12a-12c into two L band signals, Each of the two L band signals includes half of the services of the pre-segmented transport stream. In alternative embodiments, the 1: 2 dividers 26a-26b may be omitted or integrated into the satellite gateways 14a and 14b.

The newly divided L band signal may be transmitted from the 1: 2 dividers 26a-26d to the satellite gateways 14a and 14b. The embodiment of the system 10 described in FIG. 2 includes two satellite gateways 14a and 14b. However, in alternative embodiments, system 10 may include any suitable number of satellite gateways 14. For example, in one embodiment, the system may include three satellite gateways 14.

The satellite gateways 14a and 14b can then further subdivide the L-band signal and use receive resources to tune to one or more services on the L-band signal to generate one or more SPTSs, which are IP packets. Can be repackaged and multicast on the IP distribution network 20. In addition, one or more satellite gateways 14a, 14b may also be connected to a public switched telephone network (“PSTN”) 28. The satellite gateways 14a and 14b are connected to the PSTN 28, and the STBs 22a-22n can communicate with the satellite service provider via the IP distribution network 20 and the satellite gateways 14a and 14b. This function can advantageously eliminate the need to have each individual STB 22a-22n connected directly to the PSTN 28.

IP distribution network 20 may also be connected to an Internet service provider (“ISP”) 30. In one embodiment, IP distribution network 20 is used to provide Internet services, such as high speed data access, to STBs 22a-22n and / or other suitable devices (not shown) connected to IP distribution network 20. Can be.

As described above, the satellite gateways 14a and 14b may be configured to receive a plurality of L-band signals to generate a plurality of SPTSs and to multicast the requested SPTS on the IP distribution network 20. Referring now to FIG. 3, shown is a block diagram of an example satellite gateway 14. As described, the satellite gateways 14a and 14b include a power supply 40, two front ends 41a and 41b and a rear end 52. The power source 40 can be any one of a number of industry-standard AC or DC power sources that can be configured to allow the front end 41a, 41b and the rear end 52 to perform the functions described below. .

The satellite gateways 14a and 14b may also include two front ends 41a and 41b. In one embodiment, each front end 41a, 41b may be configured to receive two L band signal inputs from the 1: 2 dividers 26a-26d described above with respect to FIG. 2. For example, the front end 41a may receive two L-band signals from the 1: 2 divider 26a, and the front end 41b may receive two L-band signals from the 1: 2 divider 26b. can do. In one embodiment, each of the L band inputs to the front ends 41a, 41b includes up to eight services.

The front end portions 41a and 41b can then further subdivide the L band input using 1: 4 L band dividers 42a, 42b, 42c and 42d. Once subdivided, the L band signal can be delivered to four banks 44a, 44b, 44c and 44d of the dual tuner link. Each of the dual tuner links in banks 44a-44d may be configured to tune to two services in the L band signal received by that respective dual tuner link to produce an SPTS. Each of the dual tuner links may then send the SPTS to one of the low voltage differential signal (“LVDS”) drivers 48a, 48b, 48c, and 48d. The LVDS drivers 48a-48d can be configured to amplify the L band transport band signal for transmission to the back end 52. In alternative embodiments, other types of differential drivers and / or amplifiers may be used in place of the LVDS drivers 48a-48d. Other embodiments may use serialization together to direct all transport signals to the back end 52.

As described, the front end portions 41a and 41b may include microprocessors 46a and 46b. In one embodiment, the microprocessors 46a and 46b may control the banks 44a-44d and the 1: 4 L band dividers 42a-42d of the dual tuning link and / or relay the commands. Microprocessors 46a and 46b may include ST10 microprocessors produced by ST Microelectronics. In other embodiments, other processors may be used, or control may be derived from the processor at the rear end 52. Microprocessors 46a and 46b may be connected to the LVDS receiver and transmitter modules 50a and 50b. The LVDS receiver / transmitter modules 50a and 50b may assist in communication between the components of the microprocessor 46a and 46b and the rear end 52, as described further below.

Turning next to the rear end 52, the rear end 52 is configured to receive transport stream signals, such as SPTS or MPTS, transmitted by the LVDS drivers 48a-48d. 54c and 54d). The rear end 52 also includes LVDS receiver / transmitter modules 56a and 56b that are configured to communicate with the LVDS receiver / transmitter modules 50a and 50b.

As described, LVDS receivers 54a-54d and LVDS receivers / transmitters 56a, 56b are configured to communicate with transport processors 58a and 58b. In one embodiment, the transport processors 58a, 58b are configured to receive the SPTS generated by the dual tuning links in the front ends 41a, 41b. For example, the transport processors 58a and 58b may be configured to generate 16 SPTSs. In general, transport processors 58a and 58b may generate N SPTSs, where N is one number that is the number of individual program streams available on input to transport processors 58a and 58b. Transport processors 58a and 58b may also be configured to repacket the SPTS into IP packets that may be multicast on IP distribution network 20. For example, transport processors 58a and 58b may repacket DirecTV protocol packets into IP protocol packets, thereby multicasting IP packets on one IP address to one or more STBs 22a-22n.

Transport processors 58a and 58b may also be connected to a bus 62, such as a 32-bit, 66 MHz peripheral component interconnect (“PCI”) bus. Via bus 62, transport processor 58a, 58b may communicate with another controller or network processor 70, Ethernet interface 68, and / or expansion slot 66. The network processor 70 may be configured to receive a request for a service from the STBs 22a-22n and direct the request to the transport processor 58a, 58b for multicasting the requested service. In addition, the network processor 70 receives requests from the STBs 22a-22n, maintains a list of currently deployed services, and matches or allocates receiving resources to provide these services to the STBs 22a-22n. It is also possible to manage the operation and distribution of these services. In one embodiment, the network processor is an IXP425 network processor produced by Intel. Although not described, the network processor 70 may also be configured to transmit status data to the front panel of the satellite gateways 14a and 14b, or to support debugging or monitoring of the satellite gateways 14a and 14b through debug ports. Can be.

As described, the transport processors 58a and 58b may also be connected to the Ethernet interface via the bus 62. In one embodiment, the Ethernet interface 68 is a Giga Ethernet interface that provides a copper wire or fiber optic interface to the IP distribution network 20. In other embodiments, other interfaces may be used, such as those used in digital home network applications. In addition, the bus 62 may also be connected to an expansion slot such as a PCI expansion slot to enable upgrade or expansion of the satellite gateways 14a and 14b.

Transport processors 58a and 58b may also be coupled to host bus 64. In one embodiment, host bus 64 is a 16-bit data bus that connects transport processors 58a and 58b to modem 72, which may be configured for communication on PSTN 28, as described above. to be. In alternative embodiments, modem 72 may also be connected to bus 62.

The network processor 70 may also include a memory for storing information about various aspects of the operation of the gateways 14a and 14b. The memory may reside within the network processor 70 or may be externally located, although not shown. The memory can be used to store state information as well as tuning information for the received resource. In addition, the memory can store information about which services each receiving resource can provide, and can also be used to maintain a list of services currently being provided to STBs 22a-22n.

Those skilled in the art will appreciate that the transport processor 58a, 58b, the network processor 70, and the microprocessors 46a, 46b may be one larger than one capable of performing any of the control functions required for the operation of the gateways 14a, 14b. It will be appreciated that it may be included within a controller or processing unit. Some or all of the control functions may also be distributed to other blocks and may not affect the main operation within gateways 14a and 14b.

Transport processors 58a and 58b can also manage the processing of transport streams from received resources. In one embodiment, the transport processor 58a, 58b may take each one of the provided SPTSs from a given received resource and generate one IP multicasted stream that includes all the SPTSs together. In another embodiment, the processor may take only the SPTS requested by the STBs 22a-22n to generate a separate IP multicast stream for each one of the SPTSs. It may also be possible to use a combination of both approaches. In combination, the network processor 70 may also maintain a list of all services provided for each of the resources currently in use, whether or not these services are actually currently being requested. In addition, the transport processors 58a and 58b may also include memory for providing storage of information such as a list of services and receiving resources.

As described above, the satellite gateways 14a and 14b may multicast services to the STBs 22a-22n on the IP distribution network 20. When an IP packet constituting a service reaches one of the STBs 22a-22n, the Ethernet integrated circuit ("IC") in the STBs 22a-22n is configured by the STB 22a-22n for this service (e.g., To decode the IP packet. However, these Ethernet ICs can only support a special number of asynchronous data streams. The video, audio, or other service described above is an example of an asynchronous stream.

As described above, the Ethernet ICs in the STBs 22a-22n can be designed to handle only a certain number of asynchronous streams at any given time. Accordingly, asynchronous streams exceeding the capacity of the Ethernet IC may be discarded or lost. For example, if the Ethernet IC in one of the STBs 22a-22n has the capacity to handle four asynchronous streams at a given time, the fifth asynchronous stream may be excluded. If this fifth asynchronous stream is multicast carrying a video service, the display of the STB of this video service can be stopped. For this reason, it is desirable to minimize the number of asynchronous streams in the system 10.

Referring now to FIG. 4, shown is a method 300 for allocating resources from a gateway device to provide services to an STB. While performing other tasks related to the operation of the gateway 14, the network processor 70 waits for a request initiated by one or more STBs 22a-22n in step 302. In step 304, the service request has been received at the network processor 70, and in step 306, the service request is processed by the network processor 70. The output of the processing in step 306 is a set of information that may include the parameters needed to tune the correct channel to service the STBs 22a-22n. In step 308, a first comparison is performed to determine if the currently requested parameter is already assigned and matches the parameter being used for the service in progress. This parameter may include, for example, tuning information for receiving a service from the satellite system via a receiving resource. This comparison may involve comparing the services currently provided to the STB, or comparing a list of all available services based on the L band transport signals currently tuned by the receiving resource. If the comparison provides a match that yields a yes answer, then at step 314, the current request of the STBs 22a-22n is added to the list of services provided by the selected channel. In step 316, the network processor 70 provides a message to be sent back to the service requesting STBs 22a-22n, which indicates that the request was successful.

In one embodiment, network processor 70 provides a message by utilizing the capability in real-time streaming protocol (RTSP) used with multicast IP data. The processor 70 modifies the data stream using a notification message to the STB 22a-22n that the STB 22a-22n should begin accepting packets associated with a particular multicast IP stream containing the requested service. do. Using RTSP and multicast IP represents only one possible way for notification and modification of the data stream that the server provides to the STBs 22a-22n. In another embodiment, after the network processor 70 determines that there is a match for a particular parameter for a service, such as a required received resource, the network processor 70 may determine that the requested service being received by the received resource is currently provided. Can be further compared with. If the service is a match, the network processor 70 may continue the notification via some means, such as RTSP, as previously described. If the service does not match, the network processor 70 creates a new data stream for IP multicast via the transport processor 58a, 58b, and by the method previously described, the service is now available. It may be necessary to start a new service by notifying the STBs 22a-22n requesting that it is possible.

In step 308, if the comparison does not yield a match, in step 310, the processor 70 determines whether the tuner is available to accept the service request. If a tuner is available, the network processor 70 provides a control signal to this available tuner at step 312 and updates the service list with the new service and the new tuner at step 314. Then, in step 316, network processor 70 provides a message back to STBs 22a-22n.

Returning to step 310, if all tuners or receiving resources in the front end portions 41a and 41b are currently allocated to existing service requests, then in step 318, the network processor 70 determines that the service requests are all resources. It provides a message to the STBs 22a-22n indicating that it failed because of this busy. Then, in step 320, the network processor 70 enters a standby mode until a new service request is received.

Although this embodiment details a particular arrangement for using a method for allocating receiving resources with an Ethernet or similar interface, other interfaces may use a similar management method and benefit from this method. For example, in a system using a coaxial cable interface, resources and services can be managed to minimize the costs associated with expensive transmission devices because of the unnecessarily high operating bandwidth. It should be apparent to those skilled in the art that such a system that dynamically allocates receiving resources, such as tuners, is beneficial for use in a head end unit or gateway server.

While the invention is susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in greater detail herein. However, it should be understood that the invention is not intended to be limited to the particular form disclosed. Rather, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

The present invention is available for causing a gateway server including a plurality of received resources to dynamically allocate such resources to clients based on a resource conservation method.

Claims (31)

As a method 300 of allocating receiving resources in a network within multi-dwelling units: Receiving a signal comprising a plurality of services; Receiving (304) a request for service from a set top box on the network; Determining (306) a receiving resource for the requested service based on the request for a service; Comparing (308) the determined received resource with a list of a plurality of currently used received resources; Updating (314) the list of currently used received resources in response to the comparing step; And Modifying (314) a data stream relating to one of the currently used received resources when the currently used received resource matches the determined received resource. The method of claim 1, And if the determined received resource does not match one of the currently used received resources, allocating an unused received resource (310, 312). The method of claim 1, wherein the received resource comprises a receiver for receiving one particular signal from a group of signals. delete The method of claim 1, wherein the modifying step 314 is: Modifying the data stream to include an indicator of a plurality of requesters. The method of claim 1, wherein the request for a received resource is included in a request for a service. delete 2. The method of claim 1, wherein comparing 308 the determined received resource comprises comparing a parameter for tuning the determined received resource with a parameter for tuning the currently used received resource. How to assign. 9. The method of claim 8 wherein the parameter is a frequency. 2. The receiving resource of claim 1, wherein comparing 308 the determined received resource comprises comparing a parameter for tuning each of the determined received resources with a parameter for tuning each of the currently used received resources. How to assign. 11. The method of claim 10 wherein the parameter is a frequency. 2. The method of claim 1, wherein comparing (308) the determined received resource further comprises comparing a parameter of a service associated with the determined received resource with a parameter of a currently provided service. 13. The method of claim 12 wherein the parameter is a program identifier. 2. The method of claim 1, wherein comparing 308 the determined received resource further comprises comparing a parameter of each of a set of currently provided services with a parameter of a service associated with the determined received resource. How to. 15. The method of claim 14 wherein the parameter is a program identifier. 2. The method of claim 1 wherein the received resource comprises a tuner. As apparatus 14a, 14b for allocating received resources to a plurality of user devices in a network: A plurality of receiving devices 41a, 41b for receiving a plurality of first signals and outputting a plurality of signals capable of generating a data stream associated with the plurality of services; An interface 68 coupled to the plurality of receiving devices 41a, 41b, capable of delivering the data stream to a plurality of user devices in a multi-family residential facility and capable of receiving requests for services from the plurality of user devices. Interface 68; And A controller 70 coupled to an interface 68 with the plurality of receiving devices 41a, 41b, the controller 70 determining a receiving resource for the requested service based on the request for a service, In response to the comparison of the received request for the service and the list of the currently used receiving resources, the allocation of the plurality of receiving devices 41a and 41b is managed by updating the list of currently used receiving resources, and the controller 70 May also be based on receiving the request for a service from the interface 68, if the currently used receiving resource matches the determined received resource, the related to one of the currently used receiving resources. Controller 70, which modifies the data stream And allocating a received resource to a plurality of user devices in the network. 18. The receiving resource according to claim 17, wherein the plurality of receiving devices (41a, 41b) for receiving the plurality of first signals are receivers for receiving a specific signal from a group of signals. Device for allocation. 19. The apparatus of claim 18, wherein the receiver is a tuner. 18. The apparatus of claim 17, wherein the first signal is an L-band signal. 18. The apparatus of claim 17, wherein the data stream is a transport stream. 18. The apparatus of claim 17, wherein the interface (68) is a device for transmitting a data stream using an internet protocol. 18. The apparatus of claim 17, wherein the interface (68) is communicatively coupled to a plurality of end user devices. 24. The apparatus of claim 23, wherein the end user device is a set top box. delete 18. The apparatus of claim 17, wherein the controller 70 compares the parameter for tuning the request with a parameter for tuning one of the plurality of receiving devices 41a, 41b currently being used. And assign a received resource to a plurality of user devices in a network comparing the received request with a list of the plurality of currently used received resources. 18. The reception of a service according to claim 17, wherein the controller (70) compares the parameter for tuning the request with a parameter for tuning each of the plurality of receiving devices (41a, 41b) currently used. And assign a received resource to a plurality of user devices in a network, comparing the requested request with a list of the plurality of currently used received resources. The service of claim 17, wherein the controller 70 compares the parameters of the request for the service with the parameters of one of the data streams currently delivered from the plurality of receiving devices 41a, 41b. Comparing the received request for the plurality of currently used receiving resources with a list of received resources to a plurality of user devices in a network. 18. The apparatus of claim 17, wherein the controller 70 compares the parameters of the request for a service with each of the parameters of the data stream currently delivered from the plurality of receiving devices 41a, 41b. And assign a received resource to a plurality of user devices in a network comparing the received request with a list of the plurality of currently used received resources. delete A gateway device 14 operating in a network within a multi-family residential facility, Means for receiving a signal comprising a plurality of services; Means for receiving a request for service from a set top box on the network; Means (306) for determining a received resource for the requested service based on the request for a service; Means for comparing the determined received resource with a list of a plurality of currently used received resources; Means for updating a list of currently used received resources in response to the comparison; And Means for modifying a data stream associated with one received resource of the currently used received resource when the currently used received resource matches the determined received resource. Including a gateway device.

Images