System and method for automated bidirectional mapping between service specifications

Abstract

A method for bidirectional mapping includes storing a relationship between a first service specification and a second service specification; receiving an application programming interface (API) call for the second service specification including a payload including a relationship type; verifying that the relationship type included in the payload corresponds to the relationship type of the relationship between the first service specification and the second service specification; verifying whether a complementary relationship exists between the first service specification and the second service specification in response to the relationship type included in the payload corresponding to the relationship type of the relationship between the first service specification and the second service specification; and updating the first service specification with dependent service details of the relationship between the first service specification and the second service specification in response to the complementary relationship existing between the first service specification and the second service specification.

Description

Technical Field

[0001] This description relates to a system for automated bidirectional mapping between service specifications and a method of using the same.

Background Art

[0002] A cellular network is a telecommunications system of mobile devices (e.g., mobile phone devices) that communicate via radio waves through one or more local antennas at a cellular base station (e.g., a cell tower). Cellular service is provided in a coverage area divided into small geographical areas called cells. Each cell is served by an individual low-power multi-channel transceiver and antenna at a cell tower. Mobile devices within a cell communicate via the cell's antenna using a plurality of frequency channels and individual frequency channels assigned by the base station from a common pool of frequencies used by the cellular network.

[0003] A radio access network (RAN) is part of a telecommunications system and implements radio access technology. The RAN exists between devices such as mobile phones, computers, or remote control machines and provides a connection to a core network (CN). Depending on the standard, mobile phones and other wireless-connected devices are variously known as user equipment (UE), terminal equipment (TE), mobile station (MS), etc.

Summary of the Invention

Means for Solving the Problems

[0004] In some embodiments, a method for bidirectional mapping includes, by a processor, storing in a database a relationship between a first service specification and a second service specification; receiving, by the processor, an application programming interface (API) call requesting a second service specification that includes a payload that includes a relationship type; verifying, by the processor, that the relationship type included in the payload corresponds to the relationship type of the relationship between the first service specification and the second service specification stored in the database; verifying, by the processor, whether a complementary relationship exists between the first service specification and the second service specification in response to the relationship type included in the payload corresponding to the relationship type of the relationship between the first service specification and the second service specification stored in the database; in response to a complementary relationship existing between the first service specification and the second service specification, updating, by the processor, the first service specification using the dependent service details of the relationship between the first service specification and the second service specification.

[0005] In some embodiments, an apparatus The system includes a processor and a memory having instructions that, in response to an action performed by the processor, cause the device to receive an application programming interface (API) call requesting a second service specification including a payload containing a relationship type, to cause the device to store a relationship between a first service specification and a second service specification in a database, to receive an application programming interface (API) call requesting a second service specification including a payload containing a relationship type, to cause the device to verify that the relationship type included in the payload corresponds to a relationship type of the relationship between the first service specification and the second service specification stored in the database, to verify whether a complementary relationship exists between the first service specification and the second service specification, and to update the first service specification using the dependent service details of the relationship between the first service specification and the second service specification in response to a complementary relationship existing between the first service specification and the second service specification.

[0006] In some embodiments, a non-temporary computer-readable medium storing instructions that, in response to being executed by a processor, cause the device to store in a database a relationship between a first service specification and a second service specification; receive an application programming interface (API) call requesting a second service specification including a payload containing a relationship type; verify that the relationship type included in the payload corresponds to a relationship type of the relationship between the first service specification and the second service specification stored in the database; verify whether a complementary relationship exists between the first service specification and the second service specification in response to the relationship type included in the payload corresponding to a relationship type of the relationship between the first service specification and the second service specification stored in the database; and update the first service specification using the dependent service details of the relationship between the first service specification and the second service specification in response to the existence of a complementary relationship between the first service specification and the second service specification.

[0007] The aspects of this disclosure will be understood by reading the following detailed description in conjunction with the accompanying figures. In accordance with industry standard practice, various features are not depicted to actual size. In some embodiments, the dimensions of various features have been arbitrarily increased or decreased for the sake of clarity of consideration. [Brief explanation of the drawing]

[0008] [Figure 1] This is a diagrammatic representation of a system for network slice design (NSD) according to several embodiments. [Figure 2] This is a diagram of a universal network service (network service (NS)) bundle in several embodiments. [Figure 3] This is a data flow diagram of a method for policy onboarding integration, according to several embodiments. [Figure 4] This is a diagrammatic representation of complementary relationship tables in several embodiments. [Figure 5] This is a diagrammatic representation of a service catalog database in several embodiments. [Figure 6] This is a data flow diagram representation of a method for automated bidirectional mapping between service specifications (ABMBSS) according to some embodiments. [Figure 6C] This is a data flow diagram representation of a method for automated bidirectional mapping between service specifications (ABMBSS) according to some embodiments. [Figure 7] This is a visual representation of a method for ABMBSS according to several embodiments. [Figure 8] This is a high-level functional block diagram of a processor-based system according to some embodiments. [Modes for carrying out the invention]

[0009] The following disclosure provides many different embodiments or examples for implementing the specific features of the subject matter discussed. For the sake of simplicity, examples of components, values, behaviors, materials, arrangements, etc., are described below. These are, of course, examples and are not intended to be limiting. Other components, values, behaviors, materials, arrangements, etc., are contemplated. For example, forming a first feature on top of a second feature in the following description includes embodiments in which the first and second features are formed in direct contact, and further includes embodiments in which an additional feature is formed between the first and second features so that the first and second features cannot be in direct contact. In addition, some embodiments repeat reference numbers and / or reference letters in many examples. This repetition is for brevity and clarity and is not intended to determine the relationships between the various embodiments and / or configurations discussed.

[0010] Furthermore, spatially relative terms such as beneath, below, lower, above, and upper are used herein to facilitate explanations of the relationship between one element or feature and another element or feature, as shown in the figures. If the apparatus is oriented in other ways (rotated by 90 degrees or in other orientations), the spatially relative descriptors used herein shall be interpreted accordingly.

[0011] A network service (NS) bundle is a bundle containing technical services, configurations, manifest files, or other appropriate services and files within the scope of several embodiments. Technical services are further subdivided into different network service descriptors (NSDs) and virtualized network function descriptors (VNFDs). VNFDs are created in the application bundle.

[0012] An application bundle file is a single, relocatable file containing the artifacts necessary to run an application. The application bundle file is configured to run on (or be instantiated) an instance. Moving the application bundle file relocates the application files. Apart from system libraries, the application bundle file contains the toolkit artifacts used to run the application. The application does not access external toolkits when running on an execution host (e.g., a smartphone used by a subscriber). Logically, the application bundle file contains parts of the application directory and output directory, as well as subdirectories from the toolkits that contributed to the application. When an application bundle file is presented for execution, it is unpacked for all hosts on which the application will run. The application bundle file is then not bundled into a runtime application directory hierarchy similar to a compile-time hierarchy with any external toolkit entities added. The application bundle file has an identifier that uniquely distinguishes one build of the application from another. When an application bundle file is presented for execution, the identifier is used to check if another instance of the same application is already running, and if so, it shares an unbundled execution location. In this case, the same runtime application directory hierarchy is used for execution of a given application bundle file.

[0013] An NSD is a deployment template containing information used by a network function virtualization orchestrator (NFVO) for lifecycle management of network services (NSs). An NS is a set of functions with unspecified connectivity between NFs, or a configuration of network functions (NFs or applications) arranged according to one or more forwarding graphs.

[0014] A network slice (a portion of the original network architecture divided or sliced ​​into multiple logical and independent networks configured to effectively meet various service requirements) is further divided into subnets, each dedicated to a specific domain (e.g., RAN, CN, transport domain, or end-to-end (E2E)). A transport domain refers to telecommunications transmission equipment under which voice, data, and video communications are distributed between geographically separated locations for shared-based use.

[0015] Within a subnet, there are one or more NSs or bundles of NSs. Within an NS, there are one or more NFs or bundles of NFs. The Orchestrator Bundle Catalog (orchestration is the automated configuration, coordination, and management of computer systems and software) registers application bundles (e.g., bundles containing the executable code of an application and its associated resources). The onboarding service creates bundle / package objects in the central inventory. The onboarding service sends a request to the policy manager to create a policy descriptor file (without a universally unique identifier (UUID) for the source element, which is a 128-bit label used for information within the computer system).

[0016] When generated according to standard methods, UUIDs are unique for their practical purpose. Their uniqueness, unlike most other numbering schemes, does not depend on a central registration authority or coordination between the parties generating them. While the probability of a UUID being duplicated is not zero, it is negligibly close to zero. Therefore, UUIDs are used to identify something with near certainty that they will not duplicate identifiers already created or to be created to identify something else, even if they are created by anyone. Thus, information labeled with UUIDs by independent parties can later be combined into a single database or transmitted over the same channel with a very small probability of overlap.

[0017] A policy manager can determine (determine) the extent to which a service / device is permitted to do what it is trying / requesting, and then enforce (enforce) that decision. Some examples of policies include (1) whether a customer is permitted to use this service, (2) whether there is sufficient capacity to support this new service, (3) what happens to non-SLA (service level agreement) customers when the node approaches congestion, and (4) whether the service request / activity is a security threat.

[0018] The policy manager sends the policy ID back to the orchestrator, which stores the policy ID along with the package ID. An NF instantiation request is received from the user (for example, instantiating an NF using an NFT (network function template) that contains a policy descriptor file with the policy ID).

[0019] Instances are created in the central inventory. The orchestrator sends a notification to the policy manager to deploy the NF / application and enable the policy with each policy ID. The policy file is modified with information such as the pending (source element UUID). After modifying the pending information, the descriptor is referenced as a policy template. Here, the policy template is ready for activation by the user.

[0020] In some embodiments, an automated bidirectional mapping between NS specifications is disclosed.

[0021] In other approaches, when storing the NS bundle, a bidirectional relationship between the NS bundle and the artifact service specification is maintained. These relationships are used to fetch the NS specification by one or more applications. There is no check or means to assert whether a pre-agreed relationship is considered valid.

[0022] An artifact is a separate document that constitutes an architecture. Artifacts provide explanations from different perspectives for various parties. Artifacts are used to improve communication between different parties.

[0023] As an example of another approach, the application bundle NS specification is stored in a catalog such as a bundle catalog. To link the NF template to the bundle, the catalog allows specific relationships such as "Depends On App Bundle" because the relationship "XYZ" is considered inappropriate as it does not describe the relationship, and does not allow random relationships such as "XYZ".

[0024] When registering a bundle, engineers trace the artifact NS specification from the application bundle, and vice versa. However, with respect to NS, to create a relationship between one NS specification and another, the Tele-Management Forum (TMF) expects 30 PATCH calls to be sent to add the relationship to an already existing NS specification. This process increases the system and user load, reduces efficiency, and makes the application less user-friendly.

[0025] TMF is a global industry association for service providers and suppliers in the telecommunications industry. Its members include communications and digital service providers, telephone companies, cable operators, network operators, cloud providers, digital infrastructure providers, software suppliers, equipment suppliers, system integrators, and management consultants.

[0026] In computing, PATCH is a hypertext transfer protocol (HTTP) request method for making partial changes to existing resources. The PATCH method provides an entity containing a list of changes to be applied to the requested resource using an HTTP Uniform Resource Identifier (URI). The list of changes is provided in the form of a PATCH document. In response to the request for the resource not existing, the server creates the resource according to the PATCH document media type and permissions. The changes described in the PATCH document are semantically well-defined but have a different media type than the resource being patched.

[0027] In some embodiments, two or more NSs are configured to have many relationships related to many other relationships. Other methods were unable to store these relationships in a database so that some of the relationships between two or more services could be added / deleted in the future. In some embodiments, in response to having bidirectional relationships between two or more NS specifications, the engineer makes two or more NS specifications unidirectional. Furthermore, in some embodiments, the engineer converts unidirectional relationships to bidirectional relationships.

[0028] In some embodiments, predefined relationships between bundles and artifacts, NS templates, and descriptors are stored in a catalog database, such as a service catalog. In some embodiments, upon receiving a POST call, the service catalog checks whether the relationship between two or more specifications provided in the NS specification relationship is valid. In response that the relationship has been stored in the service catalog database, the relationship is considered valid. In response that the relationship is valid, the service catalog registers the NS specification.

[0029] A service catalog is an organized and managed collection of any business and information technology (IT) related services performed by, for, or within an enterprise. A service catalog serves as a knowledge management tool for the enterprise's employees and consultants, allowing requests from employees and consultants regarding services and service-related topics to be routed to the professionals who own, are accountable for, and operate them. Each service within such a service catalog is typically highly repeatable and has controlled inputs, processes, and outputs.

[0030] In computing, POST is a request method supported by HTTP, used by the World Wide Web (WWW). By design, the POST request method requests that a web server accept the data placed in the body of the request message, most likely for storage. POST is often used when uploading files or submitting completed web forms. As part of a POST request, any type and amount of data is sent to the server in the body of the request message. The header fields of a POST request typically indicate the internet media type of the message body.

[0031] In some embodiments, the service catalog verifies whether complementary relationships are registered. In some embodiments, the service catalog updates the NS specifications mentioned in the NS specification relationships and creates complementary relationships for the NS specifications. No additional PATCH requests, as described above, are requested by the user / engineer. In a non-limiting example, an application bundle is registered, followed by an NF template, creating a complementary relationship between the application bundle and the NF template.

[0032] In some embodiments, this complementary relationship process simplifies the creation of bidirectional relationships between two NS specifications. In some embodiments, the process improves performance and reduces user involvement (e.g., by reducing the number of PATCH calls). In some embodiments, the service catalog executes the PATCH calls. In some embodiments, the process increases efficiency as human intervention is reduced, thereby reducing errors caused by human interaction.

[0033] Figure 1 shows a diagrammatic representation of a system for network slice design (NSD) 100 in several embodiments.

[0034] The NSD system 100 includes a CN 102 that is communicatively connected to the RAN 104 via a transport network 106 that is communicatively connected to base stations 108A and 108B (hereinafter referred to as base stations 108), where an antenna 110 is wirelessly connected to a UE 112 located within geographic coverage cells 114A and 114B (hereinafter referred to as geographic coverage cells 114). The CN 102 includes one or more service providers 116, a KPI server 118, and a service builder module 120.

[0035] CN102 (also known as the backbone) is part of a computer network that interconnects networks, providing a path for exchanging information between different local area networks (LANs) or subnetworks. In some embodiments, CN102 connects diverse networks together across a wide geographical area, within different buildings in a campus environment, or even within the same building.

[0036] In some embodiments, RAN104 is a global system for mobile communications (GSM) RAN, GSM / EDGE RAN, universal mobile telecommunications system (UMTS) RAN (UTRAN), evolved UMTS terrestrial radio access network (E-UTRAN), open RAN (O-RAN), or cloud RAN (C-RAN). RAN104 resides between UE112 (e.g., a mobile phone, computer, or any remote control machine) and CN102. In some embodiments, RAN104 is a C-RAN for simplified representation and explanation. In some embodiments, a baseband unit (BBU) replaces the C-RAN.

