CN104954187A - 一种确定用户侧设备状态的方法和装置 - Google Patents

Abstract

本申请提供一种确定用户侧设备状态的方法，包括：用户侧设备CPE通过预定的第一端口接收第一状态请求报文，或者，CPE通过预定的第二端口接收第二状态请求报文，或者，CPE通过预定的第一端口及特定的URL接收第三状态请求报文；所述CPE对所述第一状态请求报文携带的错误的用户信息验证失败后回复状态应答报文，指示自身状态为可达；所述CPE直接针对所述第二状态请求报文或第三状态请求报文回复状态应答报文，指示自身状态为可达；所述CPE对所述第二状态请求报文或第三状态请求报文携带的用户信息验证后，回复状态应答报文，指示自身状态为可达。本申请还提供一种确定用户侧设备状态的装置。

Description

一种确定用户侧设备状态的方法和装置

技术领域

本申请涉及通信技术领域，尤其涉及一种确定用户侧设备状态的方法和装置。

背景技术

TR-069协议又称为用户侧终端广域网管理协议，它提供了对用户侧终端设备进行管理配置的通用框架、消息规范、管理方法和数据模型。TR-069协议主要由自动配置服务器(ACS，Auto-Configuration Server)、用户侧设备(CPE，Customer Premise Equipment)、业务配置管理服务器以及一些必要的管理接口组成。

在传统的SNMP网管系统中，一般使用ping报文来轮询设备的状态，确定设备是否可达。网管服务器定期向设备发送ping报文，根据报文返回结果更新设备的状态。在TR-069协议中，具备网管服务器功能的ACS需要定期轮询CPE的状态，由于TR-069协议是一种广域网管理协议，ACS和CPE都在公网中，两者之间一般都有防火墙，而ping报文使用ICMP协议，不能穿越防火墙，因此，TR-069协议给出了一个标准的TR069交互过程，以实现ACS轮询CPE的状态。

在上述标准的TR069交互过程中，ACS在获知了CPE的状态后，还需要再进行与状态轮询无关的Inform报文和Inform Response报文的交互。而这两种报文所需的流量比较大，大约有5K字节，如果CPE的数量比较多，那么ACS用于轮询CPE状态的流量中有相当大的一部分是不必要的。

发明内容

有鉴于此，本申请提供一种确定用户侧设备状态的方法和装置，用于解决在获取CPE状态的同时避免Inform报文的交互过程的技术问题。

基于本发明实施例，提出一种确定用户侧设备状态的方法，所述方法包括：

用户侧设备CPE通过预定的支持HTTP服务的默认端口即第一端口接收第一状态请求报文，对所述第一状态请求报文携带的错误的用户信息验证失败后回复状态应答报文，指示自身状态为可达；或

CPE通过预定的专用于检测CPE状态的第二端口接收第二状态请求报文，直接针对所述第二状态请求报文回复状态应答报文，指示自身状态为可达，或者，对所述第二状态请求报文携带的用户信息验证后，回复状态应答报文，指示自身状态为可达；或

CPE通过预定的支持HTTP服务的默认端口即第一端口及专用于检测CPE状态的特定的统一资源定位符URL接收第三状态请求报文，直接针对所述第三状态请求报文回复状态应答报文，指示自身状态为可达，或者，对所述第三状态请求报文携带的用户信息验证后，回复状态应答报文，指示自身状态为可达。

基于本发明实施例，提出一种确定用户侧设备状态的装置，应用于用户侧设备，所述装置包括：

接收模块，用于通过预定的支持HTTP服务的默认端口即第一端口接收第一状态请求报文；或用于通过预定的专用于检测CPE状态的第二端口接收第二状态请求报文；或用于通过预定的支持HTTP服务的默认端口即第一端口及专用于检测CPE状态的特定的URL接收第三状态请求报文；

验证模块，用于对所述第一状态请求报文携带的错误的用户信息验证失败后，通知所述发送模块；或用于对所述第二状态请求报文或第三状态请求报文携带的用户信息验证后，通知所述发送模块；

所述发送模块，用于根据所述通知，回复状态应答报文，指示所述用户侧设备状态为可达；或用于直接针对所述第二状态请求报文或第三状态请求报文回复状态应答报文，指示自身状态为可达。

在本发明实施例公开的用户侧设备状态的方法和装置中，使用默认的支持HTTP服务的端口时，用户信息验证失败，CPE向ACS回复状态应答报文；使用第二端口时，或者，使用默认的支持HTTP服务的端口，但是使用了特定的URL来检测CPE的状态时，CPE接收到状态请求报文，不验证直接回复一个状态应答报文，或者，无论验证成功或失败，均回复一个状态应答报文。在标准TR069交互过程中，必须是使用默认的支持HTTP服务的端口、且用户信息验证成功时，才回复状态应答报文，并且Inform报文的触发需要符合两个条件：使用默认的支持HTTP服务的端口和用户信息验证成功，而本发明实施例上述三种实现方式，均未同时符合上述两个条件，因此能够避免Inform报文的触发，节省了流量。

附图说明

图1是本发明实施例示出的确定用户侧设备状态方法的流程图；

图2是本发明实施例示出的确定用户侧设备状态装置的结构图；

图3是本发明实施例示出的一种用户侧设备的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在标准TR069协议中，确定用户侧设备CPE状态的交互过程如下：

步骤1、CPE在一个端口开放HTTP服务，默认是7547端口；

步骤2、ACS需要更新CPE的状态时，向CPE的7547端口发送HTTP GET报文，携带预先在ACS和CPE上配置的CPE的用户信息，例如用户名和/或密码；

步骤3、如果CPE已经down掉，则无法收到以及响应ACS发送的HTTPGET报文，ACS的HTTP GET报文请求超时，认为CPE不可达，将CPE的状态更新为不可达；

步骤4、CPE收到HTTP GET报文，CPE上配置的用户信息与HTTP GET报文中的用户信息不一致，则网管系统无法正常工作，这种情况不做考虑；

步骤5、CPE运行正常，收到ACS发送的HTTP GET报文，用户信息验证通过，则回复HTTP STATUS 200OK的空报文，此时，ACS认为CPE可达，将CPE的状态更新为可达。

步骤6、按照TR069协议定义，CPE回复HTTP STATUS 200OK的空报文后，继续向ACS发送CONNECTION REQUEST的Inform报文，ACS向CPE回复Inform Response报文。然后，CPE向ACS发送空报文请求任务执行，ACS发现没有需要CPE执行的任务时，回复HTTP STATUS 204NO_CONTENT报文，通知CPE没有任务需要执行。

上述过程中，步骤6对于确定CPE状态这一目的来说不是必要的步骤。整个步骤6需要的流量大约5k字节，由于ACS和CPE都位于公网，因此用户往往对流量使用比较关注。如果用户希望在CPE不可达时尽早知道，则会把状态的轮询间隔设的比较短，如果CPE数量比较多，那么ACS用于轮询CPE状态的流量是相当可观的，且其中步骤6所消耗的流量是不必要的。

鉴于上述存在的技术问题，本发明实施例提供的技术方案如下：一实施例提供一种确定用户侧设备状态的方法，参考图1所示，该方法包括：

步骤101，CPE通过预定的第一端口接收第一状态请求报文时，对所述第一状态请求报文携带的错误的用户信息验证失败后，回复状态应答报文，指示自身状态为可达。

其中，第一端口为支持HTTP服务的默认端口。

步骤102，CPE通过预定的第二端口接收第二状态请求报文时，直接针对所述第二状态请求报文回复状态应答报文，指示自身状态为可达，或者，对所述第二状态请求报文携带的用户信息验证后，回复状态应答报文，指示自身状态为可达。

其中，第二端口配置为专用于检测CPE状态。

所述第二状态请求报文携带正确或者错误的用户信息，所述CPE对正确的用户信息验证成功后，或者，对错误的用户信息验证失败后，均回复状态应答报文。

步骤103，CPE通过预定的第一端口及特定的统一资源定位符URL接收第三状态请求报文时，直接针对所述第三状态请求报文回复状态应答报文，指示自身状态为可达，或者，对所述第三状态请求报文携带的用户信息验证后，回复状态应答报文，指示自身状态为可达。

其中，特定的统一资源定位符(URL，Uniform Resource Locator)配置为专用于检测CPE状态。

所述第三状态请求报文携带正确或者错误的用户信息，所述CPE对正确的用户信息验证成功后，或者，对错误的用户信息验证失败后，均回复状态应答报文。

上述步骤101－103的执行不分先后。

回复状态应答报文后，如果ACS需要CPE执行任务，如部署配置、部署软件时，CPE会从上述第一端口接收携带正确用户信息的状态请求报文，用户信息验证成后，回复状态应答报文，同时触发后续的Inform和InformResponse报文交互(该流程即为上述标准的TR069交互过程)，并执行部署任务的流程。

下面通过一个详细的实施例来说明通过预定的第一端口接收第一状态请求报文的实现过程：

步骤a1、CPE在一个端口开放HTTP服务，例如默认为7547端口；

步骤a 2、ACS需要更新CPE的状态时，向CPE的7547端口发送HTTPGET报文、即第一状态请求报文，携带与事先在ACS和CPE上配置的用户信息不同的用户信息(即错误的用户信息)，比如一个随机生成的字符串；

步骤a 3、如果CPE已经down掉，则无法收到以及响应ACS发送的HTTPGET报文，ACS的HTTP GET报文请求超时，ACS认为CPE不可达，将CPE的状态更新为不可达；

步骤a 4、如果CPE运行正常，收到ACS发送的HTTP GET报文，因为HTTP GET报文中携带了错误的用户信息，则用户信息验证失败，CPE回复HTTP STATUS 401UNAUTHORIZED的空报文、即状态应答报文，此时，ACS认为CPE可达，将CPE的状态更新为可达。

在该流程中，虽然使用了默认的支持HTTP服务的端口，但是由于用户信息验证失败，则CPE不会按照标准的TR069交互流程执行，在回复了状态应答报文后，不向ACS发送Inform报文，避免了不必要的Inform报文和Inform Response报文交互过程，节省了网络流量。整个过程消耗的流量不到100字节。

如果ACS需要CPE执行任务，如部署配置、部署软件时，则ACS使用正确的用户信息重新向CPE的7547端口发送HTTP GET报文，触发后续的Inform和Inform Response报文交互(该流程即为上述标准的TR069交互过程)，并执行部署任务的流程。

下面通过一个详细的实施例来说明通过预定的第二端口接收第二状态请求报文的实现过程：

步骤b1、CPE在一个端口配置专用于检测状态，例如为7548端口；

步骤b2、ACS需要更新CPE的状态时，向CPE的7548端口发送HTTPGET报文、即第二状态请求报文，携带正确或者错误的用户信息均可；

步骤b3、如果CPE已经down掉，则无法收到以及响应ACS发送的HTTPGET报文，ACS的HTTP GET报文请求超时，认为CPE不可达，将CPE的状态更新为不可达；

步骤b4、如果CPE运行正常，收到ACS发送的HTTP GET报文，此时的处理方式有以下的情形：

A、进行用户信息的验证，如果验证通过，则向ACS回复HTTP STATUS200OK空报文、即状态应答报文；如果验证失败，则向ACS回复HTTPSTATUS 401UNAUTHORIZED空报文、即状态应答报文；

B、CPE确认是通过7548端口收到HTTP GET报文，则不进行用户信息的验证，直接向ACS回复HTTP STATUS 200OK空报文、即状态应答报文；

步骤b 5、ACS接收到HTTP STATUS 200OK空报文或HTTP STATUS401UNAUTHORIZED空报文，均认为CPE可达，将CPE的状态更新为可达。

在该流程中，由于使用不是默认的支持HTTP服务的端口，因此不会按照标准的TR069交互流程执行，在回复状态应答报文后，不向ACS发送Inform报文，避免了不必要的Inform报文和Inform Response报文交互过程，节省了网络流量。整个过程消耗的流量不到100字节。

如果ACS需要CPE执行其他任务，如部署配置、部署软件时，则ACS使用正确的用户信息重新向CPE默认的支持HTTP服务的端口(例如，7547端口)发送HTTP GET报文，触发后续的Inform和Inform Response报文交互(该流程即为上述标准的TR069交互过程)，并执行部署任务的流程。

下面通过一个详细的实施例来说明通过预定的第一端口及特定的URL接收第三状态请求报文的实现过程：

步骤c1、CPE在一个端口开放HTTP服务，例如默认为7547端口，同时，配置一个专门用于检测CPE状态的URL，例如，CPE的通用URL为http://1.1.1.1:7547，配置的专门用于检测状态的URL为http://1.1.1.1:7547/statuspoll/statuspoll；

步骤c2、ACS需要更新CPE的状态时，使用URLhttp://1.1.1.1:7547/statuspoll/statuspoll访问CPE的7547端口，即向CPE的7547端口发送HTTP GET报文、即第三状态请求报文，使用的URL为http://1.1.1.1:7547/statuspoll/statuspoll，第三状态请求报文携带正确或者错误的用户信息均可；

步骤c3、如果CPE已经down掉，则无法收到以及响应ACS发送的HTTPGET报文，ACS的HTTP GET报文请求超时，认为CPE不可达，将CPE的状态更新为不可达；

步骤c4、如果CPE运行正常，收到ACS发送的HTTP GET报文，此时的处理方式有以下的情形：

A、进行用户信息的验证，如果验证通过，则向ACS回复HTTP STATUS200OK空报文、即状态应答报文；如果验证失败，则向ACS回复HTTPSTATUS 401UNAUTHORIZED空报文、即状态应答报文；

B、CPE确认是通过特定的URL收到HTTP GET报文，则不进行用户信息的验证，直接向ACS回复HTTP STATUS 200OK空报文、即状态应答报文；

步骤c5、ACS接收到HTTP STATUS 200OK空报文或HTTP STATUS401UNAUTHORIZED空报文，均认为CPE可达，将CPE的状态更新为可达。

在该流程中，虽然使用了默认的支持HTTP服务的端口，但是，使用了特定的URL来检测CPE的状态，因此不会按照标准的TR069交互流程执行，在回复了状态应答报文后，不向ACS发送Inform报文，避免了不必要的Inform报文和InformResponse报文交互过程，节省了网络流量。整个过程消耗的流量不到100字节。

如果ACS需要CPE执行其他任务，如部署配置、部署软件时，则ACS使用正确的用户信息重新向CPE默认的支持HTTP服务的端口(例如，7547端口)发送HTTP GET报文，触发后续的Inform和Inform Response报文交互(该流程即为上述标准的TR069交互过程)，并执行部署任务的流程。

为了实现上述方法，在一实施例中提供了一种确定用户侧设备状态的装置20，如图2所示，应用于用户侧设备，包括：接收模块21、验证模块22和发送模块23，其中：

接收模块21，用于通过预定的第一端口接收第一状态请求报文，还用于通过预定的第二端口接收第二状态请求报文，还用于通过预定的第一端口及特定的URL接收第三状态请求报文；

验证模块22，用于对所述第一状态请求报文携带的错误的用户信息验证失败后，通知所述发送模块23；还用于对所述第二状态请求报文或第三状态请求报文携带的用户信息验证后，通知所述发送模块23；

所述发送模块23，用于根据所述通知，回复状态应答报文，指示所述用户侧设备状态为可达；还用于直接针对所述第二状态请求报文或第三状态请求报文回复状态应答报文，指示自身状态为可达。

其中，所述第一端口为支持HTTP服务的默认端口；

所述特定的URL配置为专用于检测CPE状态；

所述第二端口配置为专用于检测CPE状态。

其中，所述第二状态请求报文或第三状态请求报文携带正确或者错误的用户信息；

所述验证模块22，还用于对正确的用户信息验证成功后，通知所述发送模块23，或者，对错误的用户信息验证失败后，通知所述发送模块23；

所述发送模块23，还用于根据所述通知，在验证失败或成功后，均回复状态应答报文，指示所述用户侧设备状态为可达。

上述装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在的租户设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图3所示，为本申请租户设备的一种硬件结构图，除了图3所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的租户设备通常根据该租户设备的实际功能，还可以包括其他硬件，对此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (4)

1.一种确定用户侧设备状态的方法，其特征在于，所述方法包括：

用户侧设备CPE通过预定的支持HTTP服务的默认端口即第一端口接收第一状态请求报文，对所述第一状态请求报文携带的错误的用户信息验证失败后回复状态应答报文，指示自身状态为可达；或

CPE通过预定的专用于检测CPE状态的第二端口接收第二状态请求报文，直接针对所述第二状态请求报文回复状态应答报文，指示自身状态为可达，或者，对所述第二状态请求报文携带的用户信息验证后，回复状态应答报文，指示自身状态为可达；或

CPE通过预定的支持HTTP服务的默认端口即第一端口及专用于检测CPE状态的特定的统一资源定位符URL接收第三状态请求报文，直接针对所述第三状态请求报文回复状态应答报文，指示自身状态为可达，或者，对所述第三状态请求报文携带的用户信息验证后，回复状态应答报文，指示自身状态为可达。

2.根据权利要求1所述的方法，其特征在于，所述第二状态请求报文或第三状态请求报文携带正确或者错误的用户信息；

所述CPE对所述第二状态请求报文或第三状态请求报文携带的用户信息验证后，回复状态应答报文，包括：所述CPE对正确的用户信息验证成功后，或者，对错误的用户信息验证失败后，均回复状态应答报文。

3.一种确定用户侧设备状态的装置，应用于用户侧设备，其特征在于，所述装置包括：接收模块、验证模块和发送模块，其中：

接收模块，用于通过预定的支持HTTP服务的默认端口即第一端口接收第一状态请求报文；或用于通过预定的专用于检测CPE状态的第二端口接收第二状态请求报文；或用于通过预定的支持HTTP服务的默认端口即第一端口及专用于检测CPE状态的特定的URL接收第三状态请求报文；

验证模块，用于对所述第一状态请求报文携带的错误的用户信息验证失败后，通知所述发送模块；或用于对所述第二状态请求报文或第三状态请求报文携带的用户信息验证后，通知所述发送模块；

所述发送模块，用于根据所述通知，回复状态应答报文，指示所述用户侧设备状态为可达；或用于直接针对所述第二状态请求报文或第三状态请求报文回复状态应答报文，指示自身状态为可达。

4.根据权利要求3所述的装置，其特征在于，所述第二状态请求报文或第三状态请求报文携带正确或者错误的用户信息；

所述验证模块，还用于对正确的用户信息验证成功后，通知所述发送模块，或者，对错误的用户信息验证失败后，通知所述发送模块；

所述发送模块，还用于根据所述通知，在验证失败或成功后，均回复状态应答报文，指示所述用户侧设备状态为可达。