Multicast services control system and method

RELATED PATENT DATA

This application claims priority from U.S. Provisional Patent Application Ser. No. 60/484,033, which was filed Jun. 30, 2003, and which is incorporated by reference herein.

TECHNICAL FIELD

The present invention pertains to apparatus and methods for improving communications in digital networks. More particularly, the present invention relates to multicast services control of digital information over a digital network.

BACKGROUND OF THE INVENTION

Traffic management is important in digital networks. Traffic management involves the controlling and scheduling of traffic through paths established through a network. The traffic can include audio, video, or any form of digital information. The individual streaming of television channels on a network typically requires the involvement of a multicast router because there is an inability to control multicast streams at lower layers in an Open Systems Interconnection (OSI) model. For example, the provision of multicast video services over an Ethernet broadband network requires the use of a multicast router to enable control of multicast streams of television channels.

According to one previously known technique, Internet Group Management Protocol (IGMP) enabled multicast switches are designed to “snoop” IGMP membership reports and “leaves” based upon queries from an upstream, multicast router. However, current router-based multicast services are adversely affected by complex multicast routing protocols and the processing overload experienced by routers due to thousands of channel changes occurring downstream.

Additionally, such previously known technique uses expensive routers that are specialized for use in implementing multicast control. Furthermore, this technique uses complex Internet Protocol (IP) address and router protocol design. Even more, there exists a performance degradation due to video service subscriber increases.

Also according to previous known techniques, presently available Ethernet gear can be configured to enable the sending of one multicast stream of digital information from a server to multiple endpoints. However, problems arise with such previously known technique when trying to stream more than one multicast stream on the same network. IGMP snooping was previously designed in order to solve this basic problem. However, difficulties are encountered when attempting to deliver 100 channels of video to 1,000 different subscribers over an Ethernet network using presently available off-the-shelf gear. More particularly, such a solution still requires the use of a Layer-3 router configured to run IGMP. There presently exists several routers that are commercially available that are capable of such configuration. However, such routers are presently very expensive, particularly when such a router is provided for solely implementing present tasks. Secondly, channel-change latency becomes a problem as the number of channels, hosts, and “hops” is increased between the router and an end user. Finally, Layer-2 devices are typically not designed to respond quickly in response to a topology change. As a result, there can be a loss of service to the customer.

SUMMARY OF THE INVENTION

A multicast digital information services control system is provided for Internet protocol (IP) information transport. The system provides channel streaming of digital information including video and audio without the use of a router. The solution is able to solve Internet protocol (IP) television transport issues while reducing overall complexity and alleviating IP addressing concerns. The system provides completely Level 2 control of broadband television services over a network.

According to one aspect, a multicast video service control system is provided for Internet protocol television transport. The system includes a service distribution platform, at least one service concentration platform, and at least one set-top box. The service distribution platform has a multicast table. The service distribution platform is configured to receive channels from an Internet protocol video source and the multicast table is configured to include an entry for each of the channels. The at least one service concentration platform communicates with the service distribution platform for forwarding “leaves” and receiving “joins” with the service distribution platform. The at least one set-top box includes a receiving port and is configured to generate “leaves” and forward the “leaves” to one or more of the at least one service concentration platform wherein the “leaves” are snooped by portals and concentrators and wherein the set-top box is further configured to receive “joins” from one or more of the at least one service concentration platform.

According to another aspect, a method is provided for controlling multicast video service. The method includes: providing a service distribution platform having a multicast table, at least one service concentration platform, a portal site, and at least one set-top box; receiving channels at the service distribution platform from an Internet protocol video source; providing an entry in the multicast table for each of the channels; generating a “join” or a “leave” at a set-top box; snooping messages from the set-top box to identify one or more “joins” and “leaves”; forwarding an identified “join” or “leave” to the service distribution platform from the portal site via the service concentration platform; forwarding an identified “join” or “leave” to the service distribution platform from the portal site via the service concentration platform; and forwarding the “join” or the “leave” to one or more of the at least one service concentration platform wherein the “join” or the “leave” is snooped by portals and concentrators and wherein the set-top box is further configured to receive additional “joins” or “leaves” from one or more of the at least one service concentration platform.

According to yet another aspect, a system is provided for communicating between a first point and a second point on a computer network such that no router is required. The system includes a service distribution platform, at least one service concentration platform, at least one portal site, and at least one set-top box. The service distribution platform has a multicast table and is configured to receive channels from an Internet protocol video source. The multicast table is configured to include an entry for each of the channels and to add and delete receiving ports via “joins” and “leaves” associated with the entry for each channel in the multicast table. The at least one service concentration platform communicates with the service distribution platform for forwarding “leaves” and “joins” with the service distribution platform. The at least one portal site communicates with the service concentration platform. The at least one set-top box includes a receiving port. The at least one set-top box is configured to generate “leaves” and “joins” and forward the “leaves” and “joins” to one or more of the at least on service concentration platform. The “leaves” and “joins” are snooped by one or more of the at least one portal.

An advantage results because channel streaming is provided without having to use a router. Another advantage is provided because overall system complexity is reduced. A further advantage results because IP addressing concerns are alleviated.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the invention are described below with reference to the following accompanying drawings.

<figref idref="DRAWINGS">FIG. 1</figref> is a diagrammatic illustration of a multicast video service control system depicting channel stream architecture.

<figref idref="DRAWINGS">FIG. 2</figref> is a diagrammatic illustration of a first step for leaving a channel stream pursuant to the system and method of <figref idref="DRAWINGS">FIG. 1</figref>.

<figref idref="DRAWINGS">FIG. 3</figref> is a diagrammatic illustration of a second step for leaving a channel stream pursuant to the system and method of <figref idref="DRAWINGS">FIG. 1</figref>.

<figref idref="DRAWINGS">FIG. 4</figref> is a diagrammatic illustration of a third step for leaving a channel stream pursuant to the system and method of <figref idref="DRAWINGS">FIG. 1</figref>.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

This disclosure of the invention is submitted in furtherance of the constitutional purposes of the U.S. Patent Laws “to promote the progress of science and useful arts” (Article 1, Section 8).

Reference will now be made to a preferred embodiment of Applicant's invention. An exemplary implementation is described below and depicted with reference to the drawings comprising a system and method for joining and leaving channel streams via router-less multicast video service control. While the invention is described by way of a preferred embodiment, it is understood that the description is not intended to limit the invention to such embodiment, but is intended to cover alternatives, equivalents, and modifications which may be broader than the embodiment, but which are included within the scope of the appended claims.

In an effort to prevent obscuring the invention at hand, only details germane to implementing the invention will be described in great detail, with presently understood peripheral details being incorporated by reference, as needed, as being presently understood in the art.

As used herein, “streaming digital multicast services” (SDMS) is intended to refer to the process of sending information from one source to multiple endpoints over a digital network. For example, SDMS comprises the process of streaming a video program from one server to several hosts over an IP/Ethernet network.

As used herein, the term “Internet Group Management Protocol” (IGMP) is intended to refer to a standard networking protocol belonging to the TCP/IP family of protocols. IGMP can be found on many Layer-3 routers that are presently commercially available.

As used herein, the term “IGMP snooping” is intended to refer to a technique used by Layer-2 devices for monitoring IGMP activity on a network. IGMP snooping is not a protocol itself, and it presently is much less common in the Ethernet world compared to IGMP in the TCP/IP world. IGMP snooping is presently a proposed standard in the Internet Engineering Task Force (IETF).

As used herein, the term “Distributor” is intended to refer to a large, Layer-2 Ethernet switch designed to aggregate traffic from thousands of subscribers.

As used herein, the term “Concentrator” is intended to refer to a term similar to a distributor, but designed to aggregate network traffic from one or two dozen subscribers.

As used herein, the term “Portal” is intended to refer to a Layer-2 Ethernet switch, typically located at a customer location, or premises.

The following description provides one exemplary implementation for implementing channel streaming over a digital information network comprising a multicast video service control system for internet protocol television transport. However, it is understood that channel streaming can be implemented with any of a number of services, including video, audio, or any other form of digital information. Channel streaming is used to take a group of digital information services and configure them to flow down into a digital network into several channels so as to get the digital information close to an end user so the end user can access the digital information very quickly. Such an implementation is made readily available for digital networks that have capacity, such as extra bandwidth, that enables the flow of digital services closer in proximity to an end user so that the end user can retrieve them more quickly. Accordingly, the end user experiences a reduction in channel change latency (by way of example) when changing channels while watching video over such a digital network. The digital information (or data) is pushed down the network, even though no specific end user has requested the digital information. For example, channels <b>1</b>-<b>40</b> can be sent down a network 24 hours a day, seven days a week, so that channels <b>140</b> are close to specific end users and so that the end users can retrieve channels <b>140</b> very quickly.

Channel streaming is intended to improve behavior of almost any Ethernet topology. However, benefits of channel streaming become more important as the size of the network is increased, and the number of “hops” between a client and a server increases. In a typical access-space network, there can exist five or more “hops” between a multicast server and a multicast client (i.e., a set-top box). For example, “hops” can occur progressively from a server, a router, a distributor, a concentrator, a portal, and a set-top device (or box). When a set-top device makes a request to receive a particular multicast stream, a message is sent from the set-top device to the router. This message is then required to be processed by each device along the path from the set-top device to the router, and each device will add a certain amount of latency to this request. When the router finally receives the message, the router begins to forward the desired multicast stream to the set-top device. A maximum end-to-end latency allowed in such a system is about 100 milliseconds, but a single piece of Ethernet gear could easily cause 200 milliseconds of latency by itself, unless IGMP messages are handled efficiently and with high priority relative to other messages and tasks. This problem gets worse as the size of a network grows. One of the goals of channel streaming is to reduce (or eliminate) this latency as much as possible.

The basic concept of the present invention is to define a set of static multicast groups, and then flood those groups to all ports in the virtual local area network (VLAN) all the time. This technique can be used in order to bring multicast services down into the network (in closer proximity to an end user) before any host actually has joined the group. Latency is thereby reduced because the IGMP “join” message does not need to propagate all the way to the router. In fact, if a channel stream is configured such that multicast groups flow all the way to the portal, then the portal is the only switch that needs to process the “join” message in order to flow the multicast group to the end user.

According to the present invention, channel streaming (or channel stream) is configured to overcome the above problems within a typical network topology. More particularly, channel stream comprises a collection of technologies that are intended to improve the way streaming digital multicast services (SDMS) are supported on a Layer-2 Ethernet network. Specifically, channel stream is designed to provide several benefits. First, channel stream reduces the overall cost of a network by eliminating the need for a Layer-3 router. Secondly, channel stream reduces the complexity of a network configuration and maintenance. Thirdly, channel stream reduces the latency associated with a “channel change” event, as much as possible. Fourthly, channel stream increases the number of multicast streams that are supported by a network. Finally, channel stream increases the number of multicast hosts that are supported by a network.

A number of technologies are utilized in order to make up channel stream: (1) static multicast groups; (2) unresolved multicast filtering (UMF); (3) well-known multicast forwarding (WKMF); (4) IGMP query engine; (5) rapid response to topology changes; (6) channel change heuristics; (7) each VLAN is a separate domain for multicast services; each service provider can have their own VLAN; (8) high priority processing for IGMP packets; (9) security features; (10) inquisitive leave or fast leave; (11) active-linger mode; and (12) proxy query.

According to the present implementation, channel streaming (or channel stream) is used to force a selected group of multicast streams (of services) to flow down into a digital network before the services are requested by any multicast hosts within the digital network. As a result, channel-change latency is reduced, and load on a router is also reduced. Secondly, channel stream can be used to eliminate the need for a router within a digital network. In contrast, TCP/IP services presently use a router which can be costly and complex.

According to the implementation depicted herein, channel stream provides an interface between a user and a video source. Channel stream is implemented in an Ethernet switch via a distributor and a concentrator. By using software within a distributor and concentrator, the need for a router is eliminated. In order to implement this feature, unresolved multicast filtering (UMF) is provided on every Ethernet switch that is running channel stream. UMF enables the dropping of channels that are not being utilized.

<figref idref="DRAWINGS">FIG. 1</figref> illustrates a system <b>10</b> for providing multicast video services over an Ethernet broadband network without requiring the use of a multicast router. However, other digital information can also be multicast via a channel streaming, such as voice information. System <b>10</b> is configured to implement multicast video control, without use of a router, to enable Layer 2 Ethernet broadband devices to receive channels, filter the channels, and distribute the channels. Each of these functions is carried out based upon Internet Group Management Protocol (IGMP) membership reports and IGMP leaves. Individual channels can be programmed into the access switches via manual input, via integration with third party interactive television management software, or via a network supervisor.

For purposes of this disclosure, the term “multicasting” refers to one-to-many transmission, or broadcasting to multiple users at once. Typically, a receiver decides whether to join a specific multicast transmission.

As shown in <figref idref="DRAWINGS">FIG. 1</figref>, system <b>10</b> includes a service distribution platform <b>12</b>, a service concentration platform <b>14</b>, portal sites <b>16</b>, and set-top boxes <b>18</b>. Set-top boxes <b>18</b> are provided in association with television sets <b>20</b>. An Internet protocol (IP) video source <b>22</b> provides a range of channels comprising “all channels” <b>24</b> that are delivered over a communication link <b>26</b> to service distribution platform <b>12</b>. By way of example, “all channels” <b>24</b> comprises a set of sequentially numbered video channels <b>1</b>-<b>100</b>, as shown in <figref idref="DRAWINGS">FIGS. 2-4</figref>. The set of “all channels” <b>24</b> are sent to service distribution platform <b>12</b> from source <b>22</b> where a multicast table <b>26</b> includes an entry <b>28</b> for each individual channel <b>30</b> within set of “all channels” <b>24</b>. Individual channels <b>30</b> are manually placed into multicast table <b>26</b>. Alternatively or additionally, individual channels <b>30</b> can be dynamically learned and filtered upon ingress into service distribution platform <b>12</b>. As shown in <figref idref="DRAWINGS">FIG. 1</figref>, services distribution platform <b>12</b> drops all of channels <b>1</b>-<b>100</b> for the case where a “join” has not been sent for any channel.

Service distribution platform <b>12</b> distributes selected channels, such as channel <b>30</b>, over communication links <b>32</b> to individual service concentration platforms <b>14</b> based upon “joins”. The service concentration platforms <b>14</b> send “join” messages for “n” channels, such as channel <b>30</b>, based on configuration.

Service concentration platforms <b>14</b> distribute the “n” channels that have been “joined”, such as channel <b>30</b>, via communication links <b>34</b> to portal sites <b>16</b>. Portal sites <b>16</b> deliver the “n” channels to set-top boxes <b>18</b> and television sets <b>20</b>. In operation, portal sites <b>16</b> update multicast tables based on IGMP snooping of messages from the set-top boxes <b>18</b>.

<figref idref="DRAWINGS">FIGS. 2-4</figref> illustrate in steps the “leave” message processes and the “join” message processes that trigger port subtractions and additions, respectively, to the multicast tables. Although the “leave” processes are described in detail with reference to such Figures, it is understood that the “join” processes work similarly. However, the “join” processes trigger additions to the multicast tables, instead of subtractions. Otherwise, the same logic is used in order to determine upstream forwarding of channel streams that are “joined”.