[0037] In a hierarchical telecommunications network, the transport network 106 of the NSD system 100 includes an intermediate link between CN 102 and RAN 104. Two main methods in mobile backhaul implementations are fiber-based backhaul and wireless point-to-point backhaul. Other methods, such as copper-based wired, satellite, and point-to-multipoint wireless technologies, are being phased out as capacity and latency requirements become higher in 4G and 5G networks. Backhaul refers to the network side that communicates with the internet. The connection between base station 108 and UE 112 begins with the transport network 106 connected to CN 102. In some embodiments, the transport network 106 includes wired, optical fiber, and wireless components. The wireless section includes using microwave band, mesh, and edge network topologies that use high-capacity wireless channels to send packets to microwave or fiber links.

[0038] In some embodiments, base station 108 is a grid or self-supporting tower, guy tower, monopole tower, and concealed tower (e.g., a tower designed to resemble a tree, cactus, water tower, sign, lighting standard, and other types of structure). In some embodiments, base station 108 is a cellular-enabled mobile device site where antennas and electronic communication equipment are typically located on a radio mast, tower, or other elevated structure to create a cell (or adjacent cell) in the network. The elevated structure typically supports antenna(s) 110 and one or more sets of transmitters / receivers (transmitters and receivers), digital signal processors, control electronics, remote radio heads (RRHs), primary and backup power sources, and shelters. Base stations are also known by other names such as transceiver base stations, mobile phone masts, or cell phone base stations. In some embodiments, other edge devices are configured to communicate wirelessly with the UE. The edge devices provide an entry point to a service provider CN, such as CN102. Examples include routers, routing switches, integrated access devices (IADs), multiplexers, and various metropolitan area network (MAN) and wide area network (WAN) access devices.

[0039] In at least one embodiment, antenna 110 is a sector antenna. In some embodiments, antenna(s) 110 is a type of directional microwave antenna having a sector-shaped radiation pattern. In some embodiments, the sector angle of the arc is 60°, 90°, or 120° in design, with a few extra degrees to ensure overlap. Furthermore, sector antennas are mounted in multiples if wider coverage or full circular coverage is desired. In some embodiments, antenna 110 is a rectangular antenna, sometimes referred to as a panel antenna or radio antenna, used to transmit and receive waves or data between a mobile device or other device and a base station. In some embodiments, antenna(s) 110 is a circular antenna. In some embodiments, antenna(s) 110 operate at microwave or ultra-high frequency (UHF) frequencies (300 MHz to 3 GHz). In other examples, antenna(s) 110 are selected for their size and directivity. In some embodiments, the antenna(s) 110 are MIMO (multiple-input, multiple-output) antennas that simultaneously transmit and receive two or more data signals over the same radio channel by utilizing multipath propagation.

[0040] In some embodiments, UE112 is a computer or computing system. Additionally or alternatively, UE112 has a liquid crystal display (LCD), light-emitting diode (LED), or organic light-emitting diode (OLED) screen interface, such as a user interface (UI) 822 (Figure 8), which gives a touchscreen interface with digital buttons and a keyboard or physical buttons along with a physical keyboard. In some embodiments, UE112 connects to the internet and interconnects with other devices. Additionally or alternatively, UE112 incorporates an integrated camera, the ability to make and receive voice and video phone calls, video games, and Global Positioning System (GPS) functionality. Additionally or alternatively, UE runs an operating system (OS) that allows third-party applications specialized for specific capabilities to be installed and run. In some embodiments, UE112 is a computer (such as a tablet computer, netbook, digital media player, digital assistant, graphing calculator, handheld game console, handheld personal computer (PC), laptop, mobile internet device (MID), personal digital assistant (PDA), pocket calculator, portable media player, or ultra-mobile PC), a mobile phone (such as a camera phone, feature phone, smartphone, or phablet), a digital camera (such as a digital camcorder, or digital still camera (DSC), digital video camera (DVC), or front camera), a pager, a personal navigation device (PND), a wearable computer (such as a calculator watch, smartwatch, head-mounted display, earphone, or biometric device), or a smart card.

[0041] In some embodiments, the geographic coverage cell 114 includes shape and size. In some embodiments, the geographic coverage cell 114 is a macrocell (covering 1 km to 30 km), a microcell (covering 200 m to 2 km), or a picocell (covering 4 m to 200 m). In some embodiments, the geographic coverage cell is circular, elliptical (Figure 1), sector-shaped, or lobe-shaped, but the geographic coverage cell 114 can be almost any arbitrary shape or size. The geographic coverage cell 114 represents the geographic area to which the antenna 110 and UE 112 are configured to communicate.

[0042] A service provider (CSP) is a company, vendor, customer, or organization that sells bandwidth or network access to subscribers (using a UE) by directly granting Internet service providers (ISPs) internet backbone access, typically through access to network access points (NAPs). Service providers are sometimes also referred to as backbone providers, internet providers, or vendors. Service providers include telecommunications companies, data carriers, wireless communication providers, internet service providers, and cable television operators that provide high-speed internet access.

[0043] In some embodiments, the service builder module 120 is configured to allow a user to design one or more network slices. In some embodiments, network slice design is GUI-based. In some embodiments, the operation includes the user entering basic information such as the network slice name, slice type, domain, and shared or non-shared slice selection. Other operations include defining slices such as NS profile parameters (holding the inherent requirements of the communication service instance, such as latency, data rate, and mobility level) as requested by the northbound interface (e.g., internally within the system or manually from the user), and converting the NS profile parameters into slice profile parameters (holding slice subnet parameter information for different network domain slice subnet instances (NSSIs), such as RAN, transport network (TN), and CN NSSI).

[0044] In some embodiments, the service builder module 120 is configured to integrate policy onboarding, such as network function / network service (NF) / (NS) package onboarding.

[0045] Figure 2 shows visual representations of the Universal NS Bundle 200 in several embodiments.

[0046] For the purposes of this explanation, application and network functions are used interchangeably unless otherwise distinguished.

[0047] In Figure 2, the NS bundle 202 is an integration of technical services 204 (and other services such as icons 206) which are further subdivided into different NSDs 205 and VNFDs 207. In some embodiments, the VNFD 207 is created using application bundles 208 and 210. In some embodiments, policy descriptors 212 and 214 are part of application bundles 208 and 210. In some embodiments, policy descriptor files 212 and 214 are in JavaScript Object Notification (JSON) format. In some embodiments, the policy bundle is part of a network services (NS) / (NF) network functionality bundle that includes other artifacts such as technical application images, metrics, configuration files, or other appropriate files, within the scope of some embodiments.

[0048] JSON is an open standard file and data exchange format that uses human-readable text to store and transmit data objects consisting of attribute-value pairs and arrays (or other serializable values). JSON is a data format with diverse uses in electronic data exchange, including with servers and web applications. JSON is a language-independent data format. While JSON originated from JavaScript, many modern programming languages ​​include code for generating and parsing JSON formatted data. JSON filenames use the extension .json.

[0049] Figure 3 is a data flow diagram of Method 300 for Policy Onboarding Integration, according to several embodiments.

[0050] In some embodiments, Method 300 for Policy Onboarding Integration describes the operation of policy onboarding integration. Although the operation of Method 300 for Policy Onboarding Integration is described and shown as having a specific order, each operation of Method 300 for Policy Onboarding Integration is configured to be executed in any order unless otherwise specified. Method 300 for Policy Onboarding Integration is performed as a set of operations, such as operations 302 through 320.

[0051] In operation 302 of the method for policy onboarding integration 300, the service builder 358 registers application bundles, such as application bundles 208 and 210, in the orchestrator 360's bundle catalog 364. In response to the presentation of an NF application, the service builder tool 358 creates the application bundle and automatically registers the application bundle in the orchestrator 360's bundle catalog 364 via the application programming interface (API). A bundle is a set of products provided under a single right or license that does not include any proprietary components. In the bundle catalog 364, a bundle is modeled as a software product that has a setup relationship with other software products.

