A client fault diagnosis method and device of an FTTR gateway device

Abstract

The present application relates to a kind of FTTR gateway device client fault diagnosis method and device.The method part mainly includes: the grouping of all gateway devices in networking environment, and the gateway device of multiple attempts grouping failure is marked as fault state;Gateway device in the same group mutually carries out fault diagnosis between each other, and the gateway device of discovery fault is marked as fault state;For the gateway device marked as fault state, attempt to recover.The present application can timely, actively discover TR069 client fault state and attempt to recover, greatly improve the service reliability of TR069 client, reduce problem troubleshooting cost, improve work efficiency.

Description

Technical Field

[0001] This invention relates to the field of TR069 remote management protocol technology for FTTR (Fiber to the Room) systems, specifically to the main ONT (Optical Network Terminal) and edge ONTs, and particularly to a client fault diagnosis method and apparatus for FTTR gateway devices. Background Technology

[0002] The TR069 protocol, as a public protocol standard, is widely used for remote management of various network devices. However, this widespread application has also led to many unforeseen special scenarios. These unforeseen scenarios may cause the TR069 client program on the terminal to enter an abnormal state, rendering it unable to provide normal business services, and may even affect the operator's network environment and servers, causing serious consequences. Currently, the common problems mainly fall into the following categories:

[0003] (1) The terminal device is disconnected from management and cannot be remotely managed through the remote management platform. In engineering environments, such devices can only be reconnected to the remote management platform after they restart themselves, or require on-site assistance from engineering technicians.

[0004] (2) Frequent packet sending by terminal devices is usually due to inadequate exception handling in the code. Under certain special conditions, the software repeatedly executes the code that sends data packets. Such devices, by sending a large number of data packets in the network environment, will have an adverse impact on both the device itself and the operator's network infrastructure. In addition, because the device is repeatedly executing the code that sends data packets, it often cannot provide normal TR069 service functions.

[0005] In view of this, how to overcome the defects and solve the problems of existing technologies is a difficult problem to be solved in this technical field. Summary of the Invention

[0006] Addressing the deficiencies or improvement needs in existing technologies, this invention provides a client fault diagnosis method and apparatus for FTTR gateway devices. It groups the main gateway device and sub-gateway devices in an FTTR networking environment into pairs, with devices within the same group diagnosing each other. Through this diagnostic process, the fault status of the TR069 client can be detected promptly and proactively, and recovery attempts can be attempted, greatly improving the service reliability of the TR069 client, reducing troubleshooting costs, and increasing work efficiency.

[0007] The present invention adopts the following technical solution:

[0008] In a first aspect, the present invention provides a client fault diagnosis method for an FTTR gateway device, comprising:

[0009] Group all gateway devices in the network environment and mark gateway devices that fail to group multiple times as faulty;

[0010] Gateway devices within the same group perform fault diagnosis on each other and mark the gateway device that is found to be faulty as faulty.

[0011] Attempt to restore the gateway device marked as faulty.

[0012] Furthermore, the grouping of all gateway devices in the network environment specifically includes:

[0013] With the main gateway device as the center, all sub-gateway devices are registered to the main gateway device;

[0014] The main gateway device groups all sub-gateway devices into pairs.

[0015] If only one sub-gateway device remains at the end, it will be grouped with the main gateway device; if no sub-gateway devices remain at the end, the main gateway device will be in a separate group and remain in a pending grouping state.

[0016] Furthermore, the step of registering all sub-gateway devices to the main gateway device, with the main gateway device as the center, specifically includes:

[0017] The main gateway device runs packet services;

[0018] The main gateway device registers its own device information, and its initial state is the pending grouping state;

[0019] The main gateway device's grouping service obtains the device information of each sub-gateway device registered with the main gateway device. The initial state of all newly registered sub-gateway devices is the pending grouping state.

[0020] Furthermore, the step of grouping all sub-gateway devices pairwise by the main gateway device specifically includes:

[0021] After receiving a new sub-gateway device registration, the main gateway device's grouping service searches the list of registered gateway devices, finds the gateway devices in the grouping state, groups every two sub-gateway devices in the grouping state, sets the group ID, and sets the status of the corresponding sub-gateway device to the grouping state.

[0022] Send a teaming instruction to the sub-gateway device that ranks first in the list of registered gateway devices in the same group, so that the sub-gateway device can initiate a teaming process to the specified teaming object;

[0023] After receiving the grouping process result reported by the sub-gateway device, if the grouping result is successful, the main gateway device will set the status of the two sub-gateway devices in the group to the grouped state; if the grouping result fails, the main gateway device will set the status of the two sub-gateway devices in the group to the pending grouping state and increment the number of failed grouping attempts for the corresponding sub-gateway device by 1.

[0024] Furthermore, the team formation process specifically includes:

[0025] The two sub-gateway devices exchange reverse connection addresses and simulated ACS service address information for diagnostic testing. If the information exchange between the two devices is successful, the team formation is successful; otherwise, the team formation fails.

[0026] Furthermore, marking gateway devices that fail to attempt to group data multiple times as faulty specifically includes:

[0027] If a sub-gateway device fails to send packets more than 3 times, then the sub-gateway device will be marked as faulty.

[0028] Furthermore, if there is an odd number of sub-gateway devices in the pending grouping state, then check if the main gateway device is in the pending grouping state. If the main gateway device is in the pending grouping state, then the remaining single sub-gateway device is grouped with the main gateway device; if the main gateway device is already grouped, then the remaining single sub-gateway device is in a separate group and remains in the pending grouping state.

[0029] Furthermore, the gateway devices within the same group perform fault diagnosis on each other, and mark the gateway device that is found to be faulty as faulty, specifically including:

[0030] For mutual diagnosis after two sub-gateway devices are grouped together, the diagnosing sub-gateway device initiates a reverse connection request to the sub-gateway device to be diagnosed in order to complete the reverse connection authentication process of the sub-gateway device to be diagnosed; after the sub-gateway device to be diagnosed recognizes the reverse connection request, it initiates a forward connection request to the diagnosing sub-gateway device in order to complete the forward connection process of the sub-gateway device to be diagnosed; if either connection fails, the sub-gateway device to be diagnosed is marked as faulty, the grouped state between the diagnosing sub-gateway device and the sub-gateway device to be diagnosed is removed, and the diagnosing sub-gateway device is marked as pending grouping.

[0031] For the diagnosis of sub-gateway devices by the main gateway device, the main gateway device initiates a reverse connection request to the sub-gateway device to complete the reverse connection authentication process of the sub-gateway device; after the sub-gateway device recognizes the reverse connection request, it initiates a forward connection request to the main gateway device to complete the forward connection process of the sub-gateway device; if any connection fails, the sub-gateway device is marked as faulty, the grouped state between the main gateway device and the sub-gateway device is removed, and the main gateway device is marked as pending grouping.

[0032] For the diagnosis of the main gateway device by the sub-gateway device, the sub-gateway device initiates a reverse connection request to the main gateway device to complete the reverse connection authentication process of the main gateway device; after the main gateway device recognizes the reverse connection request, it initiates a forward connection request to the sub-gateway device to complete the forward connection process of the main gateway device; if any connection fails, the main gateway device is marked as faulty, the grouped state between the main gateway device and the sub-gateway device is removed, and the sub-gateway device is marked as pending grouping.

[0033] Furthermore, the attempt to restore gateway devices marked as faulty specifically includes:

[0034] For sub-gateway devices marked as faulty, the main gateway device resets the client status of the sub-gateway device through the management channel. After the client of the sub-gateway device is reset, it will re-register its own device information with the main gateway device. After successful registration, the status will be updated to pending grouping.

[0035] If the main gateway device is in a faulty state, the sub-gateway devices that are in the same group as it can reset the client state of the main gateway device through the management channel.

[0036] On the other hand, the present invention provides a client fault diagnosis device for an FTTR gateway device, specifically comprising at least one processor and a memory, wherein the at least one processor and the memory are connected via a data bus, the memory stores instructions that can be executed by the at least one processor, and the instructions, after being executed by the processor, are used to complete the client fault diagnosis method for the FTTR gateway device in the first aspect.

[0037] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0038] 1. Through the diagnostic process, this invention can promptly and proactively detect the fault status of the TR069 client and attempt to restore it, greatly improving the service reliability of the TR069 client, reducing troubleshooting costs, and increasing work efficiency.

[0039] 2. This invention solves the problem that the effect of iptables firewall cannot be covered when implementing self-diagnosis on the same device by triggering reverse connection tests on different devices, thus improving the accuracy and completeness of the diagnosis.

[0040] 3. This invention uses mutual diagnosis between TR069 clients on different devices to group sub-gateway devices, thereby distributing the resource consumption of simulated ACS during the diagnosis process to different gateway devices as much as possible, reducing the impact of diagnosis on the performance of a single device; and distributing the simulated ACS and simulated Inform processes to different devices, reducing the impact of the diagnosis process on the instantaneous performance of a single device. Attached Figure Description

[0041] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0042] Figure 1 This is a flowchart of a client fault diagnosis method for an FTTR gateway device provided in Embodiment 1 of the present invention;

[0043] Figure 2 This is an extended flowchart of step 100 provided in Embodiment 1 of the present invention;

[0044] Figure 3 This is a timing diagram of the team formation of the main gateway device and the sub-gateway device under a certain condition, provided in Embodiment 2 of the present invention;

[0045] Figure 4 This is a schematic diagram of the state transitions of the main gateway device and the sub-gateway device provided in Embodiment 2 of the present invention;

[0046] Figure 5 This is a network topology diagram for device diagnostics provided in Embodiment 2 of the present invention;

