Model-driven network resource service design method and system

Abstract

This invention discloses a model-driven network resource service design method, comprising: defining basic information of objects involved in the network resource service; defining topological relationships between objects involved in the network resource service; defining lifecycle events involved in the network resource service; defining APIs of objects involved in the network resource service; and defining the orchestration and control of APIs of objects involved in the network resource service based on topological relationships between objects and lifecycle events involved in the network resource service, thereby forming a network resource service model. This invention, by opening up basic network resource capabilities, constructs an integrated layered and decoupled capability object model, leveraging the flexibility and agility of a layered service architecture to achieve efficient reuse and flattened management of capabilities at each layer, thereby enabling visualized and flexible allocation of network resources and improving network resource allocation efficiency.

Description

Technical Field

[0001] This invention relates to the field of network resource management technology. More specifically, this invention relates to a model-driven network resource service design method and system. Background Technology

[0002] Currently, network and resource service management methods typically rely on traditional interface models and follow fixed business logic and processes to allocate and manage network resources, thereby enabling the deployment of different products and services. However, existing technologies cannot meet the flexible configuration requirements of network resource services when supporting network reconstruction, cloud-network convergence, and other network services. Network resources must be allocated according to predetermined business strategies, and data is scattered and silos exist between different domains, making it impossible to associate and reuse data, thus reducing the efficiency of network resource allocation and network product deployment. Summary of the Invention

[0003] One object of the present invention is to solve at least the above-mentioned problems and to provide at least the advantages that will be described later.

[0004] Another objective of this invention is to provide a model-driven network resource service design method and system. By opening up the basic capabilities of network resources, it enables layered design of business rules, including modeling various objects and relationships that make up the business, formulating policy rules to guide business behavior, and formulating the applications, analysis, and closed-loop events required for flexible business management. This allows for the visualized and flexible design and allocation of network resources, solving the problem of a single and passive network resource allocation mode and meeting the needs of cross-domain businesses.

[0005] To achieve these objectives and other advantages according to the present invention, a model-driven network resource service design method is provided, comprising:

[0006] Define the basic information of the objects involved in network resource services;

[0007] Define the topological relationships between objects involved in network resource services;

[0008] Define the lifecycle events involved in network resource services;

[0009] Define the APIs for the objects involved in network resource services;

[0010] Based on the topological relationships between objects involved in network resource services and the lifecycle events involved in network resource services, the orchestration and control of the APIs of objects involved in network resource services are defined to form a network resource service model.

[0011] Define the data processing strategy for the network resource service model during runtime;

[0012] Based on the parameters in the network resource service model, performance indicators for network resource services are defined.

[0013] Preferably, the objects involved in the network resource service are divided into business services, network services, and resource capabilities. The business services are assembled from network services, and the network services are assembled from resource capabilities. The basic information of the objects includes object name, code, event, description, version, status, and directory. The basic information of the objects involved in the network resource service is defined to support adding, deleting, updating, querying, and changing the status of objects in a directory tree manner.

[0014] Preferably, the basic information of the objects involved in the network resource service is defined by assigning values ​​to the basic information through specification mapping, attribute mapping, and dictionary value mapping.

[0015] Preferably, defining the topological relationships between objects involved in network resource services includes: defining object composition relationship information and object topology information, wherein the object composition relationship information is used to describe the composition relationship between upper-level objects and lower-level objects, and the object topology information is used to describe the association relationship between one upper-level object and multiple lower-level objects; and automatically generating a topology mapping based on the object composition relationship information and object topology information.

[0016] Preferably, the lifecycle events involved in network resource services include operational production events and network operation and maintenance management events.

[0017] Preferably, defining the APIs of objects involved in network resource services includes defining the name, code, time, status, description, and parameters of the APIs of objects involved in network resource services, and supporting operations such as adding, deleting, updating, querying, and changing the status of the object's API.

[0018] Preferably, based on the topological relationships between objects involved in the network resource service and the lifecycle events involved in the network resource service, the orchestration and control of the APIs of the objects involved in the network resource service are defined, including: defining the process template information of the API, selecting the lower-level objects and their APIs in the topological relationship between objects, defining the relationship between the lower-level object APIs, forming a process template; and defining the instructions for calling the lowest-level object.

[0019] Preferably, the data processing strategy for the network resource service model runtime is defined by defining object strategy, process strategy, API strategy and exception strategy; the data processing strategy for the network resource service model runtime is defined using the Groovy rule language.

[0020] Preferably, the performance indicators of network resource services include KPI, KOI, and QQE.

[0021] This invention also provides a model-driven network resource service design system, comprising:

[0022] The object definition module is used to define the basic information of the objects involved in network resource services;

[0023] The object topology definition module is used to define the topological relationships between objects involved in network resource services;

[0024] The event definition module is used to define the lifecycle events involved in network resource services;

[0025] The API definition module is used to define the APIs of objects involved in network resource services;

[0026] The API implementation definition module is used to define the orchestration and control of the APIs of the objects involved in the network resource service based on the topological relationships between the objects involved in the network resource service and the lifecycle events involved in the network resource service, so as to form a network resource service model.

[0027] The strategy definition module is used to define the data processing strategy for the network resource service model during runtime;

[0028] The indicator definition module is used to define performance indicators of network resource services based on parameters in the network resource service model.

[0029] This invention offers at least the following beneficial effects: By leveraging open network resource capabilities, it employs a layered design for business rules. This includes modeling the various objects and relationships that constitute the business, formulating policy rules to guide business behavior, and defining the applications, analyses, and closed-loop events required for flexible business management. This enables visualized and flexible design and allocation of network resources, addressing the problem of a single, passive network resource allocation model and meeting the needs of cross-domain businesses. Furthermore, by designing and outputting standardized configuration packages for automated network and resource configuration, it improves the deployment efficiency and reliability of different network products.

[0030] Other advantages, objectives and features of the present invention will become apparent in part from the following description, and in part from those skilled in the art through study and practice of the invention. Attached Figure Description

[0031] Figure 1 This is a flowchart of the model-driven network resource service design method described in an embodiment of the present invention;

[0032] Figure 2 This is a schematic diagram of the structure of the model-driven network resource service design system described in an embodiment of the present invention. Detailed Implementation

[0033] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0034] See Figure 1 This invention provides a model-driven network resource service design method, which includes:

[0035] S101. Define the basic information of the objects involved in network resource services;

[0036] In this step, the objects involved in the network resource service are divided into business services, network services, and resource capabilities. The business services are assembled from network services, and the network services are assembled from resource capabilities.

[0037] Specifically, business services refer to end-to-end network communication capabilities, including point-to-point and point-to-network capabilities. Points can be users, clouds, devices, platforms, etc., and networks can be SDN, VPN, and the Internet, etc. Network services refer to providing network communication capabilities for communication networks, including network services such as 5G core networks and metropolitan area networks. Resource capabilities refer to the classification of physical resources (network equipment, lines), logical resources (IP, ports), network elements, and other entities involved in the network.

[0038] The basic information of an object includes object name, code, event, description, version, status, and directory. The basic information of objects involved in network resource services is defined, and the system supports adding, deleting, updating, querying, and changing the status of objects in a directory tree manner.

[0039] The basic information of objects involved in network resource services is defined using specification mapping, attribute mapping, and dictionary value mapping to assign values ​​to this basic information. Specification mapping describes the mapping relationship between business service objects and product service specifications defined in metadata, network service objects and product service specifications defined in metadata, and resource capability objects and resource specifications. Attribute mapping describes the attributes of business service objects, network service objects, and resource capability objects, and allows for operations such as adding, deleting, updating, and querying. Dictionary value mapping describes and defines the value range of attributes; after an attribute is selected, it is retrieved by calling the dictionary value query API provided by the metadata, based on the attribute specification.

[0040] S102. Define the topological relationships between objects involved in network resource services;

[0041] In this step, defining the topological relationships between objects involved in network resource services includes: defining object composition relationship information and object topology information. The object composition relationship information is used to describe the composition relationship between upper-level objects and lower-level objects, and the object topology information is used to describe the association relationship between one upper-level object and multiple lower-level objects; and automatically generating a topology mapping based on the object composition relationship information and object topology information.

[0042] The system defines the topological relationships between objects involved in network resource services, supporting the addition, deletion, modification, and querying of relationships among business services, network services, and resource capabilities within the topology. By selecting the network service relationships that a business service needs to include, a business service object topology is formed; network service and resource capability object topologies can be derived downwards in this manner. The object composition relationship information describes the compositional relationships between upper-level and lower-level objects, specifically including information such as the object, included objects, included object types, status, and creation time. The object topology information describes the association between a higher-level object and multiple lower-level objects, specifically including information such as the object, status, and creation time. Based on the object composition relationship information and object topology information, a topology mapping is automatically generated, and the SR object topology diagram can be used to describe and display the relationships between business service objects, network service objects, and resource capability objects.

[0043] S103. Define the lifecycle events involved in network resource services;

[0044] In this step, the lifecycle events involved in network resource services include operational production events and network operation and maintenance management events.

[0045] S104. Define the APIs for the objects involved in network resource services;

[0046] In this step, defining the API of the objects involved in the network resource service refers to defining the standardized capability interface provided to the outside world, which is the capability formed by the operation corresponding to the object.

[0047] Defining the APIs of objects involved in network resource services includes defining the name, code, time, status, description, and parameters of the APIs of objects involved in network resource services, and supporting operations such as adding, deleting, updating, querying, and changing the status of the APIs of objects.

[0048] For example, input / output parameter design defines the input data required during API implementation and the output results after execution. Based on the URI, APIs can be divided into normal, abnormal, redo, and test URIs.

[0049] In addition, API definitions can maintain logs, security, and performance information, such as monitoring events, time consumption, and call address information that occur during API calls, as well as end-to-end data protection and performance metrics such as response time and concurrency.

[0050] When defining an API, a service directory can be used. This service directory, defined by the cloud network service design center, is used to manage services and facilitates quick location of the service hosting the API. The service directory describes the hierarchical relationship of services, allowing users to categorize services by type and create different directory levels.

[0051] S105. Based on the topological relationships between objects involved in network resource services and the lifecycle events involved in network resource services, define the orchestration and control of the APIs of objects involved in network resource services to form a network resource service model.

[0052] This step first defines the API's workflow template information, selects the lower-level objects and their APIs configured in the object topology, defines the relationships between the APIs, and forms the workflow template. The API implementation design supports adding, deleting, modifying, and querying workflow templates, and allows configuring API parameter strategies, exception rollback, and exception handling methods on API nodes. After configuring the workflow template, synchronization and dependency strategies can be configured for two API nodes within the same workflow template or between different workflow templates.

[0053] The synchronization strategy means that synchronization nodes must be generated together. When process A in the group flows to the synchronization node, but process B in the group has not yet flowed to the synchronization node, process A will pause its flow and wait for process B to flow to the synchronization node before the synchronization node is generated together.

[0054] Dependency strategies mean that dependent activity instances are only generated when the dependent activity instance is completed. For example, if process A in a group depends on process B, then process A's dependent activity instance can only be generated when the dependent activity instance of process B is completed. This supports collaborative scheduling between process instances, including scheduling one process instance after another is completed, allowing multiple process instances to arrive at a stage simultaneously before processing that stage, allowing another process instance to execute a specified stage only after a stage of one process instance is completed, and allowing multiple process instances to proceed to the next stage only after all stages of a stage are completed, such as setting up associated waiting periods during the installation stage of ordinary telephone or ADSL installation services.

[0055] Secondly, define the instructions that call the lowest-level object. Control design is used to implement the logical design of resource capabilities to device instructions, specifically divided into real instruction design and virtual instruction design. Real instruction design refers to the specific instruction definitions for each equipment manufacturer and model, while virtual instructions are mapped from real instructions and can be customized for logic processing.

[0056] S106. Define the data processing strategy for the network resource service model during runtime;

[0057] In this step, the data processing strategy for the network resource service model runtime is defined, including: defining object strategy, process strategy, API strategy, and exception strategy; the definition of the data processing strategy for the network resource service model runtime is implemented using the Groovy rule language.

[0058] Object strategies describe the coordination strategies for business services, network services, and resource capability objects. These are categorized as synchronization and dependency. Synchronized objects must be generated together; during the execution of an object service, synchronized objects must either start or finish simultaneously. Dependent object instances are only generated when the instance they depend on completes.

[0059] The process strategy supports custom process adaptation strategies for different process templates. Process adaptation rules allow defining information attributes for the rules themselves, and can adapt to different flow methods such as serial flow, parallel flow, self-looping flow, and conditional selection flow, depending on the flow method. Serial flow: If there are dependencies between two or more stages, the next stage cannot be executed until the previous stage is completed. Parallel flow: After one stage ends, multiple stages are generated simultaneously. The process waits for all branches to arrive at the aggregation node, and only after all branches have completed execution is the subsequent activity activated and execution continued. Self-looping flow: The process can flow back to its own state to repeatedly execute a task. Conditional selection flow: The activity has multiple paths to choose from, each with certain conditional judgments, and the process can select the path that meets the conditions for flow.

