Data processing method, computer readable storage medium, electronic device and computer program product
By using data context as an intermediary, data collection requests are received and sent, solving the problem of intelligent application interaction in transmission networks and their management and control systems. This enables efficient and secure data collection and processing, and is suitable for large-scale network resource management and monitoring.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ZTE CORP
- Filing Date
- 2024-10-29
- Publication Date
- 2026-05-01
AI Technical Summary
There is no effective solution yet for how to achieve interaction in the intelligent application of existing transmission networks and their management and control systems, and traditional operation and maintenance methods are difficult to support efficient management and control.
By using data context as an intermediary, data collection requests are received and sent, target data is collected and processed, and efficient and secure data collection and processing are achieved.
It significantly improves data processing efficiency and is suitable for large-scale network resource management and monitoring, especially in cross-system and cross-component data integration and analysis scenarios, enhancing the flexibility and security of data processing.
Smart Images

Figure CN121967149A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communications, and more specifically, to a data processing method, a computer-readable storage medium, an electronic device, and a computer program product. Background Technology
[0002] The transport network is the infrastructure of communication networks and the foundation supporting the digital transformation of various industries. Users have higher requirements for the performance and reliability of the transport network. As the scale of transport network applications continues to grow, the operation and maintenance of the transport network throughout its entire lifecycle becomes increasingly complex. Traditional operation and maintenance methods can no longer adapt to the scale of business growth and are difficult to support efficient management and control. Therefore, the transport network needs to develop in the direction of intelligent networks throughout its entire lifecycle. Intelligent applications are a good supplement to realizing intelligent networks, including digital twin applications, AI / ML (Artificial Intelligence / Machine Learning) applications, and data analysis applications. However, how intelligent applications can achieve interaction with the existing transport network and its management and control system has not yet been proposed.
[0003] Application content
[0004] This application provides a data processing method, a computer-readable storage medium, an electronic device, and a computer program product to at least address the problem of how intelligent applications in the related art can achieve interaction with existing transmission networks and their management and control systems.
[0005] According to one embodiment of this application, a data processing method is provided, applied to a data context, comprising: receiving a data collection request from a first entity; collecting target data according to the data collection request; and returning the target data to the first entity.
[0006] According to another embodiment of this application, a data processing method is provided, applied to a first entity, comprising: sending a data collection request to the data context; and receiving target data collected by the data context according to the data collection request.
[0007] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.
[0008] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.
[0009] According to yet another embodiment of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.
[0010] Through the embodiments described above in this application, the data context receives a data collection request from a first entity; collects target data according to the data collection request; and returns the target data to the first entity. Therefore, it can solve the problem of how intelligent applications can achieve interaction with existing transmission networks and their management systems. By using the data context as an intermediary, efficient and secure data collection and processing can be achieved, significantly improving data processing efficiency. Attached Figure Description
[0011] Figure 1 This is a schematic diagram of the connection scheduling of the control system in related technologies;
[0012] Figure 2 This is a flowchart of the data processing method according to the embodiments of this application. Figure 1 ;
[0013] Figure 3 This is a flowchart of the data processing method according to the embodiments of this application. Figure 2 ;
[0014] Figure 4 This is a schematic diagram of the data context structure according to an embodiment of this application;
[0015] Figure 5 This is a schematic diagram of data context deployment according to embodiments of this application. Figure 1 ;
[0016] Figure 6 This is a schematic diagram of data context deployment according to embodiments of this application. Figure 2 ;
[0017] Figure 7 This is a schematic diagram of data context deployment according to embodiments of this application. Figure 3 ;
[0018] Figure 8 This is a schematic diagram of components in an n+1 layer SDN according to an embodiment of this application;
[0019] Figure 9 This is a schematic diagram of components in an n-layer SDN according to an embodiment of this application;
[0020] Figure 10 This is a block diagram of a data processing apparatus according to embodiments of this application. Figure 1 ;
[0021] Figure 11 This is a block diagram of a data processing apparatus according to embodiments of this application. Figure 2 . Detailed Implementation
[0022] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.
[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.
[0024] 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.
[0025] Figure 1 This is a schematic diagram of the connection scheduling of the control system in related technologies, such as... Figure 1 As shown, 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.
[0026] The link topology and resource usage information in the controller are stored in the Resource Database (RDB).
[0027] 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.
[0028] A group of SNPs grouped together is represented as an SNPP (SubNetworkPoint 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.
[0029] For components where the controller directly controls the interaction of transmitted resources, such as Figure 1 As shown, in the controller, when the NCC receives the connection establishment request (1), the Boundary Resource Identifier (BRI) in the request is converted by DS (2) to two SNP identifiers within this 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). 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. 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] This embodiment provides a method for running on the aforementioned network management system. Figure 2 This is a flowchart of the data processing method according to the embodiments of this application. Figure 1 ,like Figure 2As shown, applied to the data context, this process includes the following steps:
[0034] Step S202: Receive a data collection request from the first entity;
[0035] Step S204: Collect target data according to the data collection request;
[0036] Step S206: Return the target data to the first entity.
[0037] 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.
[0038] The embodiments of this application can achieve 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, when cross-system and cross-component data integration and analysis are required, it can significantly improve data processing efficiency.
[0039] 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.
[0040] 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.
[0041] In this embodiment, step S204 may specifically include: mapping and / or converting the data collection request into the 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.
[0042] 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 independent deployment or resides 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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 requiring comprehensive and detailed network monitoring, such as network operation and maintenance, and security auditing.
[0051] This application also provides a data processing method. Figure 3 This is a flowchart of the data processing method according to the embodiments of this application. Figure 2 ,like Figure 3 As shown, applied to the first entity, the process includes the following steps:
[0052] Step S302: Send a data collection request to the data context;
[0053] Step S304: Receive the target data collected by the data context according to the data collection request.
[0054] 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.
[0055] In one embodiment, the method further includes: processing the target data; and configuring the target entity based on the processing result.
[0056] 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.
[0057] 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.
[0058] The data processing method provided in this application, 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.
[0059] In this embodiment, data processing based on the control system is applied to the data context. Figure 4 This is a schematic diagram of the data context structure according to an embodiment of this application, such as... Figure 4 As shown, it includes at least one of the following functions.
[0060] 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.
[0061] 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.
[0062] Data processing involves mapping and / or converting data into data for one or more target entities based on data collection requests.
[0063] Mapping can be a one-to-one, one-to-many, many-to-one, or many-to-many relationship.
[0064] Transformation: Namespace transformation between the first entity and the target entity.
[0065] Data processing collected from the target entity may include:
[0066] Data cleaning includes deduplication, filling in missing values, and handling outliers.
[0067] Formatting: Standardizing data to achieve a unified data format;
[0068] Storage: Storing data for further processing;
[0069] Compression: Reduce data transmission bandwidth by compressing data without affecting data integrity;
[0070] Filtering: Selecting necessary information based on data requests;
[0071] Analysis: Data can be classified, correlated, and combined to extract valuable information, such as root causes and trend predictions.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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.
[0076] 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.
[0077] 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.
[0078] The entity initiating the data request can be an external application, and the entity being requested can be a control system or a transmission network. Figure 5 This is a schematic diagram of data context deployment according to embodiments of this application. Figure 1 ,like Figure 5 As shown, the entity initiating the data request can be a control system or a transmission network, while the requested entity can be an external application. Figure 6 This is a schematic diagram of data context deployment according to embodiments of this application. Figure 2 ,like Figure 6 As shown. In the context of data, both can be either the requester or the requested party.
[0079] Figure 7 This is a schematic diagram of data context deployment according to embodiments of this application. Figure 3 ,like Figure 7 As shown, a data context can reside on any existing system. If deployed in a distributed manner, the data context has the permissions and resources of the system it resides in, i.e., there is a hierarchical relationship. If deployed in a centralized manner, it is similar to an independent deployment and can interact with any system, application, or component. Moreover, the functions of the data context can reuse the functions of existing systems, such as permission management, data collection, and data distribution.
[0080] Digital twin applications collect and manage data to perform business survivability simulations and traffic predictions, such as... Figure 6As shown, the data context and digital twin application, 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 (1) to the data context regarding the current network topology, service connections, resource configuration, protection policies and other information. The data distribution function sends the request to the data processing function (2). The data processing function maps / transforms the data collection request to the target management component (3), such as NCC, RC, CC, LRM, TAP or RDB. The data collection function obtains the corresponding data from the management 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).
[0081] like Figure 1 As shown, 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 becomes two SNP identifiers within this controller. It is also possible that the connection establishment request carries 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.
[0082] Figure 8 This is a schematic diagram of components in the n+1 layer SDN according to an embodiment of this application. Figure 9 This is a schematic diagram of components in an n-layer SDN according to an embodiment of this application, such as... Figure 8 and 9As shown, 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's 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 requested client context's topology and resources (provided by the LRM), including 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 NCCs in the service context of the n+1 layer controller send call requests to the NCCs in the respective controllers of the n layer, and the connection establishment process of the n layer controllers... Figure 1 They are the same, except that NCC and DS are marked in the client context, while TAP is in the service context. Interoperability between controllers involves NCC interactions.
[0083] Table 1
[0084]
[0085]
[0086] 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).
[0087] Table 2
[0088]
[0089]
[0090]
[0091] 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).
[0092] like Figure 7 As shown, the data context is assigned the data resources under its 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 before adjusting the network configuration (5).
[0093] 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.
[0094] The terminal data context mapping relationship completed in this application embodiment includes:
[0095] One-to-one: This means that the requested data is the target data of the target entity.
[0096] 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.
[0097] 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.
[0098] 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.
[0099] 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 application, 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 application.
[0100] According to one embodiment of this application, 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 implements 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.
[0101] Figure 10 This is a block diagram of a data processing apparatus according to embodiments of this application. Figure 1 ,like Figure 10 As shown, it applies to the data context and includes:
[0102] The first receiving module 1002 is used to receive a data collection request from the first entity;
[0103] Collection module 1004 is used to collect data according to the data collection request;
[0104] The return module 1006 is used to return the data to the first entity.
[0105] According to another embodiment of this application, a data processing apparatus is provided. Figure 11 This is a block diagram of a data processing apparatus according to embodiments of this application. Figure 2 ,like Figure 11 As shown, it is applied to the first entity and includes:
[0106] Sending module 112 is used to send a data collection request to the data context;
[0107] The second receiving module 114 is used to receive the target data collected by the data context according to the data collection request.
[0108] 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.
[0109] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.
[0110] 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.
[0111] Embodiments of this application also provide an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.
[0112] 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.
[0113] 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.
[0114] Obviously, those skilled in the art should understand that the modules or steps of this application 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 here, 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 application is not limited to any particular combination of hardware and software.
[0115] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.
Claims
1. A data processing method, characterized in that, Applied to the data context, including: 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, characterized in that, 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, characterized in that, 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, characterized in that, 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, characterized in that, 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, characterized in that, 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, characterized in that, 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, characterized in that, 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, characterized in that, 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, characterized in that, 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, characterized in that, Applied to the first entity, including: 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, characterized in that, Also includes: The target data is processed; Configure the target entity based on the processing results.
13. The method according to claim 11, characterized in that, 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, characterized in that, 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, characterized in that, The computer-readable storage medium stores 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 implements 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, characterized in that, When the processor executes the computer program, 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.
17. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the steps of the method described in any one of claims 1 to 10, or implements the steps of the method described in any one of claims 11 to 14.