WO2023131403A1 - Dimensionnement de fonction de réseau virtuel piloté par service automatisé - Google Patents

Dimensionnement de fonction de réseau virtuel piloté par service automatisé Download PDF

Info

Publication number
WO2023131403A1
WO2023131403A1 PCT/EP2022/050165 EP2022050165W WO2023131403A1 WO 2023131403 A1 WO2023131403 A1 WO 2023131403A1 EP 2022050165 W EP2022050165 W EP 2022050165W WO 2023131403 A1 WO2023131403 A1 WO 2023131403A1
Authority
WO
WIPO (PCT)
Prior art keywords
vnf
service
dimensioning
network slice
instance
Prior art date
Application number
PCT/EP2022/050165
Other languages
English (en)
Inventor
Patrick Maguire
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/EP2022/050165 priority Critical patent/WO2023131403A1/fr
Publication of WO2023131403A1 publication Critical patent/WO2023131403A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/084—Configuration by using pre-existing information, e.g. using templates or copying from other elements
    • H04L41/0843—Configuration by using pre-existing information, e.g. using templates or copying from other elements based on generic templates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0876—Aspects of the degree of configuration automation
    • H04L41/0886—Fully automatic configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/16—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0888—Throughput
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/20—Arrangements for monitoring or testing data switching networks the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV

Definitions

  • VNFs Virtual Network Functions
  • 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.
  • 5G Fifth Generation
  • SLA Service Level Agreement
  • 3GPP Third Generation Partnership Project
  • TS Technical Specification
  • Table 1 gives 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.
  • E2E End-to-End
  • TMF Tele Management Forum
  • API Application Programming Interface
  • the service requirements 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.
  • service specifications also referred to herein as "service templates”
  • 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.
  • dimensioning the network function.
  • the parameters highlighted in italicized, bold text are related to dimensioning aspects of network functions. Summary
  • 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.
  • dimensioning e.g., for a dimensioning tool
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • FIG. 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
  • VNF Virtual Network Function
  • FIGS 3A and 3B provide a functional block diagram of the E2E orchestrator of Figure 2 in accordance with one embodiment of the present disclosure
  • FIG 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
  • FIG. 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.
  • Figure 8 is a schematic block diagram of the computing node of Figure 6 according to some other embodiments of the present 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.
  • RAN Radio Access Network
  • a radio access node examples 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.
  • 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
  • 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.
  • MME Mobility Management Entity
  • P-GW Packet Data Network Gateway
  • SCEF Service Capability Exposure Function
  • HSS Home Subscriber Server
  • a core network node examples 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.
  • AMF Access and Mobility Function
  • UPF User Plane Function
  • SMF Session Management Function
  • AUSF Authentication Server Function
  • NSSF Network Slice Selection Function
  • NEF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • PCF Policy Control Function
  • UDM Unified Data Management
  • 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.
  • 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).
  • 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.
  • UE User Equipment
  • MTC Machine Type Communication
  • LoT Internet of Things
  • 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.
  • 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.
  • VNF Virtualized Network Function
  • a service template is a Topology and Orchestration Specification for Cloud Applications (TOSCA) service template.
  • TOSCA Topology and Orchestration Specification for Cloud Applications
  • 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.
  • virtual resource limits i.e., dimensioning constraints
  • 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.
  • Figure 1 illustrates one example of a cellular communications system 100 in which embodiments of the present disclosure may be implemented.
  • 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.
  • 5GS 5G system
  • NG-RAN Next Generation RAN
  • 5GC 5G Core
  • EPS Evolved Packet System
  • E-UTRAN Evolved Universal Terrestrial RAN
  • EPC Evolved Packet Core
  • 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.
  • 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.
  • 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.
  • NFs Network Functions
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • eMBB enhanced Mobile Broadband
  • URLLC Ultra-Reliable Low-Latency Communication
  • 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.
  • VNF refers to both VNFs and CNFs, shared or dedicated.
  • WCDs Wireless communication devices 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.
  • dimensioning parameters e.g., dimensioning constraints
  • storage resources e.g., memory resources and/or hard drive resources
  • this functionality is provided by an End-to-End (E2E) orchestrator 210.
  • 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.
  • processing circuitry e.g., one or more processors
  • FIGS 3A and 3B provide a functional block diagram of the E2E orchestrator 210 in accordance with one embodiment of the present disclosure.
  • 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.
  • 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:
  • each of multiple vendors of a particular VNF type may define a respective dimensioning tool for the VNF type for that vendor
  • 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:
  • each of multiple vendors of a particular VNF type may define a respective transformation model for the VNF type for that vendor
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • the NF/workload dimensioning model mapper 302 of the automated service instance design function 300 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:
  • 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 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.
  • 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.
  • dimensioning related parameters from the service request include, in one embodiment:
  • 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;
  • 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);
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Artificial Intelligence Al
  • ML Machine Learning
  • 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.
  • APIs Application Programming Interfaces of the dimensioning tools are published so the transformation models are able to communicate the transformed sets of input parameters to the dimensioning tools.
  • 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.
  • the transformation models support a set of input parameters, which extends beyond that provided by the input service request.
  • the set of input parameters in the service request are set by a previous step in the overall service design process.
  • the NF/workload dimensioning model mapper 302 is, in on embodiment, extensible in that additional dimensioning tools may be added.
  • the embodiments described herein provide a number of advantages over existing solutions.
  • 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.
  • 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)).
  • SMO Service Management Orchestration
  • OF-RAN Open Radio Access Network
  • the level of automation in E2E service/slice orchestration is increased (i.e., NF/workload dimensioning is automated).
  • 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.
  • FIG. 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.
  • 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.
  • FIG. 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.
  • 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)).
  • 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.
  • processors 704 e.g., CPUs, ASICs, FPGAs, and/or the like
  • memory 706, and/or the like e.g., RAM, ROM, and/or the like
  • 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.
  • 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.
  • 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.
  • 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).
  • FIG 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Automation & Control Theory (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention divulgue des systèmes et des procédés de dimensionnement automatisé basé sur un service de fonctions de réseau virtuel (VNF) pour une tranche de réseau pour prendre en charge une instance de service dans un système de communication cellulaire. Dans un mode de réalisation, un procédé de dimensionnement automatisé de VNF pour une tranche de réseau pour prendre en charge une instance de service consiste à recevoir une requête de service pour une instance de service, la requête de service comprenant un ou plusieurs paramètres liés au dimensionnement d'instances de VNF pour une tranche de réseau qui doit prendre en charge l'instance de service. Le procédé consiste en outre à déployer une tranche de réseau qui prend en charge l'instance de service conformément à la requête de service, de telle sorte que le dimensionnement de VNF soit effectué de manière automatisée. Des modes de réalisation correspondants d'un nœud informatique pour le dimensionnement automatisé de VNF pour une tranche de réseau pour prendre en charge une instance de service.
PCT/EP2022/050165 2022-01-05 2022-01-05 Dimensionnement de fonction de réseau virtuel piloté par service automatisé WO2023131403A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2022/050165 WO2023131403A1 (fr) 2022-01-05 2022-01-05 Dimensionnement de fonction de réseau virtuel piloté par service automatisé

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2022/050165 WO2023131403A1 (fr) 2022-01-05 2022-01-05 Dimensionnement de fonction de réseau virtuel piloté par service automatisé

Publications (1)

Publication Number Publication Date
WO2023131403A1 true WO2023131403A1 (fr) 2023-07-13

Family

ID=80035245

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/050165 WO2023131403A1 (fr) 2022-01-05 2022-01-05 Dimensionnement de fonction de réseau virtuel piloté par service automatisé

Country Status (1)

Country Link
WO (1) WO2023131403A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160212017A1 (en) * 2015-01-20 2016-07-21 Huawei Technologies Co., Ltd. Systems and Methods for SDT to Interwork with NFV and SDN
EP3609161A1 (fr) * 2017-05-22 2020-02-12 Huawei Technologies Co., Ltd. Procédé et appareil de création de tranche de réseau, et système de communication
EP3684010A1 (fr) * 2017-09-30 2020-07-22 Huawei Technologies Co., Ltd. Procédé de gestion de tranches de réseau, et dispositif associé
EP3720050A1 (fr) * 2018-03-29 2020-10-07 Huawei Technologies Co., Ltd. Procédé et appareil de déploiement de tranche de réseau

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160212017A1 (en) * 2015-01-20 2016-07-21 Huawei Technologies Co., Ltd. Systems and Methods for SDT to Interwork with NFV and SDN
EP3609161A1 (fr) * 2017-05-22 2020-02-12 Huawei Technologies Co., Ltd. Procédé et appareil de création de tranche de réseau, et système de communication
EP3684010A1 (fr) * 2017-09-30 2020-07-22 Huawei Technologies Co., Ltd. Procédé de gestion de tranches de réseau, et dispositif associé
EP3720050A1 (fr) * 2018-03-29 2020-10-07 Huawei Technologies Co., Ltd. Procédé et appareil de déploiement de tranche de réseau

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
3GPP 28.541
3GPP TECHNICAL SPECIFICATION (TS) 28.541
3GPP TS 22.261
3GPP TS 28.552

Similar Documents

Publication Publication Date Title
US10841767B2 (en) Enhanced data download mechanism for power constrained Internet of Things devices
US11297601B2 (en) Resource allocation method and orchestrator for network slicing in the wireless access network
EP3512233B1 (fr) Procédé de gestion de tranche de réseau et unité de gestion
EP4017046A1 (fr) Procédé et dispositif de rapport d'informations d'entité fonctionnelle de plan utilisateur, support de stockage et dispositif électronique
US20220116800A1 (en) Automated cell parameter update in cellular networks
US11903076B2 (en) Method and apparatus for setting timer value in network
EP4294087A1 (fr) Procédé et appareil de contrôle d'accès pour tranche de réseau
WO2020024771A1 (fr) Procédé d'attribution de ressources gf sans ordonnancement et dispositif associé
WO2010075738A1 (fr) Procédé et système de gestion d'un élément de réseau multi-mode et élément de réseau multi-mode
US20230239795A1 (en) Enhanced Wake-Up Signal Based Power Saving for a Wireless Device
CN114424611B (zh) 网络功能的控制
WO2023131403A1 (fr) Dimensionnement de fonction de réseau virtuel piloté par service automatisé
WO2019095783A1 (fr) Procédé d'association, procédé d'instruction, et dispositif pour bloc de synchronisation et message de signalisation de planification de radiomessagerie
EP4304238A1 (fr) Procédé de traitement de modèle, dispositif de communication et système
CN113260032B (zh) 唤醒无线电分组标识符分配
WO2015039626A1 (fr) Procédé, système et dispositif de transmission et de réception de données
EP3140970A1 (fr) Techniques pour utiliser une technique de modulation et de codage pour des transmissions en liaison descendante
CN116156667A (zh) 物联网设备的会话建立方法及装置
CN110650071B (zh) 用户设备的接入管理方法、装置和管理服务器
WO2021063909A1 (fr) Appareil, procédé et programme informatique
WO2018121220A1 (fr) Procédé de transmission d'informations système, terminal d'utilisateur et nœud de transmission
CN114514764A (zh) 设备、方法和计算机程序
EP4277432A2 (fr) Réduction de latence de plan de commande dans un réseau de communication sans fil
US20240073815A1 (en) Open RAN Radio Unit Power Saving on Per-Symbol Basis
WO2023030328A1 (fr) Procédé de configuration de service de réseau sans fil, terminal et dispositif côté réseau

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22700721

Country of ref document: EP

Kind code of ref document: A1