一种组合使用流媒体裁剪技术和显性拥塞通知技术的方法

摘要

本发明提供了一种用于为基于可分级的视频业务实现组合使用流媒体裁剪技术和显性拥塞通知技术的方法。通过本发明提供的优选的技术方案，能够将ECN技术和流裁剪技术结合地应用至基于可分级的视频业务，并能够产生可靠的显性拥塞通知和/或周期性显性拥塞通知总结报告。由此在收到显性拥塞通知和/或周期性显性拥塞通知总结报告之后，RTP接收端能够实现良好的码率适配或拥塞控制效果。并且依据本发明的ECN技术还考虑了无线网络中的时变性问题。此外，在本发明中，网络设备能够根据需要为同一个基于可分级的视频业务设置不同的拥塞事件，这对于RTP发送端实施准确的拥塞控制也是非常有利的。

说明书

技术领域

本发明涉及移动通信技术，尤其涉及一种用于为基于可分级的 视频业务实现组合使用流媒体裁剪技术和显性拥塞通知技术的方 法。

背景技术

在文献IETF RFC 3168(09/2001)“将显性拥塞通知添加入IP网 络(The Addition of Explicit Congestion Notification(ECN)to IP)” 中提出了一种显性拥塞通知(Explicit Congestion Notification，ECN) 技术，即在发现即将发生拥塞时，将在IP数据包中作出指示，而不 是直接丢弃。具体地，在IP数据包的包头中设置ECN域。如图1 所示，该ECN域包括两比特，即显性拥塞指示传输比特(ECN-Capable Transport，ECT)和拥塞预警比特(Congestion Experienced，CE)。 当发送端将这两个比特设置为00时，将指示各个路由器不使用ECN 技术。当发送端将这两个比特设置为01或10时，指示各个路由器 使用ECN技术，当然在这之前，发送端与接收端之间还存在一个初 始化过程，以确定两者之间的传输路径是否支持ECN技术。而当两 者之间传输路径中的路由器将01或10更改成11时，则表示网络存 在拥塞，从而接收端在接收到带有11的IP数据包头的IP数据包时， 将生成显性拥塞通知反馈报告，并向发送端发送该显性拥塞通知反 馈报告。

另一方面，应用可分级视频编码的视频业务或应用多视角视频 编码的视频业务一般是基于由用户数据报协议(User Datagram Protocol，UDP)承载的实时传输协议(real-time transport protocol， RTP)流进行传输的。

现今，传输控制协议(Transmission Control Protocol，TCP)、 流控制传输协议(Stream Control Transmission Protocol，SCTP)和数 据报拥塞控制协议(Datagram Congestion Control Protocol，DCCP) 已经能够支持ECN技术。然而，由于用户数据报协议(User Datagram Protocol，UDP)缺少反馈机制，因此在如何将ECN技术应用至由 UDP承载的RTP流方面存在问题。

针对上述问题，在文献IETF RFC 6679(08/2012)“用于由UDP 承载的RTP流的ECN技术(Explicit Congestion Notification(ECN)for RTP over UDP)中提出了一种新的由RTP控制协议(RTP Control Protocol，RTCP)承载的反馈消息，该消息的数据包通过特定域的 取值，指示其包含显性拥塞通知反馈报告，其用于当所接收的IP数 据包中的显性拥塞通知域为11时，即时地生成并向RTP发送端发送 RTCP承载的显性拥塞通知反馈报告。此外，还提出一种使用RTCP 来传输的新的扩展报告块(Extended Report Block)，其用于周期性 地传输显性拥塞通知总结报告。并且在上述文献中提出了在这些报 告中包括下述参数：Extended Highest Sequence Number，用于计数与 该报告相关的最高的RTP序列号、ECT(0)Counter，用于计数带 有ECT(0)的RTP数据包的数量、ECT(1)Counter，用于计数带 有ECT(1)的RTP数据包的数量、ECN-CE Counter，用于计数带 有CE的RTP数据包的数量、not-ECT Counter，用于计数带有non-ECT 的RTP数据包的数量、Lost Packets Counter，用于计数丢失的RTP 数据包的数量，Duplication Counter，用于计数如下RTP数据包的数 量，即该RTP数据包和已接收的RTP数据包相同。在此仅简要地给 出了显性拥塞通知反馈报告以及周期性显性拥塞通知总结报告所应 当包括的参数的定义，对于详细内容，感兴趣的读者可以参考上述 文献。

