CN102118653A - 保障网络电视直播业务的业务服务质量的方法和设备 - Google Patents

保障网络电视直播业务的业务服务质量的方法和设备 Download PDF

Info

Publication number
CN102118653A
CN102118653A CN2009102388769A CN200910238876A CN102118653A CN 102118653 A CN102118653 A CN 102118653A CN 2009102388769 A CN2009102388769 A CN 2009102388769A CN 200910238876 A CN200910238876 A CN 200910238876A CN 102118653 A CN102118653 A CN 102118653A
Authority
CN
China
Prior art keywords
message
delay
time
multicast
service device
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.)
Granted
Application number
CN2009102388769A
Other languages
English (en)
Other versions
CN102118653B (zh
Inventor
欧雄兵
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.)
Yingweite Spe LLC
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN2009102388769A priority Critical patent/CN102118653B/zh
Priority to PCT/CN2010/080611 priority patent/WO2011079822A1/zh
Priority to EP20100840609 priority patent/EP2521298B1/en
Publication of CN102118653A publication Critical patent/CN102118653A/zh
Priority to US13/540,062 priority patent/US9246639B2/en
Application granted granted Critical
Publication of CN102118653B publication Critical patent/CN102118653B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1835—Buffer management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1887—Scheduling and prioritising arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/188—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092—Error control systems characterised by the topology of the transmission link
    • H04L2001/0093—Point-to-multipoint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092—Error control systems characterised by the topology of the transmission link
    • H04L2001/0097—Relays

Landscapes

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

Abstract

本发明实施例提供了一种保障网络电视直播业务的业务服务质量的方法，该方法包括：检测从原始组播组中收到的直播报文；当检测到所述直播报文有错误或丢失时，加入重传服务器发送的延时组播流对应的组播组，并从所述延时组播流中接收延时重发报文；根据接收到的所述延时重发报文恢复所述直播报文。相应地，还提供了一种终端和重传服务器。使得终端一旦检测到原始报文丢失或错误，可以直接从重传服务器发送的延时报文流中接收报文进行恢复，不需要向重传服务器发送Nack消息请求重传数据，避免了Nack风暴，简化了重传服务器的处理，提高了重传的效率。

Description

