单播多播IPTV网络中实现快速信道更改的方法和服务器

摘要

本发明的实施例有关的目的是实现用于快速信道更改的改进带宽利用的解决方案，其中，通过在多播流能够提供所需媒体之前启动单播流，实现了快速信道更改。带宽利用通过延迟多播会话以及通过最迟在多播会话开始时终止单播会话而得以实现。多播会话的延迟取决于网络等待时间。在此上下文中，等待时间指客户端发送IGMP加入(IGMPJOIN)消息开始，直至它收到多播流的第一个分组经过的时间。

说明书

技术领域

本发明的实施例涉及因特网协议TV (IPTV)网络，并且具体地说，涉及IPTV网络中的快速信道更改。

背景技术

因特网协议TV (IPTV)是在通过一般为宽带接入网络的IP网络输送广播的TV服务时使用的术语。当前主导的IPTV服务是宽带TV，其中，普通非IPTV信道及低渗透的另外信道通过宽带网络从超级头端向下传送到最终用户的机顶盒(STB)。为最小化这些传送所要求的带宽，最好是通过网络使用多播技术。用户切换信道时，STB随后发送出因特网组管理协议(IGMP)消息以离开当前多播信道并且加入新的多播信道。在IGMP第3版中，这在同一消息中进行，而在IGMP的以前版本中，在两个单独的消息发送离开和加入。

STB加入的多播群组包含带有MPEG帧的流。MPEG中有不同的帧，包含完全图像的所谓I帧、包括增量外推信息的P帧和包含内插信息的B帧。由于B和P帧取决于相邻帧，因此，在能够将新信道的帧解码之前，STB必需接收完全I帧。这意味着用于在信道之间切换的平均时间将取决于在I帧之间的时间距离。一般情况下，对于mpeg-2，距离大约在0.5秒，并且对于mpeg-4第10部分，它能够长达几秒。

信道切换延迟的其它源与STB和网络设备中的缓冲、执行IGMP离开/加入和其它处理所用的时间有关。

为减轻与信道切换延迟有关的问题，今天存在各种解决方案。一种解决方案是开始用于新信道的单播会话以尽快获得新信道的帧，并随后在同步可能时执行到原多播会话的切换。此解决方案暗示有重叠的单播和多播流，这是因为在能够执行到原多播流的切换之前，同时传送单播流和原多播流。

由于重叠的流要求额外的带宽，因此，重叠的单播和多播流是依据多播流的基于单播的快速获取技术的典型快速信道更改解决方案具有的一个重要限制。甚至单播和多播会话的小重叠可严重影响最终用户体验，或者大幅限制网络容量利用的效率。

发明内容

人们希望解决与重叠流有关的问题以节省带宽。

因此，本发明的实施例有关的目的是实现用于快速信道更改(FCC)的改进带宽利用的解决方案，其中，通过在FCC多播流能够提供所需媒体之前启动单播流，实现了快速信道更改。FCC多播流在此上下文中指多播流的延迟版本。原多播流指直播和非延迟多播流。

带宽利用通过相对于原多播流延迟FCC多播流，并且通过最迟在FCC多播流开始时终止单播流而得以实现。FCC多播流的延迟取决于网络等待时间。在此上下文中，等待时间指客户端发送IGMP加入(IGMP JOIN)消息开始，直至它收到FCC多播流的第一个分组经过的时间。

根据本发明的实施例的第一方面，提供了一种在服务器中用于在IPTV网络中实现FCC的方法。通过在将FCC多播流加入某个信道之前提供所述信道的单播流，促进了到所述信道的快速信道更改，并且其中，网络等待时间的信息已知。在方法中，确定取决于至少一个网络等待时间的FCC多播流的延迟。通过确定的延迟，相对于原多播流延迟FCC多播流，并且控制单播流最迟在延迟的多播流开始时终止。

根据本发明的实施例的第二方面，提供了一种用于在IPTV网络中实现快速信道更改的服务器。服务器配置成通过在将FCC多播流加入某个信道之前提供所述信道的单播流，促进到所述信道的快速信道更改，并且最大网络等待时间和最小网络等待时间已知。服务器包括处理器，处理器配置成确定取决于最大和最小网络等待时间的FCC多播流的延迟，相对于所述信道的原多播流延迟FCC多播流。此外，服务器配置成控制单播流最迟在延迟的多播流开始时终止。

重叠的单播和多播流是依据多播流的基于单播的快速获取技术的典型快速信道更改解决方案具有的一个重要限制。实施例提供了用于为快速信道更改优化带宽利用，并且具体而言避免单播和多播流的重叠的解决方案。优点是大幅降低了与FCC有关的带宽要求。

附图说明

图1示出其中可实现本发明的实施例的IPTV网络。

图2示出根据现有技术的I、B和P帧的流。

图3示出在本发明的实施例的上下文内在FCC中涉及的不同媒体流之间的关系。

图4是根据本发明的实施例的方法的流程图。

图5示出根据本发明的实施例如何确定FCC多播流的延迟。

图6以示意图方式示出根据本发明的一实施例的FCC服务器。

具体实施方式

在本发明实施例中，假设提供了快速信道更改(FCC)解决方案，其中，通过在多播流能够提供新信道到客户端之前启动新信道的单播流，启动新信道。客户端也可称为机顶盒(STB)。

通过利用本发明的实施例，可能优化快速信道更改(FCC)带宽利用并且避免在FCC操作期间单播和多播流的重叠。

能够假设IGMP网络等待时间已知。此等待时间信息的使用使得在信道更改操作期间重叠单播和多播流的可能性大幅降低。通常，通过监视在选择的连接和路由选择点的业务来测量确定给定网络中IGMP等待时间。商用IP网络的大多数运营商通过使用专业网络监视产品定期执行此类监视。

此外，FCC服务器已知IGMP加入(IGMP JOIN)消息的最大(max)和最小(min)等待时间。在此上下文中，等待时间指客户端发送IGMP加入(IGMP JOIN)消息开始，直至它收到多播流的第一个分组经过的时间。减轻单播和多播的重叠时的一个复杂因素是IGMP等待时间的变化。未将该变化考虑在内的一种解决方案不得不补充重新传送的经常和随意使用和/或面临重叠单播和多播流的严重风险。通过FCC服务器在计算单播流的大小和延迟多播流时至少假设整个网络的最大和最小IGMP等待时间中的差别，根据实施例解决了此方面。

图1示出其中能够实现实施例的带有快速信道更改能力的IPTV系统。

接入节点(AN) 101是朝向订户的运营商网络中的最后节点，在数字订户线路(DSL)情况下，AN是数字订户线路复用器(DSLAM)。头端服务器是从中发送多播视频流的主要位置。FCC服务器（未示出）通常放置在靠近头端服务器103的位置，但它能够定位在网络的许多层中以便节省网络带宽。如果FCC服务器靠近AN 101，则要求使用更多服务器，如果服务器更靠近头端，则利用更多网络带宽。在何处放置FCC服务器因此是在带宽成本与服务器成本之间的折衷。

终止IPTV多播流的装置称为机顶盒(STB) 102。FCC解决方案的家庭部分能够在STB 102中或者在住宅网关(RGW) 104中实现。

在图1所示交换器和路由器105是支持多播（包括IGMP）的标准设备。

通过测量IGMP等待时间的最大和最小值，能够计算最佳切换点以避免单播和多播数据的重叠。

根据实施例，多播信道的延迟必须大于最大网络IGMP等待时间减去最小网络IGMP等待时间。

相反，单播流的最后分组必须比第一多播分组早IGMP等待时间差（最大IGMP等待时间减去最小IGMP等待时间）传送。这些原则确保客户端接收足够的数据以执行与多播流的成功同步而无重叠流的风险。

如果用于给定信道更改请求的IGMP等待时间低于最大等待时间，则客户端应丢弃冗余流分组。另外，FCC单播流可比实时更快发送以便填充缓冲器，例如，120%。在接收单播流（突发）一会之后，STB将切换到FCC多播流。

MPEG中有不同的帧，包含完全图像的所谓I帧、包括增量外推信息的P帧和包含内插信息的B帧。S帧是已转换成I帧的P帧。由于B和P帧取决于相邻帧，因此，在能够示出新信道之前，STB必需接收完全I帧。就MPEG-4第10部分而言，I帧或内部帧通常称为IDR帧，但原则是相同的。

图2示出帧的典型序列。这不必是它们传送的顺序，而是它们显示的顺序。

不同帧的大小示出I帧比P帧大，P帧又比B帧大的事实。图中的相对大小是用于说明；实际上，大小的不同甚至更大。I帧加上两个I帧之间的帧称为图像组(GOP)。上述示例中的GOP是19，但它能够更大得多。在无FCC解决方案的情况下，大的GOP导致更长的平均信道切换时间。

FCC多播流能够以I帧或S帧开始。只使用I帧有关的优点是不必执行成本高的转码。缺点是单播流要在更长时间处于活动状态。

图3示出如何构建不同的媒体流，以及它们在时间上如何相互有关。FCC多播流和单播流从原TV多播信道构建。应注意的是，原TV多播信道不由客户端接收。FCC多播流是原多播信道的时间延迟版本。在图3的示例中，也相对于原多播流延迟单播流。这不是必需的，但只是可能的情况，这是因为与原多播相比，缓冲和重新传送原数据通常增加了单播流的小延迟。此情况造成的单播流的任何延迟必须由FCC服务器在计算单播流的长度或延迟原多播时考虑在内。

在IP网络中，流内容通常被封装为传送控制协议(TCP)或用户数据报协议(UDP)/实时协议(RTP)分组。基于诸如校验和或分组序号等不同分组属性，能够独特地识别每个此类分组。在图3中的示例提供了对应于RTP封装流的简化的视图，流中根据序号识别每个分组。分组序号包括在内以指示单播流和FCC多播流相对于时间和原流的延迟。

单播流的压缩表象指示它能够比FCC多播和原流更快地发送。这样，STB能够在它开始显示视频/音频的同时填充缓冲器。

根据本发明的实施例和如图3所示，必须在时间上延迟FCC多播流，使得在收到延迟的多播的第一帧之前尽早收到单播流的最后帧。在上述示例中，客户端将接收一定量的冗余数据。这通过根据本发明的实施例描述FCC的以下示例进一步例示。

1.   信道更改事件在STB中发生，例如，由于用户从电子节目指南(EPG)变换或选择新信道。

2.   STB查明要加入哪个多播信道。此多播信道对应于原多播信道的延迟版本，下文如图3所示称为FCC多播。

3.   STB请求来自FCC服务器的FCC多播信道的单播流。

4.   STB开始从单播流填充其缓冲器。结合此事件，STB也接收单独的消息，消息指示单播流何时将结束以及STB何时应开始加入FCC多播信道。

5.   第一I帧收到时，STB将所述FCC多播信道解码并且开始显示视频/音频。

6.   STB使用在步骤4收到的信息启动FCC多播信道的加入。

7.   服务器基于计算的单播流长度及时终止单播流，以避免与FCC多播信道的重叠。

8.   STB停止接收单播流。

9.   STB接收FCC多播流，并且同步所述FCC多播信道的帧和所述单播流的帧。

因此，如图4的流程图中所示，为避免单播流和FCC多播流的重叠，确定401取决于至少一个网络等待时间的FCC多播流的延迟。注意，可以不按每信道更改确定延迟。然而，可能按信道更改确定延迟，或者确定在网络等待时间未发生大的更改时可用于在某个时间期内发生的多个信道更改的延迟。通过确定的延迟，相对于所述信道的原多播流延迟402 FCC多播流。此外，控制403单播流最迟在延迟的FCC多播流开始时终止。

根据一个实施例，基于最小网络等待时间和最大网络等待时间确定FCC多播流的延迟，例如确定为在最大网络等待时间与最小网络等待时间之间的差。这在下面进一步描述并在图5a中示出。

根据另一实施例，误差裕度被添加到确定的延迟，从而产生要用于相对于所述信道延迟FCC多播流的更长延迟。这在下面进一步描述并在图5b中示出。

此外，可控制单播流终止，使得所述信道的内容通过单播流或FCC多播流传送。

在理想的情形中，测量的IGMP等待时间值是完全准确的，并且由于不适当的测量而重叠流的风险不存在。在此类情况下，如图5a所示，通过从IGMP最大等待时间减去IGMP最小等待时间，能够确定必需的延迟。实际上，如图5b所示，在计算适当的多播延迟时，将某个误差裕度考虑在内是合理的。视避免重叠流的相对重要性而定，通过在单播流的最后分组与FCC多播流的第一分组之间引入时间间隙，能够应用误差裕度。对于实际的给定请求，最后单播流分组与第一多播分组之间的间隙是最大IGMP等待时间减去实际IGMP等待时间加上误差裕度的因子。如果应用误差裕度，则FCC服务器必须通过延长单播流来提供另外的流数据 - 补偿误差裕度。这是避免客户端接收太少流数据所必需的。

FCC服务器配置成计算单播流的长度。前提条件是FCC服务器例如通过配置知道最大和最小IGMP等待时间，并且FCC多播流延迟时间是至少这两个值的差。

计算单播流的持续时间的公式能够表述如下：

单播流持续时间=（相对于原多播流的GOP开始+误差裕度）/超速因子

GOP开始指环形缓冲器中单播流应开始的点。FCC服务器根据FCC接收来自客户端的FCC请求时在环形缓冲器中I帧的数量和超速因子，确定适当的GOP开始。如果在环形缓冲器中有几个I帧，则选择最近的I帧是优选的，这是因为需要传送的单播流数据更少。但选择太靠近直播点的I帧可限制解码器缓冲器能够更快填充的程度。这是因为使用1秒解码器缓冲器时在20%超速需要至少5秒的流传送。因此，如果GOP开始不是至少在FCC多播后1秒，则将不可能在超速速率填充整个解码器缓冲器。确定最佳I帧（即，GOP开始）是FCC服务器的责任，并且不在实施例的范围内。实施例假设FCC服务器能够基于缓冲的流数据确定适当的GOP开始。

如果应用误差裕度，则FCC服务器按客户端要赶上多播流时需要的相同准则延长单播流。这实际上意味着同步点应移位到以后的时间点，该时间点对应于在时间上单播流的延长和误差裕度的长度。

如图5b所示，下面的等式对根据一个实施例计算多播延迟有效：

多播延迟=最大IGMP延迟-最小IGMP延迟+误差裕度

为示出可行示例，假设有以下值：

IGMP最大等待时间：250毫秒(ms)

IGMP最小等待时间：100ms

误差裕度：50ms

多播延迟：200ms (250 - 100 + 50) 

FCC服务器在原多播后3.5秒查找GOP开始。在20%超速（单播流比实时更快发送的速度），计算的单播流时间是(3.5 + 0.05)/ 0.2 = 17.75。FCC服务器也必须计算客户端何时应加入FCC服务器多播。为确保客户端不会接收不足的数据，服务器必须将IGMP最小等待时间和误差裕度考虑在内。客户端应加入FCC多播的时间能够通过以下等式计算得出：

同步点（加入FCC多播的时间）=单播流持续时间-IGMP最小等待时间+误差裕度

通过应用示例值，加入FCC多播流的时间给出17.7s的值(17.75 - 0.1 + 0.05)。如步骤4中所述，服务器经单独的消息向客户端指示此值。

在17.7秒后，客户端发送IGMP加入。在17.75秒后，单播流在FCC多播之前到达点200ms。同时，单播流由FCC服务器终止。

STB接收多播流的第一数据分组，例如，在IGMP加入后175ms。因此，在此示例中，IGMP等待时间为175，这意味着STB接收325ms的冗余数据（250（最大等待时间）-175（示范等待时间）+ 250（误差裕度/超速因子））。最大IGMP等待时间的情形因此将提供250ms的冗余数据，并且相反的是，最小等待时间的情况将提供400ms的冗余数据。

冗余数据的数量，以ms为单位=IGMP最大等待时间-实际IGMP等待时间+误差裕度/超速因子