而对于基于可分级的视频业务，还可以应用流裁剪技术，即基 于拥塞控制原理，媒体感知网络单元(media-aware network element， MANE)将对RTP数据包进行流裁剪(stream thinning)。在图2中 示出了现有技术中的这种流裁剪的实施过程。该技术移除一个或多 个完整的RTP数据包或RTP数据包的一部分，并根据具体情况改写 RTP数据包的头信息。而在流裁剪过程中，传输路径中的相关网络 设备，例如路由器也会实施ECN技术来指示即将发生的拥塞。在这 种情况下，由于RTP接收端没有意识到MANE已经移除了一个或多 个完整的RTP数据包。因此，当在生成显性拥塞通知反馈报告和/ 或周期性显性拥塞通知总结报告时，在计算例如参数ECT(0)计数、 ECT(1)计数和Lost Packets Counter时，将不会计数被MANE移除 的RTP数据包。因此，反馈至RTP发送端的由RTCP承载的显性拥 塞通知反馈报告和/或周期性显性拥塞通知总结报告将不再可靠。在 此，由于计算这些被移除的RTP数据包能够非常有助于RTP发送端 实现良好的码率适配或拥塞控制效果，因此不计数这些RTP数据包 将会降低反馈报告的可靠性和准确性。综上所述，在应用流裁剪技 术的情况下，现有技术不能实现可靠的显性拥塞通知反馈报告和/或 周期性显性拥塞通知总结报告。

此外，随着视频业务的不断增加，尤其是基于可分级的视频业 务(例如应用可分级视频编码(scalable video coding)的视频业务或 应用多视角视频编码(multiview video coding)的视频业务)的不断 增加对于ECN技术的设计提出更高的要求。如何在RTP传输路径中 的各网路设备中为基于可分级的视频业务实现ECN技术，是有待解 决的问题。特别的，在3GPP TS 36.300，va300，E-UTRAN中提出 了将前文所述的ECN技术应用至基站以控制编解码速率，但是却未 对该建议给出详细的实现方法。因此，例如如何在基站中为基于可 分级的视频业务实现ECN技术，用户终端如何向RTP发送端作出反 馈也是有待解决的问题。

发明内容

由此可见，背景技术中所提及的现有方案在应用流裁剪技术的 情况下，不能为基于可分级的视频业务确保显性拥塞通知反馈报告 和/或周期性显性拥塞通知总结报告的可靠性。并且，在背景技术中， 也没有针对如何为基于由UDP承载RTP流的基于可分级的视频业务 实现ECN技术给出明确的方案。

为了解决背景技术中的问题，根据本发明的第一方面，提出了 一种在网络单元中用于为基于可分级的视频业务实现组合使用流媒 体裁剪技术和显性拥塞通知技术的方法，其中，所述媒体感知网络 单元从RTP发送端接收基于由UDP承载的RTP流的所述基于可分 级的视频业务，并且所述基于可分级的视频业务的比特流包括基层 和一个或多个非基层，通过所述基层和一个或多个非基层传输所述 基于可分级的视频业务的IP数据包，所述方法包括如下步骤：A.确 定是否需要对所述一个或多个非基层上的基于可分级的视频业务的 IP数据包中的RTP数据包进行流裁剪；B.当需要对所述一个或多 个非基层上的基于可分级的视频业务的RTP数据包进行流裁剪时， 判断是否需要移除一个或多个完整的RTP数据包；以及C.当需要 移除一个或多个完整的RTP数据包时，则以虚拟RTP数据包替换该 RTP数据包，其中所述RTP虚拟数据包保留该RTP数据包的RTP 头信息，并在所述RTP虚拟数据包中以一个空的NAL单元来替换该 RTP数据包负载中的所有NAL单元。

