Network Slice Provisioning and Operation

Abstract

A method and network management function for allocating slice instances of a communication network are provided. The method includes the management function obtaining a requirement for a slice instance, and the management function checking the feasibility of the slice instance requirement based on network resources and / or network capabilities. The method also includes the management function preparing a network environment for the slice instance based on the slice instance requirement, and the management function serving the slice instance. The method may additionally or alternatively include terminating, modifying, and / or deactivating the slice instance.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based on the U.S. non-provisional patent application with application number 16 / 243,771 filed on January 9, 2019, and the invention name is “NETWORK SLICE PROVISION AND OPERATION”, and claims the priority of the above-mentioned U.S. non-provisional patent application. The above-mentioned U.S. non-provisional patent application claims the priority of the U.S. provisional patent application with application number 62 / 617,133 filed on January 12, 2018, and the invention name is “NETWORK SLICE PROVISION AND OPERATION”, all contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure relates to wireless communications, and certain embodiments or aspects relate to slice instances and mechanisms for providing or provisioning and operating slice instances accordingly. Background Art

[0004] The demand for wireless resources in terms of bandwidth and throughput is constantly increasing. One approach considered for meeting this growing demand is through network virtualization, where network resources and functions are offloaded to one or more existing network nodes or points of presence (PoPs) to provide dynamic service level capabilities when appropriate for specific customer service providers and their end users.

[0005] In some approaches, a customer may subscribe to a mobile network operator (MNO) to obtain one or more so-called virtual network "slices" of network resources. Typically, each network slice is dynamically allocated to provide some relatively isolated and / or homogeneous (in terms of type and grade) services to a relatively homogeneous group of end users of the customer or a class of devices of the subscriber (e.g., a utility and its remote smart meters). In some examples, multiple end users of a customer may constitute a user group for that customer.

[0006] From the customer's perspective, it obtains a separate telecommunications network for its services, while from the perspective of the MNO that provides this service capability, the MNO's network resources and network functions (NF) are shared with other virtual networks (VNs) in a manner that is largely transparent to customers and their end users.

[0007] In the network slicing process, multiple VNs utilize a shared physical network infrastructure. Certain network functions can be downloaded and instantiated from cloud-based resources to one or more existing PoPs as virtual NFs (VNFs) to implement network functions for specific slices. A given PoP may have one or more VNFs downloaded and instantiated on it, each corresponding to one or more slices. When a function is no longer appropriate, the corresponding VNF can be terminated, deactivated, or modified to reflect a more appropriate function.

[0008] Typically, an MNO designs or develops a given network slice and deploys its instances (network slice instance "network slice instance, NSI"). The NSI is generally considered to span the scope of the physical network (end-to-end). In some examples, the NSI can be considered to include one or more network slice subnet instances (network slice subnet instance, NSSI), each NSSI being deployed by downloading and instantiating one or more VNFs corresponding to the design of the network slice subnet. Ultimately, the operator of the NSI and / or NSSI (as the case may be) uses the control plane (CP) 108 function (CPF) to deliver services on the deployed NSSI and / or NSI (generally, "NS(S)I"). In some examples, the NS(S)I may be referred to as a managed NS(S)I ("managed NS(S)I, MNS(S)I").

[0009] The third generation partnership project (3GPP) describes the provision of different types of services in its technical report (TR) 28.801 (specifically clause 7.9.1), including network slice as a service (NSAAS) (clause 7.9.1.3) and network slice subnet as a service (NSSAAS) (clause 7.9.1.4).

[0010] In 3GPP technical specification (TS) 28.531, a use case for the creation of NSI is described.

[0011] also:

[0012] The following table shows an example use case for creating a description for NSSI:

[0013]

[0014] The following table shows an example use case for activation descriptions for NSSI:

[0015]

[0016]

[0017] The following table shows an example use case for deactivation description of NSSI:

[0018]

[0019]

[0020] The following table shows an example use case for a termination description for NSSI:

[0021]

[0022] The following table shows an example use case for creating a description for NSI:

[0023]

[0024] The following table shows an example use case for activation descriptions for NSI:

[0025]

[0026]

[0027] The following table shows an example use case for modifying descriptions for NSI:

[0028]

[0029]

[0030] The following table shows an example use case for deactivating a description for an NSI:

[0031]

[0032] The following table shows an example use case for a termination description for NSI:

[0033]

[0034]

[0035] However, the detailed procedures and interfaces called when provisioning NS(S)I are not described.

[0036] Such detailed processes may describe network conditions including, but not limited to, open and / or specific policies, service types, slices, and service lifecycles, and / or other relevant factors. In some examples, these processes may vary based on factors including, but not limited to, service types and openness levels between network entities, service consumers, and service providers.

[0037] refer to Fig.11 It is generally believed that slice provisioning can include four life cycle stages, namely preparation 1110, commissioning 1130, operation 1140, and decommissioning 1150. In the preparation stage 1110, the NS(S)I can be designed 1111, the network environment can be prepared 1112, and the NS(S)I can be loaded 1113 onto the PoP. In the commissioning stage 1130, the NS(S)I can be created 1131. In some examples, the NS(S)I can be a modified form of a previously created NS(S)I. During the operation stage 1140, the NS(S)I can be activated 1141 and finally deactivated 1145. Between activation 1141 and deactivation 1145, management functions can supervise 1142 and report 1143 the operation of the NS(S)I. In some examples, between activation 1140 and deactivation 1145, the NS(S)I can be operationally modified 1144. During the decommissioning phase 1150, the NS(S)I may be terminated 1151.

[0038] In the present disclosure, the term "supply" is understood to include a combination of the preparation phase and the commissioning phase.

[0039] Accordingly, there may be a need for a mechanism for provisioning and operating network slice instances that is not subject to one or more limitations of the prior art.

[0040] This background information is intended to provide information that may be relevant to the present invention. It is not necessary nor should it be construed that any of the aforementioned information constitutes prior art to the present invention. Summary of the invention

[0041] It is an object of the present disclosure to obviate or mitigate at least one of the disadvantages of the prior art.

[0042] According to a first aspect, a method for allocating a slice instance of a communication network is provided. The method includes a management function obtaining a requirement for a slice instance, and a management function checking the feasibility of the slice instance requirement based on network resources and / or network capabilities. The method also includes the management function preparing a network environment for the slice instance according to the slice instance requirement, and the management function serving the slice instance.

[0043] According to another aspect, a method for checking a request for a slice instance of a communication network is provided. The method includes a management function obtaining a request for a slice instance, and the management function checking the feasibility of the slice instance request based on network resources and / or network capabilities. Checking the feasibility of the slice request includes determining whether the request is feasible.

[0044] According to another aspect, a method for processing a slice instance of a communication network is provided. The method includes a management function obtaining a trigger to terminate a slice instance or a network slice subnet instance of a slice instance, wherein the management function is responsible for the slice instance. The method also includes terminating a slice instance, a component of a slice instance, or a network slice subnet instance of a slice instance. Optionally, in the method, terminating a slice instance or NSSI includes: receiving a slice instance termination request; sending a response to a slice instance termination request; and calling one or more processes for terminating one or more of the following: a slice instance; a component of a slice instance; and an NSSI. Optionally, the method also includes releasing resources held by one or more component entities for supporting the slice instance. Optionally, the method also includes: receiving a slice instance termination request; determining whether to satisfy the slice instance termination request; when determining that the slice instance termination request will be satisfied, calling one or more processes for terminating the slice instance; when determining that the slice instance termination request will not be satisfied, modifying the slice instance instead of terminating the slice instance.

[0045] According to another aspect, a method for modifying a slice instance of a communication network is provided. The method includes receiving a request to modify a slice instance during a slice instance operation phase. The method also includes modifying the slice instance according to the request. Optionally, in the method, the slice instance modification triggers modification of a network slice subnet instance (NSSI) of the slice instance. Optionally, the method also includes determining the feasibility of modifying the slice instance, and modifying the slice instance only when the determination indicates that modifying the slice instance is feasible. Optionally, the method also includes subsequently sending a response indicating that the request is feasible or indicating that the slice instance has been modified according to the request.

[0046] According to another aspect, a method for discovering network resources for supporting a slice instance of a communication network is provided. The method includes a network slice subnet management function obtaining information from one or more component management entities and / or one or more NSSMFs. Optionally, the method also includes requesting an open to one or more component management entities before obtaining the information. Optionally, in the method, discovering network resources is performed before allocating the slice instance, or wherein discovering network resources is performed during allocating the slice instance.

[0047] According to another aspect, a method for supporting the provisioning of slice instances of a communication network is provided, wherein the slice instance includes a network slice subnet instance. The method includes discovering resources and / or capabilities of the network, and deriving requirements for the slice instance. The method also includes checking the feasibility of the slice instance requirements based on network resources and / or capabilities. Optionally, the method also includes: the network slice subnet management function (NSSMF) initiates deactivation of the slice instance and / or one or more component network slice subnet instances (NSSI) of the slice instance. Optionally, in the method, termination of the slice instance triggers termination or deactivation of the above-mentioned one or more component NSSIs. Optionally, in the method, at least one of the component NSSIs is managed by a management entity other than the NSSMF, and wherein the deactivation of the above-mentioned at least one of the component NSSIs includes sending a deactivation request from the NSSMF to the management entity other than the NSSMF.

[0048] According to another aspect, a method for processing a slice instance of a communication network is provided, wherein the slice instance includes a network slice subnet instance. The method includes: receiving a trigger to deactivate the slice instance and / or one or more component network slice subnet instances of the slice instance. The method also includes determining whether to perform deactivation in response to the trigger. The method also includes initiating deactivation of the slice instance and / or one or more component NSSIs of the slice instance when it is determined that deactivation is to be performed. The method also includes modifying the slice instance and / or one or more component NSSIs of the slice instance instead of deactivating it when it is determined that deactivation is not to be performed. Optionally, the method also includes: receiving a request to modify a network slice subnet instance (NSSI) associated with the slice instance; determining the feasibility of the request to modify the NSSI; when the determination indicates that modifying the NSSI is feasible, modifying the NSSI according to the request; when the determination indicates that modifying the NSSI is feasible, sending a response indicating that the request is feasible or indicating that the NSSI has been modified according to the request. Optionally, in the method, the NSSI modification triggers the modification of another component NSSI of the NSSI and / or a component network function (NF) instance that supports the NSSI. Optionally, the method further comprises the management function providing one or more of the following to the subscribing client: resources of the network, capabilities of the network, and associated templates. Optionally, in the method, the capabilities of the network include types of services that the network can provide.

[0049] According to some aspects, a network management function is provided, the network management function comprising a processor and a non-transitory memory for storing machine-readable and machine-executable instructions. When executed by the processor, the instructions cause the network management function to perform one or more methods defined herein.

[0050] Embodiments have been described above in conjunction with various aspects of the present disclosure, and these embodiments may be implemented based on various aspects of the present disclosure. Those skilled in the art will appreciate that embodiments may be implemented in conjunction with the aspects in which they are described, or may be implemented together with other embodiments of that aspect. When embodiments are mutually exclusive or incompatible, this will be apparent to those skilled in the art. Some embodiments may be described with respect to one aspect, and may also be applicable to other aspects, which will be apparent to those skilled in the art. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Example embodiments of the present disclosure will now be described with reference to the following drawings, in which like reference numerals in different drawings represent like elements, and in which:

[0052] Figure 1 is a block diagram of electronic devices within a computing and communication environment 50 that may be used to implement devices and methods according to representative embodiments of the present disclosure;

[0053] Figure 2 is a block diagram illustrating a service-based view of a 5G core network system architecture;

[0054] Figure 3 It is shown from the reference point connection angle as Figure 2 The block diagram of the 5G core network system architecture shown in FIG.

[0055] Figure 4 is a block diagram illustrating the architecture of a 5G radio access network architecture;

[0056] Figure 5 is a block diagram schematically illustrating an architecture in which network slicing may be implemented;

[0057] Figure 6 is shown from the perspective of a single slice Figure 5 A block diagram of the architecture discussed in ;

[0058] Figure 7 is a diagram illustrating a cloud-based implementation of a core network and a radio access network using virtualized functions;

[0059] Figure 8 is a block diagram illustrating a logical platform on which an ED may provide virtualized services;

[0060] Fig. 9 is a block diagram illustrating ETSI NFV MANO compliant management and orchestration services;

[0061] Fig.10 is a diagram showing an embodiment of interaction between a management plane, a control plane, and a user plane of a network;

[0062] Fig.11 is a diagram showing an example of the life cycle of an NS(S)I;

[0063] Fig.12 is a signal flow diagram illustrating an example signal flow for provisioning NSSI according to an example;

[0064] Fig.13 is a signal flow diagram illustrating an example process for provisioning NSSI according to an example;

[0065] Fig.14 is a signal flow diagram illustrating an example process for preparing an NSSI with directory and capability exposure according to an example;

[0066] Fig.15 is a signal flow diagram illustrating an example process for creating an NSSI with directory and capability exposure according to an example;

[0067] Fig.16 is a signal flow diagram illustrating an example process for provisioning an NSSI with catalog and capability opening according to an example;

[0068] Fig.17 is a signal flow diagram illustrating an example process of serving an NSSI by modifying an existing NSSI according to an example;

[0069] Fig.18 is a signal flow diagram illustrating an example process for activating NSSI according to an example;

[0070] Fig.19 is a signal flow diagram illustrating an example process for deactivating NSSI according to an example;

[0071] Fig. 20 is a signal flow diagram illustrating an example process for terminating NSSI according to an example;

[0072] Fig.21 is a signal flow diagram illustrating an example signal flow for provisioning NSI according to an example;

[0073] Fig. 22 is a signal flow diagram illustrating an example process for provisioning NSI according to an example;

[0074] Fig.23 is a signal flow diagram illustrating an example process of preparing an NSI with directory and capability exposure according to an example;

[0075] Fig.24 is a signal flow diagram illustrating an example process of creating an NSI with directory and capability exposure according to an example;

[0076] Fig.25 is a signal flow diagram illustrating an example process for provisioning an NSI with catalog and capability exposure according to an example;

[0077] Fig.26 is a signal flow diagram illustrating an example process of serving an NSI by modifying an existing NSI according to an example;

[0078] Fig. 27 is a signal flow diagram illustrating an example process for activating NSI according to an example;

[0079] Fig.28 is a signal flow diagram illustrating an example flow of an NSI operable according to an example modification;

[0080] Fig.29 is a signal flow diagram illustrating an example process for deactivating NSSI according to an example;

[0081] Fig.30 is a signal flow diagram illustrating an example process for terminating NSSI according to an example; and

[0082] Fig.31 is a flow chart illustrating an example of a method.

[0083] In the present disclosure, for the purpose of explanation rather than limitation, specific details are set forth to provide a thorough understanding of the present disclosure. In some cases, the specific implementations of well-known devices, circuits, and methods are omitted to avoid obscuring the description of the present disclosure with unnecessary details.

[0084] Accordingly, system and method components are represented by conventional symbols in the figures where appropriate, and only specific details relevant to understanding the embodiments of the present disclosure are shown so as not to obscure the present invention with details that would be apparent to one of ordinary skill in the art having the benefit of this specification.

[0085] Any features or acts shown in dashed outline may be considered optional in some example embodiments. DETAILED DESCRIPTION

[0086] Figure 15 is a block diagram showing an electronic device (ED) 52 within a computing and communication environment 50, which can be used to implement the devices and methods disclosed herein. In some embodiments, ED 52 can be a communication network infrastructure unit, such as a base station (e.g., NodeB, evolved NodeB (eNodeB or eNB), next generation NodeB (sometimes referred to as gNodeB or gNB)), a home subscriber server (HSS), a gateway (GW) such as a packet gateway (PGW) or a serving gateway (SGW), or various other nodes or functions within a core network (CN) or a public land mobile network (PLMN). In other embodiments, ED 52 can be a device connected to the network infrastructure via a wireless interface, such as a mobile phone, a smart phone, or other devices that can be classified as user equipment (UE). In some embodiments, ED 52 may be a machine type communications (MTC) device (also known as a machine-to-machine (m2m) device), or another device that does not provide direct services to a user but can be classified as a user device. In some references, ED 52 may also be referred to as a mobile device, a term intended to refer to a device that is connected to a mobile network, regardless of whether the device itself is designed to be mobile or capable of being mobile. A particular device may utilize all of the components shown or only a subset of the components, and the degree of integration may vary from device to device. In addition, a device may include multiple instances of components, such as multiple processors, memories, transmitters, receivers, and the like. ED 52 typically includes a processor 54 such as a central processing unit (CPU), and may also include a dedicated processor such as a graphics processing unit (GPU) or other such processor, a memory 56, a network interface 58, and a bus 60 for connecting the components of ED 52. ED 52 may also optionally include components such as a mass storage device 62, a video adapter 64, and an input / output (I / O) interface 68 (shown in dashed outline).

[0087] Memory 56 may include any type of non-transitory system memory readable by processor 54, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic SDRAM (SDRAM), read-only memory (ROM), or a combination thereof. In an embodiment, memory 56 may include more than one type of memory, such as a ROM used at boot time, and a DRAM for storing programs and data used when executing programs. Bus 60 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.

[0088] ED52 may also include one or more network interfaces 58, which may include a wired network interface and / or a wireless network interface. Figure 1 As shown, the network interface 58 may include a wired network interface for connecting to a network 74, and may also include a wireless access network interface 72 for connecting to other devices via a wireless link. When the ED 52 is a network infrastructure unit, the wireless access network interface 72 may be omitted for nodes or functions that act as PLMN units (rather than nodes or functions of units located at the wireless edge (e.g., eNBs)). When the ED 52 is an infrastructure at the wireless edge of the network 74, a wired network interface and a wireless network interface may be included. When the ED 52 is a wirelessly connected device (e.g., a UE), the wireless access network interface 72 may be present, and the wireless access network interface 72 may be supplemented by other wireless interfaces such as a Wi-Fi network interface. The network interface 58 allows the ED 52 to communicate with remote entities such as those connected to the network 74.

