CN110431807B - Iptv业务质量检测的方法、装置及系统 - Google Patents

Abstract

本发明涉及通信技术领域，尤其涉及一种IPTV业务质量检测技术。在一种IPTV业务质量检测的方法中，SDN控制器从第一网络设备接收视频源标识和携带所述视频源标识的数据包流的QoS参数信息。当SDN控制器发现所述QoS参数超过预设的阈值时，发送检测请求消息给IPTV业务数据流的转发路径上的至少一个第二网络设备。收到所述至少一个第二网络设备返回的检测结果后，SDN控制器根据结果确定引起QoS参数超过预设的阈值的网络设备。通过本申请提供的方案，可以自动地发起IPTV业务的质量检测，有效地压缩检测周期，并且无需人工参与，从而有效地降低了检测的运维成本。

Description

IPTV业务质量检测的方法、装置及系统

技术领域

本发明涉及通信技术领域，尤其涉及一种质量检测的方法、装置及系统。

背景技术

随着宽带网络的普及，因特网协议电视(Internet Protocol Television，简称IPTV)业务也越来越普遍。IPTV业务泛指服务提供商借助网际协议(Internet Protocol，简称IP)做为基础协议的网络设备，向其用户分发视频多媒体资源的一类电视业务。IPTV业务包括视频直播，视频点播以及时间移位的多媒体播放(time-shifted media)等多种类型，可通过因特网或运营商自建网络或者两者混合等多种方式发放视频多媒体资源。这类业务很好地适应了当今网络飞速发展的趋势，充分有效地利用网络资源。

IPTV业务的分发网络比较复杂，如图1所示，多媒体视频源存储在IPTV服务提供商的一个或者多个视频源服务器中，被封装成数据包流后，要经过IP核心网、宽带接入网和用户家庭网络等多个环节才能最终达到用户终端，例如：机顶盒(Set Top Box，简称STB)，从而最终在屏幕上显示。这些网络设备和链路都有可能对视频源的数据包流造成损伤，导致用户观看IPTV节目时出现花屏、卡屏，甚至是黑屏等现象，严重地影响了IPTV用户的体验质量。

当前用户在观看IPTV节目发现业务质量问题时，通过人工上报给其服务提供商，然后由服务提供商委派维护人员到现场(例如用户家中，又如接入设备放置地点)，进行对应的视频业务的质量检测，从而找出引起该IPTV业务质量恶化的故障设备。这种方法检测周期长，而且需要人工排障，引入的维护成本高。

因此，需要一种IPTV业务质量检测的方案，在实现快速检测的同时能够降低运维成本。

发明内容

本文描述了因特网协议电视IPTV业务质量检测的方法、装置和系统，以实现快速检测并降低检测引入的运维成本。

第一方面，本发明的实施例提供一种IPTV业务质量检测的方法，该方法包括：

发送第一请求消息给至少一个第一网络设备，所述第一请求消息包含QoS参数劣化的数据包流所携带的视频源标识，所述视频源标识用于指示所述QoS参数劣化的数据包流所对应的IPTV视频源；所述至少一个第一网络设备为转发携带所述视频源标识的数据包流的路径上的设备；

从所述至少一个第一网络设备针对接收携带所述视频源标识的数据包流的QoS参数检测的检测结果；

根据所述检测结果，确定故障的网络设备。

当发现质量问题时自主发起QoS参数检测请求，无需人为参与，有效地降低了检测周期并降低了维护成本。

在一种可能的设计中，所述第一请求消息为第一检测请求消息，用于请求对携带所述第一请求消息包含的视频源标识的数据包流进行QoS参数检测。在另一种可能的设计中，所述第一请求消息为请求更新消息，用于请求对携带所述第一请求消息包含的视频源标识的数据包流进行QoS检测参数的刷新。

在一种可能的设计中，所述第一请求消息还包括检测类型；所述检测类型指示待检测的QoS参数，所述QoS参数包括时延、时延抖动、丢包个数、丢包时间间隔、乱序包个数和业务带宽的一种或多种。这样可以实现对具体检测参数进行精细化控制，更有利于快速高效检测出故障的网络设备。

在一种可能的设计中，所述第一请求消息还包括检测步长和检测时长，所述检测步长指示多次QoS参数收集中相邻两次QoS参数收集的间隔，所述检测时长指示所述多次QoS参数收集的长度值。具体地，所述间隔和长度值可以是以时间为纬度的，即时间间隔和时间长度值；还可以是以数据包个数作为衡量纬度。这样可以实现对具体检测参数进行精细化控制，更有利于快速高效检测出故障的网络设备。

在一种可能的设计中，所述视频源标识包括视频源服务器IP地址和TCP/UDP端口地址，结合上述方法能实现单播IPTV业务的QoS参数检测。

在一种可能的设计中，所述视频源标识包括视频源服务器IP地址和组播组IP地址，结合上述方法能实现组播IPTV业务的QoS参数检测。

在一种可能的设计中，所述方法还包括，在发送第一请求消息之前，定期地从第二网络设备接收数据包流的QoS参数信息，并判断所述QoS参数是否超过预设的阈值，其中，所述第一网络设备位于所述第二网络设备和所述视频源服务器之间。第二网络设备(有时也可以称为监测网络设备)仅进行参数监测和上报，简化了网络设备的设计，体现了软件定义网络(Software Defined Networking，简称SDN)的设计原则。

在另一种可能的设计中，所述方法还包括，在发送第一请求消息之前，接收第二请求消息，所述第二请求消息用于指示QoS参数检测。监测网络设备进行QoS参数的监测和是否进行QoS参数检测的判断动作，仅在需要进行QoS参数检测时才发送消息，节约了检测开销。

在一种可能的设计中，所述第一请求消息还包括起始检测序列号，用于指示待检测的数据包流的序列号必须大于所述起始序列号。

在一种可能的设计中，所述方法还包括，维护一个“当前检测信息表”，用于包含当前正在进行的视频源检测信息，所述当前检测信息表包含所述第一请求消息中的参数。

在一种可能的设计中，当判断所述QoS参数超过预设的阈值，并判断当前没有针对携带所述视频源的数据包流进行检测时，所述第一请求消息用于指示进行QoS参数检测。判断是否需要进行检测可以通过查找其“当前检测信息表”的表项，看是否可以找到跟所述收到的检测请求消息中所指示的视频源信息相同的表项。这么做的好处是仅在判断当前没有针对指定的视频源进行检测时才执行检测，能够减少重复的检测，从而节约网络资源。

在一种可能的设计中，所述第一请求消息还包括一个刷新指示位，所述刷新指示位用于指示对QoS参数检测的检测类型、检测时长和检测步长的一个或者多个参数进行刷新。这么做的好处是避免了重复的质量检测，提高了网络资源利用率。所述第一网络设备收到所述第一请求消息后，需要根据所述第一消息中指定的新的检测参数(即检测类型、检测时长和检测步长的一个或者多个)进行检测。

在一种可能的设计中，所述方法还包括，发送停止检测请求消息给至少一个第一网络设备，用于指示停止检测，所述停止检测请求消息包含视频源标识。该网络设备收到该消息后，停止针对所述视频源标识对应的数据流的检测。这么做能够进一步减少不必要的检测，提高了网络资源利用率。

在一种可能的设计中，所述方法中的信息交互使用的协议是OPENFOW协议。重用现有协议来实现质量检测的设备交互流程，可以降低网络的维护成本。

第二方面，本发明的实施例提供一种IPTV业务质量检测的方法，该方法包括：

接收检测请求消息，所述检测请求消息包含QoS参数劣化的数据包流所携带的视频源标识，所述视频源标识用于指示所述QoS参数劣化的数据包流所对应的IPTV视频源；

根据预先设定的检测步长和检测时长，对携带所述视频源标识的数据包流进行QoS参数检测和收集，所述检测步长指示多次QoS参数收集中相邻两次QoS参数收集的间隔，所述检测时长指示所述多次QoS参数收集的长度值；具体地，所述间隔和长度值可以是以时间为纬度的，即时间间隔和时间长度值；还可以是以数据包个数作为衡量纬度；

发送所述QoS参数检测的检测结果。

当发现质量问题时才发起检测请求，请求相应的网络设备进行QoS参数的检测，无需人为参与，有效地降低了检测周期并降低了检测所引入的维护成本。

在一种可能的设计中，所述检测请求消息由网络设备接收，所述方法还包括，转发所述检测请求消息给另一个网络设备，其中所述另一个网络设备为所述网络设备在转发所述数据包流的路径上的上游网络设备。这么做是让检测请求消息传递到待检测序列里的所有设备，使其执行QoS参数检测并获得对应的质量检测结果，有助于确定故障的网络设备。其中，所述待检测序列为需要执行QoS参数检测的设备序列集合。

在一种可能的设计中，网络设备之间的信息交互使用的协议是因特网组管理协议(Internet Group Management Protocol，简称IGMP)，或协议无关组播协议(Protocol-Independent Multicast，简称PIM)，或组播侦听器发现协议(Multicast ListenerDiscovery，简称MLD)协议。重用现有协议来实现质量检测的设备交互流程，可以降低网络的维护成本。

在一种可能设计中，所述检测请求消息还包括所述检测步长和所述检测时长。这样可以实现对具体检测参数进行精细化控制，更有利于快速高效检测出故障设备。