优选地，所述基于可分级的视频业务包括应用可分级视频编码 的视频业务或应用多视角视频编码的视频业务。

优选地，当所述基于可分级的视频业务为应用可分级视频编码 的视频业务时，所述基层为应用可分级视频编码的视频业务的比特 流的基本层，所述非基层为应用可分级视频编码的视频业务的比特 流的增强层。当所述基于可分级的视频业务为应用多视角视频编码 的视频业务时，所述基层为应用多视角视频编码的视频业务的基本 视角，所述非基层为应用多视角视频编码的视频业务的比特流的非 基本视角。

优选地，所述网络单元包括媒体感知网络单元和基站，并且当 所述网络单元为所述媒体感知网络单元时，所述方法还包括步骤D： 将经流裁剪和/或未经流裁剪的基于可分级的视频业务的IP数据包 经由网络发送至网络设备，所述网络设备包括基站和路由器。

根据本发明的第二方面，提出了一种在网络设备中用于为基于 可分级的视频业务实现组合使用流媒体裁剪技术和显性拥塞通知技 术的方法，其中，所述基于可分级的视频业务是基于由UDP承载的 RTP流的，并且所述基于可分级的视频业务的比特流包括基层和一 个或多个非基层，通过所述基层和一个或多个非基层传输所述基于 可分级的视频业务的IP数据包，所述方法包括如下步骤：b.根据 预定条件确定是否需要将将IP数据包的IP数据包头中的显性拥塞通 知域设置为11，所述IP数据包经过流裁剪或未经过流裁剪；c.当 确定需要将IP数据包头中的显性拥塞通知域设置为11时，确定需 要将IP数据包头中的显性拥塞通知域设置为11的非基层的数量， 并且根据所述非基层的数量以降序的顺序确定需要将IP数据包头中 的显性拥塞通知域设置为11的非基层；以及d.对于需要将IP数据 包头中的显性拥塞通知域设置为11的每个非基层，将该非基层中的 至少一个IP数据包的IP数据包头中的显性拥塞通知域设置为11， 并生成更新后的IP数据包。

优选地，所述预定条件包括可用资源状态、缓冲器状态、信道 质量和/或链路质量。

优选地，所述网络设备包括基站和路由器。

优选地，在所述步骤b之前，所述方法还包括步骤a：a.从网络 接收经媒体感知网络单元流裁剪和/或未经所述媒体感知网络单元流 裁剪的基于可分级的视频业务的IP数据包。

优选地，所述步骤d进一步包括：对于需要将IP数据包头中的 显性拥塞通知域设置为11的每个非基层，将该非基层中的时间上连 续的两个或三个IP数据包的IP数据包头中的显性拥塞通知域设置为 11，并生成更新后的IP数据包。

由此，可以避免由于例如无线信道的时变性引起的IP数据包的 丢失，从而进一步确保了带有显性拥塞通知域设置为11的IP数据 包头的IP数据包能够被可靠地发送至RTP接收端。

优选地，所述方法还包括步骤e：e.将经更新和/或未更新的基 于可分级的视频业务的IP数据包发送至RTP接收端。

根据本发明的第三方面，提出了一种在RTP接收端中用于为基 于可分级的视频业务实现组合使用流媒体裁剪技术和显性拥塞通知 技术的方法，其中，所述基于可分级的视频业务是基于由UDP承载 的RTP流的，并且所述基于可分级的视频业务的比特流包括基层和 一个或多个非基层，通过所述基层和一个或多个非基层传输所述基 于可分级的视频业务的IP数据包，所述方法包括如下步骤：X1.从 网络设备接收经所述网络设备更新和/或未经所述网络设备更新的基 于可分级的视频业务的IP数据包；X2.根据IP数据包头中的显性拥 塞通知域的取值，针对不同的取值来分类地计数IP数据包中的RTP 数据包的数量，并且当从所述网络设备接收的IP数据包中的RTP数 据包为虚拟RTP数据包时，则不将该RTP数据包用于视频解码，并 且计数虚拟RTP数据包的数量；以及X3.当所接收的IP数据包中 的显性拥塞通知域为11时，生成并向RTP发送端发送由RTCP承载 的显性拥塞通知反馈报告。

优选地，当所接收的IP数据包中的显性拥塞通知域为11时， 所述步骤X3进一步包括：X31.如果该IP数据包是第一个显性拥塞 通知域为11的IP数据包时，则记录该IP数据包的接收时间，生成 并向RTP发送端发送由RTCP承载的显性拥塞通知反馈报告；以及 X32.如果该IP数据包不是第一个显性拥塞通知域为11的IP数据包 时，则判断该IP数据包是否与先前接收的显性拥塞通知域为11的 IP数据包属于相同的非基层，当不属于相同的非基层时，则记录该 IP数据包的接收时间，生成并向RTP发送端发送由RTCP承载的显 性拥塞通知反馈报告，当属于相同的非基层时，则判断接收该IP数 据包的接收时间是否小于先前接收的属于相同的非基层的显性拥塞 通知域为11的IP数据包的接收时间和RTP发送端与所述RTP接收 端之间的回程时间的和，如果不小于，则记录并更新所述接收时间， 生成并向所述RTP发送端发送由RTCP承载的显性拥塞通知反馈报 告，如果小于，则仅记录并更新所述接收时间。

由此，在收到带有显性拥塞通知域设置为11的IP数据包头的 IP数据包时，RTP接收端可以确定该IP数据包属于现有的拥塞事件 (congestion event)或还是属于新的拥塞事件，并仅在属于新的拥塞 事件时候发送显性拥塞通知反馈报告。由此可以避免不需要的显性 拥塞通知反馈报告。

优选地，所述步骤X3还包括：向所述RTP发送端发送由RTCP 承载的周期性显性拥塞通知总结报告，并且当显性拥塞通知反馈报 告及其处理时间大于发送周期性显性拥塞通知总结报告的预定时间 时，不再发送该显性拥塞通知反馈报告。

通过本发明提供的优选的技术方案，能够将ECN技术和流裁剪技 术结合地应用至基于可分级的视频业务，并能够产生可靠的显性拥 塞通知和/或周期性显性拥塞通知总结报告。由此在收到显性拥塞通 知和/或周期性显性拥塞通知总结报告之后，RTP接收端能够实现良 好的码率适配或拥塞控制效果。并且依据本发明的ECN技术还考虑 了无线网络中的时变性问题。此外，在本发明中，网络设备(例如 路由器和基站)能够根据需要为同一个基于可分级的视频业务设置 不同的拥塞事件，这对于RTP发送端实施准确的拥塞控制也是非常 有利的。

本发明的各个方面将通过下文中的具体实施例的说明而更加清晰。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述， 本发明的其它特征、目的和优点将会变得更加明显：

图1示出了IP数据包头中的ECN域的四种设置示意图；

图2示出了现有技术中实施流裁剪的方法流程图；

图3示出了根据本发明的一个实施例的用于为基于可分级的视 频业务实现显性拥塞通知的系统示意图；

图4示出了根据本发明的一个实施例的在MANE中实施流裁剪 的方法流程图；

图5示出了根据本发明的一个实施例的在网络设备中实施用于 为基于可分级的视频业务实现显性拥塞通知的方法的流程图；

图6示出了根据本发明的一个实施例的在RTP接收端中实施用 于为基于可分级的视频业务实现显性拥塞通知的方法的流程图；

图7示出了根据本发明的另一个实施例的图6中的步骤S603的 实施方法的流程图；

图8示出了一个IP数据包的示例性结构示意图；

图9示出了根据本发明的一个实施例的RTP虚拟数据包的结构 示意图；以及

图10示出了根据本发明的一个实施例的确定拥塞事件的示意 图。

在图中，贯穿不同的示图，相同或类似的附图标记表示相同或相对 应的部件或特征。

具体实施方式

图3示出了根据本发明的一个实施例的用于为基于可分级的视 频业务实现显性拥塞通知的系统示意图。图4示出了根据本发明的 一个实施例的在MANE中实施流裁剪的方法流程图。图5示出了根 据本发明的一个实施例的在网络设备中实施用于为基于可分级的视 频业务实现显性拥塞通知的方法的流程图。图6示出了根据本发明 的一个实施例的在RTP接收端中实施用于为基于可分级的视频业务 实现显性拥塞通知的方法的流程图。

以下将结合图4至图6对图3中的系统进行描述。如图3所示， 该系统包括RTP发送端、网络单元、网络设备以及RTP接收端。

RTP发送端例如可以是视频服务器。网络单元例如可以是媒体 感知网络单元MANE和基站。网络设备例如可以是基站和路由器。 RTP接收端例如可以是移动终端。在图3中以网络单元为MANE、 网络设备为基站为例对本发明进行阐述。

而在本发明的另一些实施例中，MANE的功能也可以完全在基 站侧实现。因此，在这种情况下，系统将仅包括RTP发送端、网络 设备(例如基站)和RTP接收端。

并且，虽然在图3中简要地示出了MANE与网络设备直接连接， 但是本领域的技术人员应当理解在其他情形中，MANE可以经过多 个网元与网络设备连接。同理，虽然RTP发送端和MANE直接连接， 但是本领域的技术人员应当理解在其他情形中，RTP发送端可以经 过多个网元与MANE连接。

在此，我们假定RTP发送端与网格中的各个元件已经完成初始 化过程，即已经协商确定将使用ECN技术。

在运行中，RTP发送端首先将向MANE发送基于由UDP承载 的RTP流的基于可分级的视频业务。在图8中示出了一个IP数据包 的示例性结构示意图。如图8所示，该IP数据包包括IP数据包头、 UDP数据包头和一个或多个RTP数据包。在此，在IP数据包头中 包括两比特的显性拥塞通知域(未示出)。

在本发明中，该基于可分级的视频业务的比特流包括基层和一 个或多个非基层，将通过基层和一个或多个非基层传输基于可分级 的视频业务的IP数据包。

在此，基于可分级的视频业务可以包括但不限于应用可分级视 频编码的视频业务和应用多视角视频编码的视频业务。

当基于可分级的视频业务为应用可分级视频编码的视频业务 时，基层指得是应用可分级视频编码的视频业务的比特流的基本层， 而非基层指得是应用可分级视频编码的视频业务的比特流的增强 层。

当基于可分级的视频业务为应用多视角视频编码的视频业务 时，基层指得是应用多视角视频编码的视频业务的基本视角，非基 层指得是应用多视角视频编码的视频业务的比特流的非基本视角。

现在参照图4对在MANE中实施的流裁剪的方法进行描述。而 在本发明的另一个实施例中，该方法也可以在基站侧实施。

在步骤S401中，MANE确定是否需要对一个或多个非基层上的 基于可分级的视频业务的IP数据包中的RTP数据包进行流裁剪。

如果不需要进行流裁剪，则进入步骤S407。在步骤S407中， MANE将未经流裁剪的基于可分级的视频业务的IP数据包经由网络 发送至网络设备。

如果需要对所述一个或多个非基层上的基于可分级的视频业务 的RTP数据包进行流裁剪，则进入步骤S402。在步骤S402中判断 是否需要移除一个或多个完整的RTP数据包。

当不需要移除一个或多个完整的RTP数据包时，即仅需要移除 RTP数据包中的一个或多个NAL单元时，则进入步骤S405。在步 骤405中有选择性地移除RTP数据包中的一个或多个NAL单元并更 新RTP数据包的RTP头信息。在文献IETF RFC 6190(05、2011) “用于可分级的视频编码的RTP负载格式(RTP Payload Format for Scalable Video Coding)”中对该更新过程进行了具体描述，对于详 细内容，感兴趣的读者可以参考上述文献。

当需要移除一个或多个完整的RTP数据包时，则进入步骤S406。 在步骤S406中，以虚拟RTP数据包替换这些本应该被移除的RTP 数据包。在此，图9示出了根据本发明的一个实施例的RTP虚拟数 据包的结构示意图。如图9所示，RTP虚拟数据包保留了本应该被 移除的RTP数据包的RTP头信息，并且在RTP虚拟数据包中以一 个空的NAL单元来替换本应该被移除的RTP数据包负载中的所有 NAL单元。

