正在开发通用移动电信系统UMTS，以便使用因特网协议提供无 线宽带多媒体业务。UMTS作为第三代3G移动通信将流技术与一系 列独特服务(如地理定位)相结合，以向用户提供高质量的因特网内 容。移动多媒体业务的例子有图像、语音、视听内容，它们通过多媒 体流和下载技术传送给用户。这意味着一旦内容被置于媒体服务器 上，它就可以按需通过下载或流技术传送。为了下载内容，用户点击 链接并等待内容下载以及回放开始。下载功能是容易集成的，因为可 以采用超文本传输协议(HTTP)来下载文件。为了访问流数据或普 通的语音多媒体数据，用户点击链接来启动几乎立即进行的回放。因 为流式传送是一种同时进行数据接收和播放的半实时服务，所以它对 协议和服务实现有更高的要求，尤其是在该服务要在服务质量低或没 有服务质量的网络上运行时，例如UMTS中的情况。用于传输的最后 一部分的无线电资源要以更好的方式加以利用。
目前正在进行工作以将广播和组播引入WCDMA和GSM无线网 络。广播和组播均提供了传输效率并降低了内容服务器如流式服务器 上的负载。此外，正在设计一些解决方案以执行无线网络中的流式传 送或一般的系统表达的多媒体传输。在下文中，将给出对应的体系结 构。
图1显示目前所谓的多媒体广播/组播服务(MBMS)的体系结 构。在下文中，仅提到了最重要的节点和连接最终用户UE的不同接 入网(如UTRAN、GERAN)的实例。这些接入网通过服务节点SGSN 来处理，SGSN与负责连接到外部网络(如因特网)的GGSN通信。 连接到GGSN的BM-SC实体负责组播/广播的指配，例如负责承载 建立和数据转发。BM-SC提供至内容提供商的接口，以便所述内容 提供商可以请求向用户传送数据。BM-SC可以授权内容提供商并对 其收费。
为了使解决方案保持简单，目前预见，在无线电网络部分方面， 要仅支持供数据业务到最终用户UE的下行信道。这意味着，接入网 中没有上行信道可供最终用户UE用于发送例如有关接收质量的报 告。
在无线网络中，单个用户的多媒体流的传输通过分组交换流式 体系结构来执行。图2显示了所述体系结构。它显示了流式客户通 过诸如UTRAN或GERAN等接入网与UMTS核心网络连接。在UMTS 中，显示了两种重要的节点：SGSN和GGSN。SGSN是处理连接用 户的接入网的服务节点。GGSN负责与外部网络如IP网络的连接。 为了提供多媒体，IP网络中存在不同的实体，如负责提供多媒体数 据的内容服务器。
多媒体数据借助多媒体协议分发。图3显示具有负责多媒体传 输的协议层，即实时传输协议RTP的协议栈。RTP采用通用数据报 协议UDP作为适合传输流式数据的传输协议，因为虽然不象传输控 制协议TCP的情况一样可靠，但UDP可提供快速传输。HTTP和实 时流协议RTSP运行在可靠的TCP上。RTSP提供用于流式会话的会 话控制。HTTP用于静止图像、位图和文本的传输。
RTP提供端到端传输功能，适用于通过组播或单播网络服务传 送实时数据如音频、视频或模拟数据的应用。RTP提供的功能包括 净荷类型识别、序列编号、时间戳记和传送监视。RTP包含增强数 据传输的相关RTP控制协议RTCP，它用于监视QoS并传递与正在 进行的会话有关的信息。会议中的每个媒体流采用单独的RTCP流 作为一个单独的RTP会话来传送。
RTP将时间戳和序号添加到每个UDP分组的特殊RTP首部中。 时间戳涉及RTP分组的净荷中承载的媒体的采样时间或呈示时间或 合成时间。它用于以正确速度播放媒体，以及配合RTCP用于同步 其他流式媒体的呈示。净荷规范定义对该时间戳和其他RTP字段的 解释。接收方利用该序号检测分组的丢失，并可以通过RTCP将有 关分组丢失的统计数字报告给服务器。
RTCP报告提供有关从特定源端接收的数据的统计数字，如自上 次报告起丢失的分组数、累计丢失的分组数、到达时间间隔抖动等。 另一个草案定义了用于扩展RTCP发送方和接收方报告的格式。RTCP 的详细说明可以参见RFC 1889第6章。RTCP控制协议所基于的是， 采用与数据分组相同的分发机制向会话的所有参与方周期性地传送 控制分组。底层协议必须提供数据和控制分组的复用，例如将各不 相同的端口号用于UDP。
RTCP的主要功能是提供有关数据分发质量的反馈信息。此功能 是作为传输协议的RTP的主要部分，它还涉及其他传输协议的流和 拥塞控制功能。反馈信息可以直接用于诊断分发操作中的故障。向 所有参与方发送接收反馈报告允许观察问题的人对这些问题是局部 问题还是全局问题进行评估。利用诸如IP组播的分发机制，未涉及 会话的实体(如网络服务提供商)也可以接收反馈信息，并发挥第 三方监控的作用来诊断网络问题。此反馈功能通过RTCP发送方和 接收方报告来完成。RTCP规范要求所有参与方发送RTCP分组，因 此必须控制速率，以便RTP按比例扩大以适应数量巨大的参与方。 通过使每个参与方向所有其他参与方发送其控制分组，各参与方可 以独立地观察参与方数量。该数量用于计算发送分组的速率。
再者，RTCP具有传送最小会话控制信息，例如要在用户界面上 显示的参与方标识的可选功能。这在参与方进入和离开无成员关系 控制或参数协商的会话中可能最有用。RTCP用作达到所有参与方的 便利信道，但并不能据此认为它支持某个应用的所有控制通信需求。 可能还需要更高级别的会话控制，这超出本文的范围。
上述功能除最后一个功能是任选的以外，均是在RTP用于IP组 播环境中时所必需的，并且推荐用于所有环境。
因此，无线网络中的多媒体服务同样适用于单个用户，即所谓 的单播连接，但如上所述也适用于一组用户，即所说的点到多点或 甚至多点到多点的连接。点到多点服务对网络基础设施有较高的要 求，并占用相当数量的带宽。此类服务的一些实例有视频会议、白 板、实时多用户游戏、多媒体消息收发、虚拟世界。此类多媒体应 用用于传输广播或组播模式。广播可以利用地址字段中的特殊代码 使分组寻址到所有目的地。当发送含有该代码的分组时，网络上的 每个用户都会接收到该分组并对其进行处理。这种操作模式称为广 播。组播支持向一个用户子集进行传输。每个用户可以注册到组播 组。当向某个组发送分组时，便将该分组传送给注册到该组的所有 用户。
RTCP具有在组播会话情况下的报告机制。但是，在无线电网络 的情况中，组播报告会浪费空中接口资源，并有可能使网络服务器 过载。再者，在优选组播解决方案中，只有下行信道，而没有上行 信道。这意味着用户无法向源端发送RTCP报告。
在RFC 1889中，有引入的称之为混合器的实体。该混合器从一 个或多个源端接收RTP分组，可能变更数据格式，以某种方式组合 这些分组并转发新的RTP分组。因为多个输入源之间的定时通常不 是同步的，所以混合器会在各流之间进行定时调整，并为组合流生 成其自己的定时。因此，源于混合器的所有数据分组将确定为以该 混合器作为它们的同步源。因此该混合器创建作为接收消息的组合 的新消息。
但是，对于目前的RTP，在组播会话中使用RTCP接收方报告 是强制的。具体来说，组播发送方接收这些指示客户仍然在监听的报 告是很重要的。RTP的当前修订版提供了用于抑制RTCP接收方报告 使用的功能。但是，通过忽略RTCP接收方报告的同时，也等于放弃 了从接收方获取质量反馈的重要手段。这样源端无法适应于变化的条 件，也无法提供替代流。
如果来自单个客户的RTCP报告指示有多个RTP帧被破坏或丢 失以及以更低的数据率为该客户服务可能会更好，则源端应该如何处 理总之是个问题。这在不同类型用户日益增加的无线网络中尤其是个 大问题。多媒体用户的特征在于使用具有各种显示屏尺寸和功能的各 式各样的移动终端。在当前的组播解决方案中，源端要么忽略此类报 告，要么适应于最慢的接收方。当客户为服务及服务所用载体而被收 费时，以上两种方式均不令人满意。此外，不同的无线电接入网使多 种最大接入链路速度可用。因为蜂窝无线电网络的物理特性，当前连 接的质量及相应的数据率也将变化，造成异质性问题。
由此产生无线网络中有关组播会话中RTCP报告的如下问题。当 每个用户发送RTCP报告时，稀缺的无线电资源使用效率不高。这也 可导致服务器(如RNC、SGSN、GGSN)过载，例如在相当多用户 生成报告的情况下，例如在足球场。由于不同的网络，源端必须适应 最慢的用户。再者，由于报告数量较多且评估报告所需时间较长，所 以在源端了解问题之前会有很大的时延。再者，RTCP报告不含无线 网络的所有必要信息。

