Systems and methods 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 methods of use thereof. [Background technology]

[0002] A cellular network is a telecommunications system in which mobile devices (e.g., mobile phone devices) communicate over radio waves through one or more local antennas at a cellular base station (e.g., cell tower). Cellular service is provided to a coverage area divided into small geographic areas called cells. Each cell is served by a separate low-power multi-channel transceiver and antenna at the cell tower. Mobile devices within a cell communicate through that cell's antenna on multiple frequency channels and separate 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 the part of a telecommunications system that implements radio access technology. The RAN resides between devices such as mobile phones, computers, or remote control machines and provides connectivity to a core network (CN). Depending on the standard, mobile phones and other wirelessly connected devices are variously known as user equipment (UE), terminal equipment (TE), mobile stations (MS), etc. Summary of the Invention [Means for solving the problem]

[0004] In some embodiments, a method for bidirectional mapping includes: storing, by a processor, a relationship between a first service specification and a second service specification in a database; receiving, by the processor, an application programming interface (API) call for the second service specification including a payload including 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; and 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; and updating, by the processor, the first service specification with 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.

[0005] In some embodiments, the device comprises: The apparatus includes a processor; and a memory having instructions that, when executed by the processor, cause the apparatus to store a relationship between a first service specification and a second service specification in a database, receive an application programming interface (API) call for the second service specification including a payload including a relationship type, verify 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, 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 the 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 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.

[0006] In some embodiments, a non-transitory computer-readable medium having stored thereon instructions that, when executed by a processor, cause an apparatus to: store a relationship between a first service specification and a second service specification in a database; receive an application programming interface (API) call for the second service specification including a payload including a relationship type; verify 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; 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 the 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 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.

[0007] Aspects of the present disclosure can be understood from the following detailed description when read in conjunction with the accompanying drawings. In accordance with standard industry practice, various features are not drawn to scale. In some embodiments, the dimensions of various features have been arbitrarily increased or decreased for clarity of discussion. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a diagrammatic representation of a system for network slice design (NSD), according to some embodiments. [Figure 2] 1 is a diagram of a universal network service (NS) bundle, according to some embodiments. [Figure 3] FIG. 1 is a data flow diagram of a method for policy onboarding integration, according to some embodiments. [Figure 4] 1 is a diagrammatic representation of a complementary relationship table, according to some embodiments. [Figure 5] 1 is a diagrammatic representation of a service catalog database, according to some embodiments. [Figure 6] 1 is a data flow diagram representation of a method for automated bidirectional mapping between service specifications (ABMBSS), according to some embodiments. [Figure 6C] 1 is a data flow diagram representation of a method for automated bidirectional mapping between service specifications (ABMBSS), according to some embodiments. [Figure 7] 1 is a visual representation of a method for ABMBSS, according to some embodiments. [Figure 8] FIG. 1 is a high-level functional block diagram of a processor-based system according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0009] The following disclosure provides many different embodiments or examples for implementing the particular features of the discussed subject matter. To simplify the present embodiments, example components, values, operations, materials, arrangements, and the like are described below. These are, of course, examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, and the like are contemplated. For example, forming a first feature over 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 such that the first and second features cannot be in direct contact. Additionally, some embodiments repeat reference numbers and / or characters in multiple instances. This repetition is for the sake of brevity and clarity and is not intended to dictate a relationship between the various embodiments and / or configurations discussed.

[0010] Additionally, spatially relative terms such as below, below, lower, above, upper, etc. are used herein for ease of description to describe the relationship of one element or feature to another element(s) or feature(s) as shown in the figures. Devices may be otherwise oriented (rotated 90 degrees or at other orientations) and the spatially relative descriptors used herein similarly interpreted accordingly.

[0011] A network service (NS) bundle is a bundle that includes technical services, configurations, manifest files, or other suitable services and files within some embodiments. Technical services are further subdivided into different network service descriptors (NSDs) and virtualized network function descriptors (VNFDs). VNFDs are created in application bundles.

[0012] An application bundle file is a single relocatable file containing the artifacts for running an application. The application bundle file is configured to run (or instantiate) on an instance. Moving the application bundle file relocates the application file. With the exception of 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 the execution host (e.g., a smartphone used by a subscriber). Logically, an application bundle file contains the application directory and a portion of the output directory, as well as subdirectories from toolkits contributed to the application. When an application bundle file is presented for execution, it is deployed to all hosts on which the application runs. The application bundle file is then unbundled into a runtime application directory hierarchy similar to the compile-time hierarchy that added any external toolkit entities. Application bundle files have an identifier that uniquely distinguishes one build of an application from another. When an application bundle file is presented for execution, the identifier is used to check whether 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 a network service (NS), which is a configuration of network functions (NFs or applications) arranged as a set of functions with unspecified connectivity between NFs or according to one or more forwarding graphs.

[0014] A network slice (a portion of the original network architecture that has been divided or sliced ​​into multiple logical and independent networks configured to efficiently meet different service requirements) is divided into subnets, where each subnet is dedicated to a particular domain (e.g., RAN, CN, transport domain, or end-to-end (E2E)). A transport domain refers to the telecommunications transmission facility under which voice, data, and video communications are distributed between distant locations for use on a shared basis.

[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 a bundle / package object in the central inventory. The Onboarding Service sends a request to the Policy Manager to create a policy descriptor file (without the source element universally unique identifier (UUID), which is a 128-bit label used for information within computer systems).

[0016] When generated according to standard methods, UUIDs are unique for all practical purposes. Their uniqueness, unlike most other numbering schemes, does not depend on a central registration authority or coordination between the parties that generate them. The probability that a UUID will be duplicated is not zero, but it is close enough to zero to be negligible. Thus, a UUID can be created by anyone and used to identify something with near-certainty that the identifier will not duplicate an identifier already created or to be created to identify something else. Thus, information labeled with UUIDs by independent parties can later be combined into a single database or transmitted over the same channel with negligible probability of duplication.

[0017] The policy manager decides (decision) the degree to which a service / device is allowed to do what it is trying / requesting and can then enforce the decision (enforcement). Some examples of policies include (1) is a customer allowed to use this service? (2) is there enough capacity to support this new service? (3) what happens to non-SLA (service level agreement) customers when a node approaches congestion?, and (4) is a service request / activity 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 a user (e.g., instantiate an NF using an NFT (network function template) that contains a policy descriptor file with the policy ID).

[0019] An instance is created in the central inventory. The Orchestrator deploys the NF / application and sends a notification to the Policy Manager to activate the policy with the respective policy ID. The policy file is modified with the pending information (such as source element UUID). After modifying the pending information, the descriptor is referred to as a policy template. The policy template is now 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 NS bundles, bidirectional relationships between NS bundles and artifact service specifications are maintained. These relationships are used by one or more applications to fetch the NS specifications. There is no check or means to assert whether the pre-agreed relationships are considered valid.

[0022] Artifacts are the separate documents that make up an architecture. Artifacts provide different perspectives for various parties. Artifacts are used to improve communication between different parties.

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

[0024] When registering a bundle, engineers trace from the application bundle to the artifact NS specification and vice versa. However, with 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 system and user load, reduces efficiency, and makes the application less user-friendly.

[0025] TMF is the global trade association for service providers and suppliers in the telecommunications industry. 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 request method in the Hypertext Transfer Protocol (HTTP) for making partial changes to an existing resource. 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 requested 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 relationships. Other approaches could store these relationships in a database so that some of the relationships between two or more services can be configured to be added or removed in the future. In some embodiments, in response to having a bidirectional relationship between two or more NS specifications, an engineer makes the two or more NS specifications unidirectional. Additionally, in some embodiments, an engineer converts a unidirectional relationship to bidirectional.

[0028] In some embodiments, the 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 the POST call, the service catalog checks whether the relationship between two or more specifications provided in the NS specification relationship is valid. In response to the relationship being stored in the service catalog database, the relationship is then valid. In response to the relationship being 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. The service catalog serves as a knowledge management tool for the enterprise's employees and consultants, enabling their requests for services and service-related topics to be routed to the experts who own, are accountable for, and operate them. Each service in 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 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 amount of data of any type is sent to the server in the body of the request message. A header field in a POST request typically indicates the Internet media type of the message body.

[0031] In some embodiments, the service catalog verifies whether a complementary relationship is registered. In some embodiments, the service catalog updates the NS specification mentioned in the NS specification relationship and creates a complementary relationship for the NS specification. No additional PATCH request as described above is required by the user / engineer. In a non-limiting example, an application bundle is registered, then an NF template is registered, and a complementary relationship is created 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., reduces the number of PATCH calls). In some embodiments, the service catalog performs the PATCH calls. In some embodiments, the process increases efficiency as human intervention is reduced, thereby reducing errors caused by human interaction.

[0033] FIG. 1 is a diagrammatic representation of a system for network slice design (NSD) 100, according to some embodiments.

[0034] The NSD system 100 includes a CN 102 communicatively connected to a RAN 104 via a transport network 106 communicatively connected to base stations 108A and 108B (hereinafter, base stations 108), where antennas 110 are wirelessly connected to UEs 112 located within geographic coverage cells 114A and 114B (hereinafter, 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] The CN 102 (also known as a backbone) is the portion of a computer network that interconnects networks, providing a pathway for exchanging information between different local area networks (LANs) or sub-networks. In some embodiments, the CN 102 ties diverse networks together across a wide geographic area, within different buildings in a campus environment, or within the same building.

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

[0037] In a hierarchical telecommunications network, the transport network 106 of the NSD system 100 includes intermediate links between the CN 102 and the RAN 104. The two main methods in mobile backhaul implementations are fiber-based backhaul and wireless point-to-point backhaul. Other methods, such as copper-based wireline, satellite communications, 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 the base station 108 and the UE 112 begins with the transport network 106 connected to the CN 102. In some embodiments, the transport network 106 includes wireline, fiber optic, 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, the base station 108 is a lattice or self-supporting tower, a guy tower, a monopole tower, and a hidden tower (e.g., a tower designed to resemble a tree, a cactus, a water tower, a sign, a lighting standard, and other types of structures). In some embodiments, the base station 108 is a cellular-enabled mobile device site where antennas and electronic communications equipment are typically located on a radio mast, tower, or other elevated structure to create a cell (or adjacent cells) in the network. The elevated structure typically supports antenna(s) 110 and one or more sets of transmitters / receivers (transceivers), digital signal processors, control electronics, remote radio heads (RRHs), primary and backup power sources, and shelters. Base stations are known by other names, such as base transceiver station, mobile telephone mast, or cellular base station. In some embodiments, other edge devices are configured to wirelessly communicate with the UEs. The edge devices provide an entry point to a service provider CN, such as the CN 102. 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 are a type of directional microwave antenna with a sector-shaped radiation pattern. In some embodiments, the sector angle of the arc is a 60°, 90°, or 120° design, with a few extra degrees to ensure overlap. Additionally, sector antennas are mounted in multiples if wider or full-circle 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 mobile devices or other devices and base stations. In some embodiments, antenna(s) 110 are circular antennas. In some embodiments, antenna 110 operates 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 directionality. In some embodiments, antenna(s) 110 are MIMO (multiple-input, multiple-output) antennas that simultaneously transmit and receive two or more data signals over the same wireless channel by taking advantage of multipath propagation.

[0040] In some embodiments, the UE 112 is a computer or computing system. Additionally or alternatively, the UE 112 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 ( FIG. 8 ), which provides a touchscreen interface with physical buttons along with digital buttons and a keyboard or a physical keyboard. In some embodiments, the UE 112 connects to the Internet and interconnects with other devices. Additionally or alternatively, the UE 112 incorporates an integrated camera, functionality for making and receiving voice and video phone calls, video games, and global positioning system (GPS) capabilities. Additionally or alternatively, the UE runs an operating system (OS) that allows capability-specific third-party apps to be installed and executed. In some embodiments, the UE 112 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-facing camera), a pager, a personal navigation device (PND), a wearable computer (such as a calculator watch, smartwatch, head-mounted display, earphones, or biometric device), or a smart card.

[0041] In some embodiments, the geographic coverage cell 114 includes a shape and a 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 (FIG. 1), sector-shaped, or lobe-shaped, although the geographic coverage cell 114 may be configured in almost any shape or size. The geographic coverage cell 114 represents the geographic area in which the antennas 110 and the UEs 112 are configured to communicate.

[0042] Service provider(s) 116 or CSPs are companies, vendors, customers, or organizations that provide Internet backbone access directly to Internet service providers and sell bandwidth or network access to subscribers (using UEs), typically through access to network access points (NAPs). Service providers are sometimes 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 offer 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, the network slice design is GUI-based. In some embodiments, operations include a user entering basic information such as a network slice name, slice type, domain, and shared or non-shared slice selection. Other operations include defining a slice, such as NS profile parameters (holding the original requirements of a communication service instance, such as latency, data rate, and mobility level) required by a northbound interface (e.g., internal to the system or manually from a user), and translating 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 NSSIs).

[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] FIG. 2 is a visual representation of a universal NS bundle 200, according to some embodiments.

[0046] For the purposes of this description, applications and network functions are used interchangeably unless they are to be distinguished from one another.

[0047] In FIG. 2 , NS bundle 202 is an aggregation of technical services 204 (and other services, such as icons 206) that are further subdivided into different NSDs 205 and VNFDs 207. In some embodiments, VNFD 207 is created using application bundles 208, 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 service (NS) / network function (NF) bundle that includes other artifacts such as technical application images, metrics, configuration files, or other suitable files within the scope of some embodiments.

[0048] JSON is an open-standard file format and data-interchange 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 with servers, including that of web applications. JSON is a language-independent data format. JSON is derived from JavaScript, but many modern programming languages ​​include code for generating and parsing JSON-formatted data. JSON filenames use the extension json.

[0049] FIG. 3 is a data flow diagram of a method 300 for policy onboarding integration, according to some embodiments.

[0050] In some embodiments, the method 300 for policy onboarding integration describes operations for policy onboarding integration. Although the operations of the method 300 for policy onboarding integration are described and shown as having a particular order, the operations of the method 300 for policy onboarding integration are configured to be performed in any order unless specifically specified otherwise. The method 300 for policy onboarding integration is implemented as a set of operations, such as operation 302 through operation 320.

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

[0052] In some embodiments, service builder tool 358 is similar to 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 network slices and NS subnets, and orchestrator 360 is responsible for creating NSs and NFs. The process flows from operation 302 to operation 304.

[0053] In some embodiments, method 300 describes a method for the creation and transport of NS bundles. A slice manager handles the NS bundles for further execution of bundle services to northbound systems (handling specific targets of systematic operation). In some embodiments, method 300 describes policy bundles that follow the same principles as bundle processing and includes additional steps that show how policy bundles are managed.

[0054] At operation 304 of the method for policy onboarding integration 300, the onboarding service 350 of the 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, an 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 database entities. The process flows from operation 304 to operation 306.

[0055] At 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 file (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 includes general information about the application bundle as well as modules that the application bundle wants to use or extend. The descriptor file acts as glue between remote applications (e.g., owned by user 362) and applications at the CN, such as CN 102. In some embodiments, when an administrator of a cloud instance installs an application, a descriptor file containing a pointer to the 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 rule-based policy and the policy ID corresponding to the application bundle to the orchestrator 360. The process flows from operation 308 to operation 310.

[0057] At operation 310 of the method for policy onboarding integration 300, a 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 life cycle management (e.g., management, development, and maintenance) of computer programs. The life cycle encompasses 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] At operation 312 of the method for policy onboarding integration 300, a NF instantiation request (e.g., to instantiate an NF using an NFT that includes a policy descriptor file with a policy ID) is received from a user 362. The process flows from operation 312 to operation 314.

[0059] At operation 314 of the method 300 for policy onboarding integration, an NF instance is created in the CI 352. In some embodiments, a user instantiates / installs the NF for which the policy bundle was created. The context of the NF instantiation is included to associate this NF with the policy creation. The process flows from operation 314 to operation 316.

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

[0061] At operation 318 of the method for policy onboarding integration 300, orchestrator 360 sends a notification to policy manager 354 to activate the rule-based policy with the respective policy ID. Thus, when user 362 is using the application, the rule-based policy is in effect for the application. The process flows 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 UUIDs, etc.). After filling the pending information, the policy descriptor file becomes a policy template. The policy template table is updated and the enabling policy ID is activated. In some embodiments, the template references a valid working policy file (i.e., template is a name ecosystem term). A policy template is created once the created policy has parameters for implementing the policy.

[0063] FIG. 4 is a visual representation of a relationship table 400 according to some embodiments.

[0064] FIG. 5 is a visual representation of a service catalog database 500 according to some embodiments.

[0065] 6 and 6C (Continued) are data flow diagram representations of a method 600 for automated bidirectional mapping between service specifications (ABMBSS), according to some embodiments.

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

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

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

[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 in an orchestrator, such as orchestrator 360.

[0070] With other approaches, it is difficult to keep track of the files of each module used for each particular bundle. Therefore, in some embodiments, the service catalog is designed so that in response to a bundle, the service catalog goes through the entire bundle and scans the directory structure, regardless of whether any applications, network services, or network templates are onboarded or registered with the service catalog. In some embodiments, the service catalog identifies which deployment files and which files belong within the orchestrator.

[0071] In some embodiments, the service catalog is a TMF 633 service catalog, as discussed in Figure 7. 633-based modules or products. In some embodiments, input to the service catalog is in the form of TMF 633 payload specifications or service specifications.

[0072] In some embodiments, the service catalog stores payload information for bundles in a database, and regardless of which files a bundle contains, the service catalog goes through each file, identifies the file's priority and which modules use it, and tags the file. In some embodiments, the service catalog identifies a file containing details about the bundle and stores the file. 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 are for files within the bundle.

[0073] In other approaches, the question arose as to 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 comprises a collection of updates, fixes, or extensions 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. Thus, a user with access to a top-level routing bundle can now have top-down access to each module used by a child service specification. This is particularly useful for troubleshooting, because the user has access to the parent service specification or original bundle. Modules are accessed from the bottom up. The user has top-down access, and modules that use child service specifications have bottom-to-top access.

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

[0077] This manual process is burdensome for the creator of the service specification, 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 identifies the relationships and automatically creates paired relationships with other service specifications in response to discovering one or more relationships. 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 a bidirectional type service.

[0078] Some embodiments further include checking whether the relationships defined in the input payload are valid. In some embodiments, a table in a 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 the table validation is to prevent random relationships in the service specification since sensitive data is being handled.

[0079] In another approach, in response to a user already having a registered service specification and the registered service specification being to be registered with 30 other service specifications, the user then sends 30 different patch calls to associate each of the 30 service specifications with the already registered service specification.

[0080] Thus, the contemplated embodiments save users time making those many extra calls, save traffic on the service catalog, and eliminate the manual portion of the registration process. Furthermore, the error rate of the system 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. Thus, continuing with a non-limiting example, a service specification POST API call provided by a user describes a relationship type. Because this service specification depends on an application bundle, the service catalog checks a relationship table and, responsive to the relationships present in the relationship table, a valid relationship now exists. Here, the service catalog verifies whether the relationships are complementary relationships.

[0082] 6 and 6C, in operation 602 of 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 database 500, by a service catalog, such as service catalog 722 of FIG. 7. In some embodiments, the predefined relationships are registered in the service catalog and stored in a DB, such as database 500 of FIG. 5, as relationship table 400 (FIG. 4).

[0083] Relationship table 400 includes a column 402 listing serial numbers (SNOs) of service specifications in order. In some embodiments, the SNO is unlimited. In some embodiments, the SNO is 2 or 30, as discussed above (as shown). In some embodiments, the SNO is a number to quantify the number of service specifications to include in a unilateral or complementary relationship. In some embodiments, the SNO is any other suitable identifier including at least one of one or more numbers, 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] Relationship table 400 includes column 404, with each service specification role described for each service starting with column 402. In the example of Figure 4, SNO 1 is an application bundle as described above, and SNO 2 is a network function template (NFT), as further described 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] Relationship table 400 includes column 406, which details the relationship type for each service specification from column 402. In the example of Figure 4, SNO 1, the "parent," provides SNO 2 with a "child," a Container Network Function Template (CNFT), which depends on the application bundle in a complementary manner.

[0086] Operating system (OS)-level virtualization is an OS paradigm in which the kernel (a computer program at the core of a computer's OS, which generally has complete control over everything in the system) allows the existence of multiple isolated user-space instances called containers. Such instances appear to applications as real computers. Computer programs running on the OS see the resources of that computer (e.g., attached 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 in which target service specification roles in a complementary relationship are described. In the example of 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] Thus, relationship table 400 indicates a 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, relationship table 400 is created by a network operator or network engineer. In some embodiments, the complementary relationship is established during design of the network slice. The process flows from operation 602 to operation 604.

[0089] At operation 604 of ABMBSS method 600, a service catalog, such as service catalog 722 of Figure 7, stores service specifications for bundles and artifacts, such as application bundle service specifications 502, in DB 500. The service specifications 502 include service specification information, such as name identifiers 504 (e.g., appbundlename), IDs 506 (e.g., UUIDs as described in detail above), attachment 508 URLs (e.g., bundle artifact1 and bundle artifact2), and service specification relationships 510, such as relationships to application bundle artifacts.

[0090] In some embodiments, each application bundle identification in the service specification 502 is stored by the service catalog in DB 500. In some embodiments, one or more bundle identifications are stored by the service catalog in DB 500 with the service specification 502. In some embodiments, the service specification identification information is completed by a network operator or engineer. In some embodiments, the service specification identification information is entered and / or registered automatically (e.g., using processing circuitry 800 of FIG. 8 ). The process flows from operation 604 to operation 606.

[0091] In operation 606 of ABMBSS method 600, a user 620 (FIG. 6), such as a network operator or engineer, creates a service specification payload 630 for registering the service specification with the TMF using a POST API call. In the non-limiting example of FIGS. 6 and 6C, a network function template is created for an application bundle and is configured to have a dependency (one-sided) 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, i.e., to distinguish protocol overhead from the actual data. Reliably transmitting a payload of data over a communications network involves transmitting more than just the payload. Transmitting a payload of data also includes transmitting various control and signaling data necessary to reach the destination. This creates so-called protocol overhead, as the additional data does not contribute to the inherent meaning of the message.

[0093] In a non-limiting example, a service specification POST API call, such as service specification POST API call 631, Service specifications => ID: Identification of the application bundle service specification Name: Name of the application bundle service specification Role: The role of the template service specification in the relationship, such as "subordinate" Relationship Type: The relationship between a template service specification and a bundle, e.g. For example, "depends on...".

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

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

[0096] In some embodiments, the service catalog determines whether the role and relationship type included in payload 630 are stored in DB 500 (e.g., relationship table 400). In some embodiments, the determination is a validation of the relationship included in relationship table 400. In the example of FIGS. 6 and 6C, 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-specified role in column 406 is the same as role 622 of payload 630, and therefore the validation is valid and true. In some embodiments, in response to the validation being false, the service catalog notifies the user that the relationship in payload 630 is not valid. The process flows from operation 608 to operation 610.

[0097] At operation 610 of ABMBSS method 600, in response to a valid relationship between payload 630 and 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 an application bundle and an NFT) is valid and true). As discussed above with reference to FIG. 4, the service specification role in column 404 relates to and references the relationship type in column 406 of relationship table 400. Thus, the complementary relationship is valid, and the process flows from operation 610 to operation 612. In some embodiments, in response to the complementary relationship being invalid or false, the service catalog notifies the user that the complementary relationship has not been established or does not exist.

[0098] At operation 612 of ABMBSS method 600, in response to the existence of a complementary relationship (e.g., relationship table 400 is verified to include a complementary relationship), an update is made to application bundle service specification 502 to include dependent service details 626 of the network function template service specification. In the non-limiting example of FIGS. 6 and 6C , service specification 502 is updated with the dependent service specification's ID (e.g., the network function template service specification ID) obtained from service specification POST API call 631, its name (e.g., the network function template name) obtained from service specification POST API call 631, its role (e.g., application bundle) obtained from relationship table 400, and its relationship (e.g., provision to CNFT) further obtained from relationship table 400. In some embodiments, dependent service details 626 are also payloads and are pulled directly from relationship table 400. Continuing with the non-limiting example, 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 ABMBSS method 600, user 620 stores in DB 500 an application bundle service specification 502 with dependent service details 626 that provide valid relationships. Furthermore, application bundle service specification 502 is updated with complementary relationships in a single POST API call (as opposed to two separate POST API calls), as discussed in operation 612. DB 500 also stores a service specification 632 in service specification POST API call 631.

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

[0101] FIG. 7 is a visual representation of a method 700 for automated bidirectional mapping between service specifications (ABMBSS), according to some embodiments.

[0102] 7 is discussed to provide an understanding of a 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 circuitry 802, discussed below with respect to FIG. 8. In some embodiments, some or all of the operations of ABMBSS method 700 are performed according to instructions corresponding to instructions 806, discussed below with respect to FIG. 8.

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

[0104] At operation 702 of ABMBSS method 700, service catalog 722 registers complementary relationships between service specifications in a database, such as DB 500. In some embodiments, the complementary relationships are created based on relationship tables 720 developed by a user, such as user 620. In some embodiments, service specification relationship tables 720 are similar to relationship tables 400 and are also stored in service catalog 722. In FIG. 7, service specification relationship data tables 720 are stored within service catalog 722. In some embodiments, service catalog 722 is a TMF 633 service catalog. In some embodiments, service catalog 722 is a TMF service catalog API that enables a 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 a service specification for the bundle, such as an application bundle service specification 724. In some embodiments, the application bundle service specification 724 is registered with the TMF.

[0106] In some embodiments, the TMF 633 REST API call requests the application bundle service specification 724 to register the application bundle service specification 724 with TMF. Representational state transfer (REST) ​​allows content to be rendered when it is requested, often referred to as dynamic content. The process flows from operation 704 to operation 706.

[0107] At operation 706 of ABMBSS method 700, a network function template service specification 726 is registered for an 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, a REST API call in the TMF 633 requests the NFT service specification 726 to register the NFT service specification 726, which includes a relationship to the application bundle service specification 724 included in the TMF's service specification relationship 728. The process flows from operation 706 to operation 708.

[0108] In operation 708 of ABMBSS method 700, service catalog 722 determines whether a relationship in the payload of service specification relationship 728 exists and is valid in service specification relationship table 720. In a non-limiting example, service specification relationship 728 includes a payload with reference to application bundle service specification 724. Continuing with the non-limiting example, the payload is: Name: Application Bundle (e.g., Application Bundle Service Specification 724) Relationship Type: Depends on Application Bundle Role: Application Bundle Type: Service specification relationship.

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

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

[0111] At operation 712 of the ABMBSS method 700, in response to the existence of a complementary relationship, an update is made to the application bundle service specification 724 to include the dependent service details. Continuing with a non-limiting example, the payload is: Name: Network Function Template Name (e.g., NFT Service Specification 726) Relationship Type: Supply to CNFT Role: Application Bundle Type: Service specification relationship.

[0112] 8 is a block diagram of an automated bidirectional mapping between service specifications (ABMBSS) processing circuit 800, according to some embodiments. In some embodiments, the ABMBSS processing circuit 800 is a general-purpose computing device including a hardware processor 802 and a non-transitory computer-readable storage medium 804. The storage medium 804 is encoded with, i.e., stores, among other things, computer program code 806, i.e., a set of executable instructions such as algorithms, or methods 300, 600, and 700. 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) according to one or more embodiments.

[0113] The processor 802 is electrically coupled to a computer-readable storage medium 804 via a bus 808. The processor 802 is further electrically coupled by the bus 808 to an I / O interface 810. A network interface 812 is further electrically connected to the processor 802 via the bus 808. The network interface 812 connects to a network 814 such 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 on the computer-readable storage medium 804 to enable the ABMBSS processing circuit 800 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 other suitable processing unit.

[0114] In one or more embodiments, computer-readable storage medium 804 is an electronic, magnetic, optical, electromagnetic, infrared, and / or semiconductor system (or apparatus or device). For example, computer-readable storage medium 804 includes semiconductor 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, computer-readable storage medium 804 includes a Compact Disk-Read Only Memory (CD-ROM), a Compact Disk-Read / Write (CD-R / W), and / or a 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 processes and / or methods mentioned. In one or more embodiments, the storage medium 804 further stores information such as algorithms that enable the execution of some or all of the processes and / or methods mentioned.

[0116] The ABMBSS processing circuit 800 includes an I / O interface 810. The I / O interface 810 couples to external circuitry. In one or more embodiments, the I / O interface 810 includes a keyboard, keypad, mouse, trackball, trackpad, touchscreen, and / or cursor direction 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 connect. The network interface 812 includes a wireless network interface such as BLUETOOTH, WIFI, WIMAX, GPRS, WCDMA, etc., or a wired network interface such as ETHERNET, USB, IEEE-864, etc. 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 an I / O interface 810. The information received via the I / O interface 810 includes one or more of instructions, data, design rules, and / or other parameters for processing by the processor 802. The information is transferred to the processor 802 via the bus 808. The ABMBSS processing circuit 800 is configured to receive information regarding a UI 822 via the I / O interface 810. The information is stored in the computer-readable medium 804 as a user interface (UI) 822.

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

[0120] In some embodiments, a method for bidirectional mapping includes: storing, by a processor, a relationship between a first service specification and a second service specification in a database; receiving, by the processor, an application programming interface (API) call for the second service specification including a payload including 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; and 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; and updating, by the processor, the first service specification with 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.

[0121] In some embodiments, storing the relationship between the first service specification and the second service specification in the database includes storing, by the processor, one or more predefined relationships between the application bundle, the application artifact, the service template, and the descriptor in the database; The database is a service catalog database, and the first and second service specifications include one or more service specifications.

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

[0123] In some embodiments, receiving the API call for the second service specification including a payload including a relationship type includes receiving, by the processor, a service specification relationship included in the API call including 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 the relationship type included in the payload corresponds to a relationship type of a relationship between the first service specification and the second service specification stored in the database includes verifying, by the processor, that the relationship type included in the payload corresponds to a relationship type of a relationship between the first service specification and the second service specification stored in a relationship table stored in the database, the relationship table including the relationship between the first service specification and the second service specification.

[0125] In some embodiments, the relationship table includes one or more of a specification identifier, a service specification role, a service specification relationship type, and a service specification target service specification role.

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

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

[0128] In some embodiments, the device comprises: The apparatus includes a processor; and a memory having instructions that, when executed by the processor, cause the apparatus to store a relationship between a first service specification and a second service specification in a database, receive an application programming interface (API) call for the second service specification including a payload including a relationship type, verify 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, 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 the 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 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.

[0129] In some embodiments, the device comprises: storing one or more predefined relationships between the application bundle and the application artifacts, the service templates, and the descriptors in a database, the database being a service catalog database, and the first and second service specifications including one or more service specifications; A relationship between the first service specification and the second service specification is adapted to be stored in a database.

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

[0131] In some embodiments, the device comprises: By receiving a service specification relationship included in the API call including a first service specification identification (ID), a first service specification name, a second service specification role, and a first service specification relationship type, an API call for a second service specification including a payload including the relationship type is received.

[0132] In some embodiments, the device comprises: Verify 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 stored in the database, the relationship table including 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 a specification identifier, a service specification role, a service specification relationship type, and a service specification target service specification role.

[0134] In some embodiments, the device comprises: comparing a target service specification role in a relationship table for the first service specification with a second service specification role; The system is configured to verify whether a complementary relationship exists between the first service specification and the second service specification by comparing a target service specification role in the relationship table for the second service specification with the first service specification role, and determining that a complementary relationship exists in response to the target service specification role for the first service specification matching the service specification role for the second service specification and the target service specification role for the second service specification matching the service specification role for the first service specification.

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

[0136] In some embodiments, a non-transitory computer-readable medium having stored thereon instructions that, when executed by a processor, cause an apparatus to: store a relationship between a first service specification and a second service specification in a database; receive an application programming interface (API) call for the second service specification including a payload including a relationship type; verify 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; 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 the 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 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.

[0137] In some embodiments, the device comprises: storing one or more predefined relationships between the application bundle and the application artifacts, the service templates, and the descriptors in a database, the database being a service catalog database, and the first and second service specifications including one or more service specifications; A relationship between the first service specification and the second service specification is adapted to be stored in a database.

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

[0139] In some embodiments, the device comprises: By receiving a service specification relationship included in the API call including a first service specification identification (ID), a first service specification name, a second service specification role, and a first service specification relationship type, an API call for a second service specification including a payload including the relationship type is received.

[0140] The foregoing outlines features of some embodiments so that those skilled in the art may better understand aspects of the present disclosure. Those skilled in the art will readily appreciate that this disclosure may be used as a basis for designing or modifying other processes and structures to carry out 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 constructions do not depart from the spirit and scope of the present disclosure, and that various changes, substitutions, and alterations may be made herein without departing from the spirit and scope of the present disclosure.

Claims

1. 1. A method for bidirectional mapping, comprising: storing, by a processor, a relationship between the first service specification and the second service specification in a database; receiving, by the processor, an application programming interface (API) call for the second service specification, the second service specification including a payload including a relationship type; verifying, by the processor, 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; 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; and updating, by the processor, in response to the existence of the complementary relationship between the first service specification and the second service specification, the first service specification with dependent service details of the relationship between the first service specification and the second service specification.

