在快速频道切换时预先发送加入组播请求的方法和系统.pdf

《在快速频道切换时预先发送加入组播请求的方法和系统.pdf》由会员分享，可在线阅读，更多相关《在快速频道切换时预先发送加入组播请求的方法和系统.pdf（18页珍藏版）》请在专利查询网上搜索。

1、(10)申请公布号 CN 102651823 A (43)申请公布日 2012.08.29 C N 1 0 2 6 5 1 8 2 3 A *CN102651823A* (21)申请号 201110045498.X (22)申请日 2011.02.24 H04N 21/266(2011.01) H04L 12/18(2006.01) (71)申请人中兴通讯股份有限公司 地址 518057 广东省深圳市南山区高新技术 产业园科技南路中兴通讯大厦法务部 (72)发明人朱晓斌 (74)专利代理机构北京派特恩知识产权代理事 务所(普通合伙) 11270 代理人张颖玲 周义刚 (54) 发明名称 在快速。

2、频道切换时预先发送加入组播请求的 方法和系统 (57) 摘要 本发明公开了一种在快速频道切换时预先发 送加入组播请求的方法和系统，为了克服现有快 速频道切换技术中单播与组播切换机制未考虑数 据设备处理加入组播请求的处理时间开销，导致 快速频道切换服务器浪费处理能力的缺点，考虑 在频道快速切换过程中预先发送加入组播请求的 时间，从而缩短服务器发送单播码流的时间，节约 处理能力，降低部署成本。 (51)Int.Cl. 权利要求书4页 说明书9页 附图4页 (19)中华人民共和国国家知识产权局 (12)发明专利申请 权利要求书 4 页 说明书 9 页 附图 4 页 1/4页 2 1.在快速频道切换时。

3、预先发送加入组播请求的方法，其特征在于，该方法包括： 搜集数据设备处理加入组播请求的处理时间开销，计算单播与组播码流同步的时间， 计算客户端预先发出加入组播请求的时刻。 2.根据权利要求1所述的方法，其特征在于， 所述搜集方法为以下至少之一；并且在获得多个不同的数值时，采用包括取最小值或 平均值在内的统计学方法得到单一的数值，作为组播请求处理延时： 实时统计；客户端在正常工作时，计算其自身每次从发送加入组播请求到接收到组播 码流之间的时间间隔； 实验分析；使用支持组播功能的网络主机进行实验，测量其从发送加入组播请求到接 收到组播码流之间的时间间隔； 经验估算；综合包括历史数据、实验结果、设备型。

4、号、网络架构在内的因素，进行合理估 计； 所述计算单播与组播码流同步的时间的方法为： T Sync P Dif /(R Uc -R Mc ) 公式1 上式中，T Sync 为估算的单播与组播码流同步的时间，P Dif 为某一时刻服务器已发送的单 播媒体包和其已接收的组播媒体包之间相隔的数据量，R Uc 为服务器发送单播码流的平均码 率，R Mc 为组播码流的平均码率； 将公式1左边的除数和被除数同时除以R Mc ，得到如下等价公式： T Sync T Dif /( Uc -1) 公式2 上式中，T Sync 为估算的单播与组播码流同步的时间，T Dif 为某媒体包从被接收到被发送 之间的时间间。

5、隔， Uc 为单播码率相对于组播码率的比例； 所述计算客户端预先发出加入组播请求的时刻的方法为： T ReqMc T Sync -T McDly 公式3 上式中，T ReqMc 为客户端预先发出加入组播请求的相对时间，T Sync 为单播与组播码流同 步时间，T McDly 为组播请求处理延时。 3.在快速频道切换时预先发送加入组播请求的方法，其特征在于，该方法包括： 将组播请求处理延时通知到服务器，服务器计算客户端预先发送加入组播请求的时 间，服务器控制客户端预先发出加入组播请求。 4.根据权利要求3所述的方法，其特征在于， 所述通知的方法为：由客户端保存组播请求处理延时数值，通过通讯链路发。

6、送给服务 器；将组播请求处理延时作为服务器的配置参数； 所述计算客户端预先发送加入组播请求的时间的方法为： T ReqMc T Sync -T McDly 公式3 上式中，T ReqMc 为客户端预先发出加入组播请求的相对时间，T Sync 为单播与组播码流同 步时间，T McDly 为组播请求处理延时； 所述服务器控制客户端预先发出加入组播请求的方法为： 服务器将计算得到的预先加入组播组的时刻通过通讯链路通知给客户端，客户端在预 定的时刻发出加入组播请求；或者， 服务器在预先加入组播组的时刻到达时通知客户端，客户端收到通知后立即发出加入 权 利 要 求 书CN 102651823 A 2/4。