本发明的目的在于提供一种有效利用无线网络中多媒体服务无 线电接口的解决方案。
本发明体现在权利要求1、18所公开的方法中。从属权利要求中 则描述了一些有利的实施例。
其基本的思想是，利用向客户提供多用户多媒体数据的服务器 和中间网络部分来调整通信系统中的多用户多媒体数据。所述中间 网络部分设为提供有关服务器和客户之间通信的信息。该服务器向 客户发送多媒体数据。确定所述客户的分布特性，所确定的分布特 性会在中间网络部分中生成有关客户的多媒体数据接收条件的汇集 反馈报告时加以考虑。所述反馈报告包括有关汇集方式的附加信息。 将所述汇集反馈报告发送到服务器，以便所述服务器根据所述汇集 反馈报告调整从服务器到客户的多媒体数据传输。
本发明的优点在于实现对无线网络中稀缺且昂贵的网络资源的 有效利用，尤其在上行方向上。利用本发明，可以更好的方式利用 无线电资源，因为报告与一个以上的用户相关。在一个用户的情况 中，如果有大量用户会话，源端需要进行许多报告分析。这在可以 将具有非常相似特征和行为的成员分组到一个或几个接入网中时尤 其浪费资源。再者，这会降低源端中的负载和复杂性。此解决方案 在没有上行信道的情况(如广播解决方案中)提供唯一的报告方式。 此外，所述汇集的RTCP报告可以考虑小区中的所有信息，而不是 每个客户一个专用RTCP报告。例如，在几乎过载的情况下，RNC 因丢失帧而在发生拥塞之前获悉此情况，并可将此情况报告给同一 小区内所有客户的源端。这会改善最终用户的质量体验。再者，一 般来说，因为省略了空中接口时延，所以报告更快速。这与单个用 户多媒体情况几乎一样。
在本发明的一个实施例中，分布特性与包含一组客户的地理区 域相关。无线通信网络中定义的一个或多个小区可以构建所述地理 区域。
在另一个实施例中，分布特性与确定的组播组结构相关，所述 确定的组播组结构可以包括具有用于接收以高速或低速传送的数据 的设备的客户。
在优选实施例中，分布特性与从无线电资源管理收到的信息相 关。所述无线电资源管理具有关于无线电接口上当前传输性能的信 息。因此，最好在生成反馈报告时对此信息予以考虑。
中间节点和无线电资源管理之间的交互可以频繁地执行或基于 事件执行。
在另一个实施例中，分布特性与从客户接收的信息相关。为了 提高汇集反馈报告的质量，客户发送他们自己的报告。此解决方案 的优点在于汇集反馈报告包含无法根据从无线电层导出的分布特性 来确定的信息。
建议频繁地或基于事件发送从客户收到的信息，例如在发生异 常事件时。
最好，在客户终端抑制来自客户的反馈报告。此实施例的优点 在于不会在上行链路上产生任何通信量，从而节省了无线电资源。 具体来说，在没有上行信道可用的情况下，这是一个首选解决方案。
再者，最好从无线电资源管理接收信息，所述无线电资源管理 具有关于当前无线电资源可用性的信息、来自客户的信息，并且最 好还将这些信息组合，以便生成给服务器的更满足需求的反馈报告。
在本发明的优选实施例中，有关汇集方式的附加信息包含汇集 反馈报告涉及的客户数量，以便服务器可以区分报告是涉及一个客 户还是一组客户。根据此信息，可以决定采取适当的操作，例如调 整是否有用，或是否复制实际流更合适。
在本发明的另一个优选实施例中，有关汇集方式的附加信息包 含这些客户所在接入网的无线电特征。利用此信息，服务器可以将 不同接入网的具体特性纳入考虑来区分如何调整多媒体流。
建议所述汇集反馈报告还包括供服务器使用的有关调整方式的 信息。这样，服务器接收附加信息，以便更好地判断可以/应该如何 调整数据流。
最好是就从客户和/或从无线电资源管理向中间节点发送反馈报 告的频率进行协商。此操作可以按固定时间间隔进行，也可以基于 事件执行，事件指发生某种情况。
在有利的实施例中，客户抑制将反馈报告发送到其他接收该数 据流的客户，以便确保多媒体数据所要组播到的多媒体客户的匿名 性。
在本发明的优选实施例中，所生成的汇集反馈报告包含由中间 节点提供的取决于当前传输条件的丢失分组率。该部分可以是例如 中间节点已收到的最高序号或中间节点提供的到达时间间隔抖动。
建议接收所述汇集反馈报告的服务器以适当的方式操作。例如， 在利用将所述反馈涉及的客户的比例纳入考虑的报告中的信息之 后，该服务器相应地进行调整。其反应可以是向这些客户宣告新信 道或调整数据流，例如降低比特率或切换到更可靠的编解码器。
再者，建议在相同的网络部分中实现中间网络部分的功能。在 替代解决方案中，建议在构成所述中间网络部分的不同节点之间划 分功能。
本发明的一个实施例基于实时传输协议RTP，RTP具有用于报 告反馈的控制协议实时传输控制协议RTCP。但是，本发明不应局限 于示例多媒体协议。
再者，本发明公开了一种中间网络部分，该中间网络部分适于 调整具有向客户提供多用户多媒体数据的服务器的通信系统中的多 用户多媒体数据。所述中间网络部分设为提供有关服务器和客户之 间通信的信息。它包括用于将多媒体数据从所述服务器转发到客户 的装置。用于确定与所述客户相关联的分布特性的装置也是所述中 间网络部分的组成部分。所述装置的任务是例如从可以访问低层的 无线电资源管理确定赖以向客户传送多媒体的传输条件。
再者，中间网络部分节点具有用于将分布特性纳入考虑而生成 有关客户的多媒体数据接收条件的汇集反馈报告的装置，所述反馈 报告包括有关汇集方式的附加信息。这样，通过发送汇集反馈报告 的装置将所生成的反馈报告发送到所述服务器。
还建议所述中间网络部分的装置在同一个网络节点上实现。或 者，建议用于确定与客户相关联的分布特性的装置和用于生成汇集反 馈报告的装置分设在不同的节点上。在后一种情况中，要求提供用于 接收外部确定的与客户相关联的分布特性的装置。
附图说明
下面将详细描述本发明。
图1：广播/组播服务(MBMS)体系结构。
图2：分组交换流式(PSS)体系结构。
图3：具有用于流式传输的协议层的协议栈。
图4：用于本发明的协议模型。
图5：用于确定与客户相关联的分布特性的本发明实施例。
图6：用于按每个移动终端生成汇集反馈报告的本发明实施例。
图7：用于按每个小区生成汇集反馈报告的本发明实施例。

