OTN overhead and alarm processing method and system based on cache sharing

Abstract

The application belongs to the field of optical communication, and proposes an OTN overhead and alarm processing method and system based on cache sharing. The system is equipped with a shared cache pool and a centralized processing unit. The cache pool uniformly receives multiple ODU overhead data streams, and the centralized processing unit is responsible for overhead analysis, performance monitoring and alarm determination. The method first collects computing power scheduling instructions, network configuration signaling, original overhead bytes and hardware alarm events; according to the instructions and signaling, task weights are set, network resources are bound, and a dynamic network state atlas containing multiple types of nodes and associated relationships is built and updated. The integrated service weight, health risk and risk transmission coefficient are calculated to obtain the fusion key weight, and then the scheduling priority is generated. The system combines the priority and bandwidth quota to dynamically allocate cache space and computing resources, and the centralized unit generates deep alarms and processes them according to the priority. In each processing period, performance index feedback is collected to adjust the weight parameters, finally reducing resource consumption and improving resource utilization.

Description

Technical Field

[0001] This application relates to the technical field of optical communication, and in particular to an OTN overhead and alarm processing method and system based on cache sharing. Background Technology

[0002] Optical Transport Network (OTN) is the core transmission architecture of current optical communication networks. With its advantages of large capacity, low latency and high reliability, it is widely used in various communication transmission scenarios such as backbone networks and metropolitan area networks, carrying massive amounts of core services such as government and enterprise private lines, mobile communication and data interaction.

[0003] The OTN system comprises a multi-level ODU and OPU overhead architecture. Each type of overhead possesses independent frame location, performance monitoring, fault diagnosis, and link control functions. Each ODU unit must complete overhead parsing, performance statistics, and alarm processing, which is a crucial foundation for ensuring stable operation of optical transmission links and achieving accurate fault location. With the continuous growth of communication network service load and the increasingly complex transmission path multiplexing architecture, networks exhibit multi-level nesting and multi-port concurrent transmission characteristics. The demand for processing multi-level, multi-path parallel overhead data streams has significantly increased, placing higher demands on the resource utilization, overhead processing efficiency, and fault alarm response accuracy of the OTN system.

[0004] Currently, the mainstream OTN overhead and alarm handling in the industry adopts a conventional technical solution of layered independent processing. In the OTN multiplexing path, the overhead of each level of ODUk and OPUk is generated, parsed, and alarm determined independently. For overhead data streams of different network levels and different physical ports, dedicated processing units and storage resources are configured separately. The processing resources of each level are independent and not interchangeable. In complex multiplexing path scenarios, the resource redundancy problem of this solution is extremely prominent. For example, one ODU2 can support four ODU1s and eight ODU0s. Layered independent processing requires a large number of dedicated processing units. The more complex the multiplexing path, the more overhead processing units are required, resulting in extremely high consumption of system hardware resources and extremely low resource utilization. Summary of the Invention

[0005] To reduce resource consumption and improve resource utilization, this application provides a method and system for handling OTN overhead and alarms based on cache sharing.

[0006] Firstly, this application provides a method for handling OTN overhead and alarms based on cache sharing, employing the following technical solution:

[0007] An OTN overhead and alarm processing method based on cache sharing is applied to an OTN system comprising a shared cache pool and a centralized processing unit. The shared cache pool is used to uniformly receive and cache multi-channel optical data unit (ODU) overhead data streams from different network layers and different physical ports. The centralized processing unit, as the core processing engine, is configured to perform overhead parsing, performance monitoring, and alarm judgment. The processing method includes:

[0008] Real-time acquisition of computing task scheduling instructions and network configuration signaling from upper-layer applications, as well as raw overhead bytes and raw alarm event streams from lower-layer networks;

[0009] According to the computing power task scheduling instructions, the corresponding computing power task entities are assigned business intent weights, and the bearing binding relationship between computing power task entities and network resource entities is established according to network configuration signaling. Combining the original overhead bytes and the original alarm event stream of the underlying hardware, a dynamic network status graph is constructed and updated in real time. The nodes in the dynamic network status graph include computing power task entities, logical path entities, network resource entities and status event entities. The nodes are connected by bearing, composition, influence and association relationship edges.

[0010] Based on the dynamic network state graph, a fusion criticality weight is calculated for each active OTN network entity. The fusion criticality weight integrates the service intent weight of the corresponding OTN network entity's carried services, the real-time health risk score of the corresponding OTN network entity obtained based on the graph propagation model, and the risk propagation coefficient that represents the corresponding OTN network entity's position in the fault propagation chain.

[0011] The fusion criticality weights of each active OTN network entity are directly mapped or differentiated and amplified to generate the scheduling priority weights of each OTN network entity.

[0012] Based on scheduling priority weights and bandwidth quotas in network configuration signaling, the shared cache pool is dynamically controlled to allocate logical storage space for the overhead data streams corresponding to each OTN network entity, and the centralized processing unit is scheduled to allocate computing resources for the overhead processing tasks of each OTN network entity. When performing overhead parsing and performance monitoring, the centralized processing unit simultaneously performs alarm analysis and deep alarm generation according to the preset alarm rule base. The generated deep alarm information is cached and processed in subsequent steps according to scheduling priority weights.

[0013] After a processing cycle is completed, key performance indicators are collected, and the processing effect is fed back to the construction and fusion of the dynamic network state graph and the calculation of key weights, so as to adaptively adjust the weight calculation parameters.

[0014] By adopting the above technical solutions and constructing a core architecture that integrates a shared cache pool and centralized processing units, the resource barriers of independent processing overhead and alarms at each level and port in traditional OTN systems are fundamentally broken down, achieving global scheduling and efficient reuse of computing and storage resources. Using a dynamic network state graph as the core hub, the system deeply integrates upper-layer computing power scheduling requirements with lower-layer real-time network status. Through precise calculation of criticality weights, resource allocation is no longer limited to static configuration but closely aligns with business priorities, network health status, and fault propagation risks. This ensures that high-value services and high-risk nodes receive priority processing, guaranteeing the low latency and high reliability requirements of core services while avoiding the ineffective occupation of resources by non-critical tasks. Simultaneously, a closed-loop processing effect feedback mechanism enables the entire system to have adaptive learning capabilities, continuously optimizing weight calculation logic as network operating status changes, and constantly improving the accuracy of resource scheduling and the foresight of alarm handling. This globally collaborative and dynamically adaptable processing mode not only improves the overall processing efficiency and resource utilization of the OTN system but also enhances the system's ability to perceive complex network environments and respond to faults.

[0015] Optionally, the internal logical management process for the shared cache pool to uniformly receive and cache multiple ODU overhead data streams includes:

[0016] Within the shared cache pool, for each received ODU overhead data stream, logical storage blocks are dynamically allocated for the corresponding overhead data based on the ODU level to which the corresponding overhead data belongs and the multiframe position information of the corresponding overhead data.

[0017] The hierarchical priority manager manages the reading order of data in different logical storage blocks based on ODU hierarchical information, in order to coordinate with the scheduling of the centralized processing unit.

[0018] By adopting the above technical solution, and dynamically allocating logical storage blocks based on ODU hierarchy and multiframe location information, each overhead data path can obtain dedicated and suitable storage space. This avoids mutual interference between data at different levels and optimizes the storage layout according to multiframe characteristics. The introduction of a hierarchy priority manager further improves the efficiency of cache resource utilization. It regulates the data reading order based on ODU hierarchy information, allowing the centralized processing unit to prioritize high-priority overhead data. This matches the scheduling logic of the centralized processing unit, resulting in a seamless connection between storage and computation in the entire OTN system's overhead processing flow.

[0019] Optionally, the step of dynamically allocating logical storage blocks for the corresponding overhead data based on the ODU level to which the overhead data belongs and the multiframe location information of the corresponding overhead data specifically includes:

[0020] Parse the raw overhead bytes in the ODU overhead data stream to identify the multiframe positioning signals and hierarchical identification information contained therein;