保障网络电视直播业务的业务服务质量的方法和设备
技术领域
本发明涉及通信技术领域，特别涉及一种保障网络电视直播业务的业务服务质量的方法和设备。
背景技术
以机顶盒加电视机为终端、以宽带IP作为传输技术、以视听业务为主，集即时通讯、游戏、信息服务为一体的网络电视(Internet ProtocolTelevision，简称IPTV)业务近年来引起了运营商的重点关注，从2004年下半年开始，国内运营商加快了IPTV试点建设的步伐。作为一种新兴的服务提供方式，IPTV提供了潜在的新业务、新收入、新商务模式的机遇，将为通信和媒体服务提供商带来新的利润增长点。
直播业务作为IPTV基础业务，是对传统电视业务的继承，其业务质量至少应与现有有线电视相当才能确保IPTV的竞争力，因此，保证直播业务的业务服务质量(Quality of Service，简称QoS)对于IPTV业务的顺利开展至关重要。
在IP网络上由于传输的原因会出现丢包或错包，前向纠错(ForwardError Correction，简称FEC)和自动重传请求(Auto Repeat Request，简称ARQ)技术在IPTV业务中是常用的两种用来恢复原始报文的方法，对于保证直播业务的QoS也可以采用这两种方法。FEC的实现相对比较简单，但是需要消耗更多的冗余带宽，并且存在超过纠错能力后无法恢复的问题，所以在实际应用和标准组织中通常使用ARQ的方式来恢复丢失或错误的报文。
在ARQ方式中，终端接收直播业务对应的组播报文数据并解码输出，在接收过程中根据丢包检测算法检测是否有报文丢失或错误。如果有报文出现丢失或错误，则直接向重传服务器发送请求重传数据的Nack报文，重传服务器在收到Nack重传请求后，按照Nack报文的指示给终端重传指定的报文。
该方法可以快速向重传服务器反馈各个终端的重传请求。但是，如果不是由于用户侧导致的丢包，而是在传输网络的汇聚或者核心节点层面出现的丢包，则每个用户都能感知到丢包。对于这种情况，会导致重传服务器几乎在同时接收到多个终端发出的Nack重传请求(这种情况被称之为Nack风暴)。短时间内的Nack风暴会导致如下两个问题：
1、重传服务器的负荷瞬间增强，可能导致工作状态异常或者有些终端的重传请求得不到及时响应；
2、同时给多个用户重传数据报文会导致占用的网络带宽激增，以致难以进行网络带宽规划，并且可能会导致网络进一步拥塞，因此导致丢包进一步加剧，整个系统处于不稳定的状态。
发明内容
本发明实施例提供一种保障网络电视直播业务的业务服务质量的方法和设备，以避免Nack风暴，提高重传的效率。
本发明实施例提供一种保障网络电视直播业务的业务服务质量的方法，包括：
检测从原始组播组中收到的直播报文；
当检测到所述直播报文有错误或丢失时，加入重传服务器发送的延时组播流对应的组播组，并从所述延时组播流中接收延时重发报文；
根据接收到的所述延时重发报文恢复所述直播报文。
本发明实施例提供一种终端，包括：
接收单元，用于从原始组播组中接收直播报文或者从延时组播流中接收延时重发报文；
检测单元，用于对接收单元接收到的所述直播报文进行检测，确定所述直播报文是否有错误或丢失；
加入单元，用于当所述检测单元检测到接收的所述直播报文有错误或丢失时，加入重传服务器发送的延时组播流对应的组播组；
恢复单元，用于根据所述接收单元接收的延时重发报文恢复所述直播报文。
本发明实施例提供一种重传服务器，包括：
接收单元，用于从原始组播组中接收直播报文；
缓存单元，用于将所述接收单元接收的所述直播报文去掉IP层的封装后缓存起来；
延时发送单元，用于将所述缓存单元缓存的所述直播报文经过一定的时延后，以新的组播IP封装重发。
本发明实施例通过重传服务器延时重发原始报文流，终端一旦检测到原始报文丢失或错误，就直接从延时报文流中接收报文进行恢复，不需要向重传服务器发送Nack消息请求重传数据，因此避免了Nack风暴，简化了重传服务器的处理，提高了重传的效率。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1本发明提供的保障网络电视直播业务的业务服务质量的方法一个实施例的流程示意图；
图2本发明提供的保障网络电视直播业务的业务服务质量的方法另一个实施例的流程示意图；
图3本发明实施例提供的终端检测到丢包时，从延时组播流接收延迟报文的示意图；
图4本发明实施例提供的终端结构示意图；
图5本发明实施例提供的重传服务器结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
图1为本发明保障网络电视直播业务的业务服务质量的方法一个实施例的流程图。如图1所示，本实施例的方法包括：
步骤100、检测从原始组播组中收到的直播报文；
步骤102、当检测到所述直播报文有错误或丢失时，加入重传服务器发送的延时组播流对应的组播组，并从所述延时组播流中接收延时重发报文；
步骤104、根据接收到的所述延时重发报文恢复所述直播报文。
需要说明的是，在步骤100之前，进一步可以包括：重传服务器将接收到的所述直播报文去掉IP层的封装后保存在缓存中，经过一定的时延后，再将缓存的所述直播报文以新的组播IP封装重发；以及，终端通过和电子节目菜单服务器交互，获取直播频道列表信息，所述信息至少包括直播报文的组播IP地址和延时重发报文的组播IP地址。
图2为本发明保障网络电视直播业务的业务服务质量的方法另一个实施例的流程图。图中的头端是提供节目的源头，用来将外界的节目内容转换成适合在IPTV网络中传输的形式，如将通过卫星传输的基于MPEG-2编码格式的直播节目接收下来后转码成基于H.264编码格式的节目，实际中为了节省带宽一般再将重新生成的直播节目按照IP组播方式输入到IPTV网络中供用户观赏。如图2所示，本实施例具体包括：
步骤201、重传服务器在部署时加入从头端过来的组播报文的组播组，接收直播频道的节目内容，对接收到的报文去掉IP层的封装后保存在缓存中。
需要说明的是，在IPTV系统中一般会部署媒体服务器来为用户提供视频点播(Video On Demand，简称VOD)业务，因此在实际应用中可以用媒体服务器来充当直播业务的重传服务器或者部署单独的重传服务器来提供直播重传功能。
步骤202、为了减少组播加入的时延，在节目部署时将直播频道的节目内容直接推送到了接入设备上，即接入设备也加入组播组接收组播报文。实际应用中比较常见的接入设备包括IP-DSLAM和GEPON。
步骤203、重传服务器将缓存的报文经过一定的延时后也按照组播的方式推送到接入设备上。
即，重传服务器在经过一定的时延后将缓存的直播节目的报文以预先分配的新的组播IP封装并发送出去。其中，时延的取值由以下至少一种因素决定：网络的报文传输时延，终端检测到报文丢失或错误的检测时延以及终端加入到新的组播组的处理时延。这些时延值在实际应用中可以根据网络规划来确定。
需要说明的是，在该步骤中，重传服务器也可以向接入设备推送多个不同延时的组播流，每个组播流相对原始组播流的时延不一样，从而满足不同终端的要求。
步骤204、终端开机后首先与应用服务器交互进行必要的鉴权，确保业务的合法使用。
步骤205、终端鉴权通过后，通过与电子节目菜单(Elect ronic ProgramGuide，简称EPG)服务器的交互获得直播频道列表信息。
需要说明的是，该直播频道列表信息中除了包含正常的直播节目的组播IP地址和用于对直播节目音视频码流进行解码的编解码参数信息外，还包含组播延时重传的报文流的信息。从而，终端在检测到报文丢失或错误时，知道加入到哪个组播组接收重传报文流进行恢复。如下是按照会话描述协议(Session Description Protocol，简称SDP)形式给出的频道列表中某个频道参数的示例：
v＝0
0＝-28908445 262890842807 IN IP4 192.16.24.202
s＝SDP Session
a＝control:sdp://ts.example.com/twister/cctv1
m＝video 7722 MP2T/AVP 33//在RFC3551中定义33为MPEG-2 TS流对应的PT类型
c＝IN IP4 224.2.1.183//节目的组播IP地址
a＝rtcp:3021 IN IP4 126.16.64.4//接收Nack消息的重传服务器接收RTCP消息的IP地址和端口号
a＝delay-stream:delay＝200；port＝7722，IN IP4 192.16.24.204//延时重传的组播流，相对于原始流的时延为200ms，其组播IP地址为192.16.24.204，延时重传流使用与原始流一致的端口号
如果重传服务器在步骤203中发送了多个不同延时的组播流(假设是两个)，则上述频道列表中某个频道参数的示例可以表示如下：
v＝0
0＝-2890844526 2890842807 IN IP4 192.16.24.202
s＝SDP Session
a＝control:s dp://ts.example.com/twister/cctv1
m＝video 7722 MP2T/AVP 33//在RFC3551中定义33为MPEG-2 TS流对应的PT类型
c＝IN IP4 224.2.1.183//节目的组播IP地址
a＝rtcp:3021 IN IP4 126.16.64.4//接收Nack消息的重传服务器接收RTCP消息的IP地址和端口号
a＝delay-stream:delay＝200；port＝7722，IN IP4 192.16.24.204//延时重传的组播流1，相对于原始流的时延为200ms，其组播IP地址为192.16.24.204，延时重传流使用与原始流一致的端口号
a＝delay-stream:delay＝300；port＝7722，IN IP4 192.16.24.206//延时重传的组播流2，相对于原始流的时延为300ms，其组播IP地址为192.16.24.206，延时重传流使用与原始流一致的端口号
需要说明的是：这里通过扩展SDP描述来示例指示了重传流的信息，其他的扩充描述方式只要终端可以理解也是可以的。
步骤206、终端通过接入设备按照正常切换频道的方式切换到指定频道，即通过Internet组管理协议(Internet Group Management Protocol，简称IGMP)消息加入指定频道所对应的组播组。
步骤207、接入设备完成IGMP消息处理后将指定频道的组播报文转发给终端，终端收到原始组播组的组播报文后正常解码和输出。
步骤208、终端如果检测到从原始组播组中收到的组播报文有错误或者丢失，则立即通过IGMP消息从接入设备加入到从重传服务器播出的延时组播流所对应的组播组。
需要说明的是，对于存在多个延时组播流的情况，由于终端可以加入的组播组有多个，并且各个组播组相对原始组播流的时延不一样，则终端可以根据网络传输时延、检测报文丢失或错误的时延和加入组播组的时延来选择合适的组播组加入。另外，由于存在多个有时延差异的延时组播流，则终端如果从最近的延时组播流上没有找到可以恢复的报文，终端可以加入下一个延时组播流继续查找。
步骤209、接入设备完成IGMP消息处理后将延时重传的组播报文转发给终端。
步骤210、终端从延时组播流中接收报文。
具体地，终端对于已经在原始组播流中正确收到的报文直接丢弃，当终端从延时组播流中找到需要恢复的报文后，通过IGMP消息退出该组播组，只保留原始组播组并继续从原始组播组接收报文。
图3是对上述步骤的一个图示说明，图中设延时重发报文相对原始直播报文的时延为T，则，假设用户原来在接收原始报文流，用户在A时刻检测到P5所对应的报文丢失，则加入延迟报文所在的组播流，准备从延迟重传流中重新接收丢失的报文。
如图所示，设终端在B点开始接收延迟报文流，则终端对于以前在原始报文流中已经收到的报文直接丢弃；设终端在C点收到了用于恢复的P5报文，则终端在D点退出该组播组，继续从原始组播组接收原始报文流.
步骤211、如果终端加入到延时重传的组播流后发现已经错过了想要的报文，或者虽然收到了重传报文，但是已经错过了终端对该报文的解码时间，因此收到的重传报文最终也是无效的，则终端可以再直接向重传服务器请求重传报文。
具体地，针对这种重传报文流的时延设置不合适的情况终端可以通过扩展的实时控制协议(Real-time Control Protocol，简称RTCP)报文向重传服务器反馈，扩展的RTCP报文可以和原始的Nack消息复用在一起传输。重传服务器收到多个终端的反馈信息后可以对重传流的时延进行调整，或者增加新的重传流。
根据步骤205中获得的信息，扩展的RTCP报文和Nack报文的目的IP地址和端口号分别为126.16.64.4和3021。扩展的RTCP报文中需要指示当前终端的检测时延和组播加入时延，还可以包括终端收到的最新的实时传送协议(Real-time Transport Protoeol，简称RTP)包序列号和收到该RTP包时所对应的协调世界时(Universal Time Coordinated，简称UTC)时间信息，便于重传服务器计算网络传输时延。扩展的RTCP报文格式可以有多种构造方式，只需要包含上述信息即可，下面以RTCP报文类型中可根据实际应用需要来进行扩展的APP报文举例说明。APP报文格式如下：
Figure G2009102388769D00091
APP报文的PT类型固定为204，subtype(5bits)可以根据实际应用进行扩展，APP报文主要是利用application-dependent data来传输相关信息，这里我们定义application-dependent data部分如下：
步骤212、重传服务器收到该RTCP消息后，根据终端上报的最新的RTP包序列号和收到该RTP包时所对应的UTC时间信息，与自身收到该报文的UTC时间进行对比就可以计算重传服务器和终端之间的传输时延，结合上报的终端的检测时延和组播加入时延就可以估算该终端如果检测到丢包或错包，相对原始组播流会延迟多长时间开始收到重传流，从而可以调整重传流的延时或者根据需要增加新的重传流。
重传服务器对重传流进行了调整或者增加了新的重传流后，需要将调整后的重传流信息或者新增加的重传流信息通过扩展的RTCP报文周期性广播给终端，扩展的RTCP报文中包含了当前频道的所有重传流的信息。这里以两个重传流为例定义application-dependent data部分如下：
Figure G2009102388769D00101
步骤213、重传服务器在将调整后的重传流信息或者新增加的重传流信息周期性广播给终端的同时，也将上述信息同步到电子节目菜单服务器上。这样，新的终端也可以获取到新的重传流的信息。
步骤214、重传服务器向接入设备继续发送重传流。
需要说明的是，由于视频编码输出的I、P、B帧中，I帧最为重要，解码器必须要收到I帧才能开始解码，而P帧或者B帧丢失一般可以考虑用一些内插的方法来预测恢复。因此，如果从节省带宽的角度来考虑，本发明实施例中，延时组播流可以只是重发I帧。如果是P帧或者B帧的数据丢失，则在本地通过错误隐藏方法来减小丢包导致的对图像质量的影响即可。相应的，终端在对原始直播报文进行检测时，也只需要在发现I帧所对应的报文丢失时，才加入到重传组播组接收重传报文。
本发明实施例提供的方法，通过重传服务器延时重发原始报文流，终端一旦检测到丢包就直接从延时报文流中接收报文进行恢复，不需要向重传服务器发送Nack消息请求重传数据，避免了Nack风暴，简化了重传服务器的处理，提高了重传效率。
图4为本发明实施例提供的一种终端的结构示意图。如图4所示，该终端可以包括：接收单元，检测单元，加入单元和恢复单元。其中，所述接收单元用于从原始组播组中接收直播报文或者从延时组播流中接收延时重发报文；所述检测单元用于对接收单元接收到的所述直播报文进行检测，确定所述直播报文是否有错误或丢失；所述加入单元用于当所述检测单元检测到接收的所述直播报文有错误或丢失时，加入重传服务器发送的延时组播流对应的组播组；所述恢复单元用于根据所述接收单元接收的延时重发报文恢复所述直播报文。
进一步，该终端还可以包括(图中未示出)：信息获取单元，用于通过和电子节目菜单服务器的交互，获取直播频道列表信息，所述信息至少包括直播报文的组播IP地址和延时重发报文的组播IP地址；上报单元，用于当接收单元从重传服务器发送的延时组播流中没有接收到需要的报文或者接收到了需要的报文，但是已经错过了终端对该报文的解码时间时，向重传服务器上报对应的报文信息。
图5为本发明实施例提供的一种重传服务器的结构示意图。如图5所示，该重传服务器可以包括：接收单元，缓存单元和延时发送单元。其中，所述接收单元用于从原始组播组中接收直播报文；所述缓存单元用于将所述接收单元接收的所述直播报文去掉IP层的封装后缓存起来；所述延时发送单元，用于将所述缓存单元缓存的所述直播报文经过一定的时延后，以新的组播IP封装重发。
进一步，该重传服务器还可以包括(图中未示出)：同步单元，用于将延时重发信息同步给电子节目菜单服务器，所述延时重发信息至少包括延时重发报文对应的组播IP地址；调整单元，用于根据终端上报的报文信息，调整所述报文信息对应的延时组播流的时延或者增加新的延时组播流；广播单元，用于在所述调整单元调整所述报文信息对应的延时组播流的时延或者增加新的延时组播流后，将该变化周期性广播给终端。
通过本发明实施例提供的方法和设备，重传服务器延时重发原始报文流，终端一旦检测到丢包就直接从延时报文流中接收报文进行恢复，不需要向重传服务器发送Nack消息请求重传数据，避免了Nack风暴，简化了重传服务器的处理，提高了重传效率。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (18)

