Optical transmission network equipment communication method and equipment

Abstract

The invention discloses an optical transmission network equipment communication method and equipment, and relates to the technical field of optical transmission network equipment communication, and the method comprises the steps: obtaining a frame identifier of an equipment frame where a single board is located, and a slot identifier of a slot where the single board is located; according to the frame identifier and the slot identifier, a transparent inter-process communication service address of a single board is determined, and the single board comprises a main control board and a service line card board; and performing communication between the single board and other single boards in the cluster based on the transparent inter-process communication service address. According to the method, the addressing information required by communication and the fixed physical position information of the OTN equipment are bound and mapped, so that the tight coupling relationship among a communication protocol, a physical carrier and an upper-layer application is radically relieved, and the system maintenance complexity and the upgrading cost caused by the change of a communication infrastructure are remarkably reduced.

Description

Technical Field

[0001] This application relates to the field of optical transmission network equipment communication technology, and in particular to an optical transmission network equipment communication method and device. Background Technology

[0002] Currently, OTN (Optical Transport Network) equipment is mainly deployed in two ways: separate deployment and integrated deployment. Separate deployment places the electrical layer signal processing board and the optical layer signal processing board in different device frames of the OTN equipment, while integrated deployment allows both to coexist in the same device frame of the OTN equipment.

[0003] However, OTN devices deployed using these two methods generally rely on the communication functions of various upper-layer applications distributed across the OTN device in existing cluster communication solutions. This means they use TCP / IP protocol stacks or proprietary Layer 2 protocols to achieve inter-node communication, resulting in a high degree of coupling between the communication protocol, physical carrier, and upper-layer applications. This tightly coupled communication architecture means that if the communication protocol or physical carrier changes, all related upper-layer applications must be adjusted synchronously, greatly increasing the complexity of system maintenance and upgrade costs. Summary of the Invention

[0004] The main purpose of this application is to provide a communication method and device for optical transmission network equipment, which aims to solve the technical problem of poor maintainability caused by the high coupling of the current OTN equipment communication architecture.

[0005] To achieve the above objectives, this application proposes a communication method for an optical transmission network device, the communication method comprising: Obtain the unique identifier of a single board in an optical transmission network device. The unique identifier includes the frame identifier of the device frame in which the single board is located and the slot identifier of the slot in which the single board is located. Based on the frame identifier and the slot identifier, the transparent inter-process communication service address of the single board in the cluster is determined, wherein the cluster is composed of multiple single boards; Based on the transparent inter-process communication service address, communication between the single board and other single boards is carried out within the cluster.

[0006] In one embodiment, the step of determining the transparent inter-process communication service address of the single board within the cluster based on the frame identifier and the slot identifier includes: Based on the frame identifier and the slot identifier, generate the node identifier corresponding to the single board; Based on the type of the single board, the node identifier is mapped to the transparent inter-process communication service address of the single board within the cluster.

[0007] In one embodiment, the step of mapping the node identifier to the transparent inter-process communication service address of the board within the cluster according to the type of the board includes: When the type of the single board is a service line board, determine the first type field mapped by the service line board and the instance field mapped by the node identifier, and form the transparent inter-process communication service address of the service line board in the cluster based on the first type field and the instance field. When the type of the single board is a main control board, the second type field mapped by the main control board and the instance field range mapped by the node identifier are determined, and the transparent inter-process communication service address of the main control board in the cluster is formed according to the second type field and the instance field range. The instance field range includes a combination of instance fields corresponding to each service line card that communicates with the main control board.

[0008] In one embodiment, after determining the transparent inter-process communication service address of the board within the cluster based on the frame identifier and the slot identifier, the method further includes: Register the single board according to the power-on sequence of the single board in the cluster, or through the single board maintenance service registry; Specifically, when the type of the single board is a service line card, the service line card is registered; when the type of the single board is a main control board, the service registry of the service line card is maintained by the main control board, and the service registry is used to record the registration status of the service line card.

[0009] In one embodiment, the step of registering the single board according to its power-on order within the cluster, or through the single board maintenance service registry, includes: In the cluster, the power-on sequence of the main control board and the service line card is as follows: if the main control board powers on before the service line card, the service line card sends a registration message to the main control board to register the service line card. The registration message includes the service type of the service line card and the physical information of the service line card. Within the cluster, the power-on sequence of the main control board and the service line cards is as follows: if the service line cards are powered on before the main control board, the main control board sends a registration request to the service line cards to request the service line cards to respond with the registration message.

[0010] In one embodiment, the step of enabling communication between the single board and other single boards within the cluster based on the transparent inter-process communication service address includes: When the type of the single board is a main control board, in response to the configuration management request, the main control board calls the preset configuration management interface to generate the configuration management request message corresponding to the configuration management request; The main control board maps the first target frame identifier and the first target slot identifier carried in the configuration management request message to the first target transparent inter-process communication service address, and packages the configuration management request message based on the first target transparent inter-process communication service address. The main control board transmits the packaged configuration management request message to the first target service line card corresponding to the first target transparent inter-process communication service address.

[0011] In one embodiment, the optical transmission network device communication method further includes: The configuration management request message after the package is received through the first target service line card; When the configuration management request is a configuration request, the packaged configuration management request message is processed by the first target service line card so that the first target service line card executes the configuration task corresponding to the configuration request message; The execution result of the configuration task is obtained through the first target service line card, and the configuration response message corresponding to the execution result is returned to the main control board.

[0012] In one embodiment, the step of enabling communication between the single board and other single boards within the cluster based on the transparent inter-process communication service address includes: When the type of the single board is a service line card, in response to a service alarm request, a preset service alarm interface is called through the second target service line card in the cluster to generate service alarm information corresponding to the service alarm request. The message header of the service alarm information includes the second target frame identifier and the second target slot identifier of the main control board corresponding to the second target service line card. The second target frame identifier and the second target slot identifier are mapped to the second transparent inter-process communication service address through the second target service line card. The second target service line card sends the service alarm information to the main control board based on the second transparent inter-process communication service address.

[0013] In one embodiment, the cluster further includes multiple sites, each site including at least one optical transmission network device, the single board including a service line card, the service line card type including an optical amplifier board and an optical line amplifier board, and the sites are connected through the optical monitoring channel of the optical amplifier board and / or the optical line amplifier board.