According to <figref idref="DRAWINGS">FIG. 2</figref>, a first step comprises set-top box <b>18</b> (in the lower branch) sending a “leave” message for a selected channel “n”, such as channel <b>30</b>. A portal table <b>36</b> within corresponding portal site <b>16</b> is altered in order to remove a receiving port <b>38</b> corresponding to the selected channel <b>30</b> from the multicast entry for channel “n”. Set-top box <b>18</b> (in the upper branch) sends a “join” for a selected document t “n” to corresponding portal site <b>16</b>.

As shown in <figref idref="DRAWINGS">FIG. 2</figref>, channels <b>140</b> are illustrated as streaming from service distribution platform <b>12</b> to service concentration platform <b>14</b>. Service concentration platform <b>14</b> is shown dropping all of channels <b>1</b>-<b>40</b>. Accordingly, <figref idref="DRAWINGS">FIG. 2</figref> illustrates what happens when channels <b>1</b>-<b>40</b> are configured on service distribution platform <b>12</b>.

In order to implement the above-described feature, portal site <b>16</b> implements the following logic: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0042"> If Channel “n” has current membership on another port (i.e., another television set within a particular home is watching channel “n”), </li><li id="ul0002-0002" num="0043"> Do not forward leave up to service concentration platform, </li><li id="ul0002-0003" num="0044"> Else <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0045"> Forward leave up to service concentration platform </li></ul></li></ul></li></ul>

<figref idref="DRAWINGS">FIG. 3</figref> illustrates a second step in the process comprising the delivery of a “leave” message from set-top box <b>18</b> via portal site <b>16</b> to service concentration platform <b>14</b> (in the lower branch). The “leave” message is received by service concentration platform <b>14</b> if no other members are present on the associated portal site <b>16</b>. However, if there exists another member on portal site <b>16</b>, then the “leave” message is not received by service concentration platform <b>14</b>. Multicast table <b>26</b> (see <figref idref="DRAWINGS">FIG. 1</figref>) is then altered in order to remove the respective receiving port, or portal site <b>16</b> from the channel “n” multicast entry within table <b>26</b>. Likewise, set-top box <b>18</b> delivers (or forwards) a “join” message to a respective service concentration platform <b>14</b> (in the upper branch).

In order to implement the above-described feature, the following logic is implemented: <ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0000"><ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0048"> If (Channel “n”=Channel <b>1</b>-<b>40</b>), then Service Concentration Platform doesn't forward the leave to the Service Distribution Platform </li><li id="ul0005-0002" num="0049"> If (Channel “n”≠Channel <b>1</b>-<b>40</b> AND there are other port members for Channel “n”s multicast tale entry, then the Service Concentration Platform doesn't forward the leave to the Service Distribution Platform </li><li id="ul0005-0003" num="0050"> If (Channel “n”≠Channel <b>1</b>-<b>40</b>) AND there are no other port members for Channel “n”s multicast table entry, then the Service Concentration Platform forwards the leave to the Service Distribution Platform </li></ul></li></ul>

<figref idref="DRAWINGS">FIG. 4</figref> illustrates a fourth step in the process comprising the service concentration platform <b>14</b> forwarding the “leave” message for channel “n” from the service distribution platform <b>12</b>, assuming the criteria for this action are met. The multicast table <b>26</b> in the service distribution platform <b>12</b> is altered and the receiving port, or portal site <b>16</b> is removed from the multicast table entry for Channel “n”.

According to the above-described implementation, no further logic is necessary because “leave” messages should only make it this far if the source of the “leave” was the last member of channel “n” on that particular service distribution platform <b>12</b>. In other words, no one else on the entire network is watching that particular channel, channel “n”.

