TECHNICAL FIELD

The present disclosure is directed to the use of service management platforms in communications networks, and is more particularly directed to techniques for onboarding artifacts to a service management and orchestration platform.

BACKGROUND

The Open Network Automation Platform (ONAP) is an example of what might more generally be referred to as a service management and orchestration platform or, more simply, a service management platform. ONAP provides a comprehensive platform for real-time, policy- driven orchestration and automation of physical and virtual network functions that may enable software, network, IT and cloud providers and developers to rapidly automate new services and support complete lifecycle management. By unifying member resources, ONAP promises to accelerate the development of a vibrant ecosystem around a globally shared architecture and implementation for network automation-with an open standard focus-faster than any one product could on its own.

One use for ONAP is the Cloud Radio Access Network, or Cloud RAN, which is a cloudnative software solution handling compute functionality in the RAN. Cloud RAN is a viable option for communications service providers to have increased flexibility, faster delivery of services, and greater scalability in networks. The vision for Cloud RAN is that service providers can deploy cloud-native networks, virtually everywhere, on any cloud and any server platform.

Coupled with the Cloud RAN concept is the concept of Open RAN. At its simplest, the concept is for a more open radio access network architecture than provided today. The Radio Access Network (RAN) provides the critical technology to connect users, including mobile phones or enterprises, to the mobile network over radio waves. It also acts as a bridge to access all the key applications on the web. Current RAN technology is provided as a hardware and software integrated platform. The ambition for Open RAN is to create a multi-supplier RAN solution that allows for the separation - or disaggregation - between hardware and software with open interfaces and virtualization, hosting software that controls and updates networks in the cloud. The promised benefits include supply chain diversity, solution flexibility, and new capabilities leading to increased competition and further innovation.

The O-RAN Alliance has developed an O-RAN architecture and is developing standards and software for implementing the Open RAN. At the heart of this architecture are what are referred to as RAN Intelligent Controllers, or RICs, which include a non-real-time RIC and a near-real-time RIC, as shown in FIG. 1. The non-real-time RIC is shown at the top, in an Orchestration & Automation layer, which may be implemented using ONAP, for instance. At this layer, design, inventory, policies, and configurations are managed. The near-RT RIC is shown below the Orchestration & Automation Layer, and may be used to implement core network functions and service provider applications.

As part of the Open RAN architecture, two new types of automation applications, xApps and rApps, have been introduced. RAN automation applications, or rApps, are for automation use cases with more than 1 -second automation loops.

An rApp is designed to run on the Non-Real-Time RAN Intelligent Controller (RIC) described by the O-RAN Alliance. The rApp may be used to realize different RAN automation and management use cases, with control loops on a time scale of one second and longer.

For example, five main rApp categories may be defined:

Network evolution rApps,

Network deployment rApps,

Network optimization rApps,

Network healing rApps, and Automation and Al rApps.

Field-proven rApps for both Cloud RAN only, and purpose-built and Open RAN networks, are being considered for some communication systems.

Some existing systems, however, may lack configurations for supporting onboarding of non-standard artifacts.

SUMMARY

To support upgrades of rAPPs for the Cloud RAN, as implemented on a service management and orchestration platform like that described by ONAP, a dedicated non-standard microservice needs to be onboarded to the platform, together with a new version of a network function (NF) type. “Onboarding” is the procedure to transform the software provider’s product or application information into a format specific to the service management and orchestration platform. The dedicated non-standard microservice may be used by rAPP to upgrade any existing NF instance to the target software version. This is illustrated in the example of FIG. 2, which illustrates an example implementation in a data center cloud 190 and an edge cloud 117, where the microservice is referred to as “Canary.” The term “microservice” will be understood as a reference to an architectural style that structures an application as a collection of services (each, a “microservice”) that are, at least as a goal, highly maintainable and testable, loosely coupled, independently deployable, organized around business capabilities, and/or owned by a small team. The microservice architecture may enable the rapid, frequent, and reliable delivery of large, complex applications. As used herein, the term “microservice” should thus be understood as an application component that carries out a specific task.

A problem however, arises in onboarding this or other microservices, which may be specific to a certain vendor or otherwise non-standard. The microservice may be delivered by the vendor and used by a dedicated rAPP, where both the rAPP and the microservice are nonstandard.