在一种可能设计中，所述检测请求消息还包括检测类型；所述检测类型指示待检测的QoS参数，所述QoS参数包括时延、时延抖动、丢包个数、丢包时间间隔、乱序包个数和业务带宽的一种或多种。这样可以实现对具体检测参数进行精细化控制，更有利于快速高效检测出故障的网络设备。

在一种可能的设计中，所述视频源标识包括视频源服务器IP地址和TCP/UDP端口号，结合上述的方法能实现对单播IPTV业务的QoS参数检测。

在一种可能的设计中，所述视频源标识包括视频源服务器IP地址和组播组IP地址，结合上述的方法能实现对组播IPTV业务的QoS参数检测。

在一种可能的设计中，所述方法还包括，接收停止检测请求消息所述停止检测请求消息包含视频源标识。收到所述停止检测消息后，停止针对所述视频源标识对应的数据流的检测。这么做能够进一步减少不必要的检测，提高了网络资源利用率。

第三方面，本发明实施例提供一种IPTV业务质量检测的方法，该所述方法包括：

监测至少一个携带视频源标识的数据包流的服务质量QoS参数，其中所述视频源标识用于识别一个IPTV视频源；

判断所述QoS参数超过预设的阈值时，生成检测请求消息，所述检测请求消息包含QoS参数劣化的数据包流所携带的视频源标识；

发送所述检测请求消息，用于请求对携带所述检测请求消息包含的视频源标识的数据包流进行QoS参数检测。

当发现质量问题时才发起检测，无需人为参与，有效地降低了检测周期并降低了检测所引入的维护成本。

在一种可能的设计中，所述检测请求消息还包括检测步长和检测时长，所述检测步长指示多次QoS参数收集中相邻两次QoS参数收集的间隔，所述检测时长指示所述多次QoS参数收集的长度值。具体地，所述间隔和长度值可以是以时间为纬度的，即时间间隔和时间长度值；还可以是以数据包个数作为衡量纬度。这样可以实现对具体检测参数进行精细化控制，更有利于快速高效检测出故障设备。

在一种可能的设计中，所述检测请求消息还包括检测类型，所述检测类型指示待检测的QoS参数，所述QoS参数包括时延、时延抖动、丢包个数、丢包时间间隔、乱序包个数和业务带宽的一种或多种。这样可以实现对具体检测参数进行精细化控制，更有利于快速高效检测出故障设备。

在一种可能的设计中，所述视频源标识包括视频源服务器IP地址和TCP/UDP端口号，结合上述方法能实现对单播IPTV业务的QoS参数检测。

在一种可能的设计中，所述视频源标识包括视频源服务器IP地址和组播组IP地址，结合上述方法能实现对组播IPTV业务的QoS参数检测。

第四方面，本发明实施例提供了一种控制器，该控制器具有实现上述第一方面描述的方法的行为的功能。

在一种可能的设计中，该控制器包括发送模块、接收模块和处理模块，其中：

所述发送模块，用于发送第一请求消息给至少一个第一网络设备，所述第一请求消息包含QoS参数劣化的数据包流所携带的视频源标识，所述视频源标识用于指示所述QoS参数劣化的数据包流所对应的IPTV视频源；所述至少一个第一网络设备为转发携带所述视频源标识的数据包流的路径上的设备；

所述接收模块，用于从所述至少一个第一网络设备接收携带所述视频源标识的数据包流的QoS参数检测结果；

所述处理模块，用于根据所述检测结果，确定故障的网络设备。

第五方面，本发明实施例提供一种网络设备，该网络设备具有实现上述第二方面描述的方法的行为的功能。

在一种可能的设计中，该网络设备包括其包括接收模块、处理模块和发送模块，其中：

所述接收模块，用于接收检测请求消息，所述检测请求消息包含QoS参数劣化的数据包流所携带的视频源标识，所述视频源标识用于指示所述QoS参数劣化的数据包流所对应的IPTV视频源；

所述处理模块，用于根据预先设定的检测步长和检测时长，对携带所述视频源标识的数据包流进行QoS参数检测和收集，所述检测步长指示多次QoS参数收集中相邻两次QoS参数收集的时间间隔，所述检测时长指示所述多次QoS参数收集的时间长度值；

所述发送模块，用于发送所述QoS参数检测的检测结果。

在一种可能的设计中，所述发送模块，还用于转发所述的检测请求消息给另一个网络设备，其中所述另一个网络设备为所述网络设备在转发所述数据包流的路径上的上游网络设备。

第六方面，本发明的实施例提供又一种网络设备，该网络设备具有实现上述第三方面描述的方法的行为的功能。

在一种可能的设计中，该网络设备包括处理模块和发送模块，其中：

所述处理模块，用于监测至少一个携带视频源标识的数据包流的服务质量QoS参数，其中所述视频源标识用于识别一个IPTV视频源；可选地，所述处理模块还用于判断所述QoS参数是否超过预设的阈值。当判断所述的QoS参数超过预设的阈值时，生成检测请求消息，所述检测请求消息包含QoS参数劣化的数据包流所携带的视频源标识；

所述发送模块，用于发送消息。在一种可能的设计中，所述发送模块发送的消息包含至少一个携带视频源标识的数据包流的服务质量QoS参数。在又一种可能的设计中，所述发送模块发送的消息为检测请求消息，所述检测请求消息用于请求对携带所述检测请求消息包含的视频源标识的数据包流进行QoS参数检测。

需要说明的是上述三个方面中描述的装置里的发送模块、接收模块和处理模块也可以替换为发送器、接收器和处理器。

第七方面，本发明实施例提供一种分布式的质量检测系统，其包括第一网络设备和第二网络设备。其中：

所述第一网络设备，用于监测至少一个携带视频源标识的数据包流的服务质量QoS参数，其中所述视频源标识用于识别一个IPTV视频源；判断所述QoS参数超过预设的阈值时，生成检测请求消息，所述检测请求消息包含QoS参数劣化的数据包流所携带的视频源标识；发送所述检测请求消息给其上游的第二网络设备，请求其对携带所述检测请求消息包含的视频源标识的数据包流进行QoS参数检测。可选地，所述第一网络设备还可以发送其QoS参数信息。

所述第二网络设备，用于接收所述第一网络设备发送的检测请求消息；执行对所述视频源标识指示的数据流的质量参数检测，并发送所述QoS参数检测的检测结果。可选地，所述第二网络设备还转发所述检测请求消息给其上游的另一个第二网络设备，所述另一个第二网络设备执行所述第二网络设备相同的操作。

在一种可能的设计中，所述分布式的质量检测系统还包括检测中心，所述检测中心，用于接收所述第二网络设备发送的检测结果。可选地，所述检测中心还可以用于接收所述第一网络设备发送的检测QoS参数信息。所述检测中心还用于在收到检测结果后，确定故障的网络设备。

第八方面，本发明实施例提供一种集中式的质量检测系统，其包括第一网络设备和第二网络设备。其中：

所述第一网络设备，用于监测至少一个携带视频源标识的数据包流的服务质量QoS参数，其中所述视频源标识用于识别一个IPTV视频源；发送第一消息给控制器。

在一种可能的设计中，所述第一消息为所述QoS参数信息。在另一种可能的设计中，所述第一消息为所述第一网络设备判断所述QoS参数超过阈值时，发送的第一检测请求消息，所述第一检测请求消息包含QoS劣化的数据包流所携带的视频源标识，用于请求控制器发起对包含所述检测请求消息中包含的视频源标识的数据包流进行QoS参数检测。

所述第二网络设备，为转发携带所述视频源标识的数据包流的转发路径上的至少一个设备，用于从所述控制器接收第二检测请求消息后，对相应的数据包流进行QoS参数检测和收集；发送QoS参数检测的结果给所述控制器。

在一种可能的设计中，所述系统还包括所述控制器，所述控制器用于发送第二检测请求消息给至少一个第二网络设备，所述的第二检测请求消息包含QoS参数劣化的数据包流所携带的视频源标识，所述视频源标识用于指示所述QoS参数劣化的数据包流所对应的IPTV视频源；从所述至少一个第二网络设备接收携带所述视频源标识的所述QoS参数劣化的数据包流的QoS参数检测结果；根据所述检测结果，确定故障的网络设备。

第九方面，本发明实施例提供一种计算机存储介质，用于存储为上述监测网络设备(或第一网络设备)所用的计算机软件指令，其包含用于执行上述方面所设计的程序。

第十方面，本发明实施例提供了一种计算机存储介质，用于存储为上述第二网络设备所用的计算机软件指令，其包含用于执行上述方面所设计的程序。

第十一方面，本发明实施例提供了一种计算机存储介质，用于存储为上述控制器所用的计算机软件指令，其包含用于执行上述方面所设计的程序。

相较于现有技术，本发明提供的方案可以通过监测IPTV业务视频源的数据流对应的QoS参数，并在发现质量问题时，请求转发视频源数据包流的网络设备进行质量检测，该方案有助于通过质量检测分析出故障设备，能够实现快速检测并能够降低运维成本。

附图说明

下面将参照所示附图对本发明实施例进行更详细的描述：

图1是本发明的一种可能的应用场景示意图；

图2是本发明实施例适用的一种可能的网络示意图；

图3是RTP协议的报文头示意图；

图4是本发明实施例提供的一种IPTV业务质量检测的方法流程图；