在此，该空的NAL单元中域可以被设置为：F＝0、NRI＝3、 Type＝31、Subtype＝1、J＝0、K＝0以及L＝0。

通过使用RTP虚拟数据包，基于可分级的视频业务的RTP数据 包的序列号将保持流裁剪前的连续状态，从而有助于RTP接收端不 会再不计数原本遭移除的RTP数据包，因此可以实现准确的显性拥 塞通知反馈报告和/或周期性显性拥塞通知总结报告。另一方面，这 仍保持了流裁剪的初衷和效果，因为原有的所有NAL单元已经被一 个空的NAL单元替换了。

然后，步骤S405和步骤S406都进入步骤S407中，在步骤S407 中，MANE将经流裁剪和/或未经流裁剪的基于可分级的视频业务的 IP数据包经由网络发送至网络设备。需要指出的是，在MANE的功 能也可以完全在基站侧实现的情况下，方法将不包括步骤S407。

接着，参考图5对在网络设备中实施的为基于可分级的视频业 务实现显性拥塞通知的方法进行描述。如图5所示，在步骤S501中， 网络设备从网络接收经MANE流裁剪和/或未经MANE流裁剪的基 于可分级的视频业务的IP数据包。需要指出的是，在MANE的功能 也可以完全在基站侧实现的情况下，方法将不包括步骤S501。即， 基站可以在实施流裁剪技术之后，直接将ECN技术应用至基于可分 级的视频业务。

在步骤S502中，网络设备可以根据预定条件确定是否需要将IP 数据包的IP数据包头中的显性拥塞通知域设置为11，即指示即将发 生的拥塞。

在此，预定条件可以包括可用资源状态、缓冲器状态、信道质 量和/或链路质量。

当确定不需要将IP数据包头中的显性拥塞通知域设置为11时， 则不需要对基于可分级的视频业务的IP数据包进行更新，方法进入 步骤S505。在步骤S505中将未更新的基于可分级的视频业务的IP 数据包发送至RTP接收端。

当确定需要将IP数据包头中的显性拥塞通知域设置为11时， 则方法进入步骤S503。

在步骤S503中，网络设备确定需要将IP数据包头中的显性拥 塞通知域设置为11的非基层的数量。在此，例如可以取决于网络设 备想告知RTP发送端即将发生的拥塞程度来确定需要将IP数据包头 中的显性拥塞通知域设置为11的非基层的数量。多个非基层意味着 多个拥塞事件，而这将引起后续的RTP接收端的相对应的多个显性 拥塞通知反馈报告。进而，对于同一个基于可分级的视频业务，将 产生多个显性拥塞通知反馈报告。由此，RTP发送端将更精确地施 行快速拥塞控制。

此外，在步骤S503中，还将根据非基层的数量以降序的顺序确 定需要将IP数据包头中的显性拥塞通知域设置为11的非基层。

具体地，对于应用可分级视频编码的视频业务，由于应用可分 级视频编码的视频业务的基层和增强层是通过{dependency_id， quality_id，temporal_id}来确定的，{dependency_id，quality_id， temporal_id}位于NAL单元的头信息中。其中，{0，0，x}表示基层，x 意味着temporal_id的任意取值，而其他组合则表示增强层。具有较 高数值的dependency_id增强层的层数较高。对于具有相同数值的 dependency_id增强层，具有较高数值的quality_id的增强层的层数 较高。而对于具有相同数值的dependency_id，quality_id，具有较高 数值的temporal_id的增强层的层数较高。因而，对于应用可分级视 频编码的视频业务，网络设备可以根据上述原则从高到低确定出需 要将IP数据包头中的显性拥塞通知域设置为11的增强层。

而对于应用多视角视频编码的视频业务，由于应用多视角视频 编码的视频业务的非基本视角是通过{view_id}来区分的，{view_id} 位于NAL单元的头信息中。其中，具有较高数值的view_id的增强 层的层数较高。因而，对于应用多视角视频编码的视频业务，网络 设备可以根据上述原则从高到低确定出需要将IP数据包头中的显性 拥塞通知域设置为11的非基本视角。

在步骤504中，对于需要将IP数据包头中的显性拥塞通知域设 置为11的每个非基层，将该非基层中的至少一个IP数据包头中的 显性拥塞通知域设置为11，并生成更新后的IP数据包。

具体地，对于应用可分级视频编码的视频业务，将需要将IP数 据包头中的显性拥塞通知域设置为11的增强层中的至少一个IP数 据包的IP数据包头中的显性拥塞通知域设置为11，并生成更新后的 IP数据包。

对于应用多视角视频编码的视频业务，将需要将IP数据包头中 的显性拥塞通知域设置为11的非基本视角中的至少一个IP数据包 的IP数据包头中的显性拥塞通知域设置为11，并生成更新后的IP 数据包。

优选地，在该步骤中，对于需要将IP数据包头中的显性拥塞通 知域设置为11的每个非基层，将该非基层中的时间上连续的两个或 三个IP数据包的IP数据包头中的显性拥塞通知域设置为11，并生 成更新后的IP数据包。由此可以避免由于例如无线信道的时变性引 起的不利影响。

随后，在步骤S505中，网络设备将经更新的基于可分级的视频 业务的IP数据包发送至RTP接收端。

接着，参考图6对在RTP接收端中实施的为基于可分级的视频 业务实现显性拥塞通知的方法进行描述。如图6所示，在步骤S601 中，RTP接收端从网络设备接收经网络设备更新和/或未经所述网络 设备更新的基于可分级的视频业务的IP数据包。

在步骤S602中，RTP接收端根据IP数据包头中的显性拥塞通 知域的取值，针对不同的取值来分类地计数IP数据包中的RTP数据 包的数量。在此，每收到一个IP数据包都要对其中的RTP包进行计 数。即对于图1中所示的IP数据包头中的显性拥塞通知域为00、01、 10和11四种情况下的RTP数据包，无论该RTP数据包是虚拟RTP 数据包还是非虚拟RTP数据包，都将进行累积计数，以便用于可能 将要发送的显性拥塞通知反馈报告和/或周期性显性拥塞通知总结报 告。具体地，将对ECT(0)、ECT(1)、ECN-CE、not-ECT这四 个参数计数RTP数据包的数量。

并且，在该步骤中，当从网络设备接收的IP数据包中的RTP数 据包为虚拟RTP数据包时，则不将该RTP数据包用于视频解码，并 且计数虚拟RTP数据包的数量。在此，将虚拟RTP数据包的数量计 数入参数Lost Packets Counter和Duplication Counter。

在步骤S603中，当所接收的IP数据包中的显性拥塞通知域为 11时，RTP接收端生成并向RTP发送端发送由RTCP承载的显性拥 塞通知反馈报告。

在此，图7示出了根据本发明的另一个实施例的图6中的步骤 S603的实施方法的流程图。如图7所示，当所接收的IP数据包中的 显性拥塞通知域为11时，在步骤S1中RTP接收端判断该IP数据是 否是第一个显性拥塞通知域为11的IP数据包。

如果是，则触发拥塞事件，方法进入步骤S3，在步骤S3中RTP 接收端记录该IP数据包的接收时间，生成并向RTP发送端发送由 RTCP承载的显性拥塞通知反馈报告。

如果不是，则方法进入步骤S2。在步骤S2中RTP接收端判断 该IP数据包是否与先前接收的显性拥塞通知域为11的IP数据包属 于相同的非基层。对于应用可分级视频编码的视频业务，可以通过 NAL单元的头中的{dependency_id，quality_id，temporal_id}来进行 判断。而对于应用多视角视频编码的视频业务，可以通过NAL单元 的头中的{view_id}来进行判断。

如果不属于相同的非基层，则触发拥塞事件，方法又进入步骤 S3。在步骤S3中RTP接收端记录该IP数据包的接收时间，生成并 向RTP发送端发送由RTCP承载的显性拥塞通知反馈报告。

如果属于相同的非基层，则方法进入步骤S4。在步骤S4中， RTP接收端判断接收该IP数据包的接收时间是否小于先前接收的属 于相同的非基层的显性拥塞通知域为11的IP数据包的接收时间和 RTP发送端与RTP接收端之间的回程时间(Round Trip Time，RTT) 的和。