As shown above with reference to <figref idref="DRAWINGS">FIGS. 2-4</figref>, it is understood that the process of joining a channel stream (a “join”) is similar to leaving a channel stream (a “leave”). However, a “join” triggers an addition to the multicast tables, whereas a “leave” triggers a subtraction from the multicast tables. Otherwise, the same logic is used to determine upstream forwarding when implementing a “join”.

As shown in <figref idref="DRAWINGS">FIG. 4</figref>, a network administrator can be used to configure service distribution platform <b>12</b> either manually or by communicating with a middle ware server (such as part of a video server) in order to auto configure service distribution platform <b>12</b>. Service distribution platform <b>12</b> forwards 40 channels to the service concentration platforms (concentrators) <b>14</b> by way of unresolved multicast filtering (UMF), the service concentration platforms <b>14</b> that did not ask for these channels will then drop channels <b>1</b>-<b>40</b>. Accordingly, service concentration platforms <b>14</b> that did not ask for the channels will receive the channels and drop the channels.

In operation, a set-top box <b>18</b> sends a “join” message to a portal site <b>16</b>. The portal site is essentially a standard portal site, and the video source is also a standard video source. Secondly, a portal site <b>16</b> runs IGMP snooping, and they forward the “join” message to the service concentration platform (concentrator) <b>14</b>. Accordingly, video (and other digital information) will flow to a set-top box quicker because the “join” messages are not sent all the way to a service distribution platform <b>12</b>, or to a router.

In contrast, prior art techniques send such a “join” message to a router that is positioned between the video source <b>22</b> and service distribution platform <b>12</b>, as shown in <figref idref="DRAWINGS">FIG. 4</figref>. The prior art use of a router filters video/multicast traffic, runs IGMP protocol, and generates IGMP query messages.

The present implementation eliminates a router. Instead, service distribution platform <b>12</b> is used to generate IGMP query messages, without the provision of a router.

According to one exemplary construction, there exist three techniques for programming a multicast table. The first is static, the second is automatic, and the third is integrated. Pursuant to the first, static technique, ranges of multicast groups can be defined by an operator. A network supervisor is then used to fill in the individual channels for table entering. Accordingly, a network supervisor can manually identify each element that is desired to flow through the network down to the portal(s).

Pursuant to a second, automatic technique, all streams from a source are filtered by a filter as they ingress to the service distribution platform. Multicast groups are then gleaned from actual streams, and table entries are made accordingly.

Pursuant to a third, integrated technique, a network supervisor is interfaced to one or more middleware platforms. Next, multicast tables are programmed from channel databases.

According to one implementation, the system can operate in multiple modes including an IGMP mode (where channel streaming is turned off) and a channel streaming mode. When operating in the IGMP mode, messages are snooped between a router and a set-top box. Devices synchronize timers off of queries, and the devices further filter channel streams when a maximum number of responses are exceeded. Additionally, message filtering is used in order to determine upstream “leave” and “join” forwarding.

When operating in channel streaming mode, several benefits are provided. First, no router is needed. Secondly, no queries are required. Thirdly, no membership reports are generated in response to the queries. Instead, just “leaves” and “joins” are delivered from and to the set-top boxes. Devices disable timers that are used to time responses to queries (when operating in the other mode). The cleanup timer is disabled since queries will not be present. A linger timer is retained in an enabled mode in order to ensure maximum quality in the event of a slow “leave” or “join” at the service concentration platform or the service distribution platform.

In one case, the service distribution platform includes a Layer-2 Ethernet broadband device. The device is capable of receiving channels, filtering channels, and distributing channels based upon IGMP membership reports and IGMP “leaves”. In one case, the service distribution platform receives channels from a digital turnaround source so as to retransmit previously encoded signals. The service distribution platform can receive channels from an encoder that encodes signals.