7、页 3 组播请求。 5.在快速频道切换时预先发送加入组播请求的方法，其特征在于，该方法包括： 将组播请求处理延时通知到客户端，服务器计算单播与组播码流同步的时间，客户端 预先发送加入组播请求。 6.根据权利要求5所述的方法，其特征在于， 所述将组播请求处理延时通知到客户端的过程中，客户端直接保存结果；或者，将组播 请求处理延时作为客户端的配置参数； 所述服务器计算单播与组播码流同步的时间的方法为： T Sync P Dif /(R Uc -R Mc ) 公式1 上式中，T Sync 为估算的单播与组播码流同步的时间，P Dif 为一时刻服务器已发送的单播 媒体包和其已接收的组播媒体包之间相隔的。

8、数据量，R Uc 为服务器发送单播码流的平均码 率，R Mc 为组播码流的平均码率； 将公式1左边的除数和被除数同时除以R Mc ，得到如下等价公式： T Sync T Dif /( Uc -1) 公式2 上式中，T Sync 为估算的单播与组播码流同步的时间，T Dif 为媒体包从被接收到被发送之 间的时间间隔， Uc 为单播码率相对于组播码率的比例； 所述客户端预先发送加入组播请求的方法为： 服务器将单播与组播码流同步时间的计算结果通过通讯链路发送给客户端；客户端计 算预先发出加入组播请求的时间，并在预先发出加入组播请求的时刻到达时发出加入组播 请求。 7.在快速频道切换时预先发送加入组播。

9、请求的系统，其特征在于，该系统包括搜集单 元、计算单元；其中， 所述搜集单元，用于搜集数据设备处理加入组播请求的处理时间开销； 所述计算单元，用于计算单播与组播码流同步的时间，计算客户端预先发出加入组播 请求的时刻。 8.根据权利要求7所述的系统，其特征在于， 所述搜集单元在进行所述搜集时，采用的搜集方法为以下至少之一；并且在获得多个 不同的数值时，采用包括取最小值或平均值在内的统计学方法得到单一的数值，作为组播 请求处理延时： 实时统计；在客户端正常工作时，计算客户端每次从发送加入组播请求到接收到组播 码流之间的时间间隔； 实验分析；使用支持组播功能的网络主机进行实验，测量其从发送加入组播请。

10、求到接 收到组播码流之间的时间间隔； 经验估算；综合包括历史数据、实验结果、设备型号、网络架构在内的因素，进行合理估 计； 所述计算单元在计算单播与组播码流同步的时间时，用于： T Sync P Dif /(R Uc -R Mc ) 公式1 上式中，T Sync 为估算的单播与组播码流同步的时间，P Dif 为一时刻服务器已发送的单播 媒体包和其已接收的组播媒体包之间相隔的数据量，R Uc 为服务器发送单播码流的平均码 权 利 要 求 书CN 102651823 A 3/4页 4 率，R Mc 为组播码流的平均码率； 将公式1左边的除数和被除数同时除以R Mc ，得到如下等价公式： T Syn。

11、c T Dif /( Uc -1) 公式2 上式中，T Sync 为估算的单播与组播码流同步的时间，T Dif 为媒体包从被接收到被发送之 间的时间间隔， Uc 为单播码率相对于组播码率的比例； 所述计算单元在计算客户端预先发出加入组播请求的时刻时，用于： T ReqMc T Sync -T McDly 公式3 上式中，T ReqMc 为客户端预先发出加入组播请求的相对时间，T Sync 为单播与组播码流同 步时间，T McDly 为组播请求处理延时。 9.在快速频道切换时预先发送加入组播请求的系统，其特征在于，该系统包括通知单 元、服务器、客户端；其中， 所述通知单元，用于将组播请求处理延时。

12、通知到服务器； 所述服务器，用于计算客户端预先发送加入组播请求的时间，并且控制客户端预先发 出加入组播请求。 10.根据权利要求9所述的系统，其特征在于， 所述通知单元进行所述通知时，用于：触发客户端保存组播请求处理延时数值，通过通 讯链路发送给服务器；将组播请求处理延时作为服务器的配置参数； 所述服务器计算客户端预先发送加入组播请求的时间时，用于： T ReqMc T Sync -T McDly 公式3 上式中，T ReqMc 为客户端预先发出加入组播请求的相对时间，T Sync 为单播与组播码流同 步时间，T McDly 为组播请求处理延时； 所述服务器控制客户端预先发出加入组播请求时，用。