[0021] The corresponding overhead data is determined by the hierarchical identification information, and the position of the corresponding overhead data within the multiframe is determined by the multiframe positioning signal.

[0022] Based on the ODU level and multiframe location, a corresponding logical storage block is dynamically allocated or located in the shared cache pool for the corresponding overhead data, which is used to sequentially store the overhead data.

[0023] Optionally, the steps of dynamically controlling the shared cache pool to allocate logical storage space for the overhead data streams corresponding to each OTN network entity specifically include:

[0024] The scheduling priority weight of each active OTN network entity is associated with the bandwidth quota in the network configuration signaling and the total logical capacity of the shared buffer pool to calculate the guaranteed buffer quota allocated to the overhead data stream corresponding to the OTN network entity.

[0025] Identify the top K active OTN network entities by scheduling priority weight, mark these OTN network entities as hot entity groups, and dynamically map and lock a contiguous storage area with low access latency as a hot storage area in the physical storage space of the shared cache pool for the overhead data corresponding to the hot entity groups.

[0026] The controller of the shared cache pool adjusts the capacity quota of each logical storage block and the entity binding relationship of hot storage areas in real time based on the scheduling priority weight of each OTN network entity updated in each processing cycle.

[0027] By adopting the above technical solution, and calculating cache quotas by associating scheduling priority weights with the total logical capacity of the shared cache pool, each active OTN network entity can obtain basic cache resources commensurate with its importance. This ensures the basic processing needs of low-priority services while avoiding unnecessary resource reservations, achieving fine-grained allocation of cache resources. Furthermore, the identification of hot entity groups and the locking of hot storage areas further focus on the performance requirements of core services, providing dedicated storage areas with low access latency for high-priority network entities. This reduces the latency of reading and processing high-value, high-risk entity overhead data, allowing the system to respond more quickly to changes in critical services. This not only maximizes the resource utilization of the shared cache pool but also enhances the OTN system's adaptability to complex business scenarios through differentiated resource protection strategies.

[0028] Optionally, the process of allocating computing resources for the overhead processing tasks of each OTN network entity by the scheduling centralized processing unit specifically includes:

[0029] Within the centralized processing unit, a corresponding software task queue is created for each active OTN network entity to cache the ODU overhead data to be processed;

[0030] Set the scheduling priority weight of each OTN network entity to the dynamic scheduling weight of the corresponding software task queue of the corresponding OTN network entity in the current scheduling period.

[0031] The task scheduler within the centralized processing unit allocates CPU time slices or processing threads to each software task queue based on the dynamic scheduling weights of each queue using a weighted scheduling algorithm.

[0032] By adopting the above technical solution and creating an independent software task queue for each active OTN network entity, the overhead processing tasks of different entities are isolated, avoiding mutual interference between tasks. Mapping scheduling priority weights directly to the dynamic scheduling weights of the task queues means that the allocation of computing resources no longer depends on static configuration but closely follows real-time changes in factors such as the business importance and health status of network entities. This allows high-priority network entities to receive more computing power support, ensuring that the overhead analysis, performance monitoring, and alarm judgment of core businesses can be processed in a timely manner, effectively reducing the processing latency of critical businesses.

[0033] Optionally, the steps for caching and subsequent processing of the generated deep alarm information based on scheduling priority weights specifically include:

[0034] When performing overhead analysis and performance monitoring, the centralized processing unit determines whether to trigger a deep analysis alarm event based on a preset alarm rule base.

[0035] For the triggered deep analysis alarm events, extract the OTN network entity identifier, alarm type and severity level associated with the corresponding alarm event, and encapsulate them into a deep alarm message;

[0036] Deep alarm messages are sent to the alarm cache area linked to the shared cache pool for priority sorting and caching based on the scheduling priority weight of the OTN network entity associated with them, or directly used as new status event inputs and fed back into the construction process of the dynamic network status graph.

[0037] Optionally, the steps for calculating the fusion criticality weight for each active OTN network entity based on the dynamic network state graph specifically include:

[0038] By traversing the bearing relationship edges in the dynamic network state graph, all computing power task entities carried by the target OTN network entity are determined.

[0039] Obtain the largest business intent weight among all computing power task entities, and use it as the business intent weight component of the target OTN network entity.

[0040] The real-time health risk score of the target OTN network entity is obtained from the dynamic network state graph and used as a health risk component.

[0041] By analyzing the influence relationship edges originating from the target OTN network entity in the dynamic network state graph, the number of computing power task entities downstream of the target OTN network entity that are affected and whose business intent weight exceeds a set threshold is counted, and the risk propagation coefficient component is obtained after normalization.

[0042] The business intent weight component, health risk component, and risk propagation coefficient component are multiplied by the dynamically adjustable business intent weight factor, health risk weight factor, and risk propagation amplification factor, respectively, and then summed to obtain the fusion criticality weight.

[0043] By adopting the above technical solutions and a multi-dimensional integrated evaluation system, the OTN system can perceive the network operation status from a global perspective and predict and mitigate potential risks in advance.

[0044] Optional steps in calculating the real-time health risk score include:

[0045] Extract raw performance monitoring parameters and historical alarm events directly associated with the target OTN network entity from the dynamic network state graph;

[0046] The original performance monitoring parameters are compared with the preset threshold range to calculate the current deviation.

[0047] Calculate the historical risk residual value by combining the frequency, severity level, and time decay factor of historical alarm events;

[0048] A real-time health risk score is obtained by combining the current deviation and the historical risk residual value through weighted calculation.

[0049] By adopting the above technical solutions and multi-dimensional, dynamic evaluation methods, not only is a precise and reliable health status basis provided for the calculation of criticality weights, but the OTN system can also perceive the health status of network entities more meticulously and accurately, effectively improving the reliability and stability of the entire OTN system.

[0050] Optionally, the steps to feed back the processing results to the construction and fusion of key weights in the dynamic network state graph, in order to adaptively adjust the weight calculation parameters, specifically include:

[0051] Monitor the overhead processing tasks corresponding to each active OTN network entity and obtain the end-to-end latency from when the ODU overhead data enters the shared buffer pool to when it is processed by the centralized processing unit.

[0052] Analyze the correlation between end-to-end latency and the scheduling priority weight of the corresponding OTN network entity, and evaluate whether end-to-end latency shows the expected decreasing trend as the scheduling priority weight increases;

[0053] If the evaluation results do not meet expectations, the business intent weight factor, health risk weight factor, or risk propagation amplification factor used in calculating the integration criticality weight will be adaptively adjusted based on the deviation analysis.

[0054] The adjusted weighting factors are applied to the fusion criticality weight calculation in the next processing cycle, forming a closed-loop optimization.

[0055] By adopting the above technical solutions, the closed-loop optimization mechanism not only improves the adaptive capability and processing efficiency of the OTN system, but also enables the entire system to continuously optimize its performance as network services develop and the operating environment changes.

[0056] Secondly, this application provides an OTN overhead and alarm processing system based on cache sharing, which adopts the following technical solution:

[0057] An OTN overhead and alarm processing system based on cache sharing includes:

[0058] A shared buffer pool is used to uniformly receive and cache multi-channel optical data unit (ODU) overhead data streams from different network layers and different physical ports;

[0059] The centralized processing unit, as the core processing engine, is configured to perform execution overhead analysis, performance monitoring, and alarm judgment.

[0060] The data acquisition module is used to collect computing task scheduling instructions and network configuration signaling from upper-layer applications in real time, as well as raw overhead bytes and raw alarm event streams from lower-layer networks.

[0061] The cognitive modeling module is used to assign business intent weights to the corresponding computing task entities according to the computing task scheduling instructions, and to establish the bearing binding relationship between computing task entities and network resource entities according to network configuration signaling. Combining the original overhead bytes and the original alarm event stream of the underlying hardware, it constructs and updates the dynamic network status graph in real time. The nodes in the dynamic network status graph include computing task entities, logical path entities, network resource entities and status event entities. The nodes are connected by bearing, composition, influence and association relationship edges.

[0062] The criticality calculation module is used to calculate the fused criticality weight for each active OTN network entity based on the dynamic network state graph. The fused criticality weight integrates the service intent weight of the corresponding OTN network entity's carried services, the real-time health risk score of the corresponding OTN network entity obtained based on the graph propagation model, and the risk propagation coefficient that represents the corresponding OTN network entity's position in the fault propagation chain.

[0063] The scheduling strategy generation module is used to directly map or differentiate the fusion criticality weights of each active OTN network entity to generate the scheduling priority weights of each OTN network entity.

[0064] The elastic scheduling controller is used to dynamically control the shared cache pool to allocate logical storage space for the overhead data streams corresponding to each OTN network entity based on scheduling priority weights and bandwidth quotas in network configuration signaling, and to schedule the centralized processing unit to allocate computing resources for the overhead processing tasks of each OTN network entity. The centralized processing unit is further configured to: simultaneously perform alarm analysis and deep alarm generation according to a preset alarm rule base when performing overhead parsing and performance monitoring; and cache and process the generated deep alarm information according to scheduling priority weights.

[0065] The feedback optimization module is used to collect key performance indicators after a processing cycle ends and feed the processing effect back to the construction and fusion of the dynamic network state graph and the calculation process of key weights, so as to adaptively adjust the weight calculation parameters.

[0066] In summary, this application includes at least one of the following beneficial technical effects:

[0067] 1. Relying on the collaborative architecture of shared cache pool and centralized processing unit, the resource barriers of independent processing in traditional OTN systems are broken. Storage and computing resources are dynamically scheduled based on business importance, network health status and fault propagation risk, so as to realize global resource reuse and fine allocation, effectively ensuring low latency and high reliability of core business operations.

[0068] 2. By leveraging dynamic network state graphs to achieve full network state awareness, and through end-to-end latency monitoring to form a closed-loop adaptive optimization mechanism, the weight calculation logic is continuously optimized, which not only improves alarm processing efficiency and fault prediction and handling capabilities, but also enhances the system's adaptability to complex network environments. Attached Figure Description

[0069] Figure 1 This is a first flowchart of an embodiment of the method of this application;

[0070] Figure 2 This is a second flowchart of an embodiment of the method of this application;

[0071] Figure 3This is a third flowchart of an embodiment of the method of this application;

[0072] Figure 4 This is the fourth flowchart of an embodiment of the method of this application;

[0073] Figure 5 This is the fifth flowchart of an embodiment of the method of this application;

[0074] Figure 6 This is the sixth flowchart of an embodiment of the method of this application;

[0075] Figure 7 This is the seventh flowchart of an embodiment of the method of this application. Detailed Implementation

[0076] To make the purpose, technical solution, and advantages of this application clearer, the following description is provided in conjunction with the appendix. Figures 1-7 The present application will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the application.

[0077] The first embodiment of this application discloses an OTN overhead and alarm processing method based on cache sharing, which is applied to an OTN system including a shared cache pool and a centralized processing unit. The shared cache pool is used to uniformly receive and cache multi-channel optical data unit (ODU) overhead data streams from different network layers and different physical ports. The centralized processing unit is configured as the core processing engine to perform overhead parsing, performance monitoring and alarm judgment.

[0078] The internal logical management process of the shared cache pool uniformly receiving and caching multiple ODU overhead data streams includes:

[0079] Within the shared cache pool, for each received ODU overhead data stream, logical storage blocks are dynamically allocated to the corresponding overhead data based on the ODU level to which the corresponding overhead data belongs and the multiframe position information of the corresponding overhead data. Through the hierarchy priority manager, the reading order of data in different logical storage blocks is managed according to the ODU hierarchy information to cooperate with the scheduling of the centralized processing unit.

[0080] Furthermore, the step of dynamically allocating logical storage blocks for the corresponding overhead data based on the ODU level to which the overhead data belongs and the multiframe location information of the corresponding overhead data specifically includes:

[0081] Parse the raw overhead bytes in the ODU overhead data stream to identify the multiframe positioning signals and hierarchical identification information contained therein;

[0082] The corresponding overhead data is determined by the hierarchical identification information, and the position of the corresponding overhead data within the multiframe is determined by the multiframe positioning signal.

[0083] Based on the ODU level and multiframe location, a corresponding logical storage block is dynamically allocated or located in the shared cache pool for the corresponding overhead data, which is used to sequentially store the overhead data.

[0084] Specifically, initially, the basic architecture and cache pool logic management are carried out. Specifically, a global shared cache pool is built using high-capacity DDR4 high-speed memory, and the memory addressing granularity is adapted to the frame length characteristics of various ODU overhead data streams. At the same time, a centralized processing unit is built based on a multi-core FPGA+ARM heterogeneous architecture. The FPGA hardware logic is responsible for high-speed overhead byte parsing and real-time performance parameter acquisition, while the ARM core is responsible for alarm judgment, weight calculation, and scheduling strategy optimization. It is configured as the core processing engine for global overhead parsing, performance monitoring, and alarm judgment.

[0085] The shared buffer pool receives multiple ODU overhead data streams from all network layers and physical ports of the receiving device, covering optical channel data of all layers: ODU0, ODU1, ODU2, and ODU3. For each access overhead data stream, the system uses a hardware byte parsing channel to peel off the original overhead bytes byte by byte, and identifies the multiframe positioning signal and layer identification information in the data stream. The multiframe positioning signal is based on the MFAS byte to define the 256-frame period ODU standard multiframe structure. The layer identification information is identified by parsing the overhead types of OTU segment monitoring (SM) and ODU channel monitoring (PM), combined with frame frequency and mapping characteristics, to identify the four transmission layers from ODU0 to ODU3.

[0086] After information identification is completed, the system accurately defines the ODU service level to which the current overhead data belongs based on the hierarchical identifier, determines the precise location of the data within the standard multiframe based on the frame count of the multiframe positioning signal MFAS, and then dynamically allocates or locates dedicated logical storage blocks in the shared cache pool logical address space using the ODU level and multiframe position as a two-dimensional index. The blocks are allocated according to the preset minimum allocation unit. Basic storage blocks are allocated for low-bandwidth services, while high-bandwidth services can be dynamically expanded according to data traffic. Overhead data of the same level and the same multiframe position are strictly written to the corresponding blocks in the order of reception timing to prevent frame order disorder and data overwriting issues.

[0087] Meanwhile, the cache pool has a built-in hierarchical priority manager that presets basic priority rules for ODU3, ODU2, ODU1, and ODU0 from high to low. In its implementation, the hierarchical priority manager maintains a basic weight mapping table, mapping the ODU level to a basic weight coefficient. When the centralized processing unit initiates data read scheduling, the priority manager multiplies and weights this basic weight coefficient with the dynamically calculated priority weight, and outputs the final read enable signal priority order to control the data read order of different logical storage blocks. When a high-dynamic-weight low-level business and a low-dynamic-weight high-level business have a serious conflict, the centralized processing unit arbitrates the read order according to the current system load status, coordinating with the scheduling rhythm of the core processing engine to achieve orderly and efficient retrieval of cached data.

[0088] Reference Figure 1 The processing method includes S110-S160:

[0089] S110 collects computing task scheduling instructions and network configuration signaling from upper-layer applications in real time, as well as raw overhead bytes and raw alarm event streams from lower-layer networks.

[0090] S120 assigns business intent weights to the corresponding computing task entities according to the computing task scheduling instructions, and establishes a bearing binding relationship between computing task entities and network resource entities according to network configuration signaling. Combining the original overhead bytes and the original alarm event stream of the underlying hardware, it constructs and updates a dynamic network status graph in real time. The nodes in the dynamic network status graph include computing task entities, logical path entities, network resource entities and status event entities. The nodes are connected by bearing, composition, influence and association relationship edges.

[0091] S130, based on the dynamic network state graph, calculates the fusion criticality weight for each active OTN network entity. The fusion criticality weight integrates the service intent weight of the corresponding OTN network entity's carried services, the real-time health risk score of the corresponding OTN network entity obtained based on the graph propagation model, and the risk propagation coefficient that represents the corresponding OTN network entity's position in the fault propagation chain.