[0047] Figure 6 This is a timing diagram illustrating the mutual diagnostics performed by devices within the same group, as provided in Embodiment 2 of the present invention.

[0048] Figure 7 This is a schematic diagram of the client fault diagnosis device for an FTTR gateway device provided in Embodiment 3 of the present invention. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0050] This invention is an architecture of a specific functional system. Therefore, the specific embodiments mainly describe the functional logic relationship of each structural module, and do not limit the specific software and hardware implementation methods.

[0051] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other, and the order of the steps can be changed as long as they are logical and do not conflict. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0052] Example 1:

[0053] like Figure 1 As shown in the figure, this embodiment of the invention provides a client fault diagnosis method for an FTTR gateway device, which includes the following steps.

[0054] Step 100: Group all gateway devices in the network environment and mark gateway devices that fail to group multiple times as faulty. In this preferred embodiment, the network environment is an FTTR network environment. Grouping all gateway devices in the network environment involves grouping the main gateway device and sub-gateway devices in pairs. Generally, sub-gateway devices are first grouped in pairs. In the grouping of sub-gateway devices, if there is only one sub-gateway device remaining, it is grouped with the main gateway device; if there are no remaining sub-gateway devices, the main gateway device is in a separate group and remains in a pending grouping state.

[0055] Step 200: Gateway devices within the same group perform fault diagnosis on each other, marking faulty gateway devices as faulty. In this preferred embodiment, the first gateway device within the same group runs a simulated remote management service program, then triggers a test reverse connection process for the second gateway device in the same group, initiating a test forward connection from the second gateway device to the first gateway device to test whether the TR069 client program of the second gateway device is in a normal working state; conversely, testing whether the TR069 client program of the first gateway device is in a normal working state follows the same principle.

[0056] Step 300: Attempt recovery for gateway devices marked as faulty. In this preferred embodiment, for gateway devices marked as faulty, recovery can also be automatically attempted after being marked as faulty (this recovery is controlled by the main gateway device or a sub-gateway device in the same group as the main gateway device through instructions issued by other (non-TR069) management channels to control the devices in the TR069 faulty state to attempt recovery), thereby improving the service reliability of TR069 clients. In this embodiment, the management channel here is a PON management channel, which may specifically include the OMCI channel of GPON and the OAM channel of EPON.

[0057] Through the above steps, this embodiment can promptly and proactively detect TR069 client fault status and attempt to recover, greatly improving the service reliability of TR069 client, reducing troubleshooting costs, and improving work efficiency.

[0058] To reduce the impact of the diagnostic process on the performance of individual devices, this embodiment groups the gateway devices. Typically, the relationship between the TR069 and the remote management platform is a typical "client"-"server" structure. In an FTTR network environment, diagnostic services can run on the main gateway device to perform diagnostics on each main and sub-gateway device in the network. All device diagnostic processes are centered on the main gateway device, consuming significant system resources and lacking parallel processing capabilities, requiring coordinated control of the diagnostic processes across all gateway devices. However, this embodiment only has the main gateway device handle the grouping process. During the actual diagnostic process, each gateway device within the same group acts as a "client"-"server," distributing the system resource load of the diagnostic process as evenly as possible across all gateway devices. This reduces the impact of the diagnostic process on the performance of individual devices and also minimizes the impact on the instantaneous performance of devices during the diagnostic process.

[0059] For details, please refer to Figure 2 As shown, in a specific embodiment of this preferred embodiment, step 100 (grouping all gateway devices in the network environment and marking gateway devices that have failed to group multiple times as faulty) specifically includes the following steps:

[0060] Step 101: Using the main gateway device as the center, register all sub-gateway devices to the main gateway device. In this preferred embodiment, the main gateway device first runs the packet service; then, the main gateway device registers its own device information, initially in a pending packet state (M0), where the registered device information includes the main gateway device's device SN and IP address; finally, the sub-gateway devices register their respective device information (including device SN and IP address) with the main gateway device, and the main gateway device's packet service obtains the device information registered by the sub-gateway devices. The initial state of all newly registered sub-gateway devices is a pending packet state (C0).

