Technical Field The present disclosure relates to dimensioning of Virtual Network Functions (VNFs) for a network slice in a cellular communications system.

Background

Network slicing is a key capability in a Fifth Generation (5G) to support service isolation and Service Level Agreement (SLA) assurance for various service types. In 5G, the Third Generation Partnership Project (3GPP) has characterized the requirements of a service by a service profile, see Table 1 below which is reproduced from 3GPP Technical Specification (TS) 28.541 V17.3.0. While this is evolving, the parameters shown in Table 1 give an indication of what parameter set needs to be provided as input to an End-to-End (E2E) Service Orchestrator over a 3GPP interface or Tele Management Forum (TMF) Application Programming Interface (API) 641 to realize (i.e., deploy and configure) the needed resources (i.e., a network slice) in order to support a service according to its service requirements.

Table 1

The service requirements, represented by the service profile, map to one or more service specifications (also referred to herein as "service templates") which outline the required network function types that need to be deployed or reconfigured, in a shared context, to fulfill the service requirement. What neither the service profile nor the service template indicates is the cardinality of (i.e., the number of) and needed virtual resource capacity of each network function of each network function type needed for the deployed/re-configured network slice that is to support the respective service instance. Determining the needed virtual resource capacity of each network function is referred to herein as "dimensioning" the network function. In the service profile of Table 1, the parameters highlighted in italicized, bold text are related to dimensioning aspects of network functions. Summary

Systems and methods are disclosed for service-based automated dimensioning of Virtual Network Functions (VNFs) for a network slice for supporting a service instance in a cellular communications system. In one embodiment, a method for automated dimensioning of VNFs for a network slice for supporting a service instance comprises receiving a service request for a service instance, the service request comprising one or more parameters related to dimensioning of VNF instances for a network slice that is to support the service instance. The method further comprises deploying a network slice that supports the service instance in accordance with the service request. Deploying the network slice that supports the service instance comprises, in an automated manner, mapping the service request to a service template comprising information that defines one or more VNF types needed and a topology for the network slice that supports the service instance. Deploying the network slice further comprises, in an automated manner, for a VNF type from among the VNF types needed for the network slice: determining a number of VNF instances of the VNF type to be deployed for the network slice that supports the service instance and, for a VNF instance of the VNF type, transforming the one or more parameters related to dimensioning of VNF instances for the network slice that is to support the service instance into one or more input parameters for dimensioning (e.g., for a dimensioning tool) for the VNF type and providing the one or more input parameters to the dimensioning (e.g., to the dimensioning tool) for the VNF type to thereby obtain dimensioning parameters for the VNF instance. In this manner, a flexible, automated process for service-based dimensioning of VNFs is provided.

Corresponding embodiments of a computing node for automated dimensioning of VNFs for a network slice for supporting a service instance are also disclosed. In one embodiment, a computing node for automated dimensioning of VNFs for a network slice for supporting a service instance is adapted to receive a service request for a service instance, the service request comprising one or more parameters related to dimensioning of VNF instances for a network slice that is to support the service instance. The computing node is further adapted to deploy a network slice that supports the service instance in accordance with the service request. In order to deploy the network slice that supports the service instance, the computing node is further adapted to, in an automated manner, map the service request to a service template comprising information that defines one or more VNF types needed and a topology for the network slice that supports the service instance. In order to deploy the network slice that supports the service instance, the computing node is further adapted to, in an automated manner, for a VNF type from among the VNF types needed for the network slice: determine a number of VNF instances of the VNF type to be deployed for the network slice that supports the service instance and, for a VNF instance of the VNF type, transform the one or more parameters related to dimensioning of VNF instances for the network slice that is to support the service instance into one or more input parameters for dimensioning for the VNF type and provide the one or more input parameters to the dimensioning for the VNF type to thereby obtain dimensioning parameters for the VNF instance.