[0052] In some embodiments, the service builder tool 358 is similar to the service builder module 120 and includes a reference to the NS bundle when the reference is created by the slice manager. The slice manager is responsible for creating the network slices and NS subnets, while the orchestrator 360 is responsible for creating the NS and NF. The process flows from operation 302 to operation 304.

[0053] In some embodiments, Method 300 describes a method for creating and transporting NS bundles. A slice manager is responsible for the NS bundles for further execution of bundle services to the northbound system (dealing with specific objectives of systematic operation). In some embodiments, Method 300 includes additional steps to describe policy bundles that follow the same principles as bundle processing and to show how policy bundles are managed.

[0054] In operation 304 of the method for policy onboarding integration 300, the onboarding service 350 of orchestrator 360 creates a bundle / package object in the central inventory (CI) 352 and stores the bundle / package object as an inventory file. In some embodiments, the object is a variable, a data structure, a function, or a method. As a region of memory, the application bundle object contains values ​​and is referenced by an identifier. In some embodiments, the application bundle object is a combination of variables, functions, and data structures. In some embodiments, the application bundle object is a table or column, or an association between data and a database entity. The process flows from operation 304 to operation 306.

[0055] In operation 306 of the method for policy onboarding integration 300, the onboarding service 350 sends a request to the policy manager 354 to create a policy descriptor file (e.g., policy name, policy descriptor files (e.g., policy descriptor files 212 and 214), bundle / package UUID, but without the source element UUID). In some embodiments, the application bundle descriptor file is a JSON file (e.g., policy.descriptor.json) that describes the application bundle. The descriptor file contains general information about the application bundle, as well as any modules that the application bundle may want to use or extend. The descriptor file acts as a glue between the remote application (e.g., one owned by user 362) and the application in CN such as CN102. In some embodiments, when the administrator of the cloud instance installs the application, a descriptor file containing a pointer to NS is installed. The process flows from operation 306 to operation 308.

[0056] In operation 308 of the method for policy onboarding integration 300, the policy manager 354 returns the policy IDs corresponding to the rule-based policies and application bundles to the orchestrator 360. The process flows from operation 308 to operation 310.

[0057] In operation 310 of the method for policy onboarding integration 300, the life cycle management (LCM) or network function (NF) planning module 356 stores the policy ID along with the package ID. Application LCM is the product lifecycle management (e.g., administration, development, and maintenance) of a computer program. The lifecycle includes requirements management, software architecture, computer programming, software testing, software maintenance, change management, continuous integration, project management, and release management. The process flows from operation 310 to operation 312.

[0058] In operation 312 of the method for policy onboarding integration 300, a request for NF instantiation from user 362 is received (for example, to instantiate an NF using an NFT containing a policy descriptor file with a policy ID). The process flows from operation 312 to operation 314.

[0059] In operation 314 of method 300 for policy onboarding integration, an NF instance is created within CI352. In some embodiments, the user instantiates / installs the NF on which the policy bundle is created. The context of the NF instantiation is included to relate that this NF is for policy creation. The process flows from operation 314 to operation 316.

[0060] In operation 316 of the method for policy onboarding integration 300, the orchestrator 360 deploys the NF / application for user 362. The process flows from operation 316 to operation 318.

[0061] In operation 318 of the method for policy onboarding integration 300, the orchestrator 360 sends a notification to the policy manager 354 to enable rule-based policies with their respective policy IDs. Thus, when user 362 is using the application, the rule-based policies are in effect for the application. The process then proceeds from operation 318 to operation 320.

[0062] In operation 320 of the method for policy onboarding integration 300, the policy manager 354 modifies the policy file with pending information (e.g., source element UUID). After filling with pending information, the policy descriptor file becomes a policy template. The policy template table is updated and the enabled policy ID is activated. In some embodiments, the template refers to a valid working policy file (i.e., template is a naming ecosystem term). A policy template is created when the created policy has parameters for enforcing the policy.

[0063] Figure 4 shows a visual representation of the relational table 400 according to several embodiments.

[0064] Figure 5 shows a visual representation of the service catalog database 500 in several embodiments.

[0065] Figures 6 and 6C (Continued) are data flow diagram representations of Method 600 for automated bidirectional mapping between service specifications (ABMBSS) in several embodiments.

[0066] Figures 4, 5, and 6 and 6C are discussed together to provide an understanding of method 600 for automated bidirectional mapping (ABMBSS) between NS specifications. In some embodiments, the ABMBSS method 600 is performed by a processing circuit 802, which is discussed below with respect to Figure 8. In some embodiments, some or all of the operation of the ABMBSS method 600 is performed according to instructions corresponding to instructions 806, which are discussed below with respect to Figure 8.

[0067] The ABMBSS method 600 includes exemplary operations 602–614, but the operations are not necessarily performed in the order shown. Operations may be added, replaced, reordered, and / or deleted as appropriate, in accordance with the spirit and scope of the embodiment. In some embodiments, one or more operations of the ABMBSS method 600 are repeated. In some embodiments, the operations of the ABMBSS method 600 are performed sequentially unless otherwise specified.

[0068] In some embodiments, application-related bundles are configured to deploy their application along with artifacts and / or files used by other modules. In non-limiting examples, observability frameworks (OBF, which collects telemetry data from network capabilities that enable the use of artificial intelligence (AI) and machine learning (ML) to optimize and operate 5G networks and provide greater near real-time visibility into the performance and operation of cloud-native network capabilities), Cloud Management as a Service (CMaaS), and / or other similar modules use files to deploy applications and manage the lifecycle of those applications.

[0069] In some embodiments, the service catalog stores bundle information. As discussed, an application bundle contains files used by one or more (e.g., seven or eight) modules within an orchestrator such as Orchestrator 360.

[0070] Other methods make it difficult to maintain track of the files for each module used in a particular bundle. Therefore, in some embodiments, the service catalog is designed to scan the directory structure of the entire bundle, regardless of whether the application, network service, or network template is onboarded or registered in the service catalog in response to the bundle. In some embodiments, the service catalog identifies which deployment files and which files belong within the orchestrator.

[0071] In some embodiments, as discussed in Figure 7, the service catalog is a TMF633 service catalog for a 633-based module or product. In some embodiments, the input to the service catalog is in the form of a TMF633 payload specification or service specification.

[0072] In some embodiments, the service catalog stores bundle payload information in a database, and regardless of which files the bundle contains, the service catalog goes through each file, identifies its priority and which modules use that file, and tags the file. In some embodiments, the service catalog identifies and stores a file containing bundle details. In a non-limiting example, in response to a bundle containing five files, the service catalog creates six service specifications for this one top-level bundle, and the other five service specifications for the files within the bundle.

[0073] In other approaches, the problem arose of how to map the service specifications in response to the service catalog creating these six service specifications.

[0074] In some embodiments, service pack relationships are used to link service specifications. In computing, a service pack is a collection of updates, adjustments, or enhancements to a software program delivered in the form of a single installable package. Installing a service pack is less error-prone than installing many individual patches.

[0075] In some embodiments, the service catalog uses service pack relationships to map top-level service specifications to lower-level service specifications. Therefore, a user with access to the top-level routing bundle can then have top-down access to each module used by the child service specifications. This is particularly useful for troubleshooting because the user has access to the parent service specification or the original bundle. Modules are accessed from bottom to top. The user has top-down access, and modules using the child service specifications have bottom-to-top access.

[0076] In some embodiments, the user provides the relationship as part of the request body. Often, multiple service specifications exist, or rather, there are numerous service specifications related to a top-level specification created by the user. According to the current standard, in response to the relationship between service specifications, the user first provides the relationship between one service specification (e.g., service specification A) and another service specification (e.g., service specification B). This means that the user first provides the link between service specification A and service specification B while creating service specification A. Then, the user provides the link between service specification B and service specification A by updating service specification B.

[0077] This manual process is burdensome for the creator of service specifications, and in the case of bundles, there are hundreds, or even thousands, of other service specifications to be created. Therefore, some embodiments provide the ability to define such relationships, and once these relationships are defined, the service catalog automatically identifies the relationships and, in response to the discovery of one or more relationships, creates paired relationships with other service specifications. Returning to a non-limiting example, in response to a user creating a relationship between service specification A and service specification B, a bidirectional relationship is automatically created in response to the existence of bidirectional services.

[0078] Some embodiments further include checking whether the relationships defined in the input payload are valid. In some embodiments, a table in the database stores the relationships that are considered valid by the service catalog, and each relationship not mentioned in this table is considered invalid, and the service catalog throws an error. In some embodiments, the reason behind table validation is to prevent random relationships in the service specification, as sensitive data is being handled.

[0079] In another method, a user has already registered a service specification, and in response to the need to register that service specification with 30 other service specifications, the user sends 30 different patch calls to associate each of the 30 service specifications with the already registered service specification.

[0080] Therefore, the embodiments considered save users time by reducing the number of extra calls they would otherwise have to make, thus saving traffic on the service catalog, while also eliminating the manual portion of the registration process. Furthermore, the system's error rate is reduced because human involvement in the process is significantly reduced.

[0081] In some embodiments, a bidirectional relationship is reduced to a single API POST call. Therefore, continuing with an unrestricted example, a service specification POST API call provided by the user describes a relationship type. Since this service specification depends on the application bundle, the service catalog checks the relationship table and, in response to the relationships present in the relationship table, determines that a valid relationship exists at this time. Here, the service catalog verifies whether the relationships are complementary.

[0082] In Figures 6 and 6C, in operation 602 of the ABMBSS method 600, predefined relationships between service specifications, such as application bundles, and artifacts, service templates, and descriptors are stored in a catalog database, such as database 500. In some embodiments, the predefined relationships are complementary relationships between service specifications and are stored in a database (DB), such as DB 500, by a service catalog, such as service catalog 722 in Figure 7. In some embodiments, the predefined relationships are registered in the service catalog and stored in a DB, such as DB 500 in Figure 5, as a relationship table 400 (Figure 4).

[0083] The relationship table 400 includes a column 402 listing the serial numbers (SNOs) of service specifications in order. In some embodiments, the SNOs are unlimited. In some embodiments, the SNOs are 2 or 30 as discussed above (as shown in the figure). In some embodiments, the SNO is a number to quantify the number of service specifications to be included in a one-sided or complementary relationship. In some embodiments, the SNO is any other suitable identifier, including at least one of one or more digits, one or more letters, one or more symbols, one or more graphics, one or more QR codes®, one or more barcodes, one or more other suitable identification mechanisms, or a combination thereof.

[0084] The relationship table 400 includes column 404, where each service specification role is described for each service, starting from column 402. In the example in Figure 4, SNO 1 is the application bundle described above, and SNO 2 is the network function template (NFT), which is described further above. In some embodiments, an application bundle (e.g., service specification A) is configured to have a relationship with a network function template (e.g., service specification B), and vice versa.

[0085] The relationship table 400 includes column 402 and column 406, which detail the relationship type for each service specification. In the example in Figure 4, SNO 1, the "parent," supplies SNO 2 with a "child," which is a Container Network Functionality Template (CNFT) that depends on the application bundle in a complementary way.

[0086] Operating system (OS) level virtualization is an OS paradigm in which the kernel (the computer program at the core of a computer's OS, which generally has complete control over everything in the system) allows for the existence of multiple isolated user-space instances called containers. Such instances appear like actual computers from an application's perspective. Computer programs running on the OS see the resources of that computer (e.g., connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities). However, programs running inside a container see the contents of the container and the devices assigned to the container.

[0087] The relationship table 400 includes a column 408 that describes the target service specification roles for complementary relationships. In the example in Figure 4, SNO 1 has a target service specification role using a network function template, and SNO 2 has a target service specification role using an application bundle.

[0088] Therefore, relation table 400 shows the complementary relationship between a first service specification (e.g., application bundle (SNO 1)) and a second service specification (e.g., network function template (SNO 2)). In some embodiments, relation table 400 is created by a network operator or network engineer. In some embodiments, the complementary relationship is established during the design of the network slice. The process proceeds from operation 602 to operation 604.

[0089] In operation 604 of the ABMBSS method 600, a service catalog, such as the service catalog 722 in Figure 7, stores artifacts such as the bundle's service specification and the application bundle service specification 502 in the DB 500. The service specification 502 includes service specification information such as a name identifier 504 (e.g., appbundlename), an ID 506 (e.g., a UUID as described in detail above), an attachment 508 URL (e.g., bundle artifact 1 and bundle artifact 2), and a service specification relationship 510, such as the relationship to the application bundle artifact.

[0090] In some embodiments, each application bundle identifier in service specification 502 is stored in DB 500 by a service catalog. In some embodiments, one or more bundle identifiers are stored in the service catalog in DB 500 that has the service specification 502. In some embodiments, the service specification identifiers are completed by a network operator or engineer. In some embodiments, the service specification identifiers are automatically entered and / or registered (for example, using the processing circuit 800 in Figure 8). The process flows from operation 604 to operation 606.

[0091] In operation 606 of the ABMBSS method 600, a user 620 (Figure 6), such as a network operator or engineer, creates a service specification payload 630 for registering the service specification with the TMF by making a POST API call. In the non-limiting examples of Figures 6 and 6C, the network function template is created for an application bundle and configured to have a dependent (one-sided only) relationship with the application bundle. To create the relationship between the network function template and the application bundle, the user 620 provides a reference to the bundle service specification in the service specification payload 630 of the service specification POST API call 631.

[0092] In computer programming, the term "payload" is used in the context of message protocols, specifically to distinguish protocol overhead from the actual data. Ensuring the reliable transmission of a data payload over a communication network involves transmitting more than just the payload itself. Transmitting a data payload further involves transmitting various control and signaling data necessary to reach its destination. This creates so-called protocol overhead, as the additional data does not contribute to the inherent meaning of the message.

[0093] In non-specific examples, service specification POST API calls such as service specification POST API call 631 are, Service specifications related => ID: Identifier for Application Bundle Service Specification Name: Name of the application bundle service specification Role: The role of a template service specification in relationships, such as "subordinate". Relationship type: The relationship between a template service specification and a bundle, for example, Examples include "to depend on ~".

[0094] The payload 630 is received by a service catalog, such as the service catalog 722 in Figure 7. In some embodiments, the payload 630 is sent via a POST API call 631. The process proceeds from operation 606 to operation 608.

[0095] In operation 608 of the ABMBSS method 600, upon receiving the POST API call 631, the service catalog verifies whether the relationships between the specifications provided in the service specification relationships of the payload 630 are valid. In response that the relationships have been stored in the relationship table 400 of the catalog database 500, the service specification relationships of the payload 630 are valid, and the service catalog registers the service specification 628.

[0096] In some embodiments, the service catalog determines whether the roles and relationship types included in payload 630 are stored in DB500 (e.g., relationship table 400). In some embodiments, the determination is a validation of the relationships included in relationship table 400. In the example in Figures 6 and 6C, the role 622 and relationship type 624 of payload 630 are validated against relationship table 400. Continuing with a non-limiting example, in relationship table 400, in column 404 SNO 2, the relationship type in column 404 is the same as the relationship type 624 of payload 630. Furthermore, in column 406 SNO 1, the target service designating role in column 406 is the same as the role 622 of payload 630, and therefore the validation is valid and true. In some embodiments, in response to a false validation, the service catalog notifies the user that the relationship in payload 630 is not valid. The process proceeds from operation 608 to operation 610.

[0097] In operation 610 of the ABMBSS method 600, in response to a valid relationship between the payload 630 and the relationship table 400, the service catalog determines whether a complementary relationship exists and is registered (i.e., the inverse relationship (e.g., the relationship between the application bundle and the NFT) is valid and true). As discussed above with reference to Figure 4, the service specification role in column 404 relates to and references the relationship type in column 406 of the relationship table 400. Therefore, the complementary relationship is valid and the process proceeds from operation 610 to operation 612. In some embodiments, in response to an invalid or false complementary relationship, the service catalog notifies the user that the complementary relationship has not been established or does not exist.

[0098] In operation 612 of the ABMBSS method 600, in response to the existence of a complementary relationship (for example, relation table 400 is verified to contain the complementary relationship), the application bundle service specification 502 is updated to include the dependent service detail 626 of the network function template service specification. In the non-limiting example in Figures 6 and 6C, the service specification 502 is updated with the ID of the dependent service specification (e.g., the ID of the network function template service specification) obtained from the service specification POST API call 631 (e.g., the name of the network function template) obtained from the service specification POST API call 631 (e.g., the name of the network function template) (e.g., the role obtained from relation table 400) (e.g., application bundle) and the relationship further obtained from relation table 400 (e.g., supply to CNFT). In some embodiments, the dependent service detail 626 is further a payload and is directly retrieved from relation table 400. Continuing the non-limiting example, the application bundle service specification 502 is updated with the NFT service specification relationship. The process flows from operation 612 to operation 614.

[0099] In operation 614 of the ABMBSS method 600, user 620 stores in DB 500 an application bundle service specification 502 having dependent service details 626 that provide a valid relationship. Furthermore, the application bundle service specification 502 is updated in a complementary relationship with a single POST API call (as opposed to two separate POST API calls), as considered in operation 612. DB 500 also stores the service specification 632 of the service specification POST API call 631.

[0100] In some embodiments, the results are the same regardless of the number of complementary relationships to be updated. Whether the updates are between two service specifications as shown in the non-limiting example, or 30 updates in the non-limiting example considered above, or thousands of possible updates, the process is completed in a single POST API call. Thus, the bidirectional mapping process is made more efficient by automating the process, reducing human interaction, and mitigating errors that may result from human interaction.

[0101] Figure 7 is a visual representation of Method 700 for automated bidirectional mapping between service specifications (ABMBSS) in several embodiments.

[0102] Figure 7 is considered to provide an understanding of method 700 for automated bidirectional mapping between service specifications (ABMBSS). In some embodiments, ABMBSS method 700 is similar to ABMBSS method 600. In some embodiments, ABMBSS method 700 is performed by processing circuit 802, which is considered below with respect to Figure 8. In some embodiments, some or all of the operation of ABMBSS method 700 is performed according to instructions corresponding to instructions 806, which are considered below with respect to Figure 8.

[0103] The ABMBSS method 700 includes exemplary operations 702–712, but the operations are not necessarily performed in the order shown. Operations may be added, replaced, reordered, and / or deleted as appropriate, in accordance with the spirit and scope of the embodiment. In some embodiments, one or more operations of the ABMBSS method 700 are repeated. In some embodiments, the operations of the ABMBSS method 700 are performed sequentially unless otherwise specified.

[0104] In operation 702 of the ABMBSS method 700, the service catalog 722 registers complementary relationships between service specifications in a database such as DB500. In some embodiments, the complementary relationships are created based on a relationship table 720 developed by a user, such as user 620. In some embodiments, the service specification relationship table 720 is similar to the relationship table 400 and is further stored in the service catalog 722. In Figure 7, the service specification relationship data table 720 is stored in the service catalog 722. In some embodiments, the service catalog 722 is the TMF633 service catalog. In some embodiments, the service catalog 722 is the TMF service catalog API, which enables the service catalog management API to manage the entire lifecycle of service catalog elements. The process flows from operation 702 to operation 704.

[0105] In operation 704 of the ABMBSS method 700, the service catalog 722 registers the bundle's service specifications, such as the application bundle service specification 724. In some embodiments, the application bundle service specification 724 is registered in the TMF.

[0106] In some embodiments, the TMF633 REST API call requests the Application Bundle Service Specification 724 to register the Application Bundle Service Specification 724 with the TMF. Representational state transfer (REST) enables content to be rendered when the content is requested, often referred to as dynamic content. The process flows from operation 704 to operation 706.

[0107] In operation 706 of the ABMBSS method 700, the Network Function Template Service Specification 726 is registered with the Application Bundle Service Specification 724. In some embodiments, the Network Function Template Service Specification 726 is registered with the TMF for the Application Bundle Service Specification 724. In some embodiments, the TMF633 REST API call requests the NFT Service Specification 726 to register the NFT Service Specification 726, which includes the relationship with the Application Bundle Service Specification 724 included in the Service Specification Relationship 728 of the TMF. The process flows from operation 706 to operation 708.

[0108] In operation 708 of the ABMBSS method 700, the Service Catalog 722 determines whether a relationship exists within the payload of the Service Specification Relationship 728 and is valid within the Service Specification Relationship Table 720. In a non-limiting example, the Service Specification Relationship 728 includes a payload that references the Application Bundle Service Specification 724. Continuing with the non-limiting example, the payload is as follows: Name: Application Bundle (e.g., Application Bundle Service Specification 724) Relationship Type: Dependent on Application Bundle Role: Application Bundle Type: Service Specification Relationship.

[0109] The process flows from operation 708 to operation 710.

[0110] In operation 710 of the ABMBSS method 700, in response to a valid relationship between the payload within the service specification relationship 728 and the relationship table 720, a determination is made as to whether a complementary relationship between the NFT service specification 726 and the application bundle service specification 724 exists and is registered within the service specification table 720. In response to the complementary relationship existing within the specification table 720, the process flows from operation 710 to operation 712.

[0111] In operation 712 of the ABMBSS method 700, in response to the complementary relationship existing, the application bundle service specification 724 is updated to include dependent service details. Continuing with the non-limiting example, the payload is as follows: Name: Network Function Template Name (e.g., NFT service specification 726) Relationship Type: Provision to CNFT Role: Application Bundle Type: It is a service specification relationship.

[0112] FIG. 8 is a block diagram of an automated bidirectional mapping (ABMBSS) processing circuit 800 between service specifications, according to some embodiments. In some embodiments, the ABMBSS processing circuit 800 is a general-purpose computing device that includes a hardware processor 802 and a non-transitory computer-readable storage medium 804. The storage medium 804 stores, among other things, computer program code 806, i.e., a set of executable instructions such as algorithms, or is encoded, i.e., stores, the methods 300, 600, and 700 described herein. Execution of the instructions 806 by the hardware processor 802 represents (at least in part) an automated bidirectional mapping between service specification applications that implements some or all of the methods described herein (hereinafter, the described processes and / or methods).

[0113] The processor 802 is electrically coupled to the computer-readable storage medium 804 via bus 808. The processor 802 is further electrically coupled to the I / O interface 810 via bus 808. The network interface 812 is further electrically connected to the processor 802 via bus 808. The network interface 812 connects to the network 814 so that the processor 802 and the computer-readable storage medium 804 connect to external elements via the network 814. The processor 802 is configured to execute computer program code 806 encoded in the computer-readable storage medium 804, making the ABMBSS processing circuit 800 available to perform some or all of the processes and / or methods mentioned. In one or more embodiments, the processor 802 is a central processing unit (CPU), a multiprocessor, a distributed processing system, an application-specific integrated circuit (ASIC), and / or a suitable processing unit.

[0114] In one or more embodiments, the computer-readable storage medium 804 is an electronic, magnetic, optical, electromagnetic, infrared, and / or semiconductor system (or apparatus or device). For example, the computer-readable storage medium 804 includes semiconductor memory or solid-state memory, magnetic tape, removable computer diskette, random access memory (RAM), read-only memory (ROM), rigid magnetic disk, and / or optical disk. In one or more embodiments using an optical disk, the computer-readable storage medium 804 includes Compact Disk-Read Only Memory (CD-ROM), Compact Disk-Read / Write (CD-R / W), and / or Digital Video Disc (DVD).

[0115] In one or more embodiments, the storage medium 804 stores computer program code 806 configured to enable the ABMBSS processing circuit 800 to perform some or all of the mentioned process and / or method. In one or more embodiments, the storage medium 804 further stores information such as algorithms that enable the performance of some or all of the mentioned process and / or method.

[0116] The ABMBSS processing circuit 800 includes an I / O interface 810. The I / O interface 810 is coupled to an external circuit. In one or more embodiments, the I / O interface 810 includes a keyboard, keypad, mouse, trackball, trackpad, touchscreen, and / or cursor directional keys for communicating information and commands to the processor 802.

[0117] The ABMBSS processing circuit 800 further includes a network interface 812 coupled to the processor 802. The network interface 812 enables the ABMBSS processing circuit 800 to communicate with a network 814 to which one or more other computer systems are connected. The network interface 812 includes wireless network interfaces such as BLUETOOTH®, WIFI, WiMAX, GPRS, WCDMA®, or wired network interfaces such as ETHERNET, USB, IEEE-864. In one or more embodiments, some or all of the processes and / or methods mentioned are implemented in two or more ABMBSS processing circuits 800.

[0118] The ABMBSS processing circuit 800 is configured to receive information via the I / O interface 810. The information received via the I / O interface 810 includes one or more of the following for processing by the processor 802: instructions, data, design rules, and / or other parameters. The information is transferred to the processor 802 via the bus 808. The ABMBSS processing circuit 800 is configured to receive information about the UI 822 via the I / O interface 810. The information is stored in the computer-readable medium 804 as the user interface (UI) 822.

[0119] In some embodiments, some or all of the processes and / or methods mentioned are implemented as standalone software applications for execution by a processor. In some embodiments, some or all of the processes and / or methods mentioned are implemented as software applications that are part of an additional software application. In some embodiments, some or all of the processes and / or methods mentioned are implemented as plug-ins to a software application.

[0120] In some embodiments, a method for bidirectional mapping includes: a processor storing a relationship between a first service specification and a second service specification in a database; a processor receiving an application programming interface (API) call requesting a second service specification containing a payload containing a relationship type; a processor verifying that the relationship type contained in the payload corresponds to a relationship type of the relationship between the first service specification and the second service specification stored in the database; and, in response to the processor verifying that the relationship type contained in the payload corresponds to a relationship type of the relationship between the first service specification and the second service specification stored in the database, verifying whether a complementary relationship exists between the first service specification and the second service specification. The process includes, in response to the existence of a complementary relationship between the first service specification and the second service specification, the processor updating the first service specification using the dependent service details of the relationship between the first service specification and the second service specification.

[0121] In some embodiments, storing the relationship between a first service specification and a second service specification in a database includes the processor storing one or more predefined relationships between an application bundle and application artifacts, service templates, and descriptors in a database. The database is a service catalog database, and the first and second service specifications contain one or more service specifications.

[0122] In some embodiments, the method further includes the processor storing one or more service specifications having a predefined relationship between an application bundle and one or more application artifacts.

[0123] In some embodiments, receiving an API call requesting a second service specification including a payload containing a relationship type includes the processor receiving a service specification relationship included in the API call, which includes a first service specification identification (ID), a first service specification name, a second service specification role, and a first service specification relationship type.

[0124] In some embodiments, verifying that a relationship type included in a payload corresponds to a relationship type between a first service specification and a second service specification stored in a database includes the processor verifying that a relationship type included in a payload corresponds to a relationship type between a first service specification and a second service specification stored in a relationship table in the database, the relationship table containing the relationship between the first service specification and the second service specification.

[0125] In some embodiments, the relationship table includes one or more of the following: a specification identifier, a service specification role, a service specification relationship type, and a service specification role that is specified.

[0126] In some embodiments, verifying whether a complementary relationship exists between a first service specification and a second service specification includes the processor comparing the target service specification role in the relational table for the first service specification with the second service specification role; the processor comparing the target service specification role in the relational table for the second service specification with the first service specification role; and the processor determining that a complementary relationship exists in response to the fact that the target service specification role for the first service specification matches the service specification role for the second service specification, and the target service specification role for the second service specification matches the service specification role for the first service specification.

[0127] In some embodiments, the method further includes the processor storing a second service specification in a database, which includes a service specification relationship with a first service specification.

[0128] In some embodiments, the apparatus, The system includes a processor and a memory having instructions that, in response to an action performed by the processor, cause the device to receive an application programming interface (API) call requesting a second service specification including a payload containing a relationship type, to cause the device to store a relationship between a first service specification and a second service specification in a database, to receive an application programming interface (API) call requesting a second service specification including a payload containing a relationship type, to cause the device to verify that the relationship type included in the payload corresponds to a relationship type of the relationship between the first service specification and the second service specification stored in the database, to verify whether a complementary relationship exists between the first service specification and the second service specification, and to update the first service specification using the dependent service details of the relationship between the first service specification and the second service specification in response to a complementary relationship existing between the first service specification and the second service specification.

[0129] In some embodiments, the apparatus, The database stores one or more predefined relationships between the application bundle and application artifacts, service templates, and descriptors, and the database is a service catalog database, and the first and second service specifications contain one or more service specifications. The relationship between the first service specification and the second service specification is stored in the database.

[0130] In some embodiments, the device is further configured to store one or more service specifications having predefined relationships between application bundles and one or more application artifacts.

[0131] In some embodiments, the apparatus, By receiving a service specification relationship included in an API call that includes a first service specification identification information (ID), a first service specification name, a second service specification role, and a first service specification relationship type, the system is configured to receive an API call that requests a second service specification that includes a payload containing the relationship type.

[0132] In some embodiments, the apparatus, The system verifies that the relationship type included in the payload corresponds to the relationship type of the relationship between the first service specification and the second service specification stored in a relationship table in the database. The relationship table includes the relationship between the first service specification and the second service specification, thereby verifying that the payload relationship type corresponds to the relationship type of the relationship between the first service specification and the second service specification stored in the database.

[0133] In some embodiments, the relationship table includes one or more of the following: a specification identifier, a service specification role, a service specification relationship type, and a service specification role that is specified.

[0134] In some embodiments, the apparatus, Compare the target service specification role in the relationship table for the first service specification with the second service specification role. The system verifies whether a complementary relationship exists between the first and second service specifications by comparing the target service specification roles in the relationship table for the second service specification with the service specification roles for the first service specification, and determining that a complementary relationship exists in response to the fact that the target service specification roles for the first service specification match the service specification roles for the second service specification, and the target service specification roles for the second service specification match the service specification roles for the first service specification.

[0135] In some embodiments, the device is further configured to store a second service specification in a database, which includes a service specification relationship with a first service specification.

[0136] In some embodiments, a non-temporary computer-readable medium storing instructions that, in response to being executed by a processor, cause the device to store in a database a relationship between a first service specification and a second service specification; receive an application programming interface (API) call requesting a second service specification including a payload containing a relationship type; verify that the relationship type included in the payload corresponds to a relationship type of the relationship between the first service specification and the second service specification stored in the database; verify whether a complementary relationship exists between the first service specification and the second service specification in response to the relationship type included in the payload corresponding to a relationship type of the relationship between the first service specification and the second service specification stored in the database; and update the first service specification using the dependent service details of the relationship between the first service specification and the second service specification in response to the existence of a complementary relationship between the first service specification and the second service specification.

[0137] In some embodiments, the apparatus, The database stores one or more predefined relationships between the application bundle and application artifacts, service templates, and descriptors, and the database is a service catalog database, and the first and second service specifications contain one or more service specifications. The relationship between the first service specification and the second service specification is stored in the database.

[0138] In some embodiments, the device is further configured to store one or more service specifications having predefined relationships between application bundles and one or more application artifacts.

[0139] In some embodiments, the apparatus, By receiving a service specification relationship included in an API call that includes a first service specification identification information (ID), a first service specification name, a second service specification role, and a first service specification relationship type, the system is configured to receive an API call that requests a second service specification that includes a payload containing the relationship type.

[0140] The above outlines some features of embodiments so that those skilled in the art may better understand aspects of the disclosure. Those skilled in the art should understand that the disclosure will readily be used as a basis for designing or modifying other processes and structures to perform the same purposes and / or achieve the same advantages as the embodiments introduced herein. Those skilled in the art should further recognize that such equivalent configurations will not depart from the spirit and scope of the disclosure, and that they will be modified, replaced, and altered in this specification without departing from the spirit and scope of the disclosure.

Claims

1. In a method for bidirectional mapping, The processor stores the relationship between the first service specification and the second service specification in a database, The processor receives an application programming interface (API) call that requests the second service specification, which includes a payload including a relationship type. The processor verifies that the relationship type included in the payload corresponds to the relationship type of the relationship between the first service specification and the second service specification stored in the database, In response to the fact that the relationship type included in the payload corresponds to the relationship type of the relationship between the first service specification and the second service specification stored in the database, the processor verifies whether a complementary relationship exists between the first service specification and the second service specification. A method for bidirectional mapping, comprising: updating the first service specification with the dependent service details of the relationship between the first service specification and the second service specification, in response to the existence of the complementary relationship between the first service specification and the second service specification, by the processor.

2. The above-mentioned relationship between the first service specification and the second service specification is stored in the database, The processor stores in a database predefined relationships between application bundles, application artifacts, service templates, and descriptors, wherein the database is a service catalog database, and the first and second service specifications include one or more service specifications. A method for bidirectional mapping according to claim 1.

3. The processor further includes storing the one or more service specifications having the predefined relationships between the application bundle and one or more application artifacts. The method for bidirectional mapping according to claim 2.

4. The fact that an API call is received to request the second service specification, which includes the payload including the relationship type, The aforementioned processor, First service specification identification information (ID), First service specification name, Second service specification role and Includes receiving a service specification relationship included in the API call, which includes a first service specification relationship type. A method for bidirectional mapping according to claim 1.

5. The act of verifying that the relationship type included in the payload corresponds to the relationship type of the relationship between the first service specification and the second service specification stored in the database is: The processor verifies that the relationship type included in the payload corresponds to the relationship type of the relationship between the first service specification and the second service specification stored in the relationship table stored in the database, wherein the relationship table includes the relationship between the first service specification and the second service specification. The method for bidirectional mapping according to claim 4.

6. The aforementioned relationship table is, Specification identifier, Service specification role, Service specification relationship type and Includes one or more of the service specification roles that are subject to the service specification, The method for bidirectional mapping according to claim 5.

7. Verifying whether the complementary relationship exists between the first service specification and the second service specification is: The processor compares the target service specification role in the relational table for the first service specification with the second service specification role, The processor compares the target service specification role in the relational table for the second service specification with the first service specification role, The processor determines that the complementary relationship exists in response to the fact that the target service specification role for the first service specification matches the service specification role for the second service specification, and the target service specification role for the second service specification matches the service specification role for the first service specification. The method for bidirectional mapping according to claim 6.

8. The aforementioned processor, The further includes storing the second service specification, which includes the service specification relationship with the first service specification, in the database. The method for bidirectional mapping according to claim 6.

9. In the apparatus, Processor and A memory, which, in response to an action performed by the processor, provides the device, The relationship between the first service specification and the second service specification is stored in the database. The system receives an application programming interface (API) call that requests the second service specification, which includes a payload containing the relationship type. The system verifies that the relationship type included in the payload corresponds to the relationship type of the relationship between the first service specification and the second service specification stored in the database. In response to the relationship type included in the payload corresponding to the relationship type of the relationship between the first service specification and the second service specification stored in the database, the system verifies whether a complementary relationship exists between the first service specification and the second service specification. A device comprising: a memory having an instruction to update the first service specification using the dependent service details of the relationship between the first service specification and the second service specification, in response to the existence of the complementary relationship between the first service specification and the second service specification.

10. The apparatus according to claim 9, wherein the apparatus stores in a database one or more predefined relationships between an application bundle and application artifacts, service templates, and descriptors, the database being a service catalog database, and the relationships between the first service specification and the second service specification are stored in the database by the first and second service specifications including one or more service specifications.

11. The aforementioned device is The apparatus according to claim 10, further configured to store one or more service specifications having predefined relationships between application bundles and one or more application artifacts.

12. The aforementioned device is First service specification identification information (ID), First service specification name, Second service specification role and First service specification relationship type By receiving the service specification relationship included in the API call, The apparatus according to claim 9, which is configured to receive the API call for the second service specification, which includes the payload including the relation type.

13. The aforementioned device is The relationship type included in the payload is verified to correspond to the relationship type of the relationship between the first service specification and the second service specification stored in the relationship table stored in the database, and the relationship table includes the relationship between the first service specification and the second service specification, The apparatus according to claim 12, wherein the relationship type included in the payload is configured to verify that it corresponds to the relationship type of the relationship between the first service specification and the second service specification stored in the database.

14. The aforementioned relationship table is, Specification identifier, Service specification role, Service specification relationship type and The apparatus according to claim 13, comprising one or more service specification roles subject to service specification.

15. The aforementioned device is The target service specification role in the relationship table for the first service specification is compared with the second service specification role. The target service specification role in the relationship table for the second service specification is compared with the first service specification role. In response to the fact that the target service specification role for the first service specification matches the service specification role for the second service specification, and the target service specification role for the second service specification matches the service specification role for the first service specification, it is determined that the complementary relationship exists. The apparatus according to claim 14, which is configured to verify whether the complementary relationship exists between the first service specification and the second service specification.

16. The aforementioned device is The apparatus according to claim 15, further comprising storing in a database a second service specification, including a service specification relationship with a first service specification.

17. A non-temporary computer-readable medium that, in response to actions performed by a processor, the device, An instruction to store the relationship between the first service specification and the second service specification in the database, The system receives an application programming interface (API) call that requests the second service specification, which includes a payload containing the relationship type. The system verifies that the relationship type included in the payload corresponds to the relationship type of the relationship between the first service specification and the second service specification stored in the database. In response to the relationship type included in the payload corresponding to the relationship type of the relationship between the first service specification and the second service specification stored in the database, the system verifies whether a complementary relationship exists between the first service specification and the second service specification. A non-temporary computer-readable medium storing an instruction to update the first service specification using the dependent service details of the relationship between the first service specification and the second service specification, in response to the existence of the complementary relationship between the first service specification and the second service specification.

18. The aforementioned device is The database stores one or more predefined relationships between the application bundle and application artifacts, service templates, and descriptors, and the database is a service catalog database, and the first and second service specifications include one or more service specifications, The non-temporary computer-readable medium according to claim 17, wherein the relationship between the first service specification and the second service specification is stored in the database.

19. The aforementioned device is The non-temporary computer-readable medium according to claim 18, further configured to store one or more service specifications having a predefined relationship between an application bundle and one or more application artifacts.

20. The aforementioned device is First service specification identification information (ID), First service specification name, Second service specification role and First service specification relationship type By receiving the service specification relationship included in the API call, A non-temporary computer-readable medium according to claim 17, which is configured to receive the API call that requests the second service specification, which includes the payload including the relation type.

Images