以下参照采用RTP的无线网络来说明本发明。术语中间节点和 中间网络部分作为同义词使用。
其基本思想是，由无线网络中的中间网络部分负责汇集RTCP报 告，而非每个用户各自执行其自己的报告。术语中间网络部分描述一 种可以在一个节点上实现的功能，其在以下所述中称为中间节点，或 者该功能可以分设在不同的网络节点上。
按例如组播组生成汇集RTCP报告或一个总的反馈报告。将确定 的小区相关特性和组结构纳入考虑来实时确定分布特性。反馈报告的 生成基于分布特性的实时确定结果，其中所述反馈报告包括含有例如 所述反馈报告所涉及的用户数量的附加信息。将所述反馈报告发送到 作为组播源的服务器，该服务器通过考虑所述反馈报告所涉及的用户 的比例来利用所述组反馈报告。根据所用的反馈报告相 应地调整组播/广播传输。再者，作为可选方案，中间节点向组播源 就如何调整相应用户组的数据流给出建议，例如，如果可能，建议 只进行多个单播或可以建议切换重叠小区或其他接入网。这样做的 原因是，可以向中间节点提供某些数据的RNC可能具有源端没有的 信息，例如小区无线电特性，因此更能判断可以/应该如何调整数据 流。例如，RTCP当前指示接收质量不佳，这触发源端将比特率降低 到次低的等级。按时间单位确定几乎过载的小区和许多会话发起的 RNC可以指示必须降低比特率。
通过接收汇集反馈报告，源端利用已考虑到所述反馈涉及的客 户比例的报告中所含的信息。其反应可以是向这些客户宣告新信道 或调整数据流，例如降低比特率或切换到更可靠的编解码器。
为了抑制客户发送RTCP接收方报告，在中间节点上生成RTCP 接收方报告。该中间节点隐藏了整个小区的接收方。该中间节点从 RNC获取信息，并据此创建RTCP报告。此外，可以利用含有特殊 无线信息的RTCP分组，并在RTCP生成节点(即中间节点)上将 其过滤掉。
再者，任选的是，RTCP报告还可以包含实际最终用户寻址的用 户数量，因为这可能是其他用户和/或源端所感兴趣的。
下文将参考图4进行描述。
图4显示本发明的协议模型。它显示了一个组播源，该组播源 通过RTP发送方消息(图中未显示)向客户发送多媒体数据。该组 播源中的协议栈包括具有位于UDP和IP协议之上的对应RTCP层的 RTP。L2是链路层的概括描述，它依据数据要发送到的网络而有所 不同。显示了接收端(即多媒体接收方)上对应的协议栈。但是， 在此情况中，为无线网络指定的链路层是具有无线电资源控制 (RRC)协议的无线电链路协议。根据本发明，组播源和组播接收 方之间存在中间网络部分，即中间节点。在图4中，给出了用于生 成汇集反馈报告的不同的选择。
中间节点可能没有从客户收到任何信息。这意味着空中接口上没 有任何可用的RTCP报告。开始时在中间节点上基于收到的RTP流以 及可能还基于有关某个小区或区域的无线电资源管理RRM知识来生 成RTCP反馈报告。为了接收RRM信息，要使用通信链路10。此信 息可以频繁发送，或可以基于事件发送。不会从客户发送报告，因为 客户抑制在RTP/RTCP层面上发送RTCP报告，或因为所有RTCP报 告在客户终端中被阻塞。
在某些情况下，允许客户在单播上行信道上发送RTCP报告，在 组播接收方和中间节点之间的通信链路上进行事件驱动的报告。这意 味着即便在报告在客户终端中被抑制或阻塞时，可选择只发送含有特 殊信息的RTCP报告，这意味着不会发送正常的RTCP报告。仅在发 生异常事件的情况下，才执行RTCP报告。在报告在客户终端中受抑 制的情况下，这在RTCP层面上处理。如果客户中阻塞报告，则终端 将不得不过滤正常的RTCP报告。视为异常的RTCP报告与服务和接 入网相关，可以是源端和目的地之间和/或接入网和目的地之间协商的 主题。例如，当丢失率超过某个阈值时，可以生成异常RTCP报告。 可以将RTCP报告用作附加输入，以形成汇集的RTCP消息。
本发明的另一个选择是抑制向所有组播接收方发送RTCP报告， 以保持用户之间的匿名性。通常，用户同样也不会对谁在接收信息感 兴趣。此外，这种选择降低了网络中的下行负载。由此，除发送方报 告外，不在下行方向发送RTCP报告。图4中未显示此选择，因为其 中只显示了一个客户。
以下参考图5描述用于确定与客户相关联的分布特性的一个替代 方案。
图5说明客户与RNC通信的一种替代逻辑体系结构。通信路径 通过无线电和核心网络到达所谓的服务节点，并在其中将从RNC接 收的网络反馈纳入考虑而生成汇集的反馈消息。这意味着获取必 需的小区级别质量信息的功能物理上与编制和发送RTCP报告的节 点分离。不从移动客户发送任何RTCP接收方报告。服务节点可以 是特殊节点或在GGSN或多媒体资源功能MRF中实现的功能，其中 由移动核心外的所述服务节点生成RTCP接收方报告。RTCP接收方 报告可以按RNC发送或按小区发送。
再者，按小区或按RNC提供RTCP报告还可以增加质量反馈信 息的周期，从而使发送方可以更快地进行调整以适应变化的条件。 RTCP报告时间间隔可根据会话参与方数量来确定。
下文将更详细地说明针对不同场景的不同的详细解决方案。
一种可能的场景是广播场景，其特征在于：不存在上行链路的 无线电接入配置。这意味着组播数据报在下行方向上发送，但无客 户响应返回。没有返回信道使客户不能回送RTCP反馈。虽然可以 生成RTCP消息，但不存在传送它们的介质。
对于广播场景，要旨是在网络节点中生成RTCP消息，例如， 在WCDMA的RNC中生成，它基本是用于生成RTCP报告的逻辑 位置。基于无线电相关的信息生成新的RTCP接收方报告。因此， 可以将创建和发送RTCP接收方报告的功能与数据收集功能分离。
为进行通信，RTCP定义了不同的RTCP消息。下面描述了利用 RTCP消息生成汇集消息的一种方式。
RTCP定义了发送方报告(SR)、接收方报告(RR)、源描述 项(SDES)、再见消息(BYE)、专用功能(APP)。这些消息可 以捆绑在一起构成所谓的复合消息。具体来说，对于本发明，接收 方报告(RR)尤其重要，发送方需要接收此报告以便适应变化的带 宽条件。基于已知RNC有关于一个或多个小区中的链路条件的信息， 建议在RNC中生成此类接收方报告。RNC可以为它负责的每个小区 生成一个消息，或者也可以为所有小区生成一个消息。
在下文中，描述如RFC 1884中定义的RR消息的不同字段。
32位的SSRC_n(源标识符)是此接收报告块中信息的相关源 端的SSRC标识符。
8位的丢失率(fraction lost)字段描述自前一SR或RR分组发 送起丢失的来自源端SSRC_n的RTP数据分组的百分比，它表示为 定点数。
24位的累计丢失分组数字段是自接收开始起已丢失的来自源端 的SSRC_n的RTP数据分组的总数。
为扩展的已接收最高序号字段保留32位。低16位包含在源端 SSRC_n的RTP数据分组中接收到的最高序号，而高16位用对应的 序号循环计数扩展序号。
还有32位的到达时间间隔抖动字段。即RTP数据分组到达时 间间隔的统计方差的估计，按时间戳单位测量并表示为无符号整数。 到达时间间隔抖动定义为一对分组在接收方接收间隔与发送方发送 间隔之差的平均偏差(平滑绝对值)。
32位的最末SR时间戳(LSR)字段描述来自源端SSRC_n的最 新RTCP发送方报告(SR)分组。如果尚未收到任何SR，则该字段 设为零。
32位的自最末SR起时延(DLSR)字段是从源端SSRC_n接收 到最末SR分组与发送此接收报告块之间的时延，以1/65536秒为单 位表示。如果尚未从SSRC_n收到任何SR分组，则将DLSR字段设 为零。
为本发明目的，需要设置RR中的各条目，以生成汇集反馈消 息。
第一字段就是发送方ID，它是已知的。对于第二字段，丢失分 组率，存在不同的选择。适当的值可以是RNC观测到的丢失率或RNC 根据当前小区状况(例如无线电资源利用率、干扰等)以及根据为 该小区中传输选定的可靠性级别来作出的估计值。
根据为避免前一字段失配所用的概念，需要选择累计丢失分组 数。例如，如果该丢失率基于RNC看到的分组丢失数，则同样应将 它们用于此条目。已接收最高序号应该是RNC已看到的最高序号。 到达时间间隔抖动可根据RNC观测到的抖动得到，也可以通过将链 路参数纳入考虑的估计值来确定，例如是否采用了ARQ或重复编码 或FEC来确保一定程度的可靠性。最末SR时间戳可以不经修改地 取自从发送方接收的发送方报告。如果尚未收到发送方报告，则该 字段设为零。最末字段DLSR可以保留不修改，或者可以引入进一 步的改进。例如，为了为发送方提供更好的往返时间RTT估计，建 议使时延值减少一个无线电接入RTT。再者，为了调整时延值以补 偿接入网时延，可以使时延值减少例如两个RTT。这些仅为示例， 不应限制本发明的范围。
下面给出下一种场景，即组播场景。
组播场景与广播场景的主要不同之处在于有返回信道可用。这 因而会使端到端RTCP信令成为可能，但因为所述问题，即当每个 客户发送报告时无线电资源过载，所以建议在中间网络部分(对于 WCDMA最好是RNC)生成RTCP消息。以下描述目前可能的两个 实施例。
在第一个实施例中，客户生成的RTCP消息在客户终端被丢弃， 并在中间节点(如RNC)从头生成RTCP消息。根据RTP规范，目 前可能的是，源端向客户表示不会使用任何RTCP接收方报告。收 到此信息，便在客户中丢弃反馈消息，或者甚至不生成该消息。
在第二个实施例中，预见在客户中生成的RTCP消息通过无线 电接口传送到中间网络部分，但在所述网络部分根据下列所述的一 定原则进行修改。来自客户的RTCP消息的RTCP消息间隔时间可 比从中间节点到发送方的RTCP消息的RTCP消息间隔时间长。客 户甚至可仅以事件驱动方式发送RTCP消息，例如当某些值超出范 围时才发送。
设置RR消息的各字段的输入与广播场景的情况相同。即便对 于组播，在设置RR消息中的字段时仍可以遵循如下原则。可以应用 的第一个原则是，当采用WCDMA中的公共传输信道时，总会有一 些接收方的信道条件不好而遭受大量分组丢失，而其他接收方则得 到较好的质量。在此情况中，RNC可以屏蔽差的接收方报告，以便 为好用户保持质量。可以应用的第二个原则是，如果RNC检测到小 区中过载，并希望降低公共信道上用于组播/广播服务的比特率，则 它可以利用RTCP报告将此信息通过信号通知组播服务器。为此， 可以提高报告中测得的分组丢失率，或者只降低已接收最高序号。 这比端到端信令更快，因为无线电接口的时延以及每用户RTCP报 告对大用户组而言是罕见的。
下面描述对上述场景公用的一般机制。
如上所述，在中间网络部分生成汇集RTCP反馈消息。在以上 描述中，RTCP报告生成是在RNC中完成的。一般而言，此报告生 成和所有相关的功能均是逻辑功能，这些功能还可以驻留在其他网 络实体(如组播/广播服务器MB-SC)中。在那种情况下，还可以 采用专用协议将相关信息从RNC转发到MB-SC。
在本发明的优选实施例中，要保证用户的匿名性。不同于固定 因特网中某些组播应用如音频和视频会议，移动用户通常形成一个 匿名社区。移动网络中观看相同视频剪辑的用户大多数可能没有兴 趣知道其他观看者的姓名，也可能不希望公开他们的身份。根据标 准的RTCP消息(具体为RR和SDES消息)应该包含例如电子邮件 地址格式的用户身份。因此，本发明建议只将在中间节点上生成的 RTCP消息发送回RTP流发送方。
在生成汇集RTCP报告的同时，将RTCP报告所涉及的目的地 的数量添加到该报告中。此信息随后可在组播流调整的情况中由源 端纳入考虑。这意味着如果汇集RTCP报告涵盖数千个目的地，则 源端可以针对这些目的地进行调整。如果它只涵盖涉及数千个目的 地的会话中的十个目的地，则建议客户切换到单播会话可能更好。
下文中公开了本发明的两个实施例。如图6所示，在第一个实 施例中，在中间节点上基于每移动终端RTCP报告生成汇集反馈消息。
图6显示一个组播源发送RTP流，下行流组播服务通过中间节 点和对应RNC到具有其移动终端的客户。中间节点生成RTCP接收 方报告，并将这些报告作为反馈发送到组播源。所述反馈是将从RNC 接收的用户和小区信息纳入考虑而生成的。
为了在几个组播源之间进行区分，每个接收方报告(RR)分组 通过源端的SSRC来定址。因此，中间节点必须处理来自源端的下行 组播服务，并将其转发到接收方，然后提取组播源的SSRC。该SSRC 是为中间节点上生成的上行RTCP接收方报告分组定址所必需的。 RNC提供每小区移动终端数量及每终端接收条件。
中间节点必须为每个客户终端分配SSRC标识符。中间节点必须 代表每个客户终端分配SSRC。除SSRC外，中间节点还必须为每个 客户提供SDES CNAME项。对特定用户，选择CNAME(规范名) 有几个选项。在匿名参与的情况中，当源端不会得到清楚的CNAME 时，SDES CNAME项是随机选择的。它可以是例如 @host的形式。该CNAME必须是唯一的。在非匿 名CNAME的情况中，要么由操作员预先确定用户名如 phonenumber@domain，或由用户在偏好数据库中指定CNAME。因此， 中间节点必须按小区维护一个客户终端列表以及由中间节点分配的 相关联的SSRC和CNAME。中间节点的功能可能被包括在BM-SC或 GGSN中。每个RTCP分组的内容如以前章节所述那样创建。
如果非用户组很大，分布在数量非常大的小区中，则中间节点将 不按客户而是按小区发送RTCP分组。非常可能的是，每个小区服务 数量近似相等的组成员。此实施例在图7中公开，图7显示与图6一 致的事实。区别在于中间节点按小区生成反馈消息。
在此情况中，中间节点为每个含组成员的小区分配有效的SSRC 和CNAME。发送的RTCP分组数量减少了。通过发送每小区RTCP 分组，RTCP分组的发送间隔时间减少，因此组播源的反应时间也相 应减少。
另外，可以引入RTCP分组类型，以根据小区中的用户数量为 RTCP接收方报告加权。每当RTCP复合分组包含一个以上成员的接 收方报告时，该RTCP分组类型必须是该RTCP复合分组的一部分。
本发明提出了用于无线和组播特定RTCP报告的解决方案，它 将无线网络的详细情况纳入考虑，从而提高了整体服务质量。这些 报告中还可以将来自RNC中已知的低层协议的其他信息纳入考虑， 以进一步优化服务质量。但是，将附加的无线电相关信息转发到源 端只是本发明的一部分。另一部分则是由RNC将该信息纳入考虑， 并向源端提出调整建议。由此，源端无需具有有关无线电网络的信 息，既然无线电网络将此信息转换为给源端的已知调整建议。