13、于： 将计算得到的预先加入组播组的时刻通过通讯链路通知给客户端，触发客户端在预定 的时刻发出加入组播请求；或者， 在预先加入组播组的时刻到达时通知客户端，触发客户端在收到通知后立即发出加入 组播请求。 11.在快速频道切换时预先发送加入组播请求的系统，其特征在于，该系统包括通知单 元、服务器、客户端；其中， 所述通知单元，用于将组播请求处理延时通知到客户端； 所述服务器，用于计算单播与组播码流同步的时间； 所述客户端，用于预先发送加入组播请求。 12.根据权利要求11所述的系统，其特征在于， 所述通知单元将组播请求处理延时通知到客户端的过程中，客户端用于直接保存结 果；或者，将组播请求处理延时。

14、作为客户端的配置参数； 所述服务器计算单播与组播码流同步的时间时，用于： T Sync P Dif /(R Uc -R Mc )公式1 上式中，T Sync 为估算的单播与组播码流同步的时间，P Dif 为一时刻服务器已发送的单播 媒体包和其已接收的组播媒体包之间相隔的数据量，R Uc 为服务器发送单播码流的平均码 率，R Mc 为组播码流的平均码率； 权 利 要 求 书CN 102651823 A 4/4页 5 将公式1左边的除数和被除数同时除以R Mc ，得到如下等价公式： T Sync T Dif /( Uc -1) 公式2 上式中，T Sync 为估算的单播与组播码流同步的时间，T D。

15、if 为媒体包从被接收到被发送之 间的时间间隔， Uc 为单播码率相对于组播码率的比例； 所述客户端预先发送加入组播请求时，用于： 在服务器将单播与组播码流同步时间的计算结果通过通讯链路发送给客户端后，计算 预先发出加入组播请求的时间，并在预先发出加入组播请求的时刻到达时发出加入组播请 求。 权 利 要 求 书CN 102651823 A 1/9页 6 在快速频道切换时预先发送加入组播请求的方法和系统 技术领域 0001 本发明涉及通信领域，具体涉及一种在快速频道切换时预先发送加入组播请求的 方法和系统。 背景技术 0002 数字视频编码技术普遍采用帧间编码来提高压缩率，这就导致解码端必须接收。

16、到 I帧(Intra Frame，帧内编码帧)才能开始正确显示视频画面。在IPTV中倾向于采用组播 技术传输直播码流，所有终端都共同接收同样的一路码流。当终端进行频道切换时，其开始 接收直播码流的时刻是随机的，通常需要等待一段时间才能接收到I帧并显示视频画面， 这严重影响了IPTV的频道切换速度。 0003 已经有多种快速频道切换(Fast Channel Change，FCC)方案用于提升IPTV的频 道切换速度，目前的主流方案是采用快速频道切换服务器(Fast ChannelChange Server， FCC Server或FCC服务器)对频道码流进行缓存，在频道切换时采用单播方式向终端。

17、快速 发送以I帧开头的码流，终端接收后迅速解码显示视频画面，随后FCC Server停止发送单 播码流，终端开始使用组播码流进行解码。 0004 在上述方案中，FCC Server停止发送单播码流和终端开始使用组播码流解码的切 换(后续简称为“单播与组播切换”)时机非常关键，过早切换可能接收不到足够的单播数 据，无法与组播数据衔接，导致终端播放的视频画面受损影响用户体验；而过晚切换虽然不 必担心单播与组播数据的衔接，但FCC Server要发送较长时间的单播码流，无形中浪费了 FCC Server的处理能力，增加了部署成本。 0005 本文随后部分将支持快速频道切换的终端称为快速频道切换客户端。

18、 (FastChannel Change Client，FCC Client或FCC客户端)，在不致引起混淆的情况下直接 简称为“客户端”，与此对应，快速频道切换服务器可被简称为“服务器”。 0006 目前，可以由服务器以较高速度发送单播码流，在单播码流与组播码流同步(即 实现衔接)时通知客户端请求加入组播组，客户端在接收到组播码流之后通知服务器停止 发送单播码流。在实际的IPTV承载网中，数据设备处理加入组播组的请求需要消耗一定的 时间，这就意味着客户端从发送加入组播请求到接收到组播码流之间存在延时间隔，这个 时间短则300ms，长则700ms甚至更长，而上述切换机制并未考虑这个时间开销，则。

19、在单播 与组播码流同步之后服务器还要继续发送数百毫秒的单播码流直到客户端真正收到组播 码流，这显然浪费了服务能力。 0007 在IETF(Internet Engineering Task Force互联网工程任务组)草案draft-iet f-avt-rapid-acquisition-for-rtp-17中，服务器可以计算出客户端请求加入组播组的最 早时间并传递给客户端，客户端可以参考这个数据自行确定请求加入组播组的时间，至于 如何得到“请求加入组播组的最早时间”的数据以及客户端如何使用这个数据，该文档并未 给出实质性的说明。 说 明 书CN 102651823 A 2/9页 7 发明内容。

20、 0008 有鉴于此，本发明的主要目的在于提供一种在快速频道切换时预先发送加入组播 请求的方法和系统，以缩短服务器发送单播码流的时间，节约处理能力。 0009 为达到上述目的，本发明的技术方案是这样实现的： 0010 在快速频道切换时预先发送加入组播请求的方法，该方法包括： 0011 搜集数据设备处理加入组播请求的处理时间开销，计算单播与组播码流同步的时 间，计算客户端预先发出加入组播请求的时刻。 0012 所述搜集方法为以下至少之一；并且在获得多个不同的数值时，采用包括取最小 值或平均值在内的统计学方法得到单一的数值，作为组播请求处理延时： 0013 实时统计；客户端在正常工作时，计算其自身。

21、每次从发送加入组播请求到接收到 组播码流之间的时间间隔； 0014 实验分析；使用支持组播功能的网络主机进行实验，测量其从发送加入组播请求 到接收到组播码流之间的时间间隔； 0015 经验估算；综合包括历史数据、实验结果、设备型号、网络架构在内的因素，进行合 理估计； 0016 所述计算单播与组播码流同步的时间的方法为： 0017 T Sync P Dif /(R Uc -R Mc ) 公式1 0018 上式中，T Sync 为估算的单播与组播码流同步的时间，P Dif 为某一时刻服务器已发送 的单播媒体包和其已接收的组播媒体包之间相隔的数据量，R Uc 为服务器发送单播码流的平 均码率，R 。

22、Mc 为组播码流的平均码率； 0019 将公式1左边的除数和被除数同时除以R Mc ，得到如下等价公式： 0020 T Sync T Dif /( Uc -1) 公式2 0021 上式中，T Sync 为估算的单播与组播码流同步的时间，T Dif 为某媒体包从被接收到被 发送之间的时间间隔， Uc 为单播码率相对于组播码率的比例； 0022 所述计算客户端预先发出加入组播请求的时刻的方法为： 0023 T ReqMc T Sync -T McDly 公式3 0024 上式中，T ReqMc 为客户端预先发出加入组播请求的相对时间，T Sync 为单播与组播码 流同步时间，T McDly 为组播。

23、请求处理延时。 0025 在快速频道切换时预先发送加入组播请求的方法，该方法包括： 0026 将组播请求处理延时通知到服务器，服务器计算客户端预先发送加入组播请求的 时间，服务器控制客户端预先发出加入组播请求。 0027 所述通知的方法为：由客户端保存组播请求处理延时数值，通过通讯链路发送给 服务器；将组播请求处理延时作为服务器的配置参数； 0028 所述计算客户端预先发送加入组播请求的时间的方法为： 0029 T ReqMc T Sync -T McDly 公式3 0030 上式中，T ReqMc 为客户端预先发出加入组播请求的相对时间，T Sync 为单播与组播码 流同步时间，T McDl。

24、y 为组播请求处理延时； 0031 所述服务器控制客户端预先发出加入组播请求的方法为： 0032 服务器将计算得到的预先加入组播组的时刻通过通讯链路通知给客户端，客户端 说 明 书CN 102651823 A 3/9页 8 在预定的时刻发出加入组播请求；或者， 0033 服务器在预先加入组播组的时刻到达时通知客户端，客户端收到通知后立即发出 加入组播请求。 0034 在快速频道切换时预先发送加入组播请求的方法，该方法包括： 0035 将组播请求处理延时通知到客户端，服务器计算单播与组播码流同步的时间，客 户端预先发送加入组播请求。 0036 所述将组播请求处理延时通知到客户端的过程中，客户端直。