[0061] Step 102: The main gateway device groups all sub-gateway devices in pairs. In this preferred embodiment, after receiving a new sub-gateway device registration, the grouping service of the main gateway device searches the list of registered gateway devices, finds the gateway devices in the grouping state, groups every two sub-gateway devices in the grouping state, sets a group ID, and sets the state of the corresponding sub-gateway device to the grouping state (C01). The grouping service of the main gateway device issues a grouping instruction to the sub-gateway device in the same grouping state that ranks first in the list of registered gateway devices, so that the sub-gateway device initiates the grouping process to the specified grouping object. The grouping instruction contains the device information of the specified grouping object, and the device information includes the device SN and IP. After receiving the grouping instruction from the main gateway device, the sub-gateway device initiates a grouping process with the specified grouping object. The grouping process between the two devices specifically includes: the two sub-gateway devices exchanging reverse connection address (CRSURL-T) and simulated ACS service address (FakeACSURL) information for diagnostic testing. If the information exchange between the two devices is successful, the grouping result is successful; if the information exchange process is not completed, the grouping result fails. At the same time, they exchange the test reverse connection address and simulated ACS service address for use in subsequent diagnostic processes. After the grouping process is completed, the sub-gateway device that received the grouping instruction from the main gateway device reports the grouping process result to the main gateway device. After receiving the grouping process result reported by the sub-gateway device, if the grouping result is successful, the main gateway device sets the status of the two sub-gateway devices in the group to the grouped state (C02); if the grouping result fails, the main gateway device sets the status of the two sub-gateway devices in the group to the pending grouping state (C0), and increments the number of failed grouping attempts for the corresponding sub-gateway device by 1. If a sub-gateway device fails to group more than 3 times, it is marked as faulty (C3), its diagnostic thread is restarted, and it is re-registered with the main gateway device to refresh its status. It should be noted that for grouping, in this embodiment, the main gateway device has two grouping states: M0 and M11. M0: The main gateway device is not paired (i.e., the main gateway device is in a pending grouping state); M11: The main gateway device is paired with a sub-gateway device (i.e., the main gateway device is already grouped). Sub-gateway devices have three grouping states: C0, C11, and C02. C0: The sub-gateway device is not paired (i.e., the sub-gateway device is in a pending grouping state); C11: The sub-gateway device is paired with the main gateway device (i.e., the sub-gateway device is already grouped; in this state, the sub-gateway device is grouped with the main gateway device); C02: The sub-gateway device is paired with another sub-gateway device (i.e., the sub-gateway device is already grouped; in this state, the sub-gateway device is grouped with another sub-gateway device).

[0062] Step 103: If a single sub-gateway device remains, it is grouped with the main gateway device; if no sub-gateway devices remain, the main gateway device remains in a separate group and is in a pending grouping state. In a specific embodiment of this preferred embodiment, when the main gateway device performs the grouping task, it first counts the number of sub-gateway devices in the pending grouping state. If the number of sub-gateway devices in the pending grouping state is odd, it checks whether the main gateway device is in the pending grouping state. If the main gateway device is in the pending grouping state, the remaining single sub-gateway device is grouped with the main gateway device; if the main gateway device is already in a grouped state, the remaining single sub-gateway device remains in a separate group and is in a pending grouping state.

[0063] In one specific embodiment of this preferred embodiment, if the first gateway device in a group discovers a fault in the second gateway device, it reports the fault to the main gateway device. Upon receiving the fault report, the main gateway device handles the fault by marking the second gateway device as faulty (C3) and awaiting re-registration. It also removes the grouping relationship between the first and second gateway devices, marks the first gateway device as pending grouping, and repeats step 100. Furthermore, whenever a new gateway device registers, a faulty gateway device re-registers, or a gateway device that has received a grouping command reports a grouping failure, step 100 is repeated.

[0064] In one specific embodiment of this preferred embodiment, step 200 (gateway devices within the same group perform fault diagnosis on each other and mark the faulty gateway device as faulty) specifically includes the following situations.

[0065] For mutual diagnosis after two sub-gateway devices are grouped together, the diagnosing sub-gateway device initiates a reverse connection request to the sub-gateway device to be diagnosed in order to complete the reverse connection authentication process of the sub-gateway device to be diagnosed. After the sub-gateway device to be diagnosed recognizes the reverse connection request, it initiates a forward connection request to the diagnosing sub-gateway device in order to complete the forward connection process of the sub-gateway device to be diagnosed. If either connection fails, the sub-gateway device to be diagnosed is marked as faulty, the grouped state between the diagnosing sub-gateway device and the sub-gateway device to be diagnosed is removed, and the diagnosing sub-gateway device is marked as pending grouping.

[0066] For the diagnosis of sub-gateway devices by the main gateway device, the main gateway device initiates a reverse connection request to the sub-gateway device to complete the reverse connection authentication process of the sub-gateway device; after the sub-gateway device recognizes the reverse connection request, it initiates a forward connection request to the main gateway device to complete the forward connection process of the sub-gateway device; if any connection fails, the sub-gateway device is marked as faulty, the grouped state between the main gateway device and the sub-gateway device is removed, and the main gateway device is marked as pending grouping.

[0067] For the diagnosis of the main gateway device by the sub-gateway device, the sub-gateway device initiates a reverse connection request to the main gateway device to complete the reverse connection authentication process of the main gateway device. After the main gateway device recognizes the reverse connection request, it initiates a forward connection request to the sub-gateway device to complete the forward connection process of the main gateway device. If any connection fails, the main gateway device is marked as faulty, the grouped state between the main gateway device and the sub-gateway device is removed, and the sub-gateway device is marked as pending grouping. In this preferred embodiment, if the main gateway device confirms a fault, it saves the information of the currently registered sub-gateway devices and the grouping relationship information, resets the main gateway device state (attempting to recover from the main gateway device fault), reloads the saved device information and grouping relationship information, and actively inquires whether the current grouping relationship of the grouped sub-gateway devices is normal. If they are still in a normal grouping state, the grouping relationship remains unchanged. If the grouping relationship has changed, all devices in the group are reset to pending grouping state, and then the device grouping process described in step 100 is repeated.

[0068] In one specific embodiment of this preferred embodiment, step 300 (attempting recovery for gateway devices marked as faulty) specifically includes: the sub-gateway device marked as faulty is reset by the main gateway device and then re-registers its own device information with the main gateway device; after successful registration, the status is updated to pending grouping. ； After the primary gateway device marked as faulty is reset by its grouped sub-gateway devices, the grouping process is re-executed. Preferably, the primary gateway device resets the TR069 client status (process restart) of a sub-gateway device marked as faulty via a PON management channel (e.g., the OMCI channel of GPON or the OAM channel of EPON). After the TR069 client of the sub-gateway device is reset, it will re-register its device information with the primary gateway device, and after successful registration, update its status to pending grouping. In this preferred embodiment, if the primary gateway device is in a faulty state, the TR069 client status of the primary gateway device is reset by its grouped sub-gateway devices via a PON management channel.

[0069] In summary, this invention, through its diagnostic process, can promptly and proactively detect TR069 client fault states and attempt recovery, greatly improving the service reliability of TR069 clients, reducing troubleshooting costs, and increasing work efficiency. By triggering reverse connection tests on different devices, this invention solves the problem of not being able to cover the iptables firewall effect when implementing self-diagnosis on the same device, improving the accuracy and completeness of the diagnosis. Through mutual diagnosis between TR069 clients on different devices, this invention groups sub-gateway devices, distributing the resource consumption of simulated ACS during the diagnostic process across different gateway devices as much as possible, reducing the impact of diagnosis on the performance of a single device; by distributing the simulated ACS and simulated Inform processes across different devices, this invention reduces the impact of the diagnostic process on the instantaneous performance of a single device.

[0070] Example 2:

[0071] Based on the client fault diagnosis method for an FTTR gateway device provided in Embodiment 1, this Embodiment 2 further describes the present invention through a more specific example.

[0072] like Figure 3 As shown, in a preferred embodiment of this example, the team formation process is illustrated using a main gateway device A, a sub-gateway device B, a sub-gateway device C, and a sub-gateway device D as examples.

[0073] Step 1: The main gateway device A performs main gateway self-registration (SN-IP-A). After registration, it attempts to form a team.

[0074] Step 2: Sub-gateway device B registers with main gateway device A (SN-IP-B).

[0075] Step 3: The main gateway device A returns a successful registration message to the sub-gateway device B.

[0076] Step 4: The main gateway device A sends the grouping instruction information SN-IP-A to the sub-gateway device B. After this step, A and B can be marked as being in a group, and a timeout timer can be started. If the timeout occurs, the grouping is considered to have failed.

[0077] Step 5: Sub-gateway device B returns the received team formation instruction to the main gateway device A.

[0078] Step 6: Sub-gateway device B sends a teaming request (CRSURL-TB::FakeACS-B) to main gateway device A.

[0079] Step 7: The main gateway device A sends a team reply (CRSURL-TA:FakeACS-A) to the sub-gateway device B.

[0080] Step 8: Sub-gateway device B returns a successful team formation confirmation to the main gateway device A. This successful team formation confirmation is between the team members. For example, if sub-gateway device B is teamed with another sub-gateway device, then sub-gateway device B's successful team formation confirmation will be sent to that other sub-gateway device.

[0081] Step 9: Sub-gateway device B reports the success or failure of the team formation to the main gateway device A. In this embodiment, the team formation is successful, and A and B are marked as a team after success. The success or failure report in this step is a report from the team member to the main gateway device. For example, if the sub-gateway device B is teamed with another sub-gateway device, then sub-gateway device B still needs to report the success or failure of the team formation to the main gateway device A.

[0082] Step 10: The main gateway device A performs a CRSURL-A or FakeACS-A update on the sub-gateway device B. This update is a set of critical information updates for device diagnostics.

[0083] Step 11: Sub-gateway device B returns an update confirmation to the main gateway device A.

[0084] Step 12: Sub-gateway device C registers with main gateway device A (SN-IP-C).

[0085] Step 13: The main gateway device A returns a successful registration message to the sub-gateway device C. At this point, an attempt is made to team up the sub-gateway device C. Since there are no devices waiting to be teamed up, C is grouped separately.

[0086] Step 14: Sub-gateway device D registers with main gateway device A (SN-IP-D).

[0087] Step 15: The main gateway device A returns a successful registration message to the sub-gateway device D. At this point, an attempt is made to team up with the sub-gateway device D. Since there is still a sub-gateway device C that has not yet been teamed up, the sub-gateway device C and the sub-gateway device D are designated to be teamed up.

[0088] Step 16: The main gateway device A sends the team formation instruction information SN-IP-D to the sub-gateway device C.

[0089] Step 17: Sub-gateway device C returns the received team formation instruction to the main gateway device A.

[0090] Step 18: Sub-gateway device C sends a teaming request (CRSURL-TC::FakeACS-C) to sub-gateway device D. The following steps involve the teaming negotiation process between sub-gateway devices C and D, which will not be detailed here.

[0091] Step 19: Sub-gateway device C notifies the main gateway device A of the success or failure of the team formation between sub-gateway device C and sub-gateway device D. If successful, mark sub-gateway device C and sub-gateway device D as teamed.

[0092] Step 20: When sub-gateway device D loses connection with sub-gateway device C or detects a fault in sub-gateway device C, it notifies the main gateway device A of the fault in sub-gateway device C and terminates the team relationship. At this time, the main gateway device A sets sub-gateway device C to a fault state, pending fault recovery; sub-gateway device D is set to a pending team state and attempts to form a team.

[0093] Step 21: The main gateway device A sends a fault recovery command to the sub-gateway device C. The sub-gateway device C attempts fault recovery.

[0094] Step 22: Sub-gateway device C re-registers with main gateway device A (SN-IP-C).

[0095] Step 23: The main gateway device A returns a message indicating successful registration to the sub-gateway device C. Then, it attempts to form a team with the sub-gateway device C.

[0096] like Figure 4 The diagram illustrates the state transitions of the main gateway device and sub-gateway devices provided in this embodiment. The main gateway device's state transitions include the mutual conversion between M0 (the main gateway device's pending grouping state) and M11 (the main gateway device's grouped state). In state M0, the main gateway device changes from M0 to M11 after successful pairing; in state M11, the main gateway device changes from M11 to M0 when pairing is disconnected or a fault recovery occurs. The sub-gateway device's state transitions include the mutual conversion between four states: C0 (the sub-gateway device's pending grouping state), C11 (the sub-gateway device's grouped state, in which the sub-gateway device is grouped with the main gateway device), C3 (the sub-gateway device's fault state), and C02 (the sub-gateway device's grouped state, in which the sub-gateway device is grouped with another sub-gateway device). In state C0, the sub-gateway device changes from C0 to C11 when successful pairing with the main gateway device; in state C11, the sub-gateway device changes from C0 to M11 when pairing with the main gateway device is disconnected. In state C11, the sub-gateway device will change back to C0. In state C11, when a sub-gateway device detects a fault, it will change to C3. In state C0, when a sub-gateway device detects a fault, it will also change to C3. In state C3, after the sub-gateway device recovers from the fault, it will change back to C0. In state C0, if a sub-gateway device successfully pairs with another sub-gateway device, it will change to C02. In state C02, if the pairing of sub-gateway devices is disconnected, it will change back to C0. In state C02, if a sub-gateway device detects a fault, it will change back to C3.

[0097] In this preferred embodiment, after the two gateway devices are grouped together, each device starts a simulated remote management service program to periodically initiate diagnostics on the other device in the same group. The diagnostic method involves the simulated remote management service program on device C initiating a reverse request to the reverse listening service of TR069 on the other device D in the same group. This triggers device D to report its forward connection to the simulated remote management service on device C. This process checks whether the reverse and forward connections of TR069 on device D are in a normal and usable state. Conversely, device D can also check the status of device C in the same way, and the results will be satisfactory.

[0098] like Figure 5 The diagram shown is a network topology diagram of the device diagnostics provided in this embodiment.

[0099] The mutual diagnostic process after the two sub-gateway devices are grouped together is referenced. Figure 5 As shown in the CD device diagram, the specific steps include: The TR069 WAN interfaces of devices C and D are on the same local area network. The simulated remote management service program on device D initiates a reverse connection request to the TR069 interface of device C through the TR069 WAN interface of device D, completing the reverse connection authentication process, as follows... Figure 5 As shown by the middle arrows 1->2->3->4->5->6, after device C recognizes that the test reverse connection was initiated by D, it initiates a forward connection request to the simulated remote management service on device D in the same group, completing the forward connection process, as follows. Figure 5 The middle arrows indicate 4->5->6->1->2->3.

[0100] The mutual diagnostic process between the sub-gateway and main gateway devices after they are grouped together is as follows: Figure 5 As shown in the diagram of devices A and B, the specific steps are as follows: The simulated remote management service program on the main gateway A runs on the br0 interface. Therefore, the process of the main gateway A initiating diagnosis from the sub-gateway B is the same as the process of the sub-gateway C initiating diagnosis from the main gateway D. The TR069 program of the main gateway A runs on the TR069WAN connection of device A. For security reasons, the iptables firewall on device A blocks packets from entering through interfaces other than TR069WAN from accessing the reverse connection service port of TR069. Special access rules are needed to allow packets originating from devices grouped with device A via br0 to access the reverse connection service port of TR069. The process of device B initiating diagnosis of device A is as follows: Figure 3 The middle arrows indicate 7->8->9->10->11->12.

[0101] refer to Figure 6 As shown, taking devices C and D as examples, the interaction flow between specific processes of devices in the same group is as follows.

[0102] Step 1a, Team Negotiation Process: Sub-gateway device C sends a team request (CRSURL-TD:FakeACS-D) to sub-gateway device D; sub-gateway device D returns a team reply (CRSURL-TC::FakeACS-C) to sub-gateway device C; sub-gateway device C sends a team success confirmation to sub-gateway device D.

[0103] Step 2a, updating key diagnostic information: Sub-gateway device C sends CRSURL-TC or FakeACS-C update to sub-gateway device D; sub-gateway device D returns update confirmation to sub-gateway device C.

[0104] Step 3a: The process of sub-gateway device D diagnosing sub-gateway device C: Sub-gateway device D periodically diagnoses sub-gateway device C. Sub-gateway device D sends a reverse connection test (CRSULR-TC) request to sub-gateway device C. After successful authentication, sub-gateway device C returns a reverse connection test response to sub-gateway device D. Then, sub-gateway device C performs a forward connection test, including establishing a TCP connection to FakeACS-D with sub-gateway device D, informing FakeACS-D, and then closing the TCP connection. It should be noted that the inform mentioned above belongs to the TR069 protocol (application layer), and its operation is based on the normal operation of TCP (transport layer). The normal judgment criterion for this step is to determine whether the simulated ACS server has completed the forward connection process with the device under diagnosis within the timeout period.

[0105] Step 4a: Sub-gateway device C begins the process of diagnosing sub-gateway device D: Sub-gateway device C periodically diagnoses sub-gateway device D, sub-gateway device C sends a reverse connection test request to sub-gateway device D, sub-gateway device D returns a reverse connection test response to sub-gateway device C, and then performs subsequent forward connection tests, which will not be described in detail here.

[0106] In summary, this invention, through its diagnostic process, can promptly and proactively detect TR069 client fault states and attempt recovery, greatly improving the service reliability of TR069 clients, reducing troubleshooting costs, and increasing work efficiency. By triggering reverse connection tests on different devices, this invention solves the problem of not being able to cover the iptables firewall effect when implementing self-diagnosis on the same device, improving the accuracy and completeness of the diagnosis. Through mutual diagnosis between TR069 clients on different devices, this invention groups sub-gateway devices, distributing the resource consumption of simulated ACS during the diagnostic process across different gateway devices as much as possible, reducing the impact of diagnosis on the performance of a single device; by distributing the simulated ACS and simulated Inform processes across different devices, this invention reduces the impact of the diagnostic process on the instantaneous performance of a single device.

[0107] Example 3:

[0108] Based on the client fault diagnosis method for FTTR gateway devices provided in Embodiment 1 above, the present invention also provides a client fault diagnosis device for FTTR gateway devices that can be used to implement the above method and system, such as... Figure 7 The diagram shown is a schematic representation of the device architecture according to an embodiment of the present invention. The client fault diagnosis device for the FTTR gateway device in this embodiment includes one or more processors 21 and a memory 22. Figure 7 Take a processor 21 as an example.

[0109] Processor 21 and memory 22 can be connected via a bus or other means. Figure 7 Taking the example of a connection between China and Israel via a bus.

[0110] The memory 22, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the client fault diagnosis method for the FTTR gateway device in Embodiment 1. The processor 21 executes various functional applications and data processing of the client fault diagnosis device for the FTTR gateway device by running the non-volatile software programs, instructions, and modules stored in the memory 22, thereby implementing the client fault diagnosis method for the FTTR gateway device in Embodiment 1.

[0111] Memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 22 may optionally include memory remotely located relative to processor 21, which can be connected to processor 21 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0112] The program instructions / modules are stored in memory 22. When executed by one or more processors 21, they perform the client fault diagnosis method for the FTTR gateway device described in Embodiment 1 above, for example, performing the above-described... Figures 1-2 The steps shown.

[0113] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0114] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention. Contents not described in detail in this specification are prior art known to those skilled in the art.

Claims

1. A client-side fault diagnosis method for an FTTR gateway device, characterized in that, include: All gateway devices in the network environment are grouped, and gateway devices that fail to group multiple times are marked as faulty. This includes: registering all sub-gateway devices to the main gateway device; grouping all sub-gateway devices in pairs by the main gateway device; if a single sub-gateway device remains, it is grouped with the main gateway device; if no sub-gateway devices remain, the main gateway device is in a separate group and remains in a pending grouping state. Gateway devices within the same group perform fault diagnosis on each other, marking faulty gateway devices as faulty. This includes: for mutual diagnosis after two sub-gateway devices are grouped together, the diagnosing sub-gateway device initiates a reverse connection request to the sub-gateway device to be diagnosed to complete the reverse connection authentication process of the sub-gateway device to be diagnosed; after the sub-gateway device to be diagnosed recognizes the reverse connection request, it initiates a forward connection request to the diagnosing sub-gateway device to complete the forward connection process of the sub-gateway device to be diagnosed; if any connection fails, the sub-gateway device to be diagnosed is marked as faulty, the grouping status between the diagnosing sub-gateway device and the sub-gateway device to be diagnosed is removed, and the diagnosing sub-gateway device is marked as pending grouping. For the diagnosis of sub-gateway devices by the main gateway device, the main gateway device initiates a reverse connection request to the sub-gateway device to complete the reverse connection authentication process of the sub-gateway device; after the sub-gateway device recognizes the reverse connection request, it initiates a forward connection request to the main gateway device to complete the forward connection process of the sub-gateway device; if any connection fails, the sub-gateway device is marked as faulty, the grouped state between the main gateway device and the sub-gateway device is removed, and the main gateway device is marked as pending grouping. For the diagnosis of the main gateway device by the sub-gateway device, the sub-gateway device initiates a reverse connection request to the main gateway device to complete the reverse connection authentication process of the main gateway device; after the main gateway device recognizes the reverse connection request, it initiates a forward connection request to the sub-gateway device to complete the forward connection process of the main gateway device; if any connection fails, the main gateway device is marked as faulty, the grouped state between the main gateway device and the sub-gateway device is removed, and the sub-gateway device is marked as pending grouping. The gateway device marked as faulty attempts to recover.

2. The client fault diagnosis method for FTTR gateway device according to claim 1, characterized in that, The process of registering all sub-gateway devices to the main gateway device, with the main gateway device as the center, specifically includes: The main gateway device runs packet services; The main gateway device registers its own device information, and its initial state is the pending grouping state; The main gateway device's grouping service obtains the device information of each sub-gateway device registered with the main gateway device. The initial state of all newly registered sub-gateway devices is the pending grouping state.

3. The client fault diagnosis method for FTTR gateway device according to claim 2, characterized in that, The specific steps of grouping all sub-gateway devices pairwise by the main gateway device include: After receiving a new sub-gateway device registration, the main gateway device's grouping service searches the list of registered gateway devices, finds the gateway devices in the grouping state, groups every two sub-gateway devices in the grouping state, sets the group ID, and sets the status of the corresponding sub-gateway device to the grouping state. Send a teaming instruction to the sub-gateway device that ranks first in the list of registered gateway devices in the same group, so that the sub-gateway device can initiate a teaming process to the specified teaming object; After receiving the grouping process result reported by the sub-gateway device, if the grouping result is successful, the main gateway device will set the status of the two sub-gateway devices in the group to the grouped state; if the grouping result fails, the main gateway device will set the status of the two sub-gateway devices in the group to the pending grouping state and increment the number of failed grouping attempts for the corresponding sub-gateway device by 1.

4. The client fault diagnosis method for the FTTR gateway device according to claim 3, characterized in that, The team formation process specifically includes: The two sub-gateway devices exchange reverse connection addresses and simulated ACS service address information for diagnostic testing. If the information exchange between the two devices is successful, the team formation is successful; otherwise, the team formation fails.

5. The client fault diagnosis method for the FTTR gateway device according to claim 3, characterized in that, Marking a gateway device that has repeatedly failed to packetize data as being in a faulty state specifically includes: If a sub-gateway device fails to send packets more than 3 times, then the sub-gateway device will be marked as faulty.

6. The client fault diagnosis method for the FTTR gateway device according to claim 3, characterized in that, If there are an odd number of sub-gateway devices in the pending grouping state, check if the main gateway device is in the pending grouping state. If the main gateway device is in the pending grouping state, group the remaining single sub-gateway device with the main gateway device. If the main gateway device is already in the grouping state, the remaining single sub-gateway device is in a separate group and remains in the pending grouping state.

7. The client fault diagnosis method for the FTTR gateway device according to any one of claims 1-6, characterized in that, The attempt to restore the gateway device marked as faulty specifically includes: For sub-gateway devices marked as faulty, the main gateway device resets the client status of the sub-gateway device through the management channel. After the client of the sub-gateway device is reset, it will re-register its own device information with the main gateway device. After successful registration, the status will be updated to pending grouping. If the main gateway device is in a faulty state, the sub-gateway devices that are in the same group as it can reset the client state of the main gateway device through the management channel.

8. A client fault diagnosis device for an FTTR gateway device, characterized in that: The device includes at least one processor and a memory, which are connected via a data bus. The memory stores instructions that can be executed by the at least one processor. After being executed by the processor, the instructions are used to complete the client fault diagnosis method of the FTTR gateway device according to any one of claims 1-7.

Images