在图5a和5b中示出相对于上面的示例的实施例的原则。通过适当计算以毫秒为单位的单播流的长度，并且通过基于准确测量的IGMP等待时间值来延迟多播流，图5a和5b示例显示不发生单播和多播流的重叠。

解决方案的一个重要方面是测量的最大和最小IGMP等待时间的准确度。为所有或适当选择的客户端经常测量IGMP等待时间，并且提供测量到FCC服务器，允许持续细调FCC多播延迟和IGMP加入时间。重新配置FCC多播流的延迟应在适合的时间点进行，以确保用户体验不受延迟更改的影响。

为测量用于特定客户端的IGMP等待时间，本发明提议的方法是客户端保持此信息的记录。对于每个请求，客户端比较该值是否小于以前记录的最小等待时间或大于以前记录的最大等待时间。

如果客户端没有以前最大或最小IGMP等待时间的记录，则客户端能够对它具有访问权的适当选择的信道或所有信道发出IGMP加入和离开(LEAVE)请求。信道更改请求（加入和离开操作）应连续执行以避免过多的带宽要求。在此测量操作期间，应不利用FCC功能。

在应用客户端特定测量前，强烈建议记录的最大和最小等待时间是基于足够数量的IGMP请求。如果只记录了少量的请求，则存在客户端特定等待时间值的准确度不足够的风险。在此方面足够的记录请求的数量取决于在假设有一定数量的IGMP请求的情况下记录足够准确的IGMP等待时间值的概率。

IGMP等待时间测量能够由客户端使用厂商特定扩展经实时传输控制协议(RTCP)报告提交。

在直播IPTV网络中，可发生环境更改使得FCC服务器已知的IGMP等待时间值不准确，需要进行更新。在此类情形下，如果客户端报告在FCC操作期间再发生的异常到网络中的接收节点，例如，FCC服务器，则这是有益的。大多数情况下，客户端在所述情形期间预期的异常采用携带流数据的丢失分组的形式。通过区分在FCC操作期间发生的分组丢失的报告和在其它事件期间发生的分组丢失，FCC服务器（或接收报告的节点）可断定在网络上存在与FCC服务有关的特定故障。

指示在FCC操作期间发生的分组丢失的报告能够使用厂商特定扩展经RTCP报告提交。

如图6所示，提供了根据本发明的一个方面的FCC服务器。因此，提供了用于在IPTV网络中实现快速信道更改的服务器600，也称为FCC服务器。服务器配置成通过在将FCC多播流加入某个信道之前提供所述信道的单播流，促进到所述信道的快速信道更改，并且最大网络等待时间和最小网络等待时间已知。服务器600包括处理器602，处理器配置成确定取决于最大和最小网络等待时间的FCC多播流的延迟，相对于所述信道的原多播流延迟FCC多播流，以及控制单播流最迟在延迟的FCC多播流开始时终止。FCC服务器也可包括用于存储例如网络等待时间的最大和最小值的存储器603。

根据一个实施例，处理器602配置成基于最小网络等待时间和最大网络等待时间确定FCC多播流的延迟，例如确定为在最大网络等待时间与最小网络等待时间之间的差。

此处，处理器602可配置成添加误差裕度到延迟以便用于相对于所述信道延迟FCC多播流，而不增大客户端接收太少数据的风险。添加误差裕度意味着同步点移位到以后的时间点，从而产生比无误差裕度时更长的单播流。因此，如果应用误差裕度，则在根据本发明所述原则计算同步点时必须将误差裕度考虑在内。

另外，处理器602可配置成终止单播流，使得所述信道的内容通过单播流或多播流传送。

如图6所示，服务器的功能性可通过与存储软件代码部分的存储器603相关联的处理器602实现。处理器运行软件代码部分604以实现根据本发明的实施例的服务器的功能性。

另外，FCC服务器配置成对从客户端收到的FCC请求做出反应，并且生成单播流和FCC多播流。根据实施例，相对于原多播流延迟FCC多播流。此外，FCC服务器配置成控制在单播流与FCC多播流之间的切换。

客户端可配置成测量IGMP最小和最大等待时间并且如上所述报告在FCC操作期间发生的异常。