图5是本发明实施例提供的一种可能的网络设备的处理流程图；

图6是本发明实施例提供的又一种IPTV业务质量检测的方法流程图；

图7为本发明实施例提供的一种可能的控制器的处理流程图；

图8为本发明实施例提供的一种网络设备结构示意图；

图9为本发明实施例提供的一种控制器结构示意图；

图10为本发明实施例提供的另一种网络设备结构示意图；

图11为本发明实施例提供的一种检测中心结构示意图。

具体实施方式

本发明实施例描述的网络系统以及业务场景是为了更加清楚地说明本发明实施例的技术方案，并不构成对于本发明实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本发明实施例提供的技术方案对于类似的技术问题，同样适用。

如图1所示，一个或多个IPTV视频资源存储在一个或者多个存储服务器上，被封装成多个数据包(后续简称数据包流)后，通过用户家庭网络，接入网和IP核心网等网络的网络设备进行分发，从而能够为用户提供不同的IPTV节目。其中，所述的用户家庭网络，接入网和IP核心网里的相关设备组成了IPTV业务分发系统。本发明的方案可以适用于IPTV业务分发系统，并且不对具体IP业务分发系统包含的网络类型做任何限制。

图2给出了一个本发明实施例适用的一种可能的网络示意图，包括机顶盒(SetTop Box，简称STB)，无源光网络(Passive Optical Network，简称PON)的接入网设备，IP核心网的路由器设备以及多个多媒体视频源服务器。其中，PON包括光网络单元设备(OpticalNetwork Unit，简称ONU)和光线路终端(Optical Line Terminal，简称OLT)等设备。需要说明的是，接入网也可以是各种类型的数字用户线路(x Digital Subscriber Line，x＝A，V，S等)网络。本申请中，使用PON作为接入网络的例子，但是本发明对于实际使用的接入网络和其设备类型不做任何限制。

由转发一个IPTV节目视频源对应的数据包流的所有网络设备组成的有序序列简称为该ITPV节目的转发路径。转发路径上的设备构成了上下游关系。其中，接收数据包流的网络设备为发送该数据包的网络设备的下游网络设备；后者为前者的上游网络设备。例如，图2中，路由器1，路由器2，路由器5，OLT1，ONU1和机顶盒1构成了一个IPTV节目的转发路径；其中，OLT1为ONU1的上游设备，而ONU1为OLT1的下游设备。

IPTV视频源要通过一定的数据封装方式进行封装后，才在网络中进行传输。一种可能的方式是因特网工程任务组(Internet Engineering Task Force，简称IETF)制定的实时传输协议(Real-time Transport Protocol，简称RTP)。RTP协议用于传输音频、视频、模拟数据等实时数据，侧重数据传输的实时性。还有一种可能的方式是超文本传输协议(Hyper Text Transfer Protocol，简称HTTP)。无明确说明，本申请中的所有实施例均使用RTP协议封装格式作为例子，但是对于本发明实际使用的封装格式不做任何限制，仅要求封装的方法能够提供本申请后续提到的服务质量(Quality of Service，简称QoS)参数的检测功能。

IPTV业务分发系统可以采用单播(unicast)或组播(multicast)方式来实现对视频多媒体资源的数据包流进行分发。例如，采用单播的方式实现视频点播IPTV业务的分发，采用组播方式实现视频直播IPTV业务的分发。当采用组播方式时，IPTV业务分发系统中的设备可能使用到因特网组管理协议(Internet Group Management Protocol，简称IGMP)，组播监听器发现(Multicast Listener Discovery，简称MLD)，和/或协议无关组播(Protocol Indepenent Multicast，简称PIM)等协议。其中，IGMP和MLD分别用于针对IPv4网络和IPv6网络的组播组成员关系的管理，而PIM协议用于在一个网络域内建立和维护组播路由信息。当IPTV业务分发系统覆盖了多个网络域时，还需要使用域间组播协议，用于将一个域内的组播源信息传播给其他域的设备。例如，在图2的ONU1和OLT1之间可以使用IGMP协议，而在路由器之间以及路由器5和OLT1之间可以使用PIM协议。具体协议的选择需要根据具体组网和功能需求来选择，本发明不做任何限定。

下面结合图3，对RTP协议的报文头包含的字段进行详细描述：

V(2比特位，2bits)：标明RTP协议的版本号。协议初始版本为0，RFC3550中规定的版本号为2。

P(1bit)：如果该位被设置为1，则在该数据包末尾包含了额外的附加信息。附加信息的最后一个字节表示额外附加信息的长度(包含该字节本身)。该字段之所以存在是因为一些加密机制需要固定长度的数据块，或者为了在一个底层协议数据单元中传输多个RTP分组包。

X(1bit)：如果该位被设置为1，则在固定的头部后存在一个扩展头部。

CC(CSRC count，4bits)：指示在固定头部后存在多少个贡献源(ContributingSource，CSRC)标记。

M(1bit)：该位的功能依赖于配置(profile)的定义。profile可以改变该位的长度，但是要保持M字段和PT字段的总长度不变(一共是8bit)。

PT(Payload Type，7bits)：负载类型，标记着RTP包所携带信息的类型。如果接收方不能识别该类型，必须忽略该分组包。

Sequence number(16bits)：序列号，每个RTP分组包发送后该序列号加1，接收方可以根据该序列号重新排列数据包顺序。

Timestamp(32bits)：时间戳，反映RTP分组包所携带信息包中第一个字节的采样时间。

SSRC(Synchronization source)identifier(32bits)：数据源标识。在一个RTP会话期间，每个数据流都应该有一个不同的SSRC。

CSRC identifiers(可以包含0-15个之间任意数量的标识，每个源标识32bits)：贡献源标识，仅存在Mixer的时候才有效。如一个将多声道的语音流合并成一个单声道的语音流，在这里就列出原来每个声道的SSRC。

在IPTV业务分发系统中，视频多媒体资源被封装为RTP数据包流后，要经过多个网络设备，才能最终达到用户终端设备。因为网络设备负载量和具体运行情况在不断变化，导致了RTP数据包在传递的过程中会出现乱序，丢包等诸多问题。从用户的观看体验来看，可能会出现节目质量恶化，比如出现卡屏，花屏，甚至是黑屏等现象。本发明提供的方案中就是针对这种质量问题，提供了一种自动进行质量检测的手段，能够压缩检测周期，并且无需人工参与，从而能够有效地降低运维成本。

下面将基于上面所述的本发明涉及的共性方面，对本发明实施例进一步详细说明。

实施例1

本发明的一个实施例提供了一种IPTV业务质量检测的方法，网络设备，检测中心及系统。所述网络设备中的一个网络设备定期地监测一个或多个IPTV视频源(或者视频源数据包流)的QoS参数；当确定一个IPTV视频源的QoS参数超过预设的阈值时，向其上游的网络设备发送检测请求消息，请求所述的上游的网络设备对相应的数据包流进行QoS参数检测。

所述上游的网络设备收到了所述检测请求消息后，如果判断要进行QoS参数检测时，则执行检测流程，即对所述检测请求消息中指示的数据包序列进行QoS参数检测并收集所述检测请求中指定的参数的检测结果。此外，所述上游的网络设备还要向其上游设备转发所述检测请求，直至所述检测请求消息发送到被配置为待检测序列的最后一个网络设备为止(例如：连接到视频多媒体服务器的网络设备，例如图2中所示的路由器1)。收到所述检测请求的网络设备，在判断要进行业务QoS参数检测后，执行检测流程，即进行所述上游的网络设备的检测动作。当网络设备QoS参数检测完毕后，向检测中心发送检测结果。需要说明的是所述的待检测序列为转发路径的一部分或者全部。例如，在图2中，ONU1-OLT1-路由器5-路由器2-路由器1可以为待检测序列，或者OLT1-路由器5-路由器2可以为待检测序列，其中ONU1和OLT1分别为两个待检测序列示例的负责进行QoS质量参数监测的网络设备。本发明不对待检测序列的选取做任何限定，在实际应用中，可以根据需要或者设备特性来决定实际的待检测序列。

收到检测结果后，检测中心根据检测结果信息确定引起节目质量恶化的网络设备，即故障的网络设备。值得说明的是，引起节目质量劣化的原因可能是从视频源服务器到用户屏幕之间的任意一个转发RTP数据包的网络设备(和/或网络设备的链路)，即该故障的网络设备可能是转发路径上的任一网络设备。为了方便说明，本发明将负责进行QoS监测并在发现问题时能够自主向其他网络设备发起检测请求的网络设备称作监测网络设备，以与其他接收所述的检测请求消息和/或转发此请求消息的网络设备区分开来。有时，为了简单地做区分，也使用第一网络设备和第二网络设备来指代两种不同类型的网络设备，其中所述的第一和第二仅是为了方便描述，并无特殊的其他含义。本质上，所述的监测网络设备也是一种用于转发视频源数据包流的网络设备。

下面结合图4，对本发明的实施例提供的方案进一步说明。

图4为本发明的实施例提供的一种IPTV业务质量检测的流程示意图。

需要说明的是，图4中的第一网络设备，第二网络设备1和第二网络设备2是用于转发某一IPTV业务的数据包流的转发路径上的设备示例。网络设备1和网络设备2构成了一个待检测序列。其中，第二网络设备1为本实施例中的一个可能的待检测序列的起点，而第二网络设备2为该待检测序列的最后一个网络设备。需要说明的是，在实际应用中，所述第二网络设备1和第二网络设备2之间还可以有一个或多个其他第二网络设备。

需要补充说明的是，在一种可能的实现中，待检测序列为某一个转发路径的所有设备集合，至少需要包含一个网络设备。在另一种可能的实现中，待检测序列为该转发路径的部分设备。所述的部分设备为转发路径中的一个连续的设备序列集合。

S401：第一网络设备监测IPTV节目的数据包流的QoS参数，发现检测的QoS参数超过预设的阈值；

S402：第一网络设备发送检测请求消息；

需要说明的是，所述数据包流携带视频源标识。该视频源标识用于唯一标识一个待检测的IPTV节目视频源信息；在单播的IPTV分发系统中，视频源标识信息可以用视频源服务器IP地址和传输控制协议/用户数据报协议(Transmission Control Protocol/UserDatagram Protocol，简称TCP/UDP)端口号来表示；在组播的IPTV分发系统中，视频源标识信息可以用视频源服务器IP地址和组播组IP地址来表示。需要说明的是，其中的IP地址可以是IPv4地址或者IPv6地址。

在一种可能的示例中，第一网络设备被配置为对IPTV节目所对应的数据包流(或者也可以成为数据包序列)的丢包个数进行监测。以RTP协议作为数据封装方式为例，那么就可以通过数据包头的序列号来监测丢包个数。假设预先设定的丢包数目阈值为Nset(L)，当第一网络设备检测到RTP数据包流的实际丢包数目N(L)超过了所述的预先设定的阈值时，即N(L)＞Nset(L)，执行步骤S402，即发送检测请求消息给其上游网络设备(即第二网络设备1)。

在另一种可能的示例中，第一网络设备被配置为对IPTV节目所对应的数据包序列的丢包个数和时延进行监测。以RTP协议作为数据封装方式为例，可以通过数据包头的时间戳和收到数据的时间信息来计算时延。假设预先设定的阈值为丢包数目大于10个或时延超过20微秒。当第一网络设备监测到丢包数目大于10个或者时延超过20微秒时，即发现时延或丢包率超过阈值时，执行步骤S402。

需要说明的是，数据包流的QoS参数包括时延、丢包个数(或丢包率)，丢包时间间隔、时延抖动、乱序包个数(或乱序次数)和业务带宽等。例如，采用RTP协议来进行视频源数据封装时，时延、丢包率、丢包时间间隔、时延抖动和乱序包个数可根据RTP数据包报文头里的序列号和/或时间戳等信息计算获得。例如，如果应该收到的数据包流的序列号为1，2，3，4，5，6，7和8，而实际接收到的RTP数据包流的序号为1，3，2，4，5和8，那么可以计算出来当前收到的RTP数据包流的丢包个数为2个，乱序包个数为1个(即乱序一次)。时延可以通过收到包的时间减去收到包里携带的时间戳信息来获得。当监测的QoS参数为业务带宽时，可以设置阈值为预设带宽的倒数，即如果预设带宽为B，那么阈值就设置为1/B，这么做的好处是统一的使用“超过预设的阈值”作为检测的触发条件。实际应用中第一网络设备检测的具体参数和个数，阈值的设定以及具体的检测方法是可以根据需要来自由选择的，本发明不做任何限定。

所述检测请求消息中包含视频源标识、检测类型、检测时长和检测步长。检测类型指示待检测数据流的QoS参数，具体可以包括时延、丢包个数、丢包时间间隔、抖动、乱序个数和节目带宽等参数的一个或者多个。检测时长是指针对待检测数据流要进行QoS参数检测的长度值，可以是时间长度，也可以是以其他维度来衡量的长度值，例如：进行3分钟的QoS参数检测，又如进行10240个数据包的检测。检测步长指的是相邻的两次QoS参数信息收集的间隔，可以是时间间隔，也可以是其他维度(以视频源数据包个数)为衡量的间隔，具体地，例如：每个512个数据包进行一次参数收集。

可选地，如果数据包流是RTP协议封装时，所述检测请求消息还可以携带RTP数据包的起始序列号，用于指示待检测的RTP数据包所携带的最小序列号。当收到的检测请求消息中携带起始序列号时，网络设备在实际检测过程中第一个检测的数据包的序列号不能小于所述的起始序列号。当网络设备收到的检测请求消息中没有携带起始序列号时，网络设备默认该数值为0。可选地，检测请求消息还可以携带发起检测的网络终端的标识，例如其IP地址或者介质接入控制(Media Access Control，简称MAC)地址。这个信息可以有助于负责收集检测结果并确定故障的网络设备的执行主体(例如：本实施例中的检测中心)明确发起主动检测的设备信息，用于整个检测过程的事件记录或者协助确定故障的网络设备。

S403当第二网络设备1判断要检测数据包流的QoS参数时，执行检测流程；

具体地，判断是否需要执行检测流程是通过从收到的检测请求消息解析出视频源标识信息，来判断该网络设备当前是否正在针对该视频源标识信息所标识的视频源进行QoS参数检测。具体地，可以通过网络设备维护一个“当前检测信息表”，来记录该网络设备当前正在进行的视频源检测信息，或者是通过一个其他方式来记录当前正在进行的视频源检测，例如：通过一个集中的服务器来记录每个网络设备的当前正在执行的QoS参数检测信息。为方便描述，后续均以网络设备维护“当前检测信息表”为例，但是本发明对具体实现中网络设备如何获取其“当前正在进行的检测”信息不做任何限定。

例如，在本实施例中，当第二网络设备1在其“当前检测信息表”中没有发现跟该解析出的视频源标识信息相对应的表项，则说明该网络设备没有执行针对该数据包流的检测或已检测完毕，从而可以判断要检测该视频源数据流的QoS参数。具体待检测的QoS参数的个数和具体类型以及需要检测的时间长度和步长信息，可以由收到的检测消息中携带的参数来指定。此外，这些参数还可以通过网管系统进行配置的方式配置到网络设备上。在执行检测流程的同时或之后，第二网络设备1需要往其“当前检测信息表”里添加一个表项，记录收到的所述检测请求里的参数信息。具体QoS参数可参看步骤S402中针对检测类型的说明，此处不做赘述。

需要补充说明的是，步骤S403不是一个必选的步骤。网络设备可以配置为收到检测消息后，直接执行监测。

S404第二网络设备1转发检测请求消息；

具体地，第二网络设备1判断需要进行QoS参数检测后，转发收到的所述检测请求消息给其上游的网络设备，如图4中的第二网络设备2。这个转发动作和执行检测流程的动作没有严格的顺序关系，可以同时执行或者按照任意顺序执行。

S405当第二网络设备2判断要检测数据包流的QoS参数时，执行检测；

该步骤具体可参看S403的描述，此处不做赘述。值得说明的是，在本实施例中，第二网络设备2为“待检测序列”的最后一个设备，因此该设备无需再转发收到的检测请求消息。

S406第二网络设备1和第二网络设备2发送检测结果，所述检测结果用于定位故障设备；

具体地，第二网络设备，即第二网络设备1和第二网络设备2，在所有的QoS参数检测完毕后或者完成了一次QoS质量检测后，发送所有的检测结果或者当前这次的检测结果给检测中心。在检测完毕之后或同时，第二网络设备还要将检测完毕的表项从其维护的“当前检测信息表”删除。需要说明的是，第二网络设备也可以通过其他方式来标识某一表项对应的检测已经完毕，例如通过增加一个状态标识符来表明该检测是正在或已经结束。那么，在判断是否正在对某个视频源进行检测时，需要查找状态标示符标识为正在检测的表项，而不是检测所有表项。

S407检测中心定位故障的网络设备；

检测中心根据收到的检测结果来确定引起质量劣化的网络设备。具体地，检测中心可以将收到的检测结果根据所述检测结果中所指定的数据包流所对应的转发路径设备序列来进行排序，来判断是从哪个设备开始出现一个(或者多个)QoS参数恶化，从而确定该设备和/或该设备所直接连接的链路为“问题根源”。所述转发路径信息可以是通过网管配置的方式，也可以是检测中心通过其他方式(例如：从其他管理转发路径的设备或者直接从网络设备中)获取，本发明不做任何限定。

在发现影响客户观看体验的质量问题时，第一网络设备主动发起检测请求，有效地降低了检测周期时间。如果宽带接入网是PON，第一网络设备可以是ONU。第一网络设备还可以是机顶盒(STB)，但是，机顶盒设备为用户家庭网络中的设备，其可控性和可靠性不及IPTV提供商所管辖的设备。因此，无特殊说明，本实施例和后续实施例的描述中都以网络终端是运营商所管辖的设备为例，例如ONU。但是本发明对具体部署时实际能够发起检测请求的设备，即监测网络设备，不做限定，可以是用户家庭网络，宽带接入网或IP核心网的网络设备。此外，本实施例描述的质量检测流程不需要维护人员的干预，能够有效地降低针对业务质量检测的运维成本。

在本发明的实施例中，第一网络设备和第二网络设备，以及第二网络设备之间的检测请求消息的传递可以是基于IGMP协议的消息，还可以是基于MLD协议的消息，还可以是基于PIM协议的消息，或者通过自定义的消息格式。在这里，以图1中第一网络设备为ONU1，网络设备OLT1，路由器5，路由器2和路由器1为待检测序列为例，假定数据包是通过RTP协议封装，下面对检测流程中所涉及的消息做进一步解释。假设该业务IPTV业务分发系统采用的是组播方式，其中，假设ONU1和OLT1之间使用的是ICMP协议，OLT1和路由器5以及路由器之间使用的是PIM协议。

作为一个示例，假设ONU1被配置为检测IPTV节目的RTP数据序列的抖动和丢包个数，当抖动大于30微秒或丢包个数大于15时需要发送检测请求消息。假设，当前ONU1检测到抖动为20微秒，丢包个数为20，那么ONU1需要构造一个检测请求消息，并发送给OLT1。该检测消息可以采用IGMP协议的REPORT消息，或者在该协议中新定义一个消息来传递。在一种可能的实现中，该消息所包含的相关信息格式和取值示例如表1所示：

表1

其中，IP地址示例为IPv4地址；检测类型字段中，每个比特位(bit)表示一种类型的QoS参数，一共可以表示32种不同的QoS参数。Bit位设置为1，表示是需要对该参数进行检测；否则，表示不需要对该参数进行检测。作为一种可能的示例，若将该字段的bit位从最低位到最高位编号为1，...，32，则表示为：

第1比特：丢包个数；

第2比特：乱序个数；

第3比特：时延；

第4比特：时延抖动；

第5比特：业务带宽；

第6-32比特：预留字段，为后续新增QoS参数扩展留用。

具体地，在本实施例中，假设ONU1发送给OLT1的检测请求消息中要求检测的是时延和丢包个数，该字段的具体数值为：00000000 00000000 00000000 00000101。

需要说明的是，如果使用的封装格式不是RTP协议，那么检测步长和检测时长可以通过其他方式来表示，例如按照时间维度来限定。

类似地，OLT1和路由器5以及路由器之间传递的检测请求消息也可以包含如表1所示的参数和格式。不同之处在于，使用的协议是PIM协议，这些信息可以承载在该协议新定义的DetectionRequest(检测请求)消息中，或者是使用现有的消息，如JOIN(加入)消息。其中，DetectionRequest(检测请求)消息通过PIM协议的消息报文头中的Type字段设置为10来表示。

网络设备检测完毕后，可以通过IP协议发送检测结果给检测中心，也可以用简单网络管理协议(Simple network manage Protocol，简称SNMP)，或者自定义的消息格式。作为一个示例，网络设备OLT1上报的检测结果相关参数可以是如表2所示的格式和具体取值示例：

表2

具体地，上报的检测结果里的具体参数个数由检测类型字段里置1的个数，以及检测时长和步长来决定。在本实施例中，检测类型里有两个比特位置1，因此检测结果中包含两个类型的QoS参数数值，具体为丢包个数和时延。检测步长为1024，检测时长为4，那么上报的检测结果里一共要包含2*4＝8个QoS参数数值结果，具体的见表2所示的4组丢包个数和时延数值。需要说明的是，在本实施例中，时延的单位固定为微秒。但是在实际的应用过程中，还可以选取其他的单位。如果请求检测消息的参数中还包括节目带宽，检测结果可以通过统一的单位来表示，或者是增加一个字段来表示带宽的单位，例如：通过4个比特位(bit)来表示单位，其中0001表示bps(比特每秒)，0100表示kbps(千比特每秒)，0100表示Mbps(兆比特每秒)，1000留作为未来扩展用。

表3给出了检测中心收到的一种可能的检测结果(时延单位统一为微秒)：

表3

如表3所示，该检测结果已经对应的转发路径(即“OLT1-R1-R2-R5”)的顺序排列好；从而检测中心可以分析出，R5丢包个数为0，从R2开始丢包个数为20，因此可以确定故障的网络设备为R2。需要补充说明的是，可选地，ONU1，即第一网络设备，也可以将其监测的QoS参数结果发给监测中心，以辅助其准确地判断出故障设备。

除了图4中所示的第二网络设备判断为“要执行检测”的情况，还有可能判断结果为“无需执行检测”的情况。下面将结合图5，主要针对“无需执行检测”的情况，对本发明的实施例做进一步说明。

图5为本发明的实施例给出的一种可能的网络设备的处理流程。

S501收到检测请求消息；

S502判断是否要执行检测；

S503执行检测；将所述检测请求消息加入到“当前检测信息表”中；

S504转发检测请求消息给其上游设备；

S505检测完毕后，发送检测结果，将该检测请求从“当前检测信息表”中删除；

S506判断是否要刷新检测参数；

S507刷新“当前检测信息表”；

需要说明的是步骤S504为一个可选的步骤，当第二网络设备并非待检测序列的最后一个设备时，需要进行该步骤；当第二网络设备为最后一个设备时，无需执行该步骤。

在一种可能的实现中，第二网络设备需要执行步骤S501，S502和S503，S504，S505，该步骤序列是判断为“要执行检测”需要执行的步骤。这些步骤和图4中描述的第二网络设备1执行的步骤类似，具体请参看图4中步骤S402，S403，S404和S406的描述，此处不做赘述。不同之处在于，图4的S403在图5中由S502和S503两步来表示；此外，图4的S402是从检测请求消息的发送方描述，而图5的S501是从检测请求消息的接收方描述，但是检测请求消息的内容没有区别。

在一种可能的实现中，第二网络设备需要执行的步骤S501，S502，S506，S507，S504和S505，该步骤序列为“无需执行检测”但“需要刷新检测参数”要执行的步骤。具体地，当网络设备在其“当前检测信息表”中找到了对应的表项，即包含了视频源标识对应的表项，则表明该网络设备针对这个节目源已经在进行检测，因此无需重复检测。但是，所述网络设备需要进一步提取该检测请求消息中的检测步长，检测类型和检测时长信息，以进一步判断是否需要刷新“当前检测信息表”中的对应表项的相关参数信息。

作为一个具体的示例，假设某一网络设备的“当前检测信息表”包含如下表项：

表4

该网络设备收到的检测请求消息包含的信息如下：

表5

需要说明的是，表4和表5仅给出了一个本实施例中相关的参数，其他不相关参数没有给出。

该网络设备可以判断针对该节目，即针对(视频源服务器IP地址为202.110.110.110，组播组IP地址为224.1.1.22)所标识的节目视频源，已经在进行QoS参数检测，因此无需执行新的检测。但是，该网络设备当前仅检测时延，而接收到的检测请求消息还包含丢包个数，而且检测时长和步长信息跟“当前检测信息表”里对应的表项不一致。

在一种可能的示例中，该网络设备可以刷新检测类型来包含时延和丢包个数，而不更改当前信息检测表中的检测时长和检测步长。在另外一种可能的示例中，该网络设备可以刷新检测步长为两个参数中较小的那个，即刷新检测步长为512。具体如何修改“当前检测信息表”的信息可能是由网络设备上配置的策略和/或其软硬件能力决定的。本发明的例子仅是可能的示例，但是本发明对实际如何刷新“当前信息检测表”里的参数不做任何限定。

在一种可能的实例中，第二网络设备需要执行S501，S502，S506和S505，该步骤序列是判断为“无需执行检测”且“无需刷新检测参数”需要执行的步骤。可以理解，针对收到的检测请求消息，第二网络设备在其“当前检测信息表”发现了跟所述检测请求消息中的待检测视频源标识信息一致的表项。而且，所收到的检测请求消息中指定的具体检测信息(即：检测类型，检测时长和检测步长等信息)，不对当前检测使用的具体参数造成任何影响。从而，第二网络设备无需刷新“当前检测信息表”的相关表项，仅需要执行步骤S505，即在已经执行的相关检测结束时，发送检测结果，并将该执行完毕的检测项从“当前检测信息表”中删除。需要说明的是，第二网络设备也可以在完成一次检测后立刻发送监测结果，而无需等待所有检测完毕后，本发明对具体采用何种方式不做任何限定。

由此可以看出，一个检测请求消息不一定会触发第二网络设备执行QoS参数检测流程，而可能仅会触发其修改已经在进行的检测的检测参数(即刷新检测参数)，甚至是不会触发任何动作(即直接重用另外的检测请求消息触发的检测流程所提供的检测结果)。这么做的好处是避免针对同一节目源信息进行反复的检测，可以提高检测效率，节约网络资源。

需要说明的是，在本实施例中，第一网络设备发送检测请求消息时，可以不包括检测类型、检测步长和检测时长，该参数可以默认在第二网络设备上配置为固定值，例如：在相关的第二网络设备上配置检测类型固定为时延和丢包率，检测步长固定为每隔1024个数据包和检测时长固定为检测4个检测步长。这么做可以简化第一网络设备和第二网络设备，以及第二网络设备之间的交互信息。

需要补充说明的是，在本实施例中，第二网络设备可以不执行图5的S502步骤，即针对每一个收到的检测请求消息都执行检测，这么做可能会消耗网络设备的有限资源，但是可以简化网络设备的处理流程。本发明对第二网络设备是否需要执行判断流程不做任何限定。

实施例2

本发明的一个实施例提供了又一种ITPV业务质量检测的方法，网络设备，软件定义网络(Software defined networking，SDN)控制器及系统。所述网络设备中的第一网络设备监测一个或多个IPTV视频源所对应的数据包流的QoS参数，并周期性地向所述SDN控制器上报检测到的QoS参数信息。

