Data processing method, computer-readable storage medium, electronic apparatus, and computer program product
By using data context as an intermediary, the problem of intelligent application interaction in transmission networks and their management and control systems is solved, enabling efficient and secure data collection and processing. It is suitable for large-scale network resource management and monitoring, and especially improves the flexibility and efficiency of data processing in heterogeneous network environments.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- ZTE CORP
- Filing Date
- 2025-07-30
- Publication Date
- 2026-05-07
AI Technical Summary
There is no effective solution yet for how to achieve intelligent interaction in the existing transmission network and its management and control system, making it difficult for traditional operation and maintenance methods to support efficient management and control.
By using data context as an intermediary, efficient and secure data collection and processing can be achieved, including receiving and sending data collection requests, collecting target data, and cleaning, formatting, storing, compressing, filtering, classifying, associating or combining it. It supports one-to-one, one-to-many, many-to-one, and many-to-many relationship conversions to ensure data accuracy and consistency.
It significantly improves data processing efficiency and is suitable for large-scale network resource management and monitoring. In particular, it simplifies the data collection process and improves flexibility and efficiency in cross-system and cross-component data integration and analysis scenarios.
Smart Images

Figure CN2025111540_07052026_PF_FP_ABST
Abstract
Description
Data processing method, computer readable storage medium, electronic device and computer program product
[0001] Cross-reference to related applications
[0002] The present disclosure is based on Chinese Patent Application No. 2024115230368 entitled "Data processing method, computer readable storage medium, electronic device and computer program product" filed on October 29, 2024, and claiming priority to the same, the disclosure of which is incorporated herein by reference in its entirety. TECHNICAL FIELD
[0003] Embodiments of the present disclosure relate to the field of communications, and in particular, to a data processing method, a computer readable storage medium, an electronic device and a computer program product. BACKGROUND
[0004] The bearer network is the infrastructure of the communication network and is the network base supporting the digital transformation of thousands of industries. Users have higher requirements for the performance and reliability of the bearer network. As the scale of the bearer network application continues to grow, the full life cycle operation and maintenance of the bearer network is increasingly complex. The traditional operation and maintenance method cannot adapt to the scale growth of the business and is difficult to support efficient management and control. Therefore, the bearer network needs to develop along the direction of self-intelligent network, and intelligent application is a beneficial supplement to realize the self-intelligent network, including digital twin application, AI / ML (Artificial Intelligence / Machine Learning) application and data analysis application, etc. However, how the intelligent application realizes the interaction of the existing transport network and its management and control system has not been proposed.
[0005] SUMMARY
[0006] Embodiments of the present disclosure provide a data processing method, a computer readable storage medium, an electronic device and a computer program product to at least solve the problem of how the intelligent application realizes the interaction of the existing transport network and its management and control system in the related art.
[0007] According to an embodiment of the present disclosure, a data processing method is provided, applied to a data context, including: receiving a data collection request of a first entity; collecting target data according to the data collection request; returning the target data to the first entity.
[0008] According to another embodiment of the present disclosure, a data processing method is provided, applied to a first entity, including: sending a data collection request to the data context; receiving target data collected by the data context according to the data collection request.
[0009] According to still another embodiment of the present disclosure, a computer readable storage medium is also provided, in which a computer program is stored, wherein the computer program is configured to perform the steps of any of the above method embodiments when executed.
[0010] According to still another embodiment of the present disclosure, an electronic device is also provided, comprising a memory in which a computer program is stored, and a processor configured to execute the computer program to perform the steps of any of the above method embodiments.
[0011] According to still another embodiment of the present disclosure, a computer program product is also provided, comprising a computer program which, when executed by a processor, implements the steps of any of the above method embodiments. BRIEF DESCRIPTION OF DRAWINGS
[0012] FIG. 1 is a schematic diagram of connection scheduling of a management and control system in the related art;
[0013] FIG. 2 is a flowchart of a data processing method according to an embodiment of the present disclosure;
[0014] FIG. 3 is a flowchart of a data processing method according to another embodiment of the present disclosure;
[0015] FIG. 4 is a schematic diagram of a structure of a data context according to an embodiment of the present disclosure;
[0016] FIG. 5 is a schematic diagram of deployment of a data context according to an embodiment of the present disclosure;
[0017] FIG. 6 is a schematic diagram of deployment of a data context according to another embodiment of the present disclosure;
[0018] FIG. 7 is a schematic diagram of deployment of a data context according to still another embodiment of the present disclosure;
[0019] FIG. 8 is a schematic diagram of components in an n+1 layer SDN according to an embodiment of the present disclosure;
[0020] FIG. 9 is a schematic diagram of components in an n layer SDN according to another embodiment of the present disclosure;
[0021] FIG. 10 is a block diagram of a data processing device according to an embodiment of the present disclosure;
[0022] FIG. 11 is a block diagram of a data processing device according to another embodiment of the present disclosure. DETAILED DESCRIPTION
[0023] Embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments.
[0024] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.
[0025] Management Control Continuum (MCC) integrates essentially the same management and control functions, achieving unified management and control of transmission resources and providing comprehensive management and control services to upper-layer users. Software Defined Network (SDN) controllers, Element Management Systems (EMS), Network Management Systems (NMS), Operation Support Systems (OSS), and control planes are all examples of management and control systems. Functional modules within these systems provide services through interfaces. Intelligent applications interact with the management and control systems as external network applications.
[0026] Figure 1 is a schematic diagram of connection scheduling in a control system in related technologies. As shown in Figure 1, the interaction sequence for connection establishment includes components such as: Network Call Controller (NCC), Connection Controller (CC), Routing Controller (RC), Link Resources Manager (LRM), Termination and Adaptation Performer (TAP) component, and forwarding plane network elements.
[0027] The link topology and resource usage information in the controller are stored in the Resource Database (RDB).
[0028] Resources in the forwarding plane (such as time slots and bandwidth) need to be converted into resources that can be managed by the control system. Forwarding plane resources are represented by Forwarding Points (FPs) or Forwarding End Points (FwEPs), while resources used by the control system are represented by Subnetwork Points (SNPs). The relationship between FPs / FwEPs and SNPs is managed by the TAP module. An SNP can be bound to one FP / FwEP; multiple SNPs can also be bound to one FP / FwEP to indicate that multiple SNPs share the same FP / FwEP resource. In other words, from the control system's perspective, the connection maintained uses a series of SNPs (including the first and last SNPs); from the forwarding plane's perspective, it uses the FP / FwEP resources in the forwarding plane network elements.
[0029] A group of SNPs grouped together is represented as an SNPP (Sub Network Point Pool). The association between different SNPPs is represented as an SNPP Link. An SNP identifier represents an instance of an SNP, and an SNPP identifier represents an instance of an SNPP. A Boundary Resource Identifier (BRI) is used at the domain boundary to identify the transport resources at that boundary and the interfaces between control components.
[0030] For the interaction of components that directly control transmission resources, as shown in Figure 1, when the NCC receives a connection establishment request (1) in the controller, the Boundary Resource Identifier (BRI) in the request is converted by DS (2) to two SNP identifiers within the controller. It is also possible that the connection establishment request carries some or all of the connection routing information. The NCC sends the first and last SNP identifiers to the CC (3), and the CC requests the RC to query the connection route between the first and last SNPs (4). The RC calculates the path that satisfies the CC request based on the topology and local connection status information (5) provided by the LRM. If the CC request carries the connection routing information, then the connection routing information can also participate in the RC's route query. The RC returns the routing information to the CC, and the CC requests the LRM (6) to select the appropriate link connection from the links traversed by the route. The LRM configures the forwarding resource usage status to the forwarding plane (7, 8) through the TAP component. After the forwarding plane updates the link resource usage status and establishes the subnet cross-connection, the connection established by the controller is successfully established. After successful establishment, the NCC responds to the client that the connection establishment is successful.
[0031] In the SDN Controller hierarchy, upper and lower Controllers form a client layer and a service layer relationship. Client layer Controllers and service layer Controllers interact through service contexts (ServerContext) and client contexts (ClientContext). Each Controller can create multiple ClientContexts, at least one ServerContext, and one administrative context. The administrative context provides support information for administrators to manage and control the controller and performs administrator roles within the controller, including maintaining the lifecycle of client and service contexts.
[0032] For resource management and control within the SDN Controller, the resources of the ServerContext can be resources in the forwarding plane directly controlled by the local controller, or resources provided by the service layer controller. These resources are all mapped to the local resource pool in the AdministrativeContext. The AdministrativeContext then allocates a subset of the local resource pool to different ClientContexts. For each ClientContext, resources are provided to the client layer controller through a virtual network. The resources of the controller and context mentioned above refer to SNPs / SNPPs / SNPP Links, while resources in the forwarding plane refer to FPs / FwEPs. A group of SNPs combined together is represented as an SNPP, and the association between different SNPPs is represented as an SNPP Link. An SNP identifier represents an instance of an SNP, and an SNPP identifier represents an instance of an SNPP. The Boundary Resource Identifier (BRI) is used at the domain boundary to identify the transport resources at that boundary and the interfaces between control components.
[0033] A digital twin is a real-time mirror image of a physical entity in the digital world, characterized by virtual-real fusion, real-time interaction, iterative operation, and optimization. A digital twin network is a network system that creates a virtual twin of a physical network entity in a digital way, and can interact and map with the physical network entity in real time as much as possible. It is also called a network digital twin or a digital twin system.
[0034] This embodiment provides a method running on the aforementioned network management system. Figure 2 is a flowchart of a data processing method according to an embodiment of this disclosure. As shown in Figure 2, applied to a data context, the process includes the following steps:
[0035] Step S202: Receive a data collection request from the first entity;
[0036] Step S204: Collect target data according to the data collection request;
[0037] Step S206: Return the target data to the first entity.
[0038] Through the above steps S202 to S206, the problem of how intelligent applications can achieve interaction with the existing transmission network and its management and control system can be solved. By using data context as an intermediary, efficient and secure data collection and processing can be achieved, which can significantly improve data processing efficiency.
[0039] The embodiments disclosed herein enable efficient and secure data collection and processing, and are applicable to large-scale network resource management and monitoring scenarios, such as telecommunications networks, data centers, and the Internet of Things. In particular, they can significantly improve data processing efficiency when cross-system and cross-component data integration and analysis are required.
[0040] The execution subject of the above steps can be a data context, which resides in a control component, an external application, or a control system; or, the data context is an independent entity, that is, the data context can reside in one or more control components, one or more external applications, or one or more control systems. There is a hierarchical or partitioned relationship between multiple data contexts on multiple control components, multiple external applications, or multiple control systems. One data context resides on one control component, one external application, or one control system, but is not limited to these.
[0041] The data context, based on the request, transforms the request into a target data collection requirement for the target entity, and then collects data from the target entity. The transformation process may involve a relationship between the requested data and the target data collected from the target entity that is at least one of the following: one-to-one, one-to-many, many-to-one, many-to-many, or a namespace correspondence. Data collection methods include collection from data already acquired by the target entity, collection through interfaces (such as component interfaces, performance alarm collection interfaces), or system configuration collection. Furthermore, the method includes cleaning, formatting, storing, compressing, filtering, classifying, associating, or combining the collected target data, as well as authenticating, authorizing, negotiating capabilities, and configuring the first entity. The data covers network resource information, topology, services, policies, configurations, performance, metrics, status, logs, alarms, and events, etc. The data collection request includes the data collection object, type, precision, and frequency. The first entity can further process the collected target data and adjust the target entity configuration based on the results. The data context can reside in a management component, external application, or management system, or exist as an independent entity, and supports hierarchical or partitioned relationships between multiple data contexts.
[0042] In this embodiment of the disclosure, step S204 may specifically include: mapping and / or converting the data collection request into a target data collection requirement of the target entity; and collecting target data from the target entity according to the target data collection requirement. This method can intelligently handle data requests of different formats and protocols, simplifying the data collection process and improving the flexibility and efficiency of data collection. It is particularly suitable for data collection in heterogeneous network environments, such as equipment from different vendors and different versions of software.
[0043] The data context interacts with a first entity and a second entity, where the first entity is an external intelligent application and the second entity (i.e., the aforementioned target entity) is a control system or transmission network. The data context has a data collection function, capable of collecting data from the second entity, including on-demand and periodic data acquisition. The data context module has a data processing function, used to map, transform, clean, store, compress, filter, and analyze the collected data. The data context has a data distribution function, used to distribute the processed data back to the first entity. The data context module interacts with the first and second entities through standardized authentication and authorization protocols and communication protocols, with the authentication and authorization mechanism ensuring secure data access. The data processing method supports the independent deployment of the data context or its residing on existing systems, and supports centralized or distributed deployment modes. Existing systems include ASON (Automatically Switched Optical Network), SDN, OSS, NMS, EMS, and NE (Network element) systems. The data context can realize the conversion of data resources and namespaces between different entities, including data mapping in one-to-one, one-to-many, many-to-one, or many-to-many data interaction scenarios.
[0044] In one embodiment, the data requested by the first entity and the data collected from the target entity have at least one of the following relationships: one-to-one, one-to-many, many-to-one, many-to-many, or a corresponding namespace. This design can handle complex data relationships, ensure data accuracy and consistency, and is suitable for scenarios requiring data sharing or correlation analysis, such as network fault location and business performance optimization.
[0045] Furthermore, collecting target data from the target entity based on the target data collection requirements includes at least one of the following: collecting target data from the data already acquired by the target entity; collecting target data through a collection interface; or collecting target data from the target entity configured by the system. This method can fully utilize existing data resources and supports both real-time data collection and system configuration data collection. It is suitable for scenarios requiring real-time monitoring and periodic auditing, such as network operations and maintenance, compliance checks, etc.
[0046] In one embodiment, the data acquisition interface includes at least one of the following: a component interface and a performance alarm acquisition interface. Through these interfaces, the data context can directly interact with network components and the performance monitoring system to collect the most original and accurate data. This is suitable for scenarios that require in-depth analysis of network component status and performance alarms, such as network fault prediction and performance bottleneck location.
[0047] In one embodiment, after step S204, the method further includes: processing the collected target data. Data processing ensures data quality and reduces the data processing burden on the first entity, making it suitable for scenarios with large data volumes and high processing complexity, such as big data analysis and artificial intelligence applications.
[0048] Furthermore, data processing of the collected target data may specifically include at least one of the following: data cleaning; format processing; storage; compression; filtering; and classification, association, and combination. These data processing steps can effectively improve data quality and usability, and are suitable for scenarios that require data preprocessing to meet specific analytical needs, such as network traffic analysis and user behavior analysis.
[0049] In one embodiment, the method further includes at least one of the following: authenticating the first entity; authorizing the first entity; negotiating capabilities with the first entity; and configuring capabilities for the first entity. These steps ensure the security of the data collection process, prevent unauthorized data access, and are suitable for scenarios requiring strict data security and privacy protection, such as data collection and analysis in industries like finance and healthcare.
[0050] Furthermore, capability negotiation or configuration with the first entity includes at least one of the following: communication protocol, accessible data resources, and namespace. These negotiations and configurations ensure the efficiency and accuracy of data collection and are suitable for scenarios requiring cross-system and cross-component data integration and analysis, such as resource management in multi-cloud environments and centralized monitoring of multi-vendor devices.
[0051] The data in this embodiment may specifically include at least one of the following: network resource information, topology, services, policies, configurations, performance, metrics, status, logs, alarms, and events; the data collection request may carry at least one of the following: the object of data collection, data type, data precision, and data collection frequency. This data collection and processing method can comprehensively cover various data types required for network management and monitoring, and is suitable for scenarios that require comprehensive and detailed monitoring of the network, such as network operation and maintenance, and security auditing.
[0052] This disclosure also provides a data processing method. Figure 3 is a flowchart of a data processing method according to an embodiment of this disclosure. As shown in Figure 3, the method is applied to a first entity and includes the following steps:
[0053] Step S302: Send a data collection request to the data context;
[0054] Step S304: Receive the target data collected by the data context according to the data collection request.
[0055] Through the above steps S302 to S304, the problem of how intelligent applications can achieve interaction with the existing transmission network and its management and control system can be solved. By using data context as an intermediary, efficient and secure data collection and processing can be achieved, which can significantly improve data processing efficiency.
[0056] In one embodiment, the method further includes: processing the target data; and configuring the target entity based on the processing result.
[0057] In one embodiment, the data context resides in a management component, an external application, or a management system; alternatively, the data context is a separate entity.
[0058] In one embodiment, there is a hierarchical or partitioned relationship among multiple data contexts residing on multiple management components, multiple external applications, or multiple management systems, wherein a data context resides on one management component, one external application, or one management system.
[0059] The data processing method provided in this disclosure, using data context as an intermediary, not only significantly improves the efficiency and security of data processing but also handles complex data relationships and heterogeneous network environments, making it valuable for large-scale network resource management and monitoring. Especially in the current context of digital transformation and network intelligence, this method provides robust data support for network operation and maintenance, fault prediction, performance optimization, and security auditing, making it a key technology for building intelligent networks and achieving refined management. Through intelligent processing of data context, the first entity can focus more on business logic and data analysis without needing to pay excessive attention to the details of data collection and processing, thereby achieving efficient resource utilization and rapid business response.
[0060] According to the embodiments of this disclosure, the data processing based on the control system is applied to the data context. Figure 4 is a schematic diagram of the structure of the data context according to the embodiments of this disclosure. As shown in Figure 4, it includes at least one of the following functions.
[0061] Data distribution (within the same management domain, no conversion required): Receive data collection requests from the first entity, such as: the object of data collection, data type, data precision, data collection frequency (periodic or on-demand), communication protocol, etc.
[0062] The collected data is returned to the first entity, including, for example, the object from which the data was collected, the data type, the corresponding data value, and the timestamp.
[0063] Data processing involves mapping and / or converting data into data for one or more target entities based on data collection requests.
[0064] Mapping can be a one-to-one, one-to-many, many-to-one, or many-to-many relationship.
[0065] Transformation: Namespace transformation between the first entity and the target entity.
[0066] Data processing collected from the target entity may include:
[0067] Data cleaning includes deduplication, filling in missing values, and handling outliers.
[0068] Formatting: Standardizing data to achieve a unified data format;
[0069] Storage: Storing data for further processing;
[0070] Compression: Reduce data transmission bandwidth by compressing data without affecting data integrity;
[0071] Filtering: Selecting necessary information based on data requests;
[0072] Analysis: Data can be classified, correlated, and combined to extract valuable information, such as root causes and trend predictions.
[0073] Data collection refers to the requested data or the data obtained from the target entity, which can include network resource information, configuration, performance, metrics, status, logs, alarms, events, etc.
[0074] Data can be collected from data already acquired by the target entity, such as RDB or data stored in memory. It can also be collected through data collection interfaces, such as component interfaces or performance alarm collection interfaces. The appropriate interface can be selected based on the timeliness and frequency requirements of the data request. Alternatively, data resources for the target entity can be allocated by the administrator.
[0075] Data context, authentication, authorization: user access permissions, maximum number of users allowed access, user groups (where users can be entities). Capability negotiation: communication protocol, accessible data resources, namespace.
[0076] Receive a data collection request from a first entity, convert it into a data collection request for a target entity, collect relevant data from the target entity according to the target data request, process the collected data (optionally), and return the collected / processed data to the first entity.
[0077] The first entity can further analyze and process the collected data before issuing configurations to the target entity. This entity can be a management component, an external application, or a management system.
[0078] The data context can function as an independent system, possessing all the aforementioned functionalities, or it can reside on an existing system, such as ASON / SDN / other MCS and NE, in which case it can leverage the functions of the existing system, such as authentication and capability negotiation, data collection, and data distribution.
[0079] The entity initiating the data request can be an external application, and the requested entity can be a control system or a transmission network. Figure 5 is a schematic diagram of data context deployment according to an embodiment of this disclosure. As shown in Figure 5, the entity initiating the data request can also be a control system or a transmission network, and the requested entity can be an external application. Figure 6 is a schematic diagram of data context deployment according to an embodiment of this disclosure. For the data context, both can be either the requester or the requested entity.
[0080] Figure 7 is a schematic diagram of data context deployment according to an embodiment of the present disclosure. As shown in Figure 7, the data context can reside on any existing system. If it is deployed in a distributed manner, the data context has the permissions and resources of the system it resides in, that is, there is a hierarchical relationship. If it is deployed in a centralized manner, it is similar to independent deployment and can interact with any system, application or component. Moreover, the functions of the data context can reuse the functions of the existing system, such as permission management, data collection, data distribution, etc.
[0081] The digital twin application collects management and control data to complete business survivability simulation and traffic prediction, as shown in Figure 6. The data context and the digital twin application and management and control system negotiate or are configured to interact with each other's capabilities, such as authentication and authorization, communication protocols, accessible data resources and namespaces, etc. (0). The digital twin application initiates a data collection request (1) to the data context for information such as the current network topology, service connection, resource configuration, and protection policy. The data is then sent to the data processing function (2) by the data distribution function. The data processing function maps / transforms the data collection request to the target management and control component (3), such as NCC, RC, CC, LRM, TAP or RDB, etc. The data collection function obtains the corresponding data from the management and control component (4) and sends it to the data processing function (5). The relevant data can be referred to Table 1. In particular, the data collection here can be from the data already obtained from the target system / component, such as RDB, data stored in memory, etc., or collected through the collection interface, such as the component interface, performance alarm collection interface, etc. The appropriate interface can be selected according to the timeliness and frequency requirements of the data. After the data processing function integrates this information, such as removing irrelevant information like FEF (Fault Event Filtering), and then classifying, associating, and combining the data objects requested by the data request (6), the data distribution function returns it to the digital twin application (7). The digital twin application can use this data to simulate fault points in the service connection, trigger protection / recovery, complete the service survivability simulation, and then adjust the network configuration (8). It can also use this data to obtain the network load status, predict traffic trends, further optimize existing network resources, and then adjust the network configuration (8).
[0082] As shown in Figure 1, in ASON, when the NCC receives a connection establishment request (1), the Boundary Resource Identifier (BRI) in the request is converted by the DS (2) and consists of two SNP identifiers within the controller. The connection establishment request may also carry some or all of the connection's routing information. The NCC sends the first and last SNP identifiers to the CC (3), and the CC requests the RC to query the connection route between the first and last SNPs (4). The RC calculates the path that satisfies the CC's request based on the topology and local connection status information (5) provided by the LRM. If the CC request carries the connection's routing information, then the connection's routing information can also participate in the RC's route query. The RC returns the routing information to the CC, and the CC requests the LRM (6) to select an appropriate link connection from the links traversed by the route. The LRM configures the forwarding resource usage status to the forwarding plane through the TAP component.
[0083] Figure 8 is a schematic diagram of the components in an n+1 layer SDN according to an embodiment of the present disclosure, and Figure 9 is a schematic diagram of the components in an n-layer SDN according to an embodiment of the present disclosure. As shown in Figures 8 and 9, when the NCC in the client context CC of the n+1 layer controller receives a call request, the request is mapped to the controller n+1 namespace and passed to the CC. The CC sends a routing query request to the RC. The RC calculates the path within the topology and resources (provided by the LRM) of the requested client context, and the path includes the SNPP and SNP link connections of the relevant service context (SC). Then, the CC returns the path to the NCC, and the NCC in the client context CC sends a call request to the NCC in the relevant service context SC to establish a connection in the corresponding service layer (n-layer) controller. That is, the NCC in the service context of the n+1 layer controller sends the call request to the NCC in each controller of the n-layer controller respectively. The process of establishing a connection between the n-layer controllers is the same as in Figure 1, except that the NCC and DS are in the client context, and the TAP is in the service context. Interoperability between controllers: NCCs interact with each other.
[0084] Table 1
[0085] The data context and digital twin application, transport network, and management system negotiate or are configured to interact with each other, such as authentication and authorization, communication protocols, accessible data resources and namespaces (0). The digital twin application initiates a data collection request to the data context for optical layer data, such as: fiber information, status information of optical transceivers, amplifiers, filters and their performance alarms and network topology information (1), which is sent to the data processing function by the data distribution function (2). The data processing function maps / converts the data collection request to the target management system or transport network (3), such as: OSS, NMS, EMS or NE, etc., and obtains the corresponding data from the target management system or transport network through the data collection function (4) and sends it to the data processing function (5). The relevant data can be referred to Table 2. In particular, the data collection here can be from the data already obtained from the target system / component, such as RDB, data stored in memory, etc., or collected through the collection interface, such as component interface, performance alarm collection interface, etc. The appropriate interface can be selected according to the timeliness and frequency requirements of the data. After the data processing function integrates this information, such as filtering out the necessary information of the optical layer, and then classifying, associating and combining the data objects according to the data request (6), the data distribution function returns it to the digital twin application (7). The digital twin application can use this data to complete the simulation and evaluation of the filtering cost, and can also use this data to evaluate the optical signal-to-noise ratio (OSNR) of the backup link, simulate the service level agreement (SLA) characteristics of the service, and then recalculate the path for the physical network or request (8).
[0086] Table 2
[0087] The data context negotiates or is configured to interact with AI / ML applications, transmission networks, and management systems, including capabilities such as authentication and authorization, communication protocols, accessible data resources, and namespaces (0). The AI / ML application initiates a data collection request (1) to the data context regarding network topology, service connections, performance alarms, and other information. The data distribution function then sends the request to the data processing function (2). The data processing function maps / transforms the data collection request to the target management system or transmission network (3), such as ASON / SDN / other MCS (Management and Control System) or NE. The data collection function obtains the corresponding data from the target management system or transmission network (4) and sends it to the data processing function (5). The relevant data can be found in Tables 1 and 2. In particular, the data collection here can be from data already obtained from the target system / component, such as RDB, data stored in memory, etc., or collected through collection interfaces, such as component interfaces, performance alarm collection interfaces, etc. The appropriate interface can be selected based on the timeliness and frequency requirements of the data. After the data processing function integrates this information, such as filtering out the necessary information of the optical layer, and then classifying, associating and combining the data objects according to the data request (6), the data distribution function returns it to the AI / ML application (7). The AI / ML application can use this data to perform fault association and location, such as fault delimitation and location and the affected business, thereby initiating a modification configuration of the control system (8).
[0088] As shown in Figure 7, the data context is assigned the data resources for this management by the administrator of the management system. For example, an n+1 layer SDN can have the data resources of two n layer SDNs. The management system where the data context resides negotiates or is configured to interact with external applications on related capabilities, such as authentication and authorization, communication protocols, accessible data resources, and namespaces (1). When an external application initiates a data collection request to the data context regarding information such as the current network topology, service connections, resource configuration, and protection policies (2), the data context completes data resource mapping and namespace conversion based on the negotiated information and data request from the external application (3) and returns it to the external application (4). The external application can use this data to perform simulation verification of services and then adjust the network configuration (5).
[0089] The data context handles the association and combination of data, while the data collection context determines whether the collected data is standardized or vendor-specific. If the data is vendor-specific, the data collection context cannot perform any semantic understanding of the data and therefore cannot process it; it can only collect and distribute the data. If the data is standardized, the data processing function can associate and combine the data. For example, if a high-level controller has an abstract topology, the data context needs to associate the high-level abstract topology information with (detailed) topology fragments of multiple low-level controllers.
[0090] The terminal data context mapping relationship completed in this embodiment includes:
[0091] One-to-one: This means that the requested data is the target data of the target entity.
[0092] One-to-many: The external application abstracts data to multiple specific network data. For example, an AI / ML / data analysis application requests the root cause of a fault on a certain network. The data context needs to collect relevant data on that network, and its data processing function needs to perform data cleaning, classification, combination, association, etc., to obtain the root cause and its associated data and return it to the data analysis application. The requesting entity is relatively abstract, while the requested entity is relatively specific. In the case of a network fault, the external application sends a request.
[0093] Many-to-one: When multiple external applications access the same network data, such as AI / ML / data analysis applications that require network topology, service connections, performance alarms, and resource configurations, the data processing function in the data context needs to store this data and share it with multiple external applications.
[0094] Many-to-many: This can be a combination of the above scenarios, such as re-dividing multiple virtual network resources on multiple network resources for different applications. When an external application requests network data resources, the data context needs to understand its mapping relationship, collect the corresponding network resource information, and convert the data into the corresponding virtual network resources after data processing.
[0095] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this disclosure.
[0096] According to one embodiment of this disclosure, a data processing apparatus is provided for implementing the above embodiments and preferred embodiments, the details of which will not be repeated hereafter. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0097] Figure 10 is a block diagram of a data processing apparatus according to an embodiment of the present disclosure. As shown in Figure 10, the apparatus is applied to a data context and includes:
[0098] The first receiving module 1002 is configured to receive data collection requests from the first entity;
[0099] Collection module 1004 is configured to collect data according to the data collection request;
[0100] The return module 1006 is configured to return the data to the first entity.
[0101] According to another embodiment of the present disclosure, a data processing apparatus is provided. FIG11 is a block diagram of a data processing apparatus according to an embodiment of the present disclosure. As shown in FIG11, the apparatus is applied to a first entity and includes:
[0102] Sending module 112 is configured to send a data collection request to the data context;
[0103] The second receiving module 114 is configured to receive target data collected by the data context according to the data collection request.
[0104] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.
[0105] Embodiments of this disclosure also provide a computer-readable storage medium storing a computer program configured to perform the steps in any of the above method embodiments when executed.
[0106] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.
[0107] Embodiments of this disclosure also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.
[0108] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.
[0109] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.
[0110] It is obvious to those skilled in the art that the modules or steps of this disclosure described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this disclosure is not limited to any particular combination of hardware and software.
[0111] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this disclosure should be included within the scope of protection of this disclosure.
Claims
1. A data processing method, applied to a data context, comprising: Receive data collection request from the first entity; Collect target data according to the data collection request; The target data is returned to the first entity.
2. The method according to claim 1, wherein, The target data collected according to the data collection request includes: Map and / or convert the data collection request into the target data collection requirements of the target entity; Collect the target data from the target entity according to the target data collection requirements.
3. The method according to claim 2, wherein, The data requested by the first entity and the target data collected from the target entity have at least one of the following relationships: one-to-one relationship, one-to-many relationship, many-to-one relationship, many-to-many relationship, or a corresponding relationship between namespaces.
4. The method according to claim 2, wherein, Collecting the target data from the target entity according to the target data collection requirements includes at least one of the following: Collect the target data from the data already acquired from the target entity; The target data is collected through the acquisition interface; The target data of the target entity configured by the system.
5. The method according to claim 4, wherein, The data acquisition interface includes at least one of the following: a component interface and a performance alarm acquisition interface.
6. The method according to claim 1, wherein, After collecting the target data according to the data collection request, or before returning the target data to the first entity, the method further includes: The collected target data is then processed.
7. The method according to claim 6, wherein, Data processing of the collected target data includes at least one of the following: Perform data cleaning on the target data; The target data is formatted. The target data is stored; The target data is compressed; Filter the target data; The target data is then classified, associated, and combined.
8. The method according to claim 1, wherein, The method further includes at least one of the following: Authenticate the first entity; Authorize the first entity; Negotiate capabilities with the first entity; Configure the capabilities of the first entity.
9. The method according to claim 8, wherein, Capability negotiation or configuration with the first entity includes at least one of the following: Communication protocols, accessible data resources, and namespaces.
10. The method according to claim 1, wherein, The data includes at least one of the following: network resource information, topology, services, policies, configuration, performance, metrics, status, logs, alarms, and events; The data collection request includes at least one of the following: the object of data collection, the data type, the data precision, and the data collection frequency.
11. A data processing method applied to a first entity, comprising: Send a data collection request to the data context; Receive the target data collected by the data context according to the data collection request.
12. The method according to claim 11, wherein, Also includes: The target data is processed; Configure the target entity based on the processing results.
13. The method according to claim 11, wherein, The data context resides in the management component, external application, or management system; or... The data context is an independent entity.
14. The method according to claim 13, wherein, There are hierarchical or partitioned relationships among multiple data contexts residing on multiple management components, multiple external applications, or multiple management systems, wherein a data context resides on one management component, one external application, and / or one management system.
15. A computer-readable storage medium storing a computer program, wherein, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1 to 10, or the steps of the method described in any one of claims 11 to 14.
16. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the method according to any one of claims 1 to 10, or implements the steps of the method according to any one of claims 11 to 14.
17. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 10, or implements the steps of the method according to any one of claims 11 to 14.
Citation Information
Patent Citations
Data processing method and device
CN112491574A
Data processing method and device, electronic equipment and storage medium
CN118363995A
Network management method, electronic equipment and computer readable storage medium
CN119520301A
Application service processing method and apparatus
WO2024108600A1