[0092] S140, directly map or differentiate the fusion criticality weights of each active OTN network entity to generate the scheduling priority weights of each OTN network entity.

[0093] S150 dynamically controls the shared cache pool to allocate logical storage space for the overhead data streams corresponding to each OTN network entity based on scheduling priority weights and bandwidth quotas in network configuration signaling, and schedules the centralized processing unit to allocate computing resources for the overhead processing tasks of each OTN network entity; when performing overhead parsing and performance monitoring, the centralized processing unit simultaneously performs alarm analysis and deep alarm generation according to the preset alarm rule base, and the generated deep alarm information is cached and processed in subsequent steps according to scheduling priority weights;

[0094] S160: After a processing cycle is completed, key performance indicators are collected, and the processing effect is fed back to the construction and fusion of the dynamic network state map and the calculation of key weights, so as to adaptively adjust the weight calculation parameters.

[0095] Specifically, for step S110, the system adopts a dual-path synchronous acquisition mechanism for uplink and downlink, achieving real-time synchronous acquisition of data across the entire network at a preset millisecond interval. The uplink path stably connects to the upper-level network management platform and computing power scheduling application, continuously capturing computing power task scheduling instructions and network configuration signaling issued from the upper layer. The computing power task scheduling instructions include core parameters such as computing power service type, SLA service level, bandwidth quota, and service priority label. The network configuration signaling covers the entire network configuration information, including OTN port working mode, frame structure parameters, performance threshold standards, service and channel binding relationship, and scheduling parameter configuration. The downlink path monitors the entire network OTN transmission link in real time through the device's physical optical port, continuously stripping the original overhead bytes of the link layer. At the same time, it captures the original hardware alarm event streams reported by the hardware port, such as frame loss, bit error, signal degradation, and synchronization failure. All collected signaling data, overhead bytes, and original alarm events are uniformly marked with high-precision timestamps to ensure complete synchronization of the entire network data time sequence, providing accurate and unified data source support for subsequent network state modeling and weight calculation.

[0096] For step S120, the system pre-establishes a standardized computing power service weight classification system with a fixed weight value range of 0-1. After receiving the upper-layer computing power task scheduling instruction, the system combines the SLA level, bandwidth guarantee requirements, and service priority label in the instruction to assign a unique service intent weight to each online computing power task entity.

[0097] Meanwhile, as the underlying bearer network of the computing power network, the OTN system combines the service and channel binding relationship in the network configuration signaling collected by S110 to establish an initial association binding between the upper-layer computing power task entities and the lower-layer OTN network resource entities (such as specific ODUk slices or hard pipes) that provide transmission channel guarantees, thereby realizing the accurate mapping of application layer computing power intentions to transmission layer physical resources.

[0098] Subsequently, the real-time updated raw overhead byte data and the underlying hardware raw alarm event stream are integrated, and a dynamic network status graph is constructed based on a graph database. The graph is standardized and divided into four core node types: computing power task entity, logical path entity, network resource entity, and status event entity. Each node is bound to a unique device ID and timestamp identifier. The computing power task entity records the task running status, weight value, and bandwidth usage parameters. The logical path entity records the OTN end-to-end transmission path, the network elements and port information passed through. The network resource entity covers all active OTN boards, physical ports, optical channels, and cache resources (i.e., active OTN network entities in the following text) and records resource utilization and running parameters. The status event entity stores dynamic event data such as underlying raw alarms, in-depth analysis alarms, performance anomalies, and latency fluctuations in real time.

[0099] Nodes are associated and bound to each other through four types of standardized relationship edges. The bearing relationship edge records the resource bearing binding relationship between network resource entities and computing power task entities. The composition relationship edge records the link composition relationship between logical paths and network resources. The influence relationship edge records the transmission impact relationship of network resource anomalies on downstream services. The association relationship edge records the linkage relationship between various status events and network resources. The system refreshes the graph node parameters and edge relationships across the entire domain according to the collection cycle to realize the dynamic iterative update of network status.

[0100] Reference Figure 2 S130, the step of calculating the fusion criticality weight for each active OTN network entity based on the dynamic network state graph specifically includes S210-S250:

[0101] S210: By traversing the bearing relationship edges in the dynamic network state graph, determine all computing power task entities carried by the target OTN network entity;

[0102] S220: Obtain the largest business intent weight among all computing power task entities, and use it as the business intent weight component of the target OTN network entity.

[0103] S230: Obtain the real-time health risk score of the target OTN network entity from the dynamic network state graph, and use it as a health risk component;

[0104] S240: By analyzing the influence relationship edges starting from the target OTN network entity in the dynamic network state graph, the number of computing power task entities downstream of the target OTN network entity that are affected and whose business intent weight exceeds the set threshold is counted, and the risk propagation coefficient component is obtained after normalization.

[0105] S250 is obtained by multiplying the business intent weight component, health risk component, and risk propagation coefficient component by the dynamically adjustable business intent weight factor, health risk weight factor, and risk propagation amplification factor, respectively, and then summing them up.

[0106] Specifically, the system employs a depth-first traversal algorithm, starting with each target OTN network entity to be evaluated as the initial traversal node. It searches layer by layer along all outward-extending bearer relationship edges in the graph, comprehensively collecting all computing power task entities directly carried by the current target OTN network entity. At the same time, the system automatically filters out invalid computing power task entities that are offline, suspended, or have abnormally disconnected links, retaining only active computing power tasks that are in normal online operation. This completely avoids invalid data interfering with subsequent weight calculation results and locks in all effective bearer services corresponding to the target network element.

[0107] The system iterates through the service intent weight values ​​of all active computing power task entities corresponding to the target OTN network entity, and filters out the maximum value through a global value comparison. This maximum value is directly defined as the service intent weight component of the current target OTN network entity. This component can intuitively reflect the importance of the highest level of service carried by the current OTN network element, ensuring that the network element corresponding to the core high-value service can obtain resource allocation priority in subsequent scheduling.

[0108] Reference Figure 3 In S230, the calculation steps for the real-time health risk score include S310-S340:

[0109] S310: Extract raw performance monitoring parameters and historical alarm events directly associated with the target OTN network entity from the dynamic network state graph;

[0110] S320 compares the original performance monitoring parameters with the preset threshold range and calculates the current deviation.

[0111] S330 calculates the historical risk residual value by combining the frequency, severity level and time decay factor of historical alarm events;

[0112] S340, which combines the current deviation and historical risk residual values, is used to calculate a real-time health risk score.

[0113] Specifically, the system relies on the unique entity identifier index of the dynamic network state graph to retrieve two types of core data directly associated with the target OTN network entity. It should be noted that since step S130 is executed before step S150, the latest performance monitoring parameters produced by the centralized processing unit in the current scheduling cycle have not yet been generated. Therefore, the raw performance monitoring parameters extracted here are the data produced in the previous scheduling cycle and updated in the graph. This introduces cross-cycle temporal dependencies to ensure a closed-loop data logic. For cold start scenarios where the system initially operates without historical data, all performance parameters are taken as the standard median value by default, the current deviation is recorded as 0, and the health risk score is set to the baseline value of 0.5 by default.

[0114] The original performance monitoring parameters follow the ITU-T standard to collect core parameters such as optical power, bit error rate, frame loss rate, latency jitter, and overhead byte bit error rate, with a uniform parameter acquisition accuracy of 10. -9 The first category is to ensure the accuracy of performance data; the second category is to archive all historical alarm events of the network element in the past 24 hours (covering the original alarms of the underlying hardware and the in-depth analysis alarms generated internally by the system), and to completely retain the trigger time, recovery time, severity level, alarm type and cumulative number of triggers of each alarm, so as to provide complete historical data support for subsequent risk quantification calculations.