[0014] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the optical transmission network device communication method as described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: The technical solution of this application obtains a unique identifier at the hardware level of each board, including the frame identifier and slot identifier. Then, based on this unique identifier, it determines the TIPC (Transparent Inter-process Communication) service address of each board within the cluster. Finally, communication between boards within the cluster is based on these pre-determined TIPC service addresses. This binds and maps the addressing information required for communication—the TIPC service address—with the fixed physical location information of the OTN device—the frame identifier and slot identifier—constructing a standardized communication addressing layer independent of specific upper-layer applications. In this way, the communication logic between boards within the cluster is abstracted from specific business applications and no longer depends on the communication functions scattered across various upper-layer application modules. When the underlying communication protocol or the physical carrier carrying the communication needs to be changed, only this mapping relationship and the corresponding communication addressing layer need to be adjusted, while the business logic of the upper-layer applications does not need to be modified. This fundamentally decouples the communication protocol, physical carrier, and upper-layer applications, significantly reducing the system maintenance complexity and upgrade costs caused by changes in the communication infrastructure. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating an embodiment of the communication method for an optical transmission network device according to this application. Figure 2 This is a schematic diagram of a cross-site communication scenario for the optical transmission network device communication method provided in Embodiment 1 of this application; Figure 3 This is a flowchart illustrating Embodiment 2 of the communication method for optical transmission network equipment in this application. Figure 4 This is a flowchart illustrating Embodiment 3 of the optical transmission network device communication method of this application; Figure 5 A simplified flowchart illustrating the communication method of the optical transmission network device provided in Embodiment 3 of this application; Figure 6 This is a schematic diagram of the hardware operating environment involved in the communication method of the optical transmission network device in the embodiments of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] The main solution of this application embodiment is: to obtain the unique identifier of a single board in an optical transmission network device, wherein the unique identifier includes the frame identifier of the device frame in which the single board is located and the slot identifier of the slot in which the single board is located; to determine the transparent inter-process communication service address of the single board in the cluster based on the frame identifier and the slot identifier, wherein the cluster is composed of multiple single boards; and to perform communication between the single board and other single boards in the cluster based on the transparent inter-process communication service address.

[0023] Because existing cluster communication solutions generally rely on the communication functions of various upper-layer applications distributed across OTN devices—that is, using TCP / IP protocol stacks or proprietary Layer 2 protocols to achieve inter-node communication—there is a high degree of coupling between the communication protocol, physical carrier, and upper-layer applications. This tightly coupled communication architecture means that once the communication protocol or physical carrier changes, all related upper-layer applications must be adjusted synchronously, greatly increasing the complexity of system maintenance and upgrade costs.

[0024] This application provides a solution that obtains a unique identifier at the hardware level of a single board, including a frame identifier and a slot identifier. Then, based on this unique identifier, it determines the TIPC service address of the board within the cluster. Finally, communication between boards within the cluster is based on these pre-determined TIPC service addresses. This binds and maps the addressing information required for communication—the TIPC service address—with the fixed physical location information of the OTN device—the frame identifier and slot identifier—constructing a standardized communication addressing layer independent of specific upper-layer applications. In this way, the communication logic between boards within the cluster is abstracted from specific business applications and no longer depends on the communication functions scattered across various upper-layer application modules. When the underlying communication protocol or the physical carrier carrying the communication needs to be changed, only this mapping relationship and the corresponding communication addressing layer need to be adjusted, while the business logic of the upper-layer applications does not need to be modified. This fundamentally decouples the communication protocol, physical carrier, and upper-layer applications, significantly reducing the system maintenance complexity and upgrade costs caused by changes in the communication infrastructure.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions. The following description uses an electronic device as an example to illustrate this embodiment and the subsequent embodiments.

[0026] Based on this, embodiments of this application provide a communication method for an optical transmission network device, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the communication method for optical transmission network equipment in this application.

[0027] In this embodiment, the communication method of the optical transmission network device includes steps S10 to S30: Step S10: Obtain the unique identifier of the single board in the optical transmission network device. The unique identifier includes the frame identifier of the device frame where the single board is located and the slot identifier of the slot where the single board is located. It should be noted that a single board refers to the core hardware that constitutes an OTN device; it is an independent printed circuit board inserted into a slot in the device frame. A single board may include, but is not limited to, a main control board (including main / backup main control boards), electrical layer signal processing line cards (i.e., OTU (Optical Transponder) boards, used to realize signal conversion from the client side to the line side), and optical layer signal processing line cards (such as AAWG (Arrayed Waveguide Grating) boards, OLP (Optical Line Protection) boards, OA (Optical Amplifier) ​​boards, and OLA (Optical Line Amplifier) ​​boards, etc.). Each single board has independent processing capabilities and specific service functions, and is the basic physical unit for performing tasks such as optical transmission, signal processing, system control, or network management.

[0028] The main control board is the core of system control and management within the OTN device chassis. Main control boards can exist in pairs (1+1 master / slave), such as main control boards A and B, occupying fixed slots within the chassis. It integrates a high-performance CPU processor and switching chips, responsible for device management, configuration distribution, performance monitoring, alarm collection, and communication with external network management systems via the Netconf protocol for the entire chassis and even the entire cluster. In the cluster communication framework, the main control board acts as the management node, maintaining the global service registry and handling control signaling and data exchange with all service line cards.

[0029] Service line cards are the individual boards within the OTN equipment chassis responsible for handling specific transmission services. They can be divided into two main categories: electrical layer signal processing line cards (such as OTU boards) and optical layer signal processing line cards (such as AAWG boards, OLP boards, OA boards, OLA boards, etc.). These boards carry the core service functions of the OTN network, such as photoelectric signal conversion, wavelength multiplexing / demultiplexing, optical signal amplification, and line protection. Service line cards receive configuration and management commands from the main control board, execute corresponding service processing, and report performance data and alarm information to the main control board, serving as the execution unit for completing actual optical transmission tasks.

[0030] A frame identifier is a unique identification code assigned to an OTN device frame within a specific cluster network. Each device frame is assigned a unique frame ID within the cluster. This frame ID can be pre-stored in the device frame's backplane EEPROM (Electrically Erasable Programmable Read-Only Memory) or in the main control board's Flash memory. When the device frame is powered on, the main control board reads the frame ID and transmits it to other boards within the frame via backplane traces or a CPLD (Complex Programmable Logic Device). The frame identifier is crucial for distinguishing different physical device frames within the cluster and is fundamental for cross-frame communication and cluster resource management.

[0031] Slot identifiers are unique numbers used within an OTN device frame to identify the location of each physical slot. When a board is inserted into a specific slot, it can obtain its slot ID through electrical connections on the backplane or CPLD communication. Slot identifiers ensure that different boards within the same device frame have clear location information and are one of the components constituting the unique identifier of a board, working together with the frame identifier to accurately locate each board within the cluster.

[0032] Furthermore, it should be noted that a complete OTN device typically consists of one or more device frames in its physical form. Each device frame can be an independent physical chassis with a series of fixed slots inside. These slots are physical slots conforming to specific specifications, used to install and fix various functional boards. Some slots are fixed, used to insert system-essential boards such as main control boards, power supply boards, and fan boards; the rest are flexible slots, which can accommodate different types of service line cards according to networking requirements. Therefore, an OTN device consists of a device frame forming the skeleton, slots providing physical location and electrical connections, and various boards inserted into the slots serving as the carriers for all intelligent control and service functions of the device. In a cluster system, multiple such OTN device frames are interconnected through the network interface of their main control board or the optical monitoring channel of service line cards (such as OA / OLA boards), forming a unified logical device cluster.

[0033] Step S20: Determine the transparent inter-process communication service address of the single board in the cluster based on the frame identifier and the slot identifier, wherein the cluster is composed of multiple single boards; It's important to note that the transparent inter-process communication service address is a network communication address assigned to each board logical entity within the cluster, based on the TIPC protocol. This address is a logical address generated by mapping the board's unique identifier, i.e., the frame identifier and slot identifier, according to specific rules. For example, the frame ID (frame identifier) ​​and slot ID (slot identifier) ​​are combined and mapped to the "Type" and "Instance" fields defined by the TIPC protocol. The core characteristic of this address is service address transparency; that is, the communicating parties do not need to know each other's physical network location, such as IP address, but only need to know their service logical address to communicate. This decouples the communication logic from the physical network, supporting flexible and reliable inter-process message passing within the cluster.

[0034] Step S30: Based on the transparent inter-process communication service address, communication between the single board and other single boards is performed within the cluster.

[0035] It is understood that the technical solution of this embodiment introduces a communication addressing mechanism based on mapping hardware physical location to cluster protocol logical addresses. This involves obtaining the inherent unique hardware identifier, including frame identifier and slot identifier, and determining the TIPC service address of each board within the cluster based on this identifier. Communication then occurs between boards within the cluster based on this TIPC service address. This constructs a standardized communication addressing layer independent of specific upper-layer business applications, binding the logical address required for communication to the immutable physical location information of the OTN device. This effectively avoids the problem of deep coupling between communication protocols, physical carriers, and upper-layer application functions. Because when the underlying communication protocol or physical network carrier needs to be changed or upgraded, only this mapping relationship and the corresponding communication addressing layer need to be adjusted, while the upper-layer applications carrying specific business functions do not need to be modified. This significantly reduces the complexity of system maintenance and the upgrade costs caused by changes in the communication infrastructure, ultimately improving the maintainability of the OTN device cluster system.

[0036] For example, in response to the power-on of a single board in an OTN device, that is, when a single board (whether it is a main control board or a service line card) inserted into a slot of an OTN device frame is powered on, the onboard CPU processor of the single board will read the pre-stored frame identifier representing the identity of the physical device frame from the backplane EEPROM of the device frame, for example, frame ID=1, and at the same time obtain the slot identifier of the slot into which it is inserted through the backplane electrical connection or CPLD communication, for example, slot ID=3, thereby forming the hardware unique identifier of the single board. Subsequently, the system software, based on the frame identifier "1" and slot identifier "3", follows predefined mapping rules. For example, it uses the frame identifier as the Cluster field in the TIPC node identifier, the slot identifier as the Node field, and fixes the Zone field at 0, generating a TIPC node identifier in the format "0:1:3". This node identifier is then further mapped to a specific TIPC service address. For instance, for a service line card, its service address's Type field is defined as 0x02, and the Instance field is calculated as frame identifier × 100 + slot identifier, which is 103. Ultimately, all boards within the cluster, based on their own and each other's determined, physically location-bound TIPC service addresses, communicate with the main control board and service line cards within or outside the same frame via internal VLANs defined by the switching chips within the device frame or physical links across frames (such as network cables or optical monitoring channels). This communication process, including configuration distribution, status querying, and alarm reporting, is achieved without needing to know the specific network layer IP address of the other party.

[0037] In addition, the following schemes can be implemented during the operation of the OTN device cluster system: First, all successfully registered service line cards will periodically (e.g., every 100 milliseconds) send heartbeat packets to the main control board. The main control board monitors these heartbeat packets to maintain the registration status of the corresponding card in its service registry. If a preset number of heartbeats are lost consecutively, the service line card is determined to be offline, thus achieving real-time awareness of the online status of the card. Second, for the main control board itself, an A / B board hot standby protection mechanism is adopted. The two main control boards are connected to the cluster network through a dual-star interconnection structure, and their status is synchronized in real time by the communication framework. When the primary path fails, the cluster communication automatically and seamlessly switches to the backup path, ensuring the high availability of the management node. Finally, in the communication process based on the TIPC service address, for critical data transmission such as configuration management request messages, a message ID-based acknowledgment and retransmission mechanism is adopted. If the sender does not receive an acknowledgment within the timeout period, it will retransmit a limited number of times according to the policy (e.g., a maximum of 3 times). If it ultimately fails, it will be reported to the upper-layer application to ensure the final reliability of the communication.

[0038] In one feasible implementation, the cluster further includes multiple sites, each site including at least one optical transmission network device, the single board including a service line card, the service line card type including optical amplifier board and optical line amplifier board, and the sites are connected through the optical amplifier board and / or the optical line amplifier board's optical monitoring channel.

[0039] It should be noted that a site refers to a network deployment location unit with a clearly defined geographical or physical separation attribute. Each site contains at least one OTN device with a complete equipment chassis. A site can be a data center, a telecommunications equipment room, or a remote network node. In a cluster system, these sites are connected by fiber optic cables through specific service line cards in their internal OTN equipment chassis, namely OA boards or OLA boards, which provide the OSC (Optical Supervisory Channel). This enables logical networking across distances of tens or even hundreds of kilometers, allowing multiple geographically dispersed equipment chassis to be managed as a unified cluster system at the communication layer.

[0040] Understandably, when OTN device clusters need to be deployed across multiple geographically dispersed sites, such as different data centers or network nodes, traditional interconnection methods based on electrical signals and local area networks have limitations in transmission distance, bandwidth efficiency, and resource utilization. Specifically, these limitations manifest as the inability to directly support long-distance communication, the need to allocate independent external IP addresses to each site leading to wasted IP resources, and potential service interruptions during expansion. Therefore, this implementation method effectively utilizes the inherent optical layer transmission capabilities of OTN devices by employing a technical solution that carries and connects communication between device chassis belonging to different sites within the cluster via optical monitoring channels on OA and OLA boards.

[0041] This solution avoids the problems of low transmission efficiency, weak adaptability, and high resource consumption of traditional cluster communication mechanisms in cross-site and long-distance scenarios. It achieves seamless integration of multiple geographically dispersed sites into a logically unified and uniformly manageable ultra-large capacity OTN device cluster. This saves IP address resources while supporting long-distance networking and enables smooth system expansion without interrupting existing services, significantly enhancing the cross-scenario adaptability and deployment flexibility of the entire cluster system.

[0042] For example, please refer to Figure 2When it is necessary to build a long-distance cross-site cluster between three geographically separated sites (e.g., sites 1 and 3 as OTN terminals, and site 2 as a relay station), the implementation can be as follows: An OA board is inserted into the OTN equipment chassis of site 1, an OLA board is inserted into the OTN equipment chassis of site 2, and another OA board is inserted into the OTN equipment chassis of site 3. Then, an OSC on the OA board of site 1 is connected to an OSC on the OLA board of site 2 via optical fiber, and simultaneously, an OSC on the OA board of site 3 is connected to another OSC on the OLA board of site 2. Next, the switching chip ports on these OA and OLA boards that interface with the OSCs are configured as internal network VLANs for cluster communication. Thus, these three sites located in different geographical locations establish a long-distance optical transmission link carrying cluster communication data through the OSCs on the OA and OLA boards within their OTN equipment chassis. This logically integrates all OTN equipment chassis deployed at each site into a single, uniformly manageable cluster system, achieving resource pooling and unified communication across geographical sites.

[0043] Furthermore, multiple device frames in Site 1 or Site 3 are interconnected in a daisy-chain configuration via network ports on their respective main control boards. Within a single site, only one device frame is the master frame, and the others are slave frames. Only one network port on the master frame needs to connect to the network management system, and an external IP address is configured on the main control board on the master frame for communication with the network management system. Other slave frames do not require external IP addresses. All controlled boards (i.e., service line cards) on the master and slave frames are centrally managed by the main control board on the master frame, enabling a short-distance OTN multi-frame interconnection cluster within a single site.

[0044] This embodiment provides a communication method for optical transmission network devices. By obtaining a unique identifier at the hardware level of each board, including a frame identifier and a slot identifier, the TIPC service address within the cluster is determined for each board based on this unique identifier. Finally, communication between boards within the cluster is based on these pre-determined TIPC service addresses. This binds and maps the addressing information required for communication—the TIPC service address—with the fixed physical location information of the OTN device—the frame identifier and slot identifier—constructing a standardized communication addressing layer independent of specific upper-layer applications. In this way, the communication logic between boards within the cluster is abstracted from specific business applications and no longer depends on the communication functions scattered across various upper-layer application modules. When the underlying communication protocol or the physical carrier carrying the communication needs to be changed, only this mapping relationship and the corresponding communication addressing layer need to be adjusted, while the business logic of the upper-layer applications does not need to be modified. This fundamentally decouples the communication protocol, physical carrier, and upper-layer applications, significantly reducing the system maintenance complexity and upgrade costs caused by changes in the communication infrastructure.

[0045] In one feasible implementation, step S20 may include steps S21-S22: Step S21: Based on the frame identifier and the slot identifier, generate the node identifier corresponding to the single board; It's important to note that the node identifier is a structured logical identifier generated based on the board's physical hardware location information, specifically the frame identifier and slot identifier, according to the addressing format specified in the TIPC protocol. This identifier is unique within the cluster. Specifically, the node identifier structure can be "Zone:Cluster:Node", where the Zone field is fixed at 0 to indicate the local cluster, the Cluster field is assigned the frame identifier of the device frame where the board resides, and the Node field is assigned the slot identifier of the slot where the board resides. For example, a board with frame ID 1 and slot ID 3 would have a node identifier of "0:1:3". This node identifier is a crucial intermediate data structure connecting the underlying hardware unique identifier with the upper-layer TIPC service address, providing a direct conversion basis for subsequently mapping the board to a specific TIPC service address.

[0046] Step S22: Based on the type of the single board, map the node identifier to the transparent inter-process communication service address of the single board within the cluster.

[0047] It is understandable that directly using box identifiers and slot identifiers for cluster communication addressing may lead to unclear address semantics and poor matching with the internal addressing model of the TIPC protocol, thereby affecting the full realization of the inherent advantages of the TIPC protocol, such as automatic topology discovery and service address transparency.

[0048] To address this, this implementation further generates structured node identifiers first, and then maps them to TIPC service addresses. Specifically, it first generates standardized node identifiers conforming to the TIPC protocol based on the frame identifier and slot identifier, and then maps these node identifiers to specific TIPC service addresses, including Type and Instance fields, according to the board type. This scheme avoids the address structure chaos and disconnect from the protocol's internal mechanisms that can result from direct mapping. It achieves a standardized and structured conversion of hardware information to protocol logical addresses, enabling the TIPC protocol's service discovery and multi-transmission modes to operate efficiently and stably in the OTN device cluster. This further enhances the reliability, manageability, and overall system performance of cluster communication while achieving communication decoupling.

[0049] For example, when a service line card in an OTN device cluster is powered on, its onboard software first obtains the unique identifier of the card, such as frame ID 1 and slot ID 3. Then, according to the TIPC protocol's addressing specifications, these two identifiers are combined to generate a structured node identifier in the format "Zone:Cluster:Node". Here, Zone is fixed at 0 representing the local cluster, Cluster is filled with frame identifier 1, and Node is filled with slot identifier 3, resulting in the node identifier "0:1:3". Finally, based on the type of the service line card, the system determines its corresponding TIPC service Type field y (e.g., 0x02) from a predefined mapping table. The Cluster and Node information in the node identifier are then calculated, for example, Instance = Cluster × 100 + Node, and converted into the Instance field z (e.g., 103). This constitutes the complete TIPC service address of the card {type=0x02, instance=103}, thus completing the mapping process from physical hardware location to standardized cluster logical communication address, laying the foundation for subsequent transparent communication based on the TIPC protocol.

[0050] In the specific implementation process, step S22 may also include steps S221 to S222: Step S221: If the type of the single board is a service line board, determine the first type field mapped by the service line board and the instance field mapped by the node identifier, and form the transparent inter-process communication service address of the service line board in the cluster according to the first type field and the instance field. It should be noted that the first type field is a fixed code assigned to the service line card in the TIPC service address to identify its service type. This field maps different types of service line cards, such as electrical layer signal processing boards and optical layer signal processing boards, to different logical service categories, thereby enabling clear differentiation and processing of messages from various service boards in trunking communication.

[0051] Step S222: If the type of the single board is a main control board, determine the second type field mapped by the main control board and the instance field range mapped by the node identifier, and form the transparent inter-process communication service address of the main control board in the cluster according to the second type field and the instance field range, wherein the instance field range includes a combination of instance fields corresponding to each service line card that communicates with the main control board.

[0052] It should be noted that the second type field refers to the fixed code assigned to the main control board in the TIPC service address, which identifies its management service type. Unlike the type field of the service line card, this field is specifically used to indicate that this service address corresponds to the management control node in the cluster, so that all other boards in the cluster can recognize and address the management service.

[0053] The instance field range is a range of instance values ​​used by the main control board in its TIPC service address. This range covers the set of instance fields corresponding to all service line cards in the cluster that need to communicate with this main control board. This range is not a single value, but is defined by a lower limit and an upper limit, indicating that the main control board needs to listen to and process messages from all possible service line cards in the cluster, thereby achieving one-to-many centralized communication management.

[0054] It is understandable that, since there are two types of communication roles in the OTN device cluster: the main control board and various service line cards, their communication modes are fundamentally different. If the same address mapping rules are used, the management node will not be able to efficiently identify and cover all managed nodes, thus causing problems of low addressing efficiency and high management complexity.

[0055] To address this, this implementation further differentiates the TIPC service address configuration for boards with different roles. Specifically, each business line board is assigned a first-type field representing its specific service type and a unique corresponding instance field, while the main control board responsible for centralized management is assigned a second-type field representing the management service and a range of instance fields covering all managed business line board instances. This solution effectively avoids the resource consumption problem of establishing numerous point-to-point logical connections or performing complex dynamic discovery between management nodes and managed nodes in the cluster. It enables the main control board to listen for and process communication requests from all business line boards using a single bound service address range, thereby significantly improving the efficiency, scalability, and overall reliability of cluster communication management.

[0056] For example, when a service line card in the cluster is powered on, the system generates a node identifier "0:1:3" based on its frame identifier 1 and slot identifier 3, and maps it to a TIPC service address. The first type field is predefined as 0x02 representing the service line card service, and the instance field is calculated by multiplying the frame identifier by 100 and adding the slot identifier to obtain 103, forming the address {0x02, 103}. For the main control board in the cluster, in the TIPC service address generated by the system, the second type field is predefined as 0x01 representing the main control service, and its instance field range is set to a lower limit of 101 and an upper limit of 312 based on all possible service line card instance values ​​in the cluster plan (e.g., from 101 in slot 1 of frame 1 to 312 in slot 12 of frame 3), thus forming the address {0x01, 101-312}. This allows the main control board to listen to and process the communication requests of all service line cards in the entire cluster by binding to this address range.

[0057] In one possible implementation, step S20 may be followed by step S01: Step S01: Register the single board according to the power-on sequence of the single board in the cluster, or through the single board maintenance service registry; Specifically, when the type of the single board is a service line card, the service line card is registered; when the type of the single board is a main control board, the service registry of the service line card is maintained by the main control board, and the service registry is used to record the registration status of the service line card.

[0058] It should be noted that the power-on sequence refers to the order in which different types of boards complete initialization and enter a communicable state during the system power-on startup process within an OTN device cluster. This sequence is dynamic and uncertain, mainly involving the order in which the main control board, acting as the management node, and the service line cards, acting as service function nodes, become ready. Different timing scenarios directly trigger subsequent differentiated service discovery and registration processes.

[0059] The service registry is a centralized, dynamic data structure created and maintained by the main control board in memory or storage media within the cluster. It records key information about all service line cards within the cluster. Essentially a database or list, each entry corresponds to a successfully registered service line card, typically containing the card's TIPC service address, unique hardware identifier, service type, and physical description. It forms the basis for the main control board to achieve unified discovery, monitoring, and management of resources across the entire cluster.

[0060] Registration status refers to the registration information of a service line card in the cluster service registry. It is a status indicator that shows whether the card has been officially recognized and managed by the cluster management system. The registration status includes at least two basic states: "registered" and "unregistered," which can be further refined into "online," "heartbeat lost," or "offline," reflecting the current validity of the management channel between the service line card and the main control board, as well as the manageability of the card in the cluster.

[0061] It is understandable that determining only the logical address cannot ensure that the cluster management system can reliably detect and include all service line cards that may be physically powered on and added at any time. Especially when there are a large number of single boards and the power-on sequence is unpredictable, there is a problem that the management node cannot detect new nodes in time or misjudge the node status.

[0062] To address this, this implementation dynamically triggers the registration process based on the actual power-on sequence, and the main control board centrally maintains a service registry that records the registration status of all service line cards. This clarifies two adaptive registration mechanisms: when the main control board is ready first, the service line cards proactively report for registration; and when the service line cards are ready first, the main control board proactively initiates a query. This effectively avoids problems such as missed device discovery, chaotic status management, and communication interruptions caused by the randomness of the power-on sequence. It enables the cluster system to reliably discover, track the status in real time, and manage all internal single-board resources in a unified manner, thereby further ensuring the dynamic reliability of cluster management while achieving communication decoupling.

[0063] For example, when the cluster starts, if the main control board completes power-on and TIPC service address initialization first, it will create an empty service registry in its local memory. Subsequently, each service line card will power on successively, acquiring its own frame identifier and slot identifier, and mapping them to generate its own TIPC service address. Each service line card that has completed initialization will immediately send a registration request message to the main control board's known service address via the TIPC network. This message contains its own TIPC service address, hardware identifier, and card type information. Upon receiving these registration messages, the main control board will add the corresponding service line card's key information, such as TIPC address, frame ID, slot ID, and type, as a new record to the service registry and mark its registration status as "registered". Afterward, the main control board periodically receives heartbeat messages from these service line cards, dynamically updating the registration status of each card in the service registry to "online" or "heartbeat lost," thereby achieving automatic discovery and centralized status management of cluster resources.

[0064] In the specific implementation process, step S01 may also include steps S011 to S012: Step S011: In the power-on sequence of the main control board and the service line card in the cluster, if the main control board powers on earlier than the service line card, the service line card sends a registration message to the main control board to register the service line card. The registration message includes the service type of the service line card and the physical information of the service line card. It should be noted that the service type is a classification and identification of various service line cards in the cluster according to their core functions and signal processing layers. It is used to logically distinguish boards with different functions, such as identifying whether a board is an OTU board that processes electrical layer signals, or an AAWG board or OA board that processes optical layer signals. This information is key metadata for service registration and management, enabling the main control board to understand and manage hardware resources with different functions.

[0065] Physical information refers to descriptive data carried by the service line card in the registration message, describing the specific characteristics of its hardware entity. This may include, but is not limited to, the explicit hardware identifier of the card, such as the frame identifier and slot identifier, and may also include auxiliary information such as the card silkscreen name, hardware version number, and serial number to accurately describe the physical entity, ensuring that the main control board can accurately map the logical service address to the specific physical hardware instance.

[0066] Step S012: In the cluster, if the power-on sequence of the main control board and the service line card is such that the service line card powers on earlier than the main control board, the main control board sends a registration request to the service line card to request the service line card to respond with the registration message.

[0067] It should be noted that the registration request is a query command message actively broadcast by the main control board to the cluster network or sent to a specific address when the main control board powers on after the service line cards. The purpose of this message is to proactively discover service line cards that are already online but not yet managed. Its function is equivalent to an inquiry, triggering the online service line cards to send their registration messages to the main control board, thereby completing the registration process.

[0068] It is understandable that, since the power-on sequence of each board in the cluster is completely random and unpredictable in actual deployment, if only a fixed registration triggering method is preset, such as only allowing business line boards to actively register, then in the scenario where the main control board is delayed in powering on, all business line boards that come online first will be in an unmanaged, isolated state for a long time because they cannot perceive the existence of the management node.

[0069] Therefore, this implementation adopts a bidirectional trigger registration technology based on dynamic adaptation of the actual power-on sequence, further clarifying two scenarios: when the main control board is ready first, the service line cards powered on later actively send a registration message containing their own service type and physical information to complete the registration; when the service line cards are ready first, the main control board powered on later actively sends a registration request to the network, thereby triggering all online service line cards to send their respective registration messages back to it. This solution effectively avoids the problems of device registration omissions, incomplete cluster resource discovery, or management state initialization delays that may be caused by the randomness of the power-on sequence. It enables the cluster management system to quickly, reliably, and completely discover and manage all single-board resources under any power-on sequence, thereby greatly enhancing the robustness, adaptability, and management efficiency of the cluster system deployment and startup phases.

[0070] For example, suppose that when an OTN device cluster starts up, multiple service line cards power on and initialize before the main control board. Although these service line cards have obtained their respective TIPC service addresses, they are in a pending registration state because the management node is not present. Subsequently, the main control board powers on and completes initialization. Sensing its own startup delay, it proactively sends a registration request message through the TIPC network to a predefined broadcast service address or a range of possible service line card service addresses. Upon receiving the registration request, all online service line cards immediately respond and assemble their respective registration messages, which include a clear service type such as "OTU board" or "OA board," as well as physical information including frame identifier, slot identifier, and board silkscreen name. These registration messages are then sent back to the main control board via the TIPC protocol. After receiving all responses, the main control board enters the detailed information of each service line card into its maintained service registry and updates its registration status to "registered" and "online," thereby ensuring that even in scenarios where the management node's startup is delayed, the cluster can still complete the automatic discovery and management of all resources completely and reliably.

[0071] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 Step S30 may also include steps A31 to A33: Step A31: If the type of the single board is a main control board, in response to the configuration management request, the main control board calls the preset configuration management interface to generate a configuration management request message corresponding to the configuration management request. It should be noted that a configuration management request refers to an instruction initiated by an external network management system or operator, aimed at setting parameters, querying status, or controlling functions of a specific card or service line card in an OTN device cluster. This request specifies the type of management operation to be performed (e.g., setting a port rate or querying current optical power) and the target object of the operation, serving as the initial driving force triggering the internal management communication process within the cluster.

[0072] The configuration management interface is a standardized, programmable function call interface provided by the service layer (such as the inter-board framework) to upper-layer applications in the main control board software of the OTN device cluster. Examples include `ser_bc_set_msg` or `ser_bc_get_msg`. This interface encapsulates the complex underlying communication and packet assembly details. Upper-layer applications can initiate a configuration management operation by calling this interface and passing in the target board identifier and configuration parameters, thus decoupling business logic from communication implementation.

[0073] The configuration management request message is a structured data message generated by the main control board through the configuration management interface and ultimately sent out through the TIPC network when responding to a configuration management request. This message follows a specific communication protocol format and typically includes a message header (containing the target frame identifier, target slot identifier, and sequence number) to identify the message sequence and destination, and a message body to carry specific operation instructions and parameters (using a multi-level TLV (Type-Length-Value) structure to encapsulate the specific message ID and input parameters).

[0074] Step A32: The main control board maps the first target frame identifier and the first target slot identifier carried in the configuration management request message to the first target transparent inter-process communication service address, and packages the configuration management request message based on the first target transparent inter-process communication service address; It should be noted that the first target frame identifier is a data field carried in the configuration management request message. Its value explicitly specifies the frame identifier of the physical OTN device frame to which the target service line card located within the cluster belongs, to which the configuration management operation is intended to be delivered. This identifier is the primary addressing information used to determine the physical location of the target device within the cluster.

[0075] The first target slot identifier is another data field carried in the configuration management request message. Its value, combined with the first target frame identifier, accurately locates a physical slot in a specific OTN device frame within the cluster, thereby uniquely identifying the specific target service line card for this configuration management operation.

[0076] The first target transparent inter-process communication service address refers to a TIPC logical address calculated or queried by the main control board when processing configuration management requests, based on the first target frame identifier and the first target slot identifier carried in the message, using predefined mapping rules, such as Instance = frame identifier × 100 + slot identifier. This address is the basis for message routing and delivery in the actual TIPC protocol network.

[0077] Step A33: The packaged configuration management request message is transmitted through the main control board to the first target service line card corresponding to the first target transparent inter-process communication service address.

[0078] It should be noted that the first target service line card is the specific service board to which the configuration management request message ultimately needs to be delivered and to execute the operation instructions carried in the message. It is uniquely identified by the first target frame identifier and the first target slot identifier, and can be any electrical layer or optical layer signal processing line card within any device frame in the cluster.

[0079] Understandably, in actual device management, specific configuration instructions from the network management system need to be accurately and efficiently converted into standardized communication events within the cluster and reliably delivered to the designated target board. However, general communication solutions lack clear definitions and optimizations for this application process, resulting in problems such as unclear operation triggers, low addressing mapping efficiency, and non-standard message structures.

[0080] Therefore, this embodiment adopts a standardized configuration management request processing flow technical solution. This solution clarifies the complete link from external request triggering, internal interface calling, real-time mapping of target hardware identifier to TIPC service address, and finally to the assembly and sending of structured request messages. This effectively avoids the process redundancy and implementation complexity caused by direct interaction between upper-layer management applications and lower-layer communication protocols. It realizes clear, efficient and reliable conversion of external management commands to cluster internal communication events. Thus, on the basis of communication decoupling, it further improves the automation level, operation execution accuracy and overall system maintainability of cluster configuration management.

[0081] For example, when the network management system needs to configure the port rate of an OTU board with frame identifier 2 and slot identifier 5 in the cluster, this operation request is sent to the cluster main control board as a configuration management request. The configuration management application on the main control board then calls the configuration management interface ser_bc_set_msg provided by the BC (Board Communication) framework, passing in the first target frame identifier "2", the first target slot identifier "5", and the specific port rate parameter data. The BC framework calculates the first target TIPC service address based on these two identifiers, where the instance field is 2×100+5=205 and the type field is 0x02 corresponding to the service line card. Then, the protocol layer of the main control board assembles this address and parameter data into a complete configuration management request message according to the prescribed message format (including a SEQ Value header with the target frame ID and slot ID as parts, and first-level and second-level TLV structures carrying the specific message ID and parameters). Finally, the message is accurately routed and sent to the first target service line card, namely the OTU board in slot 5 of frame 2, via the TIPC protocol through the internal network VLAN (Virtual Local Area Network) of the hardware carrier layer.

[0082] In this process, after the main control board calls the configuration management interface and determines the target TIPC service address, its packet assembly process employs a two-level TLV structure design: First, after the SEQ Value header (containing the first target box identifier "2", the first target slot identifier "5", and the sequence number), a first-level TLV is constructed. Its TAG field is set to "set request" to indicate that this is a setup request message, and its Len field indicates the total length from the TAG until the end of the message. Next, a second-level TLV is constructed. Its APP msgID field is assigned a predefined, unique identifier code corresponding to the "port rate configuration" function, its Len field indicates the length of the message in the second-level TLV, and its Input param field is filled with specific rate value parameters. Through this structure, the TAG field of the first-level TLV macroscopically distinguishes the message as a configuration request type, while the msgID field of the second-level TLV precisely defines the specific business function of port rate configuration from a microscopic perspective. This achieves a unified communication message format and flexible expansion of business functions, enabling the underlying communication framework to efficiently and standardizedly carry and process diverse management commands.

[0083] In one feasible implementation, the optical transmission network device communication method may further include steps A34-A36: Step A34: Receive the configuration management request message after packet assembly through the first target service line card; Step A35: If the configuration management request is a configuration request, the first target service line card processes the packaged configuration management request message so that the first target service line card executes the configuration task corresponding to the configuration management request message. Step A36: Obtain the execution result of the configuration task through the first target service line card, and return the configuration response message corresponding to the execution result to the main control board.

[0084] It should be noted that the execution result refers to the status and related data generated by the upper-layer application of the first target service line card after successfully receiving and parsing the configuration management request message, and executing the configuration task (such as parameter setting) carried by the message. This result includes a core return code indicating whether the operation was successful or not.

[0085] The configuration response message is a structured response message assembled and sent by the first target service line card after completing the configuration task to report the execution result to the main control board. This message follows the protocol format corresponding to the request message. Its message header matches the original request to associate context, and the message body explicitly carries the return code field and optional output parameters through a two-level TLV structure. It is the only formal communication carrier for the main control board to confirm whether the configuration operation has taken effect and to obtain the expected data.

[0086] Understandably, simply issuing configuration requests does not constitute a complete and reliable configuration management loop. The main control board cannot confirm whether the parameters have been written or applied correctly, resulting in unknowable setting operation status and failures that cannot be detected in a timely manner, thus affecting the consistency and reliability of system configuration.

[0087] Therefore, this implementation further incorporates a closed-loop feedback technology on the target service line card side, involving the reception, execution, result generation, and proactive response of configuration management request messages. Specifically, after receiving and executing the configuration request, the target service line card must assemble the execution result, containing a return code clearly indicating success or failure, into a formatted configuration response message and return it to the main control board according to the TIPC protocol path. This solution effectively avoids the technical risks of unknown setting operation results and the inability to promptly alarm and correct configuration errors due to one-way communication. It achieves full-process traceability and result confirmation for every parameter setting operation, thereby further ensuring the ultimate reliability, status visibility, and closed-loop self-control capability of the cluster configuration management operation while achieving efficient command issuance.

[0088] For example, when the first target service line card, such as the OTU board in slot 5 of frame 2, receives a configuration management request message from the main control board via the TIPC protocol, its onboard software first parses the message, extracts specific setting parameters such as port rate values, and performs corresponding hardware configuration operations. After the operation is completed, an execution result is generated, which mainly includes a return code indicating whether the operation was successful or a specific failure reason. Subsequently, the service line card assembles a configuration response message according to a predefined message format. This message reuses the SEQ Value header from the original request message to maintain sequence correspondence and fills the return code field in the secondary TLV structure. Finally, based on the correspondence between its own TIPC service address and the main control board address, the service line card sends the configuration response message back to the main control board via the internal network VLAN, thereby completing the closed-loop feedback of this parameter configuration operation.

[0089] When the first target service line card completes the port rate setting operation and assembles the configuration response message, its secondary TLV structure first includes a "Return code msgID" field, whose value strictly corresponds to the "APP msgID" in the original request message's secondary TLV, thus precisely associating the response with the specific setting request. The following "Len" field indicates the length from this field until the end of this secondary TLV. Subsequently, the "Return code" field carries the specific return code indicating whether the operation was successful or failed. Since this response is only for configuration operations, the secondary TLV may not include the "APP msgID," "Len," and "Output param" fields (corresponding to the configuration data or status parameter values ​​returned by the requesting service line card) for subsequent query-type responses, thus forming a concise yet complete setting operation response structure, ensuring that the main control board can accurately and efficiently parse and confirm the final execution result of this parameter setting.

[0090] Based on the first and / or second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 Step S30 may also include steps B31 to B33: Step B31: When the type of the single board is a service line card, in response to the service alarm request, the preset service alarm interface is called through the second target service line card in the cluster to generate the service alarm information corresponding to the service alarm request. The message header of the service alarm information includes the second target frame identifier and the second target slot identifier of the main control board corresponding to the second target service line card. It should be noted that a service alarm request is an internal trigger signal generated by a service line card in the OTN device cluster when it autonomously detects an internal hardware failure, performance limit violation, or abnormal status event during operation. This signal requires the card to immediately report the event to the management node. This request marks the beginning of the service line card's proactive alarm reporting process and signifies the start of an abnormal event notification.

[0091] The second target business line board is the specific business board that serves as the source of alarm events and the sender of alarm information. It is the physical entity in the cluster that actually detects an anomaly and needs to perform alarm reporting actions.

[0092] The business alarm interface is a standardized function call interface provided by the BC framework layer in the business line card software, specifically for initiating alarm reporting. This interface encapsulates the packet assembly and sending details of alarm information. When the upper-layer application of the business line card detects an anomaly, it can easily trigger the alarm reporting process by calling this interface.

[0093] Business alarm information consists of structured alarm data messages generated by the business line card through the business alarm interface. This information follows a specific protocol format. Its message header contains information such as the identifier of the alarm source, while the message body describes in detail the alarm type, level, occurrence time, and specific content. It serves as the carrier for transmitting details of abnormal events to the main control board.

[0094] Step B32: Map the second target frame identifier and the second target slot identifier to the second transparent inter-process communication service address through the second target service line card. It should be noted that the second target frame identifier is the target management node to which the service alarm information needs to be delivered, that is, the frame identifier of the device frame where the main control board is located. It is the frame ID used by the service line card to address the physical location of the main control board when assembling alarm information.

[0095] The second target slot identifier is the target management node to which the service alarm information needs to be sent, that is, the slot identifier in the device frame where the main control board is located. Together with the second target frame identifier, it uniquely determines the specific physical location of the main control board that receives the alarm information.

[0096] The second transparent inter-process communication service address is the TIPC logical address of the main control board, obtained by the service line card according to the known second target frame identifier and second target slot identifier through mapping rules when preparing to send service alarm information. This address is the basis for the alarm information to be ultimately routed to the correct main control board in the TIPC network.

[0097] Step B33: The second target service line card sends the service alarm information to the main control board based on the second transparent inter-process communication service address.

[0098] Understandably, during the operation of an OTN device cluster, faults or performance alarms generated by service line cards need to be transmitted to the management node in real time and reliably. However, general communication solutions only support one-way requests and lack specific optimizations for the uplink notification process for such critical events, resulting in problems such as unclear event reporting paths, low addressing efficiency, and insufficient real-time guarantees.

[0099] To address this, this embodiment employs a standardized alarm reporting technology solution proactively triggered by the service line card. This solution clarifies the complete process from detecting an abnormal event within the service line card, calling a dedicated alarm interface, generating structured alarm information, mapping the physical location identifier of the target main control board to its TIPC service address, and directly sending the alarm based on this address. This effectively avoids the risks of processing delays, priority confusion, or reporting failures that may arise from relying on general communication paths for alarm events. It achieves rapid, reliable, and accurate reporting of abnormal events, thereby further enhancing the cluster system's real-time monitoring capabilities for abnormal operating states, fault response speed, and overall operation and maintenance efficiency, based on communication decoupling.

