Unicast/multicast media edge proxy with fast channel switching

A system, method, and media edge proxy, MEP, (17) for providing media data such as Internet Protocol Television, IPTV, or Internet radio channels to a media client (12). The MEP obtains the media data from a media server (18) utilizing a temporary unicast connection and provides the media data obtained from the server to the media client for an initial time period. Upon determining that the initial time period has expired, the MEP obtains the media data via multicast from a multicast router (27), provides the media data obtained from the router to the media client, and releases the temporary unicast connection. The invention reduces channel switching delay and thus improves quality-of-experience for the end-user. The invention also avoids excessive IGMP JOIN/LEAVE signaling when a user switches quickly through channels.

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to communications networks, and in particular, to the delivery of media data such as television (TV) channels to TV sets connected to an Internet Protocol (IP) network.

DESCRIPTION OF RELATED ART

Internet Protocol Television (IPTV) enables Set-Top-Boxes (STBs) connected to an IP network to obtain delivery of TV channels and to access video content through the IP network. IP provides two delivery mechanisms: unicast and multicast. Unicast is more appropriate for Video-on-Demand (VoD) services, while multicast is more efficient for delivering TV channels.

In the Internet draft by T. Einarsson, et al., “Multiple aggregated control URIs for RTSP”, IETF Draft, June 2006, it was shown that fast channel switching is feasible over unicast. However, an IPTV solution using unicast for delivering TV channels will not scale with the number of users and is thus not feasible. While multicast is the right choice for delivering live TV channels to multiple users, it has the drawback of requiring the processing of Internet Group Management Protocol (IGMP) JOIN/LEAVE commands for channel switching, and this processing introduces delays and network-resource problems.

Accordingly, there is a need for an improved system and method of delivering media data such as TV channels over an IP network. The present invention provides such a system and method together with a media edge proxy.

SUMMARY OF THE INVENTION

The present invention provides a media edge proxy which combines the advantages of unicast for fast channel switching with the advantages of multicast as an efficient channel distribution mechanism. The invention reduces the channel switching delay and thus improves quality-of-experience for the end-user. The invention also avoids excessive IGMP JOIN/LEAVE signaling when a user switches quickly through channels.

Thus in one aspect, the present invention is directed to a method of providing media channels to a media client. The method includes the steps of receiving from the media client, a request for media data from an identified media channel; obtaining the media data from a media server utilizing a temporary unicast connection; and providing the media data received from the server to the media client for an initial time period. Upon determining that the initial time period has expired, the method includes obtaining the media data from a multicast router; providing the media data received from the router to the media client; and releasing the temporary unicast connection with the media server. The media channels may be, for example, IPTV or Internet radio channels.

In another aspect, the present invention is directed to a media edge proxy for providing media channels to a media client. The media edge proxy includes a channel switch interface for receiving from the media client, a request for media data from an identified media channel; a unicast interface for receiving the requested media data from a media server; a multicast interface for receiving the requested media data from a multicast router; and a controlling proxy unit connected to the channel switch interface, the unicast interface, and the multicast interface. The controlling proxy unit is adapted to obtain the requested media data from the media server utilizing a temporary unicast connection; and provide the requested media data received from the server to the media client for an initial time period. Upon determining that the initial time period has expired, the controlling proxy unit obtains the media data from the multicast router; provides the requested media data received from the router to the media client; and releases the temporary unicast connection with the server.

In another aspect, the present invention is directed to a system for providing requested media data to a media client. The system includes a media server for providing the requested media data utilizing a temporary unicast connection; a multicast router for providing the requested media data utilizing a multicast connection; and a media edge proxy for controlling delivery of the requested media data to the media client. The media edge proxy includes a unicast interface for receiving the requested media data from the media server utilizing the temporary unicast connection; a multicast interface for receiving the requested media data from the multicast router utilizing the multicast connection; a channel switch interface for sending the requested media data to the media client; and a controlling proxy unit connected to the unicast interface, the multicast interface, and the channel switch interface. The controlling proxy unit is adapted to obtain the requested media data from the media server utilizing a temporary unicast connection; and provide the requested media data received from the server to the media client for an initial time period. Upon determining that the initial time period has expired, the controlling proxy unit obtains the media data from the multicast router; provides the requested media data received from the router to the media client; and releases the temporary unicast connection with the server.

DETAILED DESCRIPTION OF EMBODIMENTS

The present invention provides a media edge proxy which combines the advantages of unicast for fast channel switching with the advantages of multicast as an efficient channel distribution mechanism. Although the invention is described herein primarily in terms of IPTV channels, the invention is applicable to other types of media channels such as Internet radio channels and the like.

FIG. 1is a simplified block diagram of an IP-network architecture10suitable for delivering IPTV channels to IPTV Set-Top-Boxes (STBS)11in accordance with exemplary embodiments of the system of the present invention. The STBs include a media client12, and multiple STBs may connect to a home network13. The home network connects through a Residential Gateway (GW)14to a Digital Subscriber Line Access Multiplexer (DSLAM)15. The DSLAM connects to an aggregation network16via a nearby Media Edge Proxy (MEP)17.

When a user activates television reception, the IPTV STB11establishes a control connection to the MEP17over unicast, either directly with the MEP or indirectly via the Residential GW14. In the following description, the term “STB/GW” is used to indicate from the perspective of the MEP, either a direct connection from the STB or a connection from the STB via the Residential GW. Typically the Real-Time Streaming Protocol (RTSP) is used for controlling the unicast connection, but other protocols suitable for connection control, such as the Session Initiation Protocol (SIP), may be utilized as well. Without limiting the present invention, RTSP is discussed in the following exemplary description.

When the STB/GW connects via RTSP to the MEP17, the MEP establishes a unicast connection to a media server18. Without loss of generality,FIG. 1also shows the use of RTSP between the MEP and the media server, although other protocols such as SIP may be utilized as well. The STB/GW then requests a channel. This may be accomplished, for example, by utilizing RTSP PLAY requests inside an RTSP session to request a new TV channel (content source) via the RTSP front end in the media server. The MEP17checks whether the requested channel is locally available on a multicast channel. If yes, the MEP starts forwarding packets to the media client12over the already established unicast connection as soon as the MEP receives multicast packets of the requested channel.

If the requested channel is not locally available on a multicast channel, the MEP17requests the channel from the media server over a unicast RTSP connection. While requesting the channel via RTSP from the media server18, the MEP also sends an IGMP JOIN request message to a Multicast Router27requesting a multicast connection for the requested channel. An IGMP JOIN inhibit timer triggers the IGMP JOIN request message only if the requested channel has been delivered to the STB11via the unicast connection for more than a predefined period of time (for example, 30 seconds). As soon as the requested channel becomes available over multicast, the MEP starts forwarding the packets to the STB and tells the media server18to release the unicast connection and stop sending data.

If the STB11stops using a channel, it sends a request to the MEP17. The MEP immediately stops forwarding the media packets belonging to that channel. If an IGMP JOIN request was issued previously, the MEP sends an IGMP LEAVE request to the Multicast Router27. An IGMP LEAVE inhibit timer triggers the LEAVE request only if the channel has not been requested by the same media client over a longer period of time (for example, 5 minutes). If channel data was received from the media server18via unicast, a STOP command is sent to the media server.

FIG. 2is a message sequence diagram illustrating an embodiment of the method of the present invention in which an STB11or a Residential GW14requests a channel, which is not currently available over multicast at the MEP17. It is assumed that an RTSP session has been established already between the STB and the MEP and between the MEP and the media server by using the well known sequence of RTSP SETUP messages. The invention provides a temporary unicast connection to give quick access to TV channels requested by a media client, and then rolls over from unicast to multicast reception as soon as possible to avoid excessive usage of unicast resources.