25、接保存结果；或者，将 组播请求处理延时作为客户端的配置参数； 0037 所述服务器计算单播与组播码流同步的时间的方法为： 0038 T Sync P Dif /(R Uc -R Mc ) 公式1 0039 上式中，T Sync 为估算的单播与组播码流同步的时间，P Dif 为一时刻服务器已发送的 单播媒体包和其已接收的组播媒体包之间相隔的数据量，R Uc 为服务器发送单播码流的平均 码率，R Mc 为组播码流的平均码率； 0040 将公式1左边的除数和被除数同时除以R Mc ，得到如下等价公式： 0041 T Sync T Dif /( Uc -1) 公式2 0042 上式中，T Sync 为。

26、估算的单播与组播码流同步的时间，T Dif 为媒体包从被接收到被发 送之间的时间间隔， Uc 为单播码率相对于组播码率的比例； 0043 所述客户端预先发送加入组播请求的方法为： 0044 服务器将单播与组播码流同步时间的计算结果通过通讯链路发送给客户端；客户 端计算预先发出加入组播请求的时间，并在预先发出加入组播请求的时刻到达时发出加入 组播请求。 0045 在快速频道切换时预先发送加入组播请求的系统，该系统包括搜集单元、计算单 元；其中， 0046 所述搜集单元，用于搜集数据设备处理加入组播请求的处理时间开销； 0047 所述计算单元，用于计算单播与组播码流同步的时间，计算客户端预先发出加。

27、入 组播请求的时刻。 0048 所述搜集单元在进行所述搜集时，采用的搜集方法为以下至少之一；并且在获得 多个不同的数值时，采用包括取最小值或平均值在内的统计学方法得到单一的数值，作为 组播请求处理延时： 0049 实时统计；在客户端正常工作时，计算客户端每次从发送加入组播请求到接收到 组播码流之间的时间间隔； 0050 实验分析；使用支持组播功能的网络主机进行实验，测量其从发送加入组播请求 到接收到组播码流之间的时间间隔； 0051 经验估算；综合包括历史数据、实验结果、设备型号、网络架构在内的因素，进行合 理估计； 0052 所述计算单元在计算单播与组播码流同步的时间时，用于： 0053 T。

28、 Sync P Dif /(R Uc -R Mc ) 公式1 0054 上式中，T Sync 为估算的单播与组播码流同步的时间，P Dif 为一时刻服务器已发送的 单播媒体包和其已接收的组播媒体包之间相隔的数据量，R Uc 为服务器发送单播码流的平均 说 明 书CN 102651823 A 4/9页 9 码率，R Mc 为组播码流的平均码率； 0055 将公式1左边的除数和被除数同时除以R Mc ，得到如下等价公式： 0056 T Sync T Dif /( Uc -1) 公式2 0057 上式中，T Sync 为估算的单播与组播码流同步的时间，T Dif 为媒体包从被接收到被发 送之间的时间。

29、间隔， Uc 为单播码率相对于组播码率的比例； 0058 所述计算单元在计算客户端预先发出加入组播请求的时刻时，用于： 0059 T ReqMc T Sync -T McDly 公式3 0060 上式中，T ReqMc 为客户端预先发出加入组播请求的相对时间，T Sync 为单播与组播码 流同步时间，T McDly 为组播请求处理延时。 0061 在快速频道切换时预先发送加入组播请求的系统，该系统包括通知单元、服务器、 客户端；其中， 0062 所述通知单元，用于将组播请求处理延时通知到服务器； 0063 所述服务器，用于计算客户端预先发送加入组播请求的时间，并且控制客户端预 先发出加入组播请。

30、求。 0064 所述通知单元进行所述通知时，用于：触发客户端保存组播请求处理延时数值，通 过通讯链路发送给服务器；将组播请求处理延时作为服务器的配置参数； 0065 所述服务器计算客户端预先发送加入组播请求的时间时，用于： 0066 T ReqMc T Sync -T McDly 公式3 0067 上式中，T ReqMc 为客户端预先发出加入组播请求的相对时间，T Sync 为单播与组播码 流同步时间，T McDly 为组播请求处理延时； 0068 所述服务器控制客户端预先发出加入组播请求时，用于： 0069 将计算得到的预先加入组播组的时刻通过通讯链路通知给客户端，触发客户端在 预定的时刻发。

