CN1906910A - 利用通用否定应答报告块和损失行程长度编码报告块的反馈提供 - Google Patents

Abstract

本发明涉及一种将与至少一个流会话的数据分组有关的RTCP反馈消息从客户机提供到流服务器的方法，其中，至少一个流会话是利用RTP协议和RTCP协议提供的。并且，作为可用流会话带宽一部分的RTCP带宽被分配给RTCP反馈消息。此外，本发明进一步涉及一种在移动通信系统中执行该方法的客户机。本发明规定了在单播会话中优化RTCP反馈的方法，以便用可用客户机缓冲时间保证最大重传次数，并且如有可能使有关丢失分组的冗余报告达到所需级别。

Description

利用通用否定应答报告块和损失行程长度编码报告块的反馈提供

技术领域

本发明涉及一种将与至少一个流会话的数据分组有关的实时控制协议(Real Time Control Protocol，RTCP)反馈消息从客户机提供到流服务器的方法，其中，至少一个流会话是利用实时传输协议(Real-Time Transport Protocol，RTP)协议和RTCP协议提供的。另外，作为可用流会话带宽一部分的RTCP带宽被分配给RTCP反馈消息。此外，本发明还涉及一种在移动通信系统中执行该方法的客户机。

背景技术

3GPP(第三代合作项目)采用如RTP、用户数据包协议(User DatagramProtocol，UDP)、网际协议(Internet Protocol，IP)这样的IETF(因特网工程任务组)标准化的协议用于传输，以及如自适应多速率(AdaptiveMulti-Rate，AMR)和H.264(MPEG4部分10)这样的分组交换编解码器用于编码多媒体。3GPP分组交换流业务(见“Universal Mobile TelecommunicationSystem(UMTS)；Transparent end-to-end steaming service；Protocols and codecs”，3GPP TS 26.234 version 6.1.0，September 2004，可在http://www.3gpp.org获得)使用RTP/UDP协议栈来流化(stream)音频/视频/文本媒体。

RTP是实时传输协议(见Schulzrinne等人，“RTP：A Transport Protocol forReal-Time Applications”，RFC 3550，July 2003，所有的IEFT RFC和Internet草案都可在http://www.ietf.org获得)，主要用于实时或近实时通信，即，具有不严格延迟约束的通信。它提供关于它所承载的媒体的定时的信息，并且还允许在接收器处重新排序和重新组装。

该协议的综合部分是是RTCP(实时控制协议)，它提供最小的接收信息和松散的(loose)组成员资格。RTP通常与RTP/AVP简档(见Schulzrinne等人，“RTP Profile fpr Audio and Video Conferences with Minimal Control”，RFC3551，July 2003)一起使用，后者除了简单的RTCP反馈定时规则外还定义了RTP头字段的使用和净荷类型的映射表。RTCP协议被分配可用RTP带宽的一部分，以便公平地与基于TCP/IP的业务竞争。

UDP(Postel，“User Datagram Protocol”，RFC 768，August 1980)是用于传输RTP分组的用户数据报协议。与流应用的情况一样，UDP通常用在不可靠通信适用于给定媒体的时候。使用协议栈RTP/UDP是因为，例如，如果使用TCP(传输控制协议)，媒体的定时约束提供不了可靠的通信。

在RTP中，在因特网工程任务组音频/视频传输工作组(IETF AVT WG)中规定了对现有媒体格式(编解码器)的分组化方案(净荷格式)。例如有AMR编码的话音数据的净荷格式和H.264视频的净荷格式。在Rey等人，“RTPRetransmission Format”，Internet Draft，IETF AVT Workgroup，August 2003中定义的RTP净荷格式也允许在该框架中重传RTP分组。这对于3GPP PSS流业务可能尤其有用。

如Rey等人在“RTP Retransmission Format”中规定的，只有当需要的时候用于发出多个重传的机制才依靠客户机发出请求。客户机必须使用在Ott等人，“Extended RTP Profile for RTCP-based Feedback(RTP/AVPF)”，InternetDraft，IETF AVT Workgroup，August 2004中规定的反馈可能。也可以使用其他报告块(reporting block)，如Friedman等人在“RTP Control Protocol ExtendedReports(RTCP XR)”(见RFC 3611，November 2003)中定义的那些。

可以使用RFC 3550(见6.3部分和附录)中的标准RTCP报告间隔计算来计算报告的频率。没有规定接收器报告的覆盖率，即，报告多少分组。客户机使用在RTP/AVPF简档(draft-ietf-avt-rtcp-feedback-11.txt，可以在http://www.ietf.org/internet-drafts/获得)中规定的通用NACK(NegativeACKnowledgement，否定应答)反馈消息。要注意，客户机不能使用RTP/AVPF简档来肯定应答分组，因为那里没有规定ACK消息。因此，不提供(例如利用行程长度编码(Run-Length Encoding，RLE)报告)全面的报告。

此外，在RFC 3611中定义的损失RLE报告是增强的报告块，它可以压缩并且将ACK和NACK合并作为缺省，即，允许报告关于丢失和接收到的分组。为了网络维护的目的、收费、组播树推断(multicast tree inference)和统计数据收集，规定了这些报告。

涉及损失RLE报告和单播RTCP报告的第三个文档是3GPP PacketSwitched Steaming Service(PSS)框架。根据该文档，建议流客户机实现损失RLE报告块的使用，并且在过去的RTCP间隔上以冗余的方式报告。此外要注意，根据3GPP PSS框架这些报告不应用于触发重传。

3GPP PSS框架的上下文中的冗余报告被理解为允许在丢失的数据分组的处理之前或之后关于它们的最小数量的报告。然而，没有关于该机制应当如何在客户机上实现以及该机制应当如何与RTP重传请求一起使用的规范。关于丢失分组的冗余报告是值得期望的，因为反馈(即，RTCP消息)通常使用如UDP这样的没有应答且因而不可靠的传输协议来发送。因此，会话的接收器提供的反馈可能会丢失，尤其是当考虑到通过无线接入网络(如UMTS)提供业务时。

如上所述，PSS框架要求，损失RLE报告块(RFC 3611)仅仅用于收费和网络监控目的，而通用NACK消息(RTP/AVPF简档)用于实际触发丢失数据分组的重传。因此，PSS框架要求传输会话的RTCP反馈包括通用NACK和损失RLE报告块，以便允许触发重传，并且同时允许(例如)收费和网络监控。

Rey等人描述的多个重传算法使用(或者可能利用)Ott等人的RTP/AVPF草案中定义的消息格式，即，通用NACK来触发分组重传。

如果如3GPP PSS框架所建议的，接收到的和未接收到的分组都应该被报告，则这意味着这些报告块可能造成相当大的开销，从而分配给RTCP的预留带宽对于在所要求的时间量上报告、同时保证连贯播出和/或所要求的报告冗余，可能是不够的。此外，为了使收费和网络监控业务与触发重传能并行进行，接收PSS会话的客户机的反馈实际上需要包括冗余报告块(损失RLE报告块)，这也将产生开销并且影响报告频率，从而影响可以提供的冗余报告级别。

发明内容

因此，本发明的目的是规定在单播会话中优化RTCP反馈的方法。

本发明的目的通过独立权利要求的主题达到。优选实施例是从属权利要求书的主题。

本发明的一个实施例涉及将与至少一个流会话的数据分组有关的RTCP反馈消息从客户机提供到流服务器的方法，其中，至少一个流会话是利用RTP协议和RTCP协议提供的。根据这个方法，客户机可以首先确定可在流会话的会话约束内提供的数据分组的最大重传次数是否大于客户机允许的最小重传次数。如果是，可以将数个通用NACK报告块加入到RTCP反馈分组中，用于请求重传丢失数据分组。被加入的数个通用NACK报告块能够使丢失数据分组在客户机缓冲时间内重传达最小次数。接着，客户机可以确定就会话约束而言允许的最大RTCP反馈消息大小，并且可以将数个损失RLE报告块加入到RTCP反馈分组中，用于报告丢失数据分组，使所得RTCP反馈分组的大小不超过最大RTCP反馈消息大小。并且，客户机可以将RTCP反馈分组作为RTCP反馈消息发送到流服务器。

本发明的另一个实施例涉及将与至少一个流会话的数据分组有关的RTCP反馈消息从客户机提供到流服务器的方法。在这个实施例中，至少一个流会话是利用RTP协议和RTCP协议提供的，并且作为可用流会话带宽一部分的RTCP带宽被分配给RTCP反馈消息。

客户机可以接收指示RTCP反馈消息的RTCP带宽、在客户机缓冲时间内允许的最小重传次数、至少一个流会话的丢失数据分组的最小报告冗余度和客户机缓冲时间的会话描述信息。并且，客户机可以确定可根据客户机缓冲时间和RTCP报告间隔提供的数据分组的最大重传次数。从而，RTCP报告间隔可以取决于平均RTCP反馈消息大小和分配给客户机的RTCP带宽。

客户机可以进一步确定最大重传次数是否大于或等于最小重传次数。如果是，它可以将数个通用NACK报告块加入到RTCP反馈分组中，用于请求重传丢失数据分组。被加入到RTCP反馈分组中的这数个通用NACK报告块能够使丢失数据分组在客户机缓冲时间内重传达最小次数。

客户机还可以确定对分配的RTCP带宽、客户机缓冲时间和最小重传次数加以考虑之后允许的最大RTCP反馈消息大小，并且可以根据以前发送的RTCP反馈消息的平均大小和包含数个通用NACK报告块的RTCP分组的大小，确定最后平均RTCP反馈消息大小。

并且，如果所得RTCP反馈分组的大小不超过最大RTCP反馈消息大小，则客户机可以将数个损失RLE报告块加入到RTCP反馈分组中，用于报告丢失数据分组，并且可以将RTCP反馈分组作为RTCP反馈消息从客户机发送到流服务器。

在本发明的另一个实施例中，为了收费或网络监视的目的，将损失RLE报告块加入到RTCP反馈分组中。

在进一步的实施例中，在确定包括游程长度编码损失RLE报告块的所得RTCP反馈分组的大小是否超过最大RTCP反馈消息大小之前，游程长度编码数个损失RLE报告块。通过对损失RLE报告块进行游程长度编码，可以减小它们的大小，而可以供应相应数量报告块的报告冗余度保护不变。

在另一个实施例中，客户机可以决定降低客户机通过会话描述信息配置的最小报告冗余度。对丢失的分组降低报告冗余度的不同可能性是可以预知的。

例如，在这个实施例的一种变体中，客户机可以确定为流会话的分组提供的上行链路服务质量。根据这个测量的或确定的服务质量(QoS)，例如，如果确定的服务质量在预定阈级别之上，降低最小报告冗余度。

另一种变体预知，客户机通过减小数个损失RLE报告块的大小可以降低报告冗余度。

例如，在流会话的数据包含提供基本流媒体质量的基本数据层和提高基本流媒体质量的至少一个提高层的情况下，通过只让与包含基本数据层的数据的数据分组有关的信息包括在损失RLE报告内，可以减小数个损失RLE报告的大小。

例如，当至少一个流会话的数据是MPEG流时，基本数据层包含I帧，和至少一个提高层包含P帧和/或B帧。在这个例子中，在会话描述信息设置的会话约束内，客户机可以保证I帧被报告，而对流的客户机感觉QoS影响较小的P帧和/或B帧只有在可能的情况下被报告。

关于这个方面，客户机可以根据在客户机上已经接收的数据分组确定丢失数据分组是否包含基本数据层的数据。

根据该实施例的进一步变体减小数个损失RLE报告块的大小的进一步可能性是将细化应用于损失RLE报告块。

此外，该实施例的另一种变体预知，通过减少在RTCP反馈分组中报告的数个损失RLE报告块可以减小数个损失RLE报告块的大小。

在理想情况下，在本发明的另一个实施例中，将数个损失RLE报告块加入到RTCP反馈分组中实现丢失分组的最小报告冗余度。

并且，本发明的另一个实施例预知，流会话的MIME类型参数可以表示分组速率。这个参数可用于，例如，估计在RTCP报告间隔内必须报告的流会话的分组的平均数量。

在本发明的进一步实施例中，客户机可以根据在客户机上接收的数据分组的序号确定流会话的哪些分组丢失了。

本发明的另一个实施例涉及将与至少一个流会话的数据分组有关的RTCP反馈消息从客户机发送到流服务器的移动通信系统中的客户机。此外，至少一个流会话是利用RTP协议和RTCP协议提供的，和将可用流会话带宽一部分的RTCP带宽分配给RTCP反馈消息。根据本发明这个实施例的客户机可以包含接收器，用于接收会话描述信息，其中，会话描述信息指示RTCP反馈消息的RTCP带宽、在客户机缓冲时间内允许的最小重传次数、至少一个流会话的丢失数据分组的最小报告冗余度和客户机缓冲时间；和处理装置，用于确定可根据客户机缓冲时间和RTCP报告间隔提供的数据分组的最大重传次数，其中，RTCP报告间隔取决于平均RTCP反馈消息大小和分配给客户机的RTCP带宽，和用于确定最大重传次数是否大于等于最小重传次数。

处理装置可以进一步适用于如果最大重传次数大于等于最小重传次数，将数个通用NACK报告块加入到RTCP反馈分组中，用于请求重传丢失数据分组，其中，加入到RTCP反馈分组中的数个通用NACK报告块能够使丢失数据分组在客户机缓冲时间内重传达最小次数，和确定对分配的RTCP带宽、客户机缓冲时间和最小重传次数加以考虑之后允许的最大RTCP反馈消息大小。

处理装置也可以适用于根据以前发送的RTCP反馈消息的平均大小和包含数个通用NACK报告块的RTCP分组的大小，确定最后平均RTCP反馈消息大小，和如果所得RTCP反馈分组的大小不超过最大RTCP反馈消息大小，将数个损失RLE报告块加入到RTCP反馈分组中，用于报告丢失数据分组。

客户机可以进一步包含发送器，用于将RTCP反馈分组作为RTCP反馈消息发送到流服务器。

另一个实施例涉及进一步包含适用于执行根据上述各种各样实施例和它们的变体之一的方法的装置的客户机。

此外，本发明的另一个实施例涉及用于存储指令的计算机可读媒体，当所述指令被移动通信系统中的客户机的处理器执行时，使客户机将与至少一个流会话的数据分组有关的RTCP反馈消息从客户机提供到流服务器的指令的。此外，至少一个流会话是利用RTP协议和RTCP协议提供的，并且作为可用流会话带宽一部分的RTCP带宽被分配给RTCP反馈消息。

通过在客户机上接收会话描述信息，其中，会话描述信息指示RTCP反馈消息的RTCP带宽、在客户机缓冲时间内允许的最小重传次数、至少一个流会话的丢失数据分组的最小报告冗余度和客户机缓冲时间；通过确定根据客户机缓冲时间和RTCP报告间隔的数据分组的最大重传次数，其中，RTCP报告间隔取决于平均RTCP反馈消息大小和分配给客户机的RTCP带宽；和通过确定最大重传次数是否大于等于最小重传次数，可以使客户机将与至少一个流会话的数据分组有关的RTCP反馈消息从客户机提供到流服务器。

如果后一种情况正确，该指令可以使客户机将数个通用NACK报告块加入到RTCP反馈分组中，用于请求重传丢失数据分组，其中，加入到RTCP反馈分组中的数个通用NACK报告块能够使丢失数据分组在客户机缓冲时间内重传达最小次数；确定对分配的RTCP带宽、客户机缓冲时间和最小重传次数加以考虑之后允许的最大RTCP反馈消息大小；根据以前发送的RTCP反馈消息的平均大小和包含数个通用NACK报告块的RTCP分组的大小，确定最后平均RTCP反馈消息大小；如果所得RTCP反馈分组的大小不超过最大RTCP反馈消息大小，则将数个损失RLE报告块加入到RTCP反馈分组中，用于报告丢失数据分组；和将RTCP反馈分组作为RTCP反馈消息从客户机发送到流服务器。

根据本发明进一步实施例的计算机可读媒体进一步存储当被客户机的处理器执行时使客户机执行根据上述本发明的各种各样实施例和它们的变体之一的方法的指令。

本发明的另一个实施例提供了包含将至少一个流会话提供到客户机的流服务器、和根据上面本发明实施例之一的客户机的系统，其中，至少一个流会话是利用RTP协议和RTCP协议提供的。

附图说明

下面将参照附图详细描述本发明。附图中相似或相应的细节用相同的附图标记标出。

图1示出根据本发明实施例的流环境的概况，

图2示出根据本发明实施例的、提供目标级别的重传所需要的客户机缓冲时间、RTCP报告周期和最小时间周期之间的关系，和

图3示出根据本发明示例性实施例的、在流环境中多个连续重传请求和重传的时间线，

图4示出根据本发明实施例的、用于在流会话中提供RTCP反馈的方法的初始步骤，以及

图5和6示出根据本发明不同实施例的用于提供RTCP反馈的方法的其他步骤，其中所示步骤在图4所示步骤之后执行。

具体实施方式

图1示出根据本发明实施例的流环境的概况。流服务器100可以通过无线接入网络向客户机101或移动终端提供一个或多个会话形式的流业务。在该例子中，包括核心网103(CN)和UMTS无线接入网104(UTRAN)的UMTS网络提供流分组交换业务，该业务可以根据如在3GPP TS 26.234中定义的要求操作。为了将核心网103连接到分组交换网络，例如因特网，核心网可以包括网关GPRS支持节点105(GGSN)和服务GPRS支持节点106(SGSN)。核心网的组件可以连接到UTRAN 104，UTRAN 104包括至少一个无线接入控制器107(RNC)和至少一个连接到RNC的节点B。流媒体的数据可以通过无线链路提供给移动客户机101。

本发明的一个方面是有效地利用RLE报告块以便在不同的RTP重传实现中进行丢失报告。该实现典型地在服务器与客户机执行的功能、用于调度/请求重传的信息和它们具有的关于网络状况(拥塞、分组丢失、链路特性)的知识方面不同。3GPP PSS流业务定义了会话描述属性，该属性可以或不可以用于使通信双方获悉该信息。

对于所有RTP重传实现，可以假设相同的初始情况和要求：由于RTCP传输是不可靠的，因此客户机应当执行冗余报告。此外，客户机应当至少在当前报告与最后报告之间的周期上报告，即，保证最小接收器报告。

报告频率应当足够高，以允许及时重传，即，保证对每个RTP分组的最小重传次数。因此，客户机可以限制其报告频率、报告块大小和冗余报告来遵从服务器用信号通知的RTCP带宽。

由于这些要求中的某些要求是有冲突的，因此可能在每个情况中不能同时满足它们，客户机可以在给定条件下优化冗余报告的级别、报告频率和所报告的RTP分组的数量。

例如(并且假设RTCP带宽共享和客户机缓冲时间考虑冗余报告)，这可能意味着，在简单实现中，客户机将分别使用通用NACK报告块和损失RLE报告块、请求在当前RTCP报告与最后RTCP报告之间的所有丢失分组的重传和关于这些丢失分组的报告，将关于丢失和接收到的分组的冗余报告级别设置为合理值，并且保持RTCP报告频率尽可能高，以允许最大的及时重传。应当注意，下行链路(服务器到客户机)上的RTP分组可能多次丢失，因而可能要求多次重传。

如果这个简单实现不符合限制报告频率、报告块大小和冗余报告从而与用信号通知的RTCP带宽一致的要求，客户机可以首先尝试通过行程编码来减少损失RLE报告块大小。

损失RLE报告块允许在单独分组接收和丢失事件时的详细报告。该报告可以用于例如网络特性的组播推断(MINC)。由于丢失和接收到的RTP分组的布尔迹(Boolean trace)可能很长，这种块类型可能允许通过行程编码压缩该迹。当使用行程编码时，分析要编码的迹，并且可以汇总相同事件的“行程”(run)，以减少损失RLE报告块的总大小。

接着，客户机可以减少每个损失RLE报告块的报告RTP分组的数量。请注意，由单个报告块报告的数量减少的分组将导致冗余报告的级别降低。

为了减少损失RLE报告块报告的分组数量，可以以称为细化(thinning)的机制将丢失时间报告从迹中系统地丢弃。细化机制可以通过选择细化值T实现，可以使用该值选择顺序号空间中的分组子集，例如，那些顺序号是2T倍数的分组。仅对这些分组应用分组接收和丢失报告。T可以例如在0到15之间变化。如果T为0，则顺序号空间中的每个分组被报告。如果T是15，则每32768个分组中报告一个。

假设刚才描述的迹在顺序号13821开始。该迹中的最后序列号是13865。如果要用细化值T＝2细化该迹，则将报告每第四个顺序号：13824、13828、13832、13836、13840、13844、13848、13852、13856、13960、13864。

另一个减少报告的分组数量的选择是仅报告落入最近的分组中的分组。

最后，如果所有这些措施都没有用，并且存在对在客户机缓冲时间到期之前最小重传请求(通用NACK报告块)次数的硬性要求，则客户机可以用增强的RTCP带宽重新启动会话以符合这些所要求的最小重传次数，以及/或者可以增加客户机缓冲时间。

为了进一步讨论本发明下面的构思，将参照图3讨论RTCP带宽、客户机缓冲时间、RTCP报告间隔等之间的关系。图3示出根据本发明实施例的流环境的概况。在图中示出了多个连续重传请求和重传的时间线。假设RTP分组的初始传输(SN＝0)以及其第一和第二次重传丢失。

发送器(例如，流服务器)向接收器(客户机)提供RTP数据分组。对延迟T₁起作用的参数是从发送器到接收器在网络上的单向延迟(即，物理延迟)、在空中接口上的传输延迟和由于网络队列、重新排序等引起的到达间隔(interarrival)抖动而导致的延迟：

T₁＝physical delay+transmission delay+interarrival delay jitter  (1)

或者更准确地说，

$T_1=\mathrm{physical\; delay}+\frac{\mathrm{average\; packet\; size}}{\mathrm{available\; downlink\; bitrate}}+\mathrm{interarrival\; delay\; jitter}---\left(2\right)$

假设分组的初始传输丢失，T₂表示在分组理论到达与接收器向发送器提供指示分组丢失的反馈的时间点之间的时间间隔。

因此，T₂包括在客户机检测分组丢失所需的时间(分组丢失检测时间)和从客户机到下一反馈报告的平均时间。

T₂＝packet loss detection time+average time to next feeedback report  (3)

分组丢失检测时间取决于是偶尔丢失单个分组(单一(single-ton)丢失)还是突发地出现分组丢失(突发丢失)。在第一种情况下，分组丢失检测时间应当等于在接收器处经历的到达间隔延迟抖动。在第二种情况下，必须给缓冲时间加上额外的保护时间以确定实际值。该保护时间可以被定义为平均丢失突发，并且反映了检测突发丢失要花费较长的时间这一事实。

通常丢失事件是均匀分布的，使得到下一反馈报告的平均时间通常是RTCP报告间隔的一半：

average time to next feedback report＝1/2·RTCP report interval    (4)

反馈报告的延迟T₃本质上可以与延迟T₁类似的方式计算出。

T₃＝physical delay+transmission delay+interarrival delay jitter    (5)

或者更准确地说：

$T_3=\mathrm{physical\; delay}+\frac{\mathrm{average\; packet\; size}}{\mathrm{available\; uplink\; bitrate}}+\mathrm{interarrival\; delay\; jitter}---\left(6\right)$

最后，在发送器的重传的处理时间表示为T₄，包括发送器确定要重传哪些分组所需的时间(反馈处理时间)和在发送器的排队时间，即，要重传的分组在被实际发送前停留在发送器的传输(重传)队列中的时间：

T₄＝feedback processing time+queuing time    (7)

应当注意，T₁+T₂+T₃对应于往返(roundtrip)时间(RTT)：

              RTT＝T₁+T₂+T₃     (8)

RTT典型地小于RTCP报告间隔。否则，由于接收器将在不首先等待分组重传的情况下发送反馈，报告将会过量。此外，RTT与反馈处理时间之和同样典型地落在RTCP报告间隔内，这是因为服务器通常保证定义的重传带宽，因此该时间不会增加太多。

另一个对可以提供的报告冗余有影响的RTP会话的重要“变量”是已经在上面提到的客户机缓冲时间。客户机缓冲时间通常可以定义为特定数据分组在“输出”到用户之前被缓存在接收器的存储器中的时间间隔。例如，对于视频流会话，客户机缓存时间可以理解为在向用户显示数据分组的内容之前将数据分组存储在接收器的存储器(缓冲区)中的时间间隔。

在分组被提供到用户之前RTP会话中可以提供的重传次数可以表示为：

$\mathrm{no}.\mathrm{of\; possible\; retransmissions}=\mathrm{Integer}\left(\frac{\mathrm{client\; buffering\; time}-(T_1+T_2+T_3+T_4)}{\mathrm{RTCP\; report\; interval}}\right)---\left(9\right)$

“Integer()”函数从除法结果中提取整数值。RTCP报告间隔(对于上行链路传输)定义为：

$\mathrm{RTCP\; repore\; interval}=\frac{\mathrm{average\; RTCP\; packet\; size}}{\mathrm{available\; uolink\; RTCP\; banwidth}}---\left(10\right)$

其中，

average RTCP packet size＝1/16·current RTCP packet size+15/16·average RTCP packetsize(11)

在该方程中，当前RTCP分组大小等于要发送的下一RTCP反馈的大小。

上述计算的一种简化是在T₂的定义中只考虑分组的非突发(即，单一丢失)，即，

T₂＝interarrival delay jitter    (12)

由于T₁+T₂+T₃+T₄可能不是总能在客户机得到的，因此可以如图3所示使用对该和的保守估计(注意，为了示例的目的，假设最小重传次数3)。例如，RTCP报告间隔值可以表示对该和的粗略估计，保守的缓冲时间client_buffering_time’可以定义为：

client_buffering_time′＝client_buffering_time-rtcp_report_interval保守的客户机缓冲时间client_buffering_time’也可以理解为确保所要求的最小重传次数min_no_rtxs的缓冲时间。当然这只有在值T₁+T₂+T₃+T₄小于RTCP报告间隔时有效，而这正是通常的情况，因为如果不是这样的话，客户机在发送反馈前将不等待可能的重传。这应当由负责使用SDP或类似协议编译会话描述信息的服务器或内容创建者来确保。

根据本发明的一个实施例，可能的重传次数的计算(见方程9)可以简化为：

$\mathrm{no}.\mathrm{of\; possible\; retransmissions}=$

$=\mathrm{Integer}\left(\frac{\mathrm{client\; buffering\; time}-(T_1+T_2+T_3+T_4)}{\mathrm{RTCP\; report\; int\; erval}}\right)=$

$\≈\mathrm{Integer}\left(\frac{\mathrm{client\; buffering\; time}-\mathrm{RTCP\; report\; int\; erval}}{\mathrm{RTCP\; report\; int\; erval}}\right)=---\left(13\right)$

$=\mathrm{Integer}\left(\frac{\mathrm{client\; buffering}{\mathrm{tine}}^{\′}}{\mathrm{RTCP\; report\; int\; erval}}\right)$

当然，也可以使用方程9的更精确的计算。然而，方程13可能更容易实现。在PSS流业务的初始阶段，客户机请求关于从特定服务器提供的会话细节的描述。响应于该请求，服务器发送会话描述。其中，会话描述使下列参数为客户机所知：

■媒体会话使用的编解码器的MIME类型：例如，H263、AMR、MPEG4等。

■对于接收器报告的RTCP带宽共享，client_rtcp_bandwidth(比特每秒)。对于诸如PSS规范所指向的那些单播流应用，缺省带宽共享是对发送器和接收器每个的总RTCP带宽的50％。可以使用RFC 3556的规定显式地指定其他值。总RTCP带宽通常是总会话带宽的5％。

■可选的描述编解码器的MIME类型参数。这些参数可以用于计算流的其他值，如分组速率(分组数量每秒)。

■可选的客户机可以使用的最大RTCP分组大小。当前在PSS框架内可以限制服务器的RTP(不是RTCP)分组大小。将来对于RTCP报告分组的类似限制是可能的。此外，根据本发明的实施例，下列额外的参数为客户机所知：

■服务器建议的最小重传次数min_no_rtxs。服务器可以建议客户机保证对每个分组的最小重传次数。原因可能在于，业务提供者关心链路上的分组丢失。如上所述，PSS流业务中的重传需要被反馈中的通用NACK报告块触发。

■(也是)服务器建议的报告冗余report_redundancy。这个量指示使用损失RLE报告块报告一个分组多少次。对于业务提供者，知道链路达到的性能(分组到达与否)、以及向客户机提供分组最大需要多少次重传是很重要的。这对于收费也是很重要的，其中只对个人感觉的服务质量向客户机收费。

■可以如下面段落所述从会话参数中得出的客户机缓冲时间client_buffering_time(用秒来计量)。

考虑客户机缓冲时间，有两种可能的情形。

第一种可能是，客户机不支持3GPP PSS框架中定义的比特率适应。

在这种情况下，可以选择client_buffering_time等于初始缓冲时间，即，客户机在会话开始时开始读出缓冲区的分组之前经过的时间。

第二种可能是，客户机支持3GPP PSS框架中定义的比特率适应。在这后一种情况中下，客户机可获得下列参数：

■在“3GPP-适应”头中告知的缓冲区大小buffer_size。该参数应当对应于接收和去抖动缓冲区，该缓冲区具有用于包括RTP头的完整RTP分组的该给定空间量。所指定的缓冲区大小还可以包括用于该媒体的任何预解码器缓冲空间。该参数因此对应于在任何给定会话时刻处客户机可能具有的可用会话数据(RTP分组)的最大大小。通常，该参数不用于确定客户机缓冲时间值。

■在“3GPP-适应”头中告知给客户机的目标保护时间target_protection_time(“目标-时间”参数)。该参数表示作为目标的最小缓冲级别，或者换句话说，为了保证不间断的重放并且允许服务器调节传输速率(如果需要的话)、在客户机处期望的重放时间量(以毫秒为单位)。根据本发明的一个实施例，使用该参数作为客户机缓冲时间client_buffering_time。

一旦客户机接收到会话描述信息，客户机就可以计算是否告知的对给定媒体流的RTCP带宽共享(client_rtcp_bandwidth)和期望的client_buffering_time被选择得使得可以进行分组丢失的报告。此外，还可以计算在给出RTCP带宽共享和客户机缓冲时间的情况下，是否可以提供由report_redundancy参数所示的期望的报告冗余和由min_no_rtxs参数所示的要求的最小重传次数。

应当记得，报告冗余是指提供网络监控、收费等问题，而提供的最小重传次数是基于前面提到的通用NACK反馈。

根据一个实施例，假设客户机的缓冲区对每个分组将定时器设为client_buffering_time秒。如果在所述时间间隔内没有接收到分组，则定时器超时并且不能再请求重传该分组(即，不能在另外的通用NACK消息中包含该分组)。

此外，还可以假设过去的RTCP报告(包括之前发送的通用NACK报告块和损失RLE报告块)被保存在客户机处的发送缓冲区中。可以例如对应于server_buffering_time(以秒为单位)设置该缓冲区的大小。此外，该缓冲区应当足够大，以存储下面描述的方法所需要发送的RTCP分组。

下面段落描述根据本发明实施例的示例性算法，它是对RFC 3550附录A中所描述的标准RTP算法的补充。与标准RTP算法不同，根据该算法的发明允许考虑参数min_no_rtxs和report_redundancy来配置PSS一致会话。该算法帮助客户机找出要实现下面目的所需的通用NACK和损失RLE报告的大小：

■允许对每个分组的最大分组重传次数，或者使最小重传次数min_no_rtxs在客户机缓冲时间内，

■提供report_redundancy参数所设置的报告冗余(如果可能的话)，

■同时符合接收器报告的给定RTCP带宽和客户机缓冲能力。

客户机可以从第一个RTCP分组开始，对客户机发送的每个RTCP接收器报告执行下面的示例性步骤。

步骤1：在每RTP/AVPF的1秒初始等待周期之后，客户机可以在新的通信NACK消息中请求分组重传。从实现的角度上看，这个步骤是查找操作，因为在根据上面提到的Rey等人的因特网草案实现重传的每个客户机处都应当保留挂起请求的列表。

示例性的列表可以包括两列：一列具有顺序号SN，而另一列具有标记，指示具有给定SN的分组是接收到还是未接收到，例如“0”是未接收到，“1”是接收到。在NACK中包含该列表中存在的未接收到的分组。要注意，在相应分组的客户机缓冲时间(client_buffering_time)期满之后，未接收到的分组被从该列表中删除。

步骤2：第二步骤是计算对于给定RTCP带宽client_rtcp_bandwidth、通用NACK报告块中报告的分组的最大重传次数。由于挂起重传的分组是每个重传分组为了实施最小重传次数(min_no_rtxs)而应当包括的最小信息集合，因此可以通过将client_buffering_time′除以当前RTCP报告间隔值rtcp_report_interval来计算最大重传次数：

$\max \_\mathrm{no}\_\mathrm{rtxs}=\frac{\mathrm{client}\_\mathrm{buffering}\_{\mathrm{time}}^{\′}}{\mathrm{rtcp}\_\mathrm{report}\_\mathrm{int\; erval}}=\mathrm{client}\_\mathrm{buffering}\_{\mathrm{time}}^{\′}\·\frac{\mathrm{client}\_\mathrm{rtcp}\_\mathrm{bandwidth}}{\mathrm{avg}\_\mathrm{rtcp}\_\mathrm{paket}{\_\mathrm{size}}_{\mathrm{NACK}}}---\left(14\right)$

应当注意，该计算包括上面方程(13)中提供的简化。RTCP报告间隔参数rtcp_report_interval通常由每个RTP客户机和服务器作为RTP基本算法的一部分保存。

平均RTCP分组大小avg_rtcp_packet_size_NACK可以如下计算(也参见上面方程11)：

              avg_rtcp_packet_size_NACK＝

1/16·current_rtcp_packet_size_NACK+15/16·avg_rtcp_packet_size

                          (15)

当前RTCP分组大小(字节为单位)，即，当包括通用NACK报告块(而不是损失RLE报告块)时下一反馈消息的分组大小，可以如下计算：

current_rtcp_paeket_size_NACK＝K+(step(n，17))·4     (16)

其中step()是数学上的阶梯函数，取n和常数17作为参数。17是在单个通用NACK报告块中可以请求的分组数量。在单个通用NACK报告块中可以请求多于/少于17个分组的情况下，当然可以选择17以外的常数作为阶梯函数的参数。对于n的几个值：

        step(n，17)＝

        0    if    n＜＝0；

        1    if  1＜＝n＜＝17；

        2    if1·17+1＜＝n＜＝2·17；

        3    if2·17+1＜＝n＜＝3·17

        ...

K是涉及包含存在至少一个通用NACK消息的RTCP接收器消息的IP分组中的固定字段的常数。

例如，如果分组是32个字节的一个接收器报告(RR)加上12个字节的一个SDES项(带有CNAME)的标准组合，而没有加密首标或简要表专用扩展部分，固定字段相当于IP首标+UDP首标+RTCP首标+1RR+1SDES项(CNAME)+NACK固定字段，即，20+8+8+24+12+12＝84个字节。

在分组包含诸如电话号码、电子邮件之类的简要表专用扩展部分或其它SDES项，或诸如BYE分组或专用分组(APP)之类的其它RTCP报告块的情况下，必须将固定字段加入到这个常数K中。这同样适用于下面的K′。

如果计算的最大重传次数(方程14)max_no_rtxs大于1(＞1)，这意味着丢失的分组有机会在以后的重传中被接收到。

通常，可以要求客户机服从最小重传次数min_no_rtxs。如果不可能做到这一点，即，max_no_rtxs＜min_no_rtxs，客户机可以决定用较低的重传次数继续进行或重新开始会话，当在RTCP带宽份额和客户机缓冲时间给出的约束内不能为分组提供所需最小重传次数时，选择其它设置(例如，要求较小缓冲时间的一些编解码配置，通过选择较大的RTCP带宽、和保护得较好使min_no_rtxs较小的流等)。

换句话说，如果根据上面的计算可以满足客户机要求的最小重传次数，可以将数据加入到反馈中，直到达到最大分组大小(参见下面)为止。否则，RTCP分组太大，不能频繁得像要求的那样请求重传。

允许请求重传分组min_no_rtxs次的RTCP分组的最大大小max_rtcp_packet_size可以按如下计算：

$\max \_\mathrm{rtcp}\_\mathrm{packert}\_\mathrm{size}=\mathrm{client}\_\mathrm{buffering}\_{\mathrm{time}}^{\′}\·\frac{\mathrm{client}\_\mathrm{rtcp}\_\mathrm{bandwidth}}{\min \_\mathrm{no}\_\mathrm{rtxs}}---\left(17\right)$

注意，方程17是针对min_no_rtxs的每个值定义的，因为后一参数总是大于1。否则，使用如Rey等人在上述的因特网草案中建议的重传就没有什么意义。

步骤3：假设客户机能够强制进行min_no_rtxs次和假设max_no_rtxs＞min_no_rtxs，下一个步骤是用损失RLE报告块(除了请求重传的通用NACK之外)填充反馈消息，直到达到如利用方程17计算的max_rtcp_packet_size。换句话说，max_rtcp_packet_size与current_rtcp_packet_size_NACK之间的差值等于可以加入到当前RTCP分组中而不会破坏对最小重传次数min_no_rtxs的要求的数据量：

payload_margin＝max_rtcp_packet_size-current_rtcp_packet_size_NACK    (18)

与上面的情况(参见方程16)类似，作为n的函数，为带有通用NACK报告和损失RLE报告块的RTCP计算包括IP和UDP首标的RTCP分组大小的一般公式如下：

current_rtcp_packet_size＝K′+(step(n，17)+step′(n′，30))·4       (19)

其中，step()与上面相同和step′()是将n′和常数30取作参数的数学阶跃函数。请注意，在方程19中，假设至少一个损失RLE报告块包括在反馈中，否则，方程16可以用于计算当前RTCP分组大小。参数30是在单个损失RLE报告块中可以报告的分组数量。当然，在单个损失RLE报告块可能报告多于/少于30个分组的情况下，对于阶跃函数，可以将不同于30的常数选作参数。有关n′的几个值：

   step′(n′，30)＝

        0    ifn′＜＝0；

        1    if1＜＝n′＜＝1·30；

        2    if1·30+1＜＝n′＜＝2·30；

        3    if2·30+1＜＝n′＜＝3·30；

        ...

应该注意到，n和n′逐步增加。其理由是RTCP报告是32-位排列的，每当要报告的分组数量超过17或30的倍数时，加入到一整个4-字节字。

在方程19中，K′是比上面为方程16定义的K大的6个字节，因为(至少)一个损失RLE报告块包括在接着要发送的(当前)RTCP反馈消息中。

如果要求客户机服从给定report_redundancy值，它可以包括如通过这个值定义的过去损失RLE报告块。例如，2的report_redundancy值意味着在两个相继RTCP报告中发送同一个损失RLE报告块。如果该值是3，那么，在3个相继RTCP分组中出现同一个损失RLE报告块，以此类推。换句话说，如果报告冗余度被设置成2，单个RTCP报告(即，其中的RLE报告块)应该在过去的两个RTCP报告间隔上被报告，和如果报告冗余度被设置成3，应该报告过去的三个RTCP报告间隔，如此等等。这可能要求客户机保持包括可能过期的分组在内的接收和未接收到分组的列表(例如，两列阵列)。这与客户机缓冲器的内容不同，它只包括还没有过期的分组。

步骤4：也有可能发生这样的情况，包括为了提供所需报告冗余度不得不加入到下一个RTCP反馈消息中(除了通用NACK报告块之外)的所需个损失RLE报告块的RTCP分组大小超过允许的最大RTCP分组大小max_rtcp_packet_size。在这种情况下，客户机可能试图通过游程长度编码减小损失RLE报告块的大小。作为进一步的选择，像如上所述的细化那样的其它方法也可以用于减小分组大小。但是，当考虑使用细化时，报告冗余度将降低。

如果这些机制无法充分减小RLE报告块的大小来保证所需报告冗余度，客户机可以决定不服从这个report_redundancy值，和可以继续发送。可替代地，它可以重新开始会话和选择较长的客户机缓冲时间或位速率较低的一些编解码配置。

步骤5：最后，以标准方式计算在按照RFC 3550，Annex A的标准算法中的其余变量更新和标准过程，例如avg_rtcp_packetsize和rtcp_report_interval：avg_rtcp_packet_size＝1/16·current_rtcp_packet_size+15/16·avg_rtcp_packet_size

$\mathrm{rtcp}\_\mathrm{report}\_\mathrm{interval}=\frac{\mathrm{avg}\_\mathrm{rtcp}\_\mathrm{packet}\_\mathrm{size}}{\mathrm{client}\_\mathrm{rtcp}\_\mathrm{bandwidth}}$

每当发送RTCP分组时，可以重复步骤1到5。可替代地，仅当发生客户机性能的变化，尤其仅当发生客户机缓冲时间或客户机RTCP带宽的变化时，客户机也可以选择通过这些步骤进行叠代。

在已经发送了反馈消息之后，客户机可以根据在RFC 3550中概述的条款来更新会话的各种参数。例如，客户机可以重新计算平均RTCP分组大小，可以重新计算从中得出的RTCP报告间隔，可以更新发送缓冲器内容，并可以开始对要发送的下一个RTCP反馈进行计算。

在另一个实施例中，通过客户机降低report_redundancy，可以进一步减小损失RLE报告块的大小。但是，在这种状况下，会引起客户机是否仍然可以获得合理级别的冗余报告的问题。

在允许测量上行链路上的分组损失率的实现中，可以降低报告冗余度。分组损失率可以从，例如来自发送器的RTCP报告中估计出来。可替代地或另外，客户机可以从链路建立过程中掌握一些有关链路QoS的先验知识。因此，当到客户机的特定链路上的分组损失率低/高时，可以进一步降低/提高冗余报告的级别，因为分组损失率越低/越高，当利用不可靠传输协议时，在发送器上越有可能/越不可能接收到客户机的反馈。

除了在Friedman等人的因特网草案中规定的那些之外，减小损失RLE报告块大小的另一种方法可以，例如，基于各个分组的重要性的估计。例如，在诸如MPEG-4分组之类的渐进编码技术中，分组具有不同的优先级。因此，在报告中可能放弃较不重要的分组，即，P帧。

可替代地或另外，为了减小损失RLE报告块的大小，可以考虑当前应用级QoS和链路级QoS。例如，如果当前应用级QoS足够高和/或链路级QoS很低(即，链路上发生拥塞)，客户机可以决定放弃一些丢失分组的报告。例如，MPEG4编解码实现了高级分组损失弹性措施。在一些情况下，取决于流的内容，很可能出现在链路上丢失了一些分组，而画面的质量不受这些损失影响的情况；尤其，如果B帧丢失了，造成的影响最小，分组重传的成本可能较大，因此，该应用可能决定放弃这个分组。

对于3GPP PSS单播流服务，本发明具有如下优点。首先，它提供了带有利用通用NACK报告块和损失RLE报告块构建RTCP接收器报告的用于流服务器和客户机的附加机制的3GPP PSS框架。假设客户机知道client_buf-fering_time和client_rtcp_bandwidth，该方法能够规定报告的大小以提供最小重传次数min_no_rtxs和给定report_redundancy，应该多频繁地发送它们，和它们应该涵盖多少个分组。

如上所述，与重传的性能，即，在客户机(成功地)接收到分组之前重传它们多少次有关，报告冗余度对于收费应用和尤其对于网络监视是重要的。

并且，本发明定义了规定客户机配置的宽频谱的框架，以便可以视在客户机上可获得哪些信息和损失RLE报告压缩应该多有效而定建立最简单客户机到全能客户机。此外，本发明的一些实施例提供了附加方法来减小RTCP反馈的大小。

接着，参照图4、5和6描述本发明的不同和更具体示范性实施例。

图4示出了根据本发明实施例的在流会话内提供RTCP反馈的方法的初始步骤。一旦当前RTCP报告间隔终结，客户机就准备将下一个RTCP反馈发送到服务器。首先(步骤401到404)，客户机可以确定设置的会话参数是否能够保证可以发送所需最小重传次数(min_no_rtxs)。为了这个目的，客户机可以确定401当前RTCP分组(要发送的下一个RTCP分组)的大小，假设它只包含保证为会话配置的最小重传次数所需的通用NACK报告块。如前所述(参见方程16)，当前RTCP分组的大小取决于要报告的分组的数量。根据这个计算值(current_rtcp_packet_size_NACK)、以及先前RTCP反馈消息的平均大小(sent_rtcp_packet_size)，可以利用上面的方程15确定402平均RTCP分组大小(avg_rtcp_packet_size_NACK)。接着，计算403在客户机缓冲时间内允许的最大重传次数(max_no_rtxs)(参见方程14)。

根据这些计算，客户机可以在步骤404中确定请求的最小重传次数(min_no_rtxs)是否允许。如果不允许，则客户机可以用不同的一组如上所述会话参数重新配置或重新开始(405)会话。

在max_no_rtxs＞min_no_rtxs的情况下，选择会话参数客户机缓冲时间、RTCP带宽份额和最小重传次数，以便客户机可以在这些约束参数下工作。因此，在下一个步骤406中，客户机可以因此将提供最小重传次数所需的通用NACK报告块加入到当前反馈消息中。在会话不需要带有损失RLE报告块的(附加)报告的情况下(参见步骤407)，客户机可以继续将只包含通用NACK报告块的当前反馈消息发送408到服务器。

如果有关分组损失的(冗余)报告对于会话来说是强制性的，客户机接着确定当前反馈消息是否具有足够的容量不仅包含保证最小重传次数的通用NACK报告块，而且包含保证有关分组损失的冗余报告所需的数量R个损失RLE报告块。

为了这个目的，客户机接着可以在步骤409中确定允许提供最小重传次数的RTCP反馈消息的最大大小(参见方程17)。如上所述，最大RTCP分组大小max_rtcp_packet_size是表示当保证最小重传次数时允许提供反馈的平均消息大小的度量。

由于知道max_no_rtxs＞min_no_rtxs(参见步骤404)，因此，也清楚最大RTCP分组大小等于或大于包含通用NACK报告块的平均RTCP分组大小。

在步骤410中，客户机确定当前RTCP分组中剩下的有效负载余量(payload margin)。换句话说，客户机确定可以进一步将多少个字节(payload_margin)加入到已经包含通用NACK报告块的当前RTCP分组中而不会破坏RTCP反馈的最大允许(平均)大小。

一般说来，沿着如图5和6所示的流程图的接着步骤应该理解为例示如果还有可能，如何用损失RLE报告块填充当前RTCP反馈消息内的其余空间(payload_margin)以保证(最小)冗余报告的例子。正如下面更详细描述的那样，在一些情况下，也许不能对丢失分组作出最小数量的冗余报告。不过，在这种状况下，最好至少提供某种级别的(冗余)报告，而不是一点也不报告。

在接着的步骤501(图5)中，客户机可以构建达到所请求最小报告冗余度所需的R个损失RLE报告块。由于损失RLE报告块的大小可能太长，无法使它们与有效负载余量相配，客户机可以像步骤502所例示的那样对损失RLE报告块进行游程长度压缩。请注意，这个步骤是可选的。接着，在步骤503中确定R个(压缩)损失RLE报告块的大小，和在步骤504中将该值与有效负载余量相比较，以便确定所有R个损失RLE报告块是否与当前RTCP反馈消息相配，而不会破坏允许达到所请求最小重传次数的最大允许(平均)RTCP分组大小。

如果是，将R个(压缩)损失RLE报告块加入到(505)反馈消息中，和客户机发送(506)包含数个通用NACK报告块和数(R)个损失RLE报告块的RTCP反馈消息。在这种情况下，客户机可以保证达到最小重传次数，和还可以提供最小报告冗余度。

但是，如果在步骤504中R个(压缩)损失RLE报告块的大小大于有效负载余量，客户机可以尝试至少提供一些有关丢失分组的(冗余)报告。为了这个目的，客户机可以进一步转到步骤507，和可以减少要包括在当前反馈中的损失RLE报告块的数量，直到其余数个(压缩)损失RLE报告块与当前RTCP反馈消息的有效负载余量相配(509)。例如，客户机可以相继放弃有关如在以前的报告中可能已经报告过的“最老”分组的报告块(参见步骤507、508、509、511)。另一种可能性是进行细化，直到损失RLE报告块的大小下降到有效负载余量之下。更进一步，客户机还可以像上述那样考虑报告的分组的重要性。另一种可替代手段可以是，如有需要，将这些机制结合在一起。

关于这一点，图6例示了根据本发明另一个实施例形成RTCP反馈消息的进一步步骤。与图5中的那些相似的步骤已经指定了相同的标号，并且，在下文中，为了简洁起见，省略对它们的描述。

例示在图6中的步骤允许将细化和其它机制结合在一起减小损失RLE报告块的大小。值得注意的是，有关是否应用细化(参见步骤603)的决定可以根据当前在到客户机的下行链路上可达到的服务质量(QoS)作出(参见步骤601和602)。

例如，可以对RTCP反馈消息(参见RFC 3500第6.4节)的发送器和/或接收器报告块内的“fraction lost(丢失的一部分)”字段的计算值加以评估，和分别取作上行链路和下行链路上的当前QoS的指示。可替代地，也可以从移动通信系统提供明确商定的QoS测量值。例如，如果上行链路上的指示QoS高，即，这可能意味着，利用不可靠传输协议的发送很有可能不丢失客户机的RTCP反馈。因此，客户机可能确定比服务器配置的报告冗余度低的报告冗余度就足够了。在这种情况下，客户机可以决定将细化应用于损失RLE报告块。因此，除了如果应用了细化，客户机可能不再保证最小报告冗余度之外，步骤605与图5中的步骤505相似。

在本发明的另一个实施例中，客户机甚至可以根据可达到的QoS来决定减小最小重传次数。在这种情况下，客户机可以考虑不将所有通用NACK报告块包括到反馈中，而是以与针对图5的步骤507、508、509和511所述相似的方式只报告最近、较新的分组。

本发明的另一个实施例涉及本发明的上述各种实施例的实现。应该认识到，上述各种各样方法、以及上述图中的各种各样逻辑块可以利用诸如例如通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件等的计算设备(处理器)实现或执行。本发明的各种各样实施例也可以通过这些器件的组合来完成或具体化。

并且，本发明的各种各样实施例、它们的变体、和QoS有意识调度的解决方案也可以通过由处理器执行的软件模块或直接用硬件实现。此外，软件模块和硬件实现的组合也是可以的。软件模块可以存储在任何类型的计算机可读存储媒体，例如，RAM(随机存取存储器)、EPROM(电可编程只读存储器)、EEPROM(电可擦除可编程只读存储器)、闪速存储器、寄存器、硬盘、CD-ROM(光盘只读存储器)、或DVD(数字多功能盘)等中。

Claims (20)

1.一种将与至少一个流会话的数据分组有关的RTCP反馈消息从客户机(101)提供到流服务器(100)的方法，其中，至少一个流会话是利用RTP协议和RTCP协议提供的，并且其中，作为可用流会话带宽一部分的RTCP带宽被分配给所述RTCP反馈消息，该方法包含如下步骤：

在客户机(101)上接收会话描述信息，其中，会话描述信息指示所述RTCP反馈消息的RTCP带宽、在所述客户机缓冲时间内允许的最小重传次数、所述至少一个流会话的丢失数据分组的最小报告冗余度和所述客户机缓冲时间，

根据所述客户机缓冲时间和RTCP报告间隔确定(401、402、403)数据分组的最大重传次数，其中，RTCP报告间隔取决于平均RTCP反馈消息大小和分配给客户机(101)的RTCP带宽，

确定(404)最大重传次数是否大于或等于所述最小重传次数，

如果是：

则将数个通用NACK报告块加入到(406)RTCP反馈分组中，用于请求重传丢失数据分组，其中，加入到RTCP反馈分组中的数个通用NACK报告块能够使所述丢失数据分组在所述客户机缓冲时间内重传达所述最小次数，

确定(409)对分配的RTCP带宽、客户机缓冲时间和所述最小重传次数加以考虑之后允许的最大RTCP反馈消息大小，

根据以前发送的RTCP反馈消息的平均大小和包含所述数个通用NACK报告块的RTCP分组的大小，确定(402)所得平均RTCP反馈消息大小，

如果所得RTCP反馈分组的大小不超过所述最大RTCP反馈消息大小，则将数个损失RLE报告块加入到(505、510)所述RTCP反馈分组中，用于报告所述丢失数据分组，和

将RTCP反馈分组作为RTCP反馈消息从客户机(101)发送(506)到流服务器(100)。

2.根据权利要求1所述的方法，其中，在确定包括游程长度编码损失RLE报告块的所得RTCP反馈分组的大小是否没有超过所述最大RTCP反馈之前，游程长度编码(502)所述数个损失RLE报告块。

3.根据权利要求1或2所述的方法，其中，该方法进一步包含步骤：降低客户机通过会话描述信息配置的最小报告冗余度。

4.根据权利要求3所述的方法，进一步包含步骤：确定(602)为所述流会话的分组提供的上行链路服务质量，和

其中，如果确定的所述服务质量在预定阈级别之上，则降低最小报告冗余度。

5.根据权利要求3或4所述的方法，其中，客户机通过减小所述数个损失RLE报告块的大小来降低报告冗余度。

6.根据权利要求3到5之一所述的方法，其中，流会话的数据包含提供基本流媒体质量的基本数据层和提高基本流媒体质量的至少一个提高层，

其中，减小所述数个损失RLE报告块的大小的步骤包含只让与包含所述基本数据层的数据的数据分组有关的信息包括在所述损失RLE报告块内。

7.根据权利要求6所述的方法，其中，至少一个流会话的数据是MPEG流，基本数据层包含I帧，以及至少一个提高层包含P帧和/或B帧。

8.根据权利要求6或7所述的方法，该方法进一步包含步骤：根据在客户机上已经接收的数据分组确定丢失数据分组是否包含基本数据层的数据。

9.根据权利要求3到8之一所述的方法，其中，通过细化(603)来减小所述数个损失RLE报告块的大小。

10.根据权利要求3到8之一所述的方法，其中，通过减少(507、508、509、511)在所述RTCP反馈分组中报告的所述数个损失RLE报告块来减小所述数个损失RLE报告块的大小。

11.根据权利要求1或2所述的方法，其中，将数个损失RLE报告块加入到所述RTCP反馈分组中实现所述丢失分组的所述最小报告冗余度。

12.根据权利要求1到11之一所述的方法，其中，流会话的MIME类型参数表示分组速率。

13.根据权利要求1到12之一所述的方法，进一步包含步骤：根据在客户机上接收的数据分组的序号来确定所述至少一个流会话的哪些数据分组丢失了。

14.一种将与至少一个流会话的数据分组有关的RTCP反馈消息从客户机(101)提供到流服务器(100)的方法，其中，至少一个流会话是利用RTP协议和RTCP协议提供的，该方法包含如下步骤：

确定可在流会话的会话约束内提供的数据分组的最大重传次数是否大于客户机允许的最小重传次数，

如果是，则将数个通用NACK报告块加入到RTCP反馈分组中，用于请求重传丢失数据分组，其中，加入到RTCP反馈分组中的数个通用NACK报告块能够使所述丢失数据分组在客户机缓冲时间内重传达所述最小次数，

确定就所述会话约束而言允许的最大RTCP反馈消息大小，

将数个损失RLE报告块加入到所述RTCP反馈分组中，用于报告丢失的和接收的数据分组，使所得RTCP反馈分组的大小不超过所述最大RTCP反馈消息大小，和

将RTCP反馈分组作为RTCP反馈消息从客户机(101)发送到流服务器(100)。

15.根据权利要求14所述的方法，进一步包含如下步骤：根据确定的最大RTCP反馈消息大小和通用NACK报告块的大小来计算RTCP反馈分组中的有效负载余量，和

确定与那个有效负载余量相配的数个损失RLE报告块，以便当将所述数个损失RLE报告块加入到所述RTCP反馈分组中时，保证所得RTCP反馈分组不会超过所述最大RTCP反馈消息大小。

16.一种在移动通信系统中将与至少一个流会话的数据分组有关的RTCP反馈消息从客户机发送到流服务器的客户机，其中，至少一个流会话是利用RTP协议和RTCP协议提供的，和其中，作为可用流会话带宽一部分的RTCP带宽被分配给所述RTCP反馈消息，该客户机包含：

接收器，用于接收会话描述信息，其中，会话描述信息指示所述RTCP反馈消息的RTCP带宽、在所述客户机缓冲时间内允许的最小重传次数、所述至少一个流会话的丢失数据分组的最小报告冗余度和所述客户机缓冲时间，

处理装置，用于根据所述客户机缓冲时间和RTCP报告间隔确定(401、402、403)数据分组的最大重传次数，其中，RTCP报告间隔取决于平均RTCP反馈消息大小和分配给客户机(101)的RTCP带宽，并且用于确定(404)最大重传次数是否大于或等于所述最小重传次数，

其中，处理装置进一步适用于：

如果最大重传次数大于或等于所述重传最小次数，

则将数个通用NACK报告块加入到(406)RTCP反馈分组中，用于请求重传丢失数据分组，其中，加入到RTCP反馈分组中的数个通用NACK报告块能够使所述丢失数据分组在所述客户机缓冲时间内重传达所述最小次数，

确定(409)对分配的RTCP带宽、客户机缓冲时间和所述最小重传次数加以考虑之后允许的最大RTCP反馈消息大小，

根据以前发送的RTCP反馈消息的平均大小和包含所述数个通用NACK报告块的RTCP分组的大小，确定(402)所得平均RTCP反馈消息大小，和

如果所得RTCP反馈分组的大小不超过所述最大RTCP反馈消息大小，则将数个损失RLE报告块加入到(505、510)所述RTCP反馈分组中，用于报告所述丢失数据分组，和

客户机(101)进一步包含发送器，用于将RTCP反馈分组作为RTCP反馈消息发送(506)到流服务器(100)。

17.根据权利要求16所述的客户机，进一步包含适用于执行根据权利要求2到13之一所述的方法的装置。

18.一种用于存储指令的计算机可读媒体，当所述指令被移动通信系统中的客户机的处理器执行时，通过如下步骤使客户机将与至少一个流会话的数据分组有关的RTCP反馈消息从客户机(101)提供到流服务器(100)，其中，至少一个流会话是利用RTP协议和RTCP协议提供的，和其中，作为可用流会话带宽一部分的RTCP带宽被分配给RTCP反馈消息：

在客户机(101)上接收会话描述信息，其中，会话描述信息指示所述RTCP反馈消息的RTCP带宽、在所述客户机缓冲时间内允许的最小重传次数、所述至少一个流会话的丢失数据分组的最小报告冗余度和所述客户机缓冲时间，

根据所述客户机缓冲时间和RTCP报告间隔确定(401、402、403)数据分组的最大重传次数，其中，RTCP报告间隔取决于平均RTCP反馈消息大小和分配给客户机(101)的RTCP带宽，

确定(404)最大重传次数是否大于或等于所述最小重传次数，

如果是：

将数个通用NACK报告块加入到(406)RTCP反馈分组中，用于请求重传丢失数据分组，其中，加入到RTCP反馈分组中的数个通用NACK报告块能够使所述丢失数据分组在所述客户机缓冲时间内重传达所述最小次数，

确定(409)对分配的RTCP带宽、客户机缓冲时间和所述最小重传次数加以考虑之后允许的最大RTCP反馈消息大小，

根据以前发送的RTCP反馈消息的平均大小和包含所述数个通用NACK报告块的RTCP分组的大小，确定(402)所得平均RTCP反馈消息大小，

如果所得RTCP反馈分组的大小不超过所述最大RTCP反馈消息大小，则将数个损失RLE报告块加入到(505、510)所述RTCP反馈分组中，用于报告所述丢失数据分组，和

将RTCP反馈分组作为RTCP反馈消息从客户机(101)发送(506)到流服务器(100)。

19.根据权利要求18所述的计算机可读媒体，进一步存储当被客户机的处理器执行时使客户机执行根据权利要求2到13之一所述的方法的指令。

20.一种包含将至少一个流会话提供到客户机的流服务器、和根据权利要求16或17所述的客户机的系统，其中，至少一个流会话是利用RTP协议和RTCP协议提供的。

Images