ONAP currently allows onboarding of only standard artifacts, i.e., artifacts of relatively few standardized types. In the cloud service archive package (CSAR) package uploaded to the platform, there is a manifest file that contains a list of artifacts within the package. A few keywords are specified by ONAP to allow standard artifact types to be onboarded. For instance, the keyword ‘onap_yang_module’ may be used to list all YANG files in the package. At onboarding, ONAP will recognize it and transform all listed YANG files into a specific folder of the internal package. For any non-standard artifacts, however, the associated files will be dropped at onboarding. This problem is illustrated in FIG. 3, which depicts an example of a CSAR file.

Note that in the present context, “artifact” refers to an information document that provides information or definition of a software product or application, e.g., a service description in a separated file format. The term is used herein consistently with its use in specifications for Topology and Orchestration Specification for Cloud Applications (TOSCA), which specify a file archive format called a cloud service archive (CSAR), but should be understood more generally with respect to the present disclosure. This problem is addressed in the embodiments described herein by defining a new structure, in a package manifest file, that allows onboarding any non-standard artifacts with single standard keywords. More particularly, several of the embodiments described herein use a new keyword, e.g., “onap_dedicated_vendor_app,” to indicate a non-standard artifact. Under this new keyword, three new sub-keywords are used to uniquely identify a group of non-standard use case artifacts. “Non-standard” may refer to the artifact being of a type that is not otherwise categorized on the service management platform - this includes vendor-specific microservices and the like.

In an example method for onboarding artifacts to a service management platform according to the techniques described herein, the artifact is identified, during an onboarding process, using a keyword indicating that the artifact is an artifact of a non-standard type and further using at least two sub-keywords. These at least two sub-keywords comprise a first subkeyword indicating a source or owner of the artifact and a second sub-keyword indicating a name for or type of the artifact. The method comprises selecting one or both of the at least two sub-keywords so that the combination of the first and second sub-keywords is unique among all artifacts on the service management platform. The technique may be used for onboarding application-specific or non-standard artifacts to the platform.

A corresponding method carried out by a platform node comprises the steps of receiving a manifest file, determining that there is an artifact of a non-standard type included in the manifest file, based on the inclusion, in the manifest file of a keyword indicating the presence of an artifact of a non-standard type, and identifying the artifact included in the manifest file using at least two sub-keywords included in the manifest file. Again, the at least two sub-keywords comprise a first sub-keyword indicating a source or owner of the artifact and a second subkeyword indicating a name for or type of the artifact, and the combination of the first and second sub-keywords is unique among all artifacts on the service management platform.

Other example embodiments described herein include nodes, processing circuitry, and computer program products directly corresponding to the methods described above.

According to another aspect of the present disclosure, a method is provided in a node for onboarding artifacts to a service management platform. The method includes receiving an onboarding file (e.g., a manifest file) including a first artifact, where the first artifact is a nonstandard artifact which is not previously defined in the service management platform. The method further includes onboarding a first application corresponding to the first artifact based at least on a first keyword associated with the presence of at least one non-standard artifact in the onboarding file, and at least two sub-keywords including a first sub-keyword associated with at least one of a source and an owner of the first artifact, and a second sub-keyword associated with at least one of a type and a name of the first artifact. The combination of the first and second sub-keywords is unique among all artifacts on the service management platform.

According to one or more embodiments of this aspect, each of the at least two subkeywords includes a sub-keyword name and a respective sub-keyword value. According to one or more embodiments of this aspect, the first sub-keyword includes a vendor identifier that is specific to the source of the first artifact and common to a plurality of artifacts on the service management platform, and the second sub-keyword includes an artifact identifier that is unique among the plurality of artifacts uses the common vendor identifier for the first sub-keyword. According to one or more embodiments of this aspect, the at least two sub-keywords further includes a third sub-keyword keyword indicating at least one data file, and the onboarding of the application is based at least on the at least one data file. According to one or more embodiments of this aspect, the artifact corresponds to a microservice application. According to one or more embodiments of this aspect, the artifact corresponds to a network function application. According to one or more embodiments of this aspect, the service management platform is the Open Network Automation Platform (ONAP). According to one or more embodiments of this aspect, the method further includes onboarding a second application corresponding to a second artifact in the onboarding file based at least on a second instance of the first sub-keyword and an additional second sub-keyword, where the additional second sub-keyword indicates at least one of a type and a name for the second artifact, and the combination of the first sub-keyword and the additional second sub-keyword is unique among a plurality of artifacts on the service management platform. According to one or more embodiments of this aspect, the first subkeyword is globally unique, and the second sub-keyword is unique among all sub-keywords associated with the first sub-keyword. According to one or more embodiments of this aspect, the onboarding of the first application includes transforming the first artifact into another format specific to the service management platform. According to one or more embodiments of this aspect, the onboarding file is a manifest file. According to another aspect of the present disclosure, a node is provided which is configured for onboarding artifacts to a service management platform. The node is configured to and/or includes processing circuitry configured to receive an onboarding file including a first artifact, where the first artifact is a non-standard artifact which is not previously defined in the service management platform. The node is configured to and/or includes processing circuitry configured to onboard a first application corresponding to the first artifact based at least on a first keyword associated with the presence of at least one non-standard artifact in the onboarding file, and at least two sub-keywords including a first sub-keyword associated with at least one of a source and an owner of the first artifact, and a second sub-keyword associated with at least one of a type and a name of the first artifact. The combination of the first and second sub-keywords is unique among all artifacts on the service management platform.

According to one or more embodiments of this aspect, each of the at least two subkeywords includes a sub-keyword name and a respective sub-keyword value. According to one or more embodiments of this aspect, the first sub-keyword includes a vendor identifier that is specific to the source of the first artifact and common to a plurality of artifacts on the service management platform, and the second sub-keyword includes an artifact identifier that is unique among the plurality of artifacts using the common vendor identifier for the first sub-keyword. According to one or more embodiments of this aspect, the at least two sub-keywords further includes a third sub-keyword keyword indicating at least one data file, and the onboarding of the application is based at least on the at least one data file. According to one or more embodiments of this aspect, the artifact corresponds to a microservice application. According to one or more embodiments of this aspect, the artifact corresponds to a network function application. According to one or more embodiments of this aspect, the service management platform is the Open Network Automation Platform (ONAP). According to one or more embodiments of this aspect, the node and/or the processing circuitry is further configured to onboard a second application corresponding to a second artifact in the onboarding file based at least on a second instance of the first sub-keyword and an additional second sub-keyword, where the additional second sub-keyword indicates at least one of a type and a name for the second artifact, and the combination of the first sub-keyword and the additional second sub-keyword is unique among a plurality of artifacts on the service management platform. According to one or more embodiments of this aspect, the first sub-keyword is globally unique, and the second sub- keyword is unique among all sub-keywords associated with the first sub-keyword. According to one or more embodiments of this aspect, the onboarding of the first application includes transforming the first artifact into another format specific to the service management platform. According to one or more embodiments of this aspect, the onboarding file is a manifest file.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates an example O-RAN architecture;

FIG. 2 illustrates an example of a microservice along with a new version of a network function (NF) type;

FIG. 3 illustrates an example CSAR package, illustrating the onboarding of (standard) artifacts;

FIG. 4 is a block diagram illustrating components of an example node, according to some embodiments of the present disclosure;

FIG. 5 illustrates an onboarding process for a Cloud RAN use case, according to some embodiments of the present disclosure;

FIG. 6 is a process flow diagram illustrating an example method in a node for supporting onboarding of non-standard artifacts, according to some embodiments of the present disclosure;

FIG. 7 shows another example method in a node for supporting onboarding of nonstandard artifacts, according to some embodiments of the present disclosure; and

FIG. 8 is a flowchart of an example process in a node for supporting onboarding of nonstandard artifacts, according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

FIG. 4 is a block diagram illustrating an example node that may be configured to carry out one or more of the techniques described herein, e.g., with respect to supporting onboarding of non-standard artifacts. In particular, node 400 may be configured to carry out a method like that shown, e.g., in FIG. 6, e.g., as a vendor node, a method like that shown in FIG. 7, e.g., as a platform node, and/or the method illustrated in FIG. 8. All of the variants of those methods described herein are equally applicable to these nodes.

Node 400 may be or comprise various combinations hardware and/or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. Node 400 includes processing circuitry 402 that is operatively coupled via a bus 404 to an input/output interface 406, a interface circuitry 408, a power source 410, and a memory 412. Other components may be included in other embodiments.

The memory 412 may include one or more computer programs including one or more application programs 414 and data 416, which may include user data, e.g., data generated by a user equipment (UE) for the node 400 or data generated by the node 400 for a UE. Embodiments of the node 400 may utilize only a subset or all of the components shown. Application programs 414 may be implemented in a container-based architecture and may include programs for implementing an ONAP platform, for example, or programs for onboarding components to a services management platform like ONAP. These application programs may be configured to carry out one or more of the techniques described herein, e.g., as in connection with FIG. 6, FIG. 7, and/or FIG. 8. Thus, embodiments of the present disclosure include computer program products, e.g., as instantiated in the memory 412, comprising computer program instructions for execution by a processing circuitry and configured to cause the processing circuitry and the node that contains it to carry out one or more of the techniques described herein.

As discussed above, a dedicated non-standard microservice may need to be onboarded to a service management platform, e.g., along with a new version of a network function (NF) type in a Cloud RAN application. Again, “onboarding” may refer to the procedure to transform the software provider’s product or application information into a format specific to the service management and orchestration platform. A problem, however, is how to onboard this microservice or other non-standard artifacts, which may be specific to a certain vendor or otherwise non-standard, and where “non-standard” means that there is not an already defined type for the artifact in the specifications for the service management platform.

Possible solutions include using an ‘others’ artifact type defined by the platform to onboard the non-standard microservice. A problem with this approach, however, is that one vendor may define the microservice using a dedicated file name, but this file name may not be globally unique. This could be a problem when multiple vendors are involved in a use case, as conflicts cannot be avoided. Another possible solution is to simply define a new artifact type, for each new dedicated use case. A problem with this solution is that one dedicated keyword must be standard for one dedicated use case of one vendor. Considering multiple vendors use case, this approach is not efficient, as it will quickly overload the manifest file.

FIG. 5 illustrates an example new network function (NF) onboarding package structure for the Cloud RAN use case. It is in accordance with the SOL004 package structure defined by ETSI. See ETSI GS NFV-SOL 001 and ETSI GS NFV-SOL 004. This NF onboarding package structure also does not support any non-standard artifacts onboarding.

A better solution to the problem is to define a new keyword, e.g., “onap_dedicated_vendor_app,” for use in identifying non-standard artifacts. Along with this new keyword, two or more new sub-keywords are used to uniquely identify a group of non-standard use case artifacts.

The following is an example of the possible artifact keyword structure format:

- E _xam p| _e begin - onap_dedicated_vendor_app vendor_name: Ericsson app_name: Canary

Source: foo/app.csar

Source: foo/configure.data

Source: foo/readme.txt vendor_name: Ericsson app_name: Montreal

Source: montreal/app.csar

- Example end -

Here, it can be seen that the keyword “onap_dedicated_vendor_app” indicates the presence of at least artifact of a non-standard type. A first sub-keyword, here shown as “vendor_name: Ericsson” identifies the vendor associated with the artifact, and in this example has the value “Ericsson.” A second sub-keyword, here shown as “app_name: Canary,” indicates a name for or type of the artifact, in this case having the value “Canary.” Other sub-keywords, such as “source: ...” can identify or refer to components of the artifact.

Note that in this example, there is a second use of the sub-keywords. The “vendor_name: Ericsson” sub-keyword is used again, along with the sub-keyword “app_name: Montreal.” These sub-keywords refer to a second artifact. Note that while the “vendor_name: Ericsson” sub-keyword is repeated, the “app_name: Montreal” sub-keyword is unique. More generally, the combination of the two (or more) sub-keywords used to identify the non-standard artifact should be unique to the platform. This is facilitated by the use of a “vendor_name: ...” sub-keyword, as the vendor (Ericsson, in this example), need only be responsible for ensuring that all instances of “app_name: ...” are unique among the vendor’s artifacts.

The value of the above sub-keywords shall be provided by the vendor in the onboarding package. The keyword indicating the presence of a non-standard artifact and the sub-keyword’s names (‘vendor_name:’ and “app_name:” in this example) have to be agreed names for the platform, e.g., for ONAP. The value of the ‘vendor_name:’ sub-keyword should be globally unique. The value of ‘app_name:’ sub-keyword should be unique within a vendor. The ‘Source’ sub-keyword indicates a list of files provided for that application.

If another use case is supported, another set of the sub-keywords shall be included in the subsequent line of the manifest file, as shown in the example above. More sub-keywords can be specified if needed, e.g., ‘description’, ‘version’.

At onboarding, the platform, e.g., ONAP, shall look for the sub-keywords if the “onap_dedicated_vendor_app” is found and transform the vendor specific artifacts into the platform’s internal model.

This solution is described here for the cloud RAN use case, but it can be extended to support any use cases without additional standardization work. The techniques described here allow the onboarding of dedicated non-standard application artifacts using a standard way of working - reusing the existing onboarding procedure in ONAP (or other services management platform) and avoiding excessive standardization work to accommodate vendor-specific types. The solution can be extended to onboard any vender specific use case application without impacts on standardization

FIG. 6 is a process flow diagram illustrating an example method according to the techniques described herein, e.g., as performed by a node 400. As shown at Block S510, the method includes identifying an artifact, during an onboarding process, using a keyword indicating that the artifact is of a non-standard type and further using at least two sub-keywords. Those two sub-keywords comprise a first sub-keyword indicating a source or owner of the artifact and a second sub-keyword indicating a name for or type of the artifact.

As shown at Sub-Block S515, the method further comprises selecting one or both of these at least two sub-keywords so that their combination is unique among all artifacts on the service management platform. This can be done, for example, by ensuring that the first subkeyword is globally unique, across the platform, and that the second sub-keyword is unique among all second sub-keywords associated with that first sub-keyword.

As Shown at Sub-Block S520, the method further includes uploading a manifest file identifying the artifact.

In some embodiments, such as the specific examples given herein, each of the at least two sub-keywords comprises a sub-keyword name and a respective sub-keyword value. In some embodiments, the first sub-keyword comprises a vendor identifier that is specific to the source or owner of the artifact and common to multiple artifacts on the service management platform and the second sub-keyword comprises an artifact identifier that is unique among the multiple artifacts using the common vendor identifier for the first sub-keyword. In some embodiments, the at least two sub-keywords further include a third (or fourth, fifth, etc.) sub-keyword keyword indicating a data file or files of the artifact.

In some embodiments or instances, the artifact comprises a microservice. In some embodiments, the artifact may comprise all or part of a network function (NF).

In some embodiments, the service management platform is the Open Network Automation Platform (ONAP).

In some embodiments, the illustrated method may further comprise identifying a second artifact, during the same onboarding process, using a second instance of the first sub-keyword and an additional second sub-keyword, the additional second sub-keyword indicating a name for the second artifact, in which case the additional second sub-keyword is selected so that the combination of the first sub-keyword and the additional second sub-keyword is unique among all artifacts on the service management platform. This can be extended to additional artifacts. In some embodiments, the method further comprises uploading a manifest file listing the artifact, wherein said identifying comprises identifying the artifact in the manifest file, using the keyword and the at least two sub-keywords.

FIG. 7 illustrates another example process, in this case as implemented in a node 400 which is a platform node 400, for receiving a manifest file like those described herein. This method begins, as shown at Block S610, with receiving a manifest file, e.g., via an interface towards a vendor or service provider. The method further comprises, as shown at Block S620, the step of determining that there is an artifact of a non-standard type included in the manifest file, based on the inclusion, in the manifest file of a keyword indicating the presence of an artifact of a non-standard type. As shown at Block S630, the method still further comprises identifying the artifact included in the manifest file using at least two sub-keywords included in the manifest file, the at least two sub-keywords comprising a first sub-keyword indicating a source or owner of the artifact, and a second sub-keyword indicating a name for or type of the artifact. As above, the combination of the first and second sub-keywords is unique among all artifacts on the service management platform.

As above, in some embodiments, each of the at least two sub-keywords comprises a subkeyword name and a respective sub-keyword value. In some embodiments, the first subkeyword comprises a vendor identifier that is specific to the source or owner of the artifact and common to multiple artifacts on the service management platform and the second sub-keyword comprises an artifact identifier that is unique among the multiple artifacts using the common vendor identifier for the first sub-keyword. In some embodiments, the at least two sub-keywords further include a third sub-keyword keyword indicating a data file or files of the artifact.

In some embodiments or instances, the artifact comprises a microservice. In some embodiments or instances, the artifact comprises all or part of a network function. In some embodiments, the service management platform is the Open Network Automation Platform (ONAP).

FIG. 8 is a flowchart of another example process in a node 400 (e.g., a platform node 400, an onboarding node 400, etc.) for supporting onboarding of non-standard artifacts. One or more blocks described herein may be performed by one or more elements of node 400 such as by one or more of processing circuitry 40, bus 404, input/output interface 406, interface circuitry 408, power source 410, memory 412, application programs 414, and/or data 416. Node 400 is configured to receive an onboarding file (e.g., a manifest file) including a first artifact, where the first artifact is a non-standard artifact which is not previously defined in the service management platform. Node 400 is configured to onboard a first application corresponding to the first artifact based at least on a first keyword associated with the presence of at least one non-standard artifact in the onboarding file, and at least two sub-keywords including a first sub-keyword associated with at least one of a source and an owner of the first artifact, and a second sub-keyword associated with at least one of a type and a name of the first artifact. The combination of the first and second sub-keywords is unique among all artifacts on the service management platform.

In some embodiments, each of the at least two sub-keywords includes a sub-keyword name and a respective sub-keyword value. In some embodiments, the first sub-keyword includes a vendor identifier that is specific to the source of the first artifact and common to a plurality of artifacts on the service management platform, and the second sub-keyword including an artifact identifier that is unique among the plurality of artifacts using the common vendor identifier for the first sub-keyword. In some embodiments, the at least two sub-keywords further includes a third sub-keyword keyword indicating at least one data file, and the onboarding of the application is based at least on the at least one data file. In some embodiments, the artifact corresponds to a microservice application. In some embodiments, the artifact corresponds to a network function application. In some embodiments, the service management platform is the Open Network Automation Platform (ONAP). In some embodiments, the node 400 and/or the processing circuitry 402 is further configured to onboard a second application corresponding to a second artifact in the onboarding file based at least on a second instance of the first sub-keyword and an additional second sub-keyword, the additional second sub-keyword indicating at least one of a type and a name for the second artifact, and the combination of the first sub-keyword and the additional second sub-keyword being unique among a plurality of artifacts on the service management platform. In some embodiments, the first sub-keyword is globally unique, and the second sub-keyword being unique among all sub-keywords associated with the first subkeyword. In some embodiments, the onboarding of the first application includes transforming the first artifact into another format specific to the service management platform. In some embodiments, the onboarding file is a manifest file.

Although the computing devices described herein (e.g., node 400, which may be a vendor node, platform node, etc.) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and/or by end users and a wireless network generally.

Abbreviations that may be used in the preceding description include:

PRH PNF Registration Handler

ONAP Open Network Automation Platform PNF Physical network function elM Edge Infrastructure Manager

EC External Controller

SO Service Orchestrator

DCAE Data Collection, Analytics and Events

AAI Active and Available Inventory

VIA Virtual Infrastructure Deployment

OOF ONAP Optimization Framework

Some Examples

Examples of the techniques, apparatuses, and systems described herein include, but are not limited to, the following enumerated examples:

Example Al. A method for onboarding artifacts to a service management platform, the method comprising: identifying an artifact, during an onboarding process, using a keyword indicating that the artifact is an artifact of a non-standard type and further using at least two sub-keywords, the at least two sub-keywords comprising a first sub-keyword indicating a source or owner of the artifact, and a second sub-keyword indicating a name for or type of the artifact; wherein the method further comprises: selecting one or both of the at least two sub-keywords so that the combination of the first and second sub-keywords is unique among all artifacts on the service management platform.

Example A2. The method of Example Al, wherein each of the at least two sub-keywords comprises a sub-keyword name and a respective sub-keyword value.

Example A3. The method of Example Al or A2, wherein the first sub-keyword comprises a vendor identifier that is specific to the source or owner of the artifact and common to multiple artifacts on the service management platform and wherein the second sub-keyword comprises an artifact identifier that is unique among the multiple artifacts using the common vendor identifier for the first sub-keyword.

Example A4. The method of any of Examples A1-A3, wherein the at least two sub- keywords further include a third sub-keyword keyword indicating a data file or files of the artifact. Example A5. The method of any of Examples A1-A4, wherein the artifact comprises a microservice.

Example A6. The method of any of Examples A1-A4, wherein the artifact comprises all or part of a network function.

Example A7. The method of any of Examples A1-A6, wherein the service management platform is the Open Network Automation Platform (ONAP).

Example A8. The method of any of Examples A1-A7, wherein the method further comprises: identifying a second artifact, during the same onboarding process, using a second instance of the first sub-keyword and an additional second sub-keyword, the additional second sub-keyword indicating a name for the second artifact; wherein the method further comprises: selecting the additional second sub-keyword so that the combination of the first subkeyword and the additional second sub-keyword is unique among all artifacts on the service management platform.

Example A9. The method of any of Examples A1-A8, wherein the method comprises uploading a manifest file listing the artifact, wherein said identifying comprises identifying the artifact in the manifest file, using the keyword and the at least two sub-keywords.

Example A 10. A method for onboarding artifacts to a service management platform, the method comprising: receiving a manifest file; determining that there is an artifact of a non-standard type included in the manifest file, based on the inclusion, in the manifest file of a keyword indicating the presence of an artifact of a non-standard type; and identifying the artifact included in the manifest file using at least two sub-keywords included in the manifest file, the at least two sub-keywords comprising a first sub-keyword indicating a source or owner of the artifact, and a second sub-keyword indicating a name for or type of the artifact; wherein the combination of the first and second sub-keywords is unique among all artifacts on the service management platform. Example Al l. The method of Example A 10, wherein each of the at least two subkeywords comprises a sub-keyword name and a respective sub-keyword value.

Example A 12. The method of Example A10 or Al 1, wherein the first sub-keyword comprises a vendor identifier that is specific to the source or owner of the artifact and common to multiple artifacts on the service management platform and wherein the second sub-keyword comprises an artifact identifier that is unique among the multiple artifacts using the common vendor identifier for the first sub-keyword.

Example A13. The method of any of Examples A10-A12, wherein the at least two subkeywords further include a third sub-keyword keyword indicating a data file or files of the artifact.

Example A 14. The method of any of Examples A 10-Al 3, wherein the artifact comprises a microservice.

Example A 15. The method of any of Examples A 10-Al 3, wherein the artifact comprises all or part of a network function.

Example A16. The method of any of Examples A10-A15, wherein the service management platform is the Open Network Automation Platform (ONAP).

Example A17. The method of any of Examples A10-A16, wherein the method further comprises: identifying a second artifact in the manifest file, using a second instance of the first subkeyword included in the manifest file and an additional second sub-keyword included in the manifest file, the additional second sub-keyword indicating a name for the second artifact; wherein the combination of the first sub-keyword and the additional second sub-keyword is unique among all artifacts on the service management platform.

Example Al 8. An onboarding node 400 for onboarding artifacts to a service management platform, the onboarding node 400 comprising: interface circuitry 408 configured to communicate with the service management platform; and processing circuitry 402 operatively coupled to the interface circuitry and configured to identify an artifact, during an onboarding process, using a keyword indicating that the artifact is an artifact of a non-standard type and further using at least two sub-keywords, the at least two sub-keywords comprising a first sub-keyword indicating a source or owner of the artifact and a second sub-keyword indicating a name for or type of the artifact; wherein the processing circuitry 402 is further configured to select one or both of the at least two sub-keywords so that the combination of the first and second sub-keywords is unique among all artifacts on the service management platform.

Example A 19. The onboarding node 400 of Example A 18, wherein each of the at least two sub-keywords comprises a sub-keyword name and a respective sub-keyword value.

Example A20. The onboarding node 400 of Example A18 or A19, wherein the first subkeyword comprises a vendor identifier that is specific to the source or owner of the artifact and common to multiple artifacts on the service management platform and wherein the second subkeyword comprises an artifact identifier that is unique among the multiple artifacts using the common vendor identifier for the first sub-keyword.

Example A21. The onboarding node 400 of any of Examples A18-A20, wherein the at least two sub-keywords further include a third sub-keyword keyword indicating a data file or files of the artifact.

Example A22. The onboarding node 400 of any of Examples A18-A21, wherein the artifact comprises a microservice.

Example A23. The onboarding node 400 of any of Examples A18-A21, wherein the artifact comprises all or part of a network function.

Example A24. The onboarding node 400 of any of Examples A18-A23, wherein the service management platform is the Open Network Automation Platform (ONAP).

Example A25. The onboarding node 400 of any of Examples A18-A24, wherein the processing circuitry 402 is further configured to: identify a second artifact, during the same onboarding process, using a second instance of the first sub-keyword and an additional second sub-keyword, the additional second sub-keyword indicating a name for the second artifact; wherein the processing circuitry 402 is further configured to: select the additional second sub-keyword so that the combination of the first sub-keyword and the additional second sub-keyword is unique among all artifacts on the service management platform. Example A26. The onboarding node 400 of any of Examples A18-A25, wherein the processing circuitry 402 is further configured to upload a manifest file listing the artifact and to identify the artifact in the manifest file using the keyword and the at least two sub-keywords.

Example A27. A platform node 400 for onboarding artifacts to a service management platform, the platform node 400 comprising: interface circuitry 408 configured to communicate with the service management platform; and processing circuitry 402 operatively coupled to the interface circuitry and configured to receive a manifest file, via the interface circuitry 408, determine that there is an artifact of a non-standard type included in the manifest file, based on the inclusion, in the manifest file of a keyword indicating the presence of an artifact; and identify the artifact included in the manifest file using at least two sub-keywords included in the manifest file, the at least two sub-keywords comprising a first sub-keyword indicating a source or owner of the artifact, and a second sub-keyword indicating a name for or type of the artifact; wherein the combination of the first and second sub-keywords is unique among all artifacts on the service management platform.

Example A28. The platform node 400 of Example A27, wherein each of the at least two sub-keywords comprises a sub-keyword name and a respective sub-keyword value.

Example A29. The platform node 400 of Example A27 or A28, wherein the first subkeyword comprises a vendor identifier that is specific to the source or owner of the artifact and common to multiple artifacts on the service management platform and wherein the second subkeyword comprises an artifact identifier that is unique among the multiple artifacts using the common vendor identifier for the first sub-keyword.

Example A30. The platform node 400 of any of Examples A27-A29, wherein the at least two sub-keywords further include a third sub-keyword keyword indicating a data file or files of the artifact.

Example A31. The platform node 400 of any of Examples A27-A30, wherein the artifact comprises a microservice. Example A32. The platform node 400 of any of Examples A27-A30, wherein the artifact comprises all or part of a network function.

Example A33. The platform node 400 of any of Examples A27-A32, wherein the service management platform is the Open Network Automation Platform (ONAP).

Example A34. The platform node 400 of any of Examples A27-A33, wherein the processing circuitry is further configured to: identify a second artifact in the manifest file, using a second instance of the first subkeyword included in the manifest file and an additional second sub-keyword included in the manifest file, the additional second sub-keyword indicating a name for the second artifact; wherein the combination of the first sub-keyword and the additional second sub-keyword is unique among all artifacts on the service management platform.

Example A35. A computer program product for onboarding artifacts to a service management platform, the computer program product comprising computer program instructions configured to cause processing circuitry 402 executing the computer program instructions to: identify an artifact, during an onboarding process, using a keyword indicating that the artifact is an artifact of a non-standard type and further using at least two sub-keywords, the at least two sub-keywords comprising a first sub-keyword indicating a source or owner of the artifact and a second sub-keyword indicating a name for or type of the artifact; wherein the processing circuitry 402 is further configured to select one or both of the at least two sub-keywords so that the combination of the first and second sub-keywords is unique among all artifacts on the service management platform.

Example A36. A computer program product for onboarding artifacts to a service management platform, the computer program product comprising computer program instructions configured to cause processing circuitry 402 executing the computer program instructions to: receive a manifest file; determine that there is an artifact of a non-standard type included in the manifest file, based on the inclusion, in the manifest file of a keyword indicating the presence of an artifact; and identify the artifact included in the manifest file using at least two sub-keywords included in the manifest file, the at least two sub-keywords comprising a first sub-keyword indicating a source or owner of the artifact, and a second sub-keyword indicating a name for or type of the artifact; wherein the combination of the first and second sub-keywords is unique among all artifacts on the service management platform.

Example A37. A computer-readable medium comprising, stored thereupon, the computer program product of Example A35 or A36.