[0115] The system pre-configures standardized, dynamically updatable threshold ranges for each OTN performance monitoring parameter. These threshold ranges are transmitted and updated in real time by network configuration signaling collected by the S110. For example, under normal operating conditions, the normal threshold for optical power is set to -10dBm to +3dBm, and the normal threshold for bit error rate is ≤1×10⁻⁶. -12 The standard threshold for frame loss rate is 0 to adapt to different network scenarios.

[0116] The system compares each of the real-time collected raw performance parameters with the corresponding threshold intervals one by one, and uses a piecewise function to calculate the deviation of each parameter: if the maximum fluctuation range of the threshold is 0, then the deviation is 0 when the real-time parameter is equal to the threshold, and a preset maximum deviation upper limit of 1 is directly assigned when the real-time parameter deviates from the threshold; if the maximum fluctuation range of the threshold is not 0 and the real-time parameter is within the threshold range, the deviation of each parameter = |real-time parameter value - threshold median| / maximum fluctuation range of the threshold; if the maximum fluctuation range of the threshold is not 0 and the real-time parameter exceeds the limit, the deviation of each parameter = preset basic deviation (usually the normalized value at the threshold range boundary, such as 1.0) + limit violation penalty coefficient (a positive coefficient dynamically issued by network configuration signaling) × (|real-time parameter value - threshold boundary| / maximum fluctuation range of the threshold) to reflect the severity of the limit violation state; finally, the arithmetic mean of the deviation of all performance parameter deviations is taken as the overall current deviation of the target OTN network entity, and the deviation result is uniformly normalized to the 0-1 range. The larger the value, the higher the degree of deviation of the current network element's operating performance from the normal standard.

[0117] The system has a pre-defined standardized alarm level weighting system: Level 1 emergency alarms have a weighting coefficient of 1.0, Level 2 important alarms have a weighting coefficient of 0.7, Level 3 general alarms have a weighting coefficient of 0.4, and Level 4 alert alarms have a weighting coefficient of 0.1. At the same time, an exponential time decay factor is introduced to achieve time-based weighting. The closer the alarm event is to the current time, the larger the decay factor value and the higher the risk weight ratio. Historical alarms older than 24 hours have a decay factor of zero and are not included in the risk calculation.

[0118] In practice, the system first calculates the risk value of each valid historical alarm according to "alarm level coefficient × cumulative occurrence frequency × time decay factor", then sums all the alarm risk values ​​and completes global normalization processing, mapping the result to the 0-1 standard range, and finally obtains the historical risk residual value that can reflect the impact of historical faults of network elements.

[0119] The system uses a fixed-weighted fusion algorithm to integrate two types of risk indicators. The default weight ratio is 60% for the current deviation and 40% for the historical risk residual value. The unified calculation formula is: health risk component = current deviation × 0.6 + historical risk residual value × 0.4. The calculation result is rounded to two decimal places and locked in the range of 0-1. This value is the real-time health risk score of the network element. The higher the value, the greater the current operational hidden danger and the higher the failure risk of the network element. Priority should be given to allocating processing resources to ensure stable operation.

[0120] The system uses the target OTN network entity as the core tracing node, traverses all downstream influence relationship edges in the dynamic network state graph, and counts all downstream computing power task entities that can be directly or indirectly affected by the network element's performance abnormality or failure layer by layer. At the same time, it filters according to a preset business weight threshold of 0.5. This 0.5 threshold is the industry-standard SLA dividing line that distinguishes core business from ordinary business. Only the number of medium and high priority core computing power tasks with business intent weight exceeding the threshold is counted to avoid interference from low-value business.

[0121] Subsequently, the maximum-minimum normalization algorithm is adopted. The formula "Risk propagation coefficient component = (Number of affected tasks of the current entity - Number of minimum affected tasks in the entire network) / (Number of maximum affected tasks in the entire network - Number of minimum affected tasks in the entire network + z)" is used to map the number of effectively affected core tasks to the standard range of 0-1. Here, z is a very small positive constant that approaches 0 to avoid the zeroing anomaly when the number of affected tasks in the entire network is 0. The normalized result is the risk propagation coefficient component, which reflects the scope and risk level of the impact of the network element failure on the core business of the entire network.

[0122] The system is configured with three sets of adaptively adjustable weighting factors. The initial default values ​​are 0.3 for business intent weighting factor, 0.4 for health risk weighting factor, and 0.3 for risk propagation amplification factor. The values ​​of the three factors are all in the range of 0-1, and the sum of the three is always 1, ensuring the balance and stability of the weighting system. The system completes the fusion calculation through a unified weighting formula, specifically: Fusion Criticality Weight = Business Intent Weight Component × Business Intent Weighting Factor + Health Risk Component × Health Risk Weighting Factor + Risk Propagation Coefficient Component × Risk Propagation Amplification Factor. The final fusion criticality weight can comprehensively reflect the three core dimensions of network element characteristics: business value, operational risk, and propagation risk.

[0123] Specifically, when the entire network is in a healthy, alarm-free operating state, both the health risk component and the risk propagation coefficient component approach 0. At this time, the integration criticality weight is mainly determined by the business intent weight component, and the system scheduling strategy automatically degenerates into a regular priority scheduling based on the business SLA level, ensuring that high-value businesses continue to receive high-quality resource guarantees.

[0124] For step S140, since the three components—business intent weight, health risk score, and risk propagation coefficient—have all been normalized to the 0-1 range in the preceding calculations, and the sum of the three weight factors is 1, the weighted sum of the fusion criticality weights naturally falls within the 0-1 range, eliminating the need for redundant extreme value normalization. The system directly uses the fusion criticality weights as the basic scheduling priority weights for each OTN network entity. To enhance the scheduling differentiation among multiple entities, an exponential mapping function can be introduced as needed for nonlinear amplification to generate the final scheduling priority weights. These weights serve as the core basis for subsequent allocation of cache and computing resources, while avoiding the logical flaw of the original normalization mechanism where the weights tend to zero when there is only one active entity in the entire network.

[0125] Reference Figure 4 In S150, the step of dynamically controlling the shared buffer pool to allocate logical storage space for the overhead data streams corresponding to each OTN network entity specifically includes S410-S430:

[0126] S410, associates the scheduling priority weight of each active OTN network entity with the bandwidth quota in the network configuration signaling and the total logical capacity of the shared buffer pool to calculate the guaranteed buffer quota allocated to the overhead data stream corresponding to the OTN network entity;

[0127] S420 identifies the top K active OTN network entities by scheduling priority weight, marks these OTN network entities as hot entity groups, and dynamically maps and locks a contiguous storage area with low access latency as a hot storage area in the physical storage space of the shared cache pool for the overhead data corresponding to the hot entity groups.

[0128] S430, the controller of the shared cache pool, adjusts the capacity quota of each logical storage block and the entity binding relationship of hot storage areas in real time according to the scheduling priority weight of each OTN network entity updated in each processing cycle.

[0129] Specifically, for step S150, based on the total logical capacity of the shared cache pool, an algorithm combining proportional allocation and minimum guarantee is used to accurately calculate the cache quota of a single network element. The unified calculation formula is: Single entity guaranteed cache quota = MAX(total logical capacity of shared cache pool × (current entity scheduling priority weight / total weight of all active entities in the network), minimum guaranteed capacity converted from bandwidth quota in network configuration signaling). If the sum of the minimum guaranteed capacities of all entities in the network exceeds the total logical capacity of the shared cache pool, the guaranteed capacity of each entity is proportionally compressed to the total capacity range. The calculation result is rounded according to the minimum cache allocation unit, and the minimum guaranteed cache capacity is allocated to each OTN overhead data stream. This mechanism prevents high-priority business data cache overflow and loss problems, and achieves accurate matching between cache resources and business importance.

[0130] The system sorts the scheduling priority weights of active OTN entities across the network in descending order during each scheduling cycle, and extracts the top K entities according to a preset threshold K to form a hotspot entity group. The value of K can be flexibly customized and adapted to different network load scenarios through upper-layer network configuration signaling.