所述SDN控制器收到了所述的QoS参数信息后，当确定所述QoS参数达不到预设的阈值时，进一步判断要否进行QoS参数检测。当判断需要进行QoS参数检测时，发送第一检测请求消息给对应数据包流的转发路径上的待检测序列里包含的第二网络设备。需要说明的是待检测序列还可能包含第一网络设备。所述第二网络设备收到所述第一检测请求消息后，对该消息中指示的数据包序列进行QoS参数检测并收集所述检测请求中指定的参数的检测结果。当QoS参数检测完毕后或者是每完成一次检测后，所述第二网络设备向所述SDN控制器发送检测结果。

收到检测结果后，所述SDN控制器根据检测结果信息分析出(或确定)引起节目质量恶化的网络设备。

下面将结合图6，对本发明的实施例提供的方案做进一步说明。

图6为本发明的实施例提供的又一种IPTV业务质量检测的流程示意图。

S601第一网络设备定期上报一个或者多个IPTV业务QoS参数的监测结果；

具体地，第一网络设备被配置对其收到的数据流进行监测，并按照配置的时间周期，定期地向SDN控制器上报检测的参数数值。具体可以检测的参数请参考图4的步骤S402里提到的“数据包流的QoS参数”描述，此处不做赘述。

S602 SDN控制器发现IPTV业务的QoS参数超过预设的阈值；

具体地，S502类似S401中的“发现检测的QoS参数超过预设的阈值”动作，请参看S401步骤对应的描述，此处不做赘述。

S603 SDN控制器判断要进行QoS参数检测；

S604 SDN控制器发送第一检测请求消息；

具体地，当判断要进行QoS参数检测时，发送第一检测请求消息。具体地，SDN控制器根据数据流所对应的转发路径，以及检测的策略来确定需要发送第一检测请求消息的对象，即待检测序列。需要说明的是，SDN控制器做为整个系统的控制中心，是能够获取到转发路径信息的，可以是通过用户配置或者从其他服务器获取等方式获得，甚至是由SDN控制器通过算法或者其他方式来实现为每个网络设备进行具体转发路径的配置，本发明不做任何限定。

具体地，SDN控制器需要给待检测序列的所有设备发送第一检测请求消息。在本实施例中，所有设备指的是第二网络设备1和2。但是，在具体的实现中，第二网络设备1和2之间还可以有一个或多个其他第二网络设备。该步骤中的第一检测请求消息内容具体请参看图4中步骤S402的“检测请求消息”的描述，此处不做赘述。此外，SDN控制器还需要将该检测项添加到其“当前检测信息表”中。值得说明的是发送第一检测请求消息和前面所述的添加表项的动作可以按照任意执行顺序来执行，本发明不做任何限定。

网络终端定期上报监测的QoS参数，SDN控制器在判断所述的QoS参数超过阈值时，主动请求对应转发路径上的网络设备进行质量检测，有效地降低了检测周期时间。

S605第二网络设备执行质量检测；

具体地，当第二网络设备1和2收到所述的SDN控制器发来的第一检测请求消息后，执行QoS参数检测。

S606第二网络设备发送检测结果；

具体地，在QoS参数检测完毕或者完成了一次参数质量检测后，第二网络设备1和2将其获取所有的检测结果或者当前检测的检测结果发送给SDN控制器。

S607 SDN控制器确定故障的网络设备。

具体地，SDN控制器收到检测结果后，需要执行和图4中S407相同的操作来判断引起质量恶化的网络设备。此外，SDN控制器还需要将已经完毕的检测从它维护的“当前检测信息表中”删除。需要说明的是，SDN控制器也可以通过其他方式来标识某一表项对应的检测已经完毕，例如通过增加一个状态标识符来表明该检测是正在或已经结束；或者通过其他方式来获取“当前在进行的QoS参数检测”信息，例如通过一个独立的服务器来维护这个信息。本发明使用SDN控制器维护一个“当前检测信息表”为例来进行描述。

可选地，第一网络设备还可以执行“确定所述QoS参数超过预设的阈值”步骤，并发送第二检测请求消息给SDN控制器。对应地，SDN控制器在收到“第二检测请求消息”后，直接判断是否需要进行检测以及执行上述流程中的该判断动作之后的其他动作。SDN的特点之一是转发与控制功能分离，并简化转发设备。因此，仅执行周期性上报动作更符合SDN特点，可以降低网络终端设备的复杂度。但是本发明对“确定所述QoS参数超过预设的阈值”的执行主体不做任何限定，可以是第一网络设备或SDN控制器。

所述第二检测请求消息至少需要携带视频源标识信息。可选地，所述第二检测请求消息还可以携带检测类型，检测时长和检测步长信息。具体信息的定义请参看图4中步骤S402的“检测请求消息”中的相关的描述，此处不做赘述。

本实施例描述的整个质量检测过程无需维护人员参与，有效地降低了维护成本。需要说明的是图6所示的SDN控制器和图4所示的检测中心的差别在于前者还可以发送检测请求消息给第二网络设备，而无需第一网络设备跟第二网络设备，以及第二网络设备之间进行顺序的转发，进一步降低了检测周期时间。

在本发明的实施例中，第二网络设备和SDN控制器之间，以及第一网络设备和SDN控制器的消息交互可以是基于OPENFLOW协议，或者通过自定义的消息格式。在这里，以图1中第一网络设备为ONU1，第二网络设备OLT1、路由器5、路由器2和路由器1为示例，假设数据包是通过RTP协议封装，下面对检测流程中所涉及的消息做进一步解释。假设该业务IPTV业务分发系统采用的是组播的方式，ONU1和SDN控制器之间以及SDN控制器和OLT1、路由器5、路由器2和路由器1，即SDN控制器和网络设备之间，均使用的是OPENFLOW协议。

作为一个示例，假设ONU1被配置为检测IPTV节目的RTP数据序列的时延和丢包个数，并周期性地上报监测到的参数信息，例如：每隔1分钟。

具体地，ONU1可以通过OPENFLOW协议增加一个异步上报(Asynchronous Report)消息来上报这些参数数值。该异步上报消息的报文头沿用当前OPENFLOW协议消息的报文头，通过Type字段设置为36表示，具体包含的参数信息示例可以参看表2，此处不做赘述。具体地，ONU1上报的监测结果可以每监测一次就给SDN控制器上报一次，或者按照固定的间隔进行上报。

SDN控制器上被配置为当时延大于30ms或丢包个数大于10时需要发送检测请求消息。假设SDN控制器当前收到的参数信息中抖动为20ms，丢包个数为20，那么SDN控制器需要给该视频源对应的转发路径中的待检测序列，即OLT1、路由器1、路由器2和路由器5，发送检测请求消息。该检测请求消息具体包含的参数可以如表1所示的格式，此处不再赘述。需要说明的是，该检测请求消息是通过OPENFLOW协议中的OFPT_FLOW_MOD消息中新增一种ACTION(行为)类型为OFPAT_DETECT来表示的，ofp_action_header中type设置为30来表示OFPAT_DETECT。

为了支持参数检测的统计，网络设备的FlowTable中需要增加新的表项，具体地，网络设备需要支持如表6所示的相关参数的读写处理：

表6

检测完毕后，第二网络设备可以通过OPENFLOW协议的消息，如异步上报消息，来发送检测结果。在一种可能的实现中，SDN控制器收到的信息如表3所示。根据如表3所示的检测结果，SDN控制器结合其所知的待检测序列(即OLT1-R1-R2-R5)来综合判断，可以分析出，R5丢包个数为0，从R2开始丢包个数为20，因此可以确定故障的网络设备为R2。

除了图6中所示的SDN控制器判断为“需要执行检测”的情况，还有可能判断结果为“无需执行检测”的情况。下面将结合图7，针对“无需执行检测”的情况，对本发明的实施例做进一步说明。

图7为本发明的实施例给出的一种可能的SDN控制器的处理流程。

S701收到第一检测请求消息；

S702判断是否要执行检测；

S703a将该检测项添加到“当前检测信息表”中；

S703b发送第二检测请求消息；

具体地，发送第二检测请求消息给“待检测序列”中的所有网络设备；

S704收到检测结果后，确定故障的网络设备；将该已经完成的检测项从“当前检测信息表”中删除；

具体地，SDN控制器收到检测结果后，结合转发路径信息，分析出引起质量劣化的“故障设备”。值得说明的是结果分析和删除检测项并没有严格的执行顺序限制，可以按照任意顺序来执行。

S705判断是否要刷新检测参数；

S706刷新当前正在进行的相关检测的检测参数；

在一种可能的实现中，SDN控制器需要执行步骤S701，S702和S703a，S703b，S704，该步骤序列是判断为“要执行检测”需要执行的步骤。其中，步骤S702和S703b，S704跟图6中描述的SDN控制器执行的步骤类似，具体请参看图6中步骤S603，S604和S607的描述，此处不再赘述。区别在于，图6中的SDN控制器接收从第一网络设备发送过来的监测QoS参数信息，还需要判断接收到的QoS参数是否异常，即是否超过预设的阈值。此外，S703a并没有在图6中体现，但是在对应的文字描述中有提及。值得说明的是S703a和S703b在本实施例中是顺序执行，但是这两步骤实际上可以按照任意执行顺序来执行，本发明不做任何限定。而本实施例中，第一网络设备来执行“QoS参数是否异常”的判断动作，且在发现异常时，发送第一检测请求消息，用以请求SDN控制器来发起QoS参数检测。