In another embodiment, a computing node for automated dimensioning of VNFs for a network slice for supporting a service instance comprises processing circuitry configured to cause the computing node to receive a service request for a service instance, the service request comprising one or more parameters related to dimensioning of VNF instances for a network slice that is to support the service instance. The processing circuitry is further configured to cause the computing node to deploy a network slice that supports the service instance in accordance with the service request. In order to deploy the network slice that supports the service instance, the processing circuitry is further configured to cause the computing node to, in an automated manner, map the service request to a service template comprising information that defines one or more VNF types needed and a topology for the network slice that supports the service instance. In order to deploy the network slice that supports the service instance, the processing circuitry is further configured to cause the computing node to, in an automated manner, for a VNF type from among the VNF types needed for the network slice: determine a number of VNF instances of the VNF type to be deployed for the network slice that supports the service instance and, for a VNF instance of the VNF type, transform the one or more parameters related to dimensioning of VNF instances for the network slice that is to support the service instance into one or more input parameters for dimensioning for the VNF type and provide the one or more input parameters to the dimensioning for the VNF type to thereby obtain dimensioning parameters for the VNF instance. Brief Description of the

The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

Figure 1 illustrates one example of a cellular communications system for which End-to-End (E2E) service orchestration may be performed according to some embodiments of the present disclosure;

Figure 2 illustrates a system in which an E2E orchestrator performs automated service-based dimensioning of Virtual Network Function (VNF) instances for a network slice that supports a particular service instance in accordance with one embodiment of the present disclosure;

Figures 3A and 3B provide a functional block diagram of the E2E orchestrator of Figure 2 in accordance with one embodiment of the present disclosure

Figure 4 illustrates the operation of the E2E orchestrator of Figures 2 and Figures 3A and 3B and, in particular, the operation of the automated service instance design function of the E2E orchestrator in accordance with one embodiment of the present disclosure;

Figure 5 illustrates one example embodiment of a service template;

Figure 6 is a schematic block diagram of a computing node on which the E2E service orchestrator of Figure 2 may be implemented according to some embodiments of the present disclosure;

Figure 7 is a schematic block diagram that illustrates a virtualized embodiment of the computing node of Figure 6 according to some embodiments of the present disclosure; and

Figure 8 is a schematic block diagram of the computing node of Figure 6 according to some other embodiments of the present disclosure.

Detailed

The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

Radio Node: As used herein, a "radio node" is either a radio access node or a wireless communication device.

Radio Access Node: As used herein, a "radio access node" or "radio network node" or "radio access network node" is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.

Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

Communication Device: As used herein, a "communication device" is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehiclemounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.

Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection.

Network Node: As used herein, a "network node" is any node that is either part of the RAN or the core network of a cellular communications network/system.

Service Template: A service template is a data structure that defines a cloudbased service including one or more Virtualized Network Function (VNF) types needed for the service and a topology of the VNF types for the service. In one example embodiment, a service template is a Topology and Orchestration Specification for Cloud Applications (TOSCA) service template.

Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

Note that, in the description herein, reference may be made to the term "cell"; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

Currently, there are several problems with existing solutions in relation to network slicing and realizing (i.e., deploying or updating) a network slice to support a service (i.e., a service instance) in accordance with service requirements contained in a service profile of the service. While the European Telecommunications Standards Institute (ETSI) Standardized Topology and Orchestration Specification for Cloud Applications (TOSCA) descriptors (i.e., Virtual Network Function Descriptor (VNFD) I Cloud-native Network Function Descriptor (CNFD)) associated with network functions (i.e., Virtual Network Function (VNF) I Cloud-native Network Function (CNF)) expose the capability to set its virtual resource limits (i.e. dimensioning constraints), there is no solution currently proposed on how to set these at deploy and run time, both in relation to dedicated and shared resources associated with the Life Cycle Management (LCM) of a service.

Systems and methods are disclosed herein that address the aforementioned and/or other problems. More specifically, systems and methods are disclosed herein for determining, or setting, virtual resource limits (i.e., dimensioning constraints) for a VNF or CNF at deploy and run time, both in relation to dedicated and shared resources associated with the LCM of an associated service, e.g., in the overall context of a possible set of input service requirements in a multivendor deployment.

More specifically, embodiments of the present disclosure assume that most VNF types associated to or referenced in a service template have an associated dimensioning tool with a defined set of input parameters. Embodiments of the present disclosure provide an extensible NF dimensioning model mapper that receives the dimensioning related service requirement input parameters for a service instance and, for each VNF instance of each VNF type needed for a network slice to support the service instance based on a service template for the service instance, transform the dimensioning related service requirement input parameters into a set of input parameters for a respective dimensioning tool for the VNF type. The transformation may be via a transformation model for the VNF type and, optionally, the desired VNF version, the desired vendor, desired dimensioning tool version, and/or the like. For each VNF instance of each VNF type needed for the network slice to support the service instance, the respective set of input parameters output by the NF dimensioning model mapper are provided to the respective dimensioning model to thereby obtain a set of dimensioning parameters (e.g., one or more parameters related to an amount of compute resources needed for the VNF instance and/or one or more parameters related to an amount of storage resources needed for the VNF instance). In this regard, Figure 1 illustrates one example of a cellular communications system 100 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 100 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC) or an Evolved Packet System (EPS) including an Evolved Universal Terrestrial RAN (E-UTRAN) and an Evolved Packet Core (EPC); however, the solutions described herein are not limited thereto. In this example, the RAN includes base stations 102-1 and 102-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC) and in the EPS include eNBs, controlling corresponding (macro) cells 104-1 and 104-2. The base stations 102-1 and 102-2 are generally referred to herein collectively as base stations 102 and individually as base station 102. Likewise, the (macro) cells 104-1 and 104-2 are generally referred to herein collectively as (macro) cells 104 and individually as (macro) cell 104. The RAN may also include a number of low power nodes 106-1 through 106-4 controlling corresponding small cells 108-1 through 108-4. The low power nodes 106-1 through 106-4 can be small base stations (such as pico or femto base stations) or RRHs, or the like. Notably, while not illustrated, one or more of the small cells 108-1 through 108-4 may alternatively be provided by the base stations 102. The low power nodes 106-1 through 106-4 are generally referred to herein collectively as low power nodes 106 and individually as low power node 106. Likewise, the small cells 108-1 through 108-4 are generally referred to herein collectively as small cells 108 and individually as small cell 108. The cellular communications system 100 also includes a core network 110, which in the 5G System (5GS) is referred to as the 5GC. The core network 110 includes many Network Functions (NFs) 114. For example, in the 5GS, the core network 110 includes, e.g., an AMF(s), a SMF(s), a PCF(s), a UPF(s), etc., as will be appreciated by those of skill in the art. The base stations 102 (and optionally the low power nodes 106) are connected to the core network 110.

The base stations 102 and the low power nodes 106 provide service to wireless communication devices 112-1 through 112-5 in the corresponding cells 104 and 108. The wireless communication devices 112-1 through 112-5 are generally referred to herein collectively as wireless communication devices 112 and individually as wireless communication device 112. As shown in Figure 2, a system 200 such as the cellular communications system 100 of Figure 1, utilizes network slicing to support service isolation and Service Level Agreement (SLA) assurance for various service types. In the example of Figure 2, the system 200 includes multiple (N) network slices 202-1 to 202-N supporting multiple (M) services 204-1 to 204-M. Note that, in some embodiments, a single network slice may be shared by multiple services. In this regard, the example of Figure 2 shows the network slice 204-2 being shared for the services 204-2 and 204-3. The services 204-1 to 204-M may include, e.g., one or more enhanced Mobile Broadband (eMBB) services, one or more Ultra-Reliable Low-Latency Communication (URLLC) services, or the like. Each of the network slices 202-1 to 202-N includes one or more Virtual Network Functions (VNFs) 206. The VNFs 206 of the network slice 202-1 are denoted in Figure 2 as VNFs 206-1, the VNFs 206 of the network slice 202-2 are denoted in Figure 2 as VNFs 206-2, and so on. Note that, as used in the remainder of the description and claims herein, the term "VNF" refers to both VNFs and CNFs, shared or dedicated. Wireless communication devices (WCDs) 208 (e.g., the WCDs 112 in the example cellular communications system 100 of Figure 1) may access the network slices 202 to have access to the respective services 204, e.g., if authorized to do so.

As described below in detail, systems and methods are disclosed for setting one or more dimensioning parameters (e.g., dimensioning constraints) such as, e.g., amount of compute resources and/or amount of storage resources (e.g., memory resources and/or hard drive resources) for the VNFs 206 in a network slice 202 that supports a service 204 during deployment, update, or run-time of the network slice 202, based on an associated service profile included in a service request. In the embodiments described herein, this functionality is provided by an End-to-End (E2E) orchestrator 210. The E2E orchestrator 210 may be implemented in a network node or computing node within or otherwise connected to the system 200. The E2E orchestrator 210 may be implemented in software executed by processing circuitry (e.g., one or more processors) of a network node or a computing node or implemented in software executed by processing circuitry of two or more network nodes or computing nodes in a distributed manner.

Figures 3A and 3B provide a functional block diagram of the E2E orchestrator 210 in accordance with one embodiment of the present disclosure. As illustrated, the E2E orchestrator 210 includes an automated service instance design function 300 including a NF/workload dimensioning model mapper 302. The NF/workload dimensioning model mapper 302 includes core business logic 304, a set of transformation models 306, and a set of dimensioning tools 308. The core business logic 304 maps a set of input parameters to the correct transformation model 306 and associated dimensioning tool 308, as described herein. In the preferred embodiments described herein, the set of dimensioning tools 308 includes at least one dimensioning tool for each VNF type (e.g., AMF, SMF, PCF, UPF, etc.) that can be referenced in a service template for a service instance. More specifically, the set of dimensioning tools 308 includes, for example:

• one dimensioning tool for each VNF type, or

• multiple dimensioning tools for each VNF type for:

(a) multiple vendors (e.g., each of multiple vendors of a particular VNF type may define a respective dimensioning tool for the VNF type for that vendor),

(b) multiple versions of the VNF type, or

(c) both (a) and (b).

Further, if there is one dimensioning tool for each VNF type, the dimensioning tool for a VNF type may support multiple versions of the VNF type. The dimensioning tool for a VNF type (and possibly VNF version and/or vendor) operates to provide a set of dimensioning parameters for a VNF instance of that type (and possibly that VNF version and/or vendor) based on a set of input parameters.

The set of transformation models 306 includes at least one transformation model for each VNF type (e.g., AMF, SMF, PCF, UPF, etc.) that can be referenced in a service template for a service instance. More specifically, the set of transformation models 306 includes, for example:

• one transformation model for each VNF type, or

• multiple transformation models for each VNF type for:

(a) multiple vendors (e.g., each of multiple vendors of a particular VNF type may define a respective transformation model for the VNF type for that vendor),

(b) multiple versions of the VNF type,

(c) multiple versions of the respective dimensioning tool for the VNF type,

(d) multiple service request types (e.g., 3GPP, TMF641, other service request type, and/or the like), or (e) a combination of any two or more of (a) - (d).

In another embodiment, there is a transformation model for each VNF type (possibly for each of multiple vendors), where the transformation model supports: (i) multiple versions of the VNF type, (ii) multiple versions of the respective dimensioning tool for the VNF type, (iii) multiple service request types, or (iv) a combination any two or more of (i) - (iii), where respective inputs are provided to the transformation model to indicate the VNF version, dimensioning tool version, and/or service request type such that the transformation model outputs the expected input parameters of the desired dimensioning tool.