[0131] Meanwhile, within the shared cache pool physical storage space, dedicated contiguous physical storage areas are dynamically partitioned as hotspot storage regions, defined as low-access-latency storage regions. Compared to the logical address discrete hash mapping method used in ordinary regions, this effectively eliminates the Bank pre-charge and activation switching overhead of DDR4 memory by ensuring the absolute continuity of physical addresses, thereby achieving lower and more stable average read and write access latency.

[0132] The capacity of the hot storage area is dynamically adjusted based on the total guaranteed cache quota calculated in the proportional allocation of the current hot entity group. The system dynamically maps all overhead data logical storage blocks corresponding to the hot entity group to this continuous physical range and issues storage lock instructions to solidify the mapping relationship. During the current scheduling cycle, the storage space in this area is prohibited from being occupied, released, or tampered with by low-priority services, ensuring high-speed read and write efficiency of hot core business data.

[0133] The system operates on a preset cycle as a complete processing cycle. Each time the network-wide scheduling priority weight is updated, a cache resource adjustment mechanism is immediately triggered. On one hand, the capacity quota of each logical storage block is recalculated based on the updated priority weight. The cache resources of network elements with increased priority are dynamically expanded, while the redundant caches of network elements with decreased priority are reasonably reduced, so that the cache quota can be dynamically adapted to business changes on demand. On the other hand, the members of the hot spot entity group and the capacity of the hot spot area are updated simultaneously. The storage blocks of newly promoted high-priority network elements are mapped to low-latency hot spot storage areas, and network elements that have left the hot spot group are unbound from the hot spot area and fall back to the ordinary storage area, thus completing the dual dynamic optimization of cache logical quota and physical storage resources.

[0134] Reference Figure 5 In S150, the step of the scheduling centralized processing unit allocating computing resources for the overhead processing tasks of each OTN network entity specifically includes S510-S530:

[0135] S510, within the centralized processing unit, creates a corresponding software task queue for each active OTN network entity to cache ODU overhead data to be processed;

[0136] S520 sets the scheduling priority weight of each OTN network entity to the dynamic scheduling weight of the corresponding software task queue of the corresponding OTN network entity in the current scheduling period.

[0137] The S530, within the centralized processing unit, uses a weighted scheduling algorithm based on the dynamic scheduling weights of each software task queue to allocate CPU time slices or processing threads to each software task queue.

[0138] Specifically, the centralized processing unit is based on a heterogeneous concurrent architecture and creates an independent software task queue for each online active OTN network entity. Each queue is independent of the others and the data is completely isolated. Each queue caches a maximum number of tasks according to a preset limit and adopts an in-first-out ordered caching mechanism. It is specifically used to temporarily cache the ODU overhead data processing task descriptors and data pointers of the corresponding network element that are to be parsed, monitored, or judged. This effectively avoids mutual interference between processing tasks of different network elements and ensures that the overhead processing tasks of a single network element are queued in an orderly manner and executed stably.

[0139] The system directly assigns the updated OTN network entity scheduling priority weights for each scheduling cycle to the dynamic scheduling weights of the corresponding dedicated software task queues, and updates them in real time to the configuration register of the centralized processing unit task scheduler. This enables real-time linkage between queue scheduling weights and network element service value, operational risks, and propagation risks, providing the latest configuration basis for computing resource scheduling.

[0140] The task scheduler of the ARM core within the centralized processing unit employs a weighted round-robin scheduling algorithm. Based on the dynamic scheduling weights of each software task queue, it precisely allocates runtime slices and processing threads to the multi-core CPU. It reads corresponding overhead data from the shared cache pool based on the task descriptor and performs parsing. Task queues with higher weights receive longer CPU time slices and have more concurrent processing threads bound in a single round-robin scheduling. Simultaneously, the FPGA hardware logic configures corresponding parsing pipeline priorities and data throughput bandwidth according to these dynamic scheduling weights. Through differentiated computing power allocation, it ensures that high-importance, high-risk core OTN overhead processing tasks are prioritized and completed quickly, minimizing core business processing latency.

[0141] Reference Figure 6 In S150, the steps for caching and subsequent processing of the generated deep alarm information based on scheduling priority weights specifically include S610-S630:

[0142] S610, when performing overhead analysis and performance monitoring, the centralized processing unit determines whether to trigger a deep analysis alarm event based on a preset alarm rule base;

[0143] S620: For triggered deep analysis alarm events, extract the OTN network entity identifier, alarm type and severity level associated with the corresponding alarm event, and encapsulate them into a deep alarm message;

[0144] S630 sends deep alarm messages to the alarm cache area linked to the shared cache pool for priority sorting and caching according to the scheduling priority weight of the OTN network entity associated with them, or directly as new status event inputs and feeds them back to the construction process of the dynamic network status graph.

[0145] Specifically, during the entire process of overhead byte parsing and real-time link performance monitoring, the centralized processing unit retrieves a locally pre-built standardized alarm rule library in real time. This rule library fully conforms to the ITU-T OTN equipment alarm specifications and has built-in standardized alarm triggering rules for all scenarios, including bit error rate exceeding limits, optical power anomalies, frame loss, multiframe synchronization failure, buffer overflow, and performance degradation. Each rule is configured with corresponding performance thresholds and abnormal duration judgment conditions. When the real-time monitored overhead data and performance parameters continuously meet the triggering conditions of a certain alarm rule, the system immediately determines that the corresponding in-depth analysis alarm event is triggered. This type of alarm, generated by the system internally based on continuous monitoring and in-depth analysis, is different from the underlying hardware original alarms directly reported by the physical ports in S110. It contains higher-dimensional correlation analysis information, eliminating false alarms and missed alarms.

[0146] After determining that a deep analysis alarm event has occurred, the system immediately initiates an automated encapsulation process to accurately extract core fields such as the unique device identifier of the OTN network entity associated with the alarm, the precise alarm type, the standardized severity level, the alarm trigger time, the corresponding bearer service ID, and the physical port number. The data is then encapsulated according to a unified JSON structured data format to generate a deep alarm message data packet with complete fields, a unified format, and no redundancy or missing data. This provides a standardized data carrier for subsequent priority caching and status updates.

[0147] The system reads the real-time scheduling priority weights of the OTN entities associated with deep alarm messages, and prioritizes the alarm messages according to their weights. Deep alarm messages corresponding to high-weight core services are preferentially stored in the front queue of a specially partitioned alarm cache logical partition in the shared cache pool, while low-weight ordinary service alarms are cached later, realizing hierarchical caching, orderly reporting and processing of alarm data. At the same time, the deep alarm message and the original alarms from the underlying hardware are uniformly transformed into new status event entity data, which are input and updated in real time to the dynamic network status graph, and the status node information of the corresponding OTN network element is refreshed synchronously. This allows the network status graph to absorb alarm risk data from the entire network in real time, realizing dynamic closed-loop updates of network status awareness.

[0148] Reference Figure 7 In S160, the steps of feeding back the processing effect to the construction of the dynamic network state graph and the calculation of the fusion key weights, so as to adaptively adjust the weight calculation parameters, specifically include S710-S740:

[0149] S710 monitors the overhead processing tasks corresponding to each active OTN network entity and obtains the end-to-end latency from when the ODU overhead data enters the shared buffer pool to when it is processed by the centralized processing unit.

[0150] S720, analyze the correlation between end-to-end latency and the scheduling priority weight of the corresponding OTN network entity, and evaluate whether the end-to-end latency shows the expected decreasing trend as the scheduling priority weight increases;

[0151] S730, if the evaluation results do not meet expectations, the business intent weight factor, health risk weight factor or risk propagation amplification factor used in calculating the integration criticality weight will be adaptively adjusted based on the deviation analysis.

[0152] S740 applies the adjusted weighting factor to the fusion criticality weight calculation in the next processing cycle, forming a closed-loop optimization.

[0153] Specifically, for step S160, at the end of each processing cycle, the system initiates a key performance indicator statistics process. By writing the data into the shared cache pool entry timer and the time difference between the timer mark and the timer mark of the centralized processing unit task completion, the system accurately calculates the end-to-end processing latency of the overhead data of each active OTN network entity, synchronously associates and records the current scheduling priority weight of the corresponding network element, and forms a periodic performance statistics report.