在一种可能的实现中，SDN控制器需要执行的步骤S701，S702，S705，S706，S703b和S704，该步骤序列为判断为“无需执行检测”但“需要刷新检测参数”需要执行的步骤。具体地，当SDN控制器在其“当前检测信息表”中找到了对应的表项，即包含了跟视频源标识对应的表项，则表明针对这个节目源已经在进行检测，因此无需执行新的QoS参数检测。但是，所述SDN控制器需要进一步提取该检测请求消息中的检测步长，检测类型和检测时长信息，以进一步判断是否需要刷新“当前检测信息表”中的对应表项的对应的参数信息。

作为一个具体的示例，假设SDN控制器维护的“当前检测信息表”部分参数如表4所示。而其收到的第一检测请求消息中的相关参数如表5所示。该SDN控制器可以判断针对该节目源，即针对(视频源服务器IP地址为202.110.110.110，组播组IP地址为224.1.1.22)的节目，已经在进行QoS参数检测，因此无需执行新的QoS参数检测。但是，该SDN控制器当前仅检测时延，而接收到的检测请求消息还包含丢包个数，而且检测时长和步长信息跟“当前检测信息表”里对应的表项都不一致。

在一种可能的示例中，该SDN控制器可以刷新检测类型来包含时延和丢包率，而不更改当前信息检测表中的检测时长和检测步长。在另外一种可能的示例中，该SDN控制器可以请求刷新检测步长为两个参数中较小的那个，即刷新检测步长为512。具体如何修改“当前检测信息表”的信息可能是由SDN控制器上配置的策略和/或结合网络设备的其软硬件能力综合考虑来决定的。本发明的例子仅是可能的示例，但是本发明对实际如何刷新“当前信息检测表”里的参数不做任何限定。具体地，可以通过在发送的第二检测请求消息中携带一个标识位，用于指示该第二检测请求消息的本质是请求收到该第二检测请求消息的主体(即第二网络设备)进行对应的检测参数刷新，而非请求执行QoS参数检测。

在一种可能的实现中，SDN控制器需要执行S701，S702，S705和S704，该步骤序列是判断为“无需执行检测”且“无需刷新检测参数”需要执行的步骤。可以理解，针对收到的检测请求消息，SDN控制器在其“当前检测信息表”发现了跟所述检测请求消息中的待检测视频源标识信息一致的表项。而且，所收到检测请求消息中指定的具体检测信息(即：检测类型，检测时长和检测步长)，不对当前正在执行的检测所使用的参数造成任何影响。从而，SDN控制器无需刷新“当前检测信息表”的相关表项，仅需要执行步骤S704，收到检测结果并分析出故障的网络设备，并将该已完成的检测项从“当前检测信息表”中删除。由此可以看出，一个检测请求消息不一定会触发网络设备执行QoS参数检测流程，而可能仅会触发其修改已经在进行的检测的检测参数(即刷新检测参数)，甚至是不会造成任何动作(即直接重用另外的检测请求消息触发的检测流程所提供的检测结果)。这么做的好处是避免针对同一节目源进行反复的检测，可以提高检测效率，节约网络资源。

需要补充说明的是，针对图6和图7中的实施例，可选地，在第二网络设备每检测一次QoS参数后就发送检测结果给SDN控制器时，SDN控制器可以发第三检测请求消息，让当前正在进行QoS参数检测的第二网络设备停止检测。这么做可能是因为SDN控制器已经获取了足够让其判断故障的网络设备的信息。这么做的好处是在不影响SDN控制器进行检测质量分析的前提下，进一步地节约了网络设备资源和链路资源信息。这个用于请求停止检测的第三检测请求消息是SDN控制器通过OPENFLOW协议或者其他自定义的消息来发送给相应的网络设备。

需要补充说明是，在具体的应用中，SDN控制器在发送第二检测请求消息时，可以不携带检测时长，而是通过主动发送检测停止消息给网络设备来使其收到停止消息时主动停止检测。这么做可以简化SDN控制器和网络设备的交互，并且保证在SDN控制器判断可以分析出故障设备前，网络设备可以持续检测。

还要补充说明的是，SDN控制器发送第一检测请求消息时，可以不携带检测类型和检测步长，该参数可以默认在第二网络设备上配置为固定值，例如：在相关的网络设备上配置检测类型固定为时延和丢包率，检测步长固定为每隔1024个数据包。这么做可以简化SDN控制器和网络设备的交互信息。

另外需要补充说明的是，SDN控制器可以不执行图7的S702步骤，即针对每一个收到的第一检测请求消息，SDN控制器都请求第二网络设备进行QoS参数的检测，这么做可能会消耗网络设备的有限资源，但是可以简化SDN控制器的处理流程。本发明对SDN控制器是否需要执行判断流程不做任何限定。上述主要从各个执行主体之间交互的角度对本发明实施例提供的方案进行了介绍。可以理解的是，各个执行主体，例如第一网络设备、第二网络设备、检测中心或SDN控制器等为了实现上述功能，其包含了执行各个功能相应的软件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及步骤，能够以硬件和计算机软件的结合形式来实现。某些功能究竟以硬件还是计算机软件驱动硬件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

实施例3

图8给出了上述实施例中所涉及的第一网络设备801的一种可能的结构示意图。网络设备801包括处理模块802和发送模块803。

所述处理模块802，用于监测至少一个携带视频源标识的数据包流的服务质量QoS参数，其中所述视频源标识用于识别一个IPTV视频源；可选地，所述处理模块还用于在判断所述的QoS参数超过预设的阈值时，生成检测请求消息，针对该检测请求消息的描述参见方法实施例1，此处不做赘述。所述发送模块803，用于发送消息，具体地，所述发送模块执行图4的S401或者图6的S601步骤。

图9给出了上述实施例中第二网络设备901的一种可能的结构示意图。第二网络设备901包括接收模块902，处理模块903和发送模块904。

所述接收模块902用于支持第二网络设备从上述实施例中其下游的网络设备或第一网络设备或SDN控制器接收请求消息。所述处理模块903用于执行图4和图5所描述的涉及网络设备的相关技术过程或图6和图7所描述的涉及网络设备的相关技术过程。所述的发送模块904用于发送网络设备的检测结果。此外，所述的发送模块还可以用于支持网络设备向上述实施例中的所述其上游的网络设备转发检测请求消息。

图10给出了上述实施例中所述的SDN控制器1001的一种可能的结构示意图。SDN控制器包括接收模块1002，处理模块1003和发送模块1004。

所述接收模块1002用于支持SDN控制器和第一网络设备或者是SDN控制器和第二网络设备之间的信息交互。所述处理模块1003用于执行上述实施例中涉及SDN控制器的处理过程，例如：图6和图7所描述的涉及SDN控制器的技术过程。所述的发送模块1004用于发送检测请求消息。可选地，所述发送模块还1004还可以发送停止检测请求消息。

图11给出了上述实施例中所述的检测中心1101的一种可能的结构示意图。检测中心1101包括接收模块1102和处理模块1103。

所述接收模块1102用于接收上述实施例中提到的第二网络设备发送过来的检测结果。所述处理模块用于检测中心根据所述的检测结果，进行QoS参数检测结果的分析，确定故障的网络设备。

需要补充说明的是上述的处理模块、发送模块和接收模块也可以分别是处理器、发送器和接收器。

本领域普通技术人员将会理解，本发明的各个方面、或各个方面的可能实现方式可以被具体实施为系统、方法或者计算机程序产品。因此，本发明的各方面、或各个方面的可能实现方式可以采用完全硬件实施例、完全软件实施例(包括固件、驻留软件等等)，或者组合软件和硬件方面的实施例的形式，在这里都统称为“电路”、“模块”或者“系统”。此外，本发明的各方面、或各个方面的可能实现方式可以采用计算机程序产品的形式，计算机程序产品是指存储在计算机可读介质中的计算机可读程序代码。

计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质包含但不限于电子、磁性、光学、电磁、红外或半导体系统、设备或者装置，或者前述的任意适当组合，如随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或者快闪存储器)、光纤、便携式只读存储器(CD-ROM)。

计算机中的处理器读取存储在计算机可读介质中的计算机可读程序代码，使得处理器能够执行在流程图中每个步骤、或各步骤的组合中规定的功能动作；生成实施在框图的每一块、或各块的组合中规定的功能动作的装置。

计算机可读程序代码可以完全在用户的计算机上执行、部分在用户的计算机上执行、作为单独的软件包、部分在用户的计算机上并且部分在远程计算机上，或者完全在远程计算机或者服务器上执行。也应该注意，在某些替代实施方案中，在流程图中各步骤、或框图中各块所注明的功能可能不按图中注明的顺序发生。例如，依赖于所涉及的功能，接连示出的两个步骤、或两个块实际上可能被大致同时执行，或者这些块有时候可能被以相反顺序执行。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (17)

1.一种因特网协议电视IPTV业务质量检测的方法，其特征在于，所述方法包括：

控制器根据来自第一网络设备的数据包流的服务质量QoS参数信息，确定所述QoS参数超过预设的阈值；

所述控制器发送第一检测请求消息给所述数据包流对应的转发路径上的所有第二网络设备，所述第一检测请求消息包含QoS参数劣化的数据包流所携带的视频源标识，所述第一检测请求消息用于请求对携带所述第一检测请求消息包含的视频源标识的数据包流进行QoS参数检测，所述视频源标识用于指示所述QoS参数劣化的数据包流所对应的IPTV视频源； 其中所述第二网络设备为位于所述第一网络设备和视频源服务器之间的网络设备；

所述控制器从所述所有第二网络设备接收携带所述视频源标识的数据包流的QoS参数检测结果；

所述控制器根据所述检测结果，确定故障的网络设备；

所述第一检测请求消息还包括检测步长和检测时长，所述检测步长指示多次QoS参数收集中相邻两次QoS参数收集的时间间隔，所述检测时长指示所述多次QoS参数收集的时间长度值。

2.如权利要求1所述的方法，其特征在于，所述第一检测请求消息还包括检测类型，所述检测类型指示待检测的QoS参数，所述QoS参数包括时延、时延抖动、丢包个数、丢包时间间隔、乱序包个数和业务带宽的一种或多种。

3.如权利要求1所述的方法，其特征在于，所述视频源标识包括视频源服务器IP地址和组播组IP地址。

4.一种IPTV业务质量检测的方法，其特征在于，所述方法包括：

在第一网络设备接收到的数据包流的QoS参数超过预设阈值的情况下，第二网络设备接收检测请求消息，所述检测请求消息包含QoS参数劣化的数据包流所携带的视频源标识,所述视频源标识用于指示所述QoS参数劣化的数据包流所对应的IPTV视频源；所述检测请求消息还包括检测步长和检测时长；所述第二网络设备为所述第一网络设备的上游网络设备；

所述第二网络设备根据所述检测步长和检测时长，对携带所述视频源标识的数据包流进行QoS参数检测和收集，所述检测步长指示多次QoS参数收集中相邻两次QoS参数收集的时间间隔，所述检测时长指示所述多次QoS参数收集的时间长度值；

所述第二网络设备发送所述QoS参数检测的检测结果；所述检测结果用于确定故障的网络设备；

所述第二网络设备转发所述检测请求消息至所述第二网络设备在转发所述数据包流的路径上的上游网络设备；所述第二网络设备的上游网络设备用于转发所述检测请求消息至所述第二网络设备的上游网络设备在所述路径上的上游网络设备，直至所述检测请求消息被转发至所述路径上的最后一个网络设备。

5.如权利要求4所述的方法，其特征在于，所述检测请求消息还包括检测类型，所述检测类型指示待检测的QoS参数，所述QoS参数包括时延、时延抖动、丢包个数、丢包时间间隔、乱序包个数和业务带宽的一种或多种。

6.如权利要求4或5所述的方法，其特征在于，所述视频源标识包括视频源服务器IP地址和组播组IP地址。

7.一种IPTV业务质量检测的方法，其特征在于，所述方法包括：

第一网络设备监测至少一个携带视频源标识的数据包流的服务质量QoS参数，其中所述视频源标识用于识别一个IPTV视频源；

所述第一网络设备判断所述QoS参数超过预设的阈值时，生成检测请求消息, 所述检测请求消息包含QoS参数劣化的数据包流所携带的视频源标识；

所述第一网络设备发送所述检测请求消息给第二网络设备；所述第二网络设备为所述第一网络设备在转发所述数据包流的路径上的上游网络设备；所述第二网络设备用于转发所述检测请求消息至所述第二网络设备在所述路径上的上游网络设备，所述第二网络设备的上游网络设备用于转发所述检测请求消息至所述第二网络设备的上游网络设备在所述路径上的上游网络设备，直至所述检测请求消息被转发至所述路径上的最后一个网络设备；

所述检测请求消息用于请求对携带所述检测请求消息包含的视频源标识的数据包流进行QoS参数检测；所述第二网络设备还用于根据所述检测请求消息执行检测，获取检测结果；所述检测结果用于确定故障的网络设备；

所述检测请求消息还包括检测步长和检测时长，所述检测步长指示多次QoS参数收集中相邻两次QoS参数收集的时间间隔，所述检测时长指示所述多次QoS参数收集的时间长度值。

8.如权利要求7所述的方法，其特征在于，所述检测请求消息还包括检测类型，所述检测类型指示待检测的QoS参数，所述QoS参数包括时延、时延抖动、丢包个数、丢包时间间隔、乱序包个数和业务带宽的一种或多种。

9.一种控制器，其特征在于，包括发送模块、接收模块和处理模块，其中：

所述处理模块，用于根据来自第一网络设备的数据包流的服务质量QoS参数信息，确定所述QoS参数超过预设的阈值；

所述发送模块，用于发送第一检测请求消息给所述数据包流对应的转发路径上的所有第二网络设备，所述第一检测请求消息包含QoS参数劣化的数据包流所携带的视频源标识，所述第一检测请求消息用于请求对携带所述第一检测请求消息包含的视频源标识的数据包流进行QoS参数检测，所述视频源标识用于指示所述QoS参数劣化的数据包流所对应的IPTV视频源；其中所述第二网络设备为位于所述第一网络设备和视频源服务器之间的网络设备；

所述接收模块，用于从所述所有第二网络设备接收携带所述视频源标识的数据包流的QoS参数检测结果；

所述处理模块，还用于根据所述检测结果，确定故障的网络设备；

所述第一检测请求消息还包括检测步长和检测时长，所述检测步长指示多次QoS参数收集中相邻两次QoS参数收集的时间间隔，所述检测时长指示所述多次QoS参数收集的时间长度值。

10.如权利要求9所述的控制器，其特征在于，所述第一检测请求消息还包括检测类型，所述检测类型指示待检测的QoS参数，所述QoS参数包括时延、时延抖动、丢包个数、丢包时间间隔、乱序包个数和业务带宽的一种或多种。

11.如权利要求9所述的控制器，其特征在于，所述的视频源标识包括视频源服务器IP地址和组播组IP地址。

12.一种网络设备，其特征在于，包括接收模块、处理模块和发送模块，其中：

在第一网络设备接收到的数据包流的QoS参数超过预设阈值的情况下，所述接收模块，用于接收检测请求消息，所述检测请求消息包含QoS参数劣化的数据包流所携带的视频源标识, 所述视频源标识用于指示所述QoS参数劣化的数据包流所对应的IPTV视频源；所述检测请求消息还包括检测步长和检测时长；所述网络设备为所述第一网络设备的上游网络设备；

所述处理模块，用于根据所述检测步长和检测时长，对携带所述视频源标识的数据包流进行QoS参数检测和收集，所述检测步长指示多次QoS参数收集中相邻两次QoS参数收集的时间间隔，所述检测时长指示所述多次QoS参数收集的时间长度值；

所述发送模块，用于发送所述QoS参数检测的检测结果；所述检测结果用于确定故障的网络设备；

所述发送模块，还用于转发所述检测请求消息至所述网络设备在转发所述数据包流的路径上的上游网络设备；所述网络设备的上游网络设备用于转发所述检测请求消息至所述网络设备的上游网络设备在所述路径上的上游网络设备，直至所述检测请求消息被转发至所述路径上的最后一个网络设备。

13.如权利要求12所述的网络设备，其特征在于，所述发送模块发送的检测请求消息还包括检测类型，所述检测类型指示待检测的QoS参数，所述QoS参数包括时延、时延抖动、丢包个数、丢包时间间隔、乱序包个数和业务带宽的一种或多种。

14.如权利要求12或13所述的网络设备，其特征在于，所述视频源标识包括视频源服务器IP地址和组播组IP地址。

15.一种网络设备，其特征在于，所述网络设备包括处理模块和发送模块，其中：

所述处理模块，用于监测至少一个携带视频源标识的数据包流的服务质量QoS参数，其中所述视频源标识用于识别一个IPTV视频源；还用于在判断所述QoS参数超过预设的阈值时，生成检测请求消息, 所述检测请求消息包含QoS参数劣化的数据包流所携带的视频源标识；

所述发送模块，用于发送所述检测请求消息给第二网络设备；所述第二网络设备为所述网络设备在转发所述数据包流的路径上的上游网络设备；所述第二网络设备用于转发所述检测请求消息至所述第二网络设备在所述路径上的上游网络设备，所述第二网络设备的上游网络设备用于转发所述检测请求消息至所述第二网络设备的上游网络设备在所述路径上的上游网络设备，直至所述检测请求消息被转发至所述路径上的最后一个网络设备；所述检测请求消息用于请求对携带所述检测请求消息包含的视频源标识的数据包流进行QoS参数检测；所述第二网络设备还用于根据所述检测请求消息执行检测，获取检测结果；所述检测结果用于确定故障的网络设备；

所述发送模块发送的检测请求消息还包括检测步长和检测时长，所述检测步长指示多次QoS参数收集中相邻两次QoS参数收集的时间间隔，所述检测时长指示所述多次QoS参数收集的时间长度值。

16.如权利要求15所述的网络设备，其特征在于，所述发送模块发送的检测请求消息还包括检测类型，所述检测类型指示待检测的QoS参数，所述QoS参数包括时延、时延抖动、丢包个数、丢包时间间隔、乱序包个数和业务带宽的一种或多种。

17.如权利要求15或16所述的网络设备，其特征在于，所述视频源标识包括视频源服务器IP地址和组播组IP地址。

Images