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

Abstract

The application relates to the fields of indoor networking technology and all-optical networking technology, in particular to a communication exception processing method and device, computer equipment and a readable storage medium. The method comprises the following steps: in the case that it is determined that a communication exception occurs between a first slave device and a master device in an FTTR system, obtaining slave device identifiers of each other slave device broadcast by the master device; if it is determined that an existing device identifier of the first slave device is the same as any slave device identifier, controlling the master device to reassign a new device identifier different from each slave device identifier to the first slave device.

Description

TECHNICAL FIELD

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

[0002] A fiber to the room (FTTR) system constructs an efficient network architecture, the core of which is a master device that is closely connected to multiple slave devices distributed in various rooms through an optical fiber, a high-speed and 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 the conventional technology, in the FTTR system, in order to continuously improve network performance and user experience, deep innovation and functional integration are usually carried out on the design of the master device. These innovations not only cover advanced functions such as traffic control and link control, but also aim to address the challenge of a large number of terminal devices hung under the slave device, and improve the overall quality of the network by optimizing the allocation of network resources and transmission efficiency.

[0004] However, the current FTTR system lacks management of slave devices, which may affect the normal operation of the entire system, and therefore needs to be improved. SUMMARY

[0005] Therefore, it is necessary to provide a communication exception processing method, device, computer equipment and readable storage medium capable of effectively managing the FTTR in view of the above technical problems.

[0006] In a first aspect, the present application provides a communication exception processing method applied to a first slave device in a fiber to the room (FTTR) system, the method comprising:

[0007] In a case where it is determined that a communication exception occurs between the first slave device and a master device in the FTTR system, obtaining slave device identifiers of each other slave device broadcasted by the master device;

[0008] 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 reassign a new device identifier different from each slave device identifier to the first slave device.

[0009] In one of the embodiments, determining that a communication exception occurs between the first slave device and the master device in the FTTR system comprises:

[0010] In a set communication period, listening to a communication packet sent by the master device;

[0011] If no communication message is monitored, it is determined that 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 of the embodiments, the slave device identifier of each other slave device broadcast by the master device is acquired, including:

[0014] The identifier allocation message broadcast by the master device is monitored.

[0015] If the identifier allocation message is monitored within the monitoring duration, the identifier allocation message is parsed to obtain the slave device identifier of each other slave device broadcast by the master device.

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

[0017] In one of the embodiments, the method further includes:

[0018] If it is determined that the existing device identifier of the first slave device is different from each slave device identifier, the operation of acquiring the slave device identifier of each other slave device broadcast by the master device is returned.

[0019] In one of the embodiments, the master device is controlled to re-allocate a new device identifier different from each slave device identifier for the first slave device, including:

[0020] The identifier abnormality information is sent to the master device to instruct the master device to generate a new identifier allocation message based on the identifier abnormality information.

[0021] The new identifier allocation message is parsed to obtain the new device identifier different from each slave device identifier re-allocated by the master device for the first slave device.

[0022] In a second aspect, the application further provides a communication abnormality processing apparatus configured in a first slave device in a fiber to the room FTTR system, including:

[0023] An acquisition module is configured to acquire the slave device identifier of each other slave device broadcast by the master device in a case where it is determined that 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 identifier of the first slave device is the same as any slave device identifier, the master device is controlled to re-allocate a new device identifier different from each slave device identifier for the first slave device.

[0025] In a third aspect, the present application also provides a computer device comprising a memory and a processor, the memory storing a computer program, and the processor implementing the following steps when executing the computer program:

[0026] In a case where it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system, slave device identifiers of each of the other slave devices broadcast by the master device are acquired;

[0027] If it is determined that the existing device identifier of the first slave device is the same as any of the slave device identifiers, the master device is controlled to reassign a new device identifier that is different from the slave device identifiers to the first slave device.

[0028] In a fourth aspect, the present application also provides a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the following steps:

[0029] In a case where it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system, slave device identifiers of each of the other slave devices broadcast by the master device are acquired;

[0030] If it is determined that the existing device identifier of the first slave device is the same as any of the slave device identifiers, the master device is controlled to reassign a new device identifier that is different from the slave device identifiers to the first slave device.

[0031] In a fifth aspect, the present application also provides a computer program product comprising a computer program, the computer program being executed by a processor to implement the following steps:

[0032] In a case where it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system, slave device identifiers of each of the other slave devices broadcast by the master device are acquired;

[0033] If it is determined that the existing device identifier of the first slave device is the same as any of the slave device identifiers, the master device is controlled to reassign a new device identifier that is different from the slave device identifiers to the first slave device.

[0034] The communication abnormality processing method, device, computer device, and readable storage medium described above, when a communication abnormality occurs between the first slave device and the master device, the scheme can quickly identify the problem and trigger the subsequent processing flow. By acquiring the slave device identifiers of the other slave devices broadcast by the master device and checking whether the device identifier of the first slave device is in conflict, the cause of the communication abnormality can be quickly located. Once the identifier conflict is determined, the master device is immediately controlled to reassign a new identifier to the first slave device, thereby quickly recovering the communication link and reducing the time of communication interruption. The scheme reassigns a new device identifier to ensure 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 DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the drawings needed to be used in the description of the embodiments of the present application or the related art will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other related drawings can be obtained by those skilled in the art without any creative effort on the basis of these drawings.

[0036] Figure 1 A flowchart of the application environment of the communication exception handling method in one embodiment;

[0037] Figure 2 A flowchart of the communication exception handling method in one embodiment;

[0038] Figure 3 A flowchart of the step of determining that a communication exception occurs between the first slave device and the master device in the FTTR system in one embodiment;

[0039] Figure 4 A flowchart of the step of obtaining the slave device identifiers of the other slave devices broadcast by the master device in one embodiment;

[0040] Figure 5 A flowchart of the step of controlling the master device to reassign a new device identifier different from the slave device identifiers to the first slave device in one embodiment;

[0041] Figure 6 A block diagram of the structure of the communication exception handling apparatus in one embodiment;

[0042] Figure 7 An internal structure diagram of the computer device in one embodiment. DETAILED DESCRIPTION

[0043] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not to limit the present application.

[0044] The FTTR (Fiber To The Room) system constructs an efficient network architecture, the core of which is that a master device is closely connected with a plurality of slave devices distributed in each room through a fiber link, realizing seamless interconnection of terminal devices, smooth data backhaul and intelligent coordination of wireless networks. Since the system needs to support stable operation of a large number of slave devices and terminal devices hung thereunder, it puts forward very high requirements on the overall stability of the network.

[0045] To ensure the continuous and efficient operation of the network, the system must have the ability to identify and quickly handle abnormal identification of slave devices. The establishment of this mechanism aims to timely discover and solve network failures caused by slave device identification errors or conflicts, thereby effectively guaranteeing the robust operation of the FTTR system as a whole.

[0046] The embodiment provides an application environment diagram of a communication exception processing method, as shown in the figure. Figure 1 The application environment includes a master device, a slave device 1 (first slave device) and a slave device 2 (second slave device), the master device and the slave device 1 can communicate in both directions, and the master device and the slave device 2 can communicate in both directions.

[0047] In an exemplary embodiment, as shown in the figure. Figure 2 A communication exception processing method is provided, and the method is applied to the first slave device in the figure. Figure 1 The method comprises the following steps.

[0048] S201, in the case where it is determined that a communication exception occurs between the first slave device and the master device in the FTTR system, obtaining the slave device identifier of each other slave device broadcast by the master device.

[0049] Wherein, the communication exception between the first slave device and the master device in the FTTR system refers to a special case caused by internal software defects of the master device. Such defects cause the master device to accidentally lose the slave device identifier information of the first slave device (i.e. slave device 1) during operation.

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

[0051] (1) Continuously monitor the communication state between the master device and the slave device, including connection stability, data transmission rate, etc. If the master device finds that the communication with the slave device 1 is suddenly interrupted, or the data transmission rate is abnormally reduced, there is a communication problem, which needs to be further analyzed.

[0052] (2) In the further analysis process, query the system log of the slave device 1 and the master device to find error messages or warnings related to communication interruption. If the log contains error codes, consult the device manual or manufacturer support document to understand whether these error codes indicate the problem of slave device identifier loss.

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

[0054] When needed, the master device will broadcast the slave device identifiers of other slave devices, for example, when a slave device has completed registration with the master device, the slave device identifiers of other slave devices can be broadcast once. In this case, when the first slave device detects communication anomalies, it will listen to the messages broadcast by the master device regularly. These messages contain the device identifier information of all other slave devices in the system.

[0055] It can be understood that the broadcast message is a communication method sent to all devices on the network. It does not rely on a specific device identifier 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 a listening state, it can receive broadcast messages sent on the network. After receiving the broadcast message, the first slave device will determine whether to process the message according to its internal filtering mechanism. If the message type meets the expectations of the first slave device (such as identifier allocation message), further processing will be performed. The reception of broadcast messages does not depend on the device identifier, so even if the master device loses the device identifier of the first slave device, the first slave device can still receive the broadcast message. Therefore, in the broadcast mode, the master device sends messages 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, the master device reassigns a new device identifier that is different from the slave device identifiers to the first slave device.

[0058] The existing device identifier of the first slave device refers to the device identifier assigned to the first slave device by the master device before the communication anomaly occurs. Before the communication anomaly 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 device identity with the other slave device identities received in the broadcast one by one. If the first slave device finds that its device identity is the same as any of the other slave device identities, it determines that there is an identity conflict. When the first slave device detects an identity conflict, it sends a conflict handling request to the master device. The request should include the current device identity of the first slave device and an indication that a new identity is requested.

[0060] Specifically, after receiving the conflict handling request from the first slave device, the master device verifies the legality of the request and ensures that the request is indeed from a slave device that has 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 through a secure communication method.

[0061] Further, after receiving the new device identity sent by the master device, the first slave device verifies the validity of the new identity (e.g., by checking the format, length, etc. of the new identity). If the new identity is valid, the first slave device updates its internal configuration, replacing the original device identity with the new identity. The first slave device sends an acknowledgement message to the master device, indicating that it has successfully updated the device identity. The master device updates its device list or database to reflect the new device identity of the first slave device. The master device can broadcast an update message to inform other slave devices and management devices in the network about the change of the first slave device identity. After the first slave device updates its device identity, it can use the new identity 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 identity.

[0062] In addition, if the device identity of the first slave device is not the same as each of the slave device identities, it continues to listen to the slave device identity information broadcast by the master device. If it still does not obtain the slave device identity information broadcast by the master device within a set time period, it is offline from the FTTR system and is subsequently registered by the master device according to the hardware serial number of the first slave device to obtain a new device identity.

[0063] The communication exception processing method can quickly identify the problem and trigger the subsequent processing flow when the communication exception occurs between the first slave device and the master device. By obtaining the identification of other slave devices broadcast by the master device and checking whether the identification of the first slave device is in conflict, the cause of the communication exception can be quickly located. Once the identification conflict is determined, the master device is immediately controlled to reassign a new identification to the first slave device, thereby quickly recovering the communication link and reducing the time of communication interruption. The scheme ensures that each slave device in the FTTR system has a unique device identification by reassigning a new device identification. This avoids communication confusion and data errors caused by identification conflicts, and improves the stability and reliability of the system.

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

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

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

[0067] Optionally, within the set communication period, the first slave device starts its listening mechanism to continuously listen to the communication message sent by the master device, the purpose being to confirm whether the master device is normally sending data by listening to the communication message, so as to judge whether the communication link is smooth.

[0068] S302, if no communication message is listened to, it is determined that a communication exception occurs between the first slave device and the master device in the FTTR system.

[0069] It can be understood that if the first slave device does not listen to any communication message from the master device within the set communication period of the first slave device, according to the set fault judgment mechanism, it is determined that a communication exception occurs between the first slave device and the master device in the FTTR system.

[0070] Wherein, the set fault judgment mechanism is: if no communication message from the master device is listened to within the set communication period of the first slave device, it is determined that the master device loses the identification of the first slave device due to its own defects.

[0071] In this embodiment, by listening to the communication message sent by the master device within the set communication period, the technical scheme can detect the communication state 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 perceive and determine that the communication is abnormal, thereby triggering the subsequent processing procedure in time. When the first slave device does not listen to the communication message, according to the preset fault judgment mechanism, it can be reasonably speculated that the master device may have lost the device identifier 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 problem source, providing a clear direction for subsequent problem solving. By timely detecting and accurately identifying communication abnormalities, the technical scheme 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 listening mechanism and fault judgment mechanism in the technical scheme can be automatically implemented without human intervention. This helps to reduce operation and maintenance costs, improve management efficiency, and make the FTTR system more intelligent and automated.

[0072] In one exemplary embodiment, as shown in Figure 4 The slave device identifier of each other slave device broadcast by the master device is obtained, including:

[0073] S401, listen to the identifier allocation message broadcast by the master device.

[0074] It can be understood 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 generates a unique device identifier for it and encapsulates the identifier into a device identifier message and sends it to the slave device. Alternatively, the slave device temporarily leaves the network due to some reasons (such as network problems, device failure, etc.) and needs to rejoin after repair. When rejoining the network, the master device generates a new device identifier or re-sends 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 identifier of the other registered slave device.

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

[0077] It can be understood that when the second slave device wants to join the FTTR system and perform device registration, it will actively send an identity application request to the master device. After receiving the identity application request of the second slave device, the master device will generate a unique device identity for the second slave device according to certain rules or algorithms. This device identity is used to uniquely identify the second slave device in the FTTR system.

[0078] Then, the master device encapsulates the generated device identity into an identity allocation message. This message not only contains the device identity of the second slave device, but also contains other necessary information such as message type, sender (master device) identity, timestamp, etc. The encapsulated identity allocation message will be broadcast 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 the identity allocation message is listened to within the listening duration, the identity allocation message is parsed to obtain the slave device identities of each other slave device broadcast by the master device.

[0080] Specifically, the first slave device parses the identity allocation message to obtain the slave device identities of each other slave device broadcast by the master device.

[0081] In addition, if the identity allocation message is not listened to within the listening duration, the first slave device is disconnected from the FTTR system and is re-registered with the master device based on the hardware serial number of the first slave device to obtain a new device identity.

[0082] In this embodiment, by listening to the identity allocation message broadcast by the master device, the first slave device can dynamically obtain the device identities of other slave devices in the FTTR system. This mechanism ensures the real-time and accuracy of the slave device identities, avoiding communication conflicts and data confusion caused by outdated or incorrect 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 identity for it and broadcast it to all slave devices through the identity allocation message. This mechanism supports the dynamic joining of slave devices, making the FTTR system more flexible and scalable. By ensuring that each slave device has a unique device identity and updating these 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 caused by identity conflicts or errors, thereby improving the overall reliability and performance of the system.

[0083] In an exemplary embodiment, as shown in Figure 5 the control master device re-allocates a new device identity different from the slave device identities for the first slave device, including:

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

[0085] Optionally, if it is determined that the existing device identification of the first slave device is the same as any slave device identification, identification abnormality information is generated, which should include the current device identification of the first slave device and an indication of requesting re-allocation of a new identification.

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

[0087] S502, parsing the new identification allocation message to obtain a new device identification that is different from the identifications of all slave devices and that is allocated to the first slave device by the master device.

[0088] It can be understood that when the first slave device receives this message, it will parse the new device identification in it and update its own identification information. After that, it can use this new identification to communicate with other devices in the network. When other slave devices receive this message, they will also update their knowledge of the identification of the first slave device to ensure the correctness of subsequent communication.

[0089] In this embodiment, when the first slave device discovers that its device identification conflicts with other slave devices, it can quickly trigger the master device to re-allocate a new identification for it by sending identification abnormality information. This mechanism efficiently solves the identification conflict problem and avoids communication obstacles and data chaos caused by conflicts. The master device generates a new, unique device identification for the first slave device based on the identification abnormality 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 foundation for stable operation of the system. After receiving the new identification allocation message, the first slave device will parse the new device identification in it and update its own identification information. This dynamic updating mechanism enables the slave device to adapt to changes in the network in a timely manner and maintain normal communication with other devices in the network. This technical solution allows the slave device to actively request the master device to re-allocate an identification when it discovers an identification conflict, improving the flexibility and adaptability of the system. This mechanism enables the FTTR system to better handle scenarios such as dynamic addition, removal or fault recovery of slave devices. Through automated identification conflict detection and resolution mechanism, this technical solution reduces the maintenance cost of the FTTR system. The 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, an implementation process of a communication exception handling method is provided, specifically comprising:

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

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

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

[0094] 4. When the identification exception clock times out and slave device 1 still does not receive any downlink messages, it enters a listening mode and begins to closely monitor messages that may appear in the network that allocate slave device identification. At the same time, a listening clock is started to limit the listening time.

[0095] 5. Another slave device (slave device 2) is powered on and starts the registration activation process. It reports its serial number to the master device and waits to receive the slave device identification allocated by the master device through a specific message, at this time in the O2-3 state.

[0096] 6. Slave device 1 receives this message allocating slave device identification in the listening process. It parses the message content, extracts the serial number and slave device identification, and carefully compares them 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 identification is the same as its own identification, it immediately determines that a repeated allocation of slave device identification exception has occurred in the network. Then, slave device 1 reports an identification reallocation alarm and restarts the registration activation process to try to obtain a new, unique slave device identification.

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

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

[0100] Through the above scheme, the FTTR system can effectively detect and handle the repeated allocation anomaly of the slave device identifier, ensure that each slave device in the network has a unique and correct identifier, and thus maintain the stability of the entire system and the smoothness of communication.

[0101] It should be understood that, although each step in the flowchart involved in each of the above embodiments is shown in sequence according to the arrow, these steps are not necessarily executed in the order indicated by the arrow. Unless otherwise specified herein, there is no strict order limitation for the execution of these steps, and these steps can be executed in other orders. Moreover, at least part of the steps in the flowchart involved in each of the above embodiments can include multiple steps or stages, which 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 sequential, but can be alternately executed with at least part of other steps or stages or steps or stages in other steps.

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

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

[0104] The acquisition module 11 is configured to, in a case where it is determined that a communication exception occurs between the first slave device and the master device in the FTTR system, acquire the slave device identifiers of each other slave device broadcast by the master device;

[0105] The exception handling module 12 is configured to, 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 re-allocate a new device identifier that is different from each slave device identifier for the first slave device.

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

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

[0108] In the above embodiment, the master device and the first slave device are in a communication state in a period before the communication period.

[0109] In one of the embodiments, the obtaining module 11 is further configured to listen to the identity allocation message broadcast by the master device.

[0110] If the identity allocation message is listened to within the listening duration, the identity allocation message is parsed to obtain the slave device identities of each of the other slave devices broadcast by the master device.

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

[0112] In one of the embodiments, the apparatus further comprises a loop processing module configured to, if it is determined that the existing device identity of the first slave device is different from each of the slave device identities, return to perform the operation of obtaining the slave device identities of each of the other slave devices broadcast by the master device.

[0113] In one of the embodiments, the exception handling module 12 is further configured to send identity exception information to the master device, so as to instruct the master device to generate a new identity allocation message based on the identity exception information.

[0114] The new identity allocation message is parsed to obtain a new device identity allocated by the master device for the first slave device, which is different from each of the slave device identities.

[0115] Each of the modules in the communication exception handling apparatus described above can be realized by software, hardware, and combinations thereof, in whole or in part. Each of the modules described above can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory in the computer device in software form, so as to be called and executed by the processor to perform the operations corresponding to each of the modules.

[0116] In one exemplary embodiment, a computer device is provided, which can be a server, and an internal structure diagram of the computer device can be as shown in Figure 7As shown in the figure. 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 the 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 capability. 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 external devices. The communication interface of the computer device is used to communicate with external terminals through network connection. The computer program is executed by the processor to implement a communication exception handling method.

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

[0118] In one exemplary embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the following steps:

[0119] In a case where it is determined that a communication exception occurs between the first slave device and the master device in the FTTR system, the slave device identifier of each other slave device broadcast by the master device is acquired;

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

[0121] In one embodiment, the processor executing the computer program further implements the following steps: listening to the communication message sent by the master device within a set communication period; if no communication message is listened to, it is determined that a communication exception occurs between the first slave device and the master device in the FTTR system;

[0122] Among them, the master device and the first slave device are in a communication state within a period before the communication period.

[0123] In an embodiment, the processor, when executing the computer program, further implements the following steps: listening to an identity allocation message broadcast by the master device; if the identity allocation message is listened to within a listening duration, parsing the identity allocation message to obtain the slave device identities of the other slave devices broadcast by the master device.

[0124] In an embodiment, the identity allocation message is generated by the master device according to an 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 registering the device.

[0125] In an embodiment, the processor, when executing the computer program, further implements the following steps: if it is determined that the existing device identity of the first slave device is different from each of the slave device identities, returning to perform the operation of obtaining the slave device identities of the other slave devices broadcast by the master device.

[0126] In an embodiment, the processor, when executing the computer program, further implements the following steps: sending identity exception information to the master device to instruct the master device to generate a new identity allocation message based on the identity exception information; and parsing the new identity allocation message to obtain a new device identity allocated by the master device for the first slave device, which is different from each of the slave device identities.

[0127] In an embodiment, a computer readable storage medium is provided, and the computer readable storage medium stores a computer program. The computer program is executed by a processor to implement the following steps:

[0128] In a case where it is determined that a communication exception occurs between the first slave device and the master device in the FTTR system, obtaining the slave device identities of the other slave devices broadcast by the master device;

[0129] If it is determined that the existing device identity of the first slave device is the same as any of the slave device identities, controlling the master device to allocate a new device identity for the first slave device, which is different from each of the slave device identities.

[0130] In an embodiment, the computer program, when executed by the processor, further implements the following steps: within a set communication period, listening to a communication packet sent by the master device; if no communication packet is listened to, determining that a communication exception occurs between the first slave device and the master device in the FTTR system;

[0131] In an embodiment, the master device and the first slave device are in a communication state within a period before the communication period.

[0132] In an embodiment, the computer program, when executed by the processor, further implements the following steps: listening to an identity allocation message broadcast by the master device; if the identity allocation message is listened to within a listening duration, parsing the identity allocation message to obtain the slave device identities of the other slave devices broadcast by the master device.

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

[0134] In an embodiment, the computer program, when executed by the processor, further implements the following steps: if it is determined that the existing device identity of the first slave device is different from each of the slave device identities, returning to perform the operation of obtaining the slave device identities of each of the other slave devices broadcast by the master device.

[0135] In an embodiment, the computer program, when executed by the processor, further implements the following steps: sending identity exception information to the master device to instruct the master device to generate a new identity allocation message based on the identity exception information; and parsing the new identity allocation message to obtain a new device identity allocated by the master device to the first slave device, which is different from each of the slave device identities.

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

[0137] In a case where it is determined that a communication exception occurs between the first slave device and the master device in the FTTR system, obtaining the slave device identities of each of the other slave devices broadcast by the master device;

[0138] If it is determined that the existing device identity of the first slave device is the same as any of the slave device identities, controlling the master device to allocate a new device identity to the first slave device, which is different from each of the slave device identities.

[0139] In an embodiment, the computer program, when executed by the processor, further implements the following steps: listening to a communication packet sent by the master device within a set communication period; and if no communication packet is listened to, determining that a communication exception 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 an embodiment, the computer program, when executed by the processor, further implements the following steps: listening to an identity allocation message broadcast by the master device; and if the identity allocation message is listened to within a listening duration, parsing the identity allocation message to obtain the slave device identities of each of the other slave devices broadcast by the master device.

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

[0143] In one embodiment, the computer program, when executed by the processor, further implements the following steps: if it is determined that the existing device identifier of the first slave device is different from each of the slave device identifiers, returning to perform the operation of obtaining the slave device identifier of each other slave device broadcasting the master device.

[0144] In one embodiment, the computer program, when executed by the processor, further implements the following steps: sending the identification exception information to the master device, so as to instruct the master device to generate a new identification allocation message based on the identification exception information; and parsing the new identification allocation message to obtain a new device identifier allocated by the master device to the first slave device, which is different from each of the slave device identifiers.

[0145] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when executed, can include the processes of the above-mentioned embodiment methods. Any reference to 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. The non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. The volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration but not limitation, the RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The database involved in the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a block chain, etc., without being limited thereto. The processor involved in the embodiments provided in the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., without being limited thereto.

[0146] The technical features of the above embodiments can be combined arbitrarily. In order to make the description simple, all possible combinations of the technical features in the above embodiments are not described, however, as long as the combinations of the technical features do not exist contradictory, they should be considered as the scope of the present application.

[0147] The above-described embodiments are merely illustrative of several embodiments of the present application, and the description is relatively specific and detailed, but should not be understood as a limitation on the scope of the patent. It should be noted that for those skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are all within the scope of the present application. Therefore, the scope of protection of the present application should be subject to the appended claims.

Claims

1. A communication abnormality processing method characterized by comprising: A first slave device applied to a fiber to the room (FTTR) system, the method comprises: In the case where it is determined that a communication abnormality occurs between the first slave device and a master device in the FTTR system, a master device broadcasted identity allocation message is listened to; wherein the communication abnormality is that the master device loses the slave device identity information of the first slave device in the running process; the identity allocation message is generated by the master device according to an identity application request initiated by a second slave device; the identity application request is initiated by the second slave device when joining the FTTR system and performing device registration; If the identity allocation message is listened to within a listening duration, the identity allocation message is parsed to obtain the slave device identity of each other slave device broadcasted by the master device; If it is determined that the existing device identity of the first slave device is the same as any slave device identity, the master device is controlled to re-allocate a new device identity different from each slave device identity for the first slave device.

2. The method of claim 1, wherein, The determination that a communication abnormality occurs between the first slave device and the master device in the FTTR system comprises: In a set communication period, a communication message sent by the master device is listened to; If the communication message is not listened to, it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system; Wherein, the master device and the first slave device are in a communication state in a period before the communication period.

3. The method of claim 1, wherein, The method further comprises: If it is determined that the existing device identity of the first slave device is different from each slave device identity, the operation of obtaining the slave device identity of each other slave device broadcasted by the master device is returned.

4. The method of claim 1, wherein, The control of the master device to re-allocate a new device identity different from each slave device identity for the first slave device comprises: Sending an identity abnormality information to the master device to instruct the master device to generate a new identity allocation message based on the identity abnormality information; Parses the new identity allocation message to obtain the new device identity different from each slave device identity allocated by the master device for the first slave device.

5. A communication abnormality processing apparatus characterized by comprising: A first slave device configured in a fiber to the room (FTTR) system, the device comprises: An acquisition module, configured to listen to a master device broadcasted identity allocation message in the case where it is determined that a communication abnormality occurs between the first slave device and the master device in the FTTR system; if the identity allocation message is listened to within a listening duration, the identity allocation message is parsed to obtain the slave device identity of each other slave device broadcasted by the master device; wherein the communication abnormality is that the master device loses the slave device identity information of the first slave device in the running process; the identity allocation message is generated by the master device according to an identity application request initiated by a second slave device; the identity application request is initiated by the second slave device when joining the FTTR system and performing device registration; An exception handling module is configured to control the master device to reassign a new device identifier 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. 6.A computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the computer device is configured to perform the method according to any one of claims 1-5 when the computer program is executed by the processor. The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 4.

7. A computer readable storage medium having stored thereon a computer program, characterized in that The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 4.

8. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 4. The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 4.

Images