31、出加入组播请求；或者， 0070 在预先加入组播组的时刻到达时通知客户端，触发客户端在收到通知后立即发出 加入组播请求。 0071 在快速频道切换时预先发送加入组播请求的系统，该系统包括通知单元、服务器、 客户端；其中， 0072 所述通知单元，用于将组播请求处理延时通知到客户端； 0073 所述服务器，用于计算单播与组播码流同步的时间； 0074 所述客户端，用于预先发送加入组播请求。 0075 所述通知单元将组播请求处理延时通知到客户端的过程中，客户端用于直接保存 结果；或者，将组播请求处理延时作为客户端的配置参数； 0076 所述服务器计算单播与组播码流同步的时间时，用于： 0077 T。

32、 Sync P Dif /(R Uc -R Mc ) 公式1 0078 上式中，T Sync 为估算的单播与组播码流同步的时间，P Dif 为一时刻服务器已发送的 单播媒体包和其已接收的组播媒体包之间相隔的数据量，R Uc 为服务器发送单播码流的平均 码率，R Mc 为组播码流的平均码率； 0079 将公式1左边的除数和被除数同时除以R Mc ，得到如下等价公式： 0080 T Sync T Dif /( Uc -1) 公式2 说 明 书CN 102651823 A 5/9页 10 0081 上式中，T Sync 为估算的单播与组播码流同步的时间，T Dif 为媒体包从被接收到被发 送之间的时。

33、间间隔， Uc 为单播码率相对于组播码率的比例； 0082 所述客户端预先发送加入组播请求时，用于： 0083 在服务器将单播与组播码流同步时间的计算结果通过通讯链路发送给客户端后， 计算预先发出加入组播请求的时间，并在预先发出加入组播请求的时刻到达时发出加入组 播请求。 0084 可见，本发明方法和系统，克服了现有快速频道切换技术中单播与组播切换机制 未考虑数据设备处理加入组播请求的处理时间开销，导致快速频道切换服务器浪费处理能 力的缺点，考虑在频道快速切换过程中预先发送加入组播请求的时间，从而缩短服务器发 送单播码流的时间，节约处理能力，降低部署成本。 附图说明 0085 图1为本发明预先。

34、发送加入组播请求的时间的计算方法示意图； 0086 图2为本发明计算在频道快速切换过程中预先发送加入组播请求的时间的流程 简图； 0087 图3为本发明一实施例的在快速频道切换过程中预先发送加入组播请求的流程 简图； 0088 图4为本发明另一实施例的在快速频道切换过程中预先发送加入组播请求的流 程简图； 0089 图5为本发明提供的两个实施例的部署模型示意图； 0090 图6为本发明实施例一快速频道切换过程的流程图； 0091 图7为本发明实施例二快速频道切换过程的流程图。 具体实施方式 0092 为了克服现有快速频道切换技术中单播与组播切换机制未考虑数据设备处理加 入组播请求的处理时间开销。

35、，导致快速频道切换服务器浪费处理能力的缺点，可以考虑在 频道快速切换过程中预先发送加入组播请求的时间，从而缩短服务器发送单播码流的时 间，节约处理能力，降低部署成本。 0093 本发明所述计算在频道快速切换过程中预先发送加入组播请求的时间的方法如 下： 0094 第一步、搜集数据设备处理加入组播请求的处理时间开销(以后简称为“组播请 求处理延时”)，存在多种搜集方式，包括但不限于： 0095 实时统计；客户端在正常工作时，计算其自身每次从发送加入组播请求到接收到 组播码流之间的时间间隔； 0096 实验分析；使用支持组播功能的网络主机进行实验，测量其从发送加入组播请求 到接收到组播码流之间的时。

36、间间隔； 0097 经验估算；综合历史数据、实验结果、设备型号、网络架构等各种因素，进行合理的 估计。 0098 上述方式可单独使用也可组合使用，如果获得多个不同的数值，则采用取最小值 说 明 书CN 102651823 A 10 6/9页 11 或平均值等统计学方法得到一个单一的数值，作为组播请求处理延时。 0099 第二步、计算单播与组播码流同步的时间； 0100 服务器持续接收组播码流并进行缓存，当客户端向服务器请求快速频道切换服务 时，服务器将从缓冲区中取出以I帧开头的媒体包采用单播方式发送给客户端。 0101 采用如下公式计算出单播与组播码流同步的时间： 0102 T Sync P 。

