专利名称：在分组交换网络上的按需多频道流会话的制作方法
技术领域：
本发明提供一种用于分组交换通信系统中的多频道实时流业务的 性能改善的解决方案。
特别地，本申请可应用于无线分组交换电信网络中的电视业务。 然而，相同的原理可应用于任何种类的多频道业务，该多频道业务传 递多个内容频道，终端用户可以在该多个内容频道中选择一个应在屏 幕上被显示的频道。除了移动电视业务之外，这是例如通过在如由
Three-Italy当前提供的"Mobile BigBrother"业务中所提供的不 同实况摄像机之间进行选择的情况。
背景技术：
带多媒体业务。作为第三代3G移动通信的UMTS结合流式传输 (streaming)和大量独特业务。图像、语音、音频和视频内容是多媒 体业务的例子，这些多媒体业务经由媒体流和下载技术被传递到用 户，这意味着一旦内容已经被放置到媒体服务器上，该内容就可以按 需经由下载或流式传输被传递。为了下载内容，用户点击链接并等待 内容被下载并开始播放。为了访问流数据，用户点击链接以开始播放， 播放几乎是即时的。这种按需业务被称作个性化按需流，因为用户对 内容的选择有影响。由于流是同时接收和播放数据的半实时业务的这 一事实，尤其当业务将在具有小的业务质量或没有业务质量的网络上 工作时，流对协议和业务实施提出较大的要求，如在UMTS中情况如此。 此外，在传输的最后的部分上所使用的无线电资源将以有效的方式被 使用。
分组交换网络中的流业务可以借助所谓的单播连接被提供给单个 用户并借助所谓的点对多点或者甚至多点对多点通信被提供给一组用 户。点对多点业务对网络基础结构提出高要求并且可能消耗相当大的 带宽量。这种业务的一些例子是视频会议、白板(whiteboarding)、 实时多用户游戏、多媒体消息、虚拟世界或电视广播。这种点对多点 应用将广播或组播模式用于传输。广播具有将分组寻址到所有目的
地、像寻址到网络上的每个用户那样的可能性。借助组播，内容被传 递至向组播组注册的一组用户。然而，当前网络演进还不提供在广播 传输技术上利用流业务的可能性。
不过最近， 一种新类型的按需流业务已经在无线分组交换网络中 被展开，即所谓的移动电视业务，其允许用户基于相同的被用于个性 化按需流的流技术在他们的移动电话上观看电视。
然而，按需流和电视流的区别在于确定的可用性方面。在按需流 业务中，用户浏览内容直到确定的内容被找到。随后，建立流会话， 在该流会话期间流的内容被传递到用户的终端，该流的内容被存储在 媒体服务器上。在流结束之后，流会话被终止，并且用户浏览下一内 容。
在移动电视业务中，内容典型地不预先存储在媒体服务器上。代
替地，该内容根据由电视频道提供的信号实时地(live)被编码。
现在，移动电视业务基于现有的流技术来实施。这意味着每个频 道经由单独的流会话被访问。然而，现有的流技术不支持如在移动电 视解决方案中所需要的在频道之间的快速切换。代替地，切换至另一 个频道需要首先关闭传递当前频道的会话，然后返回到WAP或Web页 面以便选择新频道，但是最后不只是建立新的流会话。在建立了会话 之后，客户端在播放开始之前在某一时间段(大约5秒钟)内緩冲数 据。
拆除当前流会话并且之后建立新的流会话与在建立该新的会话之 后的初始緩冲延迟相结合导致对频道之间切换的大约20至30秒的延 迟。显然，这与用户根据他们在家的电视体验而具有的期望相比是极 其高的。
因此，问题基本上在于在网络内不存在使用户在正在进行的按需 流会话的频道之间切换的灵活机制。当前，在提供按需业务的内容的 频道之间切换需要首先关闭正在进行的会话并且建立用于新频道的新 会话。关闭一个流会话以及建立一个新的流会话引入数秒的延迟。在 建立了新的流会话之后，客户端在某一时间段内緩冲输入的分组，直 到播放开始。
发明内容
本发明的目的是提供一种用于在电信网络内提供时间高效的按需
多频道流业务的解决方案。特别地，本发明的目的是减小在正在进行 的按需流会话期间进行频道切换的延迟。
本发明以如权利要求l、 10、 15、 16、 17中所/>开的方法来实施。 有利的实施方式在从属权利要求中被描述。
本发明的基本思想是避免用于访问属于相同业务的不同频道的单 独的流会话。这是通过在开始时只建立一个流会话来实现的，只有那 些属于所选频道的RTP分组通过该流会话被转发至终端用户。
本发明在权利要求1中被要求，权利要求1描述一种方法，该方 法应在服务器侧被描述。在权利要求IO中描述了要在用户节点处执行 的方法权利要求步骤。在权利要求15中要求了具有单元的服务器，并 且在权利要求16中要求了用户节点的单元。
在本发明中所描述的方法具有以下优点，即在经由分组交换流所 提供的频道之间切换时与现有技术解决方案相比实现明显更小的延 迟。此外，本发明可以以对现有协议(像会话描述协议SDP)的最小影 响被集成在现有网络节点中。其对现有的流客户端实施也只具有最小 的影响，因为以对客户端来说透明的方式进行频道切换。
在下文中给出了本发明的详细的描述。
在下文中将详细描述本发明的优选例子，以便为技术人员提供对 本发明的全面和完整的理解，但是这些详细的实施例只用作本发明的 例子并且并不意图进行限制。下面的描述将参照附图，其中
图1示出用于在服务器侧在正在进行的按需流会话期间执行频道 切换的本发明实施例的流程图，
图2示出用于在用户节点侧在正在进行的按需流会话期间执行频 道切换的本发明实施例的流程图，
图3示出根据本发明实施例的具有节点和接口的系统的示意性表示。
具体实施例方式
应当注意，在本发明的上下文中的术语"用户，，、"服务器，，、 "客户端，，或一般地"节点"指的是用于在通信网络中提供预定功能 的硬件和软件的任何适当组合。以这种方式，所述术语通常指的是能 够分布在网络的多个物理节点上的逻辑实体，但是也可以指的是位于
一个物理节点中的物理实体。应当注意，术语"客户端"和"用户，， 被用作同义词。
此外应当注意，术语"分组交换按需流"指的是提供多个内容频 道的任何种类的业务。优选的实施例是类似电视的业务。
优选地，所述通信网络是移动通信网络，例如是根据GPRS(通用 分组交换无线)或UMTS (通用移动电话系统)或GSM运行的移动通信 网络。然而，本发明也可应用于任何有传递流业务的能力的通信网络 中。在下面公开了涉及移动网络的实施例。然而，该实施例不应当被 看作限制。进一步的例子是任何基于IP的通信网络。
在下面针对图1来介绍要在服务器侧执行的步骤。图1是用于在 服务器侧在正在进行的按需流会话期间执行频道切换的本发明实施例 的流程图。在步骤Sll中，聚合频道束会话描述被提供给用户。所述 聚合频道束会话描述包括为所述束的一部分的频道的唯一标识。聚合 频道束会话描述被发送至用户以便将具有多个频道的按需流会话通知 用户。如果用户对接收所述会话感兴趣，则通过将聚合频道束会话描 述用作会话的标识来建立用户节点和服务器之间的流会话，步骤12。 如果用户希望在可用频道之间切换，则相应的消息、即频道切换请求 消息从用户节点被发送，请求从第一频道切换到第二频道，步骤13。 随后执行频道切换过程。在该切换过程内确定用于执行频道切换的合 适的切换点，步骤14.重要的是选择合适的切换点，以便避免图像质 量的不必要的失真，如将在说明书的随后的部分中更详细地描述的那 样。利用步骤S15，第二频道的媒体数据被提供给用户，其中提供的起 始点通过所确定的切换点来确定，步骤S15.
相应的步骤也将在用户侧被执行。这些步骤在下面针对图2来描 述。用户节点从服务器接收建立的单个频道束会话描述，S21。随着单 个频道束会话描述的接收，他具有关于通过所述会话描述所描述的可 用频道的信息。如果他希望接收这些频道之一的内容，则在用户节点 和服务器之间建立流会话，S22。为了在为束的一部分的频道之间切 换，用于从第一频道切换到第二频道的频道切换请求消息被发送至服 务器，S23。随着该消息的接收，用于估计合适的切换点以便执行如上 述的频道切换的频道切换过程在服务器处被启动。在服务器处执行了 频道切换过程之后，用户能够接收在所确定的切换点起始的第二频道
的内容，S24。以媒体分组形式接收的内容随后被解码并被传递至用户 界面，在该用户界面处这些内容被播放。
在下面针对图3来描述本发明的一个优选实施例。图3中的方框 表示在通过流传输技术提供移动电视时所包含的节点。节点之间的箭 头指示在节点之间执行的通信步骤。
首先，在一些细节上描述对于优选实施例的解释来说相关的所使 用的术语和功能中的一些。
借助流协议、特别是借助实时传输协议RTP来分发流数据。RTP 提供端到端网络传输功能，这些功能适合于通过组播或单播网络业务 传送实时多媒体数据、诸如音频和视频的应用。由RTP提供的功能包 括有效载荷类型标识、顺序编号、时间戳和传递监视。RTP包含相关的 加强数据传输的RTP控制协议RTCP，该RTP控制协议被用于监视QoS 并传送关于正在进行的会话中的参与者的信息。会议中的每个媒体流 作为具有单独的RTCP流的单独的RTP会话被传输。
实时流协议RTSP提供对流会话的会话控制，并负责流连接的建 立。特别地，RTSP建立并控制单个或多个诸如视频和音频的连续媒体 的时间同步流。换句话说，RTSP担当多媒体服务器的"网络远程控制，，。 RTSP不连接到任何传输协议。这意味着TCP以及UDP可能被用于传输 目的。此外，由RTSP控制的流为了流数据的传输目的可以使用RTP。 完整的RTSP会话、诸如观看电影包括客户端例如借助RTSP SETUP 消息建立传输机制，以PLAY开始流并以TEARD0WN关闭会话。就图3 而言，速些步骤借助连接24和25被描述。RTSP的详细的描述可以在 由H. Schulzrinne、 A. Rao、 R. Lanphier于1998年四月所著的RFC 2326 "Real Time Streaming Protocol (实时流协议)，，中找到。
要由RTSP控制的流的集合通过表示描述被描述，像或例如通过如 在M. Handley、 V. Jacobson于1998年四月所著的RFC 2327 "SDP: Session Description Protocol (SDP:会话描述协议)，，中所说曰月 的会话描述协议SDP被描述。SDP为了会话通知或会话邀请的目的而描 述多媒体会话，以便会话描述的接收者参与会话。实际上，SDP纯粹是 一种用于会话描述的格式。它不包括传输协议，因此意图使用不同的 传输协议、诸如RTSP。 SDP会话描述完全是文本的，包括多个格式为 〈typeXvalue〉的文本，例如描述所^吏用的编解码器和比特率。在下
面给出了 SDP描述的一些行，其中可选项被标以"'"。
(协议版本)
0 =(拥有者/创建者和会话标识符)
s =(会话名称)
i='(会话信息)
u=*(描述的URI)
6=,(电子邮件地址)
P='(电话号码)
C=*(连接信息)
b='(带宽信息)
z=*(时区调整)
k='(加密密钥)a=.(零或更多会话属性行)
t=(会话有效的时间)
r='(零或更多重复次数)
m=(媒体名称和传输地址)i=.(媒体标题)c=.(连接信息)
b='(带宽信息)
k=*(加密密钥)
a=*(零或更多媒体属性行)
在优选实施中，频道束的描述被置于SDP中的"s="行之后的专 门格式化的字符串中。作为替代方案，它还可以被置于单独的配置元 素(例如XML)中。
返回到图2，存在SDP聚合器20A，提供频道束描述20A'，该频道 束描述由多频道流客户端(例如移动电视应用)20B处理。图3的顶部 左侧示出实时(Live)编码器LE#1至LE#n。每个实时编码器把模拟 视频/音频信号作为输入，该模拟视频/音频信号首先被转化为数字信 号并且然后通过媒体编码器被压缩。所产生的比特流然后被分组并作 为RTP分组流RTP流"…RTP流#11被传递至流服务器，终端用户、客 户端能够连接到该服务器上。流服务器具有频道切换控制单元20H，其 将被进一步详细描述。在频道切换控制单元中，存在频道切换控制20D，其与用户侧的适当的频道切换控制20C通信。在服务器侧也存在 与用户侧的RTSP控制20J通信的RTSP控制201。来自服务器的流数 据通过单个"移动电视"RTP流33被传输至RTP处理20K，该RTP处 理是还包括媒体解码20L和播放功能20M的单元的一部分，将数据转 发34给用户设备20N。
在下面，节点间处理(inter-processing )和节点的功能将针对 图3来描述。
如已经提到的，实时编码器把其所压缩的模拟视频/音频信号 作为输入。LE#l. LE#n。所产生的比特流然后被分组并作为RTP流被 传递至服务器。每个实时编码器还产生SDP文件SDP#l...SDP#n，该SDP 文件包含由该实时编码器生成的流的描述。典型的SDP的例子如下
v。0
o-Live Encoder 1S843009 1 IN IP4 127,0.0,1
S"Chatmel One
c-IN IP4 192.168,16,254
t=0 0
b=AS:128
a^control:*
a=range: npt= 0-
ni-video S950 RTP/AVP 96
b=AS:128
a=rtpmap:96 MP4V-ES/30000 a=controls trackID=l a=iraiige snpt—O-a=fmtp:96 profile-level-
id=87Config-000001B008000001B5090000010000 0001200084400668282078A21F
在此以"S ="开始的行包含描述流的字符串，在这种情况下该字
符串是"Channel One"。流客户端通常将该信息置于视频窗口上方或 下方的标题栏中。
SDP聚合器20A的目的是根据实时编码器LE#l. LE#n的多个 SDP、即SDP并l…SDP并n生成单个SDP 20A'。该SDP包含客户端和服务 器控制业务所需要的所有信息。通过比较各种SDP文件中的合适的属 性行，SDP聚合器验证在频道束内所有频道都利用相同的编解码器以相 同的比特率被编码。SDP聚合器然后生成一个单个SDP，其描述完整的 频道束。
在优选的实施例中，描述完整的频道束的新的SDP 20A'看起来像 标准SDP。所有关于聚合频道的信息都被包含在"s-"属性行中。
构思是使用专门格式化的字符串，该字符串可以由运行在客户端 上的软件解释。该字符串针对每个频道包含唯一的标识符，通过该标
识符，频道可以与从SDP获得的人可读的频道标识符一起被引用，其 中该SDP由实时编码器产生。例如假设有两个频道"Channel One"和
"Channel Two" 。
"Channel One"通过前述的SDP描述来描述。
"Channel Two"通过下面的SDP来描述
o。Live Encoder 16843009 1 IN IP4 127,0*0*1
s=Ch3nti6l Two
c-IN IP4 192.168,16*254
t=0 0
b=AS:128
a=control:*
a一range:npt=0-
m=video 6952 RTP/AVP 96
b=ASsl28
a>=rtpmaps96 MP4V-ES/90000 3。contJ:o1 j trsckID=l a =range: npt一O-a=fmtp s 9 6 profile-level-
ids8,'config"000001B008000001B5090000010000 0001200084400668282078A21F
因此，两个SDP描述的唯一差别在于"s ="和"m="行。"s-" 包含"Channel Two"而不是"Channel One"作为频道标识符，"m ="行包含6952而不是6950作为RTP端口号，其中RTP分组通过该 RTP端口号被传递。注意，实时编码器必须被配置，以便它们中的两个 不使用相同的端口号。
如已经提到的，SDP聚合器的任务是将两个SDP合并成一个新的 SDP，该SDP看起来如下
o=Live Encoder 16843009 1 IN工P4 127.0H s*l:Chann l Ona, 2: Channel Two
c=IN工P4 192.168.16,254
t=0 0
t -AS:128
a。contro;L: rtsp: //mobiletv com/Bundle-1 3—ange s np t-0— ms7idao 0 BXP/AVP 96
t>=AS:128
a=rtpmaps9S ES/90000
a=conti:ol - rtsp s / /瓜obiletv, com/Bundl，(-
lstrackID-l
a=range s npt—O—
a—fnvtps96 profile—level-
id= 8,-COnfig=0D0001BD08000001B5090000010000 0001200084400668282078A21F
在此"s =，，行包含字符串"1:RAI Uno; 2: RAI Due"并且"m ="行包含O作为新的端口号。这指示当RTSP会话被建立时协商端口 号。配置字符串告诉客户端该束包含两个频道、即分别通过唯一的 标识符T和"2"来引用的"Channel One"和"Channel Two"。 另外，添加了具有完全指定的RTSP控制URL的"a=，，行。
返回到图3，描述频道束的SDP可以以各种方式被传递至客户端。 客户端例如可以 <吏用 URL http i也址、诸如 http: 〃mobiletv. com/Bundle-lsdp从Web月良务器下载SDP。
作为替代方案，在上面提到的例子中客户端首先接收RTSP URL， i者如rtsp: //mobiletv. com/Bundle-l，然后在RTSP会话建立期间将 SDP传递至客户端。针对图3，这是在连接22'上通过将描述字符串转 发至移动电视应用20B来完成的。移动电视应用解析该字符串并根据 该字符串生成可用频道的列表。
可用频道的列表可以根据用户请求而显示在频道选择菜单中。该 列表的条目还被用于在视频窗口的上方或下方的标题栏中显示频道标 识符。
用户还具有将该列表的条目映射为电话上的特定键的可能性。以 这种方式，移动电话键盘可以像遥控器一样被使用和编程。
为了建立RTSP会话的目的，客户端使用来自SDP文件的RTSP URL 或者在web页面上找到的RTSPURL来建立流会话。这对应于接通移动 电视接收机24、 25。
建议通过默认，服务器开始传递频道，该频道对应于频道束描 述字符串中的第一个条目，该频道束描述字符串在上面所描述的SDP 内被传递。替代地，服务器开始将频道传递至用户，该频道在最后的 会话期间作为最后一个频道被传递。
如果用户触发至新频道的切换，则移动电视应用利用根据图3的 步骤26将新频道用信令通知频道切换控制20C。
建议将频道切换请求26经由RTSP流会话控制协议直接用"带 内(in-band)"信令通知流服务器或者使用例如HTTP协议用"带外 (out-band)"信令通知流服务器。在后一种情况下，切换请求必须 不但包含移动电视应用可用的频道地址，而且还包含受影响的流会话 的唯一标识符，以便流服务器了解频道切换应针对哪个会话被执行。
在优选实施例中，借助连接26发送的RTSP SET-PARAMETER消息 被用于带内信令，如在下面的例子中略述的
<formula>formula see original document page 14</formula>
Channels 2
14
在该例子中客户端发送包含消息"Channel: 2"的RTSP SET—PARAMETER命令至服务器，告诉服务器其应当切换至频道"2"(在 我们的例子中"Channel Two")。用于切换频道的用户请求27从用 户侧的频道切换控制20C被转发至网络侧的、即服务器上的频道切换 控制20D。
服务器上的频道切换控制单元处理该切换请求并决定在哪个时间 点属于新频道的RTP分组将被转发至客户端。这也是具有频道切换控 制单元的原因，因为从一个频道至另 一个频道的切换只能在确定的同 步点进行。同步点标记数据流中的位置20F，在这些位置上，即使之前 没有接收到该频道的其它数据，也可以开始该频道的解码。例如，视 频流的解码可以仅仅以所i胃的内帧(Intra frames)开始，这些内帧 在不参考任何先前所传送的图像的情况下被编码。如果每个帧作为内 帧被编码，则实现最低切换延迟，因为于是视频流的解码可以开始于 每个帧。然而，和参考先前所传送的帧被编码的帧相比，内帧需要显 著更多的比特。因此，视频流不应当包含太多的内帧.然而，为了避 免在频道切换期间的长的延迟，每二至五秒应当有至少一个内帧。具 有频繁的内帧的另 一个优点是如果传输差错将差错引入到所接收的 视频中，则该差错将在下一个内帧之后消失。应当注意，内帧间隔可 以在实时编码器处被配置。
对于客户端来说，不可能"猜到"在哪个时间点来自新频道的内 容被显示。对于客户端来说，在频道之间的切换是透明的。因此，客 户端不具有在哪个时间点属于新频道的内容被接收的指示。 一种解决 方案将是使用对在用信令通知频道切换直到新频道的内容出现在客户 端的视频窗口中之间的延迟的估计。然而，这不给出精确的结果，因 为该延迟依赖于许多因素、例如信令自身的延迟、在服务器上的处理 延迟、直到下一个同步点(从该下一个同步点起属于新频道的分组被 转发至客户端)的时间、属于旧频道的客户端緩沖的数据的数量等等。 因此该延迟是难以预知的。
服务器具有用于緩冲RTP流RTP流"…RTP流fn以及它们的切换 点2 OF的緩冲器。所述RTP流被提供给频道选择单元20E，该频道选 择单元还从频道切换控制单元20D接收请求。频道选择单元的任务是 根据可能的切换点来同步切换命令的执行。因此，当接收到切换请求
时，频道选择单元首先检查对应于新频道的流的RTP分组的队列，以 便识别最早的可能的切换时间。然后将该时间用信令通知29、 30客户 端，作为对RTSP SET-PARAMETER请求的响应，其中该请求已经触发 频道切换的执行。于是客户端知道在哪个时间点新频道的内容被显示 在屏幕上并且可以相应地改变标题栏。
在优选实施中，以RTSP中通常所使用的NPT (正常播放时间)格 式用信令通知该时间。
在先前的部分中所示出的对切换请求的响应的例子如下，该响应 经由通信30被发送
S->C2 RTSP/1*0 200 OK CSeq: 10
Content—Lengths 20 Content-Type: text/parameters
Channel: 2 SwitchPoint: npt=32-
利用该消息，服务器确认其已经接收到对频道2的切换请求并且 频道2的显示将开始于会话开始之后的第32秒。
随后，频道选择单元继续转发属于当前频道的分组，直到播放时 间已经到达所识别的切换点。从该点开始，属于新频道的RTP分组被 转发。
切换控制单元20D还负责重写输出的RTP分组20G的RTP报头。 这是必要的，因为由不同实时编码器生成的RTP分组的报头信息是不 同步的。不同RTP流的RTP报头携带不同SSRC、不同序列号和不同RTP 播放时间。为了仿真一个单个RTP流，服务器上的切换控制单元将不 同实时编码器的RTP流同步至公共播放时间线(timeline)和序列号 空间。这是通过重写RTP中的相关字段来实现的。
这在下面的例子中被解释。让我们假设实时编码器1 (LEI)将具 有下列报头的RTP分组传递至服务器
1) <SN=1001 TS=9000 SSRC=12345678> <Payload 1.1>
2) <SN=1002 TS=18000 SSRC=12345678> <Payload 1.2>
3) <SN=1003 TS=27000 SSRC=12345678> <Payload 1. 3>
4) <SN=1004 TS=36000 SSRC=12345678> 〈Payload 1.4>
5) <SN=1005 TS=45000 SSRC=12345678> 〈Payload 1.5> 在此，行
1) <SN=1001 TS=9000 SSRC=12345678> <Payload 1. 1>
意味着分组1在其RTP报头中携带序列号SN^001、时间戳TS-90000、 以及同步源标识符SSRC=12345678，并且其传递媒体有效载荷1. 1，该 媒体有效载荷1. 1涉及流1的第一分组的媒体有效载荷。
让我们进一步假设实时编码器2 (LE2)传递下面的RTP分组
1) <SN=2011 TS=15000 SSRC-87654321> 〈Payload 2.1>
2) <SN=2012 TS=24000 SSRC-87654321> <Payload 2.2>
3) <SN=2013 TS=33000 SSRC=87654321> 〈Payload 2.3>
4) <SN=2014 TS=42000 SSRC=87654321> <Payload 2.4>
5) <SN=2015 TS=51000 SSRC=87654321> <Payload 2.5> 我们进一步假设客户端已经请求从流1切换至流2，并且确定了至
流2的切换将在分组3处被执行。从服务器被传递至客户端的RTP分 组流的例子是下面的序列
1) <SN=10000 TS=90000 SSRC=7236237 <Payload 1.1>
2) <SN=10001 TS=99000 SSRC=7236237> 〈Payload 1.2>
3) <SN=10002 TS=108000 SSRC=7236237> 〈Payload 2. 3>
4) <SN=10003 TS=117000 SSRC=7236237> <Payload 2.4>
5) <SN=10004 TS=126000 SSRC=7236237> 〈Payload 2.5> 可以看到原始RTP分组的RTP报头信息被重写，以致所产生的
RTP流既不包含序列号SN的任何"突变(jump)"，也不包含时间戳 TS的任何"突变"。同样，SSRC标识符被相应地改变。然而，针对前 两个分组从流1复制有效载荷，并且针对所有随后的分组从开始于分 组3的流2复制有效载荷。
客户端上的频道切换控制单元20C被布置用于从流播放器接收当 前所显示的帧的播放时间31。该频道切换控制单元将该时间与从服务 器用信令通知的频道切换时间相比较。如果播放时间大于频道切换时 间，则频道切换控制单元生成移动电视应用的触发器32，该触发器然 后改变视频窗口的标题栏中的频道标识符。
会话拆除(例如切断移动电视接收机)像在标准RTSP流中一样被 处理，因此将不进一步被描述。
虽然本发明已经主要根据方法步骤被描述，但应当注意本发明不 但能够以方法的形式被实施，而且还可以以计算机程序产品的形式被 实施，该计算机程序产品包含计算机程序，该计算机程序被布置用于当在数据单元传输网络的节点上被执行时执行这样的方法。该计算机 程序产品例如可以是计算机程序自身或携带计算机程序的计算机程序 载体。
此外，本发明还可以以合适的节点、例如在图1中所提到的服务 器和用户节点的形式被实施。
图4示出节点40的示意图，节点40表示经由连接414至417与 用户节点通信的服务器设备。节点40包含聚合器401，该聚合器适于 聚合频道束411、 412、 413，其中频道束中的每个频道通过唯一的频 道标识符来描述。聚合器被布置用于生成单个频道束会话描述402，该 单个频道束会话描述经由连接414被提供给用户节点。此外，服务器 40具有会话建立控制单元403，适于提供用户节点和服务器之间的流 会话415。会话的建立、流会话的提供是借助频道束会话描述402来完 成的。如果用户节点决定从第一频道切换至为频道束会话描述402的 一部分的笫二频道，则相应的频道切换请求消息416在用户节点上被 生成并被提供给服务器40。频道切换控制单元404适于从用户节点接 收频道切换请求消息416。此外，频道切换控制单元404适于控制从第 一频道至第二频道的频道切换。频道切换的执行由频道选择单元405 辅助，该频道选择单元适于在第一和第二频道之间切换，其中所述频 道选择单元适于估计用于执行切换的合适的切换点并在到达所确定的 切换点时将第二频道的内容417提供给用户节点。
此外，服务器40优选地还包含队列緩冲器(在图40中未明确示 出)，用于在将通过连接411至413所接收的数据单元转发至频道选 择单元405之前将这些数据单元排对。
图5是节点50的示意表示，节点50表示经由连接414至417与 服务器40通信的用户节点。节点50包含流应用单元501，该流应用单 元适于经由连接414从服务器接收单个频道束会话描述。该单个频道 束会话描述包括频道的描述，该描述可以利用单个按需流会话被提供 给用户节点。该用户节点适于在频道束之间做出选择。频道束中的每 个频道通过被提供给用户节点50的唯一的频道标识符来描述。此外， 用户节点50还包含会话建立控制单元502，该会话建立控制单元适于 建立一个从用户节点至服务器的流会话415。会话的建立借助频道束会 话描述来执行。如果用户决定从第一频道切换至第二频道，则生成相
应的消息并且频道切换控制单元503适于发送频道切换请求消息416 给服务器40，该服务器被布置用于执行从第一频道至笫二频道的频道 切换。此外，用户节点50包含内容提供单元504，用于接收第二频道 的内容417,并将所述内容传递至用户界面518。
先前描述的节点40和50可以由硬件和软件的任何适当组合提 供。它们也是如图6中所描绘的系统60的一部分。图6示出具有接收 频道411、 412、 413的服务器40的系统。所述频道在节点40中被准 备，如上面针对图1所公开的。节点40执行如针对图1所描述的方法 步骤。还存在如针对图5所描述的执行根据图2的方法步骤的节点50。 节点40和50适于经由通信链路601彼此通信，该通信链路是就图4 和图5而言用于交换消息414至417的示意性表示。消息交换还在图 1、图2和图3的描述中被公开。
本申请可应用于无线分组交换电信网络中的类似电视的业务。不 过，相同的原理可应用于任何种类的业务，该业务传递多个内容频道， 终端用户可以在该多个内容频道中进行选择。除了移动电视业务之 外，例如还存在通过在不同现场摄像机信号之间进行选择的情况。
权利要求
1.用于将按需多频道流会话、尤其是电视会话提供给分组交换通信网络的用户节点的方法，其中所述按需多频道流会话由服务器提供并包括多个提供内容并且能够由用户节点访问的频道，并且其中所述方法包括在服务器上执行的下述步骤-将包括频道束的描述的聚合频道束会话描述提供给用户节点，其中频道束中的每个频道借助唯一的频道标识符来描述(20A，20A′，22，22′)，并且-使用聚合频道束会话描述在用户节点和服务器之间建立一个流会话(20I，25)，并且-从用户节点接收用于执行从第一频道至第二频道的频道切换的频道切换请求消息，其中频道借助唯一的频道标识符来标识(20D，20F)，并且-执行用于在第一和第二频道之间切换的频道切换过程，该频道切换过程包括确定用于执行切换的合适的切换点(20H，20F，20D，20E，20G，28，29)，以及-提供起始于所确定的切换点的第二频道的内容(33)。
2. 根据权利要求l所述的方法，其中，所确定的切换点还被提供 给用户，以便同步在客户端应用中被显示的频道标识符与频道内容。
3. 根据权利要求l所述的方法，其中，单个频道束会话描述包括 能够由在用户节点上执行的软件解释的字符串。
4. 根据权利要求l或3所述的方法，其中，聚合频道束会话描述 的提供包括验证频道束的频道是否使用相同的编解码器以相同的比特 率被编码。
5. 根据权利要求l所述的方法，其中，使用流控制协议用"带内" 信令通知或使用应用协议用"带外"信令通知频道切换请求。
6. 根据权利要求l、 2或5所述的方法，其中，频道切换在同步 点处被执行，该同步点标记内容的数据流中的位置，在该位置处频道 的解码可以在没有任何质量退化的情况下开始。
7. 根据权利要求6所述的方法，其中，同步点之间的时间距离将 被选择，以便优化频道切换延迟和压缩效率之间的折衷。
8. 根据权利要求1所述的方法，其中，进一步在频道切换过程的范围内，被提供给用户节点的频道的数据分组在服务器上通过修改输 出的数据分组的报头而被修改，以便以提供公共播放和序列号空间的 方式同步所述数据分组。
9. 用于将按需多频道流会话、尤其是电视会话提供给分组交换电 信网络的用户节点的方法，其中所述按需流会话由服务器提供并且包 括多个提供内容并且能够由用户节点访问的频道，并且其中所述方法 包括在用户节点上执行的下述步骤-从服务器接收包括频道束的描述的单个频道束会话描述，其中 频道束中的每个频道通过唯一的频道标识符来描述(20A'， 22'， 20B)，并且-使用频道束会话描述建立一个从用户节点至服务器的流会话 (24， 20J， 25)，并且-发送频道切换请求消息给服务器以执行用于在第一和第二频道 之间切换的频道切换过程，该频道切换过程包括确定用于执行切换的 合适的切换点，其中频道借助唯一的频道标识符来标识(26， 20C， 27 )， 以及 '-在到达所确定的切换点时接收第二频道的内容并将所述内容传 递给用户界面(33， 20K， 20L， 20M, 34， 20N)。
10. 根据权利要求9所述的方法，其中，单个频道束会话描述包 括能够由在用户节点上运行的流应用解释的字符串，其中可用频道的 列表被生成并呈现给用户。
11. 根据权利要求9或IO所述的方法，其中，可用频道的列表根 据用户请求被显示在频道选择菜单中，并且此外，频道标识符被显示 在视频窗口的上方或下方的标题栏中。
12. 根据权利要求9、 10或11所述的方法，其中，列表被映射为 电话上的特定键，以便像遥控器一样使用移动电话鍵盘。
13. 根据权利要求9所述的方法，其中，所确定的切换点也被提 供给用户以便同步被显示在客户端应用中的频道标识符与频道内容。
14. 根据权利要求9或13所述的方法，其中，用户节点将当前所 显示的帧和接收到的切换点相比较，并且根据结果发送触发器给流应 用以改变视频窗口的标题栏中的频道标识符。
15. 服务器(40)，适于将按需多频道流会话、尤其是电视会话 提供给分组交换无线电信网络的用户节点，其中所述按需流会话由所 述服务器提供并包括多个提供内容且能够由用户节点访问的频道，其中所述服务器包括-聚合器(401)，适于将频道束(411、 412、 413)聚合到单个 频道束会话描述中(402 )，其中频道束中的每个频道通过唯一的频道 标识符来描述，其中所述聚合器适于将所述单个频道束会话描述提供 给用户节点(414)，和-会话建立控制单元(403 )，适于提供用户节点和服务器之间的 通过频道束会话描述来标识的流会话(415)，和-频道切换控制单元(404 )，适于从用户节点接收频道切换请求 消息(416)并执行从笫一频道至第二频道的频道切换，和-频道选择单元(405 )，适于在第一和第二频道之间切换，其中 所述频道选择单元适于估计用于执行切换的合适的切换点并在到达所 估计的切换点时将第二频道的内容(417)提供给用户节点。
16. 分组交换电信网络的用户节点(50)，适于接收按需多频道 流会话，其中所述按需多频道流会话由服务器提供并包括多个提供内 容且能够由用户节点访问的频道，并且其中所述用户节点包括-流应用单元(501)，适于从服务器接收包括频道束的描述的单 个频道束会话描述(414)，其中频道束中的每个频道通过唯一的频道 标识符来描述，和-会话建立控制单元(502 )，适于借助频道束会话描述建立一个 从用户节点至服务器的流会话(415)，和-频道切换控制单元(503 )，适于从用户节点发送频道切换请求 消息(416)至服务器以执行从第一频道至第二频道的频道切换，其中 频道借助唯一的频道标识符来标识，和-内容提供单元(504 )，用于接收第二频道的内容(417)并传 递所述内容至用户界面(518)。
17. 系统(60)，适于将按需多频道流会话、尤其是电视会话提 供给分组交换电信网络的用户节点，其中所述按需流会话由服务器提 供并包括多个提供内容且能够由用户访问的频道，其特征在于，所述系统具有根据权利要求15所述的并适于执行根据权利要求1 所述的方法的服务器(40)、和根据权利要求16所述的适于执行根据 权利要求9所述的方法的用户节点(50)，其中用户节点和服务器适 于彼此通信(601)。
全文摘要
本发明提供一种用于在属于一个按需多频道流会话的频道之间切换的解决方案。建议了用于将对应于多个频道的多个会话描述参数聚合为一个单个会话描述的聚合过程。此外，每个频道通过强制的唯一的标识符来描述，该标识符可以在频道切换请求和用于显示在标题栏或频道选择菜单中的可选的人可读的标识符中被引用。相应的客户端应用处理描述频道束的SDP并使用所发现的信息以允许用户切换至与确定的标识符相关的频道。用信令通知频道切换请求优选地经由RTSPSET PARAMETR消息来实现或作为替代方案经由HTTP带外实现。为多频道流服务器的一部分的频道切换控制单元接收多个RTP流并选择流中的一个用于转发至客户端。切换点确定是频道切换控制单元的一部分并确定用于切换至所请求的频道的下一个可能的时间点。客户端应用响应于频道切换请求而接收切换点的时间信息。
文档编号H04N7/24GK101116306SQ200580047887
公开日2008年1月30日 申请日期2005年2月8日 优先权日2005年2月8日
发明者T·洛马, U·霍恩 申请人:艾利森电话股份有限公司