According to one construction, the set-top box includes a converter box having electronic circuitry that communicates with a television receiver. In one case, the set-top box is configured to forward a “leave” for a selected channel, and a corresponding entry in a multicast table for the selected table is altered in order to remove a receiving port from a portal table. In one case, the service concentration platform is configured to receive the “leave” for the selected channel when no other member is identified as being present on the portal. Furthermore, the multicast table is modified to remove the receiving port from a multicast entry for the channel.

For the case where the service distribution platform receives channels from a digital turnaround source so as to retransmit previously encoded signals, the service concentration platform can be configured to forward a “leave” for a selected channel to the service distribution platform. In one case, the multicast table is altered and the receiving port is removed from a corresponding channel entry in the multicast table.

According to one construction, the set-top box is configured to forward a “join” for a selected channel, and a corresponding entry in the multicast table for the selected channel is altered to add a receiving port to a portal table. In one case, the service concentration platform is configured to receive the “join” for the selected channel. In another case, the multicast table is modified to add the receiving port to a multicast entry for the channel. Furthermore, the service concentration platform can be configured to forward a “leave” for a selected channel to the service distribution platform. For this case, the multicast table is altered and the receiving port is removed from a corresponding channel entry in the multicast table.

Also according to one construction, a “leave” is forwarded when one of the set-top boxes provides a source of the “leave” and the set-top box is the last member of the corresponding channel entry on that particular service distribution platform port.

According to a further implementation of the present invention, a method is provided for controlling multicast video service. In order to implement the method, the following items are provided: a service distribution platform having a multicast table, at least one service concentration platform, a portal site, and at least one set-top box. According to one step, channels are received at the service distribution platform from an Internet protocol video source. According to another step, an entry is provided in the multicast table for each of the channels. According to yet another step, either a “join” or a “leave” is generated at a set-top box. According to a further step, messages are snooped from the set-top box to identify either the “join” or the “leave”. According to another step, the identified “join” or “leave” is forwarded to the service distribution platform from the portal site via the service concentration platform. Finally, the identified “join” or “leave” is forwarded to one or more of the at least one service concentration platform. Here, the identified one of the “join” and the “leave” is snooped by portals and concentrators. The set-top box is further configured to receive additional “joins” and “leaves” from one or more of the at least one service concentration platform.

For one implementation of this method, generating includes generating a “join” at the portal site responsive to a user requesting a channel that is not presently provided as an entry on the multicast table. For one case, prior to receiving channels at the service distribution platform, all streams of channels from the Internet protocol video source are filtered.

For another implementation of this method, generating includes generating a “leave” at the portal site responsive to a user terminating a channel that is not also being used by another user via the portal site. For one case, prior to receiving channels at the service distribution platform, an operator defines ranges of multicast groups to be defined.

In another case, snooping includes implementing Internet Group Management Protocol (IGMP) snooping of messages from the set-top boxes to enable reporting of multicast group memberships via the portal site and the service concentration platforms to the service distribution platform. In one case, the method also includes generating an Internet Group Management Protocol (IGMP) membership report indicative of “joins” and used by the set-top box. In such case, the method can further include snooping the Internet Group Management Protocol (IGMP) membership report with at least one of a portal and a concentrator.

For the case where the service distribution platform includes a multicast table, channels can be manually placed into the multicast table, according to one implementation. In another case, the channels can be dynamically learned and filtered using a filter, upon ingress to the service distribution platform.

In one case, portal sites update multicast tables based on Internet Group Management Protocol (IGMP) snooping of messages from one or more of the set-top boxes where Internet Protocol (IP) multicast streams are used. In some cases, ranges of multicast groups are defined.

In compliance with the statute, the invention has been described in language more or less specific as to structural and methodical features. It is to be understood, however, that the invention is not limited to the specific features shown and described, since the means herein disclosed comprise preferred forms of putting the invention into effect. The invention is, therefore, claimed in any of its forms or modifications within the proper scope of the appended claims appropriately interpreted in accordance with the doctrine of equivalents.