1.一种保障网络电视直播业务的业务服务质量的方法，其特征在于，该方法包括：
检测从原始组播组中收到的直播报文；
当检测到所述直播报文有错误或丢失时，加入重传服务器发送的延时组播流对应的组播组，并从所述延时组播流中接收延时重发报文；
根据接收到的所述延时重发报文恢复所述直播报文。
2.如权利要求1所述的方法，其特征在于，在所述检测从原始组播组中收到的直播报文之前，该方法还包括：
通过和电子节目菜单服务器交互，获取直播频道列表信息，所述信息至少包括直播报文的组播IP地址和延时重发报文的组播IP地址。
3.如权利要求2所述的方法，其特征在于，在所述通过和电子节目菜单服务器交互，获取直播频道列表信息之前，该方法还包括：重传服务器将接收到的所述直播报文去掉IP层的封装后保存在缓存中，经过一定的时延后，再将缓存的所述直播报文以新的组播IP封装重发。
4.如权利要求3所述的方法，其特征在于，所述重传服务器将缓存的所述直播报文至少延时重发一次以上，每次发送的报文都对应不同的发送时刻和组播IP地址。
5.如权利要求3或4所述的方法，其特征在于，所述重传服务器将延时重发信息同步给所述电子节目菜单服务器，所述延时重发信息至少包括延时重发报文对应的组播IP地址。
6.如权利要求1至4中任一项所述的方法，其特征在于，所述时延报文的时延包括以下至少一项：网络的报文传输时延，终端检测到报文错误或丢失的检测时延和终端加入到延时组播流对应的组播组的处理时延。
7.如权利要求2所述的方法，其特征在于，所述加入重传服务器发送的延时组播流对应的组播组，具体包括：
根据获取的所述延时重发报文的组播IP地址，加入重传服务器发送的延时组播流对应的组播组。
8.如权利要求1或3至4任一项所述的方法，其特征在于，所述延时重发报文只包括I帧。
9.如权利要求1所述的方法，其特征在于，所述当检测到所述直播报文有错误或丢失时，加入重传服务器发送的延时组播流对应的组播组，具体包括：
当检测到I帧所对应的直播报文有错误或丢失时，加入重传服务器发送的延时组播流对应的组播组。
10.如权利要求1所述的方法，其特征在于，如果终端从重传服务器发送的延时组播流中没有接收到需要的报文或者接收到了需要的报文，但是已经错过了终端对该报文的解码时间，则终端向重传服务器上报对应的报文信息；所述重传服务器根据所述终端上报的报文信息，调整所述报文信息对应的延时组播流的时延或者增加新的延时组播流。
11.如权利要求10所述的方法，其特征在于，所述重传服务器调整所述报文信息对应的延时组播流的时延或者增加新的延时组播流后，将该变化周期性广播给终端，并同步给电子节目菜单服务器。
12.一种终端，其特征在于，包括：
接收单元，用于从原始组播组中接收直播报文或者从延时组播流中接收延时重发报文；
检测单元，用于对接收单元接收到的所述直播报文进行检测，确定所述直播报文是否有错误或丢失；
加入单元，用于当所述检测单元检测到接收的所述直播报文有错误或丢失时，加入重传服务器发送的延时组播流对应的组播组；
恢复单元，用于根据所述接收单元接收的延时重发报文恢复所述直播报文。
13.如权利要求12所述的终端，其特征在于，所述终端还包括：
信息获取单元，用于通过和电子节目菜单服务器的交互，获取直播频道列表信息，所述信息至少包括直播报文的组播IP地址和延时重发报文的组播IP地址。
14.如权利要求12所述的终端，其特征在于，所述终端还包括：
上报单元，用于当所述接收单元从重传服务器发送的延时组播流中没有接收到需要的报文或者接收到了需要的报文，但是已经错过了终端对该报文的解码时间时，向重传服务器上报对应的报文信息。
15.一种重传服务器，其特征在于，包括：
接收单元，用于从原始组播组中接收直播报文；
缓存单元，用于将所述接收单元接收的所述直播报文去掉IP层的封装后缓存起来；
延时发送单元，用于将所述缓存单元缓存的所述直播报文经过一定的时延后，以新的组播IP封装重发。
16.如权利要求15所述的重传服务器，其特征在于，所述重传服务器还包括：
同步单元，用于将延时重发信息同步给电子节目菜单服务器，所述延时重发信息至少包括延时重发报文对应的组播IP地址。
17.如权利要求15所述的重传服务器，其特征在于，所述重传服务器还包括：
调整单元，用于根据终端上报的报文信息，调整所述报文信息对应的延时组播流的时延或者增加新的延时组播流。
18.如权利要求15所述的重传服务器，其特征在于，所述重传服务器还包括：
广播单元，用于在所述调整单元调整所述报文信息对应的延时组播流的时延或者增加新的延时组播流后，将该变化周期性广播给终端。
CN2009102388769A 2009-12-31 2009-12-31 保障网络电视直播业务的业务服务质量的方法和设备 Active CN102118653B (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN2009102388769A CN102118653B (zh) 2009-12-31 2009-12-31 保障网络电视直播业务的业务服务质量的方法和设备
PCT/CN2010/080611 WO2011079822A1 (zh) 2009-12-31 2010-12-31 保障网络电视直播业务的业务服务质量的方法和设备
EP20100840609 EP2521298B1 (en) 2009-12-31 2010-12-31 Method and apparatus for ensuring quality of service of internet protocol television live broadcast service
US13/540,062 US9246639B2 (en) 2009-12-31 2012-07-02 Method and device for ensuring quality of service of internet protocol television live broadcast service

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN2009102388769A CN102118653B (zh) 2009-12-31 2009-12-31 保障网络电视直播业务的业务服务质量的方法和设备

Publications (2)

Publication Number Publication Date
CN102118653A true CN102118653A (zh) 2011-07-06
CN102118653B CN102118653B (zh) 2012-12-26

Family

ID=44217220

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2009102388769A Active CN102118653B (zh) 2009-12-31 2009-12-31 保障网络电视直播业务的业务服务质量的方法和设备

Country Status (4)

Country Link
US (1) US9246639B2 (zh)
EP (1) EP2521298B1 (zh)
CN (1) CN102118653B (zh)
WO (1) WO2011079822A1 (zh)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013083052A1 (zh) * 2011-12-09 2013-06-13 华为技术有限公司 获取组播地址的方法、装置及系统
CN103533450A (zh) * 2013-06-09 2014-01-22 浙江宇视科技有限公司 一种媒体流可靠传输和接收的方法以及装置
CN103780325A (zh) * 2014-01-17 2014-05-07 航天数字传媒有限公司 一种卫星传输监控监测系统
CN103825689A (zh) * 2014-03-03 2014-05-28 中国人民解放军理工大学 具有本地缓存的延迟确定性报文重传方法
CN105519121A (zh) * 2014-06-27 2016-04-20 北京新媒传信科技有限公司 一种关键帧路由的方法及媒体服务器
CN109286814A (zh) * 2017-07-19 2019-01-29 中兴通讯股份有限公司 一种无源光网络中检测iptv业务的方法和设备
CN112313918A (zh) * 2018-10-02 2021-02-02 谷歌有限责任公司 直播流连接器
CN112702629A (zh) * 2017-05-27 2021-04-23 华为技术有限公司 一种故障检测方法、监控设备及网络设备
CN113824991A (zh) * 2021-10-29 2021-12-21 中国电信股份有限公司 境外电视信号传输系统、方法、装置、终端及存储介质
CN114095796A (zh) * 2020-07-30 2022-02-25 中国移动通信集团终端有限公司 无效重传包减少方法、装置、设备及计算机存储介质

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2375614B1 (en) * 2010-04-09 2014-05-07 Alcatel Lucent Method for broadcasting multimedia content
US9906645B2 (en) * 2013-04-03 2018-02-27 Qualcomm Incorporated Rewinding a real-time communication session
US9760114B1 (en) * 2014-01-03 2017-09-12 Juniper Networks, Inc. Systems and methods for improving clock synchronization between master and slave devices
CN107710712B (zh) * 2015-06-19 2020-06-26 华为技术有限公司 一种集群通信方法、装置及设备
CN110730053A (zh) * 2019-09-09 2020-01-24 晶晨半导体（深圳）有限公司 一种基于ts格式和udp传输方式的网络丢包重传方法
KR20210065691A (ko) 2019-11-27 2021-06-04 삼성전자주식회사 서버 및 그 제어 방법
KR20210097285A (ko) * 2020-01-30 2021-08-09 삼성전자주식회사 이동통신 네트워크의 미디어 처리 및 전송에 대한 지연을 할당하기 위한 장치와 방법
CN114826750B (zh) * 2022-04-29 2024-02-06 阿里巴巴（中国）有限公司 一种网络异常检测方法、服务器、服务器集群及存储介质

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003209576A (ja) * 2002-01-15 2003-07-25 Matsushita Electric Ind Co Ltd マルチキャスト通信方法及びそのシステム
CN1852076B (zh) 2005-12-31 2010-05-05 华为技术有限公司 一种数据重传方法
US7793329B2 (en) * 2006-02-06 2010-09-07 Kasenna, Inc. Method and system for reducing switching delays between digital video feeds using multicast slotted transmission technique
WO2007130012A1 (en) * 2006-04-29 2007-11-15 Thomson Licensing Seamless handover of multicast sessions in internet protocol based wireless networks using staggercasting
US7573875B2 (en) * 2006-05-19 2009-08-11 Alcatel Lucent Proactively providing a redundant multicast tree in an internet protocol television (IPTV) network
US20080098089A1 (en) * 2006-10-19 2008-04-24 Ericsson, Inc. Method and apparatus for retransmission request reduction in a network
CN100550999C (zh) * 2006-11-22 2009-10-14 华为技术有限公司 一种数字频道快速切换方法和系统以及辅助频道生成设备
US20080201752A1 (en) * 2007-02-16 2008-08-21 At&T Knowledge Ventures, L.P. Multicast data packet recovery system
CN101316357B (zh) * 2008-06-30 2011-09-14 华为技术有限公司 一种频道切换的方法和终端
JP5139907B2 (ja) * 2008-07-25 2013-02-06 株式会社日立製作所 通信システム、光多重終端装置及び輻輳制御方法

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013083052A1 (zh) * 2011-12-09 2013-06-13 华为技术有限公司 获取组播地址的方法、装置及系统
US9516385B2 (en) 2011-12-09 2016-12-06 Huawei Technologies Co., Ltd. Technique for obtaining a multicast address that matches an IP version supported by a terminal
CN103533450B (zh) * 2013-06-09 2018-03-09 浙江宇视科技有限公司 一种媒体流可靠传输和接收的方法以及装置
CN103533450A (zh) * 2013-06-09 2014-01-22 浙江宇视科技有限公司 一种媒体流可靠传输和接收的方法以及装置
CN103780325A (zh) * 2014-01-17 2014-05-07 航天数字传媒有限公司 一种卫星传输监控监测系统
CN103780325B (zh) * 2014-01-17 2016-04-27 航天数字传媒有限公司 一种卫星传输监控监测系统
CN103825689A (zh) * 2014-03-03 2014-05-28 中国人民解放军理工大学 具有本地缓存的延迟确定性报文重传方法
CN103825689B (zh) * 2014-03-03 2017-04-19 中国人民解放军理工大学 具有本地缓存的延迟确定性报文重传方法
CN105519121A (zh) * 2014-06-27 2016-04-20 北京新媒传信科技有限公司 一种关键帧路由的方法及媒体服务器
CN112702629A (zh) * 2017-05-27 2021-04-23 华为技术有限公司 一种故障检测方法、监控设备及网络设备
CN112702629B (zh) * 2017-05-27 2022-02-11 华为技术有限公司 一种故障检测方法、监控设备及网络设备
US11968422B2 (en) 2017-05-27 2024-04-23 Huawei Technologies Co., Ltd. Video stream fault detection
CN109286814A (zh) * 2017-07-19 2019-01-29 中兴通讯股份有限公司 一种无源光网络中检测iptv业务的方法和设备
CN109286814B (zh) * 2017-07-19 2022-07-12 中兴通讯股份有限公司 一种无源光网络中检测iptv业务的方法和设备
CN112313918A (zh) * 2018-10-02 2021-02-02 谷歌有限责任公司 直播流连接器
CN112313918B (zh) * 2018-10-02 2023-09-05 谷歌有限责任公司 直播流连接器
CN114095796A (zh) * 2020-07-30 2022-02-25 中国移动通信集团终端有限公司 无效重传包减少方法、装置、设备及计算机存储介质
CN113824991A (zh) * 2021-10-29 2021-12-21 中国电信股份有限公司 境外电视信号传输系统、方法、装置、终端及存储介质

Also Published As

Publication number Publication date
US20120278845A1 (en) 2012-11-01
EP2521298A4 (en) 2012-11-07
EP2521298B1 (en) 2014-08-27
EP2521298A1 (en) 2012-11-07
WO2011079822A1 (zh) 2011-07-07
CN102118653B (zh) 2012-12-26
US9246639B2 (en) 2016-01-26

Similar Documents

Publication Publication Date Title
CN102118653B (zh) 保障网络电视直播业务的业务服务质量的方法和设备
CN100592670C (zh) 一种在iptv网络中动态自适应前向差错控制的系统及方法
US7542438B2 (en) Reliable multicast data retransmission method by grouping wireless terminals in wireless communication medium and apparatus for the same
EP1604477B1 (en) Transmission of data with forward error correction information
US8499212B2 (en) Method and apparatus for adaptive forward error correction with merged automatic repeat request for reliable multicast in wireless local area networks
CN101316357B (zh) 一种频道切换的方法和终端
CN101729228B (zh) 丢包抑制重传的方法、网络节点和系统
US8112542B2 (en) Multicast digital video lost packet recovery
US8127196B2 (en) Server and client for determining error restoration according to image data transmission, and method of determining error restoration according to image data transmission
CN101197693A (zh) 用于组播数据的方法和装置
CN102098586A (zh) 一种基于前向纠错的iptv传输质量控制方法及iptv终端
Xu et al. Smart media transport: A burgeoning intelligent system for next generation multimedia convergence service over heterogeneous networks in China
KR100240645B1 (ko) 멀티캐스트 통신의 패킷 오류 제어기 및 이를 이용한패킷 오류제어 방법
JP2011146942A (ja) 衛星受信装置および通信方法
CN103428531A (zh) 一种多媒体数据的arq控制方法及系统
CN103685314A (zh) 实现流媒体播放单播和多播无缝切换的方法
CN102065372A (zh) 以广播方式传输数据的方法及相关装置
WO2010108416A1 (zh) 转发可伸缩视频编码数据报文的方法、设备和通信系统
WO2008134897A1 (en) Method and system for quality service enhancement in networks for media streaming
JP5536033B2 (ja) 送信する方法、モバイル端末及びファイルサーバ
KR100792153B1 (ko) 멀티캐스트 기반 네트워크에서의 데이터 전송 방법, 데이터처리 방법 및 데이터 전송 시스템
US9160638B2 (en) Method and apparatus for performing non real time service in digital broadcast system
CN117319684A (zh) 一种数据传输方法、发送装置、接收装置和系统
EP3588847A1 (en) Multicast signal transmitting and receiving method and device
CN111641877A (zh) 一种视频网关传输方法及系统

Legal Events

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

Effective date of registration: 20221103

Address after: California, USA

Patentee after: Yingweite SPE LLC

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd.