WO2023016679A1

WO2023016679A1 - Categorization of slice profile parameters in nssmf implementation

Info

Publication number: WO2023016679A1
Application number: PCT/EP2022/064375
Authority: WO
Inventors: Dinh Danh LE; Jayachandran DEENADAYALAN
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2021-08-12
Filing date: 2022-05-26
Publication date: 2023-02-16

Abstract

A first network node supporting communication at least with a second network node is described. The first network node comprises a communication interface configured to receive a request to allocate a network portion instance, where the request includes information at least about a network domain from which the network portion instance is to be allocated. The first network node further comprises processing circuitry in communication with the communication interface. The processing circuitry is configured to at least one of: determine a profile artifact based at least in part on the received request, the determined profile artifact including at least a supported attribute and a category corresponding to the supported attribute; and allocate the network portion instance based at least in part on the supported attribute, the category corresponding to the supported attribute, and whether the network portion instance is already available.

Description

CATEGORIZATION OF SLICE PROFILE PARAMETERS IN NSSMF

IMPLEMENTATION

TECHNICAL FIELD

The present disclosure relates to wireless communications, and in particular, to management aspects of network slicing.

BACKGROUND

The Third Generation Partnership Project (3GPP) has developed and is developing standards for Fourth Generation (4G) (also referred to as Long Term Evolution (LTE)) and Fifth Generation (5G) (also referred to as New Radio (NR)) wireless communication systems. Such systems provide, among other features, broadband communication between network nodes, such as base stations, and mobile wireless devices (WD), as well as communication between network nodes and between WDs.

3GPP defines the lifecycle of Network Slice Instance (NSI)/ Network Slice Subnet Instance (NSSI), primarily, into four phases which include preparation, commissioning, operation, and decommissioning. FIG. 1 (reproduced from 3GPP TS 28.530 vl6.2.0) shows an example of management aspects of network slicing, including preparation, commissioning, operation, and decommissioning. 3GPP TS 28.530 vl6.2.0 defines management procedures such as allocation, deallocation, activation and deactivation which map to the different life-cycle phases of an NSVNSSL Applicant’s disclosure addresses the problems encountered in the allocation procedure, e.g., involving the preparation and commissioning phases in the lifecycle of an NSVNSSL

3GPP also defines separate management functions such as Network Slice Management Function (NSMF) and Network Slice Subnet Management Function (NSSMF) for the management of NSI and NSSI, respectively. An NSMF receives the network slice requirements for allocation of NSI in the form of ServiceProfile . The NSMF then translates the received ServiceProfile to different SliceProfiles based on the identified constituents (NSSIs) of the NSI. After the translation, the NSMF delegates the AllocateNssi request to the NSSMF with the corresponding SliceProfile requirement as illustrated in FIG. 2.

The ServiceProfile and SliceProfile are defined as datatypes in 3GPP specifications as shown in the example of FIG. 3 (reproduced from 3GPP TS 28.541 v 17.2.1). The ServiceProfile and SliceProfile serve as user requirements which the management functions (NSMF/NSSMF) use to fulfill a request (i.e., an NSUNSSI allocation request), e.g., by creating or using the existing slice instances (NSI/NSSI).

In addition, 3GPP TS 28.531 vl7.1.0 (2021-09) describes an AllocateNssi procedure that is an intent-based-like procedure, which may require the NSSMF to be capable of providing internal intelligent logic and decision for different steps of the entire procedure to fulfil a user requirement. The user requirement may be represented by the SliceProfile attributes specified in 3GPP TS 28.541 which define a list of attributes to be supplied in the AllocateNssi request but without any indication of how those attributes should (or can) be used. Upon reception of the AllocateNssi request, the NSSMF decides either to select an existing NSSI or to create a new NSSI to fulfill the allocation requirement. However, there is no indication of what parameters of the SliceProfile should be used for selection of an existing instance and what parameters should be used for configuration. This is an important problem to be solved as not having such an indication can produce undesirable results/consequences as part of the allocation procedure. For example, the NSSMF may incorrectly select a service instance when the NSSMF considers some parameters (e.g., Single Network Slice Selection Assistance Information, sNSSAI) in the SliceProfile (which are meant only for resource configuration/reconfiguration purpose) to be a selection parameter. Incorrectly selecting a service instance may have an undesirable impact on service availability, e.g., the selected NSSIs may be configured with incorrect details/information .

SUMMARY

Some embodiments advantageously provide methods, systems, and apparatuses for categorization of SliceProfile attributes, e.g., to aid an NSSMF during an AllocateNssi procedure. A SliceProfile artifact which includes the attributes to be supported and the categories to which they belong is described. The SliceProfile artifact extends a SliceProfile schema, e.g., as defined in 3GPP TS 28.541 vl7.2.1, by including a category and/or category information, e.g., to help the NSSMF determine the parameters/attributes to be used for selection of an instance and the parameters/attributes to be used for resource configuration and/or reconfiguration.

In some embodiments, two phases of the management aspects of network slicing are described:

Preparation (e.g., design-time): The NSSMF is supplied with the SliceProfile artifact that extends the 3 GPP SliceProfile schema with category tags that are used to classify the SliceProfile attributes. The categories supported include selection and configuration. Other categories may be included. As an example, the SliceProfile artifact may be created as (e.g., constructed in a form of) a Topology and Orchestration Specification for Cloud Applications (TOSCA) node type, which include metadata information to represent the categories to which the properties as belong.

Commissioning (e.g., runtime): The NSSMF, being supplied with the predefined SliceProfile artifact, determines the parameters to be used for selection of an existing NSSI and the parameters to be used for configuration/reconfiguration purposes .

The present disclosure provides various benefits including the categorization of parameters/attributes and the use of TOSCA YAML Profile to define SliceProfile artifact containing categorization information. More specifically, the SliceProfile artifact facilitates management by the NSSMF by classifying the SliceProfile attributes to fulfill an allocation of an NSSI. By using category information, the NSSMF is able to identify attributes which are needed to select an NSSI. For example, when the SliceProfile attribute “pLMNId” is categorized as (i.e., marked as) a “selection” attribute in the SliceProfile artifact, the NSSMF may use the “pLMNId” attribute in the AllocateNssi request to identify a matching NSSI which is deployed in the given PLMN, if there is no NSSI found in the given PLMN then the NSSMF shall fail the request. At the same time, the SliceProfile attribute “sNSSAI,” when categorized as a “configuration” attribute, will be used to reconfigure/configure the selected/created NSSI. Therefore, the categorization of ShceProfile attributes enables desired results during allocation processes.

In some embodiments, attributes may be categorized in the ServiceProfile used by the NSMF in the similar manner as categorizing SliceProfile attributes. This may aid the NSMF to fulfill the NSI allocation request with the desired results.

In some other embodiments, further information may be included such as information that needs to be (i.e., may be) supplied in subsequent steps. For example, after having knowledge of what attributes may be used for selection, the NSSMF should know (i.e., may determine) how to use these attributes in selection process (i.e., what conditions and constraints to be applied for each of these attributes to find a match). The NSSMF may decompose each of the attributes to the involved network element configuration parameters (e.g., after having knowledge of what attributes to be used for configuration, in order to apply the configuration toward the network, etc.). In short, the SliceProfile categorization artifact of the present disclosure may be used as a step of the AllocateNssi procedure, and/or a (categorization) mechanism can be extended to fulfil further steps in the end-to-end (AllocateNssi) procedure.

The NSSMF may use TOSCA Simple Profile in YAML described in https://docs. oasis-open. org/tosca/TOSCA-Simple-Profile-YAML/v 1.3/os/TOSCA- Simple-Profile-YAML-vl.3-os.html, for modeling network slice/subnet service templates (NST/NSST). The SliceProfile artifact may be modeled as a TOSCA node type. The NSSMF may use the TOSCA Service Templates to define a service topology of a NSSI. Using the TOSCA model to represent the SliceProfile artifact allows the NSSMF to parse and/or obtain information, e.g., since the NSSMF consumes TOSCA Service Templates for creation of NSSIs. Further, the usage of TOSCA to model the SliceProfiles provides an option to extend standard SliceProfiles with other custom attributes, by utilizing inheritance supported by TOSCA. Categories other than “selection” and “configuration” (e.g.., new categories) may be added, e.g., to fulfill other use-cases.

According to one aspect, a first network node supporting communication at least with a second network node is described. The first network node includes a communication interface configured to receive a request to allocate a network portion instance, where the request includes information at least about a network domain from which the network portion instance is to be allocated. The first network node also includes processing circuitry in communication with the communication interface and configured to at least one of: determine a profile artifact based at least in part on the received request, where the determined profile artifact includes at least a supported attribute and a category corresponding to the supported attribute; and allocate the network portion instance based at least in part on the supported attribute, the category corresponding to the supported attribute, and whether the network portion instance is already available.

In some embodiments, the determined profile artifact is obtained from the second network node.

In some other embodiments, the determined profile artifact is a default profile artifact amended at least to include the category corresponding to the supported attribute.

In one embodiment, the category corresponding to the supported attribute is any one of a selection value and a configuration value. The selection value indicates at least one of the supported attribute is to be used to select the network portion instance from an adaptive inventory and a selection constraint. The configuration value indicates that the supported attribute is to be used to one of configure and reconfigure the network portion instance.

In another embodiment, allocating the network portion instance further includes: if the category corresponding to the supported attribute is the selection value and the information included in the request to allocate the network portion instance indicates that the network portion instance is to be shared, filtering out the supported attribute and invoking an Application Programming Interface (API) to find an existing network portion instance.

In some embodiments, allocating the network portion instance further includes: if the existing network portion instance is not found, requesting another API to create another network portion instance based on the information included in the request to allocate the network portion instance.

In some other embodiments, allocating the network portion instance further includes triggering the first network node to request a third network node to execute one of: a reconfiguration of at least one resource associated with the existing network portion instance; and a configuration of at least another resource associated with the other network portion instance.

In one embodiment, the determined profile artifact is a SliceProfile artifact modeled as a Topology and Orchestration Specification for Cloud Applications (TOSCA) node type.

In another embodiment, the SliceProfile artifact modeled as the TOSCA node type is a domain- specific SliceProfile artifact that includes a derived base node type. The domain- specific SliceProfile artifact includes at least one supported attribute and one category associated with the network domain. The network domain is any one of a Core Network (CN) domain and a Radio Access Network (RAN) domain.

In some embodiments, the first network node is a Service Orchestrator Network Slice Subnet Management Function (NSSMF) node, the second network node is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance (NSSI).

According to another aspect, a method implemented in a first network node supporting communication at least with a second network node is described. The method includes receiving a request to allocate a network portion instance. The request includes information at least about a network domain from which the network portion instance is to be allocated. The method also includes: determining a profile artifact based at least in part on the received request, where the determined profile artifact includes at least a supported attribute and a category corresponding to the supported attribute; and allocating the network portion instance based at least in part on the supported attribute. The category corresponds to the supported attribute, and whether the network portion instance is already available.

According to one aspect, a second network node supporting communication at least with a first network node is described. The second network node includes processing circuitry configured to provide a profile artifact to be transmitted to the first network node based on a request to allocate a network portion instance. The provided profile artifact includes at least a supported attribute and a category corresponding to the supported attribute.

In some embodiments, the second network node further comprises a communication interface in communication with the processing circuitry. The communication interface is configured to receive a default profile artifact including the at least supported attribute.

In some other embodiments, the processing circuitry is further configured to amend the default profile artifact by at least including the category corresponding to the at least supported attribute. The provided profile artifact is based at least in part on the amended default profile artifact.

In one embodiment, the processing circuitry is further configured to cause transmission of the provided profile artifact to the first network node.

In another embodiment, the category corresponding to the supported attribute is any one of a selection value and a configuration value. The selection value indicates at least one of the supported attribute is to be used to select the network portion instance from an adaptive inventory and a selection constraint. The configuration value indicates that the supported attribute is to be used to one of configure and reconfigure the network portion instance.

In some embodiments, the provided profile artifact is a SliceProfile artifact modeled as a Topology and Orchestration Specification for Cloud Applications (TOSCA) node type.

In some other embodiments, the SliceProfile artifact modeled as the TOSCA node type is a domain- specific SliceProfile artifact that includes a derived base node type. The domain- specific SliceProfile artifact includes at least one supported attribute and one category associated with a network domain from which the network portion instance is to be allocated. The network domain is any one of a Core Network (CN) domain and a Radio Access Network (RAN) domain.

In one embodiment, the first network node is a Service Orchestrator Network

Slice Subnet Management Function (NSSMF) node, the second network node is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance (NSSI).

According to another aspect, a method implemented in a second network node supporting communication at least with a first network node is described. The method includes providing a profile artifact to be transmitted to the first network node based on a request to allocate a network portion instance, the provided profile artifact including at least a supported attribute and a category corresponding to the supported attribute.

In some embodiments, the method further includes receiving a default profile artifact including the at least supported attribute.

In some other embodiments, the method further includes amending the default profile artifact by at least including the category corresponding to the at least supported attribute. The provided profile artifact is based at least in part on the amended default profile artifact.

In one embodiment, the method further includes transmitting the provided profile artifact to the first network node.

In some other embodiments, the SliceProfile artifact modeled as the TOSCA node type is a domain- specific SliceProfile artifact that includes a derived base node type. The domain- specific SliceProfile artifact includes at least one supported attribute and one category associated with a network domain from which the network portion instance is to be allocated. The network domain is any one of a Core Network (CN) domain and a Radio Access Network (RAN) domain. In one embodiment, the first network node is a Service Orchestrator Network Slice Subnet Management Function (NSSMF) node, the second network node is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance (NSSI).

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present embodiments, and the attendant advantages and features thereof, will be more readily understood by reference to the following detailed description when considered in conjunction with the accompanying drawings wherein:

FIG. 1 shows typical management aspects of network slicing, including preparation, commissioning, operation, and decommissioning;

FIG. 2 shows a typical allocation of NSVNSSI in a slice management stack;

FIG. 3 shows a typical network slice Network Resource Model (NRM) fragment relationship;

FIG. 4 shows a block diagram of a network node according to some embodiments of the present disclosure;

FIG. 5 shows a flowchart of an example process in a network node for allocating a network portion instance according to some embodiments of the present disclosure;

FIG. 6 shows a flowchart of an example process in another network node for providing a profile artifact including at least a supported attribute and a category according to some embodiments of the present disclosure;

FIG. 7 shows a flowchart of another example process in a network node according to some embodiments of the present disclosure;

FIG. 8 shows a flowchart of another example process in another network node according to some embodiments of the present disclosure;

FIG. 9 shows an example system architecture according to some embodiments of the present disclosure;

FIG. 10 shows an example definition of a domain profile node type according to some embodiments of the present disclosure; and FIG. 11 shows an example allocation of a network portion instance, e.g., an NSSI according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

Before describing in detail exemplary embodiments, it is noted that the embodiments reside primarily in combinations of apparatus components and processing steps related to allocation of a network portion instance, e.g., an NSSI, an NSI, based at least in part on an attribute and a category corresponding to the attribute. Attribute categorization of profile parameters, e.g., SliceProfile parameters, in an NSSMF implementation is described. Accordingly, components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

As used herein, relational terms, such as “first” and “second,” “top” and “bottom,” and the like, may be used solely to distinguish one entity or element from another entity or element without necessarily requiring or implying any physical or logical relationship or order between such entities or elements. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and/or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

In embodiments described herein, the joining term, “in communication with” and the like, may be used to indicate electrical or data communication, which may be accomplished by physical contact, induction, electromagnetic radiation, radio signaling, infrared signaling or optical signaling, for example. One having ordinary skill in the art will appreciate that multiple components may interoperate and modifications and variations are possible of achieving the electrical and data communication.

In some embodiments described herein, the term “coupled,” “connected,” and the like, may be used herein to indicate a connection, although not necessarily directly, and may include wired and/or wireless connections.

The term “network slicing” may refer to slicing a network to transform the network into a set of network portions, e.g., logical networks and/or physical networks, which may be on top of a shared infrastructure. Each network portion, e.g., logical network and/or physical networks, may be configured to serve a defined business purpose and/or comprise a plurality of network resources. A network portion, e.g., network slice, may be a logically separated, self-contained, independent and secured part of the network, targeting different services with different requirements on speed, latency and/or reliability. Network portion characteristics, e.g., network slice characteristics/properties/attributes, may include latency (e.g., low latency), high bandwidth and ultra-reliability, e.g., for critical use cases, or higher latency and lower bandwidth for other use cases. The term “network portion instance” may refer to one or more specific realizations of a network portion, e.g., network slice. A network slice may refer to a logical network that provides specific network capabilities and/or network characteristics, e.g., supporting various service properties such as for network slice customers. Further, a network slice may refer to a logical management element representing a service managed by a management system (such as the Network Slice Management Function (NSMF)). A network portion instance may include a Network Slice Instance (NSI) and/or Network Slice Subnet Instance (NSSI). An NSI may refer to one or more network slice instances and/or associated resources, which may define network portion, e.g., network slice. Components of an NSI may be assembled as network slice subnets (e.g., RAN, 5GC and Transport). An NSSI may refer to an instance of a network slice subnet representing management aspects of a set of managed function instances and/or used resources (e.g., compute, storage, and/or networking resources). An NSSI may be managed independently from an NSI. In the present disclosure, a network portion may be to a network slice and/or a network slice subnet. A network portion instance may be to an NSI and/or an NSSI. The term selection attributes may refer to one or more attributes (e.g., SliceProfile attributes) that may be selected and/or selectable. “Configuration attributes” may refer to one or more attributes usable for configuration and/or reconfiguration. Templates may include service templates and/or configuration templates and/or any other kind of templates. Service templates may refer to templates including one or more features associated with service, e.g., network slice/subnet service templates (NST/NSST), TOSCA Service templates, etc. Configuration templates may refer templates usable for configuration, which may include creation and/or configuration and/or deletion, of network portion(s), network portion instance (s), etc.

The term “network node” used herein can be any kind of network node comprised in communication network, e.g., a radio network, a radio access network, a core network, or any other kind of network, which may further comprise any of base station (BS), radio base station, base transceiver station (BTS), base station controller (BSC), radio network controller (RNC), g Node B (gNodeB or gNB), evolved Node B (eNB or eNodeB), Node B, multi- standard radio (MSR) radio node such as MSR BS, multi-cell/multicast coordination entity (MCE), relay node, donor node controlling relay, radio access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU) Remote Radio Head (RRH), a core network node (e.g., mobile management entity (MME), self-organizing network (SON) node, a coordinating node, positioning node, MDT node, etc.), an external node (e.g., 3rd party node, a node external to the current network), nodes in distributed antenna system (DAS), a spectrum access system (SAS) node, an element management system (EMS), etc. The network node may also be a server (e.g., a physical or virtual server), a laptop, a personal computer, a workstation, and/or any other computing device. The network node may also comprise test equipment. Further, the network node may refer to an NSMF node, an NSSMF node, a catalog node, catalog manager node, a design studio node, a Universal Design Studio (UDS) node, a northbound API (NBI) node, a service instance designer node, a workflow service node, an adaptive inventory node, a Service Orchestrator (SO) node (e.g., an SO-NSSMF node), a Network Function Virtualization Orchestrator (NFVO) node, a Virtualized Network Function Manager (VNFM) node, and a network manager node (e.g., an Ericsson Network Manager (ENM) node). The term “radio node” used herein may be used to also denote a wireless device (WD) such as a wireless device (WD) or a radio network node.

In some embodiments, the non-limiting terms wireless device (WD) or a user equipment (UE) are used interchangeably. The WD herein can be any type of wireless device capable of communicating with a network node or another WD over radio signals, such as wireless device (WD). The WD may also be a radio communication device, target device, device to device (D2D) WD, machine type WD or WD capable of machine to machine communication (M2M), low-cost and/or low-complexity WD, a sensor equipped with WD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), an Internet of Things (loT) device, or a Narrowband loT (NB-IOT) device etc.

Also, in some embodiments the generic term “radio network node” is used. It can be any kind of a radio network node which may comprise any of base station, radio base station, base transceiver station, base station controller, network controller, RNC, evolved Node B (eNB), Node B, gNB, Multi-cell/multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio Unit (RRU) Remote Radio Head (RRH).

Note that although terminology from one particular wireless system, such as, for example, 3GPP LTE and/or New Radio (NR), may be used in this disclosure, this should not be seen as limiting the scope of the disclosure to only the aforementioned system. Other wireless systems, including without limitation Wide Band Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMax), Ultra Mobile Broadband (UMB) and Global System for Mobile Communications (GSM), may also benefit from exploiting the ideas covered within this disclosure.

Note further, that functions described herein as being performed by a wireless device or a network node may be distributed over a plurality of wireless devices and/or network nodes. In other words, it is contemplated that the functions of the network node and wireless device described herein are not limited to performance by a single physical device and, in fact, can be distributed among several physical devices. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

Referring again to the drawing figures, in which like elements are referred to by like reference numerals, there is shown in FIG. 4 an example network node 16 is configured to include an attribute selection unit 24 which is configured to perform any step and/or process and/or features and/or task and for functions described in the present disclosure, e.g., allocate a network portion instance, e.g., an NSSI, an NSI, based at least in part on an attribute and a category corresponding to the attribute. Attribute selection unit 24 may further be configured to select the attribute and/or configure at least a network resource associated with the selected attribute.

Communication system 10 includes the network node 16. The network node 16 includes hardware 28 enabling it to communicate at least with another network node 16. For example, a first network node 16a may communicate with a second network node 16b, a third network node 16c, a fourth network node 16d, a fifth network node 16e, and/or a sixth network node 16g included in communication system 10. In addition, anyone of the network nodes 16a, 16b, 16c, 16d, 16e, 16f, 16g (collectively referred to as network node 16) may communicate with each other. Although six network nodes 16a- 16g have been described, the present disclosure is not limited to six network nodes and may include any quantity of network nodes 16.

The hardware 28 of network node 16 may include a communication interface 30 for setting up and maintaining at least a wireless/wired connection at least with another network node 16. The communication interface 30 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and/or one or more RF transceivers. The communication interface 30 includes an array of antennas 34 to radiate and receive signal(s) carrying electromagnetic waves.

In the embodiment shown, the hardware 28 of the network node 16 further includes processing circuitry 36. The processing circuitry 36 may include a processor 38 and a memory 40. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 36 may comprise integrated circuitry for processing and/or control, e.g., one or more processors and/or processor cores and/or FPGAs (Field Programmable Gate Array) and/or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 38 may be configured to access (e.g., write to and/or read from) the memory 40, which may comprise any kind of volatile and/or nonvolatile memory, e.g., cache and/or buffer memory and/or RAM (Random Access Memory) and/or ROM (Read-Only Memory) and/or optical memory and/or EPROM (Erasable Programmable Read-Only Memory).

Thus, the network node 16 further has software 42 stored internally in, for example, memory 40, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the network node 16 via an external connection. The software 42 may be executable by the processing circuitry 36. The processing circuitry 36 may be configured to control (and/or be implemented to provide) any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed, e.g., by network node 16. Processor 38 corresponds to one or more processors 38 for performing network node 16 functions described herein. The memory 40 is configured to store data, programmatic software code and/or other information described herein. In some embodiments, network node 16 may be configured to store such as in memory 40 (and/or determine such as via processing circuitry 36 (including attribute selection unit 24) and/or provide such as via communication interface 30) one or more of the following: selection attributes 50, configuration attributes 52, service templates 54, configuration templates 56, and network portion profiles 58 (e.g., slice profiles). In some other embodiments, the software 42 may include instructions that, when executed by the processor 38 and/or processing circuitry 36, causes the processor 38 and/or processing circuitry 36 to perform the processes described herein with respect to network node 16. For example, processing circuitry 36 of the network node 16 may include attribute selection unit 24 which is configured to perform any step and/or process and/or features and/or task and for functions described in the present disclosure, e.g., allocate a network portion instance, e.g., an NSSI, an NSI, based at least in part on an attribute and a category corresponding to the attribute and/or to select the attribute and/or configure at least a network resource associated with the selected attribute.

Communication and/or connections between the network nodes 16 is in accordance with the teachings of the embodiments described throughout this disclosure. More precisely, the teachings of some of these embodiments may improve the data rate, latency, and/or power consumption and thereby provide benefits such as reduced user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime, etc. In some embodiments, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve.

Although FIG. 4 shows “unit(s)” such as attribute selection unit 24 as being within a respective processor, it is contemplated that the attribute selection unit 24 may be implemented such that a portion of the unit is stored in a corresponding memory within the processing circuitry. In other words, the units may be implemented in hardware or in a combination of hardware and software within the processing circuitry.

FIG. 5 is a flowchart of an example process in a network node 16, e.g., a first network node 16a, for allocating a network portion instance, e.g., an NSSI. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 36 (including the attribute selection unit 24), processor 38, and/or communication interface 30. Network node 16 such as via processing circuitry 36 and/or processor 38 and/or communication interface 30 is configured to receive (Block S100) a request to allocate a network portion instance, where the request includes information at least about a network domain from which the network portion instance is to be allocated. Network node 16 such as via processing circuitry 36 and/or processor 38 and/or communication interface 30 is further configured to obtain (Block S102) a profile artifact from the second network node 16b based on the received request, where the obtained profile artifact including at least a supported attribute and a category corresponding to the supported attribute. In addition, network node 16 such as via processing circuitry 36 and/or processor 38 and/or communication interface 30 is configured to allocate (Block S104) the network portion instance based at least in part on the supported attribute, the category corresponding to the supported attribute, and whether the network portion instance is already available.

In some embodiments, any one of the first network node 16a, the communication interface 30, and the processing circuitry 36 is further configured to request an execution of a configuration of at least a resource associated with the allocated network portion instance.

In some other embodiments, the obtained profile artifact is a default profile artifact amended at least to include the category corresponding to the supported attribute.

In one embodiment, the category corresponding to the supported attribute is any one of a “selection” value and a “configuration” value. The “selection” value indicates that the supported attribute is to be used to select the network portion instance from an adaptive inventory. The “configuration” value indicates that the supported attribute is to be used to one of configure and reconfigure the network portion instance.

In another embodiment, allocating the network portion instance includes, if the category corresponding to the supported attribute is the selection value and the information included in the request to allocate the network portion instance indicates that the network portion instance is to be shared, the supported attribute is filtered out and an Application Programming Interface (API) is invoked to find an existing network portion instance. If the existing network portion instance is not found, another API is called to create a new network portion instance based on the information included in the request to allocate the network portion instance.

In some embodiments, the obtained profile artifact is a SliceProfile artifact modeled as a Topology and Orchestration Specification for Cloud Applications (TOSCA) node type.

In some other embodiments, the SliceProfile artifact modeled as the TOSCA node type is a domain- specific SliceProfile artifact that includes a derived base node type. The domain- specific SliceProfile artifact includes at least one supported attribute and one category associated with the network domain. The network domain is any one of a Core Network (CN) domain and a Radio Access Network (RAN) domain. In one embodiment, the first network node 16a is Service Orchestrator Network Slice Subnet Management Function (NSSMF) node, the second network node 16b is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance (NSSI).

FIG. 6 is a flowchart of an example process in a network node 16, e.g., a second network node 16b, for providing a profile artifact including at least a supported attribute and a category according to some embodiments of the present disclosure. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 36 (including the attribute selection unit 24), processor 38, and/or communication interface 30. Network node 16 such as via processing circuitry 36 and/or processor 38 and/or communication interface 30 is configured to provide (Block S106) a profile artifact to the first network node 16a based on a request to allocate a network portion instance, where the provided profile artifact includes at least a supported attribute and a category corresponding to the supported attribute.

In some embodiments, any one of the second network node 16b, the communication interface 30, and the processing circuitry 36 is further configured to receive a default profile artifact including the at least supported attribute and amend the default profile artifact by at least including the category corresponding to the at least supported attribute.

In some other embodiments, the category corresponding to the supported attribute is any one of a selection value and a configuration value. The selection value indicates that the supported attribute is to be used to select the network portion instance from an adaptive inventory. The configuration value indicates that the supported attribute is to be used to one of configure and reconfigure the network portion instance.

In one embodiment, the provided profile artifact is a SliceProfile artifact modeled as a Topology and Orchestration Specification for Cloud Applications (TOSCA) node type.

In another embodiment, the first network node 16a is Service Orchestrator Network Slice Subnet Management Function (NSSMF) node, the second network node 16b is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance (NSSI).

FIG. 7 is a flowchart of an example process (i.e., method) in a network node 16, e.g., a first network node 16a, according to some embodiments of the present disclosure. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 36 (including the attribute selection unit 24 and/or any other unit/component of processing circuitry 36 shown in FIG. 4), processor 38, and/or communication interface 30. Network node 16 such as via processing circuitry 36 and/or processor 38 and/or communication interface 30 is configured to receive (Block S108) a request to allocate a network portion instance, where the request includes information at least about a network domain from which the network portion instance is to be allocated. Network node 16 is also configured to: determine (Block SI 10), such as via processing circuitry 36 and/or processor 38 and/or communication interface 30, a profile artifact based at least in part on the received request, the determined profile artifact including at least a supported attribute and a category corresponding to the supported attribute; and allocate (SI 12), such as via processing circuitry 36 and/or processor 38 and/or communication interface 30, the network portion instance based at least in part on the supported attribute, the category corresponding to the supported attribute, and whether the network portion instance is already available.

In some embodiments, the determined profile artifact is obtained from the second network node (16b).

In some other embodiments, allocating the network portion instance further includes triggering the first network node (16a) to request a third network node (16c) to execute one of: a reconfiguration of at least one resource associated with the existing network portion instance; and a configuration of at least another resource associated with the other network portion instance.

In some embodiments, the first network node (16a) is a Service Orchestrator Network Slice Subnet Management Function (NSSMF) node, the second network node (16b) is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance (NSSI).

FIG. 8 is a flowchart of an example process (i.e., method) in a network node 16, e.g., a second network node 16b, according to some embodiments of the present disclosure. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 36 (including the attribute selection unit 24 and/or any other unit/component of processing circuitry 36 shown in FIG. 4), processor 38, and/or communication interface 30. Network node 16 such as via processing circuitry 36 and/or processor 38 and/or communication interface 30 is configured to provide (Block SI 14) a profile artifact to be transmitted to the first network node (16a) based on a request to allocate a network portion instance, where the provided profile artifact includes at least a supported attribute and a category corresponding to the supported attribute.

In one embodiment, the method further includes transmitting the provided profile artifact to the first network node (16a).

In some other embodiments, the SliceProfile artifact modeled as the TOSCA node type is a domain- specific SliceProfile artifact that includes a derived base node type. The domain- specific SliceProfile artifact includes at least one supported attribute and one category associated with a network domain from which the network portion instance is to be allocated. The network domain is any one of a Core Network (CN) domain and a Radio Access Network (RAN) domain. In one embodiment, the first network node (16a) is a Service Orchestrator Network Slice Subnet Management Function (NSSMF) node, the second network node (16b) is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance (NSSI).

Having described the general process flow of arrangements of the disclosure and having provided examples of hardware and software arrangements for implementing the processes and functions of the disclosure, the sections below provide details and examples of arrangements for allocation of a network portion instance, e.g., an NSSI, an NSI, based at least in part on an attribute and a category corresponding to the attribute. Attribute categorization of profile parameters, e.g., SliceProfile parameters, in an NSSMF implementation is described. In some embodiments, the allocation of the network portion instance may be based on selection constraints, i.e., conditions for selection, which may be an attribute and/or part of the category, e.g., category includes one or more selection constraints and/or selection and/or configuration.

FIG. 9 depicts an example system architecture including multiple nodes 16 (e.g., one or more of network nodes 16a-16g) according to the principles of the present disclosure. The example system architecture may be part of communication system 10, e.g., an Ericsson Orchestrator (EO) solution.

The EO solution may include of network node 16a (Service Orchestrator NSSMF) and/or network node 16b (e.g., Catalog Manager (CM) node). Network node 16b may be configured to store artifacts needed for the allocation/creation of a network portion instance, e.g., an NSSI. Network node 16b, e.g., the CM node of the EO, supports service templates and/or configuration templates for creation and configuration of NSSIs. Network node 16b may include service templates 54, configuration templates 56, and/or network portion profiles 58, e.g., slice profiles.

Network node 16a may be a Service Orchestrator (SO) which may be an NSSMF and/or expose at least an Application Programming Interface, e.g., a 3GPP AllocateNssi API. An AllocateNssi operation may be invoked by a service consumer. Network node 16a may extract one or more selection attributes 50 and/or one or more configuration attributes 52 from the AllocateNssi request based on a profile artifact obtained from the network node 16b. An artifact, also referred to as artifact type, may be created/stored in network node 16b, e.g., the CM, and may be called “SliceProfile.” The artifact may be a TOSCA nodetype, e.g., in YAML (i.e., human-readable data-serialization language) format generated in another network node 16c, e.g., a Universal Design Studio (UDS) node, and onboarded to the network node 16b, the CM node. The artifact may represent a SliceProfile defined in a 3GPP Network Resource Model (NRM) and/or may additionally contain a category and/or category information for at least one attribute in the SliceProfile. The artifact may be referred to as a profile artifact and may be used to support at least an NSSMF allocation and/or an NSSMF allocation process. Parameters/attributes of a SliceProfile may be received in an AllocateNssi request. The parameters/attributes may be separated by and/or categorized as “selection” and/or “configuration” parameters, e.g., by making use of category and/or category information available in a SliceProfile artifact obtained from network node 16b, e.g., the CM node. Parameters/attributes identified as “selection,” e.g., having a “selection” value, may be used to select a network portion instance, e.g., an NSSI. The network portion instance, e.g., the NSSI, may be selected from network node 16d, e.g., an Adaptive Inventory node. Parameters/attributes identified as “configuration,” e.g., having a “configuration” value, may be used to configure/reconfigure the selected network portion instance, e.g., the NSSI. In a nonlimiting example, configuration and/or reconfiguration of the selected network portion instance, e.g., the NSSI, may be achieved by sending a request to network node 16e, e.g., a Network Function Virtualization Orchestrator (NFVO) node, network node 16f, e.g., a Virtualized Network Function Manager (VNFM) node, and/or, network node 16g, a network manager node such as an Ericsson Network Manager (ENM) node.

SliceProfile Artifact

Current 3 GPP documentation does not describe an indication of parameters/attributes of a SliceProfile that may be used for selection, creation, and/or reconfiguration of a network portion instance and/or what parameters/attributes to use for configuration and/or reconfiguration. An example list of parameters/attributes described in current 3GPP documentation, e.g., 3GPP TS 28.541 vl7.2.1, is reproduced below as Table 1. Other example lists of parameters/attnbutes are described in 3GPP TS 28.541 vl7.3.0.

Table 1 - Attribute names and corresponding support qualifier

A TOSCA nodetype may be defined, e.g., to categorize SliceProfile inputs/requirements such as attributes. The TOSCA node type may be called SliceProfile and/or may extend a SliceProfile schema by adding a metadata “category” at least for one of the SliceProfile attributes. The metadata “category” may be assigned at least one value from a plurality of values. For example, values such as “selection” and/or “configuration” and/or any other values may be assigned.

A nonlimiting example SliceProfile artifact, e.g., created using TOSCA Simple Profile in YAML v 1.3, is as follows: tosca_definitions_version: tosca_simple_yaml_l_3 node_types: com. eric sson.so.nodes.S liceProfile : derived_from: tosca.nodes.Root properties: sNSSAIList: type: list entry_schema: com.ericsson.so.datatypes.SNSSAI required: true metadata: category :[ configuration ] pLMNIdList: type: list entry_schema: com.erics son. so .datatypes .PLMNId required: true metadata: category :[ configuration ] perfReq: type: list entry_schema: com.erics son. so .datatypes .perfReq required: true metadata: category: [selection, configuration]

In this nonlimiting example, all SliceProfile attributes are tagged with “category” metadata, where each category may include at least one category. For instance, sNSSAIList, pLMNIdList may be used for configuration/reconfiguration purposes, and perfReq may be used for selection and configuration/reconfiguration purposes. Although all attributes of the SliceProfile have been tagged, not all attributes are required to be tagged, i.e., at least one attribute may be tagged with a “category,” e.g., a “category” metadata.

Domain- specific SliceProfile Artifact

The SliceProfile nodetype described above may be a base Nodetype and may be derived, e.g., to define different domain specific SliceProfile nodetypes. By deriving, attributes from the derived object, e.g., the base Nodetype, the attributes and/or properties and/or any other elements that are part of the derived object may be inherited and/or used in another object, e.g., the SliceProfile. For example, the base Nodetype may be derived to define a Core Network (CN) Domain profile, e.g., a .SliceProfile.CN. Similarly, the base Nodetype may be derived to define a Radio Access Network (RAN) domain profile, e.g., a .SliceProfile. RAN. In a nonlimiting example, the attributes and/or properties of each domain may be taken from 3 GPP TS28.541 as shown below in in Tables 2 and 3.

Table 2 - CNSliceSubnetProfile

Table 3 - RANSliceSubnetProfile

FIG. 10 shows an example definition of domain- specific SliceProfile Nodetypes using TOSCA modeling. Similar to a base SliceProflie artifact, a category metadata is added to the properties/attributes of the domain SliceProfile nodetype for categorization purpose. A nonlimiting example of a SliceProfile artifact, e.g., SliceProfile.Core artifact, is as follows. tosca_definitions_version: tosca_simple_yaml_l_3 node_types: com.ericsson.so.nodes. SliceProfile.Core: derived_from: com. eric sson. so. nodes. S liceProfile properties: maxNumberofUEs : type: integer required: false metadata: category: [selection] latency: type: integer required: false metadata: category: [selection] dLThptPerSliceSubnet: type: string required: false metadata: category: [configuration] dLThptPerUEPerSubnet: type : com. eric s son . so . datatype s . dLThptPerUEPerS ubnet required: false metadata: category: [configuration] uLThptPerSliceSubnet: type : com. eric s son . so . datatype s . ULThptPerS liceS ubnet required: false metadata: category: [configuration] uLThptPerUEPerSubnet: type : com. eric s son . so . datatype s . uLThptPerUEPerS ubnet required: false metadata: category: [configuration] maxNumberOfPDUSessions: type: integer required: false metadata: category: [configuration] coverageAreaTAList: type: list entry_schema: integer required: false metadata: category: [selection, configuration] resourceSharingLevel: type: string required: false metadata: category: [selection, configuration] maxPktS ize: type: integer required: false metadata: category: [configuration] sliceSimultaneousUse: type : com. eric s son . so . datatype s . sliceS imultaneou sUse required: false metadata: category: [configuration] delay Tolerance: type : com. eric s son . so . datatype s . delay T olerance required: false metadata: category: [configuration]

In some embodiments, although more than one domain-specific SliceProfile artifact per domain may be created, one domain- specific SliceProfile artifact for each domain (e.g., CN domain, RAN domain) is used. At deployment time each domain SliceProfile may be supplied as a default SliceProfile artifact with default categorization tags. The SliceProfile artifact(s) may be updated, e.g., by a user such as a user with administrator privilege, and/or re-onboarded, e.g., saved, to the Catalog Manager node. Re-onboarding allows overriding/overwriting the existing version of the SliceProfile artifact already stored in the Catalog Manager. Having the reonboarded SliceProfile artifacts including domain- specific SliceProfile artifacts allows the network node, e.g., a first network node 16a acting as the NSSMF node, to resolve which artifact to use based on the domain information (e.g., CN domain, RAN domain) associated with the network portion instance, e.g., the NSSI to be allocated. The artifact can be created in Universal Design Studio (USD), e.g., which may leverage TOSCA modeling to make use of TOSCA features for node-type definition and inheritance.

FIG. 11 shows an example allocation of a network portion instance, e.g., an NSSI or Network Slice Subnet instance. More specifically, the example allocation shows an example overall orchestration flow for an allocation process, e.g., an AllocateNssi process including steps associated with post-deployment, design-time, and runtime.

Post-deployment time

Step S200: At post-deployment of the communication system 10, e.g., an Orchestration System, each domain (e.g., CN domain, RAN domain, Transport domain) may be supplied with an artifact, e.g., a (default) SliceProfile artifact, including default tags. The artifact, e.g., a (default) SliceProfile artifact, may be created in network node 16 c, e.g., the Universal Design Studio (UDS) using TOSCA Simple Profile in YAML, and/or onboarded to network node 16b, e.g., the Catalog Manager (CM) node.

Design-time

Step S202: the SliceProfile artifact may be updated, e.g., by user with Administrator privilege, and re-onboard the updated SliceProfile artifact to network node 16b, the CM node. Updating and re-onboarding may override the exiting version of the artifact already stored in network node 16b, e.g., the CM node.

Runtime

Step S204: A Northbound API (NBI) user, e.g., network node 16d such as an NSMF node, sends a request, e.g., 3GPP AllocateNssi request, to network node 16a, e.g., the NSSMF node, to allocate a network portion instance, e.g., an NSSI. The request to allocate the network portion instance, e.g., AllocateNssi, may include SliceProfile parameters/attributes which includes the information about a desired domain (e.g., CN domain, RAN domain) from which the network portion instance, e.g., the NSSI, will be allocated. Network node 16a, e.g., the NSSMF node, may use the domain information to obtain a profile artifact, e.g., a SliceProfile artifact, corresponding to the desired domain from network node 16b, e.g., the Catalog Manager (see Step S206).

As shown in Table 1 above, the SliceProfile may include at least one key indicating the information of the domain (e.g., CN, RAN, Top). For example, the key may be attribute CNSliceSubnetProfile for Core domain, RANSliceSubnetProfile for RAN domain, and/or TopSliceSubnetProfile for Top-level cross-domain. In some embodiments, each domain has one corresponding profile artifact (e.g., the SliceProfile artifact), the network node 16a, e.g., the NSSMF, may fetch the corresponding profile artifact from network node 16b, e.g., the CM node, based at least in part on the domain information.

Step S206: Network node 16a, e.g., the NSSMF, fetches the profile artifact, e.g., SliceProfile artifact, from network node 16b, e.g., the CM node, based at least in part on the domain information described in step S 112. The network node 16b may extract the categories based on the metadata tags (e.g., category: [selection], category: [configuration], category: [selection, configuration]) from the profile artifact, e.g., the SliceProfile artifact.

Steps S208 and S210: network node 16a, e.g., the NSSMF determines whether to use an existing network portion instance or create a new portion instance, e.g., determining whether to use an NS SI or create a new NS SI, which may be based on network slice subnet related requirements.

Step S208: If a network portion requirement such as network slice subnet related requirement indicates that a requested network portion instance (e.g., a NSSI), is to be shared, network node 16a (e.g., the NSSMF), filters out input parameters of the request to allocate the network portion instance (e.g., the AllocateNssi request) that are tagged with “selection,” and/or invokes an API (e.g., “selectNSSI” API) on network node 16e (e.g., the Service Instance Designer node) to find a network portion instance (e.g., an NSSI) corresponding to the requirements.

Step S210. If no network portion instance (e.g., the NSSI) is found, network node 16a (e.g., the NSSMF node) may call another API (e.g., a “createNSSI” API) on network node 16e (e.g., the Service Instance Designer) to create a new network portion instance (e.g., the new NSSI) based on all the input parameters or based on some parameters.

Step S212: Network node 16a (e.g., the NSSMF node) calls network node 16f (e.g., a Workflow Service node) to execute a reconfiguration on the resources of the existing network portion instance (e.g., the existing NSSI) found in Step SI 16 and/or configuration of resources of the new network portion instance (e.g., the new NSSI) created in Step S210, based on parameters tagged with the “configuration” category.

The following Subsections (i.e., Subsections A, B, and C) provide nonlimiting examples of how certain aspects of the proposed solutions could be implemented within the framework of a specific communication standard. In particular, the following Subsections provide non-limiting examples of how the proposed solutions could be implemented within the framework of a 3GPP TSG RAN standard. The changes described by the Subsections are merely intended to illustrate how certain aspects of the proposed solutions could be implemented in a particular standard. However, the proposed solutions could also be implemented in other suitable manners, both in the 3GPP Specification and in other specifications or standards.

SUBSECTION A

3GPP TSG-SA5 Meeting #138-e S5-21xxxx

Source: Ericsson

Title: Producer handling aspects of sliceProfile attributes

Document for: Discussion

Agenda Item: TBD

1 Decision/action requested

The group is asked to take note of the following described

2 References

[1] 3GPP TS 28.530: "Management and orchestration; Concepts, use cases and requirements"

[2] 3GPP TS 28.531: "Management and orchestration; Provisioning"

[3] 3GPP TS 28.541: "Management and orchestration; 5G Network Resource

Model (NRM); Stage 2 and stage 3"

[4] TOSCA: "TOSCA Simple Profile in YAML Version 1.3 YAML vl.3"

3 Rationale

3.1 Introduction

There have been various discussions and proposals in past meetings about the use of SliceProfile attributes. The text in the specifications is written is such a way that it is left to implementation on how a single attribute should be used by a producer application.

3.2 Use case description

For the allocation of network slices the standard specifies procedure and operation in TS 28.531 [2]. The operation for allocation of a network slice subnet is allocateNssi. With this operation an MnS consumer can request an MnS producer to allocate a network slice subnet according to the requirements specified in the attributeListln.

The input parameters in an attributeListln are specified in the SliceProfile [2] is shown is Table 3.1.1.

Table 3.1.1 Input parameters for AllocateNssi operation.

The specification does not give any guidance to a developer and/or implementor on how each and all individual attributes should be treated by the producer other than the following description in 6.5.2 [2].

“The provider may create a new NSSI or using existing NSSI to satisfy the request. The requirements in the request are compared/matched against the actual capabilities of all candidate NSSIs by the provider.

It is clearly left to the implementation of the producer application which requirements are used for comparing/matching. This discussion paper gives an example of how an implementation can use the SliceProfile attributes.

3.2 Example of how an implementation can use the SliceProfile attributes

There is no indication of what parameters of the SliceProfile should be used for selection of instance and what parameters to be used for configuration/reconfiguration. This is an important problem to be solved as it can bring in undesirable results as part of the allocation procedure. For example, the Network Slice Subnet Management Function (NSSMF) may wrongly select a service instance when it considers some parameters (e.g., pLMNInfoList) in the SliceProfile which are meant only for resource configuration/reconfiguration purpose. This can have huge impacts on the service availability as the existing NSSI’s might be wrongly selected and configured with wrong details. To address the above problem, we propose a solution to categorize the SliceProfile attributes to aid the NSSMF during the AllocateNssi procedure. The solution proposal involves the introduction of a SliceProfile artifact which contains information about the attributes to be supported and the categories to which they belong. This SliceProfile artifact extends the SliceProfile schema as defined in TS 28.541 [3] with the category information to help NSSMF determine the parameters to be used for selection of instance and those to be used for resource (re)configuration purpose.

Table 3.1. gives an example of providing a TOSCA YAML artifact [4] to augment the SliceProfile attributes with categorization information. Accordingly, we supply each SliceProfile attribute with a metadata tag called category, which can have values of “selection”, or “configuration”, or both. Only the attributes tagged with “selection” or both are used in instance selection process, while the attributes tagged with “configuration” (e.g., pLMNInfoList) are not.

Table 3.1: Example of adding category information for each attribute using TOSCA YAML Profile [4]

The categorization artifact needs to be supplied to the NSSMF producer at Preparation phase so that it can be used by the NSSMF at Commissioning phase. Note that the categorization information should not be fixed, i.e., it should be changeable/configurable for the NSSMF to fulfill different business use cases. Let’s take the coverageAreaTAList as an example, in the one allocateNssi request, the coverageAreaTAList input can be translated to configuration parameters and used for configuring the radio cells to support a new RAN network slice subnet instance (NSSI). In a subsequent allocateNssi request, the coverageAreaTAList input can be used to look for any existing NSSI that has the radio cells whose coverageAreaTAList can support the new NSSI allocation request. In this later case, the coverageAreaTAList will be used for selection of existing service.

Note that the same mechanism is applied to classifying ServiceProfile attributes, i.e., the Network Slice Management Function (NSMF) shall be supplied with an artifact that contain categorization information along with the ServiceProfile attributes to aid the NSMF in handling the requirements specified in ServiceProfile 4 Detailed proposal

The group is asked to take note of the information described in section 3. SUBSECTION B

3GPP TSG-SA5 Meeting #138-e S5-21xxxx

28.541 CR (Change Request) Current version: 17.3.0

Annex X (informative): AllocateNssi AttributeListln handling example

The attributes in a network slice subnet profile may be used to fulfil different management requirements, an example for handling of attributes in an attributeListln of the AllocateNssi operation is given in Table X.l for the SliceProfile and Table X.2 for CNSliceSubnetProfile, RANSliceSubnetProfile and TopSliceSubnetProfile.

Table 3.1.1: Handling of SliceProfile parameters

Table 3.1.2: Handling of parameters contained within CNSliceSubnetProfile, RANSliceSubnetProfile and TopSliceSubnetProfile

SUBSECTION C

3GPP TSG-SA5 Meeting #138-e S5-21xxxx CR-Form-vl2.1

28.531 CR (Change Request) Current version: 17.0.

6.5.2 AllocateNssi operation

6.5.2.1 Description

This operation is invoked by allocateNssi operation service consumer to request the provider to allocate a network slice subnet instance to satisfy the network slice subnet related requirements. The provider may create a new NSSI or using existing NSSI to satisfy the request. The requirements in the request are compared/matched against the actual capabilities of all candidate NSSIs by the provider. If an existing NSSI can be found e.g., with the right coverage and with good enough latency, it is eligible for allocation. In case not, a new NSSI is created with capabilities to host the service, if enough resources are available.

6.5.2.2 Input parameters

6.5.2.3 Output parameters

The following is a nonlimiting list of example embodiments: Embodiment Al. A first network node supporting communication at least with a second network node, the first network node configured to, and/or comprising a communication interface and/or comprising processing circuitry configured to: receive a request to allocate a network portion instance, the request including information at least about a network domain from which the network portion instance is to be allocated; obtain a profile artifact from the second network node based on the received request, the obtained profile artifact including at least a supported attribute and a category corresponding to the supported attribute; and allocate the network portion instance based at least in part on the supported attribute, the category corresponding to the supported attribute, and whether the network portion instance is already available.

Embodiment A2. The first network node of Embodiment Al, wherein any one of the first network node, the communication interface, and the processing circuitry is further configured to: request an execution of a configuration of at least a resource associated with the allocated network portion instance.

Embodiment A3. The first network node of any one of Embodiments Al and A2, wherein the obtained profile artifact is a default profile artifact amended at least to include the category corresponding to the supported attribute.

Embodiment A4. The first network node of any one of Embodiments Al- A3, wherein the category corresponding to the supported attribute is any one of a selection value and a configuration value, the selection value indicating that the supported attribute is to be used to select the network portion instance from an adaptive inventory, the configuration value indicating that the supported attribute is to be used to one of configure and reconfigure the network portion instance.

Embodiment A5. The first network node of Embodiment A4, wherein allocating the network portion instance includes: if the category corresponding to the supported attribute is the selection value and the information included in the request to allocate the network portion instance indicates that the network portion instance is to be shared, filtering out the supported attribute and invoking an Application Programming Interface (API) to find an existing network portion instance; and if the existing network portion instance is not found, calling another API to create a new network portion instance based on the information included in the request to allocate the network portion instance.

Embodiment A6. The first network node of any one of Embodiments Al- A5, wherein the obtained profile artifact is a SliceProfile artifact modeled as a Topology and Orchestration Specification for Cloud Applications (TOSCA) node type.

Embodiment A7. The first network node of Embodiment A6, wherein the SliceProfile artifact modeled as the TOSCA node type is a domain- specific SliceProfile artifact that includes a derived base node type, the domain-specific SliceProfile artifact including at least one supported attribute and one category associated with the network domain, the network domain being any one of a Core Network (CN) domain and a Radio Access Network (RAN) domain.

Embodiment A8. The first network node of any one of Embodiments Al- A7, wherein the first network node is Service Orchestrator Network Slice Subnet Management Function (NSSMF) node, the second network node is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance (NSSI).

Embodiment Bl. A method implemented in a first network node supporting communication at least with a second network node, the method comprising: receiving a request to allocate a network portion instance, the request including information at least about a network domain from which the network portion instance is to be allocated; obtaining a profile artifact from the second network node based on the received request, the obtained profile artifact including at least a supported attribute and a category corresponding to the supported attribute; and allocating the network portion instance based at least in part on the supported attribute, the category corresponding to the supported attribute, and whether the network portion instance is already available. Embodiment B2. The method of Embodiment Bl, wherein the method further includes: requesting an execution of a configuration of at least a resource associated with the allocated network portion instance.

Embodiment B3. The method of any one of Embodiments B 1 and B2, wherein the obtained profile artifact is a default profile artifact amended at least to include the category corresponding to the supported attribute.

Embodiment B4. The method of any one of Embodiments B 1-B3, wherein the category corresponding to the supported attribute is any one of a selection value and a configuration value, the selection value indicating that the supported attribute is to be used to select the network portion instance from an adaptive inventory, the configuration value indicating that the supported attribute is to be used to one of configure and reconfigure the network portion instance.

Embodiment B5. The method of Embodiment B4, wherein allocating the network portion instance includes: if the category corresponding to the supported attribute is the selection value and the information included in the request to allocate the network portion instance indicates that the network portion instance is to be shared, filtering out the supported attribute and invoking an Application Programming Interface (API) to find an existing network portion instance; and if the existing network portion instance is not found, calling another API to create a new network portion instance based on the information included in the request to allocate the network portion instance.

Embodiment B6. The method of any one of Embodiments B 1-B5, wherein the obtained profile artifact is a SliceProfile artifact modeled as a Topology and Orchestration Specification for Cloud Applications (TOSCA) node type.

Embodiment B7. The method of Embodiment B6, wherein the SliceProfile artifact modeled as the TOSCA node type is a domain- specific SliceProfile artifact that includes a derived base node type, the domain- specific SliceProfile artifact including at least one supported attribute and one category associated with the network domain, the network domain being any one of a Core Network (CN) domain and a Radio Access Network (RAN) domain. Embodiment B8. The method of any one of Embodiments B 1-B7, wherein the first network node is Service Orchestrator Network Slice Subnet Management Function (NSSMF) node, the second network node is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance (NSSI).

Embodiment Cl. A second network node supporting communication at least with a first network node, the second network node configured to, and/or comprising a communication interface and/or comprising processing circuitry configured to: provide a profile artifact to the first network node based on a request to allocate a network portion instance, the provided profile artifact including at least a supported attribute and a category corresponding to the supported attribute.

Embodiment C2. The second network node of Embodiment C 1 , wherein in any one of the second network node, the communication interface, and the processing circuitry is further configured to: receive a default profile artifact including the at least supported attribute; and amend the default profile artifact by at least including the category corresponding to the at least supported attribute.

Embodiment C3. The second network node of any one of Embodiments Cl and C2, wherein the category corresponding to the supported attribute is any one of a selection value and a configuration value, the selection value indicating that the supported attribute is to be used to select the network portion instance from an adaptive inventory, the configuration value indicating that the supported attribute is to be used to one of configure and reconfigure the network portion instance.

Embodiment C4. The second network node of any one of Embodiments C1-C3, wherein the provided profile artifact is a SliceProfile artifact modeled as a Topology and Orchestration Specification for Cloud Applications (TOSCA) node type.

Embodiment C5. The second network node of Embodiment C4, wherein the SliceProfile artifact modeled as the TOSCA node type is a domain-specific SliceProfile artifact that includes a derived base node type, the domain-specific SliceProfile artifact including at least one supported attribute and one category associated with the network domain, the network domain being any one of a Core Network (CN) domain and a Radio Access Network (RAN) domain.

Embodiment C6. The second network node of any one of Embodiments C1-C5, wherein the first network node is Service Orchestrator Network Slice Subnet Management Function (NSSMF) node, the second network node is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance (NSSI).

Embodiment DI. A method implemented in a second network node supporting communication at least with a first network node, the method comprising: providing a profile artifact to the first network node based on a request to allocate a network portion instance, the provided profile artifact including at least a supported attribute and a category corresponding to the supported attribute.

Embodiment D2. The method of Embodiment DI, wherein the method further includes: receiving a default profile artifact including the at least supported attribute; and amending the default profile artifact by at least including the category corresponding to the at least supported attribute.

Embodiment D3. The method of any one of Embodiments DI and D2, wherein the category corresponding to the supported attribute is any one of a selection value and a configuration value, the selection value indicating that the supported attribute is to be used to select the network portion instance from an adaptive inventory, the configuration value indicating that the supported attribute is to be used to one of configure and reconfigure the network portion instance.

Embodiment D4. The method of any one of Embodiments D1-D3, wherein the provided profile artifact is a SliceProfile artifact modeled as a Topology and Orchestration Specification for Cloud Applications (TOSCA) node type.

Embodiment D5. The method of Embodiment D4, wherein the SliceProfile artifact modeled as the TOSCA node type is a domain- specific SliceProfile artifact that includes a derived base node type, the domain-specific SliceProfile artifact including at least one supported attribute and one category associated with the network domain, the network domain being any one of a Core Network (CN) domain and a Radio Access Network (RAN) domain.

Embodiment D6. The method of any one of Embodiments D1-D5, wherein the first network node is Service Orchestrator Network Slice Subnet Management Function (NSSMF) node, the second network node is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance (NSSI).

As will be appreciated by one of skill in the art, the concepts described herein may be embodied as a method, data processing system, computer program product and/or computer storage media storing an executable computer program. Accordingly, the concepts described herein may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or “module.” Any process, step, action and/or functionality described herein may be performed by, and/or associated to, a corresponding module, which may be implemented in software and/or firmware and/or hardware. Furthermore, the disclosure may take the form of a computer program product on a tangible computer usable storage medium having computer program code embodied in the medium that can be executed by a computer. Any suitable tangible computer readable medium may be utilized including hard disks, CD-ROMs, electronic storage devices, optical storage devices, or magnetic storage devices.

Some embodiments are described herein with reference to flowchart illustrations and/or block diagrams of methods, systems and computer program products. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer (to thereby create a special purpose computer), special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer program instructions may also be stored in a computer readable memory or storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

It is to be understood that the functions/acts noted in the blocks may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

Computer program code for carrying out operations of the concepts described herein may be written in an object oriented programming language such as Python, Java® or C++. However, the computer program code for carrying out operations of the disclosure may also be written in conventional procedural programming languages, such as the "C" programming language. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to literally describe and illustrate every combination and subcombination of these embodiments. Accordingly, all embodiments can be combined in any way and/or combination, and the present specification, including the drawings, shall be construed to constitute a complete written description of all combinations and subcombinations of the embodiments described herein, and of the manner and process of making and using them, and shall support claims to any such combination or subcombination.

Abbreviations that may be used in the preceding description include: Abbreviation Explanation

3GPP 3rd Generation Partnership Project

API Application Program Interface

LCM Life Cycle Management

NSI Network Slice Instance

NSSI Network Slice Subnet Instance

NS S T N etwork S lice S ubnet T emplate

NSMF Network Slice Management Function

NSSMF Network Slice Subnet Management Function

TOSCA Topology and Orchestration Specification for Cloud

Applications

It will be appreciated by persons skilled in the art that the embodiments described herein are not limited to what has been particularly shown and described herein above. In addition, unless mention was made above to the contrary, it should be noted that all of the accompanying drawings are not to scale. A variety of modifications and variations are possible in light of the above teachings without departing from the scope of the following claims.

Claims

What is claimed is:

1. A first network node (16a) supporting communication at least with a second network node (16b), the first network node (16a) comprising: a communication interface (30) configured to: receive a request to allocate a network portion instance, the request including information at least about a network domain from which the network portion instance is to be allocated; and processing circuitry (36) in communication with the communication interface (30), the processing circuitry (36) being configured to at least one of: determine a profile artifact based at least in part on the received request, the determined profile artifact including at least a supported attribute and a category corresponding to the supported attribute; and allocate the network portion instance based at least in part on the supported attribute, the category corresponding to the supported attribute, and whether the network portion instance is already available.

2. The first network node (16a) of Claim 1, wherein the determined profile artifact is obtained from the second network node (16b).

3. The first network node (16a) of any one of Claims 1 and 2, wherein the determined profile artifact is a default profile artifact amended at least to include the category corresponding to the supported attribute.

4. The first network node (16a) of any one of Claims 1-3, wherein the category corresponding to the supported attribute is any one of a selection value and a configuration value, the selection value indicating at least one of the supported attribute is to be used to select the network portion instance from an adaptive inventory and a selection constraint, the configuration value indicating that the supported attribute is to be used to one of configure and reconfigure the network portion instance.

5. The first network node (16a) of Claim 4, wherein allocating the network portion instance further includes: if the category corresponding to the supported attribute is the selection value and the information included in the request to allocate the network portion instance indicates that the network portion instance is to be shared, filtering out the supported attribute and invoking an Application Programming Interface, API, to find an existing network portion instance.

6. The first network node (16a) of Claim 5, wherein allocating the network portion instance further includes: if the existing network portion instance is not found, requesting another API to create another network portion instance based on the information included in the request to allocate the network portion instance.

7. The first network node (16a) of Claim 6, wherein allocating the network portion instance further includes: triggering the first network node (16a) to request a third network node to execute one of: a reconfiguration of at least one resource associated with the existing network portion instance; and a configuration of at least another resource associated with the other network portion instance.

8. The first network node (16a) of any one of Claims 1-7, wherein the determined profile artifact is a SliceProfile artifact modeled as a Topology and Orchestration Specification for Cloud Applications, TOSCA, node type.

9. The first network node (16a) of Claim 8, wherein the SliceProfile artifact modeled as the TOSCA node type is a domain-specific SliceProfile artifact that includes a derived base node type, the domain-specific SliceProfile artifact including at least one supported attribute and one category associated with the network domain, the network domain being any one of a Core Network, CN, domain and a Radio Access Network, RAN, domain.

10. The first network node (16a) of any one of Claims 1-9, wherein the first network node (16a) is a Service Orchestrator Network Slice Subnet Management Function, NSSMF, node, the second network node (16b) is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance, NSSI.

11. A method implemented in a first network node (16a) supporting communication at least with a second network node (16b), the method comprising: receiving (S108) a request to allocate a network portion instance, the request including information at least about a network domain from which the network portion instance is to be allocated; determining (S 110) a profile artifact based at least in part on the received request, the determined profile artifact including at least a supported attribute and a category corresponding to the supported attribute; and allocating (S 112) the network portion instance based at least in part on the supported attribute, the category corresponding to the supported attribute, and whether the network portion instance is already available.

12. The method of Claim 11, wherein the determined profile artifact is obtained from the second network node (16b).

13. The method of any one of Claims 11 and 12, wherein the determined profile artifact is a default profile artifact amended at least to include the category corresponding to the supported attribute.

14. The method of any one of Claims 11-13, wherein the category corresponding to the supported attribute is any one of a selection value and a configuration value, the selection value indicating at least one of the supported attribute is to be used to select the network portion instance from an adaptive inventory and a selection constraint, the configuration value indicating that the supported attribute is to be used to one of configure and reconfigure the network portion instance.

15. The method of Claim 14, wherein allocating the network portion instance further includes: if the category corresponding to the supported attribute is the selection value and the information included in the request to allocate the network portion instance indicates that the network portion instance is to be shared, filtering out the supported attribute and invoking an Application Programming Interface, API, to find an existing network portion instance.

16. The method of Claim 15, wherein allocating the network portion instance further includes: if the existing network portion instance is not found, requesting another API to create another network portion instance based on the information included in the request to allocate the network portion instance.

17. The method of Claim 16, wherein allocating the network portion instance further includes: triggering the first network node (16a) to request a third network node to execute one of: a reconfiguration of at least one resource associated with the existing network portion instance; and a configuration of at least another resource associated with the other network portion instance.

18. The method of any one of Claims 11-17, wherein the determined profile artifact is a SliceProfile artifact modeled as a Topology and Orchestration Specification for Cloud Applications, TOSCA, node type.

19. The method of Claim 18, wherein the SliceProfile artifact modeled as the TOSCA node type is a domain-specific SliceProfile artifact that includes a derived base node type, the domain- specific SliceProfile artifact including at least one supported attribute and one category associated with the network domain, the network domain being any one of a Core Network, CN, domain and a Radio Access Network, RAN, domain.

20. The method of any one of Claims 11-19, wherein the first network node (16a) is a Service Orchestrator Network Slice Subnet Management Function, NSSMF, node, the second network node (16b) is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance, NSSI.

21. A second network node (16b) supporting communication at least with a first network node (16a), the second network node (16b) comprising processing circuitry (36) configured to: provide a profile artifact to be transmitted to the first network node (16a) based on a request to allocate a network portion instance, the provided profile artifact including at least a supported attribute and a category corresponding to the supported attribute.

22. The second network node (16b) of Claim 21, wherein the second network node (16b) further comprises a communication interface (30) in communication with the processing circuitry (36), the communication interface (30) configured to: receive a default profile artifact including the at least supported attribute.

23. The second network node (16b) of Claim 22, wherein the processing circuitry (36) is further configured to: amend the default profile artifact by at least including the category corresponding to the at least supported attribute, the provided profile artifact being based at least in part on the amended default profile artifact.

24. The second network node (16b) of Claims 22 and 23, wherein the processing circuitry (36) is further configured to: cause transmission of the provided profile artifact to the first network node

(16a).

25. The second network node (16b) of any one of Claims 21-24, wherein the category corresponding to the supported attribute is any one of a selection value and a configuration value, the selection value indicating at least one of the supported attribute is to be used to select the network portion instance from an adaptive inventory and a selection constraint, the configuration value indicating that the supported attribute is to be used to one of configure and reconfigure the network portion instance.

26. The second network node (16b) of any one of Claims 21-25, wherein the provided profile artifact is a SliceProfile artifact modeled as a Topology and Orchestration Specification for Cloud Applications, TOSCA, node type.

27. The second network node (16b) of Claim 26, wherein the SliceProfile artifact modeled as the TOSCA node type is a domain-specific SliceProfile artifact that includes a derived base node type, the domain-specific SliceProfile artifact including at least one supported attribute and one category associated with a network domain from which the network portion instance is to be allocated, the network domain being any one of a Core Network, CN, domain and a Radio Access Network, RAN, domain.

28. The second network node (16b) of any one of Claims 21-27, wherein the first network node (16a) is a Service Orchestrator Network Slice Subnet Management Function, NSSMF, node, the second network node (16b) is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance, NSSI.

29. A method implemented in a second network node (16b) supporting communication at least with a first network node (16a), the method comprising: providing (S 114) a profile artifact to be transmitted to the first network node (16a) based on a request to allocate a network portion instance, the provided profile artifact including at least a supported attribute and a category corresponding to the supported attribute.

30. The method of Claim 29, wherein the method further includes: receiving a default profile artifact including the at least supported attribute.

31. The method of Claim 30, wherein the method further includes: amending the default profile artifact by at least including the category corresponding to the at least supported attribute, the provided profile artifact being based at least in part on the amended default profile artifact.

32. The method of Claims 30 and 31, wherein the method further includes: transmitting the provided profile artifact to the first network node (16a).

33. The method of any one of Claims 29-32, wherein the category corresponding to the supported attribute is any one of a selection value and a configuration value, the selection value indicating at least one of the supported attribute is to be used to select the network portion instance from an adaptive inventory and a selection constraint, the configuration value indicating that the supported attribute is to be used to one of configure and reconfigure the network portion instance.

34. The method of any one of Claims 29-33, wherein the provided profile artifact is a SliceProfile artifact modeled as a Topology and Orchestration Specification for Cloud Applications, TOSCA, node type.

35. The method of Claim 34, wherein the SliceProfile artifact modeled as the TOSCA node type is a domain-specific SliceProfile artifact that includes a derived base node type, the domain- specific SliceProfile artifact including at least one supported attribute and one category associated with a network domain from which the network portion instance is to be allocated, the network domain being any one of a Core Network, CN, domain and a Radio Access Network, RAN, domain.

36. The method of any one of Claims 29-35, wherein the first network node (16a) is a Service Orchestrator Network Slice Subnet Management Function, NSSMF, node, the second network node (16b) is a Catalog Manager node, and the network portion instance is a Network Slice Subnet Instance, NSSI.