The STB/GW sends an RSTP PLAY message21to the MEP17, which forwards the message to the Media Server18. The RSTP PLAY message identifies a requested channel (channel #x). The Media Server returns an RSTP OK message22, which the MEP forwards to the STB/GW. At23, the Media Server then sends media data for channel #x over unicast to the MEP. At24, the MEP forwards the media data, which was received over unicast from the media server, to the STB11. After a predefined time period, the MEP determines at25that channel #x has been delivered for N seconds. The MEP then sends an IGMP JOIN request message26identifying channel #x to the Multicast Router27. At28, the Multicast Router begins forwarding the media data to the MEP over multicast. The receipt of the media data indicates to the MEP at29that channel #x is available over multicast, and at31, the MEP begins forwarding the media data, which was received via multicast from the multicast router, to the STB11. At32, the MEP sends an RTSP PAUSE message identifying channel #x to the Media Server. At33, unicast delivery of the media data between the Media Server and the MEP is stopped.

FIG. 3is a message sequence diagram for the case in which the STB11receives a first channel (channel #x) and switches to a second channel (channel #y). It is assumed that channel #y is available over multicast in this case. Otherwise, the message sequence shown inFIG. 2is used to give quick access to channel #y via an RTSP unicast connection.

At35, the Multicast Router27is forwarding media data for channel #x over multicast to the MEP17. At36, the MEP forwards the media data for channel #x received over multicast to the STB11. At37, the Multicast Router also forwards media data for channel #y to the MEP. In certain situations channel #y is available at the MEP although the STB has not requested it. The system may have been configured such that all channels are always broadcasted in the backbone, or another STB may have previously requested channel #y. At38, the STB sends an RTSP PLAY message to the MEP requesting channel #y. At39, the MEP stops forwarding media data for channel #x to the STB, and at41, the MEP starts forwarding media data for channel #y to the STB11. After a predefined time period, the MEP determines at42that channel #x has not been delivered for M seconds. The MEP then sends an IGMP LEAVE request message43identifying channel #x to the Multicast Router.

FIG. 4is a flow diagram illustrating the steps of an exemplary embodiment of the method of the present invention, as executed by a unicast/multicast proxy function at the MEP. In this example, channel #x is currently being forwarded to the STB11when the user enters a request for channel #y. LEAVE and JOIN requests are entered into a timer queue. Entries in this queue are de-queued and executed when an associated timer expires. By de-queuing an entry, the associated timer is canceled. The use of special logic and inhibit timers prevents the sending of IGMP JOIN/LEAVE messages when a user rapidly changes channels because only the unicast connection is used during rapid channel changes.

At step45, the MEP17receives a request for channel #y from the STB11. At step46, it is determined whether or not forwarding of another channel, such as channel #x, is already in progress. If so, the method moves to step47where the MEP stops forwarding media data for channel #x. At step48, it is determined whether or not channel #x was forwarded from multicast. If not, the method moves to step49where the MEP sends a STOP request for channel #x to the Media Server18. At step51, the MEP de-queues the JOIN request for channel #x. The method then moves to step52where the MEP de-queues the LEAVE request for channel #y, if such a LEAVE request had been entered earlier. However, if it is determined at step48that channel #x was forwarded from multicast, the method moves instead to step53where the MEP queues a LEAVE request for channel #x at time “NOW+M” seconds. The method then moves to step52where the MEP de-queues the LEAVE request for channel #y, if it had been entered before.

The method then moves to step54where it is determined whether or not channel #y is available on multicast. If so, the method moves to step55where the MEP17receives the media data for channel #y from the Multicast Router27and forwards the media data over multicast to the STB11and Media Client12. However, if channel #y is not available on multicast, the method moves instead to step56where the MEP sends a START request for channel #y to the Media Server18. At step57, the MEP receives media data for channel #y over unicast from the Media Server and forwards the data at step58to the STB and Media Client. At step59, the MEP queues a JOIN request for channel #y at time “NOW+N” seconds. At step61, it is determined whether or not channel #y is available on multicast. If not, the method continues to wait until channel #y is available on multicast. When channel #y is available on multicast, the method moves to step62where the MEP stops the unicast connection by sending a STOP request for channel #y to the Media Server. At step63, the MEP forwards media data for channel #y received over multicast to the STB and Media Client.

FIG. 5is a simplified block diagram of a MEP17configured in accordance with the present invention. The MEP includes a channel switch interface65, a multicast interface66, and a unicast interface67. The channel switch interface is for signaling and sending media data to and from the Media Client12in the STB11. The channel switch communications may optionally pass through the Residential GW14. The multicast interface is for signaling and sending media data to and from the Multicast Router27in the aggregation network16. In one exemplary embodiment, the multicast interface uses IGMP signaling. The unicast interface is for signaling and sending media data to and from the Media Server18. In exemplary embodiments, the unicast interface uses RTSP or SIP signaling.

Logic in a coordinating proxy unit68determines if and when unicast or multicast communications are established with the Media Client12in accordance with the flow diagram illustrated inFIG. 4. Inhibit timers Timer-M69and Timer-N71provide queuing times for JOIN/LEAVE messages when the proxy unit switches from a temporary unicast connection to a multicast connection with the Media Client.