如果不小于，则触发拥塞事件，方法进入步骤S5。在步骤S5 中，RTP接收端记录并更新接收时间，生成并向RTP发送端发送由 RTCP承载的显性拥塞通知反馈报告。

如果小于，则方法进入步骤S6。在步骤S6中，RTP接收端记 录并更新接收时间。

现在参照图10对上述过程在进行示例性描述。图10示出了根 据本发明的一个实施例的确定拥塞事件的示意图。如图10所示，当 RTP接收端接收到第一个显性拥塞通知域为11的IP数据包(序列 号SN＝N)时，将触发拥塞事件，即RTP接收端将生成并向RTP发 送端发送由RTCP承载的显性拥塞通知反馈报告。并且，在此还记 录该IP数据包的接收时间，作为与非基层x相关联的接收时间 T_old。

而此后，当RTP接收端接收到下一个新的显性拥塞通知域为11 的IP数据包SN＝N+1时，并且判断出这个新的显性拥塞通知域为11 的IP数据包SN＝N+1与IP数据包SN＝N属于相同的非基层x时， 将判断这个IP数据包SN＝N+1的接收时间T_new＜T_old+RTT是否 成立。在该实施例中，上述关系成立。因而仅记录T_new，并以T_new 的取值替代T_old的取值，作为新的与非基层x的相关联的接收时 间T_old。并且在此不触发拥塞事件，即不向RTP发送端发送由RTCP 承载的显性拥塞通知反馈报告。

接着，如图10所示，RTP又收到了非基层x-1的一个新的显性 拥塞通知域为11的IP数据包SN＝M，并判断出这个新的显性拥塞通 知域为11的IP数据包SN＝M与IP数据包SN＝N和SN＝N+1不属于 相同的非基层。在这种情况下，将触发拥塞事件，即RTP接收端将 生成并向RTP发送端发送由RTCP承载的显性拥塞通知反馈报告。 在此，还记录该IP数据包SN＝M的接收时间，作为与非基层x-1相 关联的接收时间T_old。

然后，当RTP接收端接收到下一个新的显性拥塞通知域为11 的IP数据包SN＝M+1时，并且判断出这个新的显性拥塞通知域为 11的IP数据包SN＝M+1与IP数据包SN＝M属于相同的非基层x 时，将判断这个IP数据包SN＝M+1的接收时间T_new＜T_old+RTT 是否成立。在该实施例中，上述关系成立。因而仅记录T_new，并 以T_new的取值替代T_old的取值，作为新的与非基层x-1的相关 联的接收时间T_old。并且在此不触发拥塞事件，不向RTP发送端 发送由RTCP承载的显性拥塞通知反馈报告。

优选地，在此，RTP接收端还向RTP发送端发送由RTCP承载 的周期性显性拥塞通知总结报告，并且当显性拥塞通知反馈报告及 其处理时间大于发送周期性显性拥塞通知总结报告的预定时间时， 不再发送该显性拥塞通知反馈报告。在此，处理时间时指RTP接收 端处理反馈报告中的各种参数的时间以及时延等。

在此，在生成显性拥塞通知和/或周期性显性拥塞通知总结报告 时，将处理ECT(0)、ECT(1)、ECN-CE、not-ECT、Lost Packets Counter、Extended Highest Sequence Number、Duplication Counter这 些参数，并在报告中包括这些参数。

最后，如图3所示，当RTP接收端接收到显性拥塞通知和/或周 期性显性拥塞通知总结报告之后，RTP发送端将通过拥塞控制算法 等进行准确的拥塞控制。

需要说明的是，上述实施例仅是示范性的，而非对本发明的限 制。任何不背离本发明精神的技术方案均应落入本发明的保护范围 之内，这包括使用在不同实施例中出现的不同技术特征，装置方法 可以进行组合，以取得有益效果。此外，不应将权利要求中的任何 附图标记视为限制所涉及的权利要求；“包括”一词不排除其他权 利要求或说明书中未列出的装置或步骤。