37、Dif /(R Uc -R Mc ) 公式1 0103 上式中，T Sync 为估算的单播与组播码流同步的时间，P Dif 为某个时刻服务器已发送 的单播媒体包和其已接收的组播媒体包之间相隔的数据量，R Uc 为服务器发送单播码流的平 均码率，R Mc 为组播码流的平均码率。 0104 将公式1左边的除数和被除数同时除以RMc，可得到如下等价公式： 0105 T Sync T Dif /( Uc -1) 公式2 0106 上式中，T Sync 为估算的单播与组播码流同步的时间，T Dif 为某个媒体包从被接收到 被发送之间的时间间隔， Uc 为单播码率相对于组播码率的比例，即： 0107 Uc。

38、 R Uc /R Mc 0108 本步骤得到的结果是一个相对时间：对于公式1，其计时起点是进行计算的时刻； 对于公式2，其计时起点是被选择用于计算的媒体包被发送的时刻。 0109 第三步、计算客户端预先发出加入组播请求的时刻； 0110 采用下式进行计算： 0111 T ReqMc T Sync -T McDly 公式3 0112 上式中，T ReqMc 为客户端预先发出加入组播请求的相对时间，T Sync 为单播与组播码 流同步时间，T McDly 为组播请求处理延时。 0113 可由服务器、客户端或其它设备完成上述步骤二和步骤三的计算，只要将计算所 需参数传递给相应的设备即可。公式1、公式。

39、2和公式3还可表示为绝对时间形式，并可能 还有其它的等价形式。 0114 本发明所述在快速频道切换过程中预先发送加入组播请求的第一种方法如下： 0115 第一步、将组播请求处理延时通知到服务器，有多种方式可供选择，包括但不限 于： 0116 由客户端保存组播请求处理延时数值，通过通讯链路发送给服务器； 0117 将组播请求处理延时作为服务器的一个配置参数。 0118 第二步、服务器计算客户端预先发送加入组播请求的时间，具体方法已在本文前 面相应部分给出。 0119 第三步、服务器控制客户端预先发出加入组播请求，有几种不同的方式，包括但不 限于： 0120 服务器将计算得到的预先加入组播组的时刻。

40、通过通讯链路通知给客户端，客户端 在预定的时刻发出加入组播请求；或者， 0121 服务器在预先加入组播组的时刻到达时通知客户端，客户端收到通知后立即发出 加入组播请求。 0122 本发明所述在快速频道切换过程中预先发送加入组播请求的第二种方法如下： 0123 第一步、将组播请求处理延时通知到客户端，有多种方式可供选择，包括但不限 说 明 书CN 102651823 A 11 7/9页 12 于： 0124 客户端直接保存结果，这适合于采用实时统计方式获取组播请求处理延时的情 况； 0125 将组播请求处理延时作为客户端的一个配置参数，这适合于采用实验分析或经验 估算方式获取组播请求处理延时的情。

41、况。 0126 第二步、服务器计算单播与组播码流同步的时间，具体过程参见本文前面给出的 计算客户端预先发送加入组播请求的时间的方法的第二步。 0127 第三步、客户端预先发送加入组播请求，这一步可分为三个子步骤： 0128 服务器将单播与组播码流同步时间的计算结果通过通讯链路发送给客户端； 0129 客户端计算预先发出加入组播请求的时间，具体过程参见本文前面给出的计算客 户端预先发送加入组播请求的时间的方法的第三步； 0130 客户端在预先发出加入组播请求的时刻到达时，发出加入组播请求。 0131 下面结合附图对技术方案的实施作进一步的详细描述： 0132 图1为本发明所述预先发送加入组播请求。

42、的时间的计算方法示意图： 0133 其中，横轴t表示时间，纵轴p表示媒体包的发送进度。 0134 直线101为组播码流的媒体包发送进度，相当于服务器对组播媒体包的接收缓存 进度，其斜率对应公式1中的组播码流平均码率R Mc 。 0135 直线102为服务器发出的单播码流的媒体包发送进度，其斜率对应公式1中的单 播码流平均码率R Uc 。 0136 在T 1 时刻，101和102对应的纵坐标差值就是该时刻服务器已发送的单播媒体包 和其已接收的组播媒体包之间相隔的数据量，即图1中的P Dif 。 0137 101和102在T 3 时刻相交，意味着单播与组播码流在T 3 时刻实现同步，而T 3 和T。

