[发明专利]OTT组播方法、系统、装置、组播代理和组播服务器

说明书

本公开公开了一种OTT组播方法、系统、装置、组播代理和组播服务器，涉及数据通信领域。其中的方法包括：接收组播服务器发送的组播数据；判断组播数据是否完整，或者是否能够被修复；若组播数据不完整或不能够被修复，则生成NORM_NACK消息，并启动定时器；以及若定时器超时前，收到组播服务器重新发送的组播数据，则不向组播服务器发送NORM_NACK消息，能够防止NACK风暴，提高了带宽利用率。

技术领域

本公开涉及数据通信领域，尤其涉及一种OTT(Over The Top，通过互联网向用户提供应用服务)组播方法、系统、装置、组播代理和组播服务器。

背景技术

近年来，电信运营商依靠灵活互动的网络和完善的服务体系使IPTV(交互式网络电视)业务发展迅猛，在为IPTV直播业务服务发展过程中，建设了广泛覆盖的IP化组播网络，大大节省了服务器资源及网络主干的带宽资源，目前各省的组播网络仅用于承载IPTV的若干路的直播服务，未得以充分的利用。

OTT业务的直播服务中，服务器与用户间采取单播的模式传输数据，占用的带宽随着用户数线性增长，带宽容易达到网络上限，必然引发用户体验下降的问题，也无法承载大量用户的超高清视频业务通过部署OTT组播系统，可将运营商的组播能力开放给直播OTT业务，将OTT流量迁移到运营商，能有效降低成本、提升用户体验、提高播放质量。

在目前OTT组播系统中，从组播服务器到组播代理的数据传输是基于建立在UDP(User Datagram Protocol，用户数据报协议)之上的RTP(Real-time TransportProtocol，实时传输协议)，为不可靠传输。而RTP通过RTCP(Real-time Transport ControlProtocol，实时传输控制协议)为其保证服务质量，但容易造成ACK(Acknowledgecharacter，确认)风暴，且传输协议不能根据网络以及用户的数量具有自适应性，无法提供较短的差错恢复延时和较高的带宽利用率。

发明内容

本公开要解决的一个技术问题是，提供一种OTT组播方法、系统、装置、组播代理和组播服务器，能够防止NACK风暴。

根据本公开一方面，提出一种OTT组播方法，包括：接收组播服务器发送的组播数据；判断组播数据是否完整，或者是否能够被修复；若组播数据不完整或不能够被修复，则生成面向否定确认的可靠组播的否定确认NORM_NACK消息，并启动定时器；以及若定时器超时前，收到组播服务器重新发送的组播数据，则不向组播服务器发送NORM_NACK消息。

在一些实施例中，若定时器超时后，未收到组播服务器重新发送的组播数据，则将NORM_NACK消息发送至组播服务器，以便组播服务器在接收到预定数量的NORM_NACK消息后，重新发送组播数据；以及接收组播服务器重新发送的组播数据，并替换不完整或不能被修复的组播数据。

在一些实施例中，判断组播数据是否完整，或者是否能够被修复包括：基于包级前向纠错技术，检测组播数据是否完整，或者是否能够被修复。

在一些实施例中，将组播数据转换为单播数据后，发送至终端。

根据本公开的另一方面，还提出一种OTT组播方法，包括：向组播代理发送组播数据；接收组播代理发送的面向否定确认的可靠组播的否定确认NORM_NACK消息，其中，组播代理在确定组播数据不完整或不能够被修复后，生成NORM_NACK消息并启动定时器，若定时器超时后，未重新收到组播数据，则发送NORM_NACK消息；以及在接收到预定数量的NORM_NACK消息后，重新向组播代理发送组播数据。

在一些实施例中，若预定时间内收到的NORM_NACK消息数量大于阈值，则生成告警信息，以便由OTT媒体服务器向终端提供单播服务。

在一些实施例中，将OTT媒体服务器发送的单播数据流转换为组播数据。