CN1992604A - 网络电视实现受控组播运营的方法 - Google Patents

Abstract

本发明公开了一种网络电视实现受控组播运营的方法，针对现有网络电视组播无法受控且不能实现QoS、各厂商设备使用私有协议的问题，本发明方法如下：用户发起接收组播请求；管理系统将请求转发到宽带接入服务器；宽带接入服务器接收所述请求后，向组播控制服务器发送请求以获得所述用户的配置信息；组播控制服务器将所述用户的配置信息和QoS属性表发送给宽带接入服务器；宽带接入服务器判断用户是否具有接收组播的权限，如果有则开始向用户发送组播，如果没有则返回用户错误信息，步骤结束。上述所有策略信息都是通过COPS协议传输。本发明提出的方法能够控制组播，使现有网络中的不同厂家的网络设备能够互相配合，能够在与用户通信的网络全路径中实现QoS。

Description

网络电视实现受控组播运营的方法

技术领域

本发明涉及一种网络电视实现受控组播运营的方法。

背景技术

网络电视(Internet Protocol Television，IPTV)是利用宽带网络为用户提供交互式多媒体服务的一种业务。IPTV是互联网与传统电视相互融合的结果，视频流经过高效的压缩编码后被广播到IP网络上，通过位于宽带网络边缘的IP电视头端设备把直播电视、按需视频和个人录像等IPTV服务传送给用户。用户可以通过“IP机顶盒+电视”或个人电脑两种方式使用IPTV业务。IPTV的主要特点在于其交互性和实时性。IPTV既不同于传统的有线电视，也不同于目前正在兴起的数字电视。通过IPTV业务，用户可以得到高质量(接近DVD水平的)数字媒体服务，可以自由选择宽带IP网的视频节目，实现媒体提供者和媒体消费者的实质性互动。服务提供商如果要实现可运营的IPTV业务，必须对IPTV业务有所控制。而对IPTV业务的控制，包括对用户点播业务进行控制，以及对实时业务例如股票行情、电视直播等进行控制。组播技术是实现实时业务中的重要技术，服务器端使用组播技术将内容传递给用户，对实时业务进行控制，就体现在对用户组播数据流的控制。现有的组播技术中，存在着以下问题：

1、不进行控制：组播技术从一开始就是一个非赢利性的技术，从技术本身并没有提供多少控制机制。在局域网上的任何客户都能接收组播数据流，目前在网运行的大部分路由器也是这样，无条件转发、复制数据流、应答用户的IGMP(InternetGroup Management Protocol，组管理协议)请求，这种情况不利于IPTV开展有偿服务。

2、单独进行控制不进行QoS(Quality of Service，服务质量)：随着组播应用的越来越多，一些厂家网元设备如路由器、BAS(Broadband Access Server，宽带接入服务器)、DSLAM(Digital Subscriber Line Access Multiplexer，数字用户线接入复用器)等开始支持受控组播，但由于组播业务高吞吐量、低时延的特性，如果组播业务不支持，往往不能保证IPTV业务质量。

3、控制使用私有协议，不利于扩展：由于组播业务的非常多，对网元设备的组播权限往往通过动态协议来配置，不少厂家使用私有协议，在自己的网元设备之间实现数据交换。但目前的电信宽带网络上，往往是多个厂家的设备配合实现业务。使用私有协议大大限制了开设IPTV业务。

发明内容

针对现有技术中的问题和不足，本发明的目的是提出一种网络电视实现受控组播运营的方法，使网络电视能够实现组播受控运营，同时能够实现通过公有协议通信并实现QoS。

为了解决上述问题一种网络电视实现受控组播运营的方法，该方法包括以下步骤：

(1)用户向管理系统发起接收组播请求；

(2)管理系统将所述接收组播请求转发到宽带接入服务器；

(3)宽带接入服务器接收到所述接收组播请求后，向组播控制服务器发送请求，请求获得所述用户的配置信息；

(4)组播控制服务器将所述用户的配置信息发送给宽带接入服务器；

(5)宽带接入服务器根据接收到的所述的用户配置信息，判断用户是否具有接收组播的权限，如果有则开始向用户发送组播，如果没有则返回用户错误信息，步骤结束。

其中，所述步骤(2)具体为：

①管理系统将所述接收组播请求转发到计费服务器；

②计费服务器对所述用户进行认证，如果通过则进入步骤③，如果未通过则返回用户错误信息，步骤结束；

③计费服务器将所述接收组播请求转发到宽带接入服务器。

其中，该方法还包括以下步骤：

组播控制服务器根据用户配置信息，将对应的QoS属性表发送到宽带接入服务器，并将所述QoS属性表发送给与所述宽带接入服务器与所述用户连接的网络路径中的所有网络设备。

其中，所述组播控制服务器发送的QoS属性表为COPS协议报文格式，COPS：Common Open Policy Service，是一个基于状态查询响应机制的加密协议，用于策略服务器与设备间交换策略信息，可确保安全、可靠地分发策略。

其中，所述步骤(3)中，宽带接入服务器向组播控制服务器发送的所述请求为COPS协议报文格式。

其中，所述步骤(4)中，所述组播控制服务器向宽带接入服务器发送的用户的配置信息为COPS协议报文格式。

其中，所述步骤(4)中所述的配置信息包括用户名、用户的组播权限表、带宽信息。

其中，所述步骤(5)具体为：

(I)宽带接入服务器接收到所述用户配置信息，根据所述配置信息中的用户名，更新所述用户名的配置信息表；

(II)宽带接入服务器读取配置信息表，判断用户是否具有接收组播的权限，如果有则如果有则开始向用户发送组播，如果没有则返回用户错误信息，步骤结束。

其中，该方法还包括以下步骤：

(I)用户向管理系统发起注册请求；

(II)管理系统根据所述用户的注册请求，为用户进行注册操作；

(III)注册成功后，管理系统将所述用户的注册信息发送到组播控制服务器及计费服务器。

本发明提出的网络电视实现受控组播运营的方法能够有效的控制组播，实现网络电视的受控运营；同时网络设备之间传输的策略信息是通过公有协议，使现有网络中的不同厂家的网络设备能够互相配合，不需要进行网络改造；同时能够在与用户通信的网络全路径中实现QoS，提高了网络电视的业务质量。

附图说明

图1是本发明的网络拓扑图。

具体实施方式

下面结合附图对本发明作进一步的详细描述。

如图1所示，一般的城域网都采用以上拓扑结构。虚线左侧是数据平面，采用树形拓扑实现用户的上网。虚线右侧是管理平面，包括有组播控制服务器、计费服务器RADIUS、以及管理系统。管理平面通过一定的控制信令实现对数据平面的管理。

用户在使用网络电视之前，需要先在管理系统进行注册，具体步骤如下：

1、用户向管理系统发起注册请求；

2、管理系统根据所述用户的注册请求，为用户进行注册操作；

3、注册成功后，管理系统将所述用户的注册信息发送到组播控制服务器及计费服务器；

注册成功后，用户就可以通过发起请求来接收网络电视，具体步骤如下：

(1)用户向管理系统发起接收组播请求；

(2)管理系统将所述接收组播请求转发到计费服务器；

(3)计费服务器对所述用户进行认证，如果通过则进入步骤(4)，如果未通过则返回用户错误信息，步骤结束；

(4)计费服务器将所述接收组播请求转发到宽带接入服务器；

(5)宽带接入服务器接收到所述接收组播请求后，向组播控制服务器发送请求，请求获得所述用户的配置信息，所述请求是使用COPS协议报文格式发送；

(6)组播控制服务器将所述用户的配置信息使用COPS协议报文格式发送给宽带接入服务器，所述用户配置信息包括用户名、用户的组播权限表、带宽信息；

(7)组播控制服务器根据步骤(5)所述请求中的用户名，将所述用户名对应的QoS属性表发送到宽带接入服务器，并将所述QoS属性表发送给与所述宽带接入服务器与所述用户连接的网络路径中的所有网络设备，使用COPS协议报文格式发送；

(8)宽带接入服务器接收到所述用户配置信息及QoS属性表，根据所述配置信息中的用户名，更新所述用户名的配置信息表和QoS属性表；

(9)宽带接入服务器读取配置信息表，判断用户是否具有接收组播的权限，如果有则如果有则开始向用户发送组播，如果没有则返回用户错误信息，步骤结束。

COPS协议报文格式为：COPS报文头+对象(object)

COPS报文头格式：

0                       1                          2                       3

Version	Flags	Op code	Client-type
				Message Length

Version(4bits)：当前版本号1(16进制数)；

Flags(4bits)：当一个消息是被其它的COPS消息请求的消息时，Flags＝1，其它都为0；

Op code(8bits)：识别COPS的操作：

1＝Request(REQ)；2＝Decision(DEC)；3＝Report State(RPT)；

4＝Delete Request State(DRQ)；5＝Synchronize State Req(SSQ)；

6＝Client-Open(OPN)；7＝Client-Accept(CAT)；8＝Client-Close(CC)；

9＝Keep-Alive(KA)；10＝Synchronize Complete(SSC)

Client-type(16bits)：为区分不同的client(路由器)，消息中必须有客户类型。

Message Length(32bits)：COPS的总长度(8位组的个数)，包括头长度和对象的长度。

对象(object)格式：

   0                            1               2                           3

Length	S-Num	S-Type
			A number of typed objects(object contents)

Length(16bits)：对象的长度(8位组的个数)，包括32位的对象头和对象内容；

S-Num(8bits)：说明对象的目的；

              2＝Context              (REQ)

              6＝Decision             (DEC)

              10＝Keep-Alive Timer    (KA)

              12＝Report Type         (RPT)

S-Type(8bits)：描述对象的编码方法，RFC文档中使用的是BER(BASic EncodeingRules)，S-Type＝1；本实施例中没用到BER，所以设置S-Type＝0

如果对象内容不是32位的整数倍，要用0填充，便于计算下一个对象的边界。不同消息的对象内容：

1.REQ

Context Object(Context)是REQ消息用到的object。

标志位设置：

          S-Num＝2，S-Type＝0

Object的内容：

  0                          1                  2                     3

R-Type

未用

R-Type(Request Type Flag)

0x01＝Incoming-Message/Admission Control request

0x02＝Resource-Allocation request

0x04＝Outgoing-Message request

0x08＝Configuration request

2.DEC

Decision Object(Decision)是DEC消息用到的object。

标志位设置：

如果此DEC是被请求的消息，则COPS消息头中的Flags＝1；

        S-Num＝6，S-Type＝1

Object的内容：

  0                         1                       2                    3

Command Code	Protocol type	未用
			用户自定义内容

Commands：

         Command Code＝0：NULL Decision(No configuration data available)

         Command Code＝1：Install(Admit request/Install configuration)

         Command Code＝2：Remove(Remove request/Remove configuration)

用户自定义内容采用便于扩展的AVP(Attribute Value Pair)的形式。主要结构为：

  0                 1                          2                     3

Attribute Type	Length
		用户自定义内容(直到Length长度)

在Decision Object消息中，必须定义的字段包括：

对象名	Attribute Type	长度
			用户名(username@domain形式)	1	取决于用户名
允许访问组播列表	2	取决于组播IP地址个数。

可选字段：

对象名	Attribute Type	长度
			QOS profile number	3	8

QOS profile number必须与BAS配置的QOS profile号相对应。

3.RPT

Report-Type Object(Report-Type)是RPT消息用到的object。

标志位设置：

如果此RPT是DEC的确认消息，则COPS消息头中的Flags＝1，

若是向BB汇报出错信息，则Flags＝0；

S-Num＝12，S-Type＝0

Object的内容：

  0                      1                           2                    3

Report-Type	(未定义)
		出错信息

Report-Type：

1＝Success   ：Decision was successful at the PEP

2＝Failufe   ：Decision could not be completed by PEP

3＝Accounting：向BB汇报出错信息。

Claims (9)

1、一种网络电视实现受控组播运营的方法，其特征在于，该方法包括以下步骤：

(1)用户向管理系统发起接收组播请求；

(2)管理系统将所述接收组播请求转发到宽带接入服务器；

(3)宽带接入服务器接收到所述接收组播请求后，向组播控制服务器发起请求，请求获得所述用户的配置信息；

(4)组播控制服务器将所述用户的配置信息发送给宽带接入服务器；

(5)宽带接入服务器根据接收到的所述的用户配置信息，判断用户是否具有接收组播的权限，如果有则开始向用户发送组播，如果没有则返回用户错误信息，步骤结束。

2、根据权利要求1所述的网络电视实现受控组播运营的方法，其特征在于，所述步骤(2)具体为：

①管理系统将所述接收组播请求转发到计费服务器；

②计费服务器对所述用户进行认证，如果通过则进入步骤③，如果未通过则返回用户错误信息，步骤结束；

③计费服务器将所述接收组播请求转发到宽带接入服务器。

3、根据权利要求1或2所述的网络电视实现受控组播运营的方法，其特征在于，该方法还包括以下步骤：

组播控制服务器根据用户配置信息，将对应的QoS属性表发送到宽带接入服务器，并将所述QoS属性表发送给与所述宽带接入服务器与所述用户连接的网络路径中的所有网络设备。

4、根据权利要求3所述的网络电视实现受控组播运营的方法，其特征在于，所述组播控制服务器发送的QoS属性表为COPS协议报文报文格式。

5、根据权利要求4所述的网络电视实现受控组播运营的方法，其特征在于，所述步骤(3)中，宽带接入服务器向组播控制服务器发送的所述请求为COPS协议报文格式。

6、根据权利要求5所述的网络电视实现受控组播运营的方法，其特征在于，步骤(4)中，所述组播控制服务器向宽带接入服务器发送的用户的配置信息为COPS协议报文格式。

7、根据权利要求6所述的网络电视实现受控组播运营的方法，其特征在于，步骤(4)中所述的配置信息包括用户名、用户的组播权限表、带宽信息。

8、根据权利要求7所述的网络电视实现受控组播运营的方法，其特征在于，步骤(5)具体为：

(I)宽带接入服务器接收到所述用户配置信息，根据所述配置信息中的用户名，更新所述用户名对应的配置信息表；

(II)宽带接入服务器读取用户的配置信息表，判断用户是否具有接收组播的权限，如果有则如果有则开始向用户发送组播，如果没有则返回用户错误信息，步骤结束。

9、根据权利要求1或8所述的网络电视实现受控组播运营的方法，其特征在于，该方法还包括以下步骤：

(I)用户向管理系统发起注册请求；

(II)管理系统根据所述用户的注册请求，为用户进行注册操作；

(III)注册成功后，管理系统将所述用户的注册信息发送到组播控制服务器及计费服务器。