[0060] API strategies primarily implement strategy definitions during the API definition process, such as converting, merging, and splitting API input and output parameters.

[0061] Anomaly strategies refer to configuring automatic handling mechanisms to quickly resolve the impact of anomalies. By designing unified anomaly handling strategies, running nodes can respond to anomalies according to the strategies. Specifically, these strategies include: interface anomaly strategies, data anomaly strategies, business anomaly strategies, and anomaly parsing strategies.

[0062] Policy triggering conditions are divided into time-triggered and wait-triggered. Time-triggered means that a specific event is triggered at a specified time, and different time types can be defined. Wait-triggered means that when the system is instantiated, the node is in a standby state, waiting for a certain instruction or event to activate and dispatch subsequent operations.

[0063] The strategy algorithm is uniformly implemented using the Groovy rule-based language. Groovy is an agile, dynamic language for the Java Virtual Machine, built on top of Java. It is a mature object-oriented programming language that can be used for both object-oriented programming and pure scripting. Using this language requires less code writing while possessing the other features and excellent performance of dynamic languages.

[0064] Specifically, policy configuration examples are shown in Table 1 below:

[0065] Table 1

[0066]

[0067] S107. Define the performance indicators of network resource services based on the parameters in the network resource service model.

[0068] In this step, the performance metrics for network resource services include KPIs, KOIs, and QQEs. KPIs represent service quality performance data indicators, specifically KQIs (Key Quality Indicators). KQIs represent the performance of a product or product unit. These KQI metrics are calculated using multiple different KPIs. The most basic function of KQI is to calculate the degree to which actual service quality meets the SLA contract. QOE refers to Customer Experience, a quantifiable metric that measures the actual quality perceived by customers, excluding their expectations. KPIs and QOEs can be obtained through data services or data subscriptions provided by the data interaction platform, or through file services provided by the data delivery platform. When designing the metric calculation algorithms, metrics existing in relational databases require SQL-based algorithm design; metrics existing in offline databases require algorithms designed using Spark or similar methods; and for complex metric calculations, script-based algorithm design is required.

[0069] In the above embodiments, by opening up basic network resource capabilities, an integrated layered and decoupled capability object model is constructed. This leverages the flexibility and agility of the layered service architecture to achieve efficient reuse and flattened management of capabilities at each layer. Consequently, network resources are allocated flexibly and visually, improving network resource allocation efficiency. By abstracting customer-oriented services, resource-oriented services, and the capabilities provided by the network resources themselves, rapid encapsulation of network resource capabilities is achieved, increasing network implementation efficiency and reliability.

[0070] Based on the same inventive concept, the present invention also provides a model-driven network resource service design system, which can be a personal computer, a server, or other system that implements the aforementioned model-driven network resource service design method.

[0071] Please see Figure 2 As shown in the embodiments of this application, the model-driven network resource service design system includes:

[0072] The object definition module is used to define the basic information of the objects involved in network resource services;

[0073] The object topology definition module is used to define the topological relationships between objects involved in network resource services;

[0074] The event definition module is used to define the lifecycle events involved in network resource services;

[0075] The API definition module is used to define the APIs of objects involved in network resource services;

[0076] The API implementation definition module is used to define the orchestration and control of the APIs of the objects involved in the network resource service based on the topological relationships between the objects involved in the network resource service and the lifecycle events involved in the network resource service, so as to form a network resource service model.

[0077] The strategy definition module is used to define the data processing strategy for the network resource service model during runtime;

[0078] The indicator definition module is used to define performance indicators of network resource services based on parameters in the network resource service model.

[0079] All relevant content of each step involved in the aforementioned embodiments of the model-driven network resource service design method can be referenced to the functional description of the corresponding functional module of the model-driven network resource service design system in the embodiments of this application, and will not be repeated here.

[0080] The module division in this embodiment is illustrative and represents only one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional modules in the various embodiments of this invention can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0081] In the accompanying drawings of the system embodiments provided by the present invention, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0082] The present invention also provides an electronic device comprising: at least one processor and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the model-driven network resource service design method described above. This electronic device can be any terminal device including mobile phones, laptops, desktop computers, tablets, PDAs (Personal Digital Assistants), POS (Point of Sales) terminals, in-vehicle computers, etc.