43、 1 的差值就对应于公式1中的T Sync ，对于101和102两条斜率已知的直线来说，可通过T 1 时刻 两者的纵坐标差值计算出T Sync ，即公式1。 0138 现在换个角度，假设服务器在T 1 时刻发送出某个单播媒体包，其发包进度对应于 直线102在T 1 时刻的纵坐标，而直线101上与其纵坐标相同的点的横坐标T 0 就是该媒体包 在组播码流中被发送的时刻，也就是服务器接收该媒体包的时刻，显然，T 0 和T 1 的差值就是 公式2中的媒体包从被接收到被发送之间的时间间隔T Dif 。 0139 分别位于101和102两条直线上且纵坐标相同的两个点的横坐标差值已知(即 T Dif )，而。

44、直线101和直线102的斜率又已知，则通过数学运算可计算出两条直线交点的横坐 标与T 1 的时间间隔T Sync ，即公式2。 0140 假设组播请求处理延时为T McDly ，为了保证客户端在单播与组播码流同步时刚好接 收到组播码流，则需要相对于T Sync 提前一段时间(在图1中的T 2 时刻)发出加入组播请求， 而这个提前的时间长度就是T McDly 。 0141 在图1中，通过公式1或公式2可计算出T 1 到T 3 之间的时间间隔T Sync ，又已知T 2 和T 1 之间的时间间隔T McDly ，则可通过公式3计算出T 1 到T 3 之间的时间间隔T ReqMc 。 0142 单播。

45、与组播码流同步时间通常以秒计，组播请求处理延时则为数百毫秒，而媒体 包的传输时间基本都在10毫秒的数量级，和前两者比较起来可以忽略不计，故本发明提出 的计算方法忽略了媒体包在网络上的传输时间。 说 明 书CN 102651823 A 12 8/9页 13 0143 前述的在频道快速切换过程中预先发送加入组播请求的时间的操作思路，可以表 示如图2所示的流程，该流程包括以下步骤： 0144 步骤210：搜集数据设备处理加入组播请求的处理时间开销，该操作可以通过设 置搜集单元实现。 0145 步骤220：计算单播与组播码流同步的时间。 0146 步骤230：计算客户端预先发出加入组播请求的时刻。 0。

46、147 步骤220和步骤230中的操作可以通过设置计算单元实现。 0148 前述的在快速频道切换过程中预先发送加入组播请求的操作思路，可以表示如图 3或图4等所示的流程. 0149 其中，图3所示流程包括以下步骤： 0150 步骤310：将组播请求处理延时通知到服务器。 0151 步骤320：服务器计算客户端预先发送加入组播请求的时间。 0152 步骤330：服务器控制客户端预先发出加入组播请求。 0153 图4所示流程则包括以下步骤： 0154 步骤410：将组播请求处理延时通知到客户端。 0155 步骤420：服务器计算单播与组播码流同步的时间。 0156 步骤430：客户端预先发送加入组。

47、播请求。 0157 图3和图4中的所述通知操作可以通知设置通知单元实现。 0158 参见图5，图5为本发明提供的两个实施例的部署模型，其中所涉及到的实体主 要有数据设备501、服务器502和客户端503，采用互联网组管理协议(Internet Group Managemet Protocol，IGMP)来支持组播。 0159 服务器502可通过信道509向数据设备501发出IGMP报文以加入频道所在的组 播组，而数据设备501则通过信道504向服务器502发送组播码流。 0160 客户端503可通过信道505向数据设备501发出IGMP报文以加入频道所在的组 播组，数据设备501则通过信道50。

48、6向客户端503发送组播码流。 0161 服务器502和客户端503之间通过RTCP建立双向通讯信道507用于与快速频道 切换相关的消息通讯，服务器502通过信道508向客户端503发送缓存的单播码流。 0162 信道504和信道506支持组播，其上码流均采用RTP封装，服务器502缓存后通过 信道508发给客户端503的单播码流依然保持RTP封装，且不修改RTP序号字段。一旦客 户端接收到的单播码流的RTP序号能和组播码流的RTP序号无缝衔接，则认为实现了单播 与组播码流同步。 0163 服务器502启动后即通过信道509向数据设备501发出IGMP报文，加入直播频道 所在的组播组，并通过信道504持续接收媒体包进行缓存。 0164 客户端503持续统计每次从发送加入组播请求到接收到组播码流之间的时间间 隔，将其最小值或平均值作为组播请求处理延时。 0165 参见图6，图6为实施例一快速频道切换过程的流程图，图中以虚线分隔的左右两 侧分别为服务器和客户端的处理流程，纵向的实线箭头表示服务器或客户端各自的处理步。