[0100] For example, when a second target service line card in the cluster, such as an OTU board with frame ID 3 and slot ID 8, detects an abnormal event where its optical module receives optical power exceeding the limit, its onboard application software calls the service alarm interface provided by the BC framework to generate a structured service alarm message. During assembly, the message header of this message explicitly includes a preset second target frame identifier (e.g., 1, representing the device frame where the main control board is located) and a second target slot identifier (e.g., 1, representing the slot where the main control board is located). Subsequently, the BC framework uses a formula to map the frame ID and slot ID of the main control board to a second TIPC service address based on these two identifiers, for example, mapping them to the TIPC address {type=0x01, instance=101}. Finally, based on this TIPC service address, the service alarm message is directly sent to the main control board located in slot 1 of frame 1 via the internal VLAN of the switching chip within the device frame, driven by the TIPC protocol, thus completing a fast and targeted reporting process from service anomaly detection to management node alarm reception.

[0101] For example, to help understand the implementation flow of the optical transmission network device communication method obtained by combining Embodiment 1 and Embodiment 2 above, please refer to... Figure 5 , Figure 5 A simplified flowchart of a communication method for an optical transmission network device is provided, specifically: The process begins with system startup. After each board powers on, it first performs initialization and address mapping, which involves reading the unique hardware identifier, i.e., the frame identifier and slot identifier, to generate a structured node identifier, which is ultimately mapped to a logical TIPC service address. This is followed by the service discovery and registration phase, where the system dynamically triggers a two-way registration mechanism based on the actual power-on sequence. The main control board then maintains the service registry. In the core operation and communication phase, the process branches into three main business scenarios: configuration management (involving the closed loop of configuration management request and response messages), alarm reporting (involving the generation and sending of business alarm information), and cross-site communication (involving implementation via optical monitoring channels). Finally, the process covers fault tolerance and recovery mechanisms to ensure system reliability, including heartbeat-based status monitoring (related to service registry status updates), main control board 1+1 hot standby path switching, and message ID-based data retransmission. These mechanisms collectively ensure high availability of cluster communication, ultimately forming a decoupled, highly reliable, and scalable OTN device cluster communication system.

[0102] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the communication method of the optical transmission network device of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0103] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the optical transmission network device communication method of the above embodiment 1.

[0104] The following is for reference. Figure 6 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0105] like Figure 6As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although the diagrams show electronic devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0106] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0107] The electronic device provided in this application, employing the optical transmission network device communication method described in the above embodiments, can solve the technical problem of high coupling in the current OTN device communication architecture, resulting in poor maintainability. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the optical transmission network device communication method provided in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0108] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0109] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0110] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A communication method for an optical transmission network device, characterized in that, The communication method of the optical transmission network device includes: Obtain the unique identifier of a single board in an optical transmission network device. The unique identifier includes the frame identifier of the device frame in which the single board is located and the slot identifier of the slot in which the single board is located. Based on the frame identifier and the slot identifier, the transparent inter-process communication service address of the single board in the cluster is determined, wherein the cluster is composed of multiple single boards; Based on the transparent inter-process communication service address, communication between the single board and other single boards is carried out within the cluster.

2. The communication method for optical transmission network equipment as described in claim 1, characterized in that, The step of determining the transparent inter-process communication service address of the single board within the cluster based on the frame identifier and the slot identifier includes: Based on the frame identifier and the slot identifier, generate the node identifier corresponding to the single board; Based on the type of the single board, the node identifier is mapped to the transparent inter-process communication service address of the single board within the cluster.

3. The communication method for optical transmission network equipment as described in claim 2, characterized in that, The step of mapping the node identifier to the transparent inter-process communication service address of the board within the cluster according to the type of the board includes: When the type of the single board is a service line board, determine the first type field mapped by the service line board and the instance field mapped by the node identifier, and form the transparent inter-process communication service address of the service line board in the cluster based on the first type field and the instance field. When the type of the single board is a main control board, the second type field mapped by the main control board and the instance field range mapped by the node identifier are determined, and the transparent inter-process communication service address of the main control board in the cluster is formed according to the second type field and the instance field range. The instance field range includes a combination of instance fields corresponding to each service line card that communicates with the main control board.

4. The communication method for optical transmission network equipment as described in claim 1, characterized in that, After the step of determining the transparent inter-process communication service address of the single board in the cluster based on the frame identifier and the slot identifier, the method further includes: Register the single board according to the power-on sequence of the single board in the cluster, or through the single board maintenance service registry; Specifically, when the type of the single board is a service line card, the service line card is registered; when the type of the single board is a main control board, the service registry of the service line card is maintained by the main control board, and the service registry is used to record the registration status of the service line card.

5. The communication method for optical transmission network equipment as described in claim 4, characterized in that, The step of registering the single board according to its power-on sequence within the cluster, or maintaining the single board's service registry, includes: In the cluster, the power-on sequence of the main control board and the service line card is as follows: if the main control board powers on before the service line card, the service line card sends a registration message to the main control board to register the service line card. The registration message includes the service type of the service line card and the physical information of the service line card. Within the cluster, the power-on sequence of the main control board and the service line cards is as follows: if the service line cards are powered on before the main control board, the main control board sends a registration request to the service line cards to request the service line cards to respond with the registration message.

6. The communication method for optical transmission network equipment as described in claim 1, characterized in that, The step of enabling communication between the single board and other single boards within the cluster based on the transparent inter-process communication service address includes: When the type of the single board is a main control board, in response to the configuration management request, the main control board calls the preset configuration management interface to generate the configuration management request message corresponding to the configuration management request; The main control board maps the first target frame identifier and the first target slot identifier carried in the configuration management request message to the first target transparent inter-process communication service address, and packages the configuration management request message based on the first target transparent inter-process communication service address. The main control board transmits the packaged configuration management request message to the first target service line card corresponding to the first target transparent inter-process communication service address.

7. The communication method for optical transmission network equipment as described in claim 6, characterized in that, The communication method for the optical transmission network device further includes: The configuration management request message after the package is received through the first target service line card; When the configuration management request is a configuration request, the packaged configuration management request message is processed by the first target service line card so that the first target service line card executes the configuration task corresponding to the configuration request message; The execution result of the configuration task is obtained through the first target service line card, and the configuration response message corresponding to the execution result is returned to the main control board.

8. The communication method for optical transmission network equipment as described in claim 1, characterized in that, The step of enabling communication between the single board and other single boards within the cluster based on the transparent inter-process communication service address includes: When the type of the single board is a service line card, in response to a service alarm request, a preset service alarm interface is called through the second target service line card in the cluster to generate service alarm information corresponding to the service alarm request. The message header of the service alarm information includes the second target frame identifier and the second target slot identifier of the main control board corresponding to the second target service line card. The second target frame identifier and the second target slot identifier are mapped to the second transparent inter-process communication service address through the second target service line card. The second target service line card sends the service alarm information to the main control board based on the second transparent inter-process communication service address.

9. The communication method for optical transmission network equipment as described in claim 1, characterized in that, The cluster also includes multiple sites, each site including at least one optical transmission network device, and each board including a service line card. The service line card includes optical amplifier boards and optical line amplifier boards. The sites are connected to each other through the optical monitoring channels of the optical amplifier boards and / or the optical line amplifier boards.

10. An electronic device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the optical transmission network device communication method as described in any one of claims 1 to 9.

Images