[0083] The present invention also provides a storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described model-driven network resource service design method.

[0084] Through the above description of the embodiments, those skilled in the art can clearly understand that the present invention can be implemented by means of software plus necessary general-purpose hardware, and of course, it can also be implemented by special hardware including application-specific integrated circuits, special CPUs, special memory, special components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for the present invention, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of the present invention, 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 readable storage medium, such as a computer floppy disk, USB flash drive, portable hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0085] Although embodiments of the present invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. They can be applied to various fields suitable for the present invention. For those skilled in the art, other modifications can be easily made. Therefore, without departing from the general concept defined by the claims and their equivalents, the present invention is not limited to the specific details and illustrations shown and described herein.

Claims

1. A model-driven network resource service design method, characterized in that, include: Define the basic information of the objects involved in network resource services; Define the topological relationships between objects involved in network resource services; Define the lifecycle events involved in network resource services; Define the APIs for the objects involved in network resource services; Based on the topological relationships between objects involved in network resource services and the lifecycle events involved in network resource services, the orchestration and control of the APIs of the objects involved in network resource services are defined to form a network resource service model. The definition of the orchestration and control of the APIs of the objects involved in network resource services includes: defining the process template information of APIs, selecting lower-level objects and their APIs in the topological relationship between objects, defining the relationship between the APIs of lower-level objects to form a process template; and defining the instructions for calling the lowest-level object. Define the data processing strategy for the network resource service model during runtime; Based on the parameters in the network resource service model, performance indicators for network resource services are defined.

2. The model-driven network resource service design method as described in claim 1, characterized in that, The objects involved in the network resource service are divided into business services, network services, and resource capabilities. The business services are assembled from network services, and the network services are assembled from resource capabilities. The basic information of the objects includes object name, code, event, description, version, status, and directory. The basic information of the objects involved in the network resource service is defined to support adding, deleting, updating, querying, and changing the status of objects in a directory tree manner.

3. The model-driven network resource service design method as described in claim 1, characterized in that, Define the basic information of the objects involved in network resource services by assigning values ​​to the basic information using specification mapping, attribute mapping, and dictionary value mapping.

4. The model-driven network resource service design method as described in claim 1, characterized in that, Defining the topological relationships between objects involved in network resource services includes: defining object composition relationship information and object topology information, wherein the object composition relationship information is used to describe the composition relationship between upper-level objects and lower-level objects, and the object topology information is used to describe the association relationship between one upper-level object and multiple lower-level objects; and automatically generating a topology mapping based on the object composition relationship information and object topology information.

5. The model-driven network resource service design method as described in claim 1, characterized in that, The lifecycle events involved in network resource services include operational production events and network operation and maintenance management events.

6. The model-driven network resource service design method as described in claim 1, characterized in that, Defining the APIs of objects involved in network resource services includes defining the name, code, time, status, description, and parameters of the APIs of objects involved in network resource services, and supporting operations such as adding, deleting, updating, querying, and changing the status of the APIs of objects.

7. The model-driven network resource service design method as described in claim 1, characterized in that, The definition of data processing strategies for the network resource service model runtime includes defining object strategies, process strategies, API strategies, and exception strategies; the definition of data processing strategies for the network resource service model runtime is implemented using the Groovy rule language.

8. The model-driven network resource service design method as described in claim 1, characterized in that, Performance metrics for network resource services include KPIs, KOIs, and QQEs.

9. A model-driven network resource service design system, characterized in that, include: The object definition module is used to define the basic information of the objects involved in network resource services; The object topology definition module is used to define the topological relationships between objects involved in network resource services; The event definition module is used to define the lifecycle events involved in network resource services; The API definition module is used to define the APIs of objects involved in network resource services; The API implementation definition module is used to define the orchestration and control of the APIs of the objects involved in the network resource service based on the topological relationships between the objects involved in the network resource service and the lifecycle events involved in the network resource service, so as to form a network resource service model. The definition of the orchestration and control of the APIs of the objects involved in the network resource service includes: defining the flow template information of the API, selecting the lower-level objects and their APIs in the topological relationship between the objects, defining the relationship between the APIs of the lower-level objects to form a flow template; and defining the instructions for calling the lowest-level object. The strategy definition module is used to define the data processing strategy for the network resource service model during runtime; The indicator definition module is used to define performance indicators of network resource services based on parameters in the network resource service model.

Images