The set of transformation models 306 are, in one embodiment stored at the NF/workload dimensioning model mapper 302. Notably, the NF/workload dimensioning model mapper 302 provides flexibility in that new transformation models may be added to the set of transformation models 306 and/or transformation models in the set of transformation models 306 may be updated over time. For example, a new vendor may provide transformation models for one or more VNF types and provide those transformation models to the network operator for addition to the NF/workload dimensioning model mapper 302.

The operation of the E2E orchestrator 210 and, in particular, the automated service instance design function 300 is illustrated in the flow chart of Figure 4. Dashed lines/boxes are used to represent optional steps in the flow chart of Figure 4. As illustrated in Figure 4, the E2E orchestrator 210 receives a service request for a service instance of a particular service (step 400). The service request includes a set of parameters that define requirements for the service instance. This set of parameters includes one or more parameters related to dimensioning of one or more VNFs for a network slice that is to support, or provide, the service instance. In one embodiment, the service request includes a service profile such as, for example, the service profile described in the Background section above where the bold, italicized parameters in Table 1 are parameters that relate to dimensioning of the VNFs for the network slice that is to support the service instance.

The E2E orchestrator 210, and in particular the automated service instance design function 300, then deploys the service instance, i.e., deploys or updates a network slice that is to support the service instance, in accordance with the service request (step 402). The automated service instance design function 300 does so in an automated manner (i.e., without user interaction). More specifically, the automated service instance design function 300 maps the service request into a service template for the service instance and parses the service template to determine, among other things, the VNF types needed for the network slice that is to support the service instance (step 402A). The service template defines a set of VNF types needed for network slice that is to support the service instance and a topology for the network slice. In one example embodiment, the service template is TOSCA service template (e.g., as defined in Topology and Orchestration Specification for Cloud Applications Version 1.0, 25 November 2013, OASIS Standard, http://docs.oasis- open.org/tosca/TOSCA/vl.O/os/TOSCA-vl.O-os.html.), a representation of which is illustrated in Figure 5. Details regarding the TOSCA service template are understood by those of skill in the art and are available in the OASIS Standard. As such, those details are not repeated here.

The automated service instance design function 300 processes the service template (or the service model resulting from parsing the service template) to determine a required radio coverage for the service instance (not shown in Figure 4, but shown in Figure 3A) and, for each VNF type needed (or for at least one VNF type needed), determine a cardinality of the VNF type (i.e., the number of VNF instances of the VNF type) needed for the network slice that is to support the service instance (step 402B). The cardinality of each of the VNF types may be determined based on factors such as, e.g., E2E latency service requirements and/or other constraints such as, e.g., cost. For each VNF instance (or at least one VNF instance) for each of the VNF types (or at least one of the VNF types) needed for the network slice that is to support the service instance (as indicated by the corresponding cardinality), the NF/workload dimensioning model mapper 302 of the automated service instance design function 300:

• transforms, e.g., via a respective transformation model, the dimensioning related parameters from the service request into a set of input parameters for a respective dimensioning tool (step 402C), and

• provides the set of input parameters to the respective dimensioning tool to thereby obtaining a set of dimensioning parameters for the VNF instance (step 402D). The set of dimensioning parameters for the VNF instance includes, for example, one or more parameters related to an amount of compute resources needed for the VNF instance, one or more parameters related to an amount of storage resources (e.g., memory resources and/or hard drive resources) needed for the VNF instance, or both one or more parameters related to an amount of compute resources needed for the VNF instance and one or more parameters related to an amount of storage resources.

The transformation model used in step 402C for the VNF instance is the transformation model for the corresponding VNF type and optionally: the corresponding vendor, the corresponding version of the VNF type, the corresponding dimensioning tool, the corresponding version of the dimensioning tool, and/or the corresponding service request type of the service type received in step 400. Note that the correct transformation model and dimensioning tool are, in one embodiment, selected by the core business logic 304 of the NF/workload dimensioning model mapper 302 based on the VNF type and optionally: vendor, VNF version, etc.

Note that the dimensioning related parameters from the service request include, in one embodiment:

(a) a maximum number of UEs;

(b) downlink throughput per network slice;

(c) downlink throughput per UE;

(d) uplink throughput per network slice;

(e) uplink throughput per UE;

(f) maximum number of Protocol Data Unit, PDU, sessions;

(g) term density (e.g., an attribute that specifies the overall user density over the coverage area of the network slice, see e.g., Table 7.1-1 of 3GPP TS 22.261);

(h) activity factor (e.g., an attribute that specifies the percentage value of the amount of simultaneous active UEs to the total number of UEs where active means the UEs are exchanging data with the network. See Table 7.1-1 of TS 22.261);

(i) maximum downlink data volume (e.g., an attribute specifies the maximum DL PDCP data volume supported by the network slice instance (performance measurement definition see in 3GPP TS 28.552). The unit may be, e.g., MByte/day.);

(j) maximum uplink data volume (e.g., An attribute specifies the maximum UL PDCP data volume supported by the network slice instance (performance measurement definition see in 3GPP TS 28.552). The unit is MByte/day.); or (k) a combination of any two or more of (a)-(j).

The automated service instance design function 300 then uses the set of dimensioning parameters for each of the VNF instances of each of the VNF types needed for the network slice to complete the deployment of the network slice that is to support the service instance (step 402E). The details of the remaining portion of the deployment procedure are known to those of skill in the art and as such are not repeated here.

Optionally, during run-time for the service instance (i.e., during run-time of the network slice supporting the service instance), an updated service request for the service instance is received by the E2E orchestrator 210 (step 404). The updated service request includes an updated set of parameters that define updated requirements for the service instance. In this example, this updated set of parameters includes one or more updated parameters related to dimensioning of the VNFs for the network slice that supports, or provides, the service instance. The automated service instance design function 300 then repeats step 402 based on the updated service request (step 406). Note that, depending on what parameters are updated and how they relate to the VNF types used for the network slice, some, all, or none of the existing VNF instances may be updated. For example, the updated service request may be such that a new VNF instance(s) for one or more of the VNF type(s) is added, in which case the other VNF instances of the same or different VNF types may remain unchanged. However, alternatively, the entire process of step 402 may be repeated based on the updated service request. Note, however, that this update is performed during run-time, which provides significant advantages in terms of flexibility as compared to existing solutions.

Embodiments of the present disclosure assume that each VNF type has an associated dimensioning tool. However, in one embodiment, in the event that there is no dimensioning tool associated with a particular VNF type/workload, the associated transformation model determines the associated dimensioning constraints (i.e., the associated dimensioning parameters) for that VNF/workload in question.

In one embodiment, some or all of the dimensioning tools expose configurable settings (e.g., weighting factors, etc.), and these configurable setting are updated based on data analytics performed on live and historical data the associated NFs/workloads in the network to recalibrate the dimensioning tool to improve its accuracy. In one embodiment, one or more of the dimensioning tools are realized by an Artificial Intelligence (Al) or Machine Learning (ML) component which similarly determines the required dimensioning of each NF/workload instance to be deployed but instead relies on live and historical data from such NFs/workloads in the network to determine the required dimensioning.

Example aspects of the embodiments disclosed herein include:

1. An extensible (e.g., multivendor) NF/workload dimensioning model mapper 302.

2. The NF/workload dimensioning model mapper 302 has (e.g., pre-integrated) all the required transformation models to map dimensioning related parameters from service requests for one or more services to the expected set of input parameters for the dimensioning tools of the respective VNF types.

3. Application Programming Interfaces (APIs) of the dimensioning tools are published so the transformation models are able to communicate the transformed sets of input parameters to the dimensioning tools.

4. The NF/workload dimensioning model mapper 302 is extensible in some embodiments and, therefore, new transformation models can be added and/or existing transformation models can be updated.

5. In one embodiment, the transformation models support a set of input parameters, which extends beyond that provided by the input service request. Note that the set of input parameters in the service request are set by a previous step in the overall service design process. The service request may be processed to provide additional input parameters for the transformation models (e.g., the cardinality of a specific NF/workload required). Default values may be defined for these additional input parameters (e.g., default cardinality of a specific NF/workload = 1).

6. The NF/workload dimensioning model mapper 302 is, in on embodiment, extensible in that additional dimensioning tools may be added.

While not being limited to any particular advantage, the embodiments described herein provide a number of advantages over existing solutions. For example, the capability of the E2E orchestrator 210, as compared to that of existing E2E orchestrators, in in terms of level of intent or abstraction support is increased. As another example, in some embodiments of the present disclosure, the NF/workload dimensioning model mapper 302 supports multiple vendors (e.g., transformation models for multiple vendors), which is in line with industry needs (e.g., Service Management Orchestration (SMO) and Open Radio Access Network (O-RAN)). As another example, in embodiments of the present disclosure, the level of automation in E2E service/slice orchestration is increased (i.e., NF/workload dimensioning is automated). As another example, in some embodiments of the present disclosure, efficient use of virtualized resources, particularly at high-cost edge sites is well managed based on the input service requirements. As another example, in some embodiments of the present disclosure, service LCM, in terms of business expansion (i.e., Service Order Update (expand slice to increase supported number of UEs or throughput per UE), is controlled so as to secure maximum revenue return for the service provider.

Figure 6 is a schematic block diagram of a computing node 600 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The computing node 600 a server computer or other computing system that implements the E2E orchestrator 210 described herein. As illustrated, the computing node 600 includes one or more processors 604 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 606, and a network interface 608. The one or more processors 604 are also referred to herein as processing circuitry. The one or more processors 604 operate to provide one or more functions of the E2E service orchestrator 210, and in particular the automated service instance design function 300, as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 606 and executed by the one or more processors 604.

Figure 7 is a schematic block diagram that illustrates a virtualized embodiment of the computing node 600 according to some embodiments of the present disclosure. Again, optional features are represented by dashed boxes. As used herein, a "virtualized" computing node is an implementation of the computing node 600 in which at least a portion of the functionality of the computing node 600 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, the computing node 600 includes one or more processing nodes 700 coupled to or included as part of a network(s) 702. Each processing node 700 includes one or more processors 704 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 706, and a network interface 708. In this example, functions 710 of the computing node 600 described herein are implemented at the one or more processing nodes 700 or distributed across the two or more processing nodes 700 in any desired manner. In some particular embodiments, some or all of the functions 710 of the computing node 600 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environ ment(s) hosted by the processing node(s) 700.

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the computing node 600 or a node (e.g., a processing node 700) implementing one or more of the functions 710 of the computing node 600 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

Figure 8 is a schematic block diagram of the computing node 600 according to some other embodiments of the present disclosure. The computing node 600 includes one or more modules 800, each of which is implemented in software. The module(s) 800 provide the functionality of the computing node 600 described herein. This discussion is equally applicable to the processing node 700 of Figure 7 where the modules 800 may be implemented at one of the processing nodes 700 or distributed across multiple processing nodes 700.

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

References:

1. 3GPP 28.541 V17.3.0

2. TMF641 Service Ordering API User Guide v4.1.0

3. Topology and Orchestration Specification for Cloud Applications Version 1.0, 25 November 2013, OASIS Standard, http://docs.oasis- open.org/tosca/TOSCA/vl.O/os/TOSCA-vl.O-os.html

4. 3GPP TS 22.261 V18.4.0

5. 3GPP TS 28.552 V17.4.0