The present invention provides a solution for performance to improvement of a multi-channel real-time streaming service in a packet-switched communication system.
Especially the present application is applicable to TV services in a wireless packet-switched telecommunication network. Nevertheless the same principle is applicable to any kind of multi-channel service, which delivers a multitude of content channels among which end-users can select one channel that should be displayed on the screen. Apart from a Mobile TV service, this is for instance the case by selecting between different live cameras as offered within the “Mobile BigBrother” service currently provided by Three-Italy.
Universal Mobile Telecommunication System UMTS is being developed to offer wireless wideband multimedia service using Internet protocol. The UMTS as a third-generation 3G mobile communication combines streaming with a range of unique services. Images, voice, audio and video content are example of multimedia services, which are delivered to the users via media streaming and download techniques, meaning that once the content has been put onto a media server, it can be delivered on-demand via download or streaming. To download content, the user clicks on a link and waits for the content to be downloaded and playback to begin. To access streaming data, the user clicks on a link to start playback, which is almost immediate. This kind of on-demand service is called personalized on-demand streaming, because the user has influence on the choice of the content. Due to the fact that streaming is a semi-real time service that receives and plays back data at the same time, it puts greater demands on protocols and service implementation, especially when the service is to work over networks with little or no quality of service, like this is the case in UMTS. Furthermore the radio resources, which are used on the last part of a transmission is to be used in an efficient way.
The streaming service in a packet-switched network might be provided both to a single user by means of the so-called unicast connections and to a group of users by means of the so-called point-to-multipoint or even multipoint-to-multipoint communication. The point-to-multipoint services pose high demands on the network infrastructure and may consume considerable amounts of bandwidth. Some examples of such services are video-conferencing, whiteboarding, real-time multi-user games, multimedia messaging, virtual worlds or TV-broadcast. This kind of point-to-multipoint applications use broadcast or multicast mode for transmission. Broadcast has the possibility of addressing a packet to all destinations like to every user on the network. By means of the multicast, the content is delivered to a group of users being registered to the multicast group. However the current network evolution does not provide yet a possibility for utilisation of a streaming service on the broadcast transport technique.
Just recently, a new type of on-demand streaming service has been launched in wireless packet-switched networks, namely the so-called mobile TV services, which allows users to watch TV on their mobile phone, based on the same streaming technology, employed for personalized on-demand streaming.
However, on-demand streaming and TV streaming differ in certain usability aspects. In an on-demand streaming service, a user browses for the content until certain content is found. Subsequently, a streaming session is established during which the content of the stream, which is stored at a media server, is delivered to the users' terminal. After the stream has ended, the streaming session is terminated, and the user browses to the next content.
In a mobile TV service, the content is typically not pre-stored at a media server. Instead, it is encoded live from the signal provided by a TV channel.
Nowadays, Mobile TV services are implemented based on existing streaming technology. This means, each channel is accessed via a separate streaming sessions. However existing streaming technology does not support fast switching between channels as needed in a Mobile TV solution. Instead, switching to another channel requires to first close the session delivering the current channel, then going back to a WAP or Web page for selecting a new channel, and last but not least establishing a new streaming session. After the session is established, the client buffers data over a certain period of time (in the order of 5 seconds) before playout starts.
Tearing down the current streaming session followed by setting up a new streaming session in combination with the initial buffering delay after the new session is established results in delays around 20 to 30 seconds for switching between channels. This is clearly far too high compared with the expectations that users have from their TV experience at home.
Therefore the problem is basically that there is no flexible mechanism within the network to let users switch between channels of an ongoing on-demand streaming session. Currently, switching between channels providing the content of the on-demand service requires that an ongoing session is first closed and a new session for the new channel is set-up. Closing one streaming session and setting up a new one introduces a delay of several seconds. After the new streaming session is established, the client buffers incoming packets over certain period of time until playback starts.
It is an object of the present invention to provide a solution for providing a time-efficient on-demand multi-channel streaming service within a telecommunication network. In particular it is object of the present invention to reduce delays in channel switching during an ongoing on-demand streaming session.
The invention is embodied in a method as disclosed in claims 1, 10, 15, 16 and 17. Advantageous embodiments are described in the dependent claims.
The basic idea of this invention is to avoid separate streaming sessions for accessing different channels belonging to the same service. This is achieved by establishing only one streaming session in the beginning over which only those RTP packets are forwarded to the end-user, which belong to the selected channel.
The present invention is claimed in claim 1 describing a method, which is to be described at the server side. In claim 10 a method claiming steps to be performed at the user node are described. In claim 15 the server with its units is claimed and in claim 16 the units of the user node.
The method described in this invention has the advantage of achieving a considerable less delay in switching between channels offered via packet-switched streaming compared to state-of-the-art solutions. Furthermore the invention might be integrated with a minimum impact in the existing protocols, like the Session Description Protocol SDP, in the existing network nodes. It also has only minimal impact on existing streaming client implementation, since channel switching is done in a way, which is transparent to the client.
In the following a detailed description of the invention is given.
In the following preferred examples of the present invention shall be described in detail, in order to provide the skilled person with thorough and complete understanding of the invention, but these detailed embodiments only serve as examples of the invention and are not intended to be limiting. The following description shall make reference to the enclosed drawings, in which
It should be noted that the terms “user”, “server”, “client” or generally “node” in the context of the present invention refers to any suitable combination of hardware and software for providing a predetermined functionality in the communication network. In this way, said terms generally refers to a logical entity that can be spread out over several physical nodes of the network, but can also refer to a physical entity located in one physical node. It is to be noted that the terms “client” and “user” are used as synonyms.
Furthermore it should be noted that the term packet-switched on-demand streaming refers to any kind of service, which provides a multitude of content channels. A preferred embodiment is a TV like service.
Preferably, the communication network is a mobile communication network, e.g. is a mobile communication network operating according to GPRS (General Packet Switched Radio) or UMTS (Universal Mobile Telephone System) or GSM. However, the present invention is also applicable in any communication network with the ability to deliver streaming services. In the following an embodiment relating to a mobile network is disclosed. However, it should not be seen as a restriction. Further example is any IP-based communication network.
In the following the steps that are to be performed at the server side are presented in respect to
Corresponding steps are to be also performed at the user side. These steps are described in the following in respect to
In the following a preferred embodiment of the present invention is described in respect to
First, some of the used terms and function being relevant for the explanation of the preferred embodiment are described in some details.
The streaming data is distributed by means of streaming protocols, in particular by means of Real-time Transport Protocol RTP. RTP provides end-to-end network transport functions suitable for applications transmitting real-time multimedia data, such as audio and video over multicast or unicast network services. The functions provided by RTP include payload type identification, sequence numbering, timestamping, and delivery monitoring. The RTP contains a related RTP Control Protocol RTCP augmenting the data transport, which is used to monitor the QoS and to convey information about the participants in an ongoing session. Each media stream in a conference is transmitted as a separate RTP session with a separate RTCP stream.
The Real Time Streaming Protocol RTSP provides session control for streaming sessions and is responsible for establishment of a streaming connection. In particular RTSP establishes and controls either a single or several time-synchronized streams of continuous media such as video and audio. In other words RTSP acts as a “network remote control” for a multimedia server. RTSP is not connected to any transport protocol. That means that as well TCP as UDP might be used for the transport purpose. Furthermore the streams controlled by RTSP may use RTP for the transport purpose of the streaming data. A complete RTSP session, like for example viewing a movie consist of a client setting up a transport mechanism, for example by means of RTSP SETUP message, starting the stream with PLAY and closing the session with TEARDOWN. In respect to
The set of streams to be controlled by RTSP is described by a presentation description, like or example by a Session Description Protocol SDP as specified in RFC 2327 “SDP: Session Description Protocol” by M. Handley, V. Jacobson, April 1998. SDP describes multimedia sessions for the purpose of session announcement or session invitation in order to allow the recipients of a session description to participate in the session. Actually the SDP is purely a format for session description. It does not incorporate a transport protocol therefore is intended to use different transport protocols like for example RTSP. SDP session descriptions are entirely textual consisting of a number of text of the form <type>=<value>, describing for instance the used codecs and bitrates. In the following some lines of a SDP description are given, wherein the optional items are marked with a “*”.
In a preferred implementation the description of the channel bundle is put into a specially formatted string following the “s=” line in SDP. As an alternative it could also be put into a separate configuration element (e.g. XML)
Returning to
In the following the inter-processing of the nodes and their functionality is described in respect to
As already mentioned each live encoder takes as input an analog video/audio signal, which it compresses. LE#1 . . . LE#n. The resulting bitstream is then packetized and delivered as an RTP flow to the server. Each live encoder also produces an SDP file, SDP#1 . . . SDP#n, which contains a description of the stream generated by the live encoder. An example of a typical SDP is the following:
Herein the line starting with “s=” contains a string describing the stream, in this case it is “Channel One”. A streaming client usually puts this information into a title bar above or below the video window.
The aim of the SDP aggregator, 20A is it to generate from a number of the SDPs, SDP#1 . . . SDP#n of the Live Encoders LE#1 . . . LE#n a single SDP, 20A′. This SDP contains all information needed by the client and the server for controlling the service. By comparing the appropriate attribute lines in the various SDP files, the SDP aggregator verifies that within a channel bundle all channels are encoded at the same bitrate with the same codecs. The SDP aggregator then generates one single SDP, which describes the complete channel bundle.
In a preferred embodiment, the new SDP, 20A′, describing the complete channel bundle looks like a standard SDP. All information about the aggregated channels is contained in the “s=” attribute line.
The idea is to use a specially formatted string, which can be interpreted by a Software running on the client. The string contains per channel a unique identifier by which the channel can be referenced together with the human readable channel identifier taken from the SDP produced by the Live Encoder. For example assuming that there are two channels “Channel One” and “Channel Two”. “Channel One” is described by the aforementioned SDP description. “Channel Two” is described by the following SDP:
Thus, the only difference in the two SDPs description is in the “s=” and in the “m=” line. The “s=” contains “Channel Two” instead of “Channel One” as channel identifier, the “m=” line contains 6952 instead of 6950 as the RTP port number over which the RTP packets are delivered. Note that the live encoders have to be configured such that not two of them are using the same port number.
As already mentioned the task of the SDP aggregator is to merge the two SDPs into a new one, which looks like the following:
Herein the “s=” line contains the string “1:RAI Uno; 2:RAI Due” and the “m=” line contains 0 as a new port number. This indicates that the port number is negotiated when the RTSP session is established. The configuration string tells the client that this bundle contains two channels, “Channel One” and “Channel Two”, referenced by the unique identifier “1” and “2”, respectively. In addition an “a=” line with a fully specified RTSP control URL was added.
Returning to
As an alternative, the client first receives the RTSP URL, like for example rtsp://mobiletv.com/Bundle-1 in the above mentioned example, and the SDP is then delivered to the client during the RTSP session setup. In respect to
The list of available channels can be displayed upon user request in a channel selection menu. The entries of this list are also used to display a channel identifier in a title bar above or below the video window.
The user also has the possibility to map entries of this list to particular keys on the phone. In this way, the mobile phone keyboard can be used and programmed like a remote control.
For the purpose of the establishment of a RTSP session the client uses the RTSP URL from the SDP file or the RTSP URL, which it finds on a web page to setup the streaming session. This corresponds to switching on the Mobile TV receiver, 24,25.
It is proposed that by default, the server starts to deliver the channel corresponding to the first entry in the channel bundle description string delivered within the SDP described above. Alternatively, the server starts to deliver the channel to the user, which was delivered as the last one during the last session.
If the user triggers a switch to a new channel, the mobile TV application signals the new channel to the channel switch control 20C with the step 26 in respect to
It is proposed that the channel switch requests, 26 is signaled “in-band” directly to the streaming server via the RTSP streaming session control protocol or “out-band” using e.g. the HTTP protocol. In the latter case, the switch request must contain not only the channel address, which is available to the Mobile TV Application but also a unique identifier of the affected streaming session, such that the streaming server knows, for which session a channel switch should be executed.
In a preferred embodiment the RTSP SET_PARAMTER message, being sent by means of the connection 26, is used for in-band signaling as outlined in the following example:
In this example the client sends an RTSP SET_PARAMETER command containing the message “Channel: 2” to the server, telling the server that it should switch to channel “2” (in our example “Channel Two”). The user's request, 27, for switching a channel is forwarded from the Channel Switch Control, 20C, on the user side to the Channel Switch Control, 20D, on the network side, namely on the server.
The channel switch control unit at the server handles the switch request and decides at which point in time RTP packets belonging to the new channel are to be forwarded to the client. This is also the reason for having the channel switch control unit since switching from one channel to another is only possible at certain synchronization points. Synchronization points mark positions, 20F, in the data flow at which decoding of the channel can be started even if no other data for this channel has been received before. For instance, decoding of a video stream can only be started at so-called Intra frames, which are encoded without reference to any previously transmitted pictures. Lowest switching delay is achieved if every frame is encoded as an Intra-frame since then decoding of a video stream can start at every frame. However, Intra-frames require considerably more bits than frames, which are encoded with reference to a previously transmitted frame. Therefore, a video stream should not contain too many Intra-frames. However, to avoid long delays during channel switching there should be at least one Intra-frame every two to five seconds. Another advantage of having frequent Intra-frames is that if a transmission error introduces an error into the received video, this error will vanish after the next Intra-frame. It is to be noted that the Intra-frame interval can be configured at the live encoder.
For the client it is not possible to “guess” at what point in time content from the new channel is on the display. For the client switching between channels is transparent. Therefore, the client has no indication at what point in time content belonging to the new channel is received. One solution would be to use an estimate for the delay between signaling a channel switch until the content of the new channel appears in the client's video window. However, this does not give accurate results since this delay depends on many factors for instance the delay for the signaling itself, processing delays at the server, time until the next synchronization point from which on packets belonging to the new channel are forwarded to the client, amount of client-buffered data belonging to the old channel and so on. Therefore it is hard to predict.
The server has buffers for buffering the RTP flows, RTP Flow#1 . . . RTP Flow#n with their switching points 20F. Said RTP flows are provided to the channel selection unit, 20E, which also receives a request from the channel switch control unit, 20D. The task of the channel selection unit is to synchronize the execution of the switch command with respect to the possible switching points. Thus, when receiving a switch request, the channel selection unit first inspects the queue of RTP packets for that flow which corresponds to the new channel in order to identify the earliest possible switching time. This time is then signaled back, 29, 30, to the client as response to the RTSP SET_PARAMETER request, which has triggered the execution of the channel switch. The client then knows at which point in time the content of the new channel is displayed on the screen and can change the title bar accordingly.
In a preferred implementation the time is signaled in the NPT (normal play time) format commonly used in RTSP.
An example of a response to the switch request shown in the previous subsection is the following, which is sent via the communication 30:
With this message the server confirms that it has received the switch request for channel 2 and that display of channel 2 will start at second 32 after the start of the session.
Subsequently the channel selection unit continues to forward packets belonging to the current channel until the playback time has reached the identified switching point. From that point onwards, RTP packets belonging to the new channel are forwarded.
The switch control unit, 20D also takes care of rewriting the RTP header of the outgoing RTP packets, 20G. This is necessary, since the header information of the RTP packets generated by the different live encoders is not synchronized. The RTP headers of different RTP flows carry different SSRCs, different sequence numbers and different RTP playout time. In order to emulate one single RTP flow, the switch control unit at the server synchronizes the RTP flows of the different live encoders to a common playout timeline and sequence number space. This is achieved by rewriting the relevant fields in the RTP.
This is explained in the following example. Let's assume that Live Encoder 1 (LE1) delivers RTP packets with the following headers to the server:
Herein the line
Let's further assume that Live Encoder 2 (LE2) delivers the following RTP packets:
We further assume that a client has requested a switch from stream 1 to stream 2 and that it was determined that the switch to stream 2 shall be executed at packet 3. An example for the flow of RTP packets delivered from the server to the client is the following sequence:
It can be seen that the RTP header information of the original RTP packets was rewritten such that the resulting RTP stream does not contain any “jumps” neither in sequence numbers SN nor in time stamps TS. Also the SSRC identifier was changed accordingly. However, the payload is copied from stream 1 for the first two packets and from stream 2 starting with packet 3 for all following packets.
The channel switch control unit, 20C at the client is arranged to receive the playout time, 31 of the currently displayed frame from the streaming player. It compares this time with the channel switch time, which was signaled back from the server. If the playout time is larger than the channel switch time, the channel switch control unit generates a trigger for the Mobile TV application, 32, which then changes the channel identifier in the title bar of the video window.
Session teardown (e.g. switching off the mobile TV receiver) is handled like in standard RTSP streaming and therefore it will not be described further.
Although the present invention has been described primarily with respect to method steps, it is noted that the present invention can not only be embodied in the form of a method, but also in the form of a computer program product comprising a computer program that is arranged to perform such a method when executed on a node of a data unit transport network. The computer program product can e.g. be a computer program itself or a computer program carrier that carries the computer program.
Furthermore, the present invention can also be embodied in the form of appropriate nodes such as the server and the user node mentioned in
Furthermore, the server 40 preferably also comprises a queue buffer (not explicitly shown in
The previously described nodes, 40 and 50 can be provided by any suitable combination of hardware and software. They are also part of a system 60 as it is depicted in
The present application is applicable for a TV like service in a wireless packet-switched telecommunication network. Nevertheless the same principle is applicable to any kind of service, which delivers a multitude of content channels among which end-users can select. Apart from a Mobile TV service, this is for instance the case by selecting between different live camera signals.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP05/50544 | 2/8/2005 | WO | 00 | 9/27/2007 |