[0089] The mass storage 62 may include any type of non-transitory storage device for storing data, programs, and other information, and for making the data, programs, and other information accessible via the bus 60. For example, the mass storage 62 may include one or more of a solid-state drive, a hard disk drive, a magnetic disk drive, or an optical disk drive. In some embodiments, the mass storage 62 may be remote from the ED 52, and a network interface such as the interface 58 may be used to access the mass storage 62. In the illustrated embodiment, the mass storage 62 is different from the memory 56 that includes it, and can generally perform storage tasks that are compatible with higher latency, but can generally produce less fluctuation or no fluctuation. In some embodiments, the mass storage 62 may be integrated with the heterogeneous memory 56.

[0090] An optional video adapter 64 and I / O interface 68 (shown in dashed outline) provide interfaces for coupling ED 52 to external input and output devices. Examples of input and output devices include a display 66 coupled to video adapter 64 and an I / O device 70 such as a touch screen coupled to I / O interface 68. Other devices may be coupled to ED 52, and additional or fewer interfaces may be used. For example, a serial interface (not shown) such as a universal serial bus (USB) may be used to provide an interface for external devices. Those skilled in the art will appreciate that in embodiments where ED 52 is part of a data center, I / O interface 68 and video adapter 64 may be virtualized and provided through network interface 58.

[0091] In some embodiments, ED 52 may be a stand-alone device, while in other embodiments, ED 52 may be located in a data center. As understood in the art, a data center is a collection of computing resources (usually in the form of services) that can be used as collective computing and storage resources. In a data center, multiple services can be connected together to provide a computing resource pool on which virtualized entities can be instantiated. Data centers can be connected to each other to form a network consisting of pooled computing and storage resources connected to each other by connection resources. Connection resources can take the form of physical connections such as Ethernet or optical communication links, and in some cases may also include wireless communication channels. If two different data centers are connected via multiple different communication channels, the links can be combined together using any of a variety of technologies, including the form of link aggregation groups (LAGs). It should be understood that any or all computing resources, storage resources, and connection resources (as well as other resources within the network 74) can be divided between different subnets, and in some cases, can be divided in the form of resource slices. If resources across multiple connected data centers or other node collections are sliced, different network slices can be created.

[0092] Figure 2 shows the use of 5G core network (5 thFigure 80 is a service-based architecture of a new generation core network (5GCN) or a next generation core network (NGCN / NCN). This figure depicts logical connections between nodes and functions, and the connections shown should not be interpreted as direct physical connections. ED 50 establishes a radio access network connection with a (radio) access network node ((radio) access network node, (R) AN) 84, and (R) AN 84 is connected to a user plane (UP) function (UP function, UPF) 86, such as a user plane gateway of a network interface (e.g., N3 interface). UPF 86 is connected to a data network (DN) 88 via a network interface (e.g., N6 interface). DN 88 can be a data network for providing operator services, or it can be a network (e.g., the Internet) for providing third-party services outside the scope of standardization of the third generation partnership project (3GPP), and in some embodiments, DN 88 can represent an edge computing network or resource, such as a mobile edge computing (MEC) network. ED 52 is also connected to access and mobility management function (AMF) 90. AMF 90 is responsible for authentication and authorization of access requests and for mobility management functions. AMF 90 can perform other roles and functions defined by 3GPP technical specification (TS) 23.501. In a service-based view, AMF 90 can communicate with other functions through a service-based interface represented as Namf. Session management function (SMF) 92 is a NF responsible for allocating and managing IP addresses assigned to UEs and for selecting UPF 86 (or a specific instance of UPF86) for services related to a specific session of ED 52. In a service-based view, SMF 92 can communicate with other functions through a service-based interface represented as Namf. Authentication server function (AUSF) 94 provides authentication services to other NFs through a service-based Nausf interface. A network exposure function (NEF) 96 may be deployed in the network to allow servers, functions, and other entities such as those outside the trust domain to access services and capabilities within the network.In one such example, NEF96 can be similar to an agent between an application server outside the network shown and NFs such as policy control function (PCF) 100, SMF 92, and AMF 90, so that an external application server can provide information that can be used to set parameters related to data sessions. NEF 96 can communicate with other NFs through a service-based Nnef network interface. NEF96 can also have an interface to non-3GPP functions. Network storage function (network repository function, NRF) 98 provides network service discovery functions. NRF98 can be specific to the PLMN or network operator associated with it. The service discovery function can allow NFs and UEs connected to the network to determine where and how to access existing NFs, and can present a service-based interface Nnrf. PCF 100 communicates with other NFs through a service-based Npcf interface, and can be used to provide policies and rules to other NFs including NFs within a control plane (CP) 108. The implementation and application of these policies and rules are not necessarily the responsibility of PCF 100, but are usually the responsibility of the function to which the PCF 100 sends the policy. In one such example, PCF 100 may send policies related to session management to SMF 92. This may be used to allow a unified policy framework that can be used to manage network behavior. A unified data management function (UDM) 102 may present a service-based Nudm interface for communicating with other NFs, and may provide data storage facilities to other NFs. Unified data storage may allow a unified view of network information that can be used to ensure that the most relevant information can be provided to different NFs from a single resource. This may make the implementation of other NFs easier because these NFs do not need to determine where a particular type of data is stored in the network. UDM 102 may be implemented as a unified data management function front end (UDM front end, UDM-FE) and a user data repository (userdata repository, UDR). Because PCF 100 may be involved in requesting and providing subscription policy information to UDR, PCF 100 may be associated with UDM 102, but it should be understood that PCF 100 and UDM 102 are typically independent functions. PCF 100 may have a direct interface to UDR. The UDM-FE receives requests for content stored in the UDR, or requests to store content in the UDR, and is generally responsible for functions such as credential handling, location management, and subscription management.UDM-FE may also support any or all of authentication credentials processing, user identity processing, access authorization, registration / mobility management, subscription management, and short message service (SMS) management. UDR is generally responsible for storing data provided by UDM-FE. The stored data is generally related to policy profile information (which may be provided by PCF100) that manages access rights to the stored data. In some embodiments, UDR may store policy data and user subscription data, which may include any or all of subscription identifiers, security credentials, access and mobility-related subscription data, and session-related data. Application function (AF) 104 represents the non-data plane (also known as non-user plane) function of applications deployed within the network operator domain and within a 3GPP-compatible network. AF 104 interacts with other core network functions through a service-based Naf interface, and can access network capability exposure information, as well as provide application information for decisions such as service routing. AF 104 may also interact with functions such as PCF 100 to provide application-specific inputs for policy and policy implementation decisions. It should be understood that in many cases, AF 104 does not provide network services to other NFs, but is often considered a consumer or user of services provided by other NFs. Applications outside the 3GPP network can use NEF 96 to perform many of the same functions as AF 104.

[0093] ED 52 communicates with NFs in UP 106 and CP 108. UPF 86 is part of CNUP 106 (DN 88 is outside 5GCN). (R)AN 84 can be considered as part of UP, but because (R)AN 84 is not part of CN, it is not considered as part of CN UP 106. AMF 90, SMF 92, AUSF 94, NEF 96, NRF 98, PCF 100, and UDM 102 are functions located within CN CP 108 and are generally referred to as control plane functions (CPF). AF 104 can communicate with other functions within CN CP 108 (directly or indirectly through NEF 96), but AF 104 is generally not considered as part of CN CP 108.

[0094] Those skilled in the art will appreciate that multiple UPFs 86 may be connected in series between the (R)AN 84 and the DN 88, and as will be described with respect to Figure 3 As discussed, multiple UPFs can be used in parallel to mediate multiple data sessions destined for different DNs.

[0095] Figure 3A reference point representation of the 5GCN architecture 82 is shown. For clarity, Figure 3 Omitted Figure 2 Some NFs are shown in the figure, but it should be understood that the omitted functions and those not in the figure are Figure 2 or Figure 3 The functions shown in can interact with the functions shown.

[0096] ED 52 is connected to (R)AN 84 in UP 106 and AMF 90 in CP 108. The ED-to-AMF connection is an N1 connection. (R)AN 84 is also connected to AMF 90 via N2. (R)AN 84 is connected to UPF 86 via N3. UPF 86 is associated with PDU sessions and is connected to SMF 92 via N4 interface to receive session control information. If ED 52 has multiple activated PDU sessions, these PDU sessions can be supported by multiple different UPFs 86, each of which is connected to SMF 92 via N4 interface. It should be understood that from the perspective of reference point representation, multiple instances of SMF 92 or UPF 86 are considered different entities. Each UPF 86 is connected to DN 88 outside 5GCN via N6 interface. SMF 92 is connected to PCF 100 via N7 interface, and PCF 100 is connected to AF 104 via N5 interface. The AMF 90 is connected to the UDM 102 through the N8 interface. If two UPFs 86 in the UP 106 are connected to each other, the two UPFs 86 can be connected through the N9 interface. The UDM 102 can be connected to the SMF 92 through the N10 interface. The AMF 90 and the SMF 92 are connected to each other through the N11 interface. The N12 interface connects the AUSF 94 to the AMF 90. The AUSF 94 can be connected to the UDM 102 through the N13 interface. In a network where multiple AMFs 90 exist, these AMFs 90 can be connected to each other through the N14 interface. The PCF 100 can be connected to the AMF 90 through the N15 interface. If there are multiple SMFs 92 in the network, these SMFs 92 can communicate with each other through the N16 interface.

[0097] It should also be understood that any or all of the functions and nodes discussed above with respect to the 5GCN architectures 80 and 82 may be virtualized within the network, and as will be discussed below, the network itself may be provided as a network slice of a larger resource pool.

[0098] Figure 41 is a diagram showing a proposed architecture 110 for implementing a next generation radio access network (NG-RAN) 112 (also referred to as 5G RAN). NG-RAN 112 is a radio access network that connects ED 52 to CN 114. Those skilled in the art will appreciate that CN 114 may be a 5GCN (e.g., Figure 2 and Figure 3 In other embodiments, CN 114 may be a 4G evolved packet core (EPC) network. The NG-RAN 112 node is connected to the 5GCN 114 via an NG interface. The NG interface may include Figure 2 and Figure 3 The N2 interface to CP108 and the N3 interface to UPF 86 are shown. The N3 interface can provide a connection to the CN UPF. The NG-RAN 112 includes multiple radio access nodes, which can be referred to as gNBs. In the NG-RAN 112, gNB 116A and gNB 116B are able to communicate with each other via an Xn interface. Within a single gNB 116A, the functionality of the gNB can be decomposed into a centralized unit (CU, gNB-CU) 118A and a group of distributed units (DU) (gNB-DU 120A-1 and gNB-DU 120A-2, collectively referred to as 120A). The gNB-CU 118A is connected to the gNB-DU 120A via an F1 interface. Similarly, the gNB 116B has a gNB-CU 118B connected to a group of distributed units (gNB-DU 120B-1 and gNB-DU 120B-2, collectively referred to as 120B). Each gNB DU may be responsible for providing radio coverage for one or more cells within a PLMN.

[0099] The division of responsibilities between the gNB-CU and gNB-DU is not fully defined at this time. Different functions, such as radio resource management functions, may be placed in one of the CU and DU. As with all functional placements, there may be advantages and disadvantages to placing specific NFs in one location or another. It should also be understood that any or all of the functions discussed above with respect to the NG-RAN 112 may be virtualized within the network, and as will be discussed below, the network itself may be provided as a network slice of a larger resource pool.

[0100] Figure 5An architecture 130 is shown that connects multiple connection resources, computing resources, and storage resources and supports network slicing. In the following, resources are connected to other discrete resources through connection resources 134, 138, 140, 144, and 148. It should be understood that because NFs are instantiated within resources, these NFs can be connected to each other through virtual connections. In some embodiments, these NFs do not rely on the physical connection resources shown, but can be connected to each other through virtual connections, which are also considered as connection resources. Resource 1132 is connected to resource 2 136 through connection resource 134. Resource 2 136 is connected to a resource not shown through connection resource 138, and is also connected to resource 3 142 through connection resource 140, and resource 1132 is connected to resource 4 146 through connection resource 148. Resource 1132, resource 2 136, resource 3 142, and resource 4 146 should be understood as representing both computing resources and storage resources, but may also include dedicated functions. In some embodiments, a dedicated NF may be represented by any or all of resource 1 132, resource 2 136, resource 3 142, and resource 4 146, in which case it may be the capability or capacity of the NF that is being sliced. For the following discussion, connection resources 134, 138, 140, 144, and 148 may be viewed as logical links between two points (e.g., between two data centers) and may be based on a set of physical connections.

[0101] Resources 1132 are divided to allocate resources to slice A 132A and slice B 132B. A portion 132U of the available resources of resource 1132 remains unallocated. Those skilled in the art will appreciate that when network resources are allocated to different slices, the allocated resources are isolated from each other. This isolation of computing resources and storage resources ensures that processes in one slice do not interact or interfere with processes and functions of other slices. This isolation can also be extended to connection resources. Connection resources 134 are divided to provide connections 134A to slice A and 134B to slice B, and some unallocated bandwidth 134U is also reserved. It should be understood that the amount of resources (e.g., allocated bandwidth, memory, or number of processor cycles) can be changed or adjusted, whether in any resource with unallocated resources or in a resource that has been divided to support multiple resources, to allow the capacity of each slice to be changed. In some embodiments, the slice can support "breathing", which allows the resources allocated to the slice to increase or decrease together with any available resources, required resources, expected resource requirements, or other such factors, either individually or in combination with each other. In some embodiments, resources may be allocated in the form of soft slices, where a fixed allocation is not guaranteed and the amount of resources provided may be flexible. In some embodiments, a soft allocation may allocate a percentage of resources to be provided over a given time window, such as allocating 50% of the connection bandwidth over a time window. This may be accompanied by a minimum guaranteed allocation. A guarantee of always receiving 50% of the capacity of a connection resource may provide very different service characteristics than receiving 50% of the capacity of a connection resource within a 10 second window.

[0102] Resource 2 136 is divided to support the allocation of available computing resources and storage resources to slice A 136A, slice C 136C, and slice B 136B. Because no resources in connection resources 134 are allocated to slice C, in some embodiments, resource 2 136 may not provide a network interface for interacting with connection resources 134 to slice C 136C. Resource 2 136 may provide an interface to connection resources 138 to different slices based on the slices supported by connection resources 138. Connection resources 140 are allocated to slice A 140A and slice C 140C, leaving some unallocated capacity 140U. Connection resources 140 connect resource 2 136 to resource 3 142.

[0103] Resource 3 142 provides computing resources and storage resources specifically allocated to slice C 142C, and is also connected to connection resources 144, which includes connection resources 144A allocated to slice A in addition to unallocated portion 144U. It should be noted that resource 3 142 may not be visible from the perspective of a function or process within slice A. Connection resource 144 provides a connection between resource 3 142 and resource 4 146, wherein the resources of resource 4 146 are all allocated to slice A 146A.

[0104] Resource 4 146 is connected to resource 1 132 via connection resource 148, and connection resource 148 allocates a portion of connection 148 to slice A, while the remaining resource 148U is unallocated.

[0105] Figure 6 Shown is the view from slice A Figure 5 150. This can be understood as a view of the resources allocated to slice A 150 across the network segments shown. From within slice A 150, only the portion of the resources that have been allocated to slice A 150 is visible. Therefore, only the power and capacity of the portion 132A allocated to slice A is available, and the full capacity and capacity of resource 1132 is not visible. Similarly, only the power and capacity of the portion 136A allocated to slice A is available, and the capacity and capacity of resource 2 136 is not visible. Because none of the resources in resource 3 142 are allocated to slice A 150, resource 3 142 is not within the topology of slice A 150. All the capacity and capacity of resource 4 146 are allocated to slice A 146, so resource 4 146 is within the topology of slice 150. Slice A 132A of resource 1 132 is connected to slice A 136A of resource 2 136 via logical link 152. Logical link 152 may correspond to the portion of connection resource 134 allocated to slice A 134A. Slice A 136A is connected to logical link 154 (representing the portion of connection resource 138 allocated to slice A 150) and is connected to slice A 146A via logical link 156. Logical link 156 represents the portion of connection resource 140 and the portion of connection resource 144 that has been allocated to slice A (portion 140A and portion 144A, respectively). It should be understood that since there is no resource 3 142 in slice A 150, any traffic sent by slice A 136A on connection resource 140A will be transmitted to resource 4 146, and similarly, any traffic sent from slice 146A in connection resource 144A will be transmitted to slice A 136A. Thus, within slice A 150, connection resources 140A and 144A may be modeled as a single logical link 156. Logical link 158 represents the portion of connection resource 148 allocated to slice A 148A.

[0106] It should be understood that Figure 5 and Figure 6 Within the storage resources and computing resources shown, NFs can be instantiated using any of a variety of known technologies, including network function virtualization (NFV), to create virtual network functions (VNFs). Although traditional telecommunication networks, including so-called third and fourth generation (3G / 4G) networks, can be implemented using virtualized functions in their CNs, it is expected that next-generation networks, including so-called fifth generation (5G) networks, use NFV and other related technologies as basic building blocks for new CN and RAN designs. By using NFV and technologies such as software defined networking (SDN), functions in the CN can be instantiated at locations in the network determined based on network requirements. It should be understood that if network slices are created, resource allocation at different data centers allows the instantiation of functions at or near a specific geographic location or even within a slice where resources have been abstracted. This allows the virtualized function to be "close" to the location where it is used in a physical sense. This can be useful, and the logical location of the instantiated function can be selected in conjunction with topological proximity so that the function is geographically or topologically close to the selected physical or network location.

[0107] Figure 7 A system 160 is shown in which a core / RAN network 162 provides wireless access services and CN services to EDs 52 such as UE1 164 and UE2 166. Figure 7In the diagram, NFs are instantiated on the underlying resources of the data center. These functions are shown as being decomposed from the resource pool from which they are instantiated. This is to show that these functions act as independent entities and that from a logical perspective, these functions are no different from physical nodes that perform the same functions. It should also be understood that in a network where the data center provides slices of the underlying resources for creating slices, a single network can have slices that support different network versions, so that, for example, in addition to having a virtualized network that supports 5G services, separate network slices can be created to support 4G networks. Services from ED 52 can be routed through NF to GW168, which provides access to a packet data network 170 such as the Internet. Wireless access services are typically provided by a RAN, which in this illustration is provided as a cloud radio access network (cloud-RAN, C-RAN). Where the traditional RAN architecture is designed to consist of discrete units (e.g., eNBs) connected to the CN via a backhaul network, C-RAN virtualizes the access node (AN) of the network using functional virtualization. Just as a physical AN such as an eNB is connected to an antenna via a fronthaul link, in the illustrated embodiment of the cloud radio access network, access nodes such as gNBs are connected to antennas (or remote radio heads (RRHs)) via fronthaul connections, but these access nodes are functions instantiated on computer resources in the network 162. If the gNB is divided into a CU and multiple DUs, in some embodiments, the virtualized DUs can be instantiated at or near the antennas or RRHs, and the CUs can be instantiated in a data center to connect and serve multiple geographically dispersed DUs. For example, UE1 164 is connected to the network via AN172, which can provide wireless access services via antenna 174. AN172 is instantiated on computing resources and storage resources provided by a data center (in this case, data center 198-1). Similarly, AN176 and AN180, which are connected to the same antenna set 178, are also instantiated on resources in the data center 198-1. AN180 provides wireless access services to UE2166, which also uses the access services provided by AN182. AN182 is connected to antenna 184 and is instantiated on resources of data center 198-2. AN186 is connected to antenna 188 and is instantiated on resources of data center 198-2. It should be understood that the fronthaul connections linking the virtualized AN to the antenna or RRH can be direct connections, or these fronthaul connections can form a fronthaul network. Integrating C-RAN into the core network can eliminate or reduce problems associated with backhaul connections because AN functions can be co-located with CN functions. In this way, data center 198-1 also serves as a location for instantiating a user-specific GW function (u-GW) 190. This function is also instantiated in data center 198-2.Instantiating a function in more than one data center can be part of a function migration process in which the function is moved through the network, or one of the instantiations can be an intentionally redundant instantiation. Two functions can be instantiated and configured, where only one function is active at a time, or the functions can both be active, but only one of them can send data to the UE. In other embodiments such as those focused on ultra-reliable connections, such as ultra-reliable low latency communications (URLLC), both functions can be active and can both send data to or receive data from an ED (e.g., UE 2166). NFs such as HSS 192, AMF 194 or its predecessor mobility management entity (MME), and NEF 196 are shown as being instantiated on resources in data centers 198-5, 198-4, and 198-3, respectively.

[0108] Virtualization of NFs allows functions to be located in the network (topologically) close to the demand for the services provided by the function. Thus, the AN 172 associated with the antenna 174 can be instantiated on data center resources in the data center closest to the antenna 174 (data center 198-1 in this example). Functions such as NEF 196 that may not need to be close to the access node can be instantiated at a distance (in a topological and / or physical sense). Thus, NEF 196 is instantiated in data center 198-3, HSS 192 and AMF 194 are instantiated in data center 198-5 and data center 198-4, respectively, both of which are topologically close to the wireless edge of the network 162. In some network embodiments, data centers can be arranged in layers, and different functions can be placed at different layers of the layer.

[0109] Figure 8 2 is a block diagram schematically illustrating a representative server 200 architecture that can be used in embodiments of the present disclosure. It is contemplated that the server 200 can be physically implemented as one or more computers, storage devices, and routers interconnected together (any or all of which can be described in detail in accordance with the above references). Figure 1 The system 50 described herein is constructed to form a local network or cluster and executes appropriate software to perform its intended functions. Those of ordinary skill in the art will recognize that there are many suitable combinations of hardware and software that can be used in the present disclosure, which combinations may be known in the art or may be developed in the future. Therefore, figures showing physical server hardware are not included in this specification. Instead, Figure 8The block diagram shows a representative functional architecture of server 200, and it should be understood that any suitable combination of hardware and software can be used to implement the functional architecture. It will also be understood that server 200 itself can be a virtualized entity. Because from the perspective of another node, the virtualized entity has the same characteristics as the physical entity, both the virtualized computing platform and the physical computing platform can be used as the underlying resource for instantiating the virtualized function.

[0110] like Figure 8 As can be seen in the figure, the server 200 shown generally includes a hosting infrastructure 202 and an application platform 204. The hosting infrastructure 202 includes the physical hardware resources 206 of the server 200 (e.g., information processing resources, business forwarding resources, and data storage resources), and a virtualization layer 208, which presents an abstraction of the hardware resources 206 to the application platform 204. The specific details of the abstraction will depend on the requirements of the application hosted by the application layer (as described below). Thus, for example, an abstraction of the hardware resources 206 that simplifies the implementation of the business forwarding strategy in one or more routers can be presented to an application that provides business forwarding functionality. Similarly, an abstraction of the hardware resources 206 that can facilitate data storage and retrieval (e.g., using a lightweight directory access protocol (LDAP)) can be presented to an application that provides data storage functionality.

[0111] The application platform 204 provides the ability to host 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 the applications 214 by providing infrastructure as a service (Iaas) facilities. During operation, the virtualization manager 210 can provide security and resource "sandboxes" for each application 214 hosted by the platform 204. Each "sandbox" can be implemented as a virtual machine (VM) image 216, which can include a suitable operating system and controlled access to the (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, which will be described in more detail below.

[0112] Applications 214 from suppliers, service providers, and third parties can be deployed and executed by corresponding VMs 216. For example, management and orchestration (MANO) functions, and service oriented network auto-creation (SONAC) functions (or any of the following that can be incorporated into the SONAC controller in some embodiments: software-defined network (SDN) controller, software-defined topology (SDT) controller, software-defined protocol (SDP) controller, and software-defined resource allocation (SDRA) controller) can be implemented by one or more applications 214 hosted on the application platform 204 as described above. The communication between applications 214 and services in the server 200 can be conveniently designed according to the service-oriented architecture (SOA) principles known in the art.

[0113] The communication service 218 may allow applications 214 hosted on a single server 200 to communicate with the application platform service 212 (eg, via a predefined application programming interface (API)) and allow these applications 214 to communicate with each other (eg, via a service-specific API).

[0114] The service registry 220 can provide visibility of the services available on the server 200. In addition, the service registry 220 can provide service availability (e.g., service status) and related interfaces and versions. Applications 214 can use this information to discover and locate the endpoints of the services they need, and publish their own service endpoints for use by other applications 214.

[0115] Mobile edge computing allows cloud application services to be hosted with virtualized mobile network elements in a data center that is used to support the processing requirements of the C-RAN. A network information service (NIS) 222 can provide low-level network information to applications 214. For example, applications 214 can use the information provided by NIS 222 to calculate and present high-level and meaningful data, such as cell ID, subscriber location, cell load, and throughput guidance.

[0116] Traffic off-load function (TOF) service 224 can prioritize traffic and route selected policy-based user data flows to and from application 214. TOF service 224 can be provided to application 214 in various ways, including: forwarding mode, in which (uplink and / or downlink) traffic is delivered to application 214, which can monitor, modify, or shape the traffic and then send it back to the original packet data network (PDN) connection (e.g., 3GPP bearer); and endpoint mode, in which the traffic is terminated by application 214 acting as a server.

[0117] Virtualization of NFs is considered as a foundational technology for flexible 5G network architecture. Function virtualization is a technology that allows the creation of virtual functions based on computing resources, memory resources (which may include executable memory and general memory), and connection resources or network resources. In many cases, these resources will exist within a data center. It should be understood that because virtualized resources can be used as underlying resources for the next level of virtualization, this discussion involves resources rather than actual hardware.

[0118] Virtualization can take the form of instantiating a virtual machine (VM) 216, which is no different from a physical node in the network for another entity on the network and the software executed on the VM 216. VM 216 has its own set of computing resources, storage resources, and network resources, on which an operating system can be executed. VM 216 can have a virtual network interface, and a network address can be assigned to the virtual network interface. Between the underlying resources and VM 216, there is usually a management program that manages resource isolation and network interaction. One of the purposes of VM 216 is to provide isolation from other processes running on the system. When initially developed, VM 216 was a mechanism that allowed different network processors to operate without worrying that a single erroneous process would cause the system to completely crash. Instead, the erroneous process would be contained in its own VM 216. This isolation allows each VM 216 to have its own set of network interfaces. Typically, a single underlying resource can support multiple virtualized entities.

[0119] A recent development is to use containers instead of VMs 216. Each VM 216 typically includes its own operating system (OS), which typically increases redundant resource usage. Containers allow a single OS kernel to support multiple isolated virtual functions. Instead of a hypervisor allowing each VM 216 to run its own OS, a single OS hosts containers, which are responsible for performing resource isolation (originally provided by VMs 216). A virtualized network interface can be provided for each virtualized function within a container so that each virtualized function behaves as its own network entity.

[0120] When virtualization is used in a network environment, the question of how to manage or orchestrate the instantiation, modification, and removal of virtualized functions arises. To address this issue, the European Telecommunications Standards Institute (ETSI) has developed a set of network function virtualization (NFV) management and orchestration (MANO) standards. Fig. 9 As shown, the NFV-MANO system allows management of NFV instantiation and modification. As shown, there may be interfaces to existing systems such as operation support system (OSS) / business support subsystem (BSS) 250. In the network architecture 230, the NFV-MANO system 232 includes an orchestrator 234, which can access libraries 236 such as network service catalog 238, VNF catalog 240, VNF instance repository 242, and NFVI resource repository 244. The NS catalog 238 may include templates that can be used as a basis for supporting network services. The VNF catalog 240 may include templates for instantiating VNFs of different levels. A specific VNF after instantiation may be referred to as a VNF instance, and its attributes may be stored in the VNF instance repository 242. NFVI resources 244 may be used to track the availability of resources (including virtual resources and the physical infrastructure for instantiating virtual resources). NFVI 244 may be connected to multiple VNF managers 246 through an OR-VNFM interface and to a virtualized infrastructure manager (VIM) 248 through an OR-VI interface. VNFM 246 and VIM 248 may be connected to each other through a VI-VNFM interface.

[0121] NFV MANO 232 can communicate with OSS / BSS system 250 through OS-MA interface, and communicate with service, VNF & infrastructure description database 252 through SE-MA interface. Service, VNF & infrastructure description database 252 can contain operator information related to services, VNFs, and infrastructure deployed in the network. Service, VNF & infrastructure description database 252 and OSS / BSS 250 can be connected to each other so that OSS / BSS 250 can update and maintain service, VNF & infrastructure description database 252 as needed.

[0122] NFVI 270 interacts with VIM 28 through the NF-VI interface. The underlying resources can generally be classified into computing resources 274, memory resources 278, and network resources 282. Memory resources 278 can also be referred to as storage resources, and network resources 282 can also be referred to as connection resources. The virtualization layer 272 allows the abstraction of the underlying resources to which it is connected through the VI-HA interface. It should be understood that the underlying resources can be physical resources or virtual resources. The virtualization layer 272 allows the abstraction of the underlying resources into virtual computing resources 276, virtual memory resources 280, and virtual network resources 284. These virtualized resources can be provided to the network element management system 254 through the VN-NF interface, so that these virtualized resources can be used as resources that can instantiate VNFs (shown as VNF1 258, VNF2 262, and VNF3 266). The element manager (EM) 254 can be connected to the VNFM 246 within the NFV MANO 232 through the interface VE-VNFM, and connected to the OSS / BSS 250 through another interface. Each VNF instantiated on the virtual resources provided by the NFVI 270 can be associated with an EM (EM1 256, EM2 260, and EM3 264). The use of EM allows the OSS / BSS 250 to have two paths through which the VNF can be managed. The VNF can be managed by the VNFM 246 or by the EM associated with the VNF. Each EM can provide the same management control as provided to the physical network element. Therefore, the OSS / BSS 250 can treat each VNF as a traditional NF. The EM can request a modification of the resource allocation related to the VNF through the VNFM 246, or through a request from the OSS / BSS 250 via the OS-MA interface.

[0123] Virtualization of NFs allows functions to be deployed using the resources required rather than using intentional over-provisioning. Used in conjunction with the above-described slicing and data centers, a flexible network can be deployed in a manner that allows operators to dynamically modify the connections between functions (thereby changing the network logical topology) and dynamically modify the resources and location of NFs (thereby changing the physical topology of the underlying network). Additional resources can be allocated to existing functions to allow vertical expansion of existing functions, and resources can be removed from allocations to allow vertical reduction of functions. Resources from multiple resource pools or data centers can be allocated to a function in order to scale the function horizontally, and resources from different pools can be removed to allow horizontal reduction of the function. The function can be moved by transferring its state information to another NF, and in some cases, the function can be moved by a combination of horizontal expansion and horizontal reduction of functions.

[0124] In this disclosure, the term "provisioning" is understood to include a combination of the preparation phase and the service phase. It is also understood that provisioning can be defined as "allocation" or "dispensing".

[0125] Fig.10 A network architecture 300 is shown in which the resources of an operator network 302 are divided into a set of logical planes: UP 304, CP 360, and management plane (MP) 308. UP 304 is typically focused on packet transport, but certain functions (including packet filtering and traffic shaping) may be performed in UP 304, although this is typically performed based on instructions from NFs in CP 306. Functions in MP 308 receive input from NFs in customer domain 310 regarding policies that should be executed by network control functions in CP 306. If the operator network 302 supports network slicing, functions within MP 308 may be responsible for slice design and creation. It should be understood that a single MP 308 may be used to provide management functions for multiple network slices, each with different control planes and user planes. Functions within MP 308 may communicate with each other to ensure that different policies for possible multiple customers are combined together in an appropriate set of instructions.

[0126] UP 304 may also be referred to as a data plane (DP). UP 304 carries traffic between ED 52 and an external data network (not shown) or functions within operator network 302. UP 304 is typically comprised of UPF 314. In some instances, UPF 314 may be dedicated to a specific UE, UPF 314 may be dedicated to a specific service (in some embodiments, it may be both user-specific and service-specific), and in other cases, UPF 314 may be a general function serving multiple users and services. UPFs 314 are connected to each other to allow DP traffic to be sent.

[0127] CP 306 may be composed of CP functions (CP functions, CPFs) 316. In a 3GPP-compatible network, some CPFs 316A are defined by the standard, while other CPFs 316B may be outside the specifications of the relevant standards. This may effectively divide CP 306 into a standard-compatible CP segment 306A and a non-standard-compatible CP segment 306B. In the 3GPP-compatible CP segment 306A, there may be NFs 316A such as AMF, SMF, NEF, AUSF, etc., and in some embodiments, there may be multiple instances of any or all functions. In the non-standard-compatible CP segment 308B, NFs 316B such as SDN controllers or other such controllers (including SONAC-OPS controllers) may be connected to other CPFs as shown in function 316A, but such a connection is not required as shown in CPF 316B. ED 52 may also communicate with the CPF.

[0128] MP 308 can be divided between a standard-compliant part 308A and a non-standard-compliant part 308B, just as CP306 is divided. Within MP 308, NFs and nodes 318 can communicate with each other and can communicate with NFs or nodes 312 within the customer domain 310. MP entity 318A (within the standardized part 308A) and MP entity 318B (within the non-standard-compliant part 308B) can be used to establish policies and mechanisms for implementing policies based on available resources and requirements received from customers 312 (and possibly from multiple different customers). The network management function (NMF) 318 can be responsible for accounting and billing functions (for network element management), and NMF 318 can provide services required by OSS and BSS. In addition to standardized functions, non-standardized NF318B can include NFV-MANO system and SONAC-Com controller.

[0129] NMF 318 may receive external input from customer node 312, and NMF 318 may communicate with each other. NMF 318 may also communicate with CPF 316 via any MP-CP connection 320 to provide instructions related to the policies executed by CPF 316. Changes in the underlying resources of network 302 are also communicated to CPF 316 by NMF 318. In CP 306, CPFs communicate with each other and with ED52. CPF 316 also communicates with UPF 314, and through the communication, CPF 316 may receive information such as the traffic load on the link and the processing load at the NF. In conjunction with the policy information received from NMF 318, CPF 316 may send instructions to UPF 314 via CP-UP (also referred to as UP-CP) connection 322 to manage the behavior of UPF 314. UPF 314 receives configuration information from CPF 318 and processes UP services according to the received configuration information. Load information, which may include processing load and network connection (or link) load, may be collected by UPF 314 and provided to CPF 316 .

[0130] In some embodiments, the customer NF 312 may have a connection to a CPF 316. The CPF 316 that communicates with the customer NF 312 may be a 3GPP-compatible CPF 316A or a non-3GPP-compatible CPF 316B. In an alternative embodiment, the customer NF 312 may utilize a function within the MP 308 to relay messages to a function in the CP 306. Within the customer domain 310, there may be an optional control plane 324 with customer CPFs 326 and 328. When such a customer control plane 324 is present, the functions 326 and 328 may have a logical communication link with the ED 52 and / or the customer NF 312. The customer CPFs 326 and 328 may have a connection to a function within the CP 306 (either a 3GPP-compatible function 316A or a non-3GPP-compatible function 316B).

[0131] Provisioning and operating network slice instances

[0132] This disclosure describes NS(S)I provisioning at a general (high) level and at an example detailed level. In some examples, such detailed process may describe the steps taken at each life cycle stage of the NS(S)I, and the relationship between the NS(S)I and any one or more of the following: the communication service instance life cycle, specific interface descriptions, related management entities and their respective tasks. The above process may vary based on data and / or management openness, service type, and / or any other relevant details.

[0133] 3GPP believes that the process of provisioning NS(S)I may involve certain management entities in the network. These management entities include the communication service management function (CSMF) that converts customer service requirements or demands (requirements) into network slice requirements, the network slice management function (NSMF) that divides network slice requirements into separate sub-slice requirements, and the network slice subnet management function (NSSMF) that manages subnet slices and uses MANO and / or one or more domain managers (DM) / element managers (EM) to create subnets using VNFs and physical NFs (PNFs).

[0134] In some examples, one or more functions described in this document as provided by the CSMF may be provided as discrete functions or atomic functions. These functions include, but are not limited to: performing feasibility checks on communication services and preparing network slicing requirements; opening communication service related data, management functions (MF) and / or capabilities with the consent of the network operator; lifecycle management (LCM), fault management (FM), performance management (PM), and / or configuration management (CM) of one or more communication services.

[0135] In some examples, one or more functions described herein as provided by the NSMF may be provided as atomic functions. These functions include, but are not limited to: network resource discovery; performing feasibility checks on network slices; determining network slice subnet-related requirements; opening network slice capabilities with the consent of the network operator; opening network slice management functions and / or data with the consent of the network operator; self-optimization, self-configuration, and / or self-repair of one or more network slices; and / or LCM, FM, PM, and / or CM of one or more network slices.

[0136] In some examples, one or more functions described herein as provided by the NSSMF may be provided as atomic functions. These functions include, but are not limited to: network resource discovery; performing feasibility checks on network slice subnets; managing network slice subnet-related policies; opening network slice subnet capabilities with the consent of the network operator; opening network slice subnet management functions and / or data with the consent of the network operator; self-optimization, self-configuration, and / or self-repair of one or more network slice subnets; LCM, FM, PM, and / or CM of one or more network slice subnets.

[0137] In some examples, one or more 5G NF management functions may be provided as atomic functions. These functions include, but are not limited to, tracking management, minimization of driver test (MDT), self-organizing network (SON) (which may include one or more of the following: self-configuration, self-repair, automatic neighbor relation (ANR)), maintenance, reliability and operation (MRO), enrolment system (ES), and / or single wire multiswitch (SWM), entry point management (EPM), FM, PM, and / or CM of one or more 5G NFs.

[0138] In addition, the provisioning of NS(S)I may involve network management entities such as service manager (SM), slice operation manager (SOM), and infrastructure management function (InMF): SM is related to all types of services and is used to negotiate with customers, license services, establish service level agreements (SLAs), and prepare internal service requirements for CSMF processing; SOM manages and optimizes slices during operation when the slices are instantiated on the PoP; InMF manages the infrastructure and allocates the infrastructure to different slice subnets.

[0139] In the context of 5G network management, various management entities may manage one or more of the following: 5G services, 5G slice instances, 5G NFs, and / or other resources (including but not limited to virtual resources and / or non-virtual resources supporting the 5G network).

[0140] The disclosed provisioning process contemplates a number of scenarios including various combinations of one or more of the following:

[0141] - Openness (none, data openness, management openness, and / or openness between network entities);

[0142] - Service type (Infrastructure as a Service (IaaS), Network Slice as a Service (NSaaS), Network Slice Subnet as a Service (NSSaaS), and / or Communications as a Service (CaaS));

[0143] - Slice deliverable type (Type 1 (fully configured and managed slice, not open), Type 2 (fully configured and managed slice, providing specific services via some data openness and management openness), Type 3 (configured and managed slice, which can be used to provide specific services via some data openness and management openness), and / or Type 4 (open management interface and provide resources to configure slices));

[0144] -Effective lifecycle actions (design, onboarding, network environment preparation, and / or creation); and

[0145] - Shareable slices and / or non-shareable slices.

[0146] The various procedures for provisioning NSSI are described first, followed by the various procedures for provisioning NSI.

[0147] Provisioning network slice subnets

[0148] Fig.12 is a signal flow diagram illustrating an example signal flow for provisioning NSSI in the general process shown generally at 1200. Fig.11 It will be understood that in the present disclosure, the term “supply” refers to the preparation phase 1110 and the service entry phase 1130 .

[0149] The figure shows the communication between NSMF 1201, NSSMF 1202, NFV MANO 232, DM / EM 1203, and other management systems 1204 including but not limited to transport network (TN) and / or Wi-Fi system, which may include 3GPP and / or non-3GPP management entities. Those skilled in the relevant art will understand that NFV MANO 232, DM / EM 1203, and other management systems 1204 are management entities that are components (collectively referred to as 1205) of NSSMF 1202, and NSSMF 1201 can communicate with these management entities.

[0150] Assume that the network slice subnet template (NSST) has been loaded.

[0151] In the present disclosure, dotted lines or dotted boxes indicate optional processes and / or actions.

[0152] The general process 1200 includes the NSSMF 1202 going through various stages, which may include discovering resources and / or abstractions of resources in the form of capabilities 1210, deriving requirements 1220, checking feasibility 1230, preparing the network environment 1240, and serving the NSSI 1250. In some examples, the NSMF 1201 requests the removal of the served NSSI, and then enters the removal stage 1260. For descriptive purposes only, these stages are represented in the figure by horizontal dashed lines. Although they may be different from Fig.11 The elements are similar to those of Fig.11 There is not necessarily a relationship between similarly named elements.

[0153] refer to Fig.11 , the discovery phase 1210, the requirements phase 1220, and the feasibility phase 1230 collectively correspond to the design 1111 of the NSSI, and the preparation phase 1240 corresponds to the network environment preparation 1112. The service phase 1250 corresponds to at least the service phase 1130, and may include the loading 1113 during the preparation phase 1110. In some examples, the loading 1113 may be understood to occur during the preparation phase 1240.

[0154] In the discovery phase 1210, the NSSMF 1202 obtains information 1211, 1212, 1213 from its component management entity 1205. Resource discovery can be used to derive network capabilities, abstractions, and prepare a service catalog. Such a catalog may include, but is not limited to, available subnet slice types, network slice subnet templates (NSSTs), and / or existing NSSIs. In some examples, the catalog may include capability information, including, but not limited to, the remaining capacity in the network in terms of network resources and / or services that can be provided. In some examples, resource discovery may include a review of an initially prepared service catalog before or during the feasibility phase 1230.

[0155] Capability discovery may be obtained from component management entity 1205. The timing and / or frequency of capability discovery may depend on management openness policy. In this regard, the openness of component management entity 1205 may depend on whether NSSMF 1202 is in a trusted state. At certain trust levels and by mutual agreement, only a limited subset of capabilities are disclosed. In some examples, the amount of information available from component management entity 1205 may exceed the amount of information that NSSMF 1202 is seeking. In such examples, NSSMF 1202 may conduct specific queries to limit the disclosure of information.

[0156] In some examples, as a non-limiting example, in the context of a discovery phase of provisioning an NSI ( Fig.21 ), NSSMF 1202 may receive a request 1214 from NSMF 1201 to provide capability information to NSMF 1201. NSSMF 1202 provides information according to its open policy. In some examples, if NSSMF 1202 maintains a service catalog (including but not limited to an NSST repository), NSSMF 1202 may provide access to such a catalog in response to request 1214. Information obtained by NSSMF 1202 from its component management entity 1205 may be provided to NSMF 1201 or other 3GPP management entity. NSMF 1201 may use this information to derive the network slice subnet requirements of the network slice subnet customer, which may be communicated in request 1223.

[0157] In the requirements phase 1220, the NSMF 1201 derives 1221 NSSI requirements. These requirements may include one or more NSSTs, network slice subnet characteristics, network topology, specific resource requirements, latency, bandwidth, NF-related requirements (such as but not limited to layout), NF-related capabilities, and / or network knowledge performance indicators (KPIs) (such as but not limited to network outages and / or specific link requirements). Such requirements may be derived by the NSMF 1201 through its resource discovery process (including but not limited to signal flow 1214) and / or inspection of the service catalog. In some examples, the resource discovery process does not provide sufficient information, and the NSMF 1201 may make 1222 one or more target capability queries to the NSSMF 1202.

[0158] In some examples, the above requirements may be prepared and provided (not shown) to NSMF 1201 by another executor (including but not limited to a client).

[0159] Regardless of how the requirements are obtained, NSMF 1201 communicates 1223 a request with those requirements to NSSMF 1202. Finally, NSSMF 1202 communicates 1224 a response to request 1223 to NSMF 1201, as described below.

[0160] In feasibility phase 1230, NSSMF 1202 performs a feasibility check to obtain an initial indication of whether the request is feasible. In this way, NSSMF 1202 may evaluate 1231 the possibility of reusing an existing NSSI (modified or unmodified). Such evaluation may take into account the remaining capacity of the existing NSSI and / or NSST and the network subnet.

[0161] If deemed not possible, the NSSMF 1202 may evaluate 1232 the possibility of creating a new NSSI to support the request.

[0162] During this evaluation process, NSSMF 1202 may determine that more information is needed and may make queries 1233, 1234, 1235 to its component management entity 1205 to obtain additional capability information. Such queries may be based on requirements obtained from NSMF 1201, or may include a general capability information request for further discovery of resources. In some examples, the nature of the query and the response obtained may depend on the openness level of the component management entity 1205.

[0163] NSSMF 1202 then makes a formal determination of feasibility 1236. If request 1223 is feasible, NSSMF 1202 enters the network environment preparation 1240 phase, accepts request 1223 from NSMF 1201, and prepares a reply 1224 to the request. In some examples, certain information disclosure is allowed between NSSMF 1202 and NSMF 1201, and reply 1224 may disclose information related to component management entity 1205 of NSSMF 1202, including but not limited to the remaining capacity, NSST, and / or NSST attributes of component management entity 1205.

[0164] If request 1223 is not feasible, NSSMF 1202 rejects request 1223 from NSMF 1201 and prepares a reply 1224 to the request. In some examples, certain information disclosure is allowed between NSSMF 1202 and NSMF 1201, and reply 1224 may disclose information related to component management entity 1205 of NSSMF 1202, including but not limited to the remaining network capacity of component management entity 1205. Such information may allow NSMF 1201 to update and resend its request 1223.

[0165] In some examples (not shown, but in combination Fig.15 NSMF 1201 and NSSMF 1202 may negotiate other feasible provisioning options. If unsuccessful, the deletion phase 1260 is entered.

[0166] In the preparation phase 1240, the NSSMF 1202 performs preparations, which may include but are not limited to sending reservation requests 1241, 1242, 1243 to the component management entity 1205 to reserve resources for establishing NF connections (in the case of NFV MANO 232 and / or DM / EM 1203) or TN connections (in the case of other management systems 1204).

[0167] In some examples, as a non-limiting example, in the context of a network environment preparation phase for provisioning an NSI ( Fig.21 ), NSSMF 1202 may receive a request 1244 to reserve resources for use by NSMF 1201. In response to such request 1244, NSSMF 1202 makes preparations, which may include but are not limited to reserving resources by sending 1241, 1242, 1243 reservation requests to component management entity 1205.

[0168] In the in-service phase 1250, the NSSMF 1202 loads 1251 the appropriate NSSI descriptor of the selection as identified in action 1231 and / or action 1232. The loading process 1251 may include messages 1252, 1253, 1254, 1205 to its component management entities to prepare to configure its NFs and / or TNs. When the NSSI descriptor has been loaded 1251, the NSSMF 1202 creates (and / or modifies) the NSSI process to create 1255 the NSSI.

[0169] In some examples, as a non-limiting example, during the process of creating an NSI ( Fig.21 ), NSSMF 1202 may receive a request 1251 to finalize a reservation for use by NSMF 1201. In response to such request 1251, NSSMF 1202 loads NSSI descriptor 1251, performs preparations 1252, 1253, 1254, and creates NSSI 1255.

[0170] Once the NSSI has been created or modified 1255, NSSMF 1202 sends 1257 a successful loading response to NSMF 1201. In some examples, response 1257 may include information related to the NSSI, including but not limited to an ID of the NSSI, service access point information, and / or external connection point information.

[0171] In some examples (not shown), NSMF 1201 may respond to answer 1257 with a reply that provides information associating the NSSI with the corresponding NSI, which NSSMF 1202 may use to differentiate between services.

[0172] In some examples, if the feasibility check fails, a deletion phase 1260 is entered. In some examples, the deletion phase 1260 is initiated by a request 1261 from NSMF 1201 to NSSMF 1202 to delete the created NSSI. In response to such a request, NSSMF 1202 deletes the created NSSI (not shown), and in the process, requests 1262, 1263, 1264 to delete reserved resources may be issued to the component management entity 1205 of NSSMF 1202.

[0173] Fig.13 1300 is a signal flow diagram illustrating an example signal flow for provisioning NSSI in the process generally shown at 1300. The figure shows communications between a 3GPP entity 1301 (which may be a customer (not shown) and / or NSMF 1201), NSSMF 1202, NFV MANO 232, DM / EM 1203, other management systems 1204, and one or more other NSSMFs 1302.

[0174] Although similar to Fig.12 ,but Fig.13 It can be considered as an alternative example showing the existence of another NSSMF 1302. However, the NSSMF 1202 again goes through various stages, which can include discovery 1310, requirements 1320, feasibility 1330, preparation 1340, and onboarding 1350 of the NSSI. In some examples, the NSMF 1201 requests the deletion of the created NSSI, and then enters the deletion stage 1360.

[0175] In the discovery phase 1310, the NSSMF 1202 uses a Fig.12 In some examples, as a non-limiting example, in the context of the discovery phase of provisioning NSI ( Fig.21 ), NSSMF 1202 may receive a request 1314 from 3GPP entity 1301 to provide capability information to 3GPP entity 1301. NSSMF 1202 may receive a request 1314 from 3GPP entity 1301 to provide capability information to 3GPP entity 1301. Fig.12 This request is processed in the manner of request 1214.

[0176] In the requirement phase 1320, the 3GPP entity 1301 uses a method similar to Fig.12 The request with the specific slice subnet requirement is communicated 1323 to the NSSMF 1202 in the form of a request 1223. Finally, the NSSMF 1202 communicates 1324 a response to the request 1323 to the 3GPP entity 1301 as described below.

[0177] In the feasibility phase 1330, the NSSMF 1202 evaluates 1331 the feasibility of reusing the NSSI or creating a new NSSI. Such an evaluation may take into account the remaining capacity of the existing NSSIs and / or NSSTs and the network subnets.

[0178] During such an assessment, NSSMF 1202 may determine that additional information is needed and may Fig.12 In a similar manner, NSSMF 1202 may query 1233, 1234, 1235 its component management entity 1205 for other capability information. In addition, NSSMF 1202 may query 1332 other NSSMFs in a similar manner.

[0179] NSSMF 1202 was subsequently replaced by Fig.12 If the request 1323 is feasible, the NSSMF 1202 enters the network environment preparation phase 1340, obtains the request 1323 from the 3GPP entity 1301, and Fig.12 Prepare a response 1324 to the request in the same manner as in response 1224.

[0180] If the request 1323 is not feasible, the NSSMF 1202 rejects the request 1323 from the 3GPP entity 1301 and sends a similar Fig.12 Prepare a reply 1324 to the request in the manner of response 1224.

[0181] In preparation stage 1340, NSSMF 1202 Fig.12 The resource is reserved by sending 1241, 1242, 1243 reservation requests to the component management entity 1205 and 1340 reservation requests to other NSSMF 1302. Here, responses 1341, 1342, 1343 from the component management entity 1205 and responses 1344 from other NSSMF 1302 are shown. Fig.12 This response can be inferred from .

[0182] In response to reply 1324, the 3GPP entity 1301 confirms 1345 to the NSSMF 1202 its request to reserve resources for provisioning the network slice subnet.

[0183] Thus, in some examples, NSSMF 1202 performs any remaining preparations not completed in preparation phase 1340, including, but not limited to, reserving resources of component management entity 1205 and / or other NSSMF 1302, instantiating VNFs, and / or loading any missing NSSTs.

[0184] During the In-Service Phase 1350, NSSMF 1202 was similar to Fig.12 The 1255NSSI process is created (and / or modified) by Fig.12 The creation stage 1250 is shown but Fig.13 Certain processes not shown in FIG.

[0185] The deletion phase 1360 is initiated by a request 1361 to delete the created NSSI from the 3GPP entity 1301 to the NSSMF 1202. In response to such a request, the NSSMF 1202 deletes the created NSSI (not shown), and in the process, requests 1262, 1263, 1264 to delete reserved resources may be issued to the component management entity 1205 of the NSSMF 1202, and request 1362 may be issued to other NSSMFs 1302.

[0186] Fig.14 is a signal flow diagram illustrating an example flow for preparing NSSI with catalog and capability exposure, shown generally at 1400. The figure illustrates communications between 3GPP entities 1301, NSSMF 1202, NFV MANO 232, DM / EM 1203, and other management systems 1204.

[0187] exist Fig.14 In the scenario of , the service catalog and capabilities are opened to the 3GPP entity 1301. This allows the NSSMF 1202 to establish an openness with its component management entity 1205, such as (as a non-limiting example) to subscribe to updates on the remaining capacity and / or obtain an interface for accessing the information. This openness also allows the 3GPP entity 1301 (without limitation) to check the feasibility of requesting and / or designing NSSI, which can reduce the amount of negotiation, thereby facilitating provisioning. Fig.14 The scenario is well suited for the Type 2 slice deliverable type as described above, but can also be applied to any slice deliverable type.

[0188] During the discovery phase 1410, the NSSMF 1202 requests 1411, 1412, 1413 openings from its component management entities 1205 to facilitate resource and capability discovery.

[0189] Subsequently, NSSMF 1202 was similar to Fig.12The NSSMF 1202 obtains information 1211, 1212, 1213 from its component management entity 1205 in a manner that is consistent with the NSSMF 1202. However, if certain interfaces, access to databases, and / or monitoring capabilities are provided to the NSSMF 1202 as a result of an open request 1411, 1412, 1413 (but not limited to), the NSSMF 1202 does not send queries related to these.

[0190] The NSSMF 1202 may create, update, and / or maintain 1414 a service catalog, database, and / or similar repository based on the information it has collected regarding its capabilities, including but not limited to NSSTs and / or NSST types.

[0191] In the requirement phase 1420, the NSSMF 1202 may receive a request 1421 from the 3GPP entity 1301 to provide network information (i.e., to open its service catalog). In some examples, the request 1421 is a message 1421a similar to a queryNetworkResourceRequest with filter() and attributeSelector() parameters. In some examples, the request 1421 is a different message and may include, but is not limited to, parameters related to capacity opening and capability opening. In some examples, the request 1421 may be a ServiceCapabilityRequest message from the 3GPP entity 1301 to the NSSMF 1202, and in some examples, the 3GPP entity 1301 may be, but is not limited to, the NSF 1201, another NSSMF 1302, and / or a CSMF. In some examples, the input parameter of the ServiceCapabilityRequest message may be a serviceCapabilityRequest identifier requesting a service that can be provided, and the output parameter may be a serviceCapability listing possible services and capabilities (including, but not limited to, capacity opening and capability opening). In some examples, request 1421 may be a ServiceOpennessRequest message from NSSMF 1202 to one of component management entities 1205, which may be, but is not limited to, NFV MANO 232, DM / EM 1203, or other management system 1204. In some examples, an input parameter of the ServiceOpennessRequest message may be a serviceOpennessRequest identifier requesting an opening that may be provided, and an output parameter may be a serviceOpenness listing possible openings and capability information.

[0192] The NSSMF 1202 evaluates the access request 1422 and provides access 1423 to a service catalog in the form of capabilities and / or remaining capacity information to the 3GPP entity 1301, which in some examples may be, but is not limited to, the NSMF 1201, another NSSMF 1302, and / or a CSMF. In some examples, if attributeSelector() is missing, the complete attributes of the network resource are returned. In some examples, the response 1423 is a message 1423a similar to queryNetworkResourceResponse with networkResourceData as a parameter. In some examples, the response 1423 may be a ServiceCapabilityResponse message from the NSSMF 1202 to the 3GPP entity 1301, which in some examples may be, but is not limited to, the NSMF 1201, another NSSMF 1302, and / or a CSMF. In some examples, response 1423 may be a ServiceOpennessResponse message from one of component management entities 1205 , which may be, but is not limited to, NFV MANO 232 , DM / EM 1203 , or other management system 1204 , to NSSMF 1202 .

[0193] The NSSMF 1202 receives 1424 an NSSI provisioning request with NSSI requirements. In some examples, the request 1424 is a message 1424a similar to a TemplateRequest with nsstData as a parameter. In some examples, the nsstData may be one or more NSSTs selected from the service catalog. In some examples, the nssstData may be one or more attributes with values.

[0194] In feasibility phase 1430, NSSMF 1202 uses the latest service catalog information to verify 1431 the feasibility of request 1424. In some examples, verification 1431 is a command 1431a similar to InitiateServiceRequireResponse.

[0195] In some examples, because the capability and / or remaining capacity information has been provided to 3GPP entity 1301 , 3GPP entity 1301 may perform its own feasibility check in addition to and / or in lieu of feasibility verification 1431 .

[0196] In some examples, NSSMF 1202 sends queries 1432, 1433, 1434 to its component management entities 1205 to reserve resources and prepare a suitable network environment. In some examples, when resources have been reserved, component management entities 1205 send replies back to NSSMF 1202. If one or more component management entities 1205 are unable to reserve the requested resources, the responses to queries 1432, 1433, 1434 may indicate the problems encountered.

[0197] In some examples, NSSMF 1202 updates its service catalog accordingly.

[0198] The NSSMF 1202 replies 1425 to the NSSI provisioning request 1424 with information related to the reserved network resources, including but not limited to the NSSI descriptor, NSST, NSSI attribute values, and / or the ID of the shared NSSI. In some examples, the reply 1425 is a message 1425a similar to a queryNetworkResourceResponse with networkResourceData as a parameter. In some examples, such a message 1425a may send nsstID as a parameter of the associated template, ServiceRequireID as a parameter of the permitted service, and / or other parameters and / or messages.

[0199] In some examples, user plane and / or control plane policies (including but not limited to charging policies) can be established. In some examples, the establishment of such policies can include negotiation. In some examples, a specific PCF 100 can establish such policies 1436. Such PCF 100 can receive a response 1436 indicating the preparation of the licensed service from NSSMF 1202 or other management functions. In this way, the PCF 100 can send 1436 a request to retrieve the policy of the 3GPP entity 1301. This message 1436 can be sent to NSMF 1201, the PCF 100 of the 3GPP entity 1301, or another related management function. The PCF 100 can evaluate the received messages to see if they are consistent with the existing policies. If the policy of the 3GPP entity 1301 is consistent with the provider's policy and other network policies, a response can be sent to the 3GPP entity 1301. Subsequently, the policy-related configuration can be processed by the NSSMF 1202, or the PCF 100, or a specific policy configuration function of the entire network.

[0200] At this point, NSSI is ready to enter the negotiation phase 1570 ( Fig.15 ) and / or preparation phase 1550 (combined Fig.15 discuss).

[0201] Fig.15 is a signal flow diagram illustrating an example process for creating an NSSI with directory capability open, shown generally at 1500 . Fig.15 Continued from Fig.14 .

[0202] First, the result of the policy establishment 1426 is evaluated. If the 3GPP entity 1301 refuses to create the NSSI, the negotiation phase 1570 may be entered. Otherwise, the preparation phase 1540 is entered.

[0203] During the negotiation phase 1570, the rejection is signaled (NSSMF 1202 receives a message 1571 rejecting the NSSI). In some examples, such a message may provide a reason for the rejection. In some examples, NSSMF 1202 evaluates 1572 the reason for the rejection and prepares a response.

[0204] In some examples, NSSMF 1202 negotiates provisioning options, which may include, but are not limited to, redesign options, modification options, and / or network resource allocation options for existing NSSIs. In some examples, the negotiation may be facilitated by NSSMF 1202 receiving a NegotiateServiceRequireRequest() message 1573a. In response to the message, NSSMF 1202 may send a NegotiateServiceRequireResponse() message 1574a.

[0205] If the 3GPP entity 1301 approves the negotiated provisioning options, the NSSMF 1202 may receive an UpdateServiceRequireRequest() message 1575a, in response to which an UpdateServiceRequireResponse() message 1576a is prepared. Subsequently, at 1425, the feasibility phase 1430 is entered.

[0206] In the preparation phase 1540, the 3GPP entity 1301 approves and finalizes 1543 all resource reservations. In some examples, the approval 1541 is a message 1541a similar to the InstantiateNssiRequest () with nsstID and instantiateNssiTime as parameters. In some examples, the request 1541 is a different message and can include suitable parameters. In some examples, the 3GPP entity 1301 only sends a response with an ID (which can be an NSST ID). In some examples, the approval 1541 can be a ServiceConfirmationRequest message from the 3GPP entity 1301 to the NSSMF 1202. In some examples, the 3GPP entity 1301 can be, but is not limited to, the NSMF 1201, another NSSMF 1302, and / or a CSMF. In some examples, the input parameters of the ServiceConfirmationRequest message may include at least one of the following: a serviceConfirmationRequest identifier requesting confirmation of a requested service, and / or serviceConfirmationParameters (service confirmation parameters) requesting confirmation of the requested service with appropriate parameters, and the output parameter may be a serviceCapability identifier for a confirmation (ACK) and / or rejection (NACK) response.

[0207] NSSMF 1202 then loads 1542 all appropriate NSSTs and values, and / or NSSI descriptors, and / or components of the NSST. In some examples, loading 1542 may be triggered by a signal flow 1543 from 3GPP entity 1301. In some examples, signal flow 1543 is a message 1543a similar to OnBoardTemplate with a nsstID parameter. In some examples, loading 1542 may include preparations by component management entity 1205, which are triggered by signal flows 1544, 1545, 1546 from NSSMF 1202.

[0208] In some examples, completion of loading 1542 may be signaled by NSSMF 1202 by sending a ServiceRequireID() message 1547a to 3GPP entity 1301 .

[0209] During the onboarding phase 1550, creation and / or onboarding of a new NSSI and / or modification of an existing NSSI is completed 1551, and the NSSI is then ready to be activated.

[0210] The deletion phase 1560 may be initiated by a request 1561 from the 3GPP entity 1301 to the NSSMF 1202 to delete the incoming NSSI. In response to such a request, the NSSMF 1202 prepares to delete 1562 the created NSSI, and in the process, may issue requests 1262, 1263, 1264 to its component management entity 1205 to delete reserved resources.

[0211] In some examples, the NSSMF 1202 updates 1565 its service catalog accordingly to indicate the released resources.

[0212] Fig.16 is a signal flow diagram illustrating an example process for provisioning an NSSI with a catalog and capability exposure, generally shown at 1600. Fig.11 It is understood that the above provisioning includes a preparation phase 1110 and a service entry phase 1130, which includes creating 1131 (and / or combining Fig.17 Modifications discussed), therefore, in some examples, Fig.16 Can be Fig.14 and the following Fig.15 Connected, or Fig.16 Can be Fig.14 and the subsequent Fig.15 (The corresponding part is Fig.17 Partial replacement (not shown)) connected, so should refer to Fig.14 , Fig.15 , and / or Fig.17 .

[0213] Fig.17 1 is a signal flow diagram showing an example process of bringing in an NSSI by modifying an existing NSSI. The diagram shows the communication between 3GPP entity 1301, NSSMF 1202, NFV MANO 232, DM / EM 1203, and other management systems 1204.

[0214] It should be understood that Fig.17 The process of 1700 generally illustrates an alternative example including a preparation phase and an entry phase, which alternative example may replace Fig.15 and Fig.16 Thus, it should be understood that the process 1700 is preceded by the discovery phase 1410, the requirement phase 1420, and the feasibility phase 1430, and further, there may be a deletion phase 1560 and / or a negotiation phase 1570.

[0215] Process 1700 assumes that an NSSI to be modified already exists. Such an NSSI may or may not be shared. A shared NSSI is one on which other services are deployed. It is conceivable that because the previous service has been completed but not yet terminated (see Fig. 20 ), so the shared NSSI may be in service but not activated (see Fig.18 ).

[0216] First, the results of the policy establishment 1426 are evaluated. The process 1700 also assumes that the 3GPP entity 1301 approves and finalizes 1741 all resource reservations in a confirmation response.

[0217] NSSMF 1202 completes 1742 preparation of the network environment by finalizing reservations, updating policies, loading any other functions and / or any other configuration. In some examples, this may include preparations by component management entity 1205, which are triggered by signal flows 1743, 1744, 1745 from NSSMF 1202.

[0218] Subsequently, NSSMF 1202 finalized 1746 modifications to the NSSI.

[0219] NSSMF 1202 sends message 1747 to 3GPP entity 1301 indicating that the NSSI is ready to be activated (if not already activated). In some examples, NSSMF 1202 provides information (including but not limited to NSSI ID) and tools (including but not limited to interfaces) for monitoring and reporting fault management, performance management, and / or security management of services deployed on the NSSI. In some examples, the runtime (operational) monitoring and / or management capabilities provided to 3GPP entity 1301 may depend on an agreement between 3GPP entity 1301 and the network provider.

[0220] During the in-service phase 1750, NSSMF 1202 receives 1751 an activation request from 3GPP entity 1301. In response to the request, NSSMF 1202 activates 1752 the NSSI (if not already activated). In some examples, such activation may include a test for validating the NSSI. In some examples, such activation may include activation of components of the NSSI, including but not limited to VNFs, NFs, and / or NSSI.

[0221] Once activated, NSSMF 1202 sends a reply 1753 to activation request 1751 containing service entry information. Activation of the NSSI makes the NSSI operational.

[0222] In some examples, the NSSMF 1202 updates 1754 its service catalog as the network environment and resources change.

[0223] Fig.18 is a signal flow diagram illustrating an example signal flow for activating a provisioned NSSI in the process generally shown at 1800. The diagram illustrates communications between 3GPP entities 1301, NSSMF 1202, NFV MANO 232, DM / EM 1203, other NSSMFs 1302, and other management systems 1204.

[0224] refer to Fig.11 , process 1800 corresponds to activation 1141 during operation phase 1140.

[0225] Activation 1141 is initiated by a generated or received trigger 1810. Such triggers 1810 may include, but are not limited to: internal and / or external timer alarms 1811 indicating activation of the NSSI (in some examples, this may be an activateNssiTime() function and / or a TimerDone() function); a request 1812 from the 3GPP entity 1301 to activate the NSSI (in some examples, this may be an ActivateNssiRequest() with nssiID as a parameter); and / or deploying a service 1813 on an existing NSSI (e.g. Fig.17 In some examples, if a new service is being deployed and the network provider's service directory information is not provided to 3GPP entity 1301, the NSSI will not receive the nssiID parameter. In some examples, if open is provided, the NSSSF 1202 may receive the nssiID parameter.

[0226] NSSMF 1202 identifies any inactive NSSI components and sends messages 1821, 1822, 1823 to its component management entity 1205 to activate the inactive NFs. In some examples, if the NSSI components are managed by another NSSMF 1302, NSSMF 1202 may send a request 1824 to activate those resources to the other NSSMF 1302.

[0227] Furthermore, the NSSMF 1202 sends requests 1831, 1832, 1833, 1834 to the component management entity 1205 and the other NSSMF 1302 to obtain and / or configure resources for activating the NSSI and receives responses 1835, 1836, 1837, 1838 therefrom.

[0228] In addition, NSSMF 1202 activates 1841 , 1842 , 1843 , 1844 , 1845 relevant inactivation policies at 3GPP entity 1301 , other NSSMFs 1302 , and component management entity 1205 .

[0229] If an activation request 1812 is received, the NSSMF 1202 sends 1851 a response. In some examples, the response 1851 may be a response 1851a similar to ActivateNssiResponse() with NssLifecycleOperatIonOccurrenceId as a parameter, which helps traceability of the operation. Subsequently, the NSSI is activated 1861.

[0230] Fig.19 is a signal flow illustrating an example signal flow for deactivating an activated NSSI in the process generally illustrated at 1900. The figure illustrates communications between 3GPP entities 1301, NSSMF 1202, other NSSMFs 1302, NFV MANO 232, DM / EM 1203, and other management systems 1204.

[0231] refer to Fig.11 , process 1900 corresponds to deactivation 1145 during operation phase 1140.

[0232] Deactivation 1145 is initiated by a generated or received trigger 1910. Such a trigger 1910 may include, but is not limited to: an internal and / or external timer alarm 1911 indicating deactivation of the NSSI (in some examples, it may be a deactivateNssiTime() function and / or a TimerDone() function); a request 1912 from the 3GPP entity 1301 to deactivate the NSSI (in some examples, it may be a DeactivateNssiRequest() with nssiID as a parameter); and / or removing the service from the NSSI 1913. In some examples, if the NSSI is being shared, other services on the NSSI are deployed to other NSSIs without interruption. In some examples, if openness is provided, the NSSSF 1202 may receive a nssiID parameter.

[0233] The NSSMF 1202 begins deactivation 1921 by identifying whether the traffic should be rerouted, as a non-limiting example, without interrupting the ongoing service if there are other services using the slice. This may trigger a deactivation based on Fig.17 NSSI modification, directing existing services to existing slices, and / or Fig.15Create an NSSI and deploy existing services on the new NSSI.

[0234] The NSSMF 1202 identifies the activated NSSI associated with the NSSI being deactivated and sends a request 1931 to deactivate the identified NSSI to the other NSSMF 1302. In some examples, the request 1931 may be a response 1931a similar to a DeactivateNssiRequest() message with NssiLifecycleOperationOccurrenceId and / or nssiID parameters. In response to the request, the NSSMF 1202 may receive a DeactivateNssiResponse() message 1932a with a NssiLifecycleOperationOccurrenceId parameter.

[0235] In some examples, NSSMF 1202 may send notifications 1941, 1942, 1943 to its component management entity 1205 of the network that is preparing to deactivate the NSSI. As a non-limiting example, other management systems 1204 may be requested 1943 to cause the TN manager to release resources previously allocated to the NSSI. In some examples, the notifications 1941, 1942, 1943 may be accompanied by information. In some examples, the notifications 1941, 1942, 1943 elicit responses or replies 1944, 1945, 1946 from the component management entity 1205.

[0236] In addition, NSSMF 1202 deactivates 1951 , 1952 , 1953 , 1954 , 19553 relevant policies at GPP entity 1301 , other NSSMFs 1302 , and component management entity 1205 .

[0237] If a deactivation request 1912 is received, the NSSMF 1202 sends 1961 a response. In some examples, the response 1961 may be a response 1961a similar to a DeactivateNssiResponse() message with a NssiLifecycleOperationOccurrenceId parameter that facilitates traceability of the operation. Subsequently, the NSSI is deactivated 1971.

[0238] Fig. 20is a signal flow diagram illustrating an example signal flow for terminating NSSI in the process shown generally at 2000. The figure shows communications between 3GPP entities 1301, NSSMF 1202, other NSSMFs 1302, NFV MANO 232, DM / EM 1203, and other management systems 1204.

[0239] refer to Fig.11 , process 2000 corresponds to termination 1151 in decommissioning phase 1150 .

[0240] Termination 1151 is initiated by a generated or received trigger 2010. Such a trigger 2910 may include, but is not limited to: an internal timer alarm and / or policy 2911 indicating termination of the NSSI (in some examples, this may be a TimerDone() function); a request 2912 from the 3GPP entity 1301, NSMF 1201, and / or another NSMF (not shown) (as a non-limiting example) to terminate the NSSI because it is no longer needed to support a particular service (in some examples, this may be a TerminateNssiRequest() with nssiID as a parameter); and / or termination due to an unrecoverable failure 2913. In some examples, if the trigger 2910 is a request 2912, the NSSMF 1202 may decide to terminate the NSSI based solely on the NSSI. Fig.17 Modify NSSI instead of terminating NSSI.

[0241] NSSMF 1202 begins termination 2021 by identifying whether the NSSI and / or any related NSSIs and / or NSIs are active. If so, Fig.19 and / or Fig.29 Deactivate it. NSSMF1202 identifies the activated NSSI associated with the NSSI being terminated and sends a request 1931 to the other NSSMF 1302 to deactivate the identified NSSI. In some examples, request 1931 may be a request 1931a similar to a DeactivateNssiRequest() message with NssiLifecycleOperationOccurrenceId and / or nssiID parameters. In response to the request, NSSMF1202 may receive a DeactivateNssiResponse() message 1932a with a NssiLifecycleOperationOccurrenceId parameter.

[0242] Subsequently, the NSSMF 1202 sends a request to the other NSSMF 1302 to terminate the identified NSSI. In some examples, the request may be a TerminateNssiRequest() message 2031a with an NssiID parameter. In response to the request, the NSSMF 1202 may receive 2032a a Termination NssiResponse() message. It should be understood that the openness level may indicate whether the NSSMF 1202 may directly request deactivation and / or termination. In some examples, the NSSMF 1202 may send an Offloadservice() message (not shown) with a serviceID parameter.

[0243] In some examples, NSSMF 1202 may send notifications 2041, 2042, 2043 to its constituent management entities 1205 to release any resource allocations. In some examples, such notifications 2041, 2042, 2043 may appear in Fig.19 In some examples, the TNs within the NSSI will be terminated. The NSSMF 1201 sends a TN related request to the other management system 1204 to indicate to the TN manager that the TN portion does not need to support the terminated NSSI.

[0244] In some examples, NSSMF 1202 disassociates the NSI from the NSSI and may trigger NSI-related requests to the NFVO through the Os-Ma-nfvo interface and may trigger deactivation of NSSI-related policies.

[0245] In some examples, notifications 2041 , 2042 , 2043 elicit responses or replies 2044 , 2045 , 2046 from constituent management entity 1205 .

[0246] In addition, the loaded NSST can be uninstalled. In some examples, if the NSST is loaded, the NSSMF 1202 sends 2051, 2052, 2053, 2054, 2055 uninstall requests to the 3GPP entity 1301, other NSSMFs 1302, and the component management entity 1205.

[0247] If a termination request 2012 is received, the NSSMF 1202 sends 2061 a response. In some examples, the response 2061 may be a response 1961a similar to a TerminateNssiResponse() message with a NssiLifecycleOperationOccurrenceId parameter that facilitates traceability of the operation. Subsequently, the NSSI is terminated 2071.

[0248] The procedures described below are generally compatible with provisioning an NSI by creating a new NSI, however, these procedures may be applicable to the case where an existing NSI is used.

[0249] In this case, the NSMF 1201 may establish an opening with other network management entities, for example in order to subscribe to updates of remaining capacity and / or obtain an interface for accessing information. The NSMF 1021 may receive a NSI or related request from a CSMF or another NSMF 1201. The parameters given here are related to the CSMF.

[0250] Fig.21 2100 is a signal flow diagram showing an example signal flow for provisioning NSI in a general process generally shown at 2100. The figure shows the communication between a 3GPP entity 2101 (which may be a client (not shown)), one or more NSMFs 1201, NSSMF 1202, and other management systems 2103 including but not limited to TN and / or Wi-Fi systems, which may include 3GPP and / or non-3GPP management entities. Those skilled in the relevant art will understand that the NSMF 1201 and other management systems 2103 are management entities that are components of the NSMF 1201 (collectively referred to as 2105), and the NSMF 1201 can communicate with these management entities.

[0251] It is assumed that the network slice template (NST) and / or NSST of the component NSSI is loaded.

[0252] The general process 2100 includes the NSMF 1201 going through various phases, which may include discovery 2110, requirements 2120, feasibility 2130, preparation 2140, and creation 2150. In some examples, the 3GPP entity 2101 requests deletion of the created NSI, and then enters the deletion phase 2160.

[0253] In the discovery phase 2110, NSMF 1201 is similar to Fig.12The NSSMF 1202 obtains information 1211, 1212, 1213 from its component management entity 1205 in the same manner as it obtains information 2111, 2112 from its component management entity 2105.

[0254] In the requirement phase 2120, the 3GPP entity 2101 communicates 2121 a request with network slicing related requirements to the NSMF 1201. Finally, the NSMF 1201 communicates 2125 a response to the request 2121 to the 3GPP entity 2101, as described below.

[0255] The NSMF 1201 derives 2122 NSI requirements, NSSI requirements, and / or non-3GPP requirements of the NSI. These requirements may include one or more NSTs, one or more NSSTs, network slice characteristics, network slice subnet characteristics, network topology, specific resource requirements, latency, bandwidth, NF-related requirements (such as but not limited to layout), NF-related capabilities and / or network KPIs (such as but not limited to network outages and / or specific link requirements). Such requirements may be derived by the NSMF 1201 through its resource discovery process and / or inspection of the service catalog. In some examples, the resource discovery process does not provide sufficient information, and the NSMF 1201 may make one or more target capability queries 2123, 2124 to its component management entity 2105.

[0256] In some examples, the requirements may be prepared by another performer (including but not limited to a customer, a third party, or another 3GPP management entity (eg, a CSMF)) and provided (not shown) to NSMF 1201 .

[0257] As previously mentioned, the details of the requirements and who determines them depends on the openness between the management entities. Therefore, the export 2122 of the requirements is shown as optional.

[0258] In the feasibility phase 2130, the NSMF 1201 performs a feasibility check to obtain an initial indication as to whether the request is feasible. In this way, the NSMF 1201 can evaluate 2131 the possibility of reusing an existing NSI (modified or not).

[0259] If an existing NSI can be used for request 2121 and using the existing NSI does not violate its policies and services, NSMF 1201 sends a response 2125 with the existing NSI.

[0260] If it is deemed not possible, the NSMF 1201 evaluates the possibility of creating a new NSI to support the request. This evaluation may take into account the existing NSI and / or NST and the remaining capacity of the network, and derive network subnet slicing related requirements as well as TN related requirements.

[0261] Based on this evaluation, the NSMF 1201 sends 2132 the network slice subnet related requirements to the NSSMF 1202. In addition, this evaluation may determine that more information is needed, and the NSSMF 1202 may be queried 2132 for other capability information. This query may be based on the requirements obtained from the 3GPP entity 2101, or may include a general capability information request for further discovery resources. In some examples, the nature of the query and the response obtained may depend on the openness level of the NSSMF 1202.

[0262] Requests and / or queries 2132 may trigger 2134 such as Fig.12 Preparation and creation of NSSI shown. Following the required request and / or query 2132 may be a response 2135 from NSSMF 1202 to NSMF 1201.

[0263] In addition, the NSMF 1201 sends 2133 TN-related requirements (including but not limited to external connection points, latency, and / or bandwidth) to other management systems 2103 (including but not limited to TN managers). In addition, this evaluation can determine that more information is needed, and other management systems 2103 can be queried 2133 for other capability information. This query can be based on the requirements obtained from the 3GPP entity 2101, or can include a general capability information request for further discovery of resources. In some examples, the nature of the query and the response obtained can depend on the openness level of the other management system 2103.

[0264] The request and / or query 2133 may be followed by a response 2136 from the other management systems 2103 to the NSMF 1201 .

[0265] Subsequently, NSMF 1201 makes a formal determination of feasibility 2137. If request 2121 is feasible, NSMF 1201 enters the network environment preparation 2140 phase, obtains request 2121 from 3GPP entity 1201, and prepares a reply 2125 to the request. In some examples, certain information disclosure is allowed between NSMF 1201 and 3GPP entity 2101, and reply 2125 can disclose information related to component management entity 2105 of NSMF 1201, including but not limited to the remaining capacity, NST, and / or NST attributes of component management entity 2105.

[0266] If the request 2121 is not feasible, the NSMF 1201 rejects the request 2121 from the 3GPP entity 2101 and prepares a reply 2125 to the request. In some examples, certain information disclosure is allowed between the NSMF 1202 and the 3GPP entity 2101, and the reply 2125 may disclose information related to the component management entity 2105 of the NSMF 1201, including but not limited to the remaining network capabilities of the component management entity 2105. Such information may allow the 3GPP entity 2101 to update and resend its request 2121. If unsuccessful, the deletion phase 2160 is entered.

[0267] In some examples, 3GPP entity 1301 and NSMF 1201 may negotiate other feasible provisioning options.

[0268] In the preparation phase 2140, NSMF 1201 performs preparations, which may include but are not limited to reserving resources for establishing NSSI connections (in the case of NSSMF 1202) or TN connections (in the case of other management systems 2103) by sending 2141, 2142 reservation requests to the component management entity 2105.

[0269] In the creation phase 2150, the 3GPP entity 2101 sends 2151 a reply to the answer 2125 to the NSMF 1201. The NSMF 1201 requests 2152, 2153 that its component management entity 2105 prepares to configure its NSSI and / or TN, or that the NSMF 1201 completes the network environment preparation 2154. The NSMF 1201 loads 2155 the appropriate NSI descriptor of the selection as identified in action 2131 and / or action 2137. When the NSI descriptor has been loaded, the NSMF 1201 creates (and / or modifies) an NSSI procedure to create 2156 the NSI.

[0270] In some examples, if the feasibility phase 2130 fails, a deletion phase 2160 is entered. In some examples, the deletion phase 2160 is initiated by a request 2161 from the 3GPP entity 2101 to the NSMF 1201 to delete the created NSI. In response to such a request, the NSMF 1201 deletes the created NSI (not shown), and in the process, requests 2162, 2163 to delete reserved resources may be issued to the component management entity 2105 of the NSMF 1201.

[0271] Fig. 22 is a signal flow diagram illustrating an example signal flow for provisioning NSSI in the process generally shown at 2200. The diagram illustrates communications between 3GPP entities 2101, NSMF 1201, NSSMF 1202, and other management systems 2103.

[0272] Although similar to Fig.21 ,but Fig. 22 It can be considered as showing (but not limited to) alternative examples of components of NSI information message, activation request, and / or 3GPP slice management entity. However, NSMF 1201 again goes through various stages, which may include discovery 2210, requirement 2220, feasibility 2230, preparation 2240, and creation 2250 of NSI. In some examples, 3GPP entity 2101 requests to delete the created NSI, and then enters the deletion stage 2260.

[0273] In the discovery phase 2210, NSMF 1201 uses a method similar to Fig.21 Information 2111, 2112 is obtained from the NSSMF 1202 and other management systems 2103 by means of the discovery phase 1210 of the present invention. In this way, a directory can be prepared and / or an existing directory can be updated. In addition, a general policy and / or guideline for determining the services that the network can provide can be obtained.

[0274] At the requirement stage 2220, the 3GPP entity 2101 Fig.21 The NSMF 1201 communicates 2121 a request with specific slice requirements to the NSMF 1201 in the form of a request 2121 of 2124. Finally, the NSMF 1201 communicates 2125 a response to the request 2121 to the 3GPP entity 2101 as described below.

[0275] In some examples, NSMF 1201 may be similar to Fig. 22 The method of exporting 2122 derives 2122 the NSI requirements, NSSI requirements, and / or non-3GPP requirements of the NSI.

[0276] In some examples, the resource discovery process does not provide sufficient information, and the NSMF 1201 may respond with information similar to Fig.21 The query 2123, 2124 method is used to perform one or more target capability queries 2123, 2124 to the NSSMF 1202 and other management systems 2103.

[0277] In the feasibility phase 2230, the NSSMF 1202 evaluates 2131 the feasibility of reusing an NSSI or creating a new NSSI. Such an evaluation may take into account the remaining capacity of existing NSSIs and / or NSSTs and network subnets.

[0278] During this evaluation, NSMF 1201 may determine that additional information is needed and may Fig.21 The NSSMF 1202 and other management systems 2103 are queried 2132, 2133 to obtain other capability information.

[0279] Requests and / or inquiries 2132 may be sent in a manner similar to Fig.21 The method of triggering 2134 is as follows Fig.12 Preparation and creation of NSSI shown. Following the required request and / or query 2132 may be a response 2135 from NSSMF 1202 to NSMF 1201.

[0280] The request and / or query 2133 may be followed by a Fig.21 Response 2136 from other management systems 2103 to NSMF 1201 in the manner described.

[0281] Subsequently, NSSMF 1202 was similar to Fig.21 If the request 2121 is feasible, the NSMF 1201 enters the preparation phase 1340, obtains the request 2121 from the 3GPP entity 2101, and sends the request 2121 to the NSMF 1201 in a manner similar to Fig.21 Prepare a response to the request 2125 in the manner of response 2125 in.

[0282] If the request 2125 is not feasible, the NSMF 1201 rejects the request 2121 from the 3GPP entity 2101 and sends a similar Fig.21 Prepare a response to the request 2125 in the manner of response 2125 in.

[0283] In preparation for stage 2240, NSMF 1201 was developed by Fig.21 The system sends 2141, 1242 reservation requests to NSSMF 1202 and other management systems 2103 to reserve resources. Here, responses 2141, 2142 from NSSMF 1202 and other management systems 2103 are shown. Fig.21 This response can be inferred from .

[0284] In response to reply 2125, 3GPP entity 2101 sends a response similar to Fig.21 A response to reply 2125 is sent 2151 in the same manner.

[0285] Therefore, NSSMF 1202 performs preparations 2154, which may include, but are not limited to, Fig.21 Reserve resources of component management entity 1205 and / or NSSMF 1202 in a manner.

[0286] In the service entry phase 2250, NSMF 1201 creates (and / or modifies) (not shown, but similar to Fig.21The NSMF 1201 sends 2251 information related to the created (and / or modified) NSI to the 3GPP entity 2103.

[0287] In some examples, the 3GPP entity 2103 may send 2252 a request to activate the NSI to the NSMF 1201. In some examples, the NSI is automatically activated. Regardless of activation, once the NSI is activated, the NSMF 1201 sends 2253 a network slice activation notification to the 3GPP entity 2101 to indicate that the provisioning is complete.

[0288] It can be inferred that Fig.21 The creation stage 2150 is shown but Fig. 22 Certain processes are not shown in the example, and vice versa.

[0289] The deletion phase 2260 is initiated by a request 2161 from the 3GPP entity 2101 to the NSMF 1201 to delete the created NSI. In response to such a request, the NSMF 1201 deletes the created NSI (not shown), and in the process, requests 2162, 2163 to delete reserved resources may be issued to the NSSMF 1202 and other management systems 2103.

[0290] Fig.23 is a signal flow diagram illustrating an example flow for preparing a NSI with catalog and capability exposure, shown generally at 2300. The figure illustrates the communication between 3GPP entities 2101, NSMF 1201, NSSMF 1202, and other management systems 2013.

[0291] and Fig.14 The same scene, in Fig.23 In the scenario of , the service catalog and capabilities are opened to the 3GPP entity 2101. This allows the NSMF 1201 to establish an openness with its component management entity 2105, such as (as a non-limiting example) to subscribe to updates on remaining capacity and / or obtain an interface for accessing information. This openness also allows the 3GPP entity 2101 (without limitation) to check the feasibility of requesting and / or designing NSI, which can reduce the amount of negotiation, thereby facilitating provisioning. Fig.23 The scenario is well suited for the Type 2 slice deliverable type as described above, but can also be applied to any slice deliverable type.

[0292] In the discovery phase 2310, NSMF 1201 requests 2311, 2312 openness from its component management entity 2105 to facilitate resource and capability discovery. NSMF 1201 only requests openness 2311 from NSSMF 1202. If appropriate, NSSMF 1202 requests openness 1411, 1412, 1413 from its component management entity 1205 to obtain capability information therefrom.

[0293] Subsequently, NSMF 1201 was developed similar to Fig.21 2111, 2112 from its component management entity 2105. However, if, as a result of an open request 2311, 2312, certain interfaces, access to databases, and / or monitoring capabilities are provided to the NSMF 1201 (without limitation), the NSMF 1201 does not send queries related to these.

[0294] In some examples, as described below, a service catalog prepared 1414 by NSSMF 1202 may be provided to NSMF 1201 for inclusion in a service catalog to be prepared 2314 by NSMF 1201. As a non-limiting example, an NSST identified in NSSMF 1202's service catalog may be included in an NST created by NSMF 1201 for its service catalog.

[0295] The NSMF 1201 may create, update, and / or maintain 2314 a service catalog, database, and / or similar repository based on the information it has collected related to its functions (including but not limited to NSTs and / or NST types).

[0296] In the request phase 2320, the NSMF 1201 may receive a request 2321 from the 3GPP entity 2101 to provide network information (i.e., to open its service catalog). In some examples, the request 2321 is a message 2321a similar to a queryNetworkResourceRequest with filter() and attributeSelector() parameters. In some examples, the request 2321 is a message 2321b similar to a TemplateRequest() with templateType as a parameter. In some examples, the request 2321 is a different message and may include, but is not limited to, parameters related to capacity opening and capability opening. In some examples, the request 2321 may be a ServiceCapabilityRequest message from the CSMF and / or the client to the NSMF 1201. In some examples, the input parameter of the ServiceCapabilityRequest may be a serviceCapabilityRequest identifier requesting the services that can be provided, and the output parameter may be a serviceCapability listing possible services and capabilities (including but not limited to capacity opening and capability opening).

[0297] The NSSMF 1201 evaluates the access request 2322 and provides access 2323 to a service catalog in the form of capabilities and / or remaining capacity information to the 3GPP entity 2101, which in some examples may be, but is not limited to, a customer and / or CSMF. In some examples, if attributeSelector() is missing, the complete attributes of the network resource are returned. In some examples, the response 2323 is a message 2323a similar to queryNetworkResourceResponse with networkResourceData as a parameter. In some examples, the response 2323 is a message 2323b similar to TemplateResponse(). In some examples, the response 2323 may be a Service CapabilityResponse message from the NSMF 1201 to the CSMF and / or customer.

[0298] NSMF 1201 receives 2324 an NSI provisioning request with NSI requirements. In some examples, if not previously provided, request 2324 is a message 2324a similar to TemplateRequest with TemplateType as a parameter. In some examples, nstData may be one or more NSTs selected from the service catalog. In some examples, nstData may be one or more attributes with a value and the NSST.

[0299] In the feasibility phase 2330, the NSMF 1201 verifies 2331 the feasibility of the request 2324 using the latest service catalog information.

[0300] In some examples, NSMF 120 sends queries 2332a, 2332b to its component management entities 2105 to ensure remaining capacity, reserve resources, and prepare a suitable network environment. In some examples, when resources have been reserved, component management entities 2105 send a reply back to NSMF 1201. If one or more component management entities 2105 cannot reserve the requested resources, the response to the query 2132a, 2132b can indicate the problem encountered.

[0301] In some examples, NSMF 1201 updates 2333 its service catalog accordingly.

[0302] The NSMF 1201 may evaluate 2131 the possibility of reusing an existing NSI (modified or unmodified) for shared and / or non-shared services. In doing so, the NSMF 1201 obtains the corresponding NSI ID and information that may include the existing NSSI ID. If feasible, then perform Fig.26 The processing described.

[0303] In some examples, as a non-limiting example, if openness is not fully provided, the NSMF 1201 can determine the NSI and non-3GPP requirements by querying 2332a, 2332b its capabilities to its component management entity 2105 (and to other NSMFs (not shown)). In addition, if other network entities and / or functions (including but not limited to NFV MANO 232 and / or TN manager (not shown)) provide openness, the NSMF 1201 can also send queries to these network entities and / or functions. NSMF1201 receives responses to such queries. It is easy to understand that the query action can include sending queries and receiving responses to the above queries.

[0304] In the case of NSSMF 1202, query 2334a may trigger NSSMF 1202 to perform, for example Fig.14 Evaluation and initial network preparation shown.

[0305] The NSMF 1201 then makes a formal determination of feasibility 2137. If the request 2324 is feasible, a reservation request 2335a, 2335b is sent to its constituent management entity 2105, followed by an opening and response. If the response is negative, other queries may be sent.

[0306] NSMF 1201 replies 2325 to NSI provisioning request 2324 with information about the reserved network resources, including but not limited to NSI descriptor, NST, NSI attribute values, and / or ID of the shared NSI. In some examples, reply 2325 is a message 2325a similar to queryNetworkResourceResponse with networkResourceData as a parameter. In some examples, such message 2325a may send nsstID as a parameter of the associated template, ServiceRequireID as a parameter of the permitted service, and / or other parameters and / or messages.

[0307] In some examples, user plane and / or control plane policies (including but not limited to charging policies) can be established. In some examples, the establishment of such policies can include negotiation. In some examples, a specific PCF 100 can establish such policies 2327. Such PCF 100 can receive a response 2337 indicating the preparation of licensed services from NSMF 1201 or other management functions. In this way, PCF 100 can send 2337 to retrieve a request for the policy of 3GPP entity 1301. Such message 2337 can be sent to 3GPP entity 2101, PCF 100 of 3GPP entity 2101, or another related management function. PCF 100 can evaluate the received messages to see if these messages are consistent with existing policies. If the policy of 3GPP entity 2101 is consistent with the provider's policy and other network policies, a response can be sent to 3GPP entity 2101. Subsequently, policy-related configurations can be processed by NSMF 1201, or PCF100, or a specific policy configuration function of the entire network.

[0308] At this point, NSI is ready to enter the negotiation phase 2470 ( Fig.24 ) and / or preparation phase 2450 (combined Fig.24 discuss).

[0309] Fig.24 is a signal flow diagram illustrating an example process for creating an NSSI with directory capability open, shown generally at 2400 . Fig.24 Continued from Fig.23 .

[0310] First, the result of the policy establishment 2337 is evaluated. If the 3GPP entity 2101 refuses to create the NSI, the negotiation phase 2470 may be entered. Otherwise, the preparation phase 2440 is entered.

[0311] During the negotiation phase 2470, the rejection is signaled (NSMF 1201 receives a message 2471 rejecting the NSI). In some examples, such a message may provide the reason for the rejection. In some examples, NSMF 1201 evaluates 2472 the reason for the rejection and prepares a response.

[0312] In some examples, NSMF 1201 negotiates to provide options, which may include, but are not limited to, redesign options, modification options, and / or network resource allocation options for existing NSIs. In some examples, negotiation may be facilitated by NSMF 1201 receiving a NegotiateServiceRequireRequest() message 2473a. In response to the message, NSMF 1201 may send a NegotiateServiceRequireResponse() message 2474a.

[0313] If the 3GPP entity 2101 approves the negotiated provisioning options, the NSSMF 1202 may receive an UpdateServiceRequireRequest() message 2475a, in response to which an UpdateServiceRequireResponse() message 2476a is prepared. Subsequently, at 2321, the feasibility phase 2330 is entered.

[0314] In the preparation phase 2440, the 3GPP entity 2101 approves and finalizes 2441 all resource reservations. In some examples, the approval 2441 is a message 2441a similar to the InstantiateNsiRequest (instantiate NSI request) with nstID and instantiateNsiTime as parameters. In some examples, the request 2441 is a different message and may include suitable parameters. In some examples, the 3GPP entity 2101 only sends a response with an ID (which may be an NSTID). In some examples, the approval 2441 may be a ServiceConfirmationRequest message from the CSMF and / or the client to the NSMF 1201. In some examples, the input parameters of the ServiceConfirmationRequest message may include at least one of the following: a serviceConfirmationRequest identifier requesting confirmation of a requested service, and / or serviceConfirmationParameters requesting confirmation of a requested service with suitable parameters, and the output parameter may be a serviceCapability identifier for confirmation (ACK) and / or rejection (NACK) responses.

[0315] Subsequently, NSMF 1201 finalizes 2442a the reservation with its component management entities 2105 and receives a reply 2442b indicating that the reservation was successful. In some examples, NSMF 1201 also receives 2442b information about the reserved entities, including but not limited to the IDs and / or topologies of these entities.

[0316] Subsequently, NSMF 1201 loads 2443 all suitable NSTs and values, and / or NSI descriptors, and / or components of NSI. In some examples, loading 2443 can be triggered by a signal flow 2444 from 3GPP entity 2101. In some examples, signal flow 2444 is a message 2444a similar to OnBoardTemplateRequest (loading template request) with TemplateData parameters. In some examples, TemplateData may include but is not limited to NSST data. If NSMF 1201 does not open NST to 3GPP entity 2101, NSMF 1201 can determine the NST to be loaded. If NSMF 1201 opens NST to 3GPP entity 2101, 3GPP entity 2101 can directly specify the NST to be loaded by specifying templateID.

[0317] In some examples, loading 2443 may include preparations by component management entity 2105 that are triggered by signal flow 2445a from NSMF 1201. In some examples, NSMF 1201 may receive a response 2445b therefrom.

[0318] In some examples, NSMF 1201 may request 1543 NSSMF 1202 to load its NSST, and NSSMF 1202 may then load 2446 and provide its response 1547a, which may include information related to the loaded NSST.

[0319] NSMF 1201 signals 2446 the completion of NST loading and the components of the NST with a response. In some examples, NSMF 1201 may signal the completion of loading 2466 by sending an OnBoardTemplateResponse() message 2446a with templateID and / or templateInfo parameters.

[0320] The NSMF 1201 signals 2447 that the NSI is ready to be in service. In some examples, the signaling may be a ServiceRequireID() message 2447a sent to the 3GPP entity 2101.

[0321] During the onboarding phase 1550, creation and / or onboarding of a new NSSI and / or modification of an existing NSSI is completed 1551, and the NSSI is then ready to be activated.

[0322] The deletion phase 2460 may be initiated by a request 2461 from the 3GPP entity 2101 to the NSMF 1201 to delete the incoming NSI. In response to such a request, the NSMF 1201 prepares to delete 2462 the created NSI, and in the process, may issue requests 2162, 2163 to its component management entity 2105 to delete reserved resources.

[0323] In some examples, the NSMF 1201 updates 2465 its service catalog accordingly to indicate the released resources.

[0324] Fig.25 is a signal flow diagram illustrating an example process for provisioning an NSSI with a directory and capability opening, shown generally at 2500. Fig.11 It is understood that the above provisioning includes a preparation phase 1110 and a service entry phase 1130, which includes creating 1131 (and / or combining Fig.26 Modifications discussed), therefore, in some examples, Fig.16 Can be Fig.23 and the following Fig.24Connected, or Fig.16 Can be Fig.23 and the subsequent Fig.24 (The corresponding part is Fig.26 Partial replacement (not shown)) connected, so should refer to Fig.23 , Fig.24 , and / or Fig.26 .

[0325] Fig.26 12 is a signal flow diagram showing an example process of bringing an NSI into service by modifying an existing NSI. The diagram shows the communication between 3GPP entity 2101, NSMF 1201, NSSMF 1202, and other management systems 2103.

[0326] It should be understood that Fig.26 The process generally shown in 2600 includes an alternative example of a preparation phase and an onboarding phase, which can replace the preparation phase 2440 and the onboarding phase 2450 (corresponding to creating a new NSI). Therefore, it should be understood that the process 2600 is preceded by the discovery phase 2310, the requirements phase 2320, and the feasibility phase 2330, and in addition, there can be a deletion phase 2460 and / or a negotiation phase 2470.

[0327] Process 2600 assumes that an NSI to be modified already exists. Such an NSI may or may not be shared. A shared NSI is an NSI on which other services are deployed. It is conceivable that the previous service has been completed but not yet terminated (see Fig.30 ), so the shared NSI may be in service but not activated (see Fig. 27 ).

[0328] First, the results of the policy establishment 2326 are evaluated. The process 2600 also assumes that the 3GPP entity 2101 approves and finalizes 2641 all resource reservations. In some examples, the approval 2641 is a message 2641a similar to ModifyNsiRequest() with corresponding parameters.

[0329] NSMF 1201 completes the preparation of the network environment by finalizing reservations, updating policies, loading any other functions and / or any other configuration. In some examples, since finalizing all resource reservations includes approving and finalizing reservations for components of the NSI, this may include preparations by component management entity 2105, which are triggered by signal flows 2642a, 2642b from NSMF 1201 and include receiving responses and / or related information 2643a, 2643b therefrom.

[0330] Subsequently, NSMF 1201 finalizes the modification to the NSI. NSMF 1201 sends message 2644 to 3GPP entity 2101 indicating that the NSI is ready to be activated (if not yet activated). In some examples, message 2644 is a message 2644a similar to ServiceRequireID() with suitable parameters. In some examples, NSMF 1201 provides information (including but not limited to NSI ID) and tools (including but not limited to interfaces) for monitoring and reporting fault management, performance management, and / or security management of services deployed on the NSI.

[0331] In the in-service phase 2650, NSMF 1201 activates 2651 the NSI (if not already activated). In some examples, such activation may include testing for validating the NSI. In some examples, such activation may include in-service NSSI. In some examples, such activation may include activation of components of the NSI. In some examples, if the NSI is already activated and used by other services, the activation should not disrupt such services.

[0332] In some examples, NSMF 1201 updates 2652 its service catalog as the network environment and resources change.

[0333] Fig. 27 is a signal flow diagram illustrating an example signal flow for activating a provisioned NSI in the process generally shown at 2700. The figure illustrates communications between 3GPP entities 2101, NSMF 1201, NSSMF 1202, and other management systems 2103.

[0334] refer to Fig.11 , process 2700 corresponds to activation 1141 during the operation phase. In this context, NSI activation may include any action to activate the NSI to provide communication services. NSI activation may trigger NSSI activation.

[0335] Activation 1141 is initiated by a generated or received trigger 2710. Such a trigger 2710 may include, but is not limited to: an internal and / or external timer alarm 2711 indicating activation of the NSI (in some examples, it may be an activateNsiTime() function and / or a TimerDone() function); a request 2712 from the 3GPP entity 2101 to activate the NSI (in some examples, it may be an ActivateNsiRequest() with an nsiID as a parameter); and / or deploying a service 2713 on an existing NSI (e.g. Fig.26In some examples, if a new service is being deployed and the network provider's service catalog information is not provided to the 3GPP entity 2101, the NSI will not receive the nsiID parameter. In some examples, if an open is provided, the NSMF 1201 may receive the nsiID parameter.

[0336] NSMF 1201 identifies any inactive NSSI associated with the NSI and sends message 2721 to NSSMF 1202 to have NSSMF 1202 activate the NSSI. In some examples, assuming sufficient openness, message 2721 is message 2721a similar to ActivateNssiRequest() message with nssiID (if open) and / or activateNssiTime() as parameters.

[0337] NSMF 1201 receives response 2722 indicating that NSSI has been activated. In some examples, response 2722 is a message 2722a similar to an ActivateNssiResponse() message with NssiLifecycleOperationOccurrenceId as a parameter.

[0338] In some examples, NSMF 1201 sends a request 2731 to other management systems to schedule resources for activating the NSI, and receives a response 2732 therefrom.

[0339] Furthermore, NSMF 1201 activates 2741 , 2742 , 2743 the relevant inactive policies at 3GPP entity 2101 and component management entity 2105 .

[0340] If an activation request 2712 is received, the NSMF 1201 sends 2751 a response. In some examples, the response 2751 may be a response 2751a similar to ActivateNsiResponse() with NsLifecycleOperationOccurrenceId as a parameter, which facilitates traceability of the operation. Subsequently, the NSI is activated 2761.

[0341] Fig.28 is a signal flow diagram illustrating an example flow for modifying an operational NSI in the process generally shown at 2800. The figure illustrates communications between 3GPP entities 2101, NSMF 1201, NSSMF 1202, and other management systems 2103.

[0342] refer to Fig.11, process 2800 corresponds to modification 1144 during operation phase 1140. In this context, NSI modification in the operation phase may include multiple workflows, including but not limited to NSI capacity change, NSI topology change, and / or NSI reconfiguration. NSI modification may be triggered by (but not limited to) receiving new NSI related requirements, receiving new communication service requirements, and / or automatically triggered due to NSI regulation. NSI modification may trigger NSSI modification.

[0343] In some examples, NSI deactivation process 2900 ( Fig.29 ) may precede the NSI modification process 2800. In some examples, the NSI activation process 2700 may follow the NSI modification process 2800.

[0344] The modification 1144 is initiated by a generated or received trigger 2810. Such a trigger 2810 may include, but is not limited to: an alarm related to the performance of the NSI and / or its components (as non-limiting examples: reaching data storage capacity, reaching the maximum rate of the network element, and / or network element failure); a request 2812 from the 3GPP entity 2101 to modify a service using the NSI and / or its components (in some examples, a ModifyNsiRequest() message with csiID, cstID, modifyNsiType, modifyNsiData, modifyNsiTime, and / or similar parameters); and / or a specific modification request 2813 (which may be related to the NST, NSST, and / or its attributes). In some examples, if a new service is to be deployed on an existing NSI, then the modification may be followed. Fig.26 process.

[0345] In some examples, if not previously specified, NSMF 1201 begins the modification by determining 2821 the modifications required. This may include determining the modifications to the NSI component (assuming sufficiently open) and / or deriving requirements to request the modifications from component management entity 2105. It will be appreciated that deriving requirements may be envisioned as a way of obtaining requirements, and alternative or other ways of obtaining requirements may be to derive requirements and / or receive requirements.

[0346] Depending on the openness and whether there is an available service catalog, the NSMF 1201 may evaluate 2831 the feasibility of the modification. Otherwise, the NSMF 1201 may issue a modification request 2832, 2833 to the component management entity 2105 and receive a response 2834, 2835 therefrom.

[0347] If the proposed modifications are considered and / or the NSMF 1201 receives a response 2835, 2836 indicating that these modifications are not feasible, the NSMF 1201 can evaluate the reasons for such a conclusion. In some examples, the NSMF 1201 can redesign the proposed modifications 2842. In this way, it may be determined that it is not open enough, in which case the NSMF 1201 can request 2843, 2844 other information from its component management entity 2105 and obtain a response 2845, 2846 therefrom. In some examples, if (in some examples) the NSMF 1201 with the other information believes that there are no feasible modifications, the NSMF 1201 can negotiate 2847, 2848 with the 3GPP entity 2101 to modify the requirements. If the negotiation 2847, 2848 does not result in a feasible solution, the NSMF 1201 can reject the requested modification 2849, and the 3GPP entity 2101 can respond 2850 with a new proposed modification 2851 or cancel 2852 the proposed modification. In the former case, processing returns to feasibility check 2831.

[0348] In some examples, if the modification is triggered by an alarm condition 2811, and no feasible modification is possible, the service on the NSI can be offloaded to other NSIs, and eventually the service can be Fig.30 Terminate NSI and cancel modifications as shown.

[0349] If the suggested modification is deemed feasible, in some examples, responses 2845, 2846 may include, but are not limited to, resource reservations and / or information related to the NSI component (including, but not limited to, the NSSI ID).

[0350] In some examples, if the modification is triggered 2812, 2813 by a request from the 3GPP entity 2101, the NSMF 1201 may send a response 2861 indicating that the proposed modification design is feasible to the 3GPP entity 2101. In some examples, the response 2861 may include detailed information about the modified NSI component (including but not limited to topology, NSSI ID, and / or remaining capabilities of NFV).

[0351] In some examples, if other policies are to be established and / or activated, NSMF 1201 sends messages 2862, 2863, 2864 to the 3GPP entity and component management entity 2105.

[0352] In some examples, the 3GPP entity 2101 may send 2871 a message approving the modification to the NSMF 1201. Thus, in some examples, the NSMF 1201 sends messages 2872, 2873 to the component management entities 2105 approving the modification by these management entities.

[0353] If a modification request is received, a response may be prepared. In some examples, NSMF 1201 may send a ModifyNsiResponse() message with a parameter lifecycleOperationOccurrenceCsId. This may facilitate traceability of the operation.

[0354] In some examples, if the modification is triggered 2812, 2813 by a request from the 3GPP entity 2101, the NSMF 1201 may send a response 2881 to the 3GPP entity 2101 indicating that the modification has been completed. The NSI has been modified 2891.

[0355] Therefore, the NSI has been modified.

[0356] One of ordinary skill in the relevant art will appreciate that similar processing may be performed and appropriate modifications may be made to implement modifications to the NSSI, which modifications may be apparent to one of ordinary skill in the relevant art by considering the drawings and discussion herein.

[0357] Fig.29 is a signal flow illustrating an example signal flow for deactivating an activated NSI in the process generally shown at 2900. The figure illustrates the communication between 3GPP entities 2101, NSMF 1201, NSSMF 1202, and other management systems 2103.

[0358] refer to Fig.11 , process 2900 corresponds to deactivation 1145 during operation phase 1140. In this context, NSI deactivation includes any action that causes an NSI to be inactive and not provide any communication services. NSI deactivation can trigger NSSI deactivation to deactivate component NSSIs that are not used by other NSIs. In some examples, it may be decided to retain the NSI (not terminated) after deactivation and reactivate the NSI when a new communication service request is received.

[0359] Deactivation 1145 is initiated by a generated or received trigger 2910. Such a trigger 2910 may include, but is not limited to: an internal and / or external timer alarm 2911 indicating deactivation of the NSI (in some examples, it may be a deactivateNsiTime() function and / or a TimerDone() function); a request 2912 from the 3GPP entity 2101 to deactivate the NSI (in some examples, it may be a DeactivateNsiRequest() with an nsiID as a parameter); and / or removing the service from the NSI 2913. In some examples, if the NSSI is being shared, other services on the NSI are deployed to other NSSIs without interruption.

[0360] NSMF 1201 begins deactivation 2921 by identifying whether the service should be rerouted, as a non-limiting example, without interrupting the ongoing service if there are other services using the slice. This may trigger a Fig.26 NSI modification to direct existing services to existing slices, and / or trigger Fig.24 Create an NSI and deploy existing services on the new NSI.

[0361] NSMF 1201 identifies the activated NSI associated with the NSI being deactivated and sends a request 2931 to NSSMF 1202 to deactivate the identified NSI. In some examples, request 2931 may be a response 2931a similar to a DeactivateNssiRequest() message with a nssiID (if open) parameter. In some examples, request 2931 may be a request similar to a deactivateNssiTime() message (not shown). In response to the request, NSMF 1201 may receive a message 2932 confirming that the NSSI has been deactivated. In some examples, response 2932 may be a message 2932a similar to a DeactivateNssiResponse() message with a NssiLifecycleOperationOccurrenceId parameter. If the NSSI is shared, other services on the NSSI are deployed to other NSSIs without interruption, otherwise, process 2900 is rejected.

[0362] In some examples, NSMF 1201 may send a notification 2941 to other management systems 2103 of the network after preparing to deactivate the NSI. As a non-limiting example, other management systems 2103 may be requested to cause the TN manager to release resources previously allocated to the NSI. In some examples, the notification 2941 may be accompanied by information. In some examples, the notification 1941 causes a response or reply 2944 from another management system 2103.

[0363] Fig.30 21 is a signal flow illustrating an example signal flow for terminating an activated NSI in the process generally shown at 3000. The figure illustrates communications between 3GPP entities 2101, NSMF 1201, NSSMF 1202, and other management systems 2103.

[0364] refer to Fig.11 , process 3000 corresponds to termination 1151 during the decommissioning phase 1150.

[0365] Termination 1151 is initiated by a generated or received trigger 3010. Such a trigger 3010 may include, but is not limited to: an internal timer alarm and / or policy 3011 indicating termination of the NSI (in some examples, it may be a TimerDone() function); a request 3012 from the 3GPP entity 2101, another NSMF (not shown), or a CSMF (not shown) (as non-limiting examples) to terminate the NSI because it is no longer necessary to support a particular service (in some examples, it may be TerminateNsiRequest() with nsiID as a parameter); and / or removing the service from the NSI 3013. In some examples, if the trigger 3010 is a request 3012, the NSMF 1201 may decide to terminate the NSI only based on Fig.26 Modify the NSI instead of terminating it.

[0366] NSMF 1201 begins termination 3021 by identifying whether the NSI or any related NSSI is active. If so, Fig.19 and / or Fig.29 Deactivate it. Otherwise, terminate it. NSMF 1201 identifies the activated NSSI associated with the NSI being terminated, and sends a request 3031 to NSSMF 1202 to deactivate and / or terminate the identified NSSI. In some examples, request 3031 may be a request 3031a similar to a DeactivateNssiRequest() message and / or a TerminateNssiRequest() message with NssiLifecycleOperationOccurrenceId and / or nssiID parameters. In some examples, the NSMF may send a service offload request 3032 to NSSMF 1202. In some examples, the service offload request 3032 may be a message similar to an Offloadservice() message with a serviceID parameter. In response to the request, NSMF 1201 may receive a response 3033. In some examples, response 3033 may be message 3033a similar to a DeactivateNssiResponse() message and / or a TerminateNssiResponse() message (with a NssiLifecycleOperationOccurrenceId parameter).

[0367] In some examples, the NSMF 1201 can send a notification 3041 to the other management systems 2103 to release any resource allocations. In some examples, the notification 3041 causes a response or reply 344 from the other management systems 2103.

[0368] In addition, the loaded NST may be unloaded. In some examples, if the NST and / or NSST is loaded, the NSMF 1201 sends 3051 , 3052 , 3053 unloading requests to the NSSMF 1202 , the 3GPP entity 2101 , and the component management entity 2105 .

[0369] In some examples, NSMF 1201 may uninstall 3061 the NST template it has and / or send a message to NSSMF 1202 to uninstall 3062 the NSST template it has.

[0370] If a termination request 3012 is received, the NSMF 1201 sends 3071 a response. In some examples, the response 3061 may be a response 2961a similar to a TerminateNsiResponse() message with a NsiLifecycleOperationOccurrenceId parameter that facilitates traceability of the operation. Subsequently, the NSI is terminated 3071.

[0371] In addition, NSMF 1201 deactivates 2951 , 2952 , 2953 relevant policies at NSSMF 1202 , 3GPP entity 2101 , and component management entity 2105 .

[0372] If a deactivation request 2912 is received, the NSMF 1201 sends 2961 a response. In some examples, the response 2961 may be a response 2961a similar to a DeactivateNsiResponse() message with a NsiLifecycleOperationOccurrenceId parameter that facilitates traceability of the operation. Subsequently, the NSI is deactivated 2971.

[0373] Method Actions

[0374] Now go to Fig.31 , showing a flowchart of example actions for provisioning a network slice, shown generally at 3100.

[0375] One example action 3110 is discovering resources and / or capabilities of a network.

[0376] An example action 3120 is a request to export a slice.

[0377] An example action 3130 is to check the feasibility of the slicing requirements.

[0378] An example action 3140 is to prepare the network environment for slicing.

[0379] An example action 3150 is to serve a slice.

[0380] the term

[0381] The terms "including" and "comprising" are used in an open-ended manner and should be interpreted as meaning "including but not limited to". The terms "example" and "exemplary" are used only to indicate examples for illustrative purposes and should not be interpreted as limiting the scope of the present invention to the above examples. In particular, the term "exemplary" should not be interpreted as indicating or conferring any laudatory, advantageous, or other quality to the expression in which it is used, whether in design, performance, or other aspects.

[0382] The terms "coupled" and "in communication" in any form are intended to mean either a direct connection, whether optical, electrical, mechanical, chemical, or other means, or an indirect connection through some interface, device, intermediary, or connection.

[0383] Unless otherwise indicated, references to the singular include the plural and vice versa.

[0384] As used herein, relational terms such as "first" and "second" and numbered devices such as "a", "b", etc. may be used solely to distinguish one entity or unit from another entity or unit and do not necessarily require or imply any physical or logical relationship or order between these entities or units.

[0385] Overview

[0386] All descriptions of the principles, aspects, and embodiments of the present disclosure and their specific examples recorded herein are intended to include their structural and functional equivalents. In addition, such equivalents are intended to include currently known equivalents and equivalents developed in the future, i.e. any unit that performs the same function regardless of structure.

[0387] It should be understood that the present disclosure can be modified by omitting, adding, or replacing the above-mentioned units with equivalent functional units, and the present disclosure provides multiple applicable inventive concepts that can be implemented in various specific contexts. The specific embodiments discussed are only to illustrate the specific ways to make and use the present disclosure, and do not limit the scope of the present disclosure. On the contrary, the general principles set forth herein are only regarded as an illustration of the scope of the present disclosure.

[0388] Obviously, with reference to this specification, various modifications and variations including substitutions, modifications, and equivalents may be made to the embodiments disclosed herein without departing from the present disclosure as defined in the appended claims, which will be apparent to those skilled in the relevant art.

[0389] Accordingly, the specification and examples disclosed herein are considered to be exemplary only, with the true scope of the disclosure being indicated by the claims.

Claims

1. A method for allocating a slice instance of a communication network, the method comprising: a requirement for the management function to obtain the slice instance, wherein the slice instance is a network slice subnet instance (NSSI) of a network slice subnet (NSS) of a network, the NSSI being based on a network slice subnet template (NSST); The management function checks the feasibility of the slice instance requirements based on network resources and / or network capabilities; Determining that it is feasible to reuse an existing slice instance based on the slice instance requirements, the management function preparing a network environment for the slice instance, wherein preparing the network environment includes reserving resources for supporting the slice instance or a network function of the slice instance by sending a resource reservation request to a component management entity; Otherwise, the management function negotiates with the 3GPP entity provisioning options for the existing NSSI, wherein the provisioning options include redesign or modification of the existing NSSI, wherein the modification includes modifying capacity, topology, and reconfiguration of the existing NSSI; and The management function serves the slice instance.

2. The method according to claim 1, wherein: Obtaining the requirement for the slice instance includes deriving the requirement and / or receiving the requirement.

3. The method according to claim 1, wherein: The requirement to obtain the slice instance includes receiving a request for allocation of the slice instance from a 3GPP entity.

4. The method according to claim 3, wherein: The 3GPP entity is one or more of: a client, a network slice management function (NSMF), a network slice subnet management function (NSSMF), and a communication service management function (CSMF). 5 . The method according to claim 1 , further comprising the management function discovering resources of the network and / or capabilities of the network.

6. The method according to claim 5, wherein: Discover the service catalog including maintenance capabilities.

7. The method according to claim 5, wherein: Discovery includes querying a component management entity for resources and / or capabilities of the component management entity.

8. The method according to claim 6, wherein: The component management entity is one or more of the following: a network slice management function (NSMF), a network slice subnet management function (NSSMF), a network function virtualization (NFV) management and operation (MANO) function, a domain manager (DM), an element manager (EM), and a transport network (TN) manager.

9. The method according to claim 5, wherein: Discovery includes subscribing to a component management entity for updates, wherein the updates indicate remaining resources and / or remaining capabilities.

10. The method according to claim 1, further comprising the management function abstracting resources of the network and / or capabilities of the network.

11. The method according to claim 1, wherein: Preparing a network environment for the slice instance includes reserving network resources for allocation to the slice instance.

12. The method according to any one of claims 1 to 11, wherein: The management function is the Network Slice Subnet Management Function (NSSMF).

13. The method according to any one of claims 1 to 11, wherein: The slice instance is a network slice subnet instance (NSSI) including at least one network slice subnet (NSS).

14. The method according to any one of claims 1 to 11, wherein: The slice instance is a network slice instance (NSI) of a network slice (NS) of the network.

15. The method according to claim 14, wherein: The NSI is based on the Network Slice Template (NST).

16. The method according to any one of claims 1 to 11, wherein: The management function is the Network Slice Management Function (NSMF).

17. The method according to any one of claims 1 to 11 and 15, wherein: Serving the slice instance includes creating a new slice instance.

18. The method according to any one of claims 1 to 11 and 15, wherein: Serving the slice instance includes modifying an existing slice instance.

19. The method according to claim 18, wherein: The existing slice instance is a shared slice instance.

20. The method according to any one of claims 1 to 11, 15, and 19 also includes the management function deleting the slice instance entering the service.

21. The method according to any one of claims 1 to 11, 15, and 19 further includes one or more of the following: configuring, establishing, and updating the strategy of the slice instance.

22. The method according to claim 21 also includes configuring or establishing a policy control function for implementing the policy of the slice instance.

23. A method for processing a request for a slice instance of a communication network, the method comprising: a requirement for the management function to obtain the slice instance, wherein the slice instance is a network slice subnet instance (NSSI) of a network slice subnet (NSS) of a network, the NSSI being based on a network slice subnet template (NSST); The management function checks the feasibility of the slice instance request based on network resources and / or network capabilities, wherein checking the feasibility of the slice instance request includes determining whether the request is feasible; Determining that it is feasible to reuse an existing slice instance based on the slice instance requirements, the management function preparing a network environment for the slice instance, wherein preparing the network environment includes reserving resources for supporting the slice instance or a network function of the slice instance by sending a resource reservation request to a component management entity; Otherwise, the management function negotiates provisioning options for the existing NSSI with the 3GPP entity, wherein the provisioning options include redesign or modification of the existing NSSI, wherein the modification includes modifying capacity, topology, and reconfiguration of the existing NSSI.

24. The method of claim 23, further comprising checking one or more of the following: The feasibility of the Network Slice Subnet Instance (NSSI) requirements in terms of network resources and / or network capabilities; The feasibility of reusing the existing NSSI to provide the slice instance; Creating a new NSSI to provide feasibility of the slice instance; as well as Decommission the existing NSSI to provide feasibility of the slice instance.

25. The method according to claim 24 also includes obtaining other capability information from one or more component management entities, and checking the feasibility of the slice instance requirement or the NSSI requirement based on the obtained other capability information.

26. The method of claim 23, wherein: Checking the feasibility of the slice instance requirement includes determining one or more of the following: feasibility of reusing an existing network slice instance or an existing network slice subnet instance to provide the slice instance; Modify and reuse the existing network slice instance or the existing network slice subnet instance to provide feasibility of the slice instance; The feasibility of creating the slice instance as a new network slice instance or a new network slice subnet instance.

27. The method according to any one of claims 23 to 26 further includes verifying the feasibility of the slice instance requirement using the latest service catalog information.

28. The method of claim 23, wherein: Sending the resource reservation request is performed in response to receiving another resource reservation request from another entity.

29. The method of claim 23, further comprising: The management function obtains a trigger to terminate the slice instance or a network slice subnet instance (NSSI) of the slice instance, the management function being responsible for the slice instance; as well as Terminate the slice instance, components of the slice instance, or the network slice subnet instance (NSSI) of the slice instance.

30. The method of claim 29, wherein: Terminating the slice instance or the NSSI includes: Receive a slice instance termination request; sending a response to the slice instance termination request; and One or more processes are called to terminate one or more of: the slice instance, the components of the slice instance, and the NSSI.

31. The method according to claim 29 or 30 also includes releasing resources held by one or more component entities for supporting the slice instance.

32. The method according to claim 29 or 30, further comprising: Receive a slice instance termination request; Determining whether to satisfy the slice instance termination request; When it is determined that the slice instance termination request will be satisfied, calling one or more processes for terminating the slice instance; When it is determined that the slice instance termination request will not be satisfied, the slice instance is modified rather than terminated.

33. The method of claim 23, further comprising: receiving a request to modify the slice instance during an operation phase of the slice instance; as well as The slice instance is modified according to the request.

34. The method of claim 33, wherein: The slice instance modification triggers modification of the network slice subnet instance (NSSI) of the slice instance.

35. The method according to claim 33 or 34 also includes determining the feasibility of modifying the slice instance, and modifying the slice instance only when the determination indicates that modifying the slice instance is feasible.

36. The method according to claim 33 or 34 also includes subsequently sending a response indicating that the request is feasible or indicating that the slice instance has been modified according to the request.

37. The method of claim 23, further comprising: The Network Slice Subnet Management Function (NSSMF) obtains information from one or more component management entities and / or one or more other NSSMFs.

38. The method of claim 37, further comprising requesting an openness from the one or more component management entities prior to obtaining the information.

39. The method according to claim 37 or 38, wherein: Discovering network resources is performed prior to allocating the slice instance, or wherein discovering network resources is performed during allocating the slice instance.

40. A method of supporting provisioning of a slice instance of a communication network, the slice instance comprising a network slice subnet instance (NSSI), the method comprising, In the admin function: discovering resources and / or capabilities of the network; exporting a requirement for said slice instance; Checking the feasibility of the slice instance requirement based on the network resources and / or capabilities; Determining that it is feasible to reuse an existing slice instance based on the slice instance requirements, the management function preparing a network environment for the slice instance, wherein preparing the network environment includes reserving resources for supporting the slice instance or a network function of the slice instance by sending a resource reservation request to a component management entity; Otherwise, the management function negotiates provisioning options for the existing NSSI with the 3GPP entity, wherein the provisioning options include redesign or modification of the existing NSSI, wherein the modification includes modifying capacity, topology, and reconfiguration of the existing NSSI.

41. The method according to claim 40 also includes a network slice subnet management function (NSSMF) initiating deactivation of the slice instance and / or one or more component network slice subnet instances (NSSI) of the slice instance.

42. The method according to claim 41, wherein: Termination of the slice instance triggers termination or deactivation of one or more component NSSIs.

43. The method of claim 41, wherein: At least one of the component NSSIs is managed by a management entity other than the NSSMF, and wherein deactivating the at least one of the component NSSIs comprises sending a deactivation request from the NSSMF to the management entity other than the NSSMF.

44. The method of claim 40, wherein: The slice instance includes a network slice subnet instance (NSSI), and the method further includes: In the admin function: Receiving a trigger to deactivate the slice instance and / or one or more constituent network slice subnet instances (NSSIs) of the slice instance; In response to the trigger, determining whether to perform deactivation; When it is determined that the deactivation is to be performed, initiating deactivation of the slice instance and / or the one or more component network slice subnet instances (NSSIs) of the slice instance; When it is determined not to perform the deactivation, the slice instance and / or the one or more component network slice subnet instances (NSSI) of the slice instance are modified instead of deactivated.

45. The method of claim 44, further comprising: receiving a request to modify a network slice subnet instance (NSSI) associated with the slice instance; determining feasibility of the request to modify the NSSI; When the determination indicates that modifying the NSSI is feasible, modifying the NSSI according to the request; as well as When the determination indicates that modifying the NSSI is feasible, a response is sent indicating that the request is feasible or indicating that the NSSI has been modified according to the request.

46. ​​The method of claim 45, wherein: The NSSI modification triggers modification of another component NSSI of the NSSI and / or a component network function (NF) instance supporting the NSSI.

47. The method of any one of claims 44 to 46, further comprising the management function providing one or more of the following to subscribing customers: resources of the network, the capabilities of the network, and associated templates.

48. The method of claim 47, wherein: The capabilities of the network include types of services that the network can provide.

49. A network management function comprising: processor; A non-transitory memory for storing machine-readable and machine-executable instructions which, when executed by the processor, cause the network management function to perform a method according to any one of claims 1 to 48.

Images