The present invention pertains to the field of communications networks, and in particular to management of network slices and associated services.
An object of embodiments of the present invention is to provide techniques for management of network slices and associated services.
Aspects of the disclosure provide methods and systems that allow for different types of service providers to provide different types of services. Further such techniques allow the different service providers to utilize different levels of control over the resources that provide the services. Different levels of exposure of the management capabilities (including the resources, capabilities, and capacities) allows for different levels of service request details and corresponding levels of control of how the management capabilities are utilized to provide services specified in the request.
In some embodiments a request has a specification detail corresponding to a network exposure type previously provided by the network provider. For example, there are several exposure types (A-D, E1 and E2) each with a different level of specificity as the management capabilities, resources and capacity. Accordingly, the request can have corresponding levels of specificity as to how to implement the request, from an intent based request as to the intent desired, to specific details of how to allocate previously exposed resources to deliver a requested service.
Each exposure type includes a corresponding level of detail that can be provided in the request from a requesting customer. Accordingly, each exposure type allows for more detailed requests, allowing for more detailed control by the requester of the resources provided by the provider. From exposure type A1 to E2, the network management evolves from fully intent-driven to a less intent-driven fashion. In some embodiments a Service Management Exposure Function (SMEF) provides exposure interfaces for data and/or management exposure. It is the enabler to have different exposure levels without complicating individual network functions, such as NSMF, CSMF. An exposure level can be provided to SMEF as an “intent”, and SMEF can arrange the network to respond to this intent/request.
An aspect of the disclosure provides a method of delivering a communication service. Such a method includes receiving, by a network management system, a request from a requestor for a service. The method further includes requesting, by the network management system, resources to satisfy the request. Such a method further includes receiving, by the network management system, information about the resources, and providing the service utilizing the resources. An aspect of the disclosure provides a network management system configured to: selectively expose network management data; receive a request for a network service, the request including service requirements and parameters in accordance with the exposed network management data and/or capability via an exposure function, wherein the service comprises a selected one of: Communication as a Service (CaaS), Network Slice as a Service (NSaaS), Network Slice Subnet as a Service (NSSaaS), and Infrastructure as a Service (IaaS); and responsive to the received request, negotiate a service level agreement based on the service requirements and parameters.
Further features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the appended drawings, in which:
It will be noted that throughout the appended drawings, like features are identified by like reference numerals.
In the following description, features of the present invention are described by way of example embodiments. For convenience of description, these embodiments make use of features and terminology known from 4G and 5G networks as defined by the Third Generation Partnership Project (3GPP). However, it shall be understood that the present invention is not limited to such networks. Rather, methods and systems in accordance with the present invention may be implemented in any network in which a mobile device may connect to the network through at least one access point, and subsequently be handed-over to at least one other access point during the course of a communications session.
The memory 108 may comprise any type of non-transitory system memory, readable by the processor 106, such as static random-access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or a combination thereof. In specific embodiments, the memory 108 may include more than one type of memory, such as ROM for use at boot-up, and DRAM for program and data storage for use while executing programs. The bus 112 may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus, or a video bus.
The electronic device 102 may also include one or more network interfaces 110, which may include at least one of a wired network interface and a wireless network interface. As illustrated in
The mass storage 114 may comprise any type of non-transitory storage device configured to store data, programs, and other information and to make the data, programs, and other information accessible via the bus 112. The mass storage 114 may comprise, for example, one or more of a solid-state drive, hard disk drive, a magnetic disk drive, or an optical disk drive. In some embodiments, mass storage 114 may be remote to the electronic device 102 and accessible through use of a network interface such as interface 110. In the illustrated embodiment, mass storage 114 is distinct from memory 108 where it is included, and may generally perform storage tasks compatible with higher latency, but may generally provide lesser or no volatility. In some embodiments, mass storage 114 may be integrated with a memory 108 to form an heterogeneous memory.
The optional video adapter 116 and the I/O interface 118 (shown in dashed lines) provide interfaces to couple the electronic device 102 to external input and output devices. Examples of input and output devices include a display 124 coupled to the video adapter 116 and an I/O device 126 such as a touch-screen coupled to the I/O interface 118. Other devices may be coupled to the electronic device 102, and additional or fewer interfaces may be utilized. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide an interface for an external device. Those skilled in the art will appreciate that in embodiments in which ED 102 is part of a data center, I/O interface 118 and Video Adapter 116 may be virtualized and provided through network interface 110.
In some embodiments, electronic device 102 may be a standalone device, while in other embodiments electronic device 102 may be resident within a data center. A data center, as will be understood in the art, is a collection of computing resources (typically in the form of servers) that can be used as a collective computing and storage resource. Within a data center, a plurality of servers can be connected together to provide a computing resource pool upon which virtualized entities can be instantiated. Data centers can be interconnected with each other to form networks consisting of pools computing and storage resources connected to each by connectivity resources. The connectivity resources may take the form of physical connections such as Ethernet or optical communications links, and may include wireless communication channels as well. If two different data centers are connected by a plurality of different communication channels, the links can be combined together using any of a number of techniques including the formation of link aggregation groups (LAGs). It should be understood that any or all of the computing, storage and connectivity resources (along with other resources within the network) can be divided between different sub-networks, in some cases in the form of a resource slice. If the resources across a number of connected data centers or other collection of nodes are sliced, different network slices can be created.
As may be seen in
The application platform 204 provides the capabilities for hosting applications and includes a virtualization manager 210 and application platform services 212. The virtualization manager 210 supports a flexible and efficient multi-tenancy run-time and hosting environment for applications 214 by providing Infrastructure as a Service (IaaS) facilities. In operation, the virtualization manager 210 may provide a security and resource “sandbox” for each application being hosted by the platform 204. Each “sandbox” may be implemented as a Virtual Machine (VM) 216 that may include an appropriate operating system and controlled access to (virtualized) hardware resources 206 of the server 200. The application-platform services 212 provide a set of middleware application services and infrastructure services to the applications 214 hosted on the application platform 204, as will be described in greater detail below.
Applications 214 from vendors, service providers, and third-parties may be deployed and executed within a respective Virtual Machine 216. For example, MANagement and Orchestration (MANO) functions and Service Oriented Network Auto-Creation (SONAC) functions (or any of Software Defined Networking (SDN), Software Defined Topology (SDT), Software Defined Protocol (SDP) and Software Defined Resource Allocation (SDRA) controllers that may in some embodiments be incorporated into a SONAC controller) may be implemented by means of one or more applications 214 hosted on the application platform 204 as described above. Communication between applications 214 and services in the server 200 may conveniently be designed according to the principles of Service-Oriented Architecture (SOA) known in the art.
Communication services 218 may allow applications 214 hosted on a single server 200 to communicate with the application-platform services 212 (through pre-defined Application Programming Interfaces (APIs) for example) and with each other (for example through a service-specific API).
A service registry 220 may provide visibility of the services available on the server 200. In addition, the service registry 220 may present service availability (e.g. status of the service) together with the related interfaces and versions. This may be used by applications 214 to discover and locate the end-points for the services they require, and to publish their own service end-point for other applications to use.
Mobile-edge Computing allows cloud application services to be hosted alongside virtualized mobile network elements in data centers that are used for supporting the processing requirements of the Cloud-Radio Access Network (C-RAN). For example, eNodeB or gNB nodes may be virtualized as applications 214 executing in a VM 216. Network Information Services (NIS) 222 may provide applications 214 with low-level network information. For example, the information provided by NIS 222 may be used by an application 214 to calculate and present high-level and meaningful data such as: cell-ID, location of the subscriber, cell load and throughput guidance.
A Traffic Off-Load Function (TOF) service 224 may prioritize traffic, and route selected, policy-based, user-data streams to and from applications 214. The TOF service 224 may be supplied to applications 214 in various ways, including: A Pass-through mode where (either or both of uplink and downlink) traffic is passed to an application 214 which can monitor, modify or shape it and then send it back to the original Packet Data Network (PDN) connection (e.g. 3GPP bearer); and an End-point mode where the traffic is terminated by the application 214 which acts as a server.
As may be appreciated, the server architecture of
Other virtualization technologies are known or may be developed in the future that may use a different functional architecture of the server 200. For example, Operating-System-Level virtualization is a virtualization technology in which the kernel of an operating system allows the existence of multiple isolated user-space instances, instead of just one. Such instances, which are sometimes called containers, virtualization engines (VEs) or jails (such as a “FreeBSD jail” or “chroot jail”), may emulate physical computers from the point of view of applications running in them. However, unlike virtual machines, each user space instance may directly access the hardware resources 206 of the host system, using the host systems kernel. In this arrangement, at least the virtualization layer 208 of
Resource 1332 is partitioned to allocate resources to Slice A 332A, and Slice B 332B. A portion 332U of the resources available to Resource 1332 remains unallocated. Those skilled in the art will appreciate that upon allocation of the network resources to different slices, the allocated resources are isolated from each other. This isolation, both in the compute and storage resources, ensures that processes in one slice do not interact or interfere with the processes and functions of the other slices. This isolation can be extended to the connectivity resources as well. Connectivity Resource 334 is partitioned to provide connectivity to Slice A 334A and Slice B 334B, and also retains some unallocated bandwidth 334U. It should be understood that in any resource that either has unallocated resources or that has been partitioned to support a plurality of resources, the amount of the resource (e.g. the allocated bandwidth, memory, or number of processor cycles) can be varied or adjusted to allow changes to the capacity of each slice. In some embodiments, slices are able to support “breathing”, which allows the resources allocated to the slice to increase and decrease along with any of the available resources, the required resources, an anticipated resource need, or other such factors, alone or in combination with each other. In some embodiments the allocation of resources may be in the form of soft slices in which a fixed allocation is not committed and instead the amount of the resource provided may be flexible. In some embodiments, a soft allocation may allocate a percentage the resource to be provided over a given time window, for example 50% of the bandwidth of a connection over a time window. This may be accompanied by a minimum guaranteed allocation. Receiving a guarantee of 50% of the capacity of a connectivity resource at all times may provide very different service characteristics than receiving 50% of the capacity of the connectivity resource over a ten second window.
Resource 2336 is partitioned to support allocations of the available compute and storage resources to Slice A 336A, Slice C 336C and Slice B 336B. Because there is no allocation of resources in connectivity resource 334 to Slice C, Resource 2336 may, in some embodiments, not provide a network interface to Slice C 336C to interact with connectivity resource 334. Resource 2336 can provide an interface to different slices to Connectivity Resource 338 in accordance with the slices supported by Connectivity Resource 338. Connectivity Resource 340 is allocated to Slice A 340A and Slice C 340C with some unallocated capacity 340U. Connectivity Resource 340 connects Resource 2336 with Resource 3342.
Resource 3342 provides compute and storage resources that are allocated exclusively to Slice C 342C, and is also connected to Connectivity Resource 344 which in addition to the unallocated portion 344U includes an allocation of Connectivity Resource 344A to slice A. It should be noted that from the perspective of functions or processes within Slice A, Resource 3342 may not be visible. Connectivity Resource 344 provides a connection between Resource 3342 and Resource 4346, whose resources are allocated entirely to Slice A 346A. Resource 4346 is connected to Resource 1332 by Connectivity Resource 348, which has a portion of the connection allocated to Slice A 348A, while the balance of the resources 348U are unallocated.
It should be understood that within the storage and compute resources illustrated in
The European Telecommunications Standards Institute (ETSI) has developed a set of standards for Network Function Virtualization (NFV) MANagement and Orchestration (MANO). As illustrated in
The NFV MANO 432 can communicate with an OSS/BSS system 450 through OS-MA interface, and to a Service, VNF & Infrastructure description database 452 though an SE-MA interface. The Service, VNF & Infrastructure description database 452 can contain operator information about the services, VNFs and infrastructure deployed in the network. Service, VNF & Infrastructure description database 452 and OSS/BSS 450 can be connected to each other so that the OSS/BSS 450 can update and maintain the Service, VNF & Infrastructure description database 452 as needed.
NFVI 470 interacts with the VIM 448 through the NF-VI interface. Underlying resources can often be classified as compute resources 474, memory resources 478 and network resources 482. Memory resources 478 may also be referred to as storage resources, while network resources 482 may also be referred to as connectivity resources. A virtualization layer 472 allows for the abstraction of the underlying resources which it is connected to through a Vi-HA interface. It should be understood that the underlying resources may be either physical or virtual resources. The Virtualization layer 472 allows for the abstraction of the underlying resources into virtual compute resources 476, virtual memory resources 480 and virtual network resources 484. These virtualized resources can be provided to the element management system 454 through the VN-NF interface so that they can be used as the resources upon which the VNFs (shown as VNF1458, VNF2462 and VNF 3466) can be instantiated. EM 454 can be connected to the VNFM 446 within NFV MANO 432 through interface VE-VNFM, and to the OSS/BSS 450 through another interface. Each VNF instantiated upon the virtual resources provided by NFVI 470 can be associated with an element manager (EM1456, EM2460 and EM3464). The use of an element manager allows the OSS/BSS to have two paths through which the VNFs can be managed. A VNF can be managed through the VNFM 446, or through the element manager associated with the VNF. Each element manager can provide the same management controls that it would otherwise provide for a physical network element. Thus, the OSS/BSS 450 can treat each VNF as a conventional network function. Modification to the resource allocation associated with a VNF can be requested by an element manager through the VNFM 446, or through a request from the OSS/BSS 450 over the OS-MA interface.
The virtualization of network functions allows functions to be deployed with the resources that are required. As the demand for the functions increases, the resources allocated to the functions can be increased, which avoids an intentional over provisioning of the functions at instantiation. In conjunction with the above described slicing and data center utilization, flexible networks can be deployed in a manner that allows an operator to dynamically modify the connectivity between functions (thus changing the logical topology of the network) and to dynamically modify the location of and resources allocated to the network functions (thus changing the physical topology of the underlying network). Additional resources at the same location can be allocated to existing function to allow for scaling up of an existing function, and resources can be removed from an allocation to allow for a scaling down of a function. Resources from more than one resource pool or data center can be allocated to a function so that it can be scaled out, and resources from different pools can be removed to allow a function to be scaled in. Functions can be moved by transferring their state information to another network function, and in some instances, a function can be moved through a combination of scaling out and scaling in functions.
3GPP Technical Reference (TR) 28.801 describes three functional entities for managing one or more NSIs to support communication services. These functional entities include a Communication Service Management Function (CSMF), a Network Slice Management Function (NSMF), and a Network Slice Subnet Management Function (NSSMF). The CSMF is responsible for translating the communication service related requirement to network slice related requirements. The CSMF communicates with Network Slice Management Function (NSMF). The NSMF is responsible for management and orchestration of NSI. The NSMF derives network slice subnet related requirements from network slice related requirements. The NSMF communicates with the Network Slice Subnet Management Function (NSSMF) and Communication Service Management Function. The NSSMF is responsible for management and orchestration of NSSI. The NSSMF communicates with the NSMF.
In addition, it is useful to consider an Infra-structure Management function (InMF) and a business service management (BSM) function. The Infra-structure Management function (InMF) may be considered to encompass one or more management entities associated with the provision of Infrastructure as a Service (IaaS). For example, the InMF may comprise one or part or all of the elements of the MAN 432 described above with reference to
The BSM, also referred to as a Service Management (SM) function, may be responsible for service related management for one or more types of service. Specific BSM responsibilities may include: Service negotiation with a customer providing details of services that can be offered; finalizing the SLA and providing business service requirements to the appropriate management function. Example business service requirements may include the following. For a communication service, the BSM may send communications service requirements to CSMF. For NSI as a service, the BSM may send NSI requirements to NSMF. For NSSI as a service, the BSM may send NSSI requirements to NSSMF. For Infrastructure (or Assets) as a service, the BSM may send infrastructure requirements to InMF.
In some embodiments, the BSM may also provide service related information to the customer according to the negotiated SLA.
In the following text, headings in bold are provided as a useful guide to the reader but should not be considered limiting.
Involvement of the Management Functions when Providing Different Types of Business Services
There are four main business services considered in this disclosure: Communication service as a service (CaaS); NSI as a service (NSaaS); NSSI as a service (NSSaaS); and Infrastructure as a service (IaaS).
CSMF of a Communication Service Provider (CSP) may be configured to provide the communication service to the Communication Service Customer (CSC). NSMF of a Slice Provider may be configured to provide a network slice to the CSMF of the slice customer, which may be a network operator (NOP). NSSMF of a Subslice Provider may be configured to provide network subslice to the NSMF of a subslice customer, which may be a network operator (NOP). InMF of an Infrastructure Provider may be configured to provide network infrastructure to the NSSMF of an infrastructure customer, which may be a network operator (NOP).
Business negotiation may be handled by the business and service management (BSM) entity and it finalizes the business service requirements and SLA. Then, the business requirements are processed to define a customer service requirement and provided to the CSMF. CSP can have tenant management and service management capabilities to handle negotiations. Alternatively, either one of these management capabilities can be at CSC, depending on the services and customers. CSP can utilize a high level of automation, management data analytics services, and intent-driven networking to process negotiations.
Intent-driven networking is a term used to describe when high-level requests can be made. For example, a customer may request a network operator provide a video service for 100 users. This request does not include any details regarding the network configuration etc. Alternatively, a more detailed request could be a request with configuration, policy and other details regarding network operation and creation, e.g., properties of network entities (deep packet inspector with X number of CPUs, Access and Mobility Management Function with Y capacity etc.), topology, policy etc. However, in order to enable the customer to make such a detailed request, the management capabilities, resource information etc. of the service provider need to be communicated (exposed) to the customer. Then, the customer can provide a detailed request, e.g., via filling the attributes of a network slice or service instance template.
Accordingly, a CSC making a request in business terms (e.g., a video service for 100 users) can be considered an example of intent-driven management. Intent-driven management can also apply for different types of network provider. For example, a CSMF requesting an NSI with high-level details, can also be considered another type/layer of intent-driven management. If the CSI provides all the details of a network slice instance request, then the intent can be considered “null”, as the CSI is not providing an intent, but all of the specific details of the NSI. Therefore, different exposure levels in this disclosure can correspond to different levels of intent-driven network management.
CSMF will provide the NSMF with network slice requirements that correspond to the service requirements. The communication service instance is the internal 3GPP representation of the service provided using the NSI.
In the embodiment illustrated in
In some embodiments, the Slice Management Exposure Function (SMEF) 730 may act as an interface or a proxy to NSMF 531. The SMEF 730 manages the NSI 770, which may include NSSIs 777, 773, which are in turn created by NSSMF 541. The SMEF provides exposure interfaces for data and/or management exposure. It is the enabler to have different exposure levels without complicating individual network functions, such as NSMF, CSMF. An exposure level can be provided to the SMEF as an “intent”, and SMEF can arrange the network to respond to this intent/request. In this embodiment, SMEF 730 enables CSP 560 to monitor and/or manage NSI (A) 770 by exposing interfaces of NSMF 531. As a result, the CSP 560 obtains management capability without having the need to have the NSMF. The interface between SMEF 730 and CSP 560 can utilize intent-driven networking.
In some embodiments, how much is exposed is determined by the Network Operator (NOP) 575 and captured in the SLA since some of the management functionality may be handled by the NOP 575. For example, configuration management (CM) and fault management (FM) may be done by the Network Operator 575 and performance management (PM) may be done by the customer 560. This can lead to different automation levels, as well as, different levels of intent-driven management.
The service request and related service negotiation happens initially between the customer 510/560 using the CSMF 521 of BSM 870 interacting with BSM 880 of NSI Provider A 575, which is shown by a solid line. However, after the SLA is established by BSMs 870, 880, BSM 880 may provide network slice requirements to the NSMF 531 and NSMF 541. The network provider provides authorized access to certain NSMF functions so that the customer can use the NSI for its communication services. The interaction between BSMs 870, 880 can include requests and exposure for negotiating the SLA.
The network slice customer may use NSI A 770 and another NSI B 795 provided by a different Network Operator 790 to provide a communication service to a CSC. The CSMF 521 of the network slice customer 560 may prepare an integrated service instance 780 for this purpose, which uses both NSI A 770 and NSI B 795. It should be appreciated that the Slice provider 575 of
In the embodiment illustrated in
The service request and related service negotiation happens initially between the customer BSM 880 and the provider BSM 830 which is indicated by a solid line which indicates an SLA is established which meets network slice requirements. The BSM 830 may use NSSMF 542 to provide an NSSI 877,873 to the customer's NSMF 532 or NSSMF 547 as applicable. After the SLA is established, the network provider may provide authorized access to certain NSSMF functions so that the customer can use the NSSI for its communication purposes.
It is noted that in
In the embodiment illustrated in
The service request and related service negotiation may happen initially between the customer BSM 907 and the provider BSM 909 which is indicated by a solid line. The BSM may use InMF 553 to provide network infrastructure (e.g., access node, links, virtual resources, network functions) to the customer's NSSMF 543 as applicable. After the SLA is established, the network provider may provide authorized access to certain InMF functions so that the customer can use the network infrastructure for its communication purposes. Similar to the above modes, the NSSI provider 590 servers multiple roles, namely the infrastructure customer to infrastructure providers 595, 990, and NSSI 917 provider to slice provider 580.
There are several exposure types based on exposure of information, management, and design capabilities:
Each exposure type includes a corresponding level of detail that can be provided in the request from a requesting customer. Accordingly, each exposure type allows for more detailed requests, allowing for more detailed control by the requester of the resources provided by the provider. From exposure type A1 to E2, the network management evolves from fully intent-driven to a less intent-driven fashion.
For all exposure types, the customer may be provided with monitoring information, e.g., alarms about reaching to congestion levels. In this context, exposure types may affect the procedures and contents in the interfaces. For example, in case of congestion, the customer may need to request and negotiate some modifications with the provider. If the customer has management capabilities, e.g. exposure type E2, the customer may be able to perform modifications to some extent. Similarly, if the customer provides NSTs, then, CSMF does not need to request database information from the NSMF.
Exposure types A to D enable a customer to make more clear offers, and more specific requests. The exposure types D1 and D2 enable the customer to interfere with the network. There are 2 main advantages of providing exposure to customers. One advantage provides quick service provisioning: e.g., the customer can prepare more detailed requests by being able to consider the capabilities of the network. A second advantage is flexibility: e.g, the customer has more flexibility to modify the services.
In terms of openness, the management entities may be closed, partially open or fully open to each other. For example, a CSMF may be provided with partial or full access the NSMF catalogue. The CSMF may not have the full access if the NSMF belongs to another vendor. In this case, CSMF may only send a common CST with attributes, or network requirements directly.
It is useful to distinguish between exposed information and exposed functions. For example, NST may be in a database, which is exposed. But the CSMF may have other capabilities and contents, such as vendor-specific algorithms and functions. Providing access to (i.e. exposing) NST does not imply that all of the CSMF is exposed. On the other hand, if management exposure is provided, e.g., exposure types E1&E2, then the CSMF of the provider may be bypassed by the CSMF of the customer, or it may be opened to the customer via an interface to facilitate exposure.
There are also other internal openness levels that are not listed in detail above, but are referred to when they are important for the procedures described in the following sections.
Table 1 below illustrates an example of exposure of management functions to a 3rd party
Table 2 below illustrates an example of Exposure of communication service data to a 3rd party
These procedures are to perform initial network planning and service catalogue preparation. These may be common to all service types. A service provider network includes a Service Manager (SM) (also referred to as BSM).
Step 0-1: Infra-structure self-discovery and records preparation with access to the operator. This may include additional infrastructure that can be acquired/borrowed from 3rd parties.
Step 0-2; Operator decides what services to provide. For example, the operator can select the services to provide in cases in which there may be several options. For example. Operator may ask what services the network can support from SM (may use an automated SONAC tool which provides all the possible high level service types to the operator and the quantities that can be provided in each area). In other cases, the Operator may decide after analyzing the market trends.
Step 0-3: Operator provides policies (e.g. costs) for buying/selling/borrowing resources from 3rd parties
Step 0-4: Operator provides policies on service provision and provides service types that the network should provide (e.g. exposure).
Step 0-5: The Service Manager (SM) may prepare one or more service catalogues. Examples include: High level service types and attributes (details of 1st level categories); and High level service types and attributes with capacity for each service type for different geographical area (CaaS, NSaaS, NSSaaS).
Network Slice Subnet as a Service (NSSaaS) can be provided in response to a new service request or to support an existing service (e.g. as a response to service update request).
Step 1: Customer access the catalogue provided by the provider or the provider sends the available services to the customer depending on the exposure type and customer make a request to the provider. The NSSI request may have the following content depending on the exposure types.
Step 2: SM of the provider receives customer requirements from the customer, which are the initial requirements. These requirements may include high-level service types, e.g., business service templates, isolation, security, charging methods, Geographical areas based time duration based network KPIs, management exposure types, and certain openness.
Step 3: SM performs an initial evaluation of the request and prepares initial internal service requirements. If the initial requirements are not feasible, e.g., exposure of information is not appropriate, the SM can re-negotiate. Also, if the requested service type is not provided by the NOP, a direct rejection of the request can also happen at this time. The SM may prepare internal service requirements to match the customer requirements for this purpose.
Step 4: This procedure may trigger NSSaaS catalogue preparation, or NSSaaS catalogue update. A catalogue may be kept at database of NSSMF. In that case, NSMF and/or SM requests catalogue exposure (partially or fully open), or template list etc. The service catalogue update requires that a catalogue has been prepared prior to receiving the request for the current service.
Step 5: Feasibility check—VNAC has several steps and options as below after which the SM provide different options to the customer (counter-offers or acceptance of the request for an agreed cost).
Step 6: Re-negotiation and SLA preparation: Steps (2)-(5) may be repeated until an agreement is reached with the updated customer requirements. Financial aspects of the resources may be evaluated (e.g. cost for the service, which may be dynamically changed if customer agrees to that).
Step 7: If an SLA is not established, the NSSI request may be rejected.
Step 8: If an SLA is established, after agreeing to an SLA, internal requirement preparation may be finalized to create the logical network. The internal service requirement in NSSaaS in this case are the network slice subnet requirements which include NFs, NF chains, or high level capabilities
Customer's service request evaluation, feasibility check (VNAC) and SLA establishment are completed before this phase. The following procedure of internal service requirement (i.e., the network slice subnet requirement) preparation is performed at this stage. This is one of the phases of the service lifecycle:
Prepare Service Requirement—
SM sends the specific network requirements to NSSMF:
Prepared NSSIs are on-boarded in this stage
NSSMF of the provider NSSaaS operation can begin after the deployment.
After an NSSI for a customer's NSI has been prepared and provisioned, the NSMF of the customer may request the activation of the NSSI so that NSSI's runtime begins.
Some modifications may be required while the NSSI is in run-time.
Service modification can trigger NSSI modification, termination, or creation of new NSSIs.
The customer's NSMF may request to terminate an NSSI. Optionally, the customer's SM may request this from the operator's SM and operator's SM may inform that to the NSSMF managing the NSSI.
The customer may send a request to the provider for service termination.
NSSMF performs the required modifications to all NSSIs.
An acknowledgement may be received by the SM indicating that the NSSI decommissioning and/or modification is completed, required exposure interfaces are disabled, and NSSaaS is terminated.
SLA may be terminated upon receiving the acknowledgement.
Network Slice as a Service (NSaaS) can be provided in response to a new service request or to support an existing service (e.g. as a response to service update request).
Step 1: SM receives customer requirements from the customer, which are the initial requirements. These requirements may include high-level service types, e.g., business service templates, management exposure types, and certain openness.
Step 2; SM performs an initial evaluation of the request and prepares initial internal service requirements. If the initial requirements are not feasible, e.g., exposure of information is not appropriate, SM can re-negotiate. Also, if the requested service type is not provided by the NOP, a direct rejection of the request can be provided.
Step 3: Depending on the required exposure type, requested information may be provided to the customer, e.g., service types, catalogue, templates etc.
Step 4: SM may prepare internal service requirements to match the customer requirements for this purpose.
Step 5: This procedure may trigger NSaaS catalogue preparation, or NSaaS catalogue update. A catalogue may be kept at database of NSMF. In that case, CSMF may request catalogue exposure (open), or template list etc. Similar request may be sent to NSSMF by NSMF.
Step 6: The service catalogue update requires an existing catalogue prepared earlier than receiving the request for the current service
Step 7: Feasibility check—VNAC has several steps and options:
Step 8: Re-negotiation and SLA preparation: If needed, steps (2)-(5) may be repeated until an agreement is reached with the updated customer requirements.
Step 9: If SLA is not established, the NSI is not provided.
Customer's service request evaluation, feasibility check (VNAC) and SLA establishment are completed before this phase. The following procedure of internal service requirement (i.e., the network slice requirement) preparation is performed at this stage. This is one of the phases of the service lifecycle:
Prepare service requirement—SM sends the specific network requirements to NSMF:
Alternatively, slice requirements can be sent to the NSMF, which can establish the required NSTs and NSIPs. In this case, NSMF may not be open to CSMF and/or SM, e.g., they may be provided by different vendors. An NST may include NSSTs. Details of NSS provisioning procedures are explained below.
An NSMF may communicate with an NSSMF to obtain or manage required NSSTs and NSSIPs. Alternatively, slice requirements can be sent to an NSSMF which can establish the required NSSTs and NSSIPs. In this case, NSSMF may not be open to NSMF, e.g., they may be provided by different vendors.
Prepared NSIs (and NSSIs) may be on-boarded in this phase.
NSMF of the provider of the NSaaS can begin operation after the deployment.
After required NSIs for a customer's NSI request are prepared and provisioned, CSMF of the customer may request the activation of the NSI(s) so that NSIs runtime begins.
Some modifications of the service may be required as a result of monitoring and supervision. NSaaS modification procedure is explained below.
Some modifications may be required while the NSI is in runtime.
Exposure A-D: A request for modification can be negotiated with SM.
SM can perform/request a feasibility check (step 7 described above).
NSI modification can trigger NSSI modification, termination, or creation of NSSIs.
The customer's CSMF or NSMF may request to terminate an NSI. Optionally customer's SM may request this from the operator's SM and operator's SM informs that to NSMF managing the NSI.
1. The customer may send a request to the provider for service termination.
2. NSMF performs any required modifications to involved NSI and NSSIs (for example, via NSSMF).
3. An acknowledgement may be received by the SM indicating that the NSI decommissioning and/or modification is completed, required exposure interfaces are disabled, and NSaaS is terminated.
4. SLA may be terminated upon receiving the acknowledgement.
Communication as a Service (CaaS) can be provided in response to a new service request or to support an existing service (e.g. as a response to service update request).
Step 1: Customer accesses the catalogue provided by the provider or the provider sends the available services to the customer depending on the exposure type and customer makes a request to the provider. The CSI request may have the following content depending on the exposure types.
Step 2: SM of the provider receives customer requirements 1015 from the customer, which are the initial requirements. These requirements may include high-level service types, e.g., business service templates, isolation, security, charging methods, Geographical areas based time duration based network KPIs, management exposure types, and a requested level of openness.
Step 3: SM performs an initial evaluation of the request and prepares initial internal service requirements. If the initial requirements are not feasible, for example because a requested exposure of information is not appropriate, the SM can re-negotiate. Also, if the requested service type is not provided by the NOP, a direct rejection of the request can also happen at this time.
Step 4: SM may prepare internal service requirements to match the customer requirements.
Step 5: The above procedure may trigger service catalogue preparation, or service catalogue update. The service catalogue update may require a catalogue to be prepared before receiving the request for the current service.
Step 6: Feasibility check—VNAC has several steps and options as below after which the SM provide different options to the customer (counter-offers or acceptance of the request for an agreed cost):
Step 7: Re-negotiation and SLA preparation: Steps (2)-(5) may be repeated until an agreement is reached with the updated customer requirements. Financial aspects of the resources may be evaluated.
Step 8: If an SLA is not established, the CSI is not provided.
Customer's service request evaluation, feasibility check (VNAC) and SLA establishment are completed before this phase. The following procedure of internal service requirement (i.e., the network slice subnet requirement) preparation is performed at this stage. This is one of the phases of the service lifecycle:
Prepare service requirement—SM sends the specific network requirements to CSMF:
CSMF can send NSI requirements to NSMF, which can establish the required NSTs and NSIPs. In this case, NSMF may not be open to CSMF, e.g., they may be provided by different vendors. An NST may include one or more NSSTs. Details of NSSI provisioning procedures are explained below.
NSMF may communicate with NSSMF to obtain or manage required NSSTs and NSSIPs. Alternatively, slice requirements can be sent to NSSMF, and NSSMF can establish the required NSSTs and NSSIPs. In this case, NSSMF may not be open to NSMF, e.g., they may be provided by different vendors.
Accordingly, an example call flow is illustrated in
An example call flow is illustrated in
If a new slice is necessary, the signalling for CSI deployment on a new slice is illustrated at 1235. The CSMF 520 sends the CSI, NST and NSST requirements 1237 to the NSMF 530. NSMF 530 performs NSI preparation 1238 and sends the NSST requirements 1239 to the NSSMF 540. The NSSMF 540 then performs NSSI preparation 1240, network environment preparation 1241 and NSSI creation 1242. The NSSMF 540 then transmits the NSSI information 1243 to the NSMF 530, which performs NSI creation 1244. The NSMF 530 then transmits the NSI information 1245 to the CSMF 520.
CSMF 520 informs the SM 1010 that CSI operation begins 1250. SM 1010 than informs the SM 1005 of the 3rd party CSC 510 that Service runtime begins 1255.
Prepared CSIs are deployed in this stage.
CSMF of the provider of CaaS can begin CaaS operation after this stage.
After applicable NSIs for a customer's CSI are prepared and provisioned, the CSMF of the customer may request the activation of the CSI so that the CSI's runtime begins (except in Exposure E2, where the customer may not need to request activation).
Some modifications may be required on the service as a result of monitoring and supervision.
Some modifications may be required while the CSI is in run-time.
SM can perform/request a feasibility check as described above. An update of the SLA may also be negotiated. The above steps are similar to steps (2)-(7) above. If the requested modification is feasible, all the necessary steps (5)-(7) are completed by the provider.
Service modification can trigger NS(S)I modification, termination, or creation of new NS(S)Is.
The customer's CSMF may request to terminate the CSI. Optionally the customer's SM may request this from the operator's SM and operator's SM informs that to CSMF managing the CSI.
The customer may send a request to the provider for service termination.
CSMF manages the required modifications with NSMF and NSSMF.
An acknowledgement may be received by the SM indicating that the CSI termination is completed, and required exposure interfaces are disabled. The SLA may be terminated upon receiving the acknowledgement.
Accordingly,
For either type, the SM 1010 evaluates the requirements 1335, and can optionally send a quick response 1340 for exposure types C and D. A more detailed evaluation procedure 1345 may be needed if up to date information is not available at the SM 1010 or the CSMF 520. Such an evaluation includes the SM 1010 sending the service requirements 1346 to the CSMF 520. The CSMF 520 then sends the network requirements 1347 to the NSMF 530, which determines 1348 the resource requirements. The NSMF 530 sends a resource request 1349 to the NSSMF 540, which determines 1350 the resource availability. A resource report 1351, accepting or rejecting the modification, is sent from the NSSMF 540 to the NSMF 530. NSMF 530 then sends resource report 1352, accepting or rejecting the modification, to the CSMF 520. CSMF 520 then re-evaluates the requirements 1352, and then accepts or rejects the modification, along with sending financial aspects 1354 of the modification to the SM 1010. The SM 1010 then re-evaluates the request 1355 and accepts the request with an SLA update 1360 (or rejects the request).
Note that the signalling shown in
One a service modification is negotiated, resulting in an updated SLA,
Infrastructure as a Service (IaaS) can be provided to the customer to support an NSSI of the customer, as depicted in
Step 1: SM receives customer requirements from the customer, which are the initial requirements. These requirements may include high-level service types, e.g., business service templates, management exposure types, and certain openness.
Step 2: SM performs an initial evaluation of the request and prepares initial internal service requirements. If the initial requirements are not feasible (for example, the exposure of information is not appropriate) the SM can re-negotiate. Also, if the requested service type is not provided by the NOP, a direct rejection of the request can be provided.
Step 3: Depending on the required information exposure type, requested information may be provided to the customer:
Step 4: SM may prepare internal service requirements to match the customer requirements for this purpose.
Step 5: This procedure may trigger IaaS catalogue preparation, or IaaS catalogue update. A catalogue may be maintained in a database of the SM.
Step 6: The service catalogue update requires an existing catalogue is prepared before receiving the request for the current service.
Step 7: Feasibility check—VNAC has several steps and options:
Step 8: Re-negotiation and SLA preparation: Steps (2)-(5) may be repeated until an agreement is reached with updated customer requirements. Financial aspects of the resources may be re-evaluated.
Step 9: If an SLA is not established, the IaaS is not provided.
Step 10: If an SLA is established, after agreeing to an SLA, internal requirement preparation is finalized to create the logical network.
Step 11: Management Exposure for IaaS:
IaaS requirements preparation, feasibility check (VNAC) and SLA establishment are completed before this phase. The following procedure is performed in relation to some service lifecycle phases:
1. Prepare service requirement—SM sends the specific network requirements to InMF:
Service Deployment—IaaS is ready to be deployed after internal preparation is completed.
Service Operation—IaaS operation can begin.
After all resources are prepared and provisioned, IaaS runtime begins.
Some modifications of the service may be required as a result of monitoring and supervision.
Some modifications may be required while the IaaS is in run-time.
Exposure A-E1: A request for modification can be negotiated with SM.
2. SM can perform/request a feasibility check. An update of the SLA may also be negotiated. The above steps are similar to steps (2)-(7) described above. If the requested modification is feasible, all the necessary steps (5)-(7) are completed by the provider.
3. Negotiation may be required for modification, if additional resources are required.
The customer may request to terminate IaaS.
1. The customer's SM may send a request to the provider's SM for service termination.
2. SM receives an acknowledgement indicating that the IaaS is terminated, all related resources are freed. SM may also receive updated catalogue information, or start a resource-discovery process.
3. SLA is terminated upon receiving the acknowledgement.
Network management entities carrying out or controlling the methods described above may be resident within a management plane of a communications network. These entities may interact with control plane entities (and possibly user/data plane entities) within the network slices instances that are created and discussed. These network management entities may provide methods and functions for the utilization of slice templates and slice instance profiles to satisfy or address (wholly or in part) communication service requests. These communication service requests may be received from a customer of a service provider. Addressing the communication service requests may include taking into account aspects of the lifecycle management of communication service instances and network slices instances.
An aspect of the disclosure provides a network architecture that can accommodate different types of service providers, each of which can be managed by different administrative domains. The SM is a management function (which can be part of a network management system) which handles the customer request, the specifics of which depends on the exposure level. Customer intent is passed to the SM and SM prepares the network requirement accordingly. In a fully exposed system, the SM does not have to do much as customer request includes most or all of the specifics for allocating the network resources to satisfy the service requirements. In other systems, the request merely specifies broad goals or intents, and it is up to the SM (in conjunction with other network functions) to allocate network resources to satisfy the intent/goals.
Accordingly, a first provider SM function receives a service request from a customer based on the exposed service information. The first provider provides the service using the information obtained from different management functions (which can be supplied by a 2nd provider). The first provider performs a feasibility check based on the information it has (either based on its own resources, and/or based on the 2nd provider's services). If information is not sufficient it can request information from the (2nd provider) other management functions. The information includes one or more of the service types the 2nd management function can provide, the current capacity of those services, the management capability that can be given to the 1st provider, the data that could be exposed to the 1st provider. Based on the feasibility check the 1st provider negotiate with the customer and set up the SLA.
An aspect of the disclosure provides a method of delivering a communication service. Such a method includes receiving, by a network management system, a request from a requestor for a service. The method further includes requesting, by the network management system, resources to satisfy the request. Such a method further includes receiving, by the network management system, information about the resources, and providing the service utilizing the resources. In some embodiments, receiving, by the network management system, information about the resources includes receiving information exposed by an external provider. In some embodiments, the method further includes responsive to receiving information about the resources, exposing details of the resources to the requestor; and negotiating, by the network management system, the parameters of the requested service with the requestor. In some embodiments, negotiating the parameters includes negotiating the parameters of a service agreement to provide the service. In some embodiments, the method further includes the management system exposes to the requestor interfaces for utilizing network functions associated with the service. In some embodiments, the method further includes providing access to network data pertaining to the requested service to the requestor using the interfaces. In some embodiments, the method further includes providing access to network functions for controlling the requested service to the requestor using the interfaces. In some embodiments, the method further includes reserving the resources exposed by the external provider. In some embodiments, requesting, by the network management system, resources to satisfy the request comprises evaluating internal resources and previously exposed resources from external providers to determine what further resources are needed to satisfy request and requesting the further resources. In some embodiments, the request is for a communication service, the requestor is a communication service customer service manager, the network management system includes a communication service provider service manager, and the external provider is a network slice provider which provides access to a network slice to the communication service provider service manager which in turn provides the requested communication service utilizing the network slice. In some embodiments, the request is for a communication service, the requestor is a communication service customer service manager, the network management system includes a Communication Service Management Function (CSMF), and the external provider is a Network Slice Management Function (NSMF) of a network slice provider which provides access to a network slice to the CSMF. In some embodiments, receiving, by the network management system, information about the resources comprises receiving information about the network functions of the network slice exposed to the CSMF from the NSMF. In some embodiments, the request is for a network slice, the requestor is a communication service provider service manager which requests access to a network slice, the network management system includes a Network Slice Management Function (NSMF) of a network slice provider; and the external provider is a Network Slice Subnet Management Function (NSSMF) of a network slice subnet provider. In some embodiments, the network management system can include an SM (BSM). In some embodiments the network management system can include an NSSMF or an InFM. In some embodiments, the request is for a network slice, the requestor is a service manager which requests access to a network subnet slice, the network management system includes a Network Subnet Slice Management Function (NSSMF) of a network sub-slice provider; and the external provider is an Infrastructure Management Function (InMF) of a Infrastructure provider. In some embodiments, the request is selected from a set of request categories, with each category in the set of request categories corresponding to an exposure level category of information exposed to the requestor provides exposure interfaces The method of claim 15 wherein each category provides additional exposure as to at least one of network data and network capability, such that additional details can be included in the request. In some embodiments, the service comprises a selected one of: Communication as a Service (CaaS), Network Slice as a Service (NSaaS), Network Slice Subnet as a Service (NSSaaS), and Infrastructure as a Service (IaaS). In some embodiments, the network management system includes a Service Management Exposure Function (SMEF) which provides exposure interfaces for providing the different categories of exposure. In some embodiments, the request includes partial attributes of at least one of a network slice template and a service instance template according to the exposure level category; and requesting, by the network management system, resources to satisfy the request includes requesting resources not specified in the request.
A further aspect of the disclosure provides a network management system including at least one network interface, a processor and machine readable memory storing machine readable instructions which when executed by the processor, implements a Slice Management Exposure Function. The SMEF is configured to expose interfaces to a 3rd party requesting entity as to at least one of the management capability and data as to the resources controlled by the network management system.
Another aspect of the disclosure provides a network management system configured to selectively expose network management data; receive a request for a network service, the request including service requirements and parameters in accordance with the network management information to be exposed, wherein the service comprises a selected one of: Communication as a Service (CaaS), Network Slice as a Service (NSaaS), Network Slice Subnet as a Service (NSSaaS), and Infrastructure as a Service (IaaS); and responsive to the received request, negotiate a service level agreement based on the service requirements and parameters. In some embodiments the network management system is configured with management capability required for the service. In some embodiments, network management information to be exposed includes at least one of, the available Network slice template information, different service types and the available capacity information for those service types. In some embodiments the network management system is configured for accessing service and management data required for the service. In some embodiments the network management system is configured for accessing service and management data required for the service. In some embodiments the network management system is configured for at least one of: resource preparation for the service, life cycle management of the network used for the service.
In some embodiments the request has a specification detail corresponding to a network exposure type previously provided by the network provider. For example, there are several exposure types (A-D, E1 and E2) each with a different level of specificity as the management capabilities, resources and capacity. Accordingly, the request can have corresponding levels of specificity as to how to implement the request, from an intent based request as to the intent desired, to specific details of how to allocate previously exposed resources to deliver a requested service.
It is noted that that any of the network functions described herein, including the SM, BSM, CSMF, SMEF, NSMF, NSSMF, InFM etc., can be implemented using a suitably configured electronic device of
Although the present invention has been described with reference to specific features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from the invention. The specification and drawings are, accordingly, to be regarded simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention.
This application claims the benefit of U.S. Provisional Application Ser. No. 62/569,018 titled “MANAGEMENT OF NETWORK SLICES AND ASSOCIATED SERVICES” filed on Oct. 6, 2017 which is incorporated by reference herein in its entirety.
Number | Date | Country | |
---|---|---|---|
62569018 | Oct 2017 | US |