CN102857799B - 基于机顶盒的故障诊断方法 - Google Patents
基于机顶盒的故障诊断方法 Download PDFInfo
- Publication number
- CN102857799B CN102857799B CN201210343296.8A CN201210343296A CN102857799B CN 102857799 B CN102857799 B CN 102857799B CN 201210343296 A CN201210343296 A CN 201210343296A CN 102857799 B CN102857799 B CN 102857799B
- Authority
- CN
- China
- Prior art keywords
- top box
- set top
- ping
- certificate server
- network
- 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.)
- Expired - Fee Related
Links
Abstract
本发明公开了一种基于机顶盒的故障诊断方法，主要包括机顶盒开机步骤和故障诊断步骤，所述故障诊断步骤选择所述机顶盒的故障诊断模式并执行，所述故障诊断模式包括网络诊断模式、系统服务诊断模式、应用服务诊断模式和测速模式，该方法能够更加直观实时的显示机顶盒状态，有效降低维护成本，提高故障诊断效率。
Description
技术领域
本发明涉及一种交互式网络电视技术领域，特别涉及一种基于机顶盒的故障诊断方法。
背景技术
随着宽带网络的飞速发展，交互式网络电视(Internet Protocol Television，IPTV)这一崭新的行业，已受到业界越来越多的关注。它利用宽带有线电视网为基础，以家用电视机和网络机顶盒作为主要终端电器，向用户提供包括数字电视在内的多种交互式服务。IPTV是一项基于互联网的业务，其终端形式多种多样并且具备很高的智能性。同时，IPTV业务是一项互动性很高的业务，种类多样，逻辑复杂，且灵活多变。其节目在网内，可采用广播、组播、单播多种发布方式，也可以非常灵活地实现电子选单、节目预约、实时快进、快退、终端账号及计费管理、节目编排等多种功能。
目前常用的IPTV机顶盒主要由软件、硬件两大部分组成，其中硬件包含了内存、主芯片、调谐解调器、外部存储控制器、CA(加密系统)接口、回传通道、音视频输入输出等几大部分；软件主要包括嵌入式操作系统、应用层软件和各类驱动程序。由于IPTV机顶盒需要实现网络接入、音视频播放、系统升级、用户管理和配置等功能，因此软件部分包含的主要模块有：网络接入模块、浏览器模块、流媒体播放器模块、流媒体传送和控制模块、机顶盒管理及配置模块、网管模块、系统升级模块等。IPTV机顶盒采用嵌人式Linux操作系统，该操作系统有利于IPTV机顶盒应用软件的开发和移植。
IPTV的用户终端可以是机顶盒（Set-TopBox，STB）或个人计算机，IPTV的用户终端和业务的复杂性（如电视节目采用广播、组播、单播等多种发布方式，电视节目可以实现电子选单、节目预约、实时快进、快退、终端账号及计费管理、节目编排等多种功能）对终端管理提出了很高的要求，因此怎样提高IPTV终端管理的有效性成为了IPTV业务运营中重要的问题之一。
为了实现对IPTV机顶盒（也即IPTV终端）的实时管理，需要对其故障进行实时诊断，现有的诊断方法主要采用人工的方法现场检测机顶盒的故障，需要大量的客服人员，维护成本较高，对某些故障由于并不能及时进行诊断，因此无法实现全面诊断的目标（例如CN102137282A只能检测故障链路对网络故障进行定位，CN101605238A只能检测IPTV的业务故障，功能较为单一），因此需要一种故障诊断功能更加全面，能够从网络和应用的角度出发，全面的扫描和检测机顶盒的相关应用，直观实时的显示机顶盒状态，从而提高定位故障的反应速度，降低客服人员的维护成本，给用户提供更好的服务的基于机顶盒的故障诊断方法。
发明内容
本发明的主要目的是提供一种故障诊断功能更为全面、更加直观实时的显示机顶盒状态，有效降低维护成本的基于机顶盒的故障诊断方法。
为了达到上述目的，本发明提出了一种基于机顶盒的故障诊断方法，其特征在于，包括以下步骤：
A 机顶盒开机步骤：
步骤S100：所述机顶盒开机；
步骤S101：通过开机设置文件中缺省的认证服务器地址访问API（应用程序编程接口）认证服务器，向所述API认证服务器发送请求；
步骤S102：所述API认证服务器通过调用用户中心接口，判断所述机顶盒的MAC（媒体接入控制）是否是合法用户：如果是，则转入步骤S103；如果否，则转入步骤S101；
步骤S103：从所述API认证服务器中取得该用户的分组信息，并将相关资源的域名地址生成预置文件返回所述机顶盒，认证过程完成；
步骤S104：所述机顶盒根据所述预置文件中取得的相关资源的域名地址访问相关的服务，并通过调用相关系统和应用服务接口，显示服务的状态；
B，故障诊断步骤：选择所述机顶盒的故障诊断模式并执行，所述故障诊断模式包括系统服务诊断模式，所述系统服务诊断模式的诊断过程，包括以下步骤：
步骤S300：所述机顶盒采用HTTP协议格式访问API认证服务器和/或升级服务器的服务接口；
步骤S301：所述API认证服务器和/或升级服务器返回对应该服务接口的XML或者JSON数据格式的结果文件；
步骤S302 所述机顶盒根据所述结果文件判断连接所述API认证服务器和/或升级服务器是否正常：如果所述结果文件中有true，则正常，如果有false，则不正常。
进一步地，步骤B中的所述故障诊断模式还包括应用服务诊断模式，所述应用服务诊断模式的诊断过程，包括以下步骤：
步骤S400：所述机顶盒采用HTTP协议格式访问应用服务接口；
步骤S401：所述应用服务接口返回对应该接口的不同状态的值；
步骤S402 所述机顶盒根据所述返回的不同状态的值判断所述应用服务接口是否正常。
进一步地，步骤B中的所述故障诊断模式还包括测速模式，所述测速模式的诊断过程，包括以下步骤：
步骤S500：所述机顶盒下载并播放一定时长的视频；
步骤S501：所述机顶盒计算在线下载速度；
步骤S502：所述机顶盒根据所述下载速度，为用户选择不同的码流标准进行播放。
进一步地，步骤B中的所述故障诊断模式还包括网络诊断模式，所述网络诊断模式包括PING命令的连通性测试过程，具体包括以下步骤：
步骤S200：所述机顶盒采用PING命令对用户指定的域名地址向所述API认证服务器发送PING连通请求；
步骤S201：所述API认证服务器根据所述PING连通请求返回PING连通结果并在所述机顶盒上显示；
步骤S202 所述机顶盒根据所述PING连通结果统计ping包的成功次数、ping包的丢包次数、ping包的丢包率和ping包的平均响应时间；
步骤S203 根据所述机顶盒的PING连通统计结果判断所述机顶盒与所述API认证服务器之间的网络连接状态。
进一步地，步骤B中的所述故障诊断模式还包括网络诊断模式，所述网络诊断模式包括traceroute命令的连通性测试过程，具体包括以下步骤：
步骤S300：所述机顶盒采用traceroute命令对用户指定的域名地址向所述API认证服务器发送traceroute连通请求；
步骤S301：所述API认证服务器根据所述traceroute连通请求返回traceroute连通结果并在所述机顶盒上显示；
步骤S302 所述机顶盒根据所述traceroute连通结果对目的IP之间的路由进行逐跳统计，显示中间经过的跳数，每一跳的时延，以及每一跳的IP地址或者域名，如果出现无法连通到目的IP的状况，则显示路由节点测试中出现问题的跳点；
步骤S303 根据所述机顶盒的traceroute连通统计结果判断所述机顶盒与所述API认证服务器之间的网络连接状态。
进一步地，所述机顶盒包括IPTV机顶盒。
进一步地，所述机顶盒采用TR069协议。
进一步地，所述PING命令的连通性测试过程，具体包括以下步骤：
步骤P101：所述机顶盒的盒端通过PING命令访问API认证服务器；
步骤P102：所述机顶盒的网络监控模块，根据返回的用户网络响应时间是否大于200ms作为诊断依据：如果是，则PING正常，证明当地网络正常；否则，则PING异常，证明当地网络异常，并根据诊断结果提示用户进行相应的操作。
进一步地，所述traceroute命令的连通性测试过程，具体包括以下步骤：
步骤P201：所述机顶盒的盒端通过traceroute 命令对本地网络与API认证服务器间的路由进行逐跳统计；
步骤P202：所述机顶盒的网络监控模块根据返回的用户网络路由间延时是否大于200ms作为诊断依据：如果是，则traceroute正常，证明当地网络正常；否则，则traceroute异常，证明当地网络异常，并根据诊断结果提示用户进行相应的操作。
进一步地，所述系统服务诊断模式的诊断过程，具体包括以下步骤：
步骤P301：采用HTTP协议格式访问API认证服务器和/或升级服务器的服务接口；
步骤P302：所述机顶盒的系统服务监控模块通过返回的对应该服务接口的XML结果文件（getTestResult)的结果值来判断API认证服务器和/或升级服务器是否正常：如果返回true，则提示API认证服务器和/或升级服务器正常，如果返回false，则提示API认证服务和/或升级服务器异常，并根据诊断结果提示用户进行相应的操作。
进一步地，所述应用服务诊断模式的诊断过程，具体包括以下步骤：
步骤P401：采用HTTP协议格式访问应用服务器应用的服务接口；
步骤P402: 所述机顶盒的应用服务监控模块通过返回的对应该服务接口的XML结果文件来根据返回的状态值status和错误码errorcode分析应用服务的状态。
进一步地，所述测速模式的诊断过程，具体包括以下步骤：
步骤P501：通过wget命令从节点服务器下载开机广告视频文件到所述机顶盒；
步骤P502：所述机顶盒的测速模块边下载边播放开机广告，并通过返回的下载详细信息，根据当前网络速度的不同，显示不同的观看模式供用户选择。
本发明还提出了一种应用如上述方法的基于机顶盒的故障诊断系统，包括机顶盒和API认证服务器，所述API认证服务器采用如上述方法对所述机顶盒进行故障诊断，所述机顶盒包括网络监控模块、系统服务监控模块、应用服务监控模块和测速模块，分别用于执行网络诊断模式、系统服务诊断模式、应用服务诊断模式和测速模式。
进一步地，所述系统的机顶盒还包括TR 069子系统，所述TR 069子系统划分为3个模块：TR069协议栈模块、任务执行模块和NAT穿越模块，其中所述NAT穿越模块主要负责发送基于UDP的Binding Request消息，并能解析STUN服务器返回的Binding Response消息；所述TR069协议栈模块根据TR069协议规定的流程与ACS通信，解析ACS下发的各个RPC方法，并封装上报机顶盒的各个应答；所述任务执行模块负责完成TR069协议栈模块解析出来的各个任务，并将执行结果通过任务队列返回给所述TR069协议栈模块。
进一步地，所述TR069协议栈模块包括摘要认证、Inform消息上报、解析任务和心跳发送子模块；所述任务执行模块主要包括获取参数模型、获取参数值、设置参数值、重启和日志上传子模块。
进一步地，其特征在于，所述机顶盒包括IPTV机顶盒。
与现有技术相比，本发明具有以下优点：本发明可以使用户方便的了解所处网络的情况，并且直观的看到网络连接到服务器的状态，出现故障问题时能清楚的报告故障给客服人员，便于客服人员和研发人员根据瞬时故障来分析和排查故障情况，迅速解决故障，减少上门服务的频率，从而提高解决故障的效率，为用户提供更好的服务。
附图说明
为了更清楚的说明本发明的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍，显而易见的，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明IPTV机顶盒的终端管理系统的基本架构；
图2为本发明的PING或traceroute诊断流程示意图。
图3为本发明的基于机顶盒的故障诊断方法流程示意图。
图4为本发明的盒端开机流程示意图。
图5为ping诊断的具体过程示意图；
图6为traceroute诊断的具体过程示意图；
图7为本发明的网络诊断模式实现原型示意图。
图8为本发明的客户端与中介服务器通信过程示意图。
图9为本发明的HTTP协议内部操作过程示意图。
图10为本发明的HTTP访问流程示意图。
图11为系统服务诊断的具体过程示意图。
图12为本发明的系统服务诊断模式实现原型示意图。
图13为应用服务诊断的具体过程示意图。
图14为本发明的应用服务诊断模式实现原型示意图。
图15为测速模式的具体过程示意图。
图16为本发明的测速模式实现原型示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然所描述的实施例仅是本发明的一部分实施例，不是全部的实施例，基于本发明中的实施例，本领域普通技术人员在没有付出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明的基于机顶盒的故障诊断方法的基本原理，介绍如下：
（一）本发明所采用的TR069协议
由于目前IPTV机顶盒数量十分庞大且复杂，因此如何对IPTV机顶盒进行有效管理成为IPTV业务运营中重要的问题之一。目前主要采用DSL Forum制定的TR069协议（一种面向终端设备的网络管理协议）来为下一代网络中家庭网络设备进行管理配置提供通用框架和协议。
TR069协议描述了用户终端设备（CPE）和自动配置服务器（ACS）之间通信的公共平台，建立了ACS对CPE进行安全的自动化配置管理框架。TR069协议是基于TCP／IP的应用层协议，此协议使用基于HTTP的简单对象访问协议（SOAP）对TR069协议自定义的远程过程调用(RPC)方法进行编码，通过ACS与CPE之间的信息交互流程实现ACS对CPE的管理。其中RPC方法是一种通过网络从远程计算机程序上请求服务而不需要了解底层网络技术的协议，ACS可以根据解析RPC方法来读写参数，以达到配置CPE监控CPE的状态和统计信息的目的。
（二）本发明中IPTV机顶盒的终端管理系统的基本架构
本发明中IPTV机顶盒的终端管理系统的基本架构如图1所示，将TR 069子系统划分为3个模块：TR069协议栈模块、任务执行模块和NAT（Network Address Translation，网络地址转换）穿越模块。其中NAT穿越模块主要负责发送基于UDP（User Datagram Protocol，用户数据报协议）的Binding Request消息，并能解析STUN（Simple Traversal of User Datagram Protocol through Network Address Translators，NAT的UDP简单穿越，是一种网络协议）服务器返回的Binding Response消息。TR069协议栈模块根据TR069协议规定的流程与ACS通信，解析ACS下发的各个RPC（Remote Procedure Call，远程过程调用）方法，并封装上报机顶盒的各个应答。TR069协议栈模块包括摘要认证、Inform消息上报、解析任务、心跳发送等子模块。任务执行模块负责完成TR069协议栈模块解析出来的各个任务，并将执行结果通过任务队列返回给TR069协议栈模块。该任务执行模块主要包括获取参数模型、获取参数值、设置参数值、重启、日志上传等子模块。
（三）本发明中故障诊断方法的基本原理
本发明根据TR069协议定义，用户端可以进行自我诊断并报告诊断结果，终端管理平台端下发通信故障诊断指令和诊断所需要的具体参数，IPTV机顶盒可以通过ping或其他手段检查其与网络业务提供点之间的连通性、带宽等，然后将检测结果返回给终端管理平台端，通过在远端操作，终端管理平台就可以对机顶盒出现的故障进行简单定位，并作相应处理，其流程如图2所示。
其中，TR069子系统通过调用ping或traceroute测试，可以达到故障诊断目的。整个功能的实现是基于图1的IPTV终端管理系统基本架构，终端管理平台下发ping或traceroute命令及其诊断所需的参数，TR069协议栈模块通过解析RPC方法获取具体任务和诊断参数，交给任务执行模块执行诊断命令。此外，在嵌入式Linux操作系统环境下，还可以通过调用shell脚本的方式实现盒端的ping，traceroute测试。
按照IPTV终端管理系统对故障诊断功能的需求，实现终端管理平台对IPTV机顶盒的故障诊断，例如机顶盒的盒端支持ping诊断和traceroute诊断，也即终端管理平台的平台管理端通过SetParameterValues下发ping测试所需参数NumberOfRepetitions(测试重复次数)，DataBlockSize(诊断发送的数据包大小)，Host(测试的主机名或地址)后，机顶盒盒端经ping诊断后通过GetParameterValues返回SuccessCount(诊断中成功次数)，FailureCount(诊断中失败次数)，MinimumResponseTime(诊断中所有成功响应的最短时间)，MaximumResponseTime(诊断中所有成功响应的最长时间)，AverageResponseTime(诊断中所有成功响应的平均时间)；此外，终端管理平台的平台管理端通过下发traeeroute测试所需参数MaxHopCount(诊断发送数据包的最大跳数)，Timeout(诊断超时时间)，Host(测试主机名或地址)，DataBlockSize(诊断发送的数据包大小)，机顶盒盒端经traceroute诊断后返回ResponseTime(最近一次路由测试响应的时间)，NumberOfRouteHops(发现的路由的跳数)，以及i.HopHost(发现路由对象)。
如图3所示，本发明实施例提供了一种基于机顶盒的故障诊断方法。其主要包括以下步骤：
一、机顶盒开机步骤，如图4所示，
步骤S100：所述机顶盒开机；
步骤S101：通过开机设置文件（setting.xml) 中缺省的认证服务器地址访问API（Application Programming Interface，应用程序编程接口）认证服务器，向所述API认证服务器发送请求；
步骤S102：所述API认证服务器通过调用用户中心接口，判断所述机顶盒的MAC（Medium/Media Access Control，介质访问控制)地址是否是合法用户：如果是，则转入步骤S103；如果否，则转入步骤S101；
步骤S103：从所述API认证服务器中取得该用户的分组信息，并将相关资源的域名地址生成预置文件（getboxprofile.xml）返回所述机顶盒，认证过程完成；
步骤S104：所述机顶盒根据所述预置文件中取得的相关资源的域名地址访问相关的服务，并通过调用相关系统和应用服务接口，显示服务的状态。
二、故障诊断步骤：选择所述机顶盒的故障诊断模式并执行，所述故障诊断模式包括网络诊断模式、系统服务诊断模式、应用服务诊断模式和测速模式，分别详细介绍如下，这些模式可以分别单独使用或者任意组合使用：
1.网络诊断模式
（1）模式概述
借助PING、traceroute等命令的连通性测试方法确定所述机顶盒与所述API认证服务器之间的网络连接状态。例如可以在机顶盒的盒端设置相应的网络监控模块，来实现上述的网络诊断功能（例如通过相应的芯片结构来实现该功能），具体包括PING监控模块和traceroute监控模块。
1） PING命令的连通性测试方法，包括以下步骤：
步骤S200：所述机顶盒采用PING命令对用户指定的域名地址向所述API认证服务器发送PING连通请求；
步骤S201：所述API认证服务器根据所述PING连通请求返回PING连通结果并在所述机顶盒上显示；
步骤S202 所述机顶盒根据所述PING连通结果统计ping包的成功次数、ping包的丢包次数、ping包的丢包率和ping包的平均响应时间；
步骤S203 根据所述机顶盒的统计结果判断所述机顶盒与所述API认证服务器之间的网络连接状态。
例如，采用命令ping api.iptv.letv.com 来测试机顶盒与API认证服务器之间的网络连接状态，其中api.iptv.letv.com是乐视网TV版在API认证服务器中的域名。这里用户除了可以指定ping的域名，还可以指定ping的IP地址，ping包的大小，ping包的次数。通过API认证服务器返回的信息，所述机顶盒可以统计ping包的成功次数，ping包的丢包次数，ping包的丢包率和ping包的平均响应时间。通过这种方式，可以验证整个当地网络的机顶盒访问API认证服务器的连通状况，是连通的还是没有连通等。
参见图5，这里以ping api.iptv.letv.com为例，例如可以采用如下具体的步骤来实现上述PING诊断过程：
步骤P101：盒端通过PING 命令访问API认证服务器联通状况；
步骤P102：通过返回的诊断信息，盒端网络监控模块对网络状况进行诊断分析。
当返回的诊断信息为超时时，说明网络联通状况异常。例如，当 ping时间大于200 ms时，则提示 ping 异常，也即网络联通状况异常。
当返回的诊断信息符合正常情况时，说明网络联通状况正常。例如，当ping时间介于0ms与200ms之间时，提示 ping 正常，也即网络联通状况正常。
步骤P103：盒端网络监控模块向用户反馈网络状况诊断结果，并提示用户进行相应的操作。
例如：当ping异常时，盒端网络监控模块向用户提示当地网络有问题，请及时联系当地客服工程师检查网络；
步骤P104：点击详细按键，盒端网络监控模块会把通过PING 命令返回的详细网络信息，打印到相关页面上。
也即，所述PING命令的连通性测试过程，具体包括以下步骤（下面的步骤是对PING命令的连通性测试过程的具体说明，只采用用户网络响应时间作为监控指标）：
步骤P101：所述机顶盒的盒端通过PING命令访问API认证服务器；
步骤P102：所述机顶盒的网络监控模块，根据返回的用户网络响应时间是否大于200ms作为诊断依据，如果小于，则提示PING正常；如果大于，则提示PING异常，用户访问公司的网络有问题，请及时联系当地客服工程师检查网络。
2） traceroute命令的连通性测试方法，包括以下步骤：
步骤S300：所述机顶盒采用traceroute命令对用户指定的域名地址向所述API认证服务器发送traceroute连通请求；
步骤S301：所述API认证服务器根据所述traceroute连通请求返回traceroute连通结果并在所述机顶盒上显示；
步骤S302 所述机顶盒根据所述traceroute连通结果对目的IP之间的路由进行逐跳统计，显示中间经过的跳数，每一跳的时延，以及每一跳的IP地址或者域名，如果出现无法连通到目的IP的状况，则可以显示路由节点测试中出现问题的跳点；
步骤S303 根据所述机顶盒的统计结果判断所述机顶盒与所述API认证服务器之间的网络连接状态。
例如，采用命令traceroute api.iptv.letv.com来测试机顶盒与API认证服务器之间的网络连接状态，其中api.iptv.letv.com是乐视网TV版在API认证服务器中的域名。用户指定目的域名，可以对目的IP之间的路由进行逐跳统计，显示中间经过的跳数，每一跳的时延，每一跳的IP地址或者域名。如果出现无法连通到目的IP的状况，路由节点测试可以显示在哪一跳出现了问题。对问题的排查可以起到较大的作用。
参见图6，这里以traceroute api.iptv.letv.com为例，例如可以采用如下具体的步骤来实现上述traceroute诊断过程：
步骤P201：盒端通过traceroute 命令对本地网络与API认证服务器间的路由进行逐跳统计
步骤P202：盒端网络监控模块，通过返回的网络信息进行故障诊断分析
详细网络信息如下：
tracert api.iptv.letv.com //traceroute命令发送traceroute连通请求
Tracing route to api.iptv.letv.com [115.182.94.249] //返回traceroute连通结果
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms localhost [192.168.0.1]
2 15 ms 11 ms 18 ms 123.116.112.1
3 7 ms 5 ms 2 ms 61.148.18.65
4 7 ms 5 ms 5 ms 123.126.6.61
5 6 ms 6 ms 5 ms 123.126.6.145
6 6 ms 5 ms 5 ms 124.65.60.18
7 6 ms 2 ms 4 ms 124.65.60.178
8 6 ms 6 ms 5 ms 211.154.208.10
9 7 ms 6 ms 9 ms 61.51.26.110
10 13 ms 7 ms 10 ms 124.202.11.10
11 9 ms 35 ms 6 ms 124.202.11.30
12 5 ms 7 ms 9 ms 124.202.128.98
13 7 ms 7 ms 7 ms 115.182.94.249
Trace complete.
1.当网络每一跳的时延大于200ms 或者 time out , 提示 traceroute 异常
2..当网络每一跳的时延小于200ms , 提示 traceroute 正常
步骤P203：当提示 traceroute 异常，盒端网络监控模块会提示：用户访问公司网络的路由有问题，请及时联系当地客服工程师检查网络；
步骤P204：点击详细按键，盒端网络监控模块会把通过traceroute 命令返回的详细网络信息，打印到相关页面上。
也即，所述traceroute命令的连通性测试过程，具体包括以下步骤（下面的步骤是对traceroute命令的连通性测试过程的具体说明，只采用用户网络路由间延时作为监控指标）：
步骤P201：所述机顶盒的盒端通过traceroute 命令对本地网络与API认证服务器间的路由进行逐跳统计；
步骤P202：所述机顶盒的网络监控模块根据返回的用户网络路由间延时是否大于200ms作为诊断依据，如果小于则提示traceroute 正常，如果大于则提示 traceroute异常，用户访问公司网络的路由有问题，请及时联系当地客服工程师检查网络。
（2）模式实现原型：如图7所述为网络诊断模式的实现原型图，其中，
1） 点击左选按钮，无反应；点击右选按钮，跳转到系统服务诊断模式。如果网络异常，则右选按键为灰色，不允许用户跳转选择。
2） 默认只展示ping ： 正常 详细
traceroute ： 异常 详细
3） 点击详细按钮，下方展示ping或traceroute详细信息。
如果网络异常的话，提示用户访问公司的网络有问题，请及时联系当地客服工程师检查网络。
2.系统服务诊断模式
（1）HTTP协议
HTTP，全称Hyper Text Transfer Protocol，中文名为超文本传输协议。HTTP是一种用于从Web服务器端传送超文本标记语言（HTML－Hyper Text Markup Language）文件到客户端浏览器的传送协议，它是Internet上最常见的协议之一。我们通常访问的网页，就是通过HTTP协议进行传送的。HTTP协议的主要特点可概括如下：a.支持客户/服务器模式。b.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。c.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。d.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。e.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
HTTP用名字标识某一资源时（即在浏览器中输入网址），遵循统一资源名（URN－Uniform Resource Name）的规则，当前网络中最常用的URN是统一资源定位符（URL－Uniform Resource Locator），当客户端在浏览器中输入一个URL或单击一个URL超链接时，就确定了要访问的地址。以http://www.colasoft.com.cn/resource/index.html为例介绍URL的组成：
1) http://：表示使用超文本传输协议，通知Web服务器显示Web页，客户端可不输入；
2) www：代表1个Web服务器；
3) colasoft.com.cn/：Web服务器的域名，或站点服务器的名称；
4) resource/：Web服务器上的子目录，类似机器中的文件夹；
5) index.html：Web服务器上resource子目录中的一个网页文件，即Web服务器传送给客户端浏览器的文件。
HTTP使用TCP协议的80端口进行可靠数据传输，一个HTTP会话由客户端开始发起，包括以下步骤：
1) 客户端在浏览器中标识希望获取信息的URL；
2) 发起HTTP连接请求，启动客户端（UA）和一个初始WWW服务器或代理服务器之间的一个HTTP会话；
3) WWW服务器或代理服务器根据客户端的URL请求将内容传送给客户端。
（2）HTTP协议工作方式
宏观工作方式：客户端（UA）到中介服务器的通讯路径如图6所示，客户端将请求发送给中介服务器1，中介服务器1将其发送中介服务器2，中介服务器2再发给Web服务器，最后客户端收到的内容由中介服务器1发送给它，而不是Web服务器。图6为客户端与中介服务器通讯过程。
内部操作过程：如图7所示，它分为四个步骤：建立连接、发出请求信息、发出响应信息、关闭连接。
（3）HTTP协议的报文格式
客户端发送的HTTP报文，我们称为请求链；中介服务器或Web服务器发送的HTTP报文，称为响应链。两种报文都遵循以下格式：
一般开始行，即请求报文的请求行和应答报文的状态行；
总头；
报文头；
一个空行；
报文体。
（4）HTTP访问流程
HTTP访问可以使用域名，也可直接使用IP地址，在使用IP进行访问时，将不会DNS数据包，故此HTTP流程图里未包括DNS部分，而直接从TCP的三次握手开始。
图8表示HTTP的访问流程如下：客户端向服务器发送一个TCP连接的SYN请求（1），服务器在收到此请求后使用一个SYN/ACK的数据包对其进行响应（2），而客户端在收到此响应后再次向其发送一个ACK数据包进行确认（3），此时，TCP连接成功建立。在连接建立后，客户端立即使用请求方法（通常为GET或POST）向服务器请求数据（4），一般情况下这时服务器会向客户端回应其相应的HTTP报头和数据（5），但在某些情况下（脚本比较复杂，需耗费大量时间执行）开始的时候只能返回HTTP的报头，而数据（6、7、N）可能会在相隔一段时间后再单独地分组进行传输，当数据传输完后，客户端发送FIN数据包关闭连接。
对应图8中的标识，1－2的时间表示客户端和服务器之间路由所用的时间，4－5的时间为服务器的响应时间、5－N（此时5只返回了HTTP报头）所用的时间为服务器上脚本程序所用的时间。科来网络分析系统5.0中，对于每个数据包都可查看其绝对时间和相对时间（设定某个数据包为基准），在遇到访问网页速度慢的情况时，捕获HTTP的访问并查看相应的时间，即可确定访问速度慢的原因并排查故障。
以上简单介绍了HTTP协议，并使用流程图分析了访问一个网页的具体流程。据此，用户在遇到网页访问故障时，即可结合上述的HTTP相关知识，对HTTP访问的报文进行跟踪分析，通过返回相应的状态值，以完成对此类故障的快速排查。
（5）模式概述
所述系统服务诊断模式，例如可以在机顶盒的盒端设置相应的系统服务监控模块，来实现上述的系统服务诊断功能（例如通过相应的芯片结构来实现该功能）。
所述系统服务诊断模式的诊断过程，包括以下步骤：
步骤S300：所述机顶盒采用HTTP协议格式访问API认证服务器和/或升级服务器的服务接口；
步骤S301：所述API认证服务器和/或升级服务器返回对应该服务接口的XML或者JSON数据格式的结果文件；
步骤S302 所述机顶盒根据所述结果文件判断连接所述API认证服务器和/或升级服务器是否正常：如果所述结果文件中有true，则正常，如果有false，则不正常。
参见图11，这里，以对letv进行系统服务诊断为例，例如可以采用如下具体的步骤来实现：
步骤P301：通过用HTTP协议方法访问认证服务器接口：
http://api.hdtv.letv.com:8080/iptv/api/getTestResult
通过用HTTP协议方法访问升级服务器接口：
http://upgrade.hdtv.letv.com:8080/tvosup/api/getTestResult
步骤P302：盒端系统服务监控模块，通过访问认证服务器接口和升级服务器接口返回XML数据格式，分析系统服务的状态。
具体返回XML格式如下：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<response>
<result>true（false)</result>
</response>
1.当访问认证服务器接口返回 true 时, 提示认证服务正常
当访问升级服务器接口返回 true 时，提示升级服务正常
2.当访问认证服务器接口返回 false时，提示认证服务异常，请及时联系当地客服工程师查询认证服务器服务；
当访问升级服务器接口返回 false 时，提示升级服务异常，请及时联系当地客服工程师查询升级服务器服务。
也即，所述系统服务诊断模式的诊断过程，具体包括以下步骤（下面的步骤是对系统服务诊断模式的具体说明）：
步骤P301：采用HTTP协议格式访问API认证服务器和/或升级服务器的服务接口；
步骤P302：所述机顶盒的系统服务监控模块通过返回的对应该服务接口的XML结果文件（getTestResult）的结果值来判断API认证服务器和/或升级服务器是否正常，如果返回true，则提示API认证服务器和/或升级服务器正常，如果返回false，则提示API认证服务和/或升级服务器异常，请及时联系当地客服工程师查询认证服务器和/或升级服务器的服务。
（6）模式实现原型
如图12所述为系统服务诊断模式的实现原型图，其中，点击左选按钮，跳转到网络诊断模式；点击右选按钮，跳转到应用服务诊断模式。
3.应用服务诊断模式
（1）模式概述
所述应用服务诊断模式，例如可以在机顶盒的盒端设置相应的应用服务监控模块，来实现上述的应用服务诊断功能（例如通过相应的芯片结构来实现该功能）。
所述应用服务诊断模式的诊断过程，包括以下步骤：
步骤S400：所述机顶盒采用HTTP协议格式访问应用服务接口；
步骤S401：所述应用服务接口返回对应该接口的不同状态的值；例如，所述应用服务接口返回对应该接口的XML格式的数据；
步骤S402 所述机顶盒根据所述返回的不同状态的值判断所述应用服务接口是否正常；例如，所述机顶盒根据所述返回的状态值（status）和错误码（errorcode)来判断所述应用服务接口是否正常。
例如，通过用HTTP协议方法访问应用服务接口，查看应用服务接口是否正常（接口根据实际需要可增减和命名），这里，例如对影迷俱乐部videozaixian的接口和时代光华videougc接口进行测试。参见图13。
1）影迷俱乐部videozaixian的接口：
http://www.videozaixian.com/api/play?id=2317&stream=1300&series=13
2）时代光华videougc接口：
http://www.videougc.com/tbc/play.do?id=2317&stream=1300&series=13
方法实现：所述机顶盒采用HTTP协议格式访问这两个应用服务接口，这两个应用服务接口返回对应该接口的不同状态的值，所述机顶盒通过返回的对应这些接口的不同状态的值，判断应用服务接口是否正常。
表1中是对返回状态值的具体描述：通过状态值，可以判断应用服务接口是否正常。
| 页面错误提示 | 错误原因 |
| 系统错误1 | -101：分配内存失败（保存XML的内存） |
| 网页错误1 | -102：获取播放XML失败 |
| 服务器错误 | -11：服务器报错，目前提示正常 |
| 播放地址错误 | -104：从播放XML到获取最终的播放URL地址过程出错。 |
| 播放错误1 | -105：协议类型不对：既不适合HTTP也不是RTSP |
| 网页错误2 | -106：播放XML中的status值不是1，播放XML格式不对。 |
表1
这里以对影迷俱乐部videozaixian的接口和时代光华videougc接口进行测试为例，例如可以采用如下步骤实现上述应用服务诊断过程：
步骤P401： 通过用HTTP协议方法访问影迷俱乐部应用服务接口： http://www.videozaixian.com/api/play?id=2317&stream=1300&series=13
通过用HTTP协议方法访问时代光华应用服务接口：
http://www.videougc.com/tbc/play.do?id=2317&stream=1300&series=13
步骤P402: 盒端应用服务监控模块，通过访问认证服务器接口和升级服务器接口返回XML数据格式，根据返回的状态值（status）和错误码（errorcode)，分析应用服务的状态。
具体返回XML格式如下：
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<response>
<status>1</status>
<errorcode>101</errorcode>
</response>
1. 当访问影迷俱乐部应用服务接口，返回 status = 0 ,errorcode = 0 提示 影迷俱乐部应用服务正常
当访问时代光华应用服务接口，返回 status = 0 ,errorcode = 0 提示 时代光华应用服务正常
2. 当访问影迷俱乐部应用服务接口，返回 status = 1 ， errorcode = 101 提示影迷俱乐部应用服务异常，系统错误--分配内存失败，请及时联系当地客服工程师进行解决
当访问影迷俱乐部应用服务接口，返回 status = 1 ， errorcode = 102 提示影迷俱乐部应用服务异常，网页错误--获取播放XML失败，请及时联系当地客服工程师进行解决
当访问影迷俱乐部应用服务接口，返回 status = 1 ， errorcode = 104 提示影迷俱乐部应用服务异常，播放地址错误--从播放XML到获取最终的播放URL地址过程出错，请及时联系当地客服工程师进行解决
当访问影迷俱乐部应用服务接口，返回 status = 1 ， errorcode = 105 提示影迷俱乐部应用服务异常，播放错误--协议类型不对，请及时联系当地客服工程师进行解决
当访问影迷俱乐部应用服务接口，返回 status = 1 ， errorcode = 106 提示影迷俱乐部应用服务异常，网页格式错误--播放XML格式不对，请及时联系当地客服工程师进行解决。
也即，所述应用服务诊断模式的诊断过程，具体包括以下步骤（下面的步骤是对应用服务诊断模式的具体说明和参数例举）：
步骤P401：采用HTTP协议格式访问应用服务器应用的服务接口；
步骤P402: 所述机顶盒的应用服务监控模块通过返回的对应该服务接口的XML结果文件来根据返回的状态值status和错误码errorcode分析应用服务的状态：
当访问应用服务接口，返回 status = 0 ,errorcode = 0，则提示应用服务正常；
当访问应用服务接口，返回 status = 1 ，errorcode =101，则提示应用服务异常，系统错误--分配内存失败，请及时联系当地客服工程师进行解决；
当访问应用服务接口，返回 status = 1 ，errorcode =102，则提示应用服务异常，网页错误--获取播放XML失败，请及时联系当地客服工程师进行解决；
当访问应用服务接口，返回 status = 1 ，errorcode =104，则提示应用服务异常，播放地址错误--从播放XML到获取最终的播放URL地址过程出错，请及时联系当地客服工程师进行解决；
当访问应用服务接口，返回 status = 1 ，errorcode =105，则提示应用服务异常，播放错误--协议类型不对，请及时联系当地客服工程师进行解决；
当访问应用服务接口，返回 status = 1 ，errorcode =106，则提示应用服务异常，网页格式错误--播放XML格式不对，请及时联系当地客服工程师进行解决。
3.访问时代光华应用服务接口返回的状态值（status）和错误码（errorcode)同上。
（2）模式实现原型
如图14所示为应用服务诊断模式实现原型图，其中，点击左选按钮，跳转到系统服务诊断模式；点击右选按钮，跳转到测速模式。
4.测速模式
（1）模式概述
所述测速模式，例如可以在机顶盒的盒端设置相应的测速模块，来实现上述的测速功能（例如通过相应的芯片结构来实现该功能）。
所述测速模式的诊断过程，包括以下步骤：
步骤S500：所述机顶盒下载并播放一定时长的视频；
步骤S501：所述机顶盒计算在线下载速度；
步骤S502：所述机顶盒根据所述下载速度，为用户选择不同的码流标准进行播放。
参见图15，例如，通过在机顶盒上播放一个开机的广告（3分钟左右），可以查看机顶盒在线下载速度，可以让用户预览到播放的效果，从而能让用户了解机顶盒所处网络的情况，机顶盒盒端根据测试到的下载速度，自动为用户选择不同的码流标准进行播放。
关于影片码流文件大小情况，最低网速需求，说明如下：
流畅：码率是350kb/s （清晰度一般） 最低网速需要512K
标清：码率是800kb/s 最低网速需要达到1M
高清：码率是1.3M/s 最低网速需要达到2M
720P：码率是1.8M/s 最低网速需要达到3M以上
1080P：码率是6M/s （15M/s）最低网速需要达到10M以上
这里以iptv为例，上述的测速模式例如可以采用如下步骤实现上述过程：
步骤P501：通过wget 命令下载一个视频文件 ad.flv 到盒端本地，测试当地环境的网络速度
具体方法如下所示：
wget -c test.iptv.letv.com/iptv/ad.flv //采用wget下载开机广告视频文件
--2012-07-31 16:21:51-- http://test.iptv.letv.com/iptv/ad.flv
Resolving test.iptv.letv.com... 123.126.32.143
Connecting to test.iptv.letv.com|123.126.32.143|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 92491776 (88M)
Saving to: 'ad.flv'
100%[======================================================================>] 92,491,776 26.7M/s in 3.3s
2012-07-31 16:21:55 (26.6 MB/s) - 'ad.flv' saved [92491776/92491776]
步骤P502： 盒端测速模块，会播放这个视频文件ad.flv ，并在旁边显示当前网络速度 26.6MB/s
步骤P503： 盒端测速模块，会根据当前网络速度，提示最佳的观看信息
当 512K/s < 网络速度 < 1MB/s 提示 请选择流畅模式观看影视内容
当 1MB/s < 网络速度 < 2MB/s 提示 请选择标清模式观看影视内容
当 2MB/s < 网络速度 < 3MB/s 提示 请选择高清模式观看影视内容
当 3MB/s < 网络速度 < 10MB/s 提示 请选择720P模式观看影视内容
当 网络速度 > 10MB/s 提示 请选择1080P模式观看影视内容。
也即，所述测速模式的诊断过程，具体包括以下步骤（下面的步骤是对应用服务诊断模式的具体说明和参数例举）：
步骤P501：通过wget命令从节点服务器下载开机广告视频文件到所述机顶盒；
步骤P502：所述机顶盒的测速模块边下载边播放开机广告，并通过返回的下载详细信息，根据当前网络速度，提示最佳的观看信息：
当 512K/s < 网络速度 < 1MB/s，则提示请选择流畅模式观看影视内容；
当 1MB/s < 网络速度 < 2MB/s，则提示请选择标清模式观看影视内容；
当 2MB/s < 网络速度 < 3MB/s，则提示请选择高清模式观看影视内容；
当 3MB/s < 网络速度 < 10MB/s，则提示请选择720P模式观看影视内容；
当 网络速度 > 10MB/s，则提示请选择1080P模式观看影视内容。
（2）模式实现原型
如图16所述为测速诊断模式的实现原型图，其中，
1） 点击左选按钮，跳转到应用服务诊断模式；点击右选按钮，无反应。
2） 根据提示的下载速度，机顶盒的盒端会自动为用户选择不同的码流标准进行播放，达到用户所体验的视觉效果是最优的。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明还可以通过其他结构来实现，本发明的特征并不局限于上述较佳的实施例。任何熟悉该项技术的人员在本发明的技术领域内，可轻易想到的变化或修饰，都应涵盖在本发明的专利保护范围之内。
Claims (17)
1.一种基于机顶盒的故障诊断方法，其特征在于，包括以下步骤：
A 机顶盒开机步骤：
步骤S100：所述机顶盒开机；
步骤S101：通过开机设置文件中缺省的认证服务器地址访问API（应用程序编程接口）认证服务器，向所述API认证服务器发送请求；
步骤S102：所述API认证服务器通过调用用户中心接口，判断所述机顶盒的MAC（媒体接入控制）是否是合法用户：如果是，则转入步骤S103；如果否，则转入步骤S101；
步骤S103：从所述API认证服务器中取得该用户的分组信息，并将相关资源的域名地址生成预置文件返回所述机顶盒，认证过程完成；
步骤S104：所述机顶盒根据所述预置文件中取得的相关资源的域名地址访问相关的服务，并通过调用相关系统和应用服务接口，显示服务的状态；
B，故障诊断步骤：选择所述机顶盒的故障诊断模式并执行，所述故障诊断模式包括系统服务诊断模式，所述系统服务诊断模式的诊断过程，包括以下步骤：
步骤S300：所述机顶盒采用HTTP协议格式访问API认证服务器和/或升级服务器的服务接口；
步骤S301：所述API认证服务器和/或升级服务器返回对应该服务接口的XML或者JSON数据格式的结果文件；
步骤S302 所述机顶盒根据所述结果文件判断连接所述API认证服务器和/或升级服务器是否正常：如果所述结果文件中有true，则正常，如果有false，则不正常；
其中，步骤B中的所述故障诊断模式还包括测速模式，所述测速模式的诊断过程，包括以下步骤：
步骤S500：所述机顶盒下载并播放一定时长的视频；
步骤S501：所述机顶盒计算在线下载速度；
步骤S502：所述机顶盒根据所述下载速度，为用户选择不同的码流标准进行播放。
2.如权利要求1所述的方法，其特征在于，步骤B中的所述故障诊断模式还包括应用服务诊断模式，所述应用服务诊断模式的诊断过程，包括以下步骤：
步骤S400：所述机顶盒采用HTTP协议格式访问应用服务接口；
步骤S401：所述应用服务接口返回对应该接口的不同状态的值；
步骤S402 所述机顶盒根据所述返回的不同状态的值判断所述应用服务接口是否正常。
3.如权利要求1或2所述的方法，其特征在于，步骤B中的所述故障诊断模式还包括网络诊断模式，所述网络诊断模式包括PING命令的连通性测试过程，具体包括以下步骤：
步骤S200：所述机顶盒采用PING命令对用户指定的域名地址向所述API认证服务器发送PING连通请求；
步骤S201：所述API认证服务器根据所述PING连通请求返回PING连通结果并在所述机顶盒上显示；
步骤S202 所述机顶盒根据所述PING连通结果统计ping包的成功次数、ping包的丢包次数、ping包的丢包率和ping包的平均响应时间；
步骤S203 根据所述机顶盒的PING连通统计结果判断所述机顶盒与所述API认证服务器之间的网络连接状态。
4.如权利要求1所述的方法，其特征在于，步骤B中的所述故障诊断模式还包括网络诊断模式，所述网络诊断模式包括PING命令的连通性测试过程，具体包括以下步骤：
步骤S200：所述机顶盒采用PING命令对用户指定的域名地址向所述API认证服务器发送PING连通请求；
步骤S201：所述API认证服务器根据所述PING连通请求返回PING连通结果并在所述机顶盒上显示；
步骤S202 所述机顶盒根据所述PING连通结果统计ping包的成功次数、ping包的丢包次数、ping包的丢包率和ping包的平均响应时间；
步骤S203 根据所述机顶盒的PING连通统计结果判断所述机顶盒与所述API认证服务器之间的网络连接状态。
5.如权利要求1或2或4所述的方法，其特征在于，步骤B中的所述故障诊断模式还包括网络诊断模式，所述网络诊断模式包括traceroute命令的连通性测试过程，具体包括以下步骤：
步骤S300：所述机顶盒采用traceroute命令对用户指定的域名地址向所述API认证服务器发送traceroute连通请求；
步骤S301：所述API认证服务器根据所述traceroute连通请求返回traceroute连通结果并在所述机顶盒上显示；
步骤S302 所述机顶盒根据所述traceroute连通结果对目的IP之间的路由进行逐跳统计，显示中间经过的跳数，每一跳的时延，以及每一跳的IP地址或者域名，如果出现无法连通到目的IP的状况，则显示路由节点测试中出现问题的跳点；
步骤S303 根据所述机顶盒的traceroute连通统计结果判断所述机顶盒与所述API认证服务器之间的网络连接状态。
6.如权利要求3所述的方法，其特征在于，步骤B中的所述故障诊断模式还包括网络诊断模式，所述网络诊断模式包括traceroute命令的连通性测试过程，具体包括以下步骤：
步骤S300：所述机顶盒采用traceroute命令对用户指定的域名地址向所述API认证服务器发送traceroute连通请求；
步骤S301：所述API认证服务器根据所述traceroute连通请求返回traceroute连通结果并在所述机顶盒上显示；
步骤S302 所述机顶盒根据所述traceroute连通结果对目的IP之间的路由进行逐跳统计，显示中间经过的跳数，每一跳的时延，以及每一跳的IP地址或者域名，如果出现无法连通到目的IP的状况，则显示路由节点测试中出现问题的跳点；
步骤S303 根据所述机顶盒的traceroute连通统计结果判断所述机顶盒与所述API认证服务器之间的网络连接状态。
7.如权利要求1或2或4或6所述的方法，其特征在于，所述机顶盒包括IPTV机顶盒。
8.如权利要求1或2或4或6所述的方法，其特征在于，所述机顶盒采用TR069协议。
9.如权利要求3所述的方法，其特征在于，所述PING命令的连通性测试过程，具体包括以下步骤：
步骤P101：所述机顶盒的盒端通过PING命令访问API认证服务器；
步骤P102：所述机顶盒的网络监控模块，根据返回的用户网络响应时间是否大于200ms作为诊断依据：如果是，则PING正常，证明当地网络正常；否则，则PING异常，证明当地网络异常，并根据诊断结果提示用户进行相应的操作。
10.如权利要求5所述的方法，其特征在于，所述traceroute命令的连通性测试过程，具体包括以下步骤：
步骤P201：所述机顶盒的盒端通过traceroute 命令对本地网络与API认证服务器间的路由进行逐跳统计；
步骤P202：所述机顶盒的网络监控模块根据返回的用户网络路由间延时是否大于200ms作为诊断依据：如果是，则traceroute正常，证明当地网络正常；否则，则traceroute异常，证明当地网络异常，并根据诊断结果提示用户进行相应的操作。
11.如权利要求1或2或4或6，9-10任一项所述的方法，其特征在于，所述系统服务诊断模式的诊断过程，具体包括以下步骤：
步骤P301：采用HTTP协议格式访问API认证服务器和/或升级服务器的服务接口；
步骤P302：所述机顶盒的系统服务监控模块通过返回的对应该服务接口的XML结果文件（getTestResult)的结果值来判断API认证服务器和/或升级服务器是否正常：如果返回true，则提示API认证服务器和/或升级服务器正常，如果返回false，则提示API认证服务和/或升级服务器异常，并根据诊断结果提示用户进行相应的操作。
12.如权利要求1或2或4或6，9-10任一项所述的方法，其特征在于，所述应用服务诊断模式的诊断过程，具体包括以下步骤：
步骤P401：采用HTTP协议格式访问应用服务器应用的服务接口；
步骤P402: 所述机顶盒的应用服务监控模块通过返回的对应该服务接口的XML结果文件来根据返回的状态值status和错误码errorcode分析应用服务的状态。
13.如权利要求1所述的方法，其特征在于，所述测速模式的诊断过程，具体包括以下步骤：
步骤P501：通过wget命令从节点服务器下载开机广告视频文件到所述机顶盒；
步骤P502：所述机顶盒的测速模块边下载边播放开机广告，并通过返回的下载详细信息，根据当前网络速度的不同，显示不同的观看模式供用户选择。
14.一种应用如权利要求1-13任一项所述方法的基于机顶盒的故障诊断系统，包括机顶盒和API认证服务器，所述API认证服务器采用如权利要求1-13任一项所述方法对所述机顶盒进行故障诊断，所述机顶盒包括网络监控模块、系统服务监控模块、应用服务监控模块和测速模块，分别用于执行网络诊断模式、系统服务诊断模式、应用服务诊断模式和测速模式。
15.如权利要求14所述的系统，所述系统的机顶盒还包括TR 069子系统，所述TR 069子系统划分为3个模块：TR069协议栈模块、任务执行模块和NAT穿越模块，其中所述NAT穿越模块主要负责发送基于UDP的Binding Request消息，并能解析STUN服务器返回的Binding Response消息；所述TR069协议栈模块根据TR069协议规定的流程与ACS通信，解析ACS下发的各个RPC方法，并封装上报机顶盒的各个应答；所述任务执行模块负责完成TR069协议栈模块解析出来的各个任务，并将执行结果通过任务队列返回给所述TR069协议栈模块。
16.如权利要求15所述的系统，所述TR069协议栈模块包括摘要认证、Inform消息上报、解析任务和心跳发送子模块；所述任务执行模块主要包括获取参数模型、获取参数值、设置参数值、重启和日志上传子模块。
17.如权利要求14-16任一项所述的系统，其特征在于，所述机顶盒包括IPTV机顶盒。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210343296.8A CN102857799B (zh) | 2012-09-14 | 2012-09-14 | 基于机顶盒的故障诊断方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210343296.8A CN102857799B (zh) | 2012-09-14 | 2012-09-14 | 基于机顶盒的故障诊断方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102857799A CN102857799A (zh) | 2013-01-02 |
| CN102857799B true CN102857799B (zh) | 2015-08-26 |
Family
ID=47403931
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201210343296.8A Expired - Fee Related CN102857799B (zh) | 2012-09-14 | 2012-09-14 | 基于机顶盒的故障诊断方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102857799B (zh) |
Families Citing this family (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103354519B (zh) * | 2013-06-27 | 2018-01-16 | 上海斐讯数据通信技术有限公司 | 一种跟踪详细路由信息的方法 |
| CN103596060A (zh) * | 2013-11-20 | 2014-02-19 | 乐视致新电子科技（天津）有限公司 | 一种信息提示方法及装置 |
| CN103618716B (zh) * | 2013-11-28 | 2017-01-18 | 福建星网锐捷网络有限公司 | 一种终端广域网管理协议会话交互方法、设备和系统 |
| CN103747330B (zh) * | 2013-12-24 | 2017-09-29 | 深圳市九洲电器有限公司 | 一种程序监控方法、装置及数字电视接收终端 |
| CN105530110B (zh) * | 2014-09-30 | 2019-07-23 | 华为技术有限公司 | 一种网络故障检测方法以及相关网元 |
| CN104333805B (zh) * | 2014-10-29 | 2018-04-24 | 深圳市同洲电子股份有限公司 | 一种机顶盒诊断方法及相关设备 |
| CN106330496A (zh) * | 2015-06-24 | 2017-01-11 | 中兴通讯股份有限公司 | 一种诊断网络管理状态的方法、设备和网络侧设备 |
| CN106559230A (zh) * | 2015-09-25 | 2017-04-05 | 中国移动通信集团公司 | 一种故障处理方法、装置及系统 |
| CN105656674B (zh) * | 2016-01-19 | 2019-07-12 | 成都卓影科技股份有限公司 | 一种iptv专网和互联网的双网访问方法 |
| CN107801060A (zh) * | 2016-03-25 | 2018-03-13 | 乐视控股（北京）有限公司 | 在线视频的播放方法及装置 |
| CN105978758B (zh) * | 2016-06-23 | 2019-01-04 | 深圳创维数字技术有限公司 | 一种机顶盒的voip测试方法及系统 |
| CN106303753A (zh) * | 2016-08-04 | 2017-01-04 | 青岛海信电器股份有限公司 | 播放网络视频的方法及装置 |
| CN106850337B (zh) * | 2016-12-29 | 2020-07-03 | 中兴通讯股份有限公司 | 一种网络质量检测方法及装置 |
| CN107172420B (zh) * | 2017-06-23 | 2018-11-02 | 天津市德力电子仪器有限公司 | Iptv和ott机顶盒质量自动化测试方法 |
| CN107590071B (zh) * | 2017-08-25 | 2021-05-11 | 湖南国科微电子股份有限公司 | 机顶盒测试用的码流文件的数据修改方法及装置 |
| CN107395462B (zh) * | 2017-08-30 | 2021-08-10 | 深圳市瑞研通讯设备有限公司 | 一种iptv测试仪 |
| CN107864377A (zh) * | 2017-11-08 | 2018-03-30 | 山东浪潮商用系统有限公司 | 一种机顶盒的健康状态查看方法及机顶盒 |
| CN110719184A (zh) * | 2018-07-13 | 2020-01-21 | 深圳市于易点科技有限公司 | 一种网络阻塞故障的判断方法和系统 |
| CN109874025A (zh) * | 2019-03-05 | 2019-06-11 | 山东浪潮商用系统有限公司 | 一种直播、时移和回看功能的监控方法及装置 |
| CN110430100B (zh) * | 2019-08-27 | 2021-06-04 | 中国工商银行股份有限公司 | 网络连通性探测方法和装置 |
| CN110582035B (zh) * | 2019-08-30 | 2022-05-13 | 武汉长光科技有限公司 | 一种利用宽带普遍服务管理平台对onu进行升级的方法 |
| CN112492301B (zh) * | 2020-12-02 | 2022-11-01 | 湖南快乐阳光互动娱乐传媒有限公司 | 一种iptv机顶盒的性能测试方法及系统 |
| CN114024895B (zh) * | 2021-11-16 | 2022-07-29 | 中电信数智科技有限公司 | 一种基于tr069的网络路线优化方法和系统 |
| CN117294836B (zh) * | 2023-11-27 | 2024-02-09 | 天津泰达有线电视网络有限公司 | 一种机顶盒安全认证及故障分析方法和系统 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101072328A (zh) * | 2007-06-19 | 2007-11-14 | 中兴通讯股份有限公司 | 切换流媒体服务器的方法及系统 |
| CN101184204A (zh) * | 2007-12-25 | 2008-05-21 | 天柏宽带网络科技（北京）有限公司 | 一种互动电视业务中认证方法 |
| CN101431648A (zh) * | 2008-12-11 | 2009-05-13 | 北京东方广视科技有限责任公司 | 一种有线电视vod备份的方法、系统和设备 |
| CN101635703A (zh) * | 2008-07-24 | 2010-01-27 | 北京启明星辰信息技术股份有限公司 | 一种web服务异常检测方法 |
| CN101984583A (zh) * | 2010-11-23 | 2011-03-09 | 中兴通讯股份有限公司 | 一种对单播类节目播放异常进行故障定位的方法及系统 |
| CN102421023A (zh) * | 2010-09-27 | 2012-04-18 | 中国电信股份有限公司 | Iptv机顶盒、iptv测试方法和模块 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100351817B1 (ko) * | 2000-01-13 | 2002-09-11 | 엘지전자 주식회사 | 오픈케이블 수신 시스템 및 시스템 진단 방법 |
-
2012
- 2012-09-14 CN CN201210343296.8A patent/CN102857799B/zh not_active Expired - Fee Related
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101072328A (zh) * | 2007-06-19 | 2007-11-14 | 中兴通讯股份有限公司 | 切换流媒体服务器的方法及系统 |
| CN101184204A (zh) * | 2007-12-25 | 2008-05-21 | 天柏宽带网络科技（北京）有限公司 | 一种互动电视业务中认证方法 |
| CN101635703A (zh) * | 2008-07-24 | 2010-01-27 | 北京启明星辰信息技术股份有限公司 | 一种web服务异常检测方法 |
| CN101431648A (zh) * | 2008-12-11 | 2009-05-13 | 北京东方广视科技有限责任公司 | 一种有线电视vod备份的方法、系统和设备 |
| CN102421023A (zh) * | 2010-09-27 | 2012-04-18 | 中国电信股份有限公司 | Iptv机顶盒、iptv测试方法和模块 |
| CN101984583A (zh) * | 2010-11-23 | 2011-03-09 | 中兴通讯股份有限公司 | 一种对单播类节目播放异常进行故障定位的方法及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102857799A (zh) | 2013-01-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102857799B (zh) | 基于机顶盒的故障诊断方法 | |
| US9838895B2 (en) | Method and apparatus to analyze a wireless information delivery system | |
| CN102143389B (zh) | Iptv服务质量保障系统及质量保障方法 | |
| US8964572B2 (en) | Determining quality of experience with a network device | |
| US11863420B2 (en) | Diagnosing faults in a multimedia over coax alliance (MoCA) local area network (LAN) including a WiFi segment | |
| US8806550B1 (en) | Rules engine for troubleshooting video content delivery network | |
| US8677425B2 (en) | Method and system for implementing interaction between set-top box (STB) and home gateway | |
| CA2707170C (en) | Testing a content-delivery system | |
| US8660021B2 (en) | Network diagnostics | |
| CN102421023B (zh) | Iptv机顶盒、iptv测试方法和模块 | |
| US8045476B2 (en) | Apparatus and method for managing a network | |
| US20090319656A1 (en) | Apparatus and method for managing a network | |
| CN101605073A (zh) | 一种对iptv用户终端进行测试的方法、装置及系统 | |
| US20120210350A1 (en) | Method and apparatus for identifying available iptv devices on a network | |
| US20090064255A1 (en) | System and method of providing performance data | |
| US20100027412A1 (en) | System and method for service restoration in a media communication system | |
| KR102496890B1 (ko) | 정보 처리 장치, 클라이언트 장치, 및 데이터 처리 방법 | |
| US10187702B2 (en) | Systems and methods to test media devices | |
| US10382314B2 (en) | Systems and methods for automated testing of MoCA networks | |
| KR20090083344A (ko) | 서비스 방해 소스를 표시하는 방법 | |
| US20090049487A1 (en) | Router apparatus and network trouble determining method | |
| CN103369403B (zh) | 机顶盒点播包分析系统和分析方法 | |
| CN106301989A (zh) | Iptv业务检测方法及装置 | |
| JP5425389B2 (ja) | ビデオオンデマンド・セッションを回復する方法 | |
| CN102984026A (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 | ||
| ASS | Succession or assignment of patent right |
Owner name: LESHI ZHIXIN ELECTRONIC TECHNOLOGY (TIANJIN) CO., Free format text: FORMER OWNER: LETV INFORMATION TECHNOLOGY (BEIJING) CO., LTD. Effective date: 20130520 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| COR | Change of bibliographic data |
Free format text: CORRECT: ADDRESS; FROM: 100026 HAIDIAN, BEIJING TO: 300467 TANGGU, TIANJIN |
|
| TA01 | Transfer of patent application right |
Effective date of registration: 20130520 Address after: 300467, Tianjin District, Tianjin City, Tanggu animation road 126 No. 201-427 animation building B1 district two Applicant after: LESHI ZHIXIN ELECTRONIC SCIENCE & TECHNOLOGY (TIANJIN) CO., LTD. Address before: Room six, building 19, building 68, No. 100026 South Road, Haidian District, Beijing Applicant before: LeTV Information Technology (Beijing) Co., Ltd. |
|
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20150826 Termination date: 20170914 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |