Communication exception processing method and device, computer equipment and readable storage medium

Abstract

The invention relates to the technical field of indoor networking and all-optical networking, in particular to a communication exception processing method and device, computer equipment and a readable storage medium. The method comprises the following steps: acquiring slave device identifiers of other slave devices broadcasted by a master device under the condition of determining that communication between the first slave device and the master device in the FTTR system is abnormal; and if it is determined that the existing device identifier of the first slave device is the same as any slave device identifier, controlling the master device to redistribute a new device identifier different from each slave device identifier for the first slave device.

Description

Technical Field

[0001] The present application relates to the field of indoor networking technology and all-optical networking technology, and in particular to a communication exception processing method, device, computer equipment and readable storage medium. Background Art

[0002] The fiber to the room (FTTR) system builds an efficient network architecture, the core of which is a master device, which is closely connected to multiple slave devices distributed in various rooms through optical fiber, a high-speed, high-bandwidth transmission medium. This system not only realizes seamless interconnection between terminals, but also ensures smooth data return and supports collaborative work between wireless networks.

[0003] In traditional technologies, in FTTR systems, in order to continuously improve network performance and user experience, deep innovation and functional integration are usually carried out in the design of the main equipment. These innovations not only cover advanced functions such as traffic control and link control, but also focus on coping with the challenge of a large number of terminals connected to the slave equipment, and comprehensively improve the overall quality of the network by centrally optimizing network resource allocation and transmission efficiency.

[0004] However, the current FTTR system lacks management of slave devices, which may affect the normal operation of the entire system, so it is urgently needed to be improved. Summary of the invention

[0005] Based on this, it is necessary to provide a communication anomaly handling method, apparatus, computer equipment and readable storage medium that can effectively manage FTTR in response to the above technical problems.

[0006] In a first aspect, the present application provides a communication exception processing method, which is applied to a first slave device in a fiber-to-the-room FTTR system, and the method comprises:

[0007] When it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system, obtaining slave device identifiers of other slave devices broadcasted by the master device;

[0008] If it is determined that the existing device identification of the first slave device is the same as any slave device identification, the master device is controlled to reallocate a new device identification that is different from the identifications of each slave device to the first slave device.

[0009] In one embodiment, determining that a communication abnormality occurs between a first slave device and a master device in the FTTR system includes:

[0010] During the set communication period, monitor the communication messages sent by the master device;

[0011] If no communication message is monitored, it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system;

[0012] The master device and the first slave device are in a communication state in a period before the communication period.

[0013] In one embodiment, obtaining the slave device identification of each other slave device broadcasted by the master device includes:

[0014] Monitor the identification allocation message broadcast by the master device;

[0015] If the identification allocation message is monitored within the monitoring time, the identification allocation message is parsed to obtain the slave device identifications of the other slave devices broadcasted by the master device.

[0016] In one of the embodiments, the identification allocation message is generated by the master device according to the identification application request initiated by the second slave device; the identification application request is initiated by the second slave device when joining the FTTR system and performing device registration.

[0017] In one embodiment, the method further comprises:

[0018] If it is determined that the existing device identification of the first slave device is different from the identifications of each slave device, the operation of obtaining the slave device identifications of each other slave device broadcasted by the master device is returned to be executed.

[0019] In one embodiment, controlling the master device to reallocate a new device identifier to the first slave device that is different from identifiers of each slave device includes:

[0020] Sending identification exception information to the master device to instruct the master device to generate a new identification allocation message based on the identification exception information;

[0021] The new identifier allocation message is parsed to obtain a new device identifier that is reallocated by the master device to the first slave device and is different from the identifiers of each slave device.

[0022] In a second aspect, the present application further provides a communication abnormality processing device, which is configured in a first slave device in a fiber-to-the-room FTTR system, comprising:

[0023] An acquisition module, used for acquiring slave device identifiers of other slave devices broadcasted by the master device when it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system;

[0024] If it is determined that the existing device identification of the first slave device is the same as any slave device identification, the master device is controlled to reallocate a new device identification that is different from the identifications of each slave device to the first slave device.

[0025] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0026] When it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system, obtaining slave device identifiers of other slave devices broadcasted by the master device;

[0027] If it is determined that the existing device identification of the first slave device is the same as any slave device identification, the master device is controlled to reallocate a new device identification that is different from the identifications of each slave device to the first slave device.

[0028] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the following steps are implemented:

[0029] When it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system, obtaining slave device identifiers of other slave devices broadcasted by the master device;

[0030] If it is determined that the existing device identification of the first slave device is the same as any slave device identification, the master device is controlled to reallocate a new device identification that is different from the identifications of each slave device to the first slave device.

[0031] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

[0032] When it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system, obtaining slave device identifiers of other slave devices broadcasted by the master device;

[0033] If it is determined that the existing device identification of the first slave device is the same as any slave device identification, the master device is controlled to reallocate a new device identification that is different from the identifications of each slave device to the first slave device.

[0034] The above-mentioned communication anomaly processing method, device, computer equipment and readable storage medium, in this application, when a communication anomaly occurs between the first slave device and the master device, the solution can quickly identify the problem and trigger the subsequent processing flow. By obtaining the identifiers of other slave devices broadcast by the master device and checking whether there is a conflict in the device identifier of the first slave device, the cause of the communication anomaly can be quickly located. Once the identifier conflict is determined, the master device is immediately controlled to reallocate a new identifier for the first slave device, thereby quickly restoring the communication link and reducing the time of communication interruption. By reallocating a new device identifier, the solution ensures that each slave device in the FTTR system has a unique device identifier. This avoids communication confusion and data errors caused by identifier conflicts, and improves the stability and reliability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0036] Figure 1 An application environment diagram of a communication exception handling method in an embodiment;

[0037] Figure 2 A flow chart of a method for handling communication anomalies in one embodiment;

[0038] Figure 3 A schematic flow chart of a step of determining a communication abnormality between a first slave device and a master device in an FTTR system in one embodiment;

[0039] Figure 4 A schematic flow chart of a step of obtaining slave device identifications of other slave devices broadcasted by a master device in one embodiment;

[0040] Figure 5 A schematic flow chart of a step of controlling a master device to reallocate a new device identifier that is different from identifiers of each slave device to a first slave device in one embodiment;

[0041] Figure 6 is a structural block diagram of a communication exception processing device in an embodiment;

[0042] Figure 7 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0043] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0044] The FTTR (Fiber to the Room) system builds an efficient network architecture, the core of which is that a master device is closely connected to multiple slave devices distributed in various rooms through optical fiber links, achieving seamless interconnection of terminal devices, smooth data backhaul, and intelligent coordination of wireless networks. Given that the system needs to support the stable operation of a large number of slave devices and their downstream terminals, extremely high requirements are placed on the overall stability of the network.

[0045] To ensure the continuous and efficient operation of the network, the system must be able to keenly identify and quickly handle abnormal slave device identification. The establishment of this mechanism aims to timely discover and resolve network failures caused by slave device identification errors or conflicts, thereby effectively ensuring the overall stable operation of the FTTR system.

[0046] This embodiment provides a schematic diagram of an application environment of a communication exception handling method. Figure 1 As shown, the application environment includes a master device, slave device 1 (a first slave device) and slave device 2 (a second slave device). The master device and slave device 1 can communicate bidirectionally, and the master device and slave device 2 can communicate bidirectionally.

[0047] In an exemplary embodiment, Figure 2 As shown, a communication exception handling method is provided, which is applied to Figure 1 The first slave device in the example is used as an example to illustrate the following:

[0048] S201, when it is determined that a communication abnormality occurs between a first slave device and a master device in the FTTR system, obtain slave device identifiers of other slave devices broadcasted by the master device.

[0049] The communication anomaly between the first slave device and the master device in the FTTR system refers to a special situation caused by a software defect in the master device, which causes the master device to accidentally lose the slave device identification information about the first slave device (i.e., slave device 1) during operation.

[0050] Optionally, determining that a communication abnormality occurs between the first slave device and the master device in the FTTR system may include the following process:

[0051] (1) Continuous monitoring The master and slave devices should continuously monitor the communication status between them, including connection stability, data transmission rate, etc. If the master device finds that the communication with slave device 1 is suddenly interrupted, or the data transmission rate is abnormally reduced, it means that there is a communication problem and further analysis is required.

[0052] (2) During further analysis, query the system logs of slave device 1 and the master device for error messages or warnings related to communication interruption. If the logs contain error codes, consult the device manual or manufacturer support documentation to see if these error codes indicate a problem with the slave device identification being lost.

[0053] The slave device ID is the key information used to uniquely identify each slave device in the FTTR system. The slave device ID is generated by the master device. Specifically, when a slave device first joins the network or system, it usually sends a registration request to the master device. This request may contain some basic information about the slave device, such as device type, manufacturer, serial number, etc. After receiving the registration request from the slave device, the master device will generate a unique device ID for the slave device based on its internal ID allocation strategy or algorithm.

[0054] When necessary, the master device will broadcast the slave device identification of each other slave device. For example, when a slave device is registered with the master device, it can broadcast the slave device identification of each other slave device once. In this case, when the first slave device detects a communication anomaly, it will listen to the messages broadcast regularly by the master device. These messages contain the device identification information of all other slave devices in the system.

[0055] It can be understood that a broadcast message is a communication method sent to all devices on the network. It does not rely on a specific device identity for addressing, but uses a special broadcast address (such as 255.255.255.255 in IPv4) to ensure that the message can be received by all devices on the network.

[0056] As long as the network interface of the first slave device is correctly configured and in listening state, it can receive broadcast messages sent on the network. After receiving the broadcast message, the first slave device will decide whether to process the message based on its internal filtering mechanism. If the message type meets the expectations of the first slave device (such as an identification assignment message), it will be further processed. The reception of broadcast messages does not depend on the device identification, so even if the master device loses the device identification of the first slave device, the first slave device can still receive the broadcast message. Therefore, in broadcast mode, the master device sends the message to all slave devices in the network.

[0057] S202: If it is determined that the existing device identifier of the first slave device is the same as any slave device identifier, control the master device to reallocate a new device identifier that is different from the identifiers of each slave device to the first slave device.

[0058] The existing device identifier of the first slave device refers to the device identifier assigned by the master device to the first slave device before the communication abnormality occurs. Before the communication abnormality occurs, the first slave device and the master device communicate based on the existing device identifier.

[0059] Optionally, the first slave device compares its own existing device identification with the identifications of other slave devices received in the broadcast one by one. If it is found that the device identification of the first slave device is the same as the identification of any other slave device, it is determined that there is an identification conflict. When the first slave device detects an identification conflict, it sends a conflict handling request to the master device. This request should include the current device identification of the first slave device and an indication of requesting reallocation of a new identification.

[0060] Specifically, after receiving the conflict handling request from the first slave device, the master device verifies the legitimacy of the request and ensures that the request is indeed from a slave device with an identity conflict. The master device checks its device identity database or list to ensure that the newly assigned device identity is unique in the system. The master device generates a new, unique device identity and sends the new identity to the first slave device via a secure communication method.

[0061] Further, after receiving the new device identifier sent by the master device, the first slave device verifies the validity of the new identifier (for example, by checking the format, length, etc. of the new identifier). If the new identifier is valid, the first slave device updates its internal configuration and replaces the original device identifier with the new identifier. The first slave device sends a confirmation message to the master device, indicating that it has successfully updated the device identifier. The master device updates its device list or database to reflect the new device identifier of the first slave device. The master device can broadcast an update message to notify other slave devices and management devices in the network about the change of the first slave device identifier. After the first slave device updates its device identifier, it can use the new identifier to communicate with the master device and other slave devices. The master device and other slave devices will route and transmit data according to the updated device identifier.

[0062] In addition, if the device identifier of the first slave device is different from the identifiers of all slave devices, the device continues to monitor the identification information of each slave device broadcast by the master device. If the identification information of each slave device broadcast by the master device is still not obtained within the set time, the device is offline from the FTTR system and subsequently re-registered on the master device according to the hardware serial number of the first slave device to obtain a new device identifier.

[0063] The above-mentioned communication anomaly handling method, in this application, when a communication anomaly occurs between the first slave device and the master device, the solution can quickly identify the problem and trigger the subsequent processing flow. By obtaining the identifiers of other slave devices broadcast by the master device and checking whether there is a conflict in the device identifier of the first slave device, the cause of the communication anomaly can be quickly located. Once the identifier conflict is determined, the master device is immediately controlled to reallocate a new identifier for the first slave device, thereby quickly restoring the communication link and reducing the time of communication interruption. By reallocating a new device identifier, the solution ensures that each slave device in the FTTR system has a unique device identifier. This avoids communication confusion and data errors caused by identifier conflicts, and improves the stability and reliability of the system.

[0064] In an exemplary embodiment, Figure 3 As shown, determining that a communication abnormality occurs between the first slave device and the master device in the FTTR system includes:

[0065] S301, monitoring the communication message sent by the master device within the set communication period.

[0066] The master device and the first slave device are in a communication state in a period before the communication period.

[0067] Optionally, during a set communication period, the first slave device starts its monitoring mechanism and continuously monitors the communication messages sent by the master device, in order to confirm whether the master device is sending data normally by monitoring the communication messages, thereby determining whether the communication link is unobstructed.

[0068] S302: If no communication message is monitored, it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system.

[0069] It is understandable that if the first slave device does not monitor any communication message from the master device during the communication period set by the first slave device, it is determined according to the set fault judgment mechanism that a communication abnormality has occurred between the first slave device and the master device in the FTTR system.

[0070] The fault judgment machine is set as follows: if no communication message from the master device is monitored within the communication period set by the first slave device, it is determined that the master device has lost the device identification of the first slave device due to its own defects.

[0071] In this embodiment, by monitoring the communication message sent by the master device within the set communication period, the technical solution can detect the communication status between the first slave device and the master device in real time. Once the communication is interrupted or the master device does not send the expected communication message, the first slave device can quickly detect and determine that the communication is abnormal, thereby triggering the subsequent processing flow in time. When the first slave device does not monitor the communication message, according to the preset fault judgment mechanism, it can be reasonably inferred that the master device may have lost the device identification of the first slave device due to its own defects (such as software errors, memory leaks, etc.). This accurate identification helps to quickly locate the root cause of the problem and provides a clear direction for subsequent problem solving. By timely detecting and accurately identifying communication anomalies, the technical solution can reduce the risk of system instability and data loss caused by communication failures. This helps to improve the overall reliability of the FTTR system and ensure the integrity of user data and the timeliness of transmission. The monitoring mechanism and fault judgment mechanism in the technical solution can be automatically implemented without manual intervention. This helps to reduce operation and maintenance costs, improve management efficiency, and make the FTTR system more intelligent and automated.

[0072] In an exemplary embodiment, Figure 4 As shown, the slave device identifications of other slave devices broadcast by the master device are obtained, including:

[0073] S401, monitoring the identification allocation message broadcast by the master device.

[0074] It is understandable that the master device generates a unique slave device identifier according to certain rules or algorithms.

[0075] Optionally, when a new slave device needs to join the network, the master device will generate a unique device identifier for it, and encapsulate the identifier into a device identifier message and send it to the slave device. Alternatively, the slave device temporarily leaves the network for some reason (such as network problems, device failure, etc.) and needs to rejoin after repair. When rejoining the network, the master device will generate a new device identifier for it or resend the original device identifier message. Therefore, the identifier allocation message broadcast by the master device can include the device identifier generated for the newly registered slave device and the existing device identifiers of other registered slave devices.

[0076] In this embodiment, the identity allocation message is generated by the master device according to the identity application request initiated by the second slave device. The identity application request is initiated by the second slave device when joining the FTTR system and performing device registration.

[0077] It is understandable that when the second slave device wishes to join the FTTR system and register the device, it will actively send an identification application request to the master device. After receiving the identification application request from the second slave device, the master device will generate a unique device identification for the second slave device according to certain rules or algorithms. This device identification is used to uniquely identify the second slave device in the FTTR system.

[0078] Then, the master device encapsulates the generated device ID into an ID allocation message. This message contains not only the device ID of the second slave device, but also other necessary information, such as message type, sender (master device) ID, timestamp, etc. The encapsulated ID allocation message will be broadcasted by the master device to the network of the FTTR system. In this way, all slave devices in the network (including the second slave device and other registered slave devices) will receive this message.

[0079] S402: If an identifier allocation message is monitored within the monitoring time, the identifier allocation message is parsed to obtain slave device identifiers of other slave devices broadcasted by the master device.

[0080] Specifically, the first slave device parses the identifier allocation message to obtain the slave device identifiers of other slave devices broadcasted by the master device.

[0081] In addition, if no identification message is heard within the monitoring time, the device is disconnected from the FTTR system and subsequently re-registered in the master device according to the hardware serial number of the first slave device to obtain a new device identification.

[0082] In this embodiment, by monitoring the identification allocation message broadcast by the master device, the first slave device can dynamically obtain the device identification of other slave devices in the FTTR system. This mechanism ensures the real-time and accuracy of the slave device identification, and avoids communication conflicts and data confusion caused by outdated or erroneous identification information. When a new slave device (such as the second slave device) needs to join the FTTR system, the master device will generate a unique device identification for it and broadcast it to all slave devices through an identification allocation message. This mechanism supports the dynamic addition of slave devices, making the FTTR system more flexible and scalable. By ensuring that each slave device has a unique device identification and updating this identification information in real time, this technical solution helps to improve the stability of the FTTR system. It reduces the risk of communication interruption and data loss due to identification conflicts or errors, thereby improving the overall reliability and performance of the system.

[0083] In an exemplary embodiment, Figure 5 As shown, controlling the master device to reallocate a new device identifier that is different from identifiers of each slave device to the first slave device includes:

[0084] S501, sending identification exception information to a master device to instruct the master device to generate a new identification allocation message based on the identification exception information.

[0085] Optionally, if it is determined that the existing device identifier of the first slave device is the same as any slave device identifier, identifier exception information is generated, and the identifier exception information should include the current device identifier of the first slave device and an indication of requesting reallocation of a new identifier.

[0086] Specifically, the instruction to reallocate a new identifier can be a structured data packet or message body, which contains the above-mentioned key information. After receiving this instruction, the master device will generate a new, unique device identifier for the first slave device according to its internal identifier allocation strategy and algorithm, and send it to the first slave device via network broadcast or unicast to complete the identifier reallocation process.

[0087] S502: Parse the new identifier allocation message to obtain a new device identifier that is reallocated by the master device to the first slave device and is different from the identifiers of each slave device.

[0088] It is understandable that when the first slave device receives this message, it will parse out the new device identifier and update its own identifier information. After that, it can use this new identifier to communicate with other devices in the network. When other slave devices receive this message, they will also update their understanding of the first slave device identifier to ensure the correctness of subsequent communications.

[0089] In this embodiment, when the first slave device finds that its device identification conflicts with other slave devices, by sending identification exception information to the master device, the master device can quickly trigger the process of reallocating a new identification to it. This mechanism efficiently solves the identification conflict problem and avoids communication barriers and data confusion caused by the conflict. The master device generates a new and unique device identification for the first slave device based on the identification exception information, and sends it to the first slave device through a new identification allocation message. This ensures that each slave device has a unique identification in the FTTR system, providing a basis for the stable operation of the system. After receiving the new identification allocation message, the first slave device will parse the new device identification therein and update its own identification information. This dynamic update mechanism enables the slave device to adapt to changes in the network in a timely manner and maintain normal communication with other network devices. The technical solution allows the slave device to actively request the master device to reallocate the identification when an identification conflict is found, thereby improving the flexibility and adaptability of the system. This mechanism enables the FTTR system to better cope with scenarios such as dynamic joining, leaving or fault recovery of slave devices. Through an automated identification conflict detection and resolution mechanism, the technical solution reduces the maintenance cost of the FTTR system. Operation and maintenance personnel do not need to manually intervene in the handling of identification conflicts, reducing the complexity and error rate of manual operations.

[0090] In an exemplary embodiment, a method for implementing a communication exception handling method is provided, which specifically includes:

[0091] 1. Both the FTTR master device and slave device 1 are in normal working condition, and data communication is stable.

[0092] 2. Over time, the master device unfortunately loses the identification information of slave device 1 due to an internal software defect. This causes the master device to no longer accurately send user data traffic to slave device 1.

[0093] 3. Slave device 1, while in continuous operation, notices that it has not received any downlink messages from the master device for a period of time. In response, slave device 1 starts the abnormality identification clock and begins timing to monitor this abnormal state.

[0094] 4. When the identification abnormality clock times out and slave 1 still has not received any downlink message, it enters a monitoring mode and starts to pay close attention to the messages of the assigned slave device identification that may appear in the network. At the same time, a monitoring clock is turned on to limit the monitoring time.

[0095] 5. Power on another slave device (slave 2) and start the registration and activation process. It reports its own serial number to the master device and waits to receive the slave device identification assigned by the master device through a specific message. At this time, it is in the O2-3 state.

[0096] 6. During the monitoring process, slave 1 receives the message for assigning the slave ID. It parses the message content, extracts the serial number and slave ID, and compares them carefully with its own corresponding values.

[0097] 7. If slave device 1 finds that the serial number in the message is inconsistent with its own serial number, but the slave device ID is the same as its own ID, it immediately determines that a duplicate slave device ID allocation anomaly has occurred in the network. Subsequently, slave device 1 reports an ID reallocation alarm and restarts the registration and activation process to try to obtain a new, unique slave device ID.

[0098] 8. If slave device 1 finds that the sequence number in the message is inconsistent with its own, and the slave device identifier is also different from its own, it continues to remain in the listening mode and waits for possible subsequent messages.

[0099] 9. If the monitoring clock times out and slave device 1 still has not received any valid slave device identification allocation message, it will report a slave device abnormality alarm and actively go offline to avoid further confusion or conflict in the network.

[0100] Through the above solution, the FTTR system can effectively detect and handle the repeated allocation anomalies of slave device identifiers, ensuring that each slave device in the network has a unique and correct identifier, thereby maintaining the stability of the entire system and the smoothness of communication.

[0101] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0102] Based on the same inventive concept, the embodiment of the present application also provides a communication exception handling device for implementing the communication exception handling method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more communication exception handling device embodiments provided below can refer to the limitations on the communication exception handling method above, and will not be repeated here.

[0103] In an exemplary embodiment, Figure 6 As shown, a communication exception handling device is provided, comprising: an acquisition module 11 and an exception handling module 12, wherein:

[0104] An acquisition module 11 is used to acquire the slave device identifiers of other slave devices broadcasted by the master device when it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system;

[0105] The exception handling module 12 is used to control the master device to reallocate a new device identifier that is different from the identifiers of each slave device to the first slave device if it is determined that the existing device identifier of the first slave device is the same as any slave device identifier.

[0106] In one embodiment, the acquisition module 11 is further used to: monitor the communication message sent by the master device within a set communication period;

[0107] If no communication message is monitored, it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system;

[0108] The master device and the first slave device are in a communication state in a period before the communication period.

[0109] In one embodiment, the acquisition module 11 is further used to: monitor the identification allocation message broadcast by the master device;

[0110] If the identification allocation message is monitored within the monitoring time, the identification allocation message is parsed to obtain the slave device identifications of the other slave devices broadcasted by the master device.

[0111] In one of the embodiments, the identification allocation message is generated by the master device according to the identification application request initiated by the second slave device; the identification application request is initiated by the second slave device when joining the FTTR system and performing device registration.

[0112] In one embodiment, the apparatus further includes a circulation module for returning to execute an operation of acquiring the slave device identifications of other slave devices broadcasted by the master device if it is determined that the existing device identification of the first slave device is different from the identifications of each slave device.

[0113] In one of the embodiments, the exception handling module 12 is further used to: send identification exception information to the master device to instruct the master device to generate a new identification allocation message based on the identification exception information;

[0114] The new identifier allocation message is parsed to obtain a new device identifier that is reallocated by the master device to the first slave device and is different from the identifiers of each slave device.

[0115] Each module in the above communication anomaly handling device can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0116] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 7As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store XX data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a communication exception handling method is implemented.

[0117] Those skilled in the art will understand that Figure 7 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0118] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:

[0119] When it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system, obtaining slave device identifiers of other slave devices broadcasted by the master device;

[0120] If it is determined that the existing device identification of the first slave device is the same as any slave device identification, the master device is controlled to reallocate a new device identification that is different from the identifications of each slave device to the first slave device.

[0121] In one embodiment, when the processor executes the computer program, the following steps are further implemented: monitoring the communication message sent by the master device within a set communication period; if no communication message is monitored, determining that a communication abnormality occurs between the first slave device and the master device in the FTTR system;

[0122] The master device and the first slave device are in a communication state in a period before the communication period.

[0123] In one embodiment, when the processor executes the computer program, the following steps are also implemented: monitoring the identification allocation message broadcast by the master device; if the identification allocation message is monitored within the monitoring time, parsing the identification allocation message to obtain the slave device identifications of other slave devices broadcast by the master device.

[0124] In one embodiment, the identification allocation message is generated by the master device according to the identification application request initiated by the second slave device; the identification application request is initiated by the second slave device when joining the FTTR system and performing device registration.

[0125] In one embodiment, when executing the computer program, the processor further implements the following steps: if it is determined that the existing device identification of the first slave device is different from the identifications of each slave device, return to execute the operation of obtaining the slave device identifications of each other slave device broadcast by the master device.

[0126] In one embodiment, when the processor executes the computer program, the following steps are also implemented: sending identification exception information to the master device to instruct the master device to generate a new identification allocation message based on the identification exception information; parsing the new identification allocation message to obtain a new device identification that is reallocated by the master device to the first slave device and is different from the identifications of each slave device.

[0127] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0128] When it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system, obtaining slave device identifiers of other slave devices broadcasted by the master device;

[0129] If it is determined that the existing device identification of the first slave device is the same as any slave device identification, the master device is controlled to reallocate a new device identification that is different from the identifications of each slave device to the first slave device.

[0130] In one embodiment, when the computer program is executed by the processor, the following steps are further implemented: monitoring the communication message sent by the master device within the set communication period; if no communication message is monitored, determining that a communication abnormality occurs between the first slave device and the master device in the FTTR system;

[0131] The master device and the first slave device are in a communication state in a period before the communication period.

[0132] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: monitoring the identification allocation message broadcast by the master device; if the identification allocation message is monitored within the monitoring time, parsing the identification allocation message to obtain the slave device identifications of other slave devices broadcast by the master device.

[0133] In one embodiment, the identification allocation message is generated by the master device according to the identification application request initiated by the second slave device; the identification application request is initiated by the second slave device when joining the FTTR system and performing device registration.

[0134] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: if it is determined that the existing device identification of the first slave device is different from the identifications of each slave device, return to execute the operation of obtaining the slave device identifications of each other slave device broadcast by the master device.

[0135] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: sending identification exception information to the master device to instruct the master device to generate a new identification allocation message based on the identification exception information; parsing the new identification allocation message to obtain a new device identification that is reallocated by the master device to the first slave device and is different from the identifications of each slave device.

[0136] In one embodiment, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements the following steps:

[0137] When it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system, obtaining slave device identifiers of other slave devices broadcasted by the master device;

[0138] If it is determined that the existing device identification of the first slave device is the same as any slave device identification, the master device is controlled to reallocate a new device identification that is different from the identifications of each slave device to the first slave device.

[0139] In one embodiment, when the computer program is executed by the processor, the following steps are further implemented: monitoring the communication message sent by the master device within the set communication period; if no communication message is monitored, determining that a communication abnormality occurs between the first slave device and the master device in the FTTR system;

[0140] The master device and the first slave device are in a communication state in a period before the communication period.

[0141] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: monitoring the identification allocation message broadcast by the master device; if the identification allocation message is monitored within the monitoring time, parsing the identification allocation message to obtain the slave device identifications of other slave devices broadcast by the master device.

[0142] In one embodiment, the identification allocation message is generated by the master device according to the identification application request initiated by the second slave device; the identification application request is initiated by the second slave device when joining the FTTR system and performing device registration.

[0143] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: if it is determined that the existing device identification of the first slave device is different from the identifications of each slave device, return to execute the operation of obtaining the slave device identifications of each other slave device broadcast by the master device.

[0144] In one embodiment, when the computer program is executed by the processor, the following steps are also implemented: sending identification exception information to the master device to instruct the master device to generate a new identification allocation message based on the identification exception information; parsing the new identification allocation message to obtain a new device identification that is reallocated by the master device to the first slave device and is different from the identifications of each slave device.

[0145] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0146] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0147] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A communication abnormality processing method, characterized in that: Applied to a first slave device in a fiber-to-the-room FTTR system, the method comprises: When it is determined that a communication abnormality occurs between the first slave device and a master device in the FTTR system, obtaining slave device identifiers of other slave devices broadcasted by the master device; If it is determined that the existing device identification of the first slave device is the same as any slave device identification, the master device is controlled to reallocate a new device identification that is different from each of the slave device identifications to the first slave device.

2. The method according to claim 1, characterized in that: The determining that a communication abnormality occurs between the first slave device and the master device in the FTTR system includes: During a set communication period, monitoring the communication messages sent by the master device; If the communication message is not monitored, it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system; The master device and the first slave device are in a communication state in a period before the communication period.

3. The method according to claim 1, characterized in that The obtaining the slave device identification of each other slave device broadcasted by the master device includes: Monitoring the identification allocation message broadcast by the master device; If the identifier allocation message is monitored within the monitoring time, the identifier allocation message is parsed to obtain the slave device identifiers of the other slave devices broadcast by the master device.

4. The method according to claim 3, characterized in that The identification allocation message is generated by the master device according to the identification application request initiated by the second slave device; the identification application request is initiated by the second slave device when joining the FTTR system and performing device registration.

5. The method according to claim 1, characterized in that The method further comprises: If it is determined that the existing device identification of the first slave device is different from the identifications of each slave device, the operation of obtaining the slave device identifications of each other slave device broadcasted by the master device is returned to be executed.

6. The method according to claim 1, characterized in that The controlling the master device to reallocate a new device identifier for the first slave device that is different from identifiers of each of the slave devices includes: Sending identification exception information to the master device to instruct the master device to generate a new identification allocation message based on the identification exception information; The new identifier allocation message is parsed to obtain a new device identifier that is reallocated by the master device to the first slave device and is different from the identifiers of each of the slave devices.

7. A communication abnormality processing device, characterized in that: A first slave device configured in a fiber-to-the-room FTTR system, the device comprising: an acquisition module, configured to acquire slave device identifiers of other slave devices broadcasted by the master device when it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system; The exception handling module is used to control the master device to reallocate a new device identifier that is different from each of the slave device identifiers to the first slave device if it is determined that the existing device identifier of the first slave device is the same as any of the slave device identifiers.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images