CN116743625A - 一种fttr网关设备的客户端故障诊断方法和装置 - Google Patents
一种fttr网关设备的客户端故障诊断方法和装置 Download PDFInfo
- Publication number
- CN116743625A CN116743625A CN202310870671.2A CN202310870671A CN116743625A CN 116743625 A CN116743625 A CN 116743625A CN 202310870671 A CN202310870671 A CN 202310870671A CN 116743625 A CN116743625 A CN 116743625A
- Authority
- CN
- China
- Prior art keywords
- gateway
- sub
- gateway device
- equipment
- state
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 94
- 238000003745 diagnosis Methods 0.000 claims abstract description 69
- 238000011084 recovery Methods 0.000 claims abstract description 14
- 230000006855 networking Effects 0.000 claims abstract description 13
- 230000008569 process Effects 0.000 claims description 64
- 230000002441 reversible effect Effects 0.000 claims description 47
- 230000000977 initiatory effect Effects 0.000 claims description 8
- 238000002405 diagnostic procedure Methods 0.000 claims description 6
- 238000011835 investigation Methods 0.000 abstract description 2
- 238000007726 management method Methods 0.000 description 19
- 238000012360 testing method Methods 0.000 description 15
- 238000004088 simulation Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 8
- 230000015572 biosynthetic process Effects 0.000 description 7
- 230000007704 transition Effects 0.000 description 7
- 230000000694 effects Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 3
- 238000004092 self-diagnosis Methods 0.000 description 3
- 230000001052 transient effect Effects 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 2
- 230000007547 defect Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 238000013024 troubleshooting Methods 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
- H04Q11/0062—Network aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
- H04Q11/0062—Network aspects
- H04Q2011/0079—Operation or maintenance aspects
- H04Q2011/0081—Fault tolerance; Redundancy; Recovery; Reconfigurability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
- H04Q11/0062—Network aspects
- H04Q2011/0079—Operation or maintenance aspects
- H04Q2011/0083—Testing; Monitoring
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及一种FTTR网关设备的客户端故障诊断方法和装置。其方法部分主要包括：对组网环境中所有的网关设备进行分组，将多次尝试分组失败的网关设备标记为故障状态；同一分组内的网关设备彼此间互相进行故障诊断，将发现故障的网关设备标记为故障状态；对于标记为故障状态的网关设备尝试进行恢复。本发明可以及时、主动发现TR069客户端故障状态并尝试恢复，极大的提高TR069客户端的服务可靠性，减少问题排查成本，提高工作效率。
Description
技术领域
本发明涉及FTTR(Fiber to The Room，即光纤到房间)系统的TR069远程管理协议技术领域，涉及主ONT(Optical Network Terminal，即光网络终端)以及边缘ONT，特别是涉及一种FTTR网关设备的客户端故障诊断方法和装置。
背景技术
TR069协议作为一种公共的协议标准，广泛应用于各类网络设备的远程管理。同时，也正是因为该协议的广泛应用，导致了出现许多前所未见的特殊场景，这些未曾考虑到的特殊场景可能会导致终端的TR069客户端程序陷入某种异常状态而无法提供正常业务服务，甚至会影响运营商网络环境和服务器，造成恶劣影响。现阶段，其常见的问题主要有以下几类：
(1)终端设备脱管，无法通过远程管理平台对终端设备进行远程管理。在工程环境中，此类设备大多只能等待设备自行重启后连接上远程管理平台，或者需要工程技术人员上门处理。
(2)终端设备频繁发包，这通常是因为代码对异常处理不完善，在某些特殊条件触发下,软件反复执行发送数据包的代码。此类设备，由于会在网络环境中发送大量的数据包，会对设备本身和运营商网络环境设施都造成不良影响。除此之外，设备由于是在反复执行发送数据包的代码，往往不能提供正常的TR069业务服务功能。
有鉴于此，如何克服现有技术所存在的缺陷，解决现有的技术所存在的问题，是本技术领域待解决的难题。
发明内容
针对现有技术中的缺陷或改进需求。本发明提供一种FTTR网关设备的客户端故障诊断方法和装置，对FTTR组网环境的主网关设备、子网关设备进行两两分组，同一分组内的设备彼此互相诊断。通过诊断过程，能够及时、主动发现TR069客户端故障状态并尝试恢复，极大的提高TR069客户端的服务可靠性，减少问题排查成本，提高工作效率。
本发明采用如下技术方案：
第一方面，本发明提供了一种FTTR网关设备的客户端故障诊断方法，包括：
对组网环境中所有的网关设备进行分组，将多次尝试分组失败的网关设备标记为故障状态；
同一分组内的网关设备彼此间互相进行故障诊断，将发现故障的网关设备标记为故障状态；
对于标记为故障状态的网关设备尝试进行恢复。
进一步的，所述对组网环境中所有的网关设备进行分组具体包括：
以主网关设备为中心，将所有子网关设备均注册到主网关设备；
由主网关设备对所有子网关设备进行两两分组；
若最后剩余单独一个子网关设备，则与主网关设备分为一组；若最后无剩余的子网关设备，则主网关设备单独为一组且保持为待分组状态。
进一步的，所述以主网关设备为中心，将所有子网关设备均注册到主网关设备具体包括：
主网关设备运行分组服务；
主网关设备注册自身设备信息，初始状态为待分组状态；
主网关设备的分组服务获取子网关设备向主网关设备注册的各自设备信息，所有新注册子网关设备的初始状态为待分组状态。
进一步的，所述由主网关设备对所有子网关设备进行两两分组具体包括：
主网关设备的分组服务接收到新的子网关设备注册后，检索已注册网关设备列表，查找待分组状态的网关设备，将每两个待分组状态的子网关设备分为一组，设置组ID，将对应子网关设备的状态设置为分组中状态；
向同一分组中状态下在已注册网关设备列表中靠前的子网关设备下发组队指令，以使该子网关设备发起到指定组队对象的组队流程；
主网关设备收到子网关设备报告的组队流程结果后，若组队结果成功则将该组的两个子网关设备的状态设置为已分组状态，若组队结果失败则将该组的两个子网关设备的状态设置为待分组状态，并将对应子网关设备的尝试分组失败次数+1。
进一步的，所述组队流程具体包括：
两个子网关设备互相交换用于诊断测试的反向连接地址和模拟ACS服务地址信息，若两个设备的信息交换成功则组队结果成功，若未完成信息交换过程则组队结果失败。
进一步的，所述将多次尝试分组失败的网关设备标记为故障状态具体包括：
若有某一子网关设备的尝试分组失败次数超过3次，则将该子网关设备标记为故障状态。
进一步的，若待分组状态的子网关设备为奇数个，则检查主网关设备是否为待分组状态，若主网关设备为待分组状态，则将剩余单个子网关设备与主网关设备分为一组；若主网关设备为已分组状态，则剩余单个子网关设备独自为一组且保持为待分组状态。
进一步的，所述同一分组内的网关设备彼此间互相进行故障诊断，将发现故障的网关设备标记为故障状态具体包括：
对于两个子网关设备组队后的互相诊断，由诊断子网关设备向待诊断子网关设备发起反向连接请求，以完成待诊断子网关设备的反向连接认证过程；待诊断子网关设备识别到反向连接请求后，向诊断子网关设备发起正向连接请求，以完成待诊断子网关设备的正向连接过程；若有任一连接失败，则将待诊断子网关设备标记为故障状态，解除诊断子网关设备与待诊断子网关设备的已分组状态，将诊断子网关设备标记为待分组状态；
对于主网关设备对子网关设备的诊断，由主网关设备向子网关设备发起反向连接请求，以完成子网关设备的反向连接认证过程；子网关设备识别到反向连接请求后，向主网关设备发起正向连接请求，以完成子网关设备的正向连接过程；若有任一连接失败，则将子网关设备标记为故障状态，解除主网关设备与子网关设备的已分组状态，将主网关设备标记为待分组状态；
对于子网关设备对主网关设备的诊断，由子网关设备向主网关设备发起反向连接请求，以完成主网关设备的反向连接认证过程；主网关设备识别到反向连接请求后，向子网关设备发起正向连接请求，以完成主网关设备的正向连接过程；若有任一连接失败，则将主网关设备标记为故障状态，解除主网关设备与子网关设备的已分组状态，将子网关设备标记为待分组状态。
进一步的，所述对于标记为故障状态的网关设备尝试进行恢复具体包括：
标记为故障状态的子网关设备，由主网关设备通过管理通道重置子网关设备的客户端状态，子网关设备的客户端重置后，会重新向主网关设备注册自身设备信息，注册成功后将状态更新为待分组状态；
主网关设备处于故障状态的，由与其组队的子网关设备通过管理通道重置主网关设备的客户端状态。
另一方面，本发明提供了一种FTTR网关设备的客户端故障诊断装置，具体为：包括至少一个处理器和存储器，至少一个处理器和存储器之间通过数据总线连接，存储器存储能被至少一个处理器执行的指令，指令在被处理器执行后，用于完成第一方面中的FTTR网关设备的客户端故障诊断方法。
与现有技术相比，本发明的有益效果在于：
1、本发明通过诊断过程，能够及时、主动发现TR069客户端故障状态并尝试恢复，极大的提高TR069客户端的服务可靠性，减少问题排查成本，提高了工作效率。
2、本发明通过不同的设备上触发反向连接测试的方式，解决了在同一个设备上实现自诊断时无法覆盖iptables防火墙效果的问题，提高了诊断的准确性和完备性。
3、本发明通过不同设备的TR069客户端之间的互相诊断，对子网关设备进行分组，将诊断过程中模拟ACS对资源的消耗尽量分散到各个不同的网关设备上，减少了诊断对过程单一设备性能的影响；将模拟ACS和模拟发起Inform的过程分散到不同设备上，减少了诊断过程对单一设备瞬时性能的影响。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
图1为本发明实施例1提供的一种FTTR网关设备的客户端故障诊断方法流程图；
图2为本发明实施例1提供的步骤100扩展流程图；
图3为本发明实施例2提供的某种情况下主网关设备、子网关设备的组队时序图；
图4为本发明实施例2提供的主网关设备、子网关设备的状态变迁示意图；
图5为本发明实施例2提供的设备诊断的网络拓扑示意图；
图6为本发明实施例2提供的同组内设备互相执行诊断的时序示意图；
图7为本发明实施例3提供的一种FTTR网关设备的客户端故障诊断装置结构示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。
本发明是一种特定功能系统的体系结构，因此在具体实施例中主要说明各结构模组的功能逻辑关系，并不对具体软件和硬件实施方式做限定。
此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合，各个步骤在符合逻辑、不冲突的情况下也可以调换先后顺序。下面就参考附图和实施例结合来详细说明本发明。
实施例1：
如图1所示，本发明实施例提供一种FTTR网关设备的客户端故障诊断方法，该方法包括如下步骤。
步骤100：对组网环境中所有的网关设备进行分组，将多次尝试分组失败的网关设备标记为故障状态。在本优选实施例中，组网环境为FTTR组网环境，对组网环境中所有的网关设备进行分组，是对主网关设备、子网关设备进行两两分组，一般而言，先将对子网关设备之间两两分组，在对子网关设备的分组中，若最后剩余单独一个子网关设备，则与主网关设备分为一组；若最后无剩余的子网关设备，则主网关设备单独为一组且保持为待分组状态。
步骤200：同一分组内的网关设备彼此间互相进行故障诊断，将发现故障的网关设备标记为故障状态。在本优选实施例中，同一分组内的第一个网关设备上运行模拟远程管理服务程序，然后触发同组的第二个网关设备的测试反向连接流程，从第二个网关设备向第一个网关设备发起测试正向连接，用以测试第二个网关设备的TR069客户端程序是否处于正常工作状态；反过来，测试第一个网关设备的TR069客户端程序是否处于正常工作状态也是相同的道理。
步骤300：对于标记为故障状态的网关设备尝试进行恢复。在本优选实施例中，对于标记为故障状态的网关设备，还可以在标记为故障状态后自动尝试进行恢复(该恢复由主网关设备或者与主网关设备同组的子网关设备通过其他(非TR069)管理通道下发指令控制处于TR069故障状态的设备尝试恢复)，以提高TR069客户端的服务可靠性。本实施例中该处的管理通道为PON管理通道，具体可包括GPON的OMCI通道、EPON的OAM通道。
通过上述步骤，本实施例能够及时、主动发现TR069客户端故障状态并尝试恢复，极大的提高TR069客户端的服务可靠性，减少问题排查成本，提高了工作效率。
本实施例为了减少诊断过程对单个设备性能的影响，对网关设备进行分组。通常情况下，TR069与远程管理平台的关系属于典型的“客户端”-“服务器”结构。FTTR组网环境下，可以在主网关设备运行诊断服务程序，对组网环境中各主网关设备、子网关设备执行诊断，所有设备诊断过程都以主网关设备为中心完成，会较多的消耗主网关设备系统资源，且无法并行处理，需要协同控制各个网关设备的诊断过程。而本实施例仅仅在分组过程由主网关设备完成，实际诊断过程中则由同组内的网关设备分别充当“客户端”-“服务器”角色，将诊断过程的系统资源负载尽可能的均衡到各个网关设备。这样便减少了诊断过程对单一设备性能的影响，也减少诊断过程设备瞬时性能的影响。
具体的，参考图2所示，在本优选实施例的一种具体实施方式中，步骤100(对组网环境中所有的网关设备进行分组，将多次尝试分组失败的网关设备标记为故障状态)具体包括如下步骤：
步骤101：以主网关设备为中心，将所有子网关设备均注册到主网关设备。在本优选实施例的该步骤中，首先主网关设备运行分组服务；然后主网关设备注册自身设备信息，初始状态为待分组状态(M0)，其中，主网关设备注册的自身设备信息包括主网关设备的设备SN、IP；最后，子网关设备向主网关设备注册各自的设备信息(包括设备SN、IP)，主网关设备的分组服务获取子网关设备向主网关设备注册的各自设备信息，所有新注册子网关设备的初始状态为待分组状态(C0)。
步骤102：由主网关设备对所有子网关设备进行两两分组。在本优选实施例的该步骤中，主网关设备的分组服务接收到新的子网关设备注册后，检索已注册网关设备列表，查找待分组状态的网关设备，将每两个待分组状态的子网关设备分为一组，设置组ID，将对应子网关设备的状态设置为分组中状态(C01)；主网关设备的分组服务向同一分组中状态下在已注册网关设备列表中靠前的子网关设备下发组队指令，以使该子网关设备发起到指定组队对象的组队流程；所述组队指令包含指定组队对象的设备信息，所述设备信息包括设备SN以及IP。子网关设备收到主网关设备下发的组队指令后，发起到指定组队对象的组队流程，两个设备的组队流程具体包括：两个子网关设备互相交换用于诊断测试的反向连接地址(CRSURL-T)和模拟ACS服务地址(FakeACSURL)信息，若两个设备的信息交换成功则组队结果成功，若未完成信息交换过程则组队结果失败；同时，互相交换测试反向连接地址和模拟ACS服务地址，也是以备后续诊断流程使用；组队流程结束后，由收到主网关设备的组队指令的子网关设备向主网关设备报告组队流程结果；主网关设备收到子网关设备报告的组队流程结果后，若组队结果成功则将该组的两个子网关设备的状态设置为已分组状态(C02)，若组队结果失败则将该组的两个子网关设备的状态设置为待分组状态(C0)，并将对应子网关设备的尝试分组失败次数+1。若有某一子网关设备的尝试分组失败次数超过3次，则将该子网关设备标记为故障状态(C3)，重启该故障状态设备的诊断线程，重新注册到主网关设备以刷新状态。需要说明，对于分组，本实施例中主网关设备有M0、M11两种分组状态，其中，M0：主网关设备未配对状态(也即主网关设备的待分组状态)；M11：主网关设备与子网关设备配对状态(也即主网关设备的已分组状态)；子网关设备有C0、C11、C02三种分组状态，其中，C0：子网关设备未配对状态(也即子网关设备的待分组状态)；C11：子网关设备与主网关设备配对状态(也即子网关设备的已分组状态，此种状态的子网关设备是与主网关设备分为一组)；C02：子网关设备与子网关设备配对(也即子网关设备的已分组状态，此种状态的子网关设备是与子网关设备分为一组)。
步骤103：若最后剩余单独一个子网关设备，则与主网关设备分为一组；若最后无剩余的子网关设备，则主网关设备单独为一组且保持为待分组状态。在本优选实施例的一种具体实施方式中，主网关设备的分组服务执行分组任务时，先统计待分组状态的子网关设备的个数，若待分组状态的子网关设备为奇数个，则检查主网关设备是否为待分组状态，若主网关设备为待分组状态，则将剩余单个子网关设备与主网关设备分为一组；若主网关设备为已分组状态，则剩余单个子网关设备独自为一组且保持为待分组状态。
在本优选实施例的一种具体实施方式中，已完成组队的网关设备，其中的第一个网关设备发现第二个网关设备故障的，由第一个网关设备向主网关设备报告第二个网关设备的故障情况，主网关设备收到故障报告后，对第二个网关设备进行故障处理，将第二个网关设备标记为故障状态(C3)，等待设备重新注册；并且解除第一个网关设备和第二个网关设备的组队关系，将第一个网关设备标记为待分组状态，重复步骤100的过程。另外，每当有新网关设备注册、故障网关设备重新注册、已下发组队指令的网关设备反馈组队失败的，重复步骤100的过程。
在本优选实施例的一种具体实施方式中，步骤200(同一分组内的网关设备彼此间互相进行故障诊断，将发现故障的网关设备标记为故障状态)具体包括如下几种情况。
对于两个子网关设备组队后的互相诊断，由诊断子网关设备向待诊断子网关设备发起反向连接请求，以完成待诊断子网关设备的反向连接认证过程；待诊断子网关设备识别到反向连接请求后，向诊断子网关设备发起正向连接请求，以完成待诊断子网关设备的正向连接过程；若有任一连接失败，则将待诊断子网关设备标记为故障状态，解除诊断子网关设备与待诊断子网关设备的已分组状态，将诊断子网关设备标记为待分组状态。
对于主网关设备对子网关设备的诊断，由主网关设备向子网关设备发起反向连接请求，以完成子网关设备的反向连接认证过程；子网关设备识别到反向连接请求后，向主网关设备发起正向连接请求，以完成子网关设备的正向连接过程；若有任一连接失败，则将子网关设备标记为故障状态，解除主网关设备与子网关设备的已分组状态，将主网关设备标记为待分组状态。
对于子网关设备对主网关设备的诊断，由子网关设备向主网关设备发起反向连接请求，以完成主网关设备的反向连接认证过程；主网关设备识别到反向连接请求后，向子网关设备发起正向连接请求，以完成主网关设备的正向连接过程；若有任一连接失败，则将主网关设备标记为故障状态，解除主网关设备与子网关设备的已分组状态，将子网关设备标记为待分组状态。在本优选实施例中，若主网关设备确认出现故障，保存当前的已注册的子网关设备的信息及组队关系信息，重置主网关设备状态(尝试主网关设备故障恢复)后，重新载入已保存的设备信息及组队关系信息，并主动询问已组队子网关设备的当前组队关系是否正常，仍然处于正常组队状态的维持组队关系不变，组队关系变化的则将该组队中的设备都重置为待分组状态，然后重复步骤100中所述的设备组队过程。
在本优选实施例的一种具体实施方式中，步骤300(对于标记为故障状态的网关设备尝试进行恢复)具体包括：标记为故障状态的子网关设备由主网关设备控制重置状态后重新向主网关设备注册自身设备信息，注册成功后将状态更新为待分组状态；标记为故障状态的主网关设备由与其同组的子网关设备控制重置状态后，重新执行分组过程。优选的，标记为故障状态的子网关设备，由主网关设备通过PON管理通道(例如GPON的OMCI通道或EPON的OAM通道)重置其TR069客户端的状态(进程重启)；子网关设备的TR069客户端重置后，会重新向主网关设备注册自身设备信息，注册成功后将状态更新为待分组状态。在本优选实施例中，主网关设备处于故障状态的，由与其组队的子网关设备通过PON管理通道重置主网关设备的TR069客户端状态。
综上所述，本发明实施例通过诊断过程，能够及时、主动发现TR069客户端故障状态并尝试恢复，极大的提高TR069客户端的服务可靠性，减少问题排查成本，提高了工作效率。本发明通过不同的设备上触发反向连接测试的方式，解决了在同一个设备上实现自诊断时无法覆盖iptables防火墙效果的问题，提高了诊断的准确性和完备性。本发明通过不同设备的TR069客户端之间的互相诊断，对子网关设备进行分组，将诊断过程中模拟ACS对资源的消耗尽量分散到各个不同的网关设备上，减少了诊断对过程单一设备性能的影响；将模拟ACS和模拟发起Inform的过程分散到不同设备上，减少了诊断过程对单一设备瞬时性能的影响。
实施例2：
基于实施例1提供的一种FTTR网关设备的客户端故障诊断方法，本实施例2通过一个更为具体的例子来对本发明进行进一步的描述。
如图3所示，本实施例的一种优选实施方式中，以主网关设备A、子网关设备B、子网关设备C、子网关设备D举例，来对其组队流程进行说明。
步骤1：主网关设备A进行主网关自注册(SN-IP-A)。注册后进行尝试组队。
步骤2：子网关设备B注册到主网关设备A(SN-IP-B)。
步骤3：主网关设备A返回信息注册成功给子网关设备B。
步骤4：主网关设备A下发组队指令信息SN-IP-A给子网关设备B。该步骤后还可以标记A、B为组队中，启动超时计时，若超时则判断组队失败。
步骤5：子网关设备B返回收到组队指令给主网关设备A。
步骤6：子网关设备B发送组队请求(CRSURL-T-B::FakeACS-B)到主网关设备A。
步骤7：主网关设备A发送组队回复(CRSURL-T-A:FakeACS-A)到子网关设备B。
步骤8：子网关设备B返回组队成功确认到主网关设备A。该步骤的组队成功确认为组队者之间的确认，例如若与子网关设备B组队的是另一个子网关设备，那子网关设备B返回组队成功确认便是到该另一个子网关设备。
步骤9：子网关设备B通报组队成功或失败的结果给主网关设备A。本实施例中为组队成功，成功后标记A、B为已组队。该步骤的组队成功或失败的通报为组队者向主网关设备的报告，例如若与子网关设备B组队的是另一个子网关设备，那子网关设备B还是需要通报组队成功或失败的结果给主网关设备A。
步骤10：主网关设备A对子网关设备B进行CRSURL-A或FakeACS-A更新。该更新是一组对设备的诊断的关键信息更新。
步骤11：子网关设备B返回更新确认到主网关设备A。
步骤12：子网关设备C注册到主网关设备A(SN-IP-C)。
步骤13：主网关设备A返回信息注册成功给子网关设备C。此时对子网关设备C尝试组队，因为无待组队设备，C单独分组。
步骤14：子网关设备D注册到主网关设备A(SN-IP-D)。
步骤15：主网关设备A返回信息注册成功给子网关设备D。此时对子网关设备D尝试组队，因为前面还有子网关设备C未组队，所以指定子网关设备C、子网关设备D组队。
步骤16：主网关设备A下发组队指令信息SN-IP-D到子网关设备C。
步骤17：子网关设备C返回收到组队指令给主网关设备A。
步骤18：子网关设备C发送组队请求(CRSURL-T-C::FakeACS-C)到子网关设备D。接下来就是子网关设备C、子网关设备D组队协商过程，在此不赘述。
步骤19：子网关设备C向主网关设备A通报子网关设备C-子网关设备D组队成功或失败的结果。如果成功，标记子网关设备C、子网关设备D为已组队。
步骤20：当子网关设备D与子网关设备C失去连接或发现子网关设备C故障，通知主网关设备A子网关设备C故障，解除组队关系。此时，主网关设备A将子网关设备C置为故障状态，以待执行故障恢复；子网关设备D置为待组队状态，尝试组队。
步骤21：主网关设备A下发故障恢复指令到子网关设备C。子网关设备C尝试故障恢复。
步骤22：子网关设备C重新注册到主网关设备A(SN-IP-C)。
步骤23：主网关设备A返回信息注册成功到子网关设备C。然后对子网关设备C尝试组队。
如图4所示，为本实施例提供的主网关设备、子网关设备的状态变迁示意图。其中，主网关设备的状态变迁包括M0(主网关设备的待分组状态)到M11(主网关设备的已分组状态)的相互转换，M0状态下，当主网关设备配对成功之后，就会从M0变化到M11；M11状态下，当主网关设备配对断开或者进行故障恢复的时候，就会从M11变化到M0。子网关设备的状态变迁包括C0(子网关设备的待分组状态)、C11(子网关设备的已分组状态，此种状态的子网关设备是与主网关设备分为一组)、C3(子网关设备的故障状态)、C02(子网关设备的已分组状态，此种状态的子网关设备是与子网关设备分为一组)四种状态间的相互转换，C0状态下，当子网关设备配对主网关设备成功时，就会从C0变化到C11；C11状态下，当子网关设备与主网关设备的配对断开时，就会从C11变回到C0；C11状态下，当子网关设备检查到故障时，就会从C11变化到C3；在C0状态下，子网关设备检查到故障时，也会从C0变化到C3；在C3状态下，子网关设备故障恢复后，就会从C3变化为C0；在C0状态下，子网关设备配对子网关设备成功，就会从C0变化到C02；在C02状态下，子网关设备配对断开，就会从C02变化为C0；在C02状态下，子网关设备检测到故障，就会从C02变化为C3。
在本优选实施例中，两个网关设备分为一组后，分别在各自设备上启动模拟远程管理服务程序，周期性的对同组的另一台设备发起诊断。诊断方式为从C设备上的模拟远程管理服务程序发起反向请求到同组另一台设备D的TR069的反向监听服务，触发D设备正向连接上报到C设备上的模拟远程管理服务，通过这种方式检查D设备上的TR069的反向连接和正向连接是否处于正常可用状态。反过来，用D设备以相同方式检查C设备的状态，亦可成立。
如图5所示，为本实施例提供的设备诊断的网络拓扑示意图。
其中，两个子网关设备组队后的互相诊断流程参考图5中C-D设备所示，具体包含以下步骤：C、D两个设备的TR069 WAN处于同一个局域网，处于设备D上的模拟远程管理服务程序，通过D设备的TR069 WAN接口向C设备的TR069发起反向连接请求，完成反向连接认证过程，如图5中箭头1->2->3->4->5->6所示。设备C识别到是D发起的测试反向连接后，向同组的D设备上的模拟远程管理服务发起正向连接请求，完成正向连接过程，如图5中箭头的4->5->6->1->2->3所示。
其中，子网关和主网关设备组队后的互相诊断流程如图5中A-B设备所示，具体包含以下步骤：主网关A上的模拟远程管理服务程序绑定在br0接口上运行，则主网关A对子网关B发起诊断的过程与子网关C发起到主网关D发起诊断的过程相同。主网关A的TR069程序绑定在A设备的TR069WAN连接上运行，出于安全原因，A设备上的iptables防火墙禁止非TR069WAN接口进入的包访问TR069的反向连接服务端口，需要特别的准入规则允许从br0进入的与A设备组队的设备的IP为源IP的包访问TR069的反向连接服务端口；则由B设备发起对A设备的诊断的流程如图3中箭头的7->8->9->10->11->12所示。
参考图6所示，以C、D设备为例，同组内设备具体进程间的交互流程如下所述。
步骤1a、组队协商过程：子网关设备C发送组队请求(CRSURL-T-D:FakeACS-D)到子网关设备D；子网关设备D返回组队回复(CRSURL-T-C::FakeACS-C)到子网关设备C；子网关设备C发送组队成功确认到子网关设备D。
步骤2a、诊断的关键信息更新：子网关设备C发送CRSURL-T-C或FakeACS-C更新到子网关设备D；子网关设备D返回更新确认到子网关设备C。
步骤3a、子网关设备D诊断子网关设备C的过程：子网关设备D定时诊断子网关设备C，子网关设备D发送反向连接测试(CRSULR-T-C)请求到子网关设备C，子网关设备C认证成功后返回反向连接测试响应到子网关设备D；接着子网关设备C进行正向连接测试，包括对子网关设备D建立Tcp连接FakeACS-D、Inform到FakeACS-D，然后Tcp连接关闭。需说明，上述所提到Inform是属于TR069协议(应用层)，其工作的基础是TCP(传输层)的正常工作；该步骤诊断的正常判断标准是判断模拟ACS服务器在超时时间内是否完成了与待诊断设备的正向连接过程。
步骤4a、子网关设备C开始诊断子网关设备D的过程：子网关设备C定时诊断子网关设备D，子网关设备C发送反向连接测试请求到子网关设备D，子网关设备D返回反向连接测试响应到子网关设备C，然后进行后续正向连接测试，在此不再赘述。
综上所述，本发明实施例通过诊断过程，能够及时、主动发现TR069客户端故障状态并尝试恢复，极大的提高TR069客户端的服务可靠性，减少问题排查成本，提高了工作效率。本发明通过不同的设备上触发反向连接测试的方式，解决了在同一个设备上实现自诊断时无法覆盖iptables防火墙效果的问题，提高了诊断的准确性和完备性。本发明通过不同设备的TR069客户端之间的互相诊断，对子网关设备进行分组，将诊断过程中模拟ACS对资源的消耗尽量分散到各个不同的网关设备上，减少了诊断对过程单一设备性能的影响；将模拟ACS和模拟发起Inform的过程分散到不同设备上，减少了诊断过程对单一设备瞬时性能的影响。
实施例3：
在上述实施例1提供的FTTR网关设备的客户端故障诊断方法的基础上，本发明还提供了一种可用于实现上述方法及系统的FTTR网关设备的客户端故障诊断装置，如图7所示，是本发明实施例的装置架构示意图。本实施例的FTTR网关设备的客户端故障诊断装置包括一个或多个处理器21以及存储器22。其中，图7中以一个处理器21为例。
处理器21和存储器22可以通过总线或者其它方式连接，图7中以通过总线连接为例。
存储器22作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如实施例1中的FTTR网关设备的客户端故障诊断方法。处理器21通过运行存储在存储器22中的非易失性软件程序、指令以及模块，从而执行FTTR网关设备的客户端故障诊断装置的各种功能应用以及数据处理，即实现实施例1的FTTR网关设备的客户端故障诊断方法。
存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其它非易失性固态存储器件。在一些实施例中，存储器22可选包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
程序指令/模块存储在存储器22中，当被一个或者多个处理器21执行时，执行上述实施例1中的FTTR网关设备的客户端故障诊断方法，例如，执行以上描述的图1-图2所示的各个步骤。
本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ReadOnlyMemory，简写为：ROM)、随机存取存储器(RandomAccessMemory，简写为：RAM)、磁盘或光盘等。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。
Claims (10)
1.一种FTTR网关设备的客户端故障诊断方法，其特征在于，包括：
对组网环境中所有的网关设备进行分组，将多次尝试分组失败的网关设备标记为故障状态；
同一分组内的网关设备彼此间互相进行故障诊断，将发现故障的网关设备标记为故障状态；
对于标记为故障状态的网关设备尝试进行恢复。
2.根据权利要求1所述的FTTR网关设备的客户端故障诊断方法，其特征在于，所述对组网环境中所有的网关设备进行分组具体包括：
以主网关设备为中心，将所有子网关设备均注册到主网关设备；
由主网关设备对所有子网关设备进行两两分组；
若最后剩余单独一个子网关设备，则与主网关设备分为一组；若最后无剩余的子网关设备，则主网关设备单独为一组且保持为待分组状态。
3.根据权利要求2所述的FTTR网关设备的客户端故障诊断方法，其特征在于，所述以主网关设备为中心，将所有子网关设备均注册到主网关设备具体包括：
主网关设备运行分组服务；
主网关设备注册自身设备信息，初始状态为待分组状态；
主网关设备的分组服务获取子网关设备向主网关设备注册的各自设备信息，所有新注册子网关设备的初始状态为待分组状态。
4.根据权利要求3所述的FTTR网关设备的客户端故障诊断方法，其特征在于，所述由主网关设备对所有子网关设备进行两两分组具体包括：
主网关设备的分组服务接收到新的子网关设备注册后，检索已注册网关设备列表，查找待分组状态的网关设备，将每两个待分组状态的子网关设备分为一组，设置组ID，将对应子网关设备的状态设置为分组中状态；
向同一分组中状态下在已注册网关设备列表中靠前的子网关设备下发组队指令，以使该子网关设备发起到指定组队对象的组队流程；
主网关设备收到子网关设备报告的组队流程结果后，若组队结果成功则将该组的两个子网关设备的状态设置为已分组状态，若组队结果失败则将该组的两个子网关设备的状态设置为待分组状态，并将对应子网关设备的尝试分组失败次数+1。
5.根据权利要求4所述的FTTR网关设备的客户端故障诊断方法，其特征在于，所述组队流程具体包括：
两个子网关设备互相交换用于诊断测试的反向连接地址和模拟ACS服务地址信息，若两个设备的信息交换成功则组队结果成功，若未完成信息交换过程则组队结果失败。
6.根据权利要求4所述的FTTR网关设备的客户端故障诊断方法，其特征在于，所述将多次尝试分组失败的网关设备标记为故障状态具体包括：
若有某一子网关设备的尝试分组失败次数超过3次，则将该子网关设备标记为故障状态。
7.根据权利要求4所述的FTTR网关设备的客户端故障诊断方法，其特征在于，若待分组状态的子网关设备为奇数个，则检查主网关设备是否为待分组状态，若主网关设备为待分组状态，则将剩余单个子网关设备与主网关设备分为一组；若主网关设备为已分组状态，则剩余单个子网关设备独自为一组且保持为待分组状态。
8.根据权利要求1所述的FTTR网关设备的客户端故障诊断方法，其特征在于，所述同一分组内的网关设备彼此间互相进行故障诊断，将发现故障的网关设备标记为故障状态具体包括：
对于两个子网关设备组队后的互相诊断，由诊断子网关设备向待诊断子网关设备发起反向连接请求，以完成待诊断子网关设备的反向连接认证过程；待诊断子网关设备识别到反向连接请求后，向诊断子网关设备发起正向连接请求，以完成待诊断子网关设备的正向连接过程；若有任一连接失败，则将待诊断子网关设备标记为故障状态，解除诊断子网关设备与待诊断子网关设备的已分组状态，将诊断子网关设备标记为待分组状态；
对于主网关设备对子网关设备的诊断，由主网关设备向子网关设备发起反向连接请求，以完成子网关设备的反向连接认证过程；子网关设备识别到反向连接请求后，向主网关设备发起正向连接请求，以完成子网关设备的正向连接过程；若有任一连接失败，则将子网关设备标记为故障状态，解除主网关设备与子网关设备的已分组状态，将主网关设备标记为待分组状态；
对于子网关设备对主网关设备的诊断，由子网关设备向主网关设备发起反向连接请求，以完成主网关设备的反向连接认证过程；主网关设备识别到反向连接请求后，向子网关设备发起正向连接请求，以完成主网关设备的正向连接过程；若有任一连接失败，则将主网关设备标记为故障状态，解除主网关设备与子网关设备的已分组状态，将子网关设备标记为待分组状态。
9.根据权利要求1-8任一所述的FTTR网关设备的客户端故障诊断方法，其特征在于，所述对于标记为故障状态的网关设备尝试进行恢复具体包括：
标记为故障状态的子网关设备，由主网关设备通过管理通道重置子网关设备的客户端状态，子网关设备的客户端重置后，会重新向主网关设备注册自身设备信息，注册成功后将状态更新为待分组状态；
主网关设备处于故障状态的，由与其组队的子网关设备通过管理通道重置主网关设备的客户端状态。
10.一种FTTR网关设备的客户端故障诊断装置，其特征在于：
包括至少一个处理器和存储器，所述至少一个处理器和存储器之间通过数据总线连接，所述存储器存储能被所述至少一个处理器执行的指令，所述指令在被所述处理器执行后，用于完成权利要求1-9中任一项所述的FTTR网关设备的客户端故障诊断方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310870671.2A CN116743625A (zh) | 2023-07-14 | 2023-07-14 | 一种fttr网关设备的客户端故障诊断方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310870671.2A CN116743625A (zh) | 2023-07-14 | 2023-07-14 | 一种fttr网关设备的客户端故障诊断方法和装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116743625A true CN116743625A (zh) | 2023-09-12 |
Family
ID=87904626
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310870671.2A Pending CN116743625A (zh) | 2023-07-14 | 2023-07-14 | 一种fttr网关设备的客户端故障诊断方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116743625A (zh) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117729249A (zh) * | 2024-02-18 | 2024-03-19 | 四川天邑康和通信股份有限公司 | 一种基于fttr的网关管理方法、装置、设备、系统及介质 |
| CN117835099A (zh) * | 2024-03-05 | 2024-04-05 | 四川天邑康和通信股份有限公司 | 基于fttr的故障自诊断与自修复方法、装置、设备及介质 |
-
2023
- 2023-07-14 CN CN202310870671.2A patent/CN116743625A/zh active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117729249A (zh) * | 2024-02-18 | 2024-03-19 | 四川天邑康和通信股份有限公司 | 一种基于fttr的网关管理方法、装置、设备、系统及介质 |
| CN117729249B (zh) * | 2024-02-18 | 2024-05-03 | 四川天邑康和通信股份有限公司 | 一种基于fttr的网关管理方法、装置、设备、系统及介质 |
| CN117835099A (zh) * | 2024-03-05 | 2024-04-05 | 四川天邑康和通信股份有限公司 | 基于fttr的故障自诊断与自修复方法、装置、设备及介质 |
| CN117835099B (zh) * | 2024-03-05 | 2024-05-24 | 四川天邑康和通信股份有限公司 | 基于fttr的故障自诊断与自修复方法、装置、设备及介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN116743625A (zh) | 一种fttr网关设备的客户端故障诊断方法和装置 | |
| JP3932994B2 (ja) | サーバ引継システムおよびその方法 | |
| CN103414916B (zh) | 一种故障诊断系统及方法 | |
| US9692652B2 (en) | Framework for reliably communicating port information in a system of devices | |
| KR100812374B1 (ko) | 클러스터 시스템에서 프로토콜 네트워크 장애 관리 시스템및 방법 | |
| US9935848B2 (en) | System and method for supporting subnet manager (SM) level robust handling of unkown management key in an infiniband (IB) network | |
| CN106060088A (zh) | 一种服务管理方法及装置 | |
| US10397063B2 (en) | Discovering links between operating domains in a communication network | |
| US8842524B2 (en) | Redundant ring automatic recovery | |
| CN106487598B (zh) | 异构冗余Snmp协议多实例实现系统及其实现方法 | |
| US8570877B1 (en) | Preparing for planned events in computer networks | |
| US8184555B1 (en) | SpaceWire network management | |
| KR101075462B1 (ko) | 서브넷에서 마스터 노드를 선출하는 방법 | |
| JP2008097326A (ja) | Ｓｎｍｐシーケンス管理方法、マネージャ装置及びエージェント装置 | |
| TW201720105A (zh) | 混合式軟體定義網路的虛擬區域網路復原方法、系統及其裝置 | |
| CN106713038B (zh) | 一种远程传输线路质量检测方法及系统 | |
| US20220417136A1 (en) | Pce controlled network reliability | |
| US7636315B2 (en) | Broadcast traceroute | |
| CN112367373B (zh) | 分布式系统的节点确定方法和装置及存储介质 | |
| US9083586B2 (en) | Verifying availability and reachability through a network device | |
| KR101207219B1 (ko) | 데이터 분산 서비스 네트워크 과부하 방지 방법 | |
| CN116762318A (zh) | 架构可用性和同步 | |
| US20080140825A1 (en) | Determining availability of a network service | |
| CN107248935B (zh) | 一种网管发现并监控网元的系统及方法 | |
| JP2001202305A (ja) | Ｎｍｓシステムにおける通信の信頼性向上方法及びｎｍｓシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |