[发明专利]一种终端设备维护的方法、设备及系统

说明书

技术领域

本发明涉及通信技术领域，尤其涉及一种终端设备维护的方法、设备及系统。

背景技术

随着通信技术的发展，宽带的大规模普及，开展的宽带业务越来越丰富，终端设备的能力变得越来越强。

如今，不少宽带业务的开展需要将终端设备部署到用户侧才能开展，比如交互式网络电视IPTV。随着这类业务的大规模运营，不少运营商需要以人工上门的方式来进行终端设备维护，使得维护成本也日趋庞大，运营商利润下降。

由于终端设备部署在用户侧，且并不是总是在线，还有可能在网关之后，所以传统的简单网络管理协议(SNMP，Simple Network Management Protocol)不能满足对此类设备的管理。

现有的技术中的解决办法举例如下：

DSL论坛(DSL Forum)在提出一套广域网终端设备管理协议TR069后，还针对不同类型的终端设备定义了数据模型，比如对于机顶盒(STB，Set TopBox)，定义了TR135数据模型，对于家庭网关，定义了TR098数据模型，还定义了通用数据模型如：TR106；

采用TR069协议，可以实现用户侧终端设备的远程管理、故障定位，一定程度上减少了终端设备出错后上门维护的成本，DSL Forum定义的数据模型中设定了一些简单的故障诊断方式，比如TR106就支持因特网包探索器(ping)诊断、追踪路线(TraceRoute)诊断，现在的终端设备一般都支持这些简单的诊断

然而，DSL Forum定义的数据模型无法满足实际运营需求，主要体现在如下几个方面。

DSL Forum中的数据模型定义的诊断功能功能比较弱，比如TR106数据模型只是实现了ping、TraceRoute网络层的互通性诊断，其他的数据模型也是类似，主要实现对网路层互通性的诊断测试；

DSL Forum定义的诊断都是依赖与具体的数据模型，扩展性不好，以TR106的ping诊断为例，如果需要做Ping诊断就依赖于提供IP层的ping诊断.(Device.LAN.IP Ping Diagnostics)节点下的多个节点，网络管理设备首先要设置节点诊断状态(Diagnostics State)(启动时需要设置为Requested)、用于ping诊断的主机名或地址(Host)、在报告结果之前的ping诊断重复的次数(NumberOf Repetitions)、用毫秒表示的ping诊断超时时间(Time out)、每个ping命令发送的数据大小(Data Block Size)、测试包中差异化服务编码点(DSCP，Differentiated Services Code Point)的值，待诊断结束后在获取ping测试中成功的次数(Success Count)、ping测试中失败的次数(Failure Count)、ping测试的所有成功响应的平均时间(Average Response Time)、ping测试的所有成功响应中的最短时间(Minimum Response Time)、ping测试的所有成功响应中的最长时间(Maximum Response Time)。按照DSL Forum定义的方式，在扩展新的诊断时就必须要多个扩展节点来实现，要对数据模型进行大量的改造。

在用户报障后，现有的终端设备和网络管理设备无法实现针对某种新的业务或问题的动态诊断，从而无法真正的减少上门维护成本。

发明内容

本发明实施例提供了一种终端设备维护的方法、设备及系统，使用本发明实施例提供的技术方案，能够在宽带业务出现故障时不区分具体业务、具体终端设备及具体数据模型，实现动态诊断。

本发明实施例的目的是通过以下技术方案实现的：

本发明实施例提供一种终端设备维护的方法，包括：

向网络管理设备发送故障信息；

接收网络管理设备下发的下载指令，所述下载指令包括诊断程序的信息；

根据所述下载指令下载所述诊断程序；

执行所述诊断程序，获得诊断结果。

本发明实施例还提供另一种终端设备维护的方法，包括：

接收终端设备发送的故障信息；

向所述终端设备发送下载指令，所述下载指令包括诊断程序的信息，以便所述终端设备根据所述下载指令下载诊断程序。

本发明实施例还提供一种终端设备，包括：

故障信息发送单元，用于向网络管理设备发送故障信息；

指令接收单元，用于接收所述网络管理设备下发的下载指令，所述下载指令包括诊断程序的信息；