2. Storing the relationship between the first service specification and the second service specification in the database includes: storing, by the processor, predefined relationships between application bundles, application artifacts, service templates, and descriptors in the database, wherein the database is a service catalog database and the first and second service specifications include one or more service specifications; The method for bidirectional mapping according to claim 1 .

3. storing, by the processor, the one or more service specifications having the predefined relationships between application bundles and one or more application artifacts.

3. The method for bidirectional mapping according to claim 2.

4. Receiving an API call for the second service specification including the payload including the relationship type includes: by the processor First service specification identification information (ID), First service specification name, A second service specification role and receiving a service specification relationship included in the API call that includes a first service specification relationship type; The method for bidirectional mapping according to claim 1 .

5. 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 includes: 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 a relationship table stored in the database, the relationship table including the relationship between the first service specification and the second service specification.

5. The method for bidirectional mapping according to claim 4.

6. The relationship table includes: Specification identifier, Service specification roll, Service specification relationship types and Service specification target includes one or more of the service specification roles, 6. 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 includes: comparing, by the processor, target service specification roles in the relationship table for the first service specification with the second service specification roles; comparing, by the processor, target service specification roles in the relational table for the second service specification with first service specification roles; determining, by the processor, that the complementary relationship exists in response to the target service specification role for the first service specification matching the service specification role for the second service specification and the target service specification role for the second service specification matching the service specification role for the first service specification.

7. The method for bidirectional mapping according to claim 6.

8. by the processor storing the second service specification in the database, the second service specification including the service specification relationship with the first service specification.

7. The method for bidirectional mapping according to claim 6.

9. In the apparatus, a processor; a memory, which, in response to being executed by the processor, causes the device to: storing a relationship between the first service specification and the second service specification in a database; receiving an application programming interface (API) call for the second service specification, the second service specification including a payload that includes 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 stored in the database; 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 stored in the database; and instructions to update 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 existence of the complementary relationship between the first service specification and the second service specification.

10. 10. The apparatus of claim 9, wherein the apparatus is configured to store one or more predefined relationships between application bundles and application artifacts, service templates, and descriptors in the database, the database being a service catalog database, and the first and second service specifications including one or more service specifications, thereby storing the relationship between the first service specification and the second service specification in the database.

11. The device comprises: The apparatus of 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 device comprises: First service specification identification information (ID), First service specification name, A second service specification role and First Service Specification Relationship Type by receiving a service specification relation included in the API call including The apparatus of claim 9 , wherein the apparatus is adapted to receive the API call for the second service specification that includes the payload that includes the relationship type.

13. The device comprises: 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 a relationship table stored in the database, the relationship table including the relationship between the first service specification and the second service specification; 13. The apparatus of claim 12, wherein the apparatus is adapted to verify 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.

14. The relationship table includes: Specification identifier, Service specification roll, Service specification relationship types and The apparatus of claim 13 , comprising one or more of a service specification target service specification role.

15. The device comprises: comparing a target service specification role in the relationship table for the first service specification with the second service specification role; comparing a target service specification role in the relationship table for the second service specification with a first service specification role; by determining that the complementary relationship exists in response to the target service specification role for the first service specification matching the service specification role for the second service specification and the target service specification role for the second service specification matching the service specification role for the first service specification; The apparatus of claim 14 , wherein the apparatus is adapted to verify whether the complementary relationship exists between the first service specification and the second service specification.

16. The device comprises: The apparatus of claim 15 , further configured to store in the database a second service specification that includes a service specification relationship with the first service specification.

17. A non-transitory computer-readable medium that, in response to being executed by a processor, causes an apparatus to: instructions for storing a relationship between the first service specification and the second service specification in a database; receiving an application programming interface (API) call for the second service specification, the second service specification including a payload that includes a relationship type; verifying 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; 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 stored in the database; a non-transitory computer-readable medium having stored thereon instructions for, in response to the existence of the complementary relationship between the first service specification and the second service specification, updating the first service specification with dependent service details of the relationship between the first service specification and the second service specification;

18. The device comprises: storing one or more predefined relationships between application bundles, application artifacts, service templates, and descriptors in the database, the database being a service catalog database, and the first and second service specifications including one or more service specifications; 20. The non-transitory computer-readable medium of claim 17, adapted to store the relationship between the first service specification and the second service specification in the database.

19. The device comprises:

20. The non-transitory computer-readable medium of claim 18, further configured to store one or more service specifications having predefined relationships between application bundles and one or more application artifacts.

20. The device comprises: First service specification identification information (ID), First service specification name, A second service specification role and First Service Specification Relationship Type by receiving a service specification relation included in the API call including 20. The non-transitory computer-readable medium of claim 17, adapted to receive the API call for the second service specification that includes the payload that includes the relationship type.

Images