CN103329558B - 单播多播iptv网络中实现快速信道更改的方法和服务器 - Google Patents

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

Info

Publication number
CN103329558B
CN103329558B CN201180066102.8A CN201180066102A CN103329558B CN 103329558 B CN103329558 B CN 103329558B CN 201180066102 A CN201180066102 A CN 201180066102A CN 103329558 B CN103329558 B CN 103329558B
Authority
CN
China
Prior art keywords
fcc
multicast
channel
delay
multicast flows
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201180066102.8A
Other languages
English (en)
Other versions
CN103329558A (zh
Inventor
T.伦德奎斯特
M.塞德瓦尔
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vivo Mobile Communication Co Ltd
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of CN103329558A publication Critical patent/CN103329558A/zh
Application granted granted Critical
Publication of CN103329558B publication Critical patent/CN103329558B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383—Accessing a communication channel
    • H04N21/4384—Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6408—Unicasting

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

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

Description

单播多播IPTV网络中实现快速信道更改的方法和服务器
技术领域
本发明的实施例涉及因特网协议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操作期间发生的异常。

Claims (4)

1.一种在服务器中用于在因特网协议TV，IPTV，网络中实现快速信道更改FCC的方法，其中通过在将FCC多播流加入某个信道之前提供所述信道的单播流而促进到所述信道的快速信道更改，以及其中最大网络等待时间和最小网络等待时间已知，所述方法包括：
-将所述FCC多播流的延迟确定(401)为所述最大网络等待时间与所述最小网络等待时间之差，
-通过所述确定的延迟，相对于所述信道的原多播流延迟(402)所述FCC多播流，以及
-控制(403)所述单播流最迟在所述延迟的FCC多播流开始时终止。
2.如权利要求1所述的方法，其中误差裕度被添加到所述确定的延迟，从而产生要用于相对于所述信道延迟所述FCC多播流的更长延迟。
3.一种用于在因特网协议TV，IPTV，网络中实现快速信道更改FCC的服务器(600)，其中所述服务器配置成通过在将FCC多播流加入某个信道之前提供所述信道的单播流而促进到所述信道的快速信道更改，并且最大网络等待时间和最小网络等待时间已知，所述服务器(600)包括处理器(602)，所述处理器配置成将所述FCC多播流的延迟确定为所述最大网络等待时间与所述最小网络等待时间之差，相对于所述信道的原多播流延迟所述FCC多播流，以及控制所述单播流最迟在所述延迟的FCC多播流开始时终止。
4.如权利要求3所述的服务器，其中所述处理器(602)配置成添加误差裕度到所述确定的延迟，从而产生要用于相对于所述信道延迟所述FCC多播流的更长延迟。
CN201180066102.8A 2011-01-26 2011-01-26 单播多播iptv网络中实现快速信道更改的方法和服务器 Active CN103329558B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2011/050082 WO2012102651A1 (en) 2011-01-26 2011-01-26 Method and server for fast channel change in unicast-multicast iptv networks

Publications (2)

Publication Number Publication Date
CN103329558A CN103329558A (zh) 2013-09-25
CN103329558B true CN103329558B (zh) 2017-06-09

Family

ID=46581038

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201180066102.8A Active CN103329558B (zh) 2011-01-26 2011-01-26 单播多播iptv网络中实现快速信道更改的方法和服务器

Country Status (4)

Country Link
US (1) US9009765B2 (zh)
EP (1) EP2668778A4 (zh)
CN (1) CN103329558B (zh)
WO (1) WO2012102651A1 (zh)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8819264B2 (en) * 2011-07-18 2014-08-26 Verizon Patent And Licensing Inc. Systems and methods for dynamically switching between unicast and multicast delivery of media content in a wireless network
US8949451B2 (en) * 2012-04-27 2015-02-03 Mobitv, Inc. Combined broadcast and unicast delivery
US9288136B2 (en) * 2012-09-21 2016-03-15 Cisco Technology, Inc. Method and apparatus for in-band channel change for multicast data
CN104426875A (zh) * 2013-09-02 2015-03-18 中兴通讯股份有限公司 一种频道快速切换方法、服务器及系统
US9538137B2 (en) 2015-04-09 2017-01-03 Microsoft Technology Licensing, Llc Mitigating loss in inter-operability scenarios for digital video
EP3298747B1 (en) * 2015-05-20 2018-09-12 NxT Solutions AG Iptv in managed networks
US20170272827A1 (en) * 2016-03-16 2017-09-21 Samsung Electronics Co., Ltd. Display apparatus and controlling method thereof
CN106961625B (zh) * 2017-03-13 2020-02-21 华为技术有限公司 一种频道切换方法及其装置
US10667017B2 (en) 2017-07-20 2020-05-26 International Business Machines Corporation Adaptive packaging and distribution of channels
CN107682718A (zh) * 2017-09-21 2018-02-09 烽火通信科技股份有限公司 多iptv平台下快速切换频道的方法及系统

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7562375B2 (en) * 2003-10-10 2009-07-14 Microsoft Corporation Fast channel change
US8331375B2 (en) * 2004-08-06 2012-12-11 Qualcomm Incorporated Technology agnostic QoS support in a multi-mode environment
CA2597836C (en) * 2005-02-23 2014-07-15 Arroyo Video Solutions, Inc. Fast channel change with conditional return to multicasting
US7804831B2 (en) 2005-04-01 2010-09-28 Alcatel Lucent Rapid media channel changing mechanism and access network node comprising same
EP1993289A1 (en) 2007-05-16 2008-11-19 Nokia Siemens Networks Oy System having improved switching times between broadcast/multicast bearers
KR100880893B1 (ko) 2007-09-14 2009-01-30 한국전자통신연구원 복수의 멀티캐스트를 이용한 ｉｐｔｖ 고속 채널 전환을위한 장치 및 그 방법
EP2169954A1 (en) * 2008-09-24 2010-03-31 Alcatel Lucent Service configuration and management for fast channel change and reliable delivery of multimedia services
US8732327B2 (en) 2009-03-31 2014-05-20 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for system providing media via multicast distribution
EP2415261A4 (en) 2009-03-31 2012-08-22 Ericsson Telefon Ab L M METHOD AND ARRANGEMENT FOR CHANNEL CHANGING IN AN IPTV NETWORK
KR100979482B1 (ko) 2009-04-10 2010-09-02 주식회사 쿠오핀 재핑 딜레이 감소를 위한 유니캐스트와 멀티캐스트 스트림 절체방법 및 그 장치
US8161515B2 (en) 2009-05-13 2012-04-17 Alcatel Lucent Fast channel change handling of late multicast join
GB2495743B (en) * 2011-10-19 2014-06-11 Canon Kk Communication method and apparatus

Also Published As

Publication number Publication date
US20130332974A1 (en) 2013-12-12
EP2668778A1 (en) 2013-12-04
US9009765B2 (en) 2015-04-14
CN103329558A (zh) 2013-09-25
EP2668778A4 (en) 2014-07-23
WO2012102651A1 (en) 2012-08-02

Similar Documents

Publication Publication Date Title
CN103329558B (zh) 单播多播iptv网络中实现快速信道更改的方法和服务器
US8839340B2 (en) Method, system and device for synchronization of media streams
US9866886B2 (en) Method and apparatus for distributing a media content service
KR102299233B1 (ko) 콘텐츠 전달
JP5788473B2 (ja) 端末の出力を同期させる方法およびシステム
US9565482B1 (en) Adaptive profile switching system and method for media streaming over IP networks
EP3202105B1 (en) Managing streamed communication
KR20080032088A (ko) 실시간 콘텐츠 분배의 클라이언트 입력 버퍼의 충전율 추정 장치 및 방법
Montagud et al. Enhanced adaptive RTCP-based Inter-Destination Multimedia Synchronization approach for distributed applications
WO2013098809A1 (en) Media stream rate reconstruction system and method
US20070127390A1 (en) Method for providing quality-guaranteed service in converged network and apparatus using the same
EP3013013B1 (en) Networking device and method for buffer management in video streaming over a network
Mignon et al. Scaling server-based channel-change acceleration to millions of IPTV subscribers
KR100670833B1 (ko) 융합형 네트워크상에서의 품질 보장형 서비스 제공 방법 및이를 이용한 네트워크 장치
EP2912817B1 (en) A method and apparatus for distributing media content services
EP2645671A1 (en) Switching the playing out of information content beween end-user devices
Boronat et al. Smooth control of adaptive media playout to acquire IDMS in cluster-based applications
Sarni et al. A novel scheme for a fast channel change in multicast IPTV system
Prins Fast retransmission for multicast IPTV
WO2015135576A1 (en) Distributing media content services and alternative media content
Dhamodaran Optimization of Flexible Dual-TCP/UDP Streaming Protocol For HD Video Streaming over 802.11 Wireless Networks
Montagud et al. Design, Development and Assessment of Control Schemes for IDMS in an Evolved and Standardized RTCP-based Solution

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20210421

Address after: 168 Jinghai East Road, Chang'an Town, Dongguan City, Guangdong Province

Patentee after: VIVO MOBILE COMMUNICATION Co.,Ltd.

Address before: Stockholm, Sweden

Patentee before: Sweden Ericsson Co.,Ltd.