[0154] The system employs the Spearman rank correlation coefficient algorithm to quantify the monotonic correlation between the scheduling priority weights of all OTN entities in the network and the end-to-end processing latency. The scheme presupposes that the higher the scheduling priority weight, the more sufficient the resource allocation and the lower the processing latency, with the two showing a significant monotonically decreasing relationship. When the Spearman rank correlation coefficient is less than -0.7 (-0.7 is the standard threshold for judging strong negative correlation in statistics), the optimization effect is considered to have met the target. If the correlation coefficient is greater than -0.7, the latency optimization effect is considered to have not met the expectations, indicating a mismatch between cache resources and computing resources in scheduling. In this case, a parameter correction mechanism needs to be activated to adapt to the nonlinear mapping that may exist in the scheduling system.

[0155] The system automatically initiates deviation source analysis logic, accurately locating the cause of anomalies by comparing the proportion of each weight component with latency fluctuation data. If the latency optimization of high-business-weighted network elements is insufficient, the business intent weight factor is increased; if the processing latency of high-health-risk network elements is too high, the health-risk weight factor is increased; if the scheduling resources of network elements with a wide risk propagation range are insufficient, the risk propagation amplification factor is increased. All factor adjustments adopt an adaptive step size mechanism, with a basic step size of 0.05. This 0.05 is an empirically optimized value to ensure the balance between the stability of the system's weight system and the response sensitivity. When the deviation fails to converge for several consecutive periods, the step size increases by a preset coefficient to accelerate convergence (maximum not exceeding 0.15). When the deviation narrows, the step size decreases accordingly to prevent overshoot oscillation. The total sum of the three weight factors is maintained at 1 throughout the process. When one factor is increased, the other two factors are reduced proportionally to deduct the increased share. If any of the other factors has already dropped to 0, no further deduction is made. This ensures the overall stability of the weight system while correcting deviations and accurately repairs scheduling strategy adaptation vulnerabilities.

[0156] The system will solidify and store the three types of weight factor parameters that have been adaptively adjusted in this cycle, and synchronously update the configuration parameters of the weight calculation module. After the next processing and scheduling cycle starts, it will directly call the optimized new weight factors to carry out the iterative calculation of the fusion criticality weight, and synchronously update the cache quota, hot storage binding relationship, and computing power scheduling ratio of OTN entities across the network. Through a closed-loop process of periodic data collection, effect evaluation, deviation correction, and parameter iteration, the system will continuously optimize the efficiency of the entire process of OTN overhead analysis, performance monitoring, alarm handling, and resource scheduling, and achieve continuous iterative improvement of the network's processing performance and risk handling capabilities.

[0157] Based on the above method embodiments, the second embodiment of this application discloses an OTN overhead and alarm processing system based on cache sharing. The OTN overhead and alarm processing system based on cache sharing in this embodiment can implement any of the above-described methods for processing OTN overhead and alarms based on cache sharing, and the specific working process of each module in the OTN overhead and alarm processing system based on cache sharing can be referred to the corresponding process in the above method embodiments.

[0158] For ease of understanding, an example is provided below: An OTN overhead and alarm processing system based on cache sharing includes:

[0159] A shared buffer pool is used to uniformly receive and cache multi-channel optical data unit (ODU) overhead data streams from different network layers and different physical ports;

[0160] The centralized processing unit, as the core processing engine, is configured to perform execution overhead analysis, performance monitoring, and alarm judgment.

[0161] The data acquisition module is used to collect computing task scheduling instructions and network configuration signaling from upper-layer applications in real time, as well as raw overhead bytes and raw alarm event streams from lower-layer networks.

[0162] The cognitive modeling module is used to assign business intent weights to the corresponding computing task entities according to the computing task scheduling instructions, and to establish the bearing binding relationship between computing task entities and network resource entities according to network configuration signaling. Combining the original overhead bytes and the original alarm event stream of the underlying hardware, it constructs and updates the dynamic network status graph in real time. The nodes in the dynamic network status graph include computing task entities, logical path entities, network resource entities and status event entities. The nodes are connected by bearing, composition, influence and association relationship edges.

[0163] The criticality calculation module is used to calculate the fused criticality weight for each active OTN network entity based on the dynamic network state graph. The fused criticality weight integrates the service intent weight of the corresponding OTN network entity's carried services, the real-time health risk score of the corresponding OTN network entity obtained based on the graph propagation model, and the risk propagation coefficient that represents the corresponding OTN network entity's position in the fault propagation chain.

[0164] The scheduling strategy generation module is used to directly map or differentiate the fusion criticality weights of each active OTN network entity to generate the scheduling priority weights of each OTN network entity.

[0165] The elastic scheduling controller is used to dynamically control the shared cache pool to allocate logical storage space for the overhead data streams corresponding to each OTN network entity based on scheduling priority weights and bandwidth quotas in network configuration signaling, and to schedule the centralized processing unit to allocate computing resources for the overhead processing tasks of each OTN network entity. The centralized processing unit is further configured to: simultaneously perform alarm analysis and deep alarm generation according to a preset alarm rule base when performing overhead parsing and performance monitoring; and cache and process the generated deep alarm information according to scheduling priority weights.

[0166] The feedback optimization module is used to collect key performance indicators after a processing cycle ends and feed the processing effect back to the construction and fusion of the dynamic network state graph and the calculation process of key weights, so as to adaptively adjust the weight calculation parameters.

[0167] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.

Claims

1. A method for handling OTN overhead and alarm processing based on cache sharing, characterized in that, This is applied to an OTN system that includes a shared buffer pool and a centralized processing unit. The shared buffer pool is used to uniformly receive and buffer multi-channel optical data unit (ODU) overhead data streams from different network layers and physical ports. The centralized processing unit, as the core processing engine, is configured to perform overhead parsing, performance monitoring, and alarm judgment. The processing methods include: Real-time acquisition of computing task scheduling instructions and network configuration signaling from upper-layer applications, as well as raw overhead bytes and raw alarm event streams from lower-layer networks; According to the computing power task scheduling instructions, the corresponding computing power task entities are assigned business intent weights, and the bearing binding relationship between computing power task entities and network resource entities is established according to network configuration signaling. Combining the original overhead bytes and the original alarm event stream of the underlying hardware, a dynamic network status graph is constructed and updated in real time. The nodes in the dynamic network status graph include computing power task entities, logical path entities, network resource entities and status event entities. The nodes are connected by bearing, composition, influence and association relationship edges. Based on the dynamic network state graph, a fusion criticality weight is calculated for each active OTN network entity. The fusion criticality weight integrates the service intent weight of the corresponding OTN network entity's carried services, the real-time health risk score of the corresponding OTN network entity obtained based on the graph propagation model, and the risk propagation coefficient that represents the corresponding OTN network entity's position in the fault propagation chain. The fusion criticality weights of each active OTN network entity are directly mapped or differentiated and amplified to generate the scheduling priority weights of each OTN network entity. Based on scheduling priority weights and bandwidth quotas in network configuration signaling, the shared cache pool is dynamically controlled to allocate logical storage space for the overhead data streams corresponding to each OTN network entity, and the centralized processing unit is scheduled to allocate computing resources for the overhead processing tasks of each OTN network entity. When performing overhead parsing and performance monitoring, the centralized processing unit simultaneously performs alarm analysis and deep alarm generation according to the preset alarm rule base. The generated deep alarm information is cached and processed in subsequent steps according to scheduling priority weights. After a processing cycle is completed, key performance indicators are collected, and the processing effect is fed back to the construction and fusion of the dynamic network state graph and the calculation of key weights, so as to adaptively adjust the weight calculation parameters.

2. The OTN overhead and alarm processing method based on cache sharing according to claim 1, characterized in that, The internal logical management process of a shared cache pool for uniformly receiving and caching multiple ODU overhead data streams includes: Within the shared cache pool, for each received ODU overhead data stream, logical storage blocks are dynamically allocated for the corresponding overhead data based on the ODU level to which the corresponding overhead data belongs and the multiframe position information of the corresponding overhead data. The hierarchical priority manager manages the reading order of data in different logical storage blocks based on ODU hierarchical information, in order to coordinate with the scheduling of the centralized processing unit.

3. The OTN overhead and alarm processing method based on cache sharing according to claim 2, characterized in that, The steps for dynamically allocating logical storage blocks for corresponding overhead data based on the ODU level to which the overhead data belongs and the multiframe location information of the corresponding overhead data specifically include: Parse the raw overhead bytes in the ODU overhead data stream to identify the multiframe positioning signals and hierarchical identification information contained therein; The corresponding overhead data is determined by the hierarchical identification information, and the position of the corresponding overhead data within the multiframe is determined by the multiframe positioning signal. Based on the ODU level and multiframe location, a corresponding logical storage block is dynamically allocated or located in the shared cache pool for the corresponding overhead data, which is used to sequentially store the overhead data.

4. The OTN overhead and alarm processing method based on cache sharing according to claim 1, characterized in that, The specific steps for dynamically controlling the shared cache pool to allocate logical storage space for the overhead data streams corresponding to each OTN network entity include: The scheduling priority weight of each active OTN network entity is associated with the bandwidth quota in the network configuration signaling and the total logical capacity of the shared buffer pool to calculate the guaranteed buffer quota allocated to the overhead data stream corresponding to the OTN network entity. Identify the top K active OTN network entities by scheduling priority weight, mark these OTN network entities as hot entity groups, and dynamically map and lock a contiguous storage area with low access latency as a hot storage area in the physical storage space of the shared cache pool for the overhead data corresponding to the hot entity groups. The controller of the shared cache pool adjusts the capacity quota of each logical storage block and the entity binding relationship of hot storage areas in real time based on the scheduling priority weight of each OTN network entity updated in each processing cycle.

5. A method for handling OTN overhead and alarms based on cache sharing according to claim 1, characterized in that, The specific steps by which the centralized processing unit allocates computing resources for the overhead processing tasks of each OTN network entity include: Within the centralized processing unit, a corresponding software task queue is created for each active OTN network entity to cache the ODU overhead data to be processed; Set the scheduling priority weight of each OTN network entity to the dynamic scheduling weight of the corresponding software task queue of the corresponding OTN network entity in the current scheduling period. The task scheduler within the centralized processing unit allocates CPU time slices or processing threads to each software task queue based on the dynamic scheduling weights of each queue using a weighted scheduling algorithm.

6. The OTN overhead and alarm processing method based on cache sharing according to claim 1, characterized in that, The specific steps for caching and subsequent processing of generated deep alert information based on scheduling priority weights include: When performing overhead analysis and performance monitoring, the centralized processing unit determines whether to trigger a deep analysis alarm event based on a preset alarm rule base. For the triggered deep analysis alarm events, extract the OTN network entity identifier, alarm type and severity level associated with the corresponding alarm event, and encapsulate them into a deep alarm message; Deep alarm messages are sent to the alarm cache area linked to the shared cache pool for priority sorting and caching based on the scheduling priority weight of the OTN network entity associated with them, or directly used as new status event inputs and fed back into the construction process of the dynamic network status graph.

7. A method for handling OTN overhead and alarms based on cache sharing according to claim 1, characterized in that, Based on the dynamic network state graph, the specific steps for calculating the fusion criticality weight for each active OTN network entity include: By traversing the bearing relationship edges in the dynamic network state graph, all computing power task entities carried by the target OTN network entity are determined. Obtain the largest business intent weight among all computing power task entities, and use it as the business intent weight component of the target OTN network entity. The real-time health risk score of the target OTN network entity is obtained from the dynamic network state graph and used as a health risk component. By analyzing the influence relationship edges originating from the target OTN network entity in the dynamic network state graph, the number of computing power task entities downstream of the target OTN network entity that are affected and whose business intent weight exceeds a set threshold is counted, and the risk propagation coefficient component is obtained after normalization. The business intent weight component, health risk component, and risk propagation coefficient component are multiplied by the dynamically adjustable business intent weight factor, health risk weight factor, and risk propagation amplification factor, respectively, and then summed to obtain the fusion criticality weight.

8. A method for handling OTN overhead and alarms based on cache sharing according to claim 7, characterized in that, The calculation steps for a real-time health risk score include: Extract raw performance monitoring parameters and historical alarm events directly associated with the target OTN network entity from the dynamic network state graph; The original performance monitoring parameters are compared with the preset threshold range to calculate the current deviation. Calculate the historical risk residual value by combining the frequency, severity level, and time decay factor of historical alarm events; A real-time health risk score is obtained by combining the current deviation and the historical risk residual value through weighted calculation.

9. A method for handling OTN overhead and alarms based on cache sharing according to claim 1, characterized in that, The steps to feed back the processing results to the construction and fusion of the key weights in the dynamic network state graph, and to adaptively adjust the weight calculation parameters, specifically include: Monitor the overhead processing tasks corresponding to each active OTN network entity and obtain the end-to-end latency from when the ODU overhead data enters the shared buffer pool to when it is processed by the centralized processing unit. Analyze the correlation between end-to-end latency and the scheduling priority weight of the corresponding OTN network entity, and evaluate whether end-to-end latency shows the expected decreasing trend as the scheduling priority weight increases; If the evaluation results do not meet expectations, the business intent weight factor, health risk weight factor, or risk propagation amplification factor used in calculating the integration criticality weight will be adaptively adjusted based on the deviation analysis. The adjusted weighting factors are applied to the fusion criticality weight calculation in the next processing cycle, forming a closed-loop optimization.

10. An OTN overhead and alarm processing system based on cache sharing, characterized in that, Performing the OTN overhead and alarm processing method based on cache sharing as described in any one of claims 1 to 9 includes: A shared buffer pool is used to uniformly receive and buffer multi-channel optical data unit (ODU) overhead data streams from different network layers and different physical ports; The centralized processing unit, as the core processing engine, is configured to perform execution overhead analysis, performance monitoring, and alarm judgment. The data acquisition module is used to collect computing task scheduling instructions and network configuration signaling from upper-layer applications in real time, as well as raw overhead bytes and raw alarm event streams from lower-layer networks. The cognitive modeling module is used to assign business intent weights to the corresponding computing task entities according to the computing task scheduling instructions, and to establish the bearing binding relationship between computing task entities and network resource entities according to network configuration signaling. Combining the original overhead bytes and the original alarm event stream of the underlying hardware, it constructs and updates the dynamic network status graph in real time. The nodes in the dynamic network status graph include computing task entities, logical path entities, network resource entities and status event entities. The nodes are connected by bearing, composition, influence and association relationship edges. The criticality calculation module is used to calculate the fused criticality weight for each active OTN network entity based on the dynamic network state graph. The fused criticality weight integrates the service intent weight of the corresponding OTN network entity's carried services, the real-time health risk score of the corresponding OTN network entity obtained based on the graph propagation model, and the risk propagation coefficient that represents the corresponding OTN network entity's position in the fault propagation chain. The scheduling strategy generation module is used to directly map or differentiate the fusion criticality weights of each active OTN network entity to generate the scheduling priority weights of each OTN network entity. The elastic scheduling controller is used to dynamically control the shared cache pool to allocate logical storage space for the overhead data streams corresponding to each OTN network entity based on scheduling priority weights and bandwidth quotas in network configuration signaling, and to schedule the centralized processing unit to allocate computing resources for the overhead processing tasks of each OTN network entity. The centralized processing unit is further configured to: simultaneously perform alarm analysis and deep alarm generation according to a preset alarm rule base when performing overhead parsing and performance monitoring; and cache and process the generated deep alarm information according to scheduling priority weights. The feedback optimization module is used to collect key performance indicators after a processing cycle ends and feed the processing effect back to the construction and fusion of the dynamic network state graph and the calculation process of key weights, so as to adaptively adjust the weight calculation parameters.

Images