阅读说明：本技术 动态网络能力配置 (Dynamic network capability configuration ) 是由 李鸿堃 M·F·斯达西尼克 R·迪吉罗拉莫 C·M·姆拉丁 陈卓 D·N·西德 J·L· 于 2020-03-13 设计创作，主要内容包括：描述了用于在基于服务的网络中配置所需的网络能力的方法和设备,包括用于UE发起基于网络能力的注册以配置其所需的网络能力的方法,用于在UE已经注册到网络并且想要动态重新配置它们的网络能力时UE发起基于网络能力的注册更新的方法,和用于基于网络能力的UE配置更新的方法,该方法允许NF或AS发起对用于UE的网络切片中的网络能力的更新。(Methods and apparatus are described for configuring required network capabilities in a service-based network, including methods for a UE to initiate a network capability-based registration to configure its required network capabilities, methods for a UE to initiate a network capability-based registration update when UEs have registered with the network and want to dynamically reconfigure their network capabilities, and methods for a network capability-based UE configuration update that allow an NF or AS to initiate an update to network capabilities in a network slice for the UE.)

1. An apparatus implementing a first network function, the apparatus comprising a processor and a memory, the memory storing instructions that, when executed by the processor, cause the apparatus to perform a plurality of operations comprising:

receiving a first message from a user equipment through a first network function, wherein the first message indicates that an operation to be performed through a network slice is requested;

sending, by the first network function, a second message to a second network function, wherein the second message indicates a request for a determination of whether a threshold related to the operation is satisfied;

receiving, by a first network function, a first response from a second network function, the first response indicating a determination of whether a threshold value is satisfied; and

sending, by the first network function, a second response to the user equipment, the second response including an indication of whether the operation is allowed.

2. The apparatus of claim 1, wherein the operation comprises at least one of: slice registration, or protocol data unit PDU session establishment.

3. The apparatus according to claim 1, wherein the first network function comprises an access and mobility management function, AMF.

4. The apparatus according to claim 1, wherein the second network function comprises a network capability management function, NCMF.

5. The apparatus of claim 1, wherein the threshold is associated with at least one of a maximum number of user equipments that can be registered with the network slice or a maximum number of PDU sessions that can be established with the network slice.

6. The apparatus of claim 1, wherein the operation comprises slice registration, and wherein the second response comprises an indication to reject the operation because the network slice has reached a maximum number of registered UEs.

7. The apparatus of claim 1, wherein the operation comprises a PDU session setup, and wherein the second response comprises an indication to reject the operation because the network slice has reached a maximum number of PDU sessions.

8. The apparatus of any of claims 6 or 7, wherein the second response comprises an indication of an amount of time the user equipment will wait before sending further messages indicating a request for an action to be performed.

9. The apparatus of any of claims 6 or 7, wherein the instructions further cause the apparatus to send a non-access stratum, NAS, message to the UE, the NAS message including an indication that the UE is capable of sending other messages, the other messages indicating a request for an operation to be performed.

10. A user equipment, UE, comprising a processor and a memory, the memory storing instructions that, when executed by the processor, cause the UE to perform operations comprising:

sending a first message to a network function, the first message indicating that an operation to be performed over a network slice is requested, wherein the operation comprises one of slice registration or protocol data unit, PDU, session establishment; and

receiving a response from the network function, the response comprising one of: an indication to deny the operation because the network slice has reached a maximum number of registered UEs, or an indication to deny the operation because the network slice has reached a maximum number of PDU sessions.

11. The user equipment according to claim 10, wherein said network functions comprise an access and mobility management function, AMF.

12. The user equipment of claim 10, wherein the response further comprises an indication of an amount of time the user equipment will wait before sending other messages indicating a request for an action to be performed.

13. The user equipment of claim 12, wherein the instructions further cause the UE to send an additional message indicating the request for the action to be performed after the expiration of the amount of time.

14. The user equipment of claim 10, wherein the instructions further cause the UE to terminate slice registration based on the response.

15. The user equipment of claim 10, wherein the instructions further cause the UE to terminate the PDU session based on the response and to send a further message indicating a request for an action to be performed.

16. The user equipment of claim 10, wherein the instructions further cause the UE to:

receiving a non-access stratum (NAS) message from the network function, the NAS message including an indication that the operation can be requested again; and

sending, in response to the NAS message, a further message indicating a request for an operation to be performed.

Background

The third generation partnership project (3GPP) developed technical standards for cellular telecommunications network technology including radio access, core transport network and service capabilities-including work on codecs, security and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE-Advanced standards. The 3GPP has begun working on the standardization of the next generation cellular technology called New Radio (NR) (also known as "5G").

The 5G core network (5GC) includes a service-based architecture (SBA) based on the concept of network slicing and virtualized Network Functions (NF). Different network functions, such as access and mobility management functions (AMFs), Session Management Functions (SMFs), and Policy Control Functions (PCFs), provide different network function services via a service-based interface. This means that the service consumer can use the same messages and the same procedures to communicate with the service provider. For example, any NF may subscribe to the same event with an event open service provided by the AMF. On the other hand, various network capabilities such as non-IP data transfer (NIDD), Background Data Transfer (BDT), and Power Save Mode (PSM) may be implemented by a set of NF services. Under the current SBA framework, a UE may configure and access a network with Network Slice Selection Assistance Information (NSSAI) indicating a request to identify a network slice. The UE has no way to directly indicate the required network capabilities.

Disclosure of Invention

Although under the current SBA framework of 5GC, the UE can configure and access the network by NSSAI indicating a request to identify a network slice, the UE has no way to directly indicate the required network capabilities.

Methods and apparatus for configuring required network capabilities in a service-based network are disclosed herein.

In one aspect, a new framework is described that includes a network capability layer. The UE and AS may dynamically request network capabilities (e.g., background data transfer, non-IP data transfer) to support their applications. In one implementation, the UE and AS may not need to know or care which network slice supports the requested network capabilities, or whether the serving network slice is capable of supporting the requested network capabilities. The core network entity may determine and configure a network slice that supports all requested network capabilities.

In yet another aspect, a method for a UE to initiate a network capability based registration to configure its required network capabilities is described.

In yet another aspect, a method for a UE to initiate a network capability based registration update when the UE has registered with a network and wants to dynamically reconfigure their network capabilities is described.

In another aspect, a method for network capability based UE configuration update is described that allows a NF or application server to initiate an update to network capabilities in a network slice for a UE.

An extended service-based architecture is also described that includes an interface to a User Plane Function (UPF) and services provided by the UPF.

A mechanism by which the network can communicate network capability information called Network Capability Profile (NCP) of a network slice to the UE.

A method in which a network may inform a UE of alternative network slices with comparable network capability profiles based on network capabilities requested by the UE. A mechanism for a UE to initiate a network capability based registration to configure its required network capabilities.

A mechanism by which a UE may receive a set of allowed NSSAIs and their corresponding NCPs during a general UE registration procedure. If the capabilities indicated by the received NCP are not sufficient for the application in the UE, the UE may be able to request an alternative network slice based on the NCP list of allowed S-NSSAIs received from the core network.

A mechanism by which NCP of a network slice is transmitted to a UE as part of the UE policy during a UE policy update procedure.

A mechanism by which the core network enforces a maximum number of PDU sessions per network slice during the PDU session establishment procedure and handles requests received after a maximum limit is reached.

A mechanism where the core network handles a maximum limit on the number of PDU sessions per network slice, where the network regularly informs the UE through NAS messages that the network slice has reached its maximum limit so that the UE can wait before reattempting.

A mechanism by which the core network enforces a maximum number of UE registrations per network slice and processes registration requests received after a maximum limit is reached.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to addressing any or all of the disadvantages noted in any part of this disclosure.

Drawings

A more detailed understanding can be obtained from the following description, given by way of example in conjunction with the accompanying drawings, in which:

FIG. 1A illustrates an example communication system;

fig. 1B is a block diagram of an example apparatus or device, such as a wireless transmit/receive unit (WTRU), configured for wireless communication;

fig. 1C is a system diagram of an example Radio Access Network (RAN) and core network;

fig. 1D is a system diagram of another example RAN and core network;

fig. 1E is a system diagram of another example RAN and core network;

fig. 1F is a system diagram of another example RAN and core network;

FIG. 1G is a block diagram of an example computing system in which nodes, entities, devices or other apparatus of a communication system may be incorporated;

FIG. 2A shows a non-roaming 5G reference architecture with a service-based interface to the control plane;

FIG. 2B shows a non-roaming 5G system architecture in reference point representation;

FIG. 3 shows an example of network functions, NF services and NF service operations;

FIG. 4 shows an example of a "request-response" NF service;

FIG. 5 shows an example of a "subscribe-notify" NF service;

FIG. 6 illustrates a network capability configuration use case;

FIG. 7 illustrates an example network architecture with a network capability layer;

FIG. 8 illustrates a method for network capability based registration;

FIG. 9 illustrates a method for network capability based registration update;

FIG. 10 illustrates a method for network capability based UE configuration update;

figure 11 shows a service-based architecture with example extensions of the UPF and Nupf interfaces; and

FIG. 12 shows an example Graphical User Interface (GUI) for configuring network capabilities in a communication network.

Fig. 13 illustrates a method of using a registration process for a network capability profile for a requested NSSAI.

Fig. 14 illustrates a method of communicating a network capability profile to a UE as part of the UE policy.

Fig. 15 illustrates a method for handling a maximum number of PDU sessions in a network slice by a network.

Fig. 16 illustrates a method of handling a maximum number of PDU sessions in a network slice using NAS notification.

Fig. 17 shows a process of handling a maximum UE number limit in a network slice.

Figure 18 represents an example Graphical User Interface (GUI) showing a UE receiving an NCP from a network and either accepting the NCP or being able to request a new NCP.

Detailed Description

The following is a list of acronyms that may appear in the following description. Unless otherwise indicated, acronyms used herein refer to corresponding terms listed below.

5GC 5G core

AF application function

AMF access and mobility management functionality

AS application server

CN core network

CP control plane

DL downlink

DNN data network name

EPC evolved packet core

GUTI globally unique temporary identifier

LTE Long term evolution

MBMS multimedia broadcast/multicast service

MME mobility management entity

NAS non-access stratum

NCMF network capability management function

NCP network capability profile

NEF network open function

NF network function

NIDD non-IP data transport

NRF NF storage function

NSSAI network slice selection assistance information

NSSF network slice selection function

NSI network slice example

PCF policy control function

PDU protocol data unit

PSM Power saving mode

QoS quality of service

RAN radio access network

PLMN public land mobile network

SBA service-based architecture

SCS service capability server

SD slice specifier

SM session management

SMF session management function

SMSF Short Message Service (SMS) functionality

S-NSSAI Single network slice selection assistance information

SST slice/service type

SUPI subscription permanent identifier

UDM/UDR unified data management/unified data storage

UE user equipment

UL uplink

UPF user plane functionality

The following terms may have the following meanings:

"core network" refers to the central or core portion of a telecommunications network that provides a number of communication services for customers interconnected by radio access networks. The core network typically comprises a plurality of entities performing the functions of the core network. The term "core network entity" as used herein refers to any entity that performs the functions of the core network, such as AMF, UDR/UDSF, UDM/UDR, NRF, NEF, PCF, NF, SMF, AUSF, NSSF, etc., as described herein. It should be understood that such core network entities may be logical entities implemented in the form of software (i.e., computer-executable instructions) stored in a memory of a device or computer system configured for wireless and/or network communication, such as the one shown in fig. 1B or 1G, and executed on a processor of the device or computer system.

"Network Function (NF)" refers to a processing function in a network that has a defined functional behavior and defined interfaces. The NF may be implemented as a network element on dedicated hardware, or as a software instance running on dedicated hardware, or as a virtualization function instantiated on a suitable platform (e.g., on a cloud infrastructure).

"network function instance" refers to an identifiable instance of an NF.

A "Network Function (NF) service" may be a type of capability opened by an NF ("NF service provider") to an otherwise authorized NF ("NF service consumer") through a service-based interface. A network function may open one or more NF services. For example, the 5G AMF provides a Namf _ EventExposure service, which enables the AMF to send notifications to NFs that subscribe to certain mobility management related events.

"NF service instance" refers to an identifiable instance of an NF service.

"network capabilities" include transport network features that are implemented by the core network and provided to its users (e.g., UEs or application servers). Examples of network capabilities include background data transfer and event monitoring. The network capabilities are enabled by one or more NF services of the one or more NFs.

A "network slice" is a logical network that provides specific network capabilities and network characteristics.

A "network slice instance" includes the required resources (e.g., computing, storage, and networking resources) and a set of NF instances that form the deployed network slice.

The "network capability profile" is an information profile for each network slice maintained by the NCMF that indicates what network capabilities the network slice supports.

A "network capability management function" is an NF that configures a network slice to provide a UE/AS with a set of required network capabilities. The NCMF may be part of an OAM system.

The third generation partnership project (3GPP) developed technical standards for cellular telecommunications network technology including radio access, core transport network and service capabilities-including work on codecs, security and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE-Advanced standards. The 3GPP has begun working on the standardization of the next generation cellular technology called New Radio (NR) (also known as "5G"). The 3GPP NR standard development is expected to include the definition of the next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 6GHz, and the provision of new ultra mobile broadband radio access above 6 GHz. Flexible radio access is expected to consist of new non-downward compatible radio access in a new spectrum below 6GHz and is expected to include different modes of operation that can be multiplexed together in the same spectrum to address a wide set of 3GPP NR use cases with different requirements. Ultra mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra mobile broadband access for indoor applications and hotspots, for example. In particular, with cmWave and mmWave specific design optimizations, ultra mobile broadband is expected to share a common design framework with flexible radio access below 6 GHz.

The 3GPP identifies various use cases that are expected to be supported by New Radios (NR), resulting in a wide variety of user experience requirements for data rate, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, indoor ultra-high broadband access, broadband access in crowds, 50+ Mbps ubiquitous, ultra-low cost broadband access, mobile broadband in vehicles), emergency communications, large scale machine type communications, network operations (e.g., network slicing, routing, migration and interworking, energy conservation), and enhanced vehicle-to-everything (eV2X) communications. Specific services and applications in these categories include, for example, monitoring and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, first responder connection, automobile emergency calls, disaster alerts, real-time gaming, multi-player video calls, automated driving, augmented reality, haptic internet, and virtual reality, to name a few. All of these and other use cases are contemplated herein.

Fig. 1A illustrates one embodiment of an example communication system 100 in which the methods and apparatus described and claimed herein may be embodied. As shown, the example communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which may be referred to generally or collectively as WTRUs 102), Radio Access Networks (RANs) 103/104/105/103b/104b/105b, a core network 106/107/109, a Public Switched Telephone Network (PSTN)108, the internet 110, and other networks 112, although it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each WTRU102a, 102b, 102c, 102d, 102e may be any type of device or apparatus configured to operate and/or communicate in a wireless environment. Although in figures 1A-1G, each WTRU102a, 102b, 102c, 102d, 102e is depicted as a handheld wireless communication device, it should be understood that, for the wide variety of use cases contemplated with respect to 5G wireless communication, each WTRU may include or be embodied in any type of device or apparatus configured to send and/or receive wireless signals, including, by way of example only, User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a Personal Digital Assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smart watch or smart garment, a medical or electronic health appliance, a robot, an industrial device, a drone, a portable device such as a smart watch or smart garment, a portable device, a mobile device, a cellular telephone, a Personal Digital Assistant (PDA), a wireless sensor, a wireless communication device, and a wireless communication device, and a wireless communication device, a, A vehicle such as a car, truck, train or airplane, and the like.

Communication system 100 may also include base station 114a and base station 114 b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106/107/109, the internet 110, and/or the other networks 112. The base station 114b may be any type of device configured to wiredly and/or wirelessly interface with at least one of RRHs (remote radio heads) 118a, 118b and/or TRPs (transmission and reception points) 119a, 119b to facilitate access to one or more communication networks, such as the core network 106/107/109, the internet 110, and/or other networks 112. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106/107/109, the internet 110, and/or the other networks 112. The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the internet 110, and/or the other networks 112. For example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), Node-bs, eNode bs, Home Node bs (Home Node bs), Home eNode bs (Home eNode bs), site controllers, Access Points (APs), wireless routers, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

The base station 114a may be part of the RAN103/104/105, and the RAN103/104/105 may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. The base station 114b may be part of the RAN103b/104b/105b, and the RAN103b/104b/105b may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. The base station 114a may be configured to transmit and/or receive wireless signals within a particular geographic area, which may be referred to as a cell (not shown). The base station 114b may be configured to transmit and/or receive wired and/or wireless signals within a particular geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into 3 sectors. Thus, in an embodiment, the base station 114a may include 3 transceivers, e.g., one transceiver per sector of a cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) techniques, and thus multiple transceivers may be used for each sector of the cell.

The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., Radio Frequency (RF), microwave, Infrared (IR), Ultraviolet (UV), visible, cmWave, mmWave, etc.) 115/116/117. The air interface 115/116/117 may be established using any suitable Radio Access Technology (RAT).

Base station 114b may communicate with one or more of RRHs 118a, 118b and/or TRPs 119a, 119b over wired or air interfaces 115b/116b/117b, and wired or air interfaces 115b/116b/117b may be any suitable wired (e.g., cable, fiber, etc.) or wireless communication link (e.g., Radio Frequency (RF), microwave, Infrared (IR), Ultraviolet (UV), visible, cmWave, mmWave, etc.). Air interfaces 115b/116b/117b may be established using any suitable Radio Access Technology (RAT).

The RRHs 118a, 118b and/or TRPs 119a, 119b may communicate with one or more of the WTRUs 102c, 102d over air interfaces 115c/116c/117c, which air interfaces 115c/116c/117c may be any suitable wireless communication links (e.g., Radio Frequency (RF), microwave, Infrared (IR), Ultraviolet (UV), visible, cmWave, mmWave, etc.). Air interfaces 115c/116c/117c may be established using any suitable Radio Access Technology (RAT).

More specifically, as described above, communication system 100 may be a multiple-access system that may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a and WTRUs 102a, 102b, 102c in RAN103/104/105, or RRHs 118a, 118b and TRPs 119a, 119b and WTRUs 102c, 102d in RAN103b/104b/105b may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), which may establish the air interface 115/116/117 or 115c/116c/117c using wideband cdma (wcdma), respectively. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (HSPA +). HSPA may include High Speed Downlink Packet Access (HSDPA) and/or High Speed Uplink Packet Access (HSUPA).

In embodiments, the base station 114a and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b and TRPs 119a, 119b in the RAN103b/104b/105b and the WTRUs 102c, 102d may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA) that may establish the air interface 115/116/117 or 115c/116c/117c using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-a), respectively. In the future, air interface 115/116/117 may implement 3GPP NR technology.

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN103/104/105, or the RRHs 118a, 118b and TRPs 119a, 119b and the WTRUs 102c, 102d in the RAN103b/104b/105b may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA 20001X, CDMA2000 EV-DO, interim standard 2000(IS-2000), interim standard 95(IS-95), interim standard 856(IS-856), Global System for Mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and so forth.

The base station 114c in fig. 1A may be, for example, a wireless router, Home Node B, Home eNode B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area (e.g., a business, Home, vehicle, campus, etc.). In an embodiment, the base station 114c and the WTRU102 e may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In an embodiment, the base station 114c and the WTRU102 d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In another embodiment, the base station 114c and the WTRU102 e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-a, etc.) to establish a pico cell or a femto cell. As shown in fig. 1A, the base station 114b may be directly connected to the internet 110. Thus, the base station 114c may not be required to access the internet 110 via the core network 106/107/109.

The RAN103/104/105 and/or the RANs 103b/104b/105b may be in communication with a core network 106/107/109, and the core network 106/107/109 may be any type of network configured to provide voice, data, application, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, etc., and/or perform high-level security functions such as user authentication.

Although not shown in fig. 1A, it should be appreciated that the RAN103/104/105 and/or the RANs 103b/104b/105b and/or the core network 106/107/109 may communicate directly or indirectly with other RANs that employ the same RAT as the RAN103/104/105 and/or the RANs 103b/104b/105b, or a different RAT. For example, in addition to connecting to RAN103/104/105 and/or RAN103b/104b/105b, which may utilize E-UTRA radio technology, core network 106/107/109 may also communicate with other RANs (not shown) that employ GSM radio technology.

The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN108, the internet 110, and/or other networks 112. The PSTN108 may include a circuit-switched telephone network that provides Plain Old Telephone Service (POTS). The internet 110 may include a global system of interconnected computer networks and devices that utilize common communication protocols, such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) in the TCP/IP internet protocol suite. The network 112 may include wired or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include other core networks connected to one or more RANs, which may employ the same RAT as the RAN103/104/105 and/or the RANs 103b/104b/105 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers that communicate with different wireless networks over different wireless links. For example, the WTRU102 e shown in figure 1A may be configured to communicate with a base station 114a, which may employ a cellular-based radio technology, and with a base station 114c, which may employ an IEEE 802 radio technology.

Fig. 1B is a block diagram of an example device or apparatus, such as a WTRU102, configured for wireless communication in accordance with an embodiment illustrated herein. As shown in fig. 1B, an example WTRU102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad/indicator 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU102 may include any subcombination of the above elements while remaining consistent with an embodiment. In addition, embodiments contemplate that base stations 114a and 114B, and/or the nodes that base stations 114a and 114B may represent, such as (but not limited to) Base Transceiver Stations (BTSs), Node-bs, site controllers, Access Points (APs), home Node-bs, evolved home Node-bs (enodebs), home evolved Node-bs (henbs), home evolved Node-B gateways, proxy nodes, and the like, may include some or all of the elements described in fig. 1B and described herein.

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, and the transceiver 120 may be coupled to a transmit/receive element 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

The transmit/receive element 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) over the air interface 115/116/117. For example, in an embodiment, transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive, for example, IR, UV, or visible light signals. In another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF signals and optical signals. It should be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

Additionally, although transmit/receive element 122 is depicted in fig. 1B as a single element, WTRU102 may include any number of transmit/receive elements 122. More specifically, the WTRU102 may employ MIMO technology. Thus, in an embodiment, the WTRU102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.

Transceiver 120 may be configured to modulate signals to be transmitted by transmit/receive element 122 and demodulate signals received by transmit/receive element 122. As described above, the WTRU102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU102 to communicate via multiple RATs (such as UTRA and IEEE 802.11).

The processor 118 of the WTRU102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touchpad/indicator 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to a speaker/microphone 124, a keypad 126, and/or a display/touchpad/indicator 128. In addition, processor 118 may access information from, and store data in, any type of suitable memory, such as non-removable memory 130 and/or removable memory 132. Non-removable memory 130 may include Random Access Memory (RAM), Read Only Memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In an embodiment, the processor 118 may access information from, and store data in, a memory that is not physically located on the WTRU102, such as a memory on a server or home computer (not shown).

The processor 118 may obtain power from the power source 134 and may be configured to distribute power to other components in the WTRU102 and/or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, or the like.

The processor 118 may also be coupled to a GPS chipset 136, which the GPS chipset 136 may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU102 may receive location information from base stations (e.g., base stations 114a, 114b) over the air interface 115/116/117 and/or determine its location based on the timing of the reception of signals from two or more nearby base stations. It should be appreciated that the WTRU102 may acquire location information by any suitable location determination method while still remaining consistent with an embodiment.

The processor 118 may also be coupled to other peripherals 138, which peripherals 138 may include one or more software and/or hardware modules that provide additional features, functionality, and/or a wired or wireless connection. For example, peripheral devices 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photo or video), Universal Serial Bus (USB) ports or other interconnection interfaces, vibration devices, television transceivers, hands-free headsets, portable devices, and the like,A module, a Frequency Modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, etc.

The WTRU102 may be included in other devices or apparatuses such as sensors, consumer electronics, wearable apparatuses such as smart watches or smart clothing, medical or electronic health apparatuses, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes. The WTRU102 may connect to other components, modules, or systems of such devices or apparatuses via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripherals 138.

Fig. 1C is a system diagram of RAN103 and core network 106 according to an embodiment. As described above, the RAN103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. RAN103 may also communicate with core network 106. As shown in fig. 1C, the RAN103 may include Node-bs 140a, 140B, 140C, and each Node-B140 a, 140B, 140C may include one or more transceivers for communicating with the WTRUs 102a, 102B, 102C over the air interface 115. The Node-bs 140a, 140B, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN103 may also include RNCs 142a, 142 b. It should be appreciated that the RAN103 may include any number of Node-bs and RNCs while remaining consistent with embodiments.

As shown in FIG. 1C, the Node-Bs 140a, 140B may communicate with an RNC 142. In addition, Node-B140 c may communicate with RNC 142B. The Node-bs 140a, 140B, 140c may communicate with the respective RNCs 142a, 142B via an Iub interface. The RNCs 142a, 142b may communicate with each other via an Iur interface. Each RNC 142a, 142B may be configured to control the respective Node-B140 a, 140B, 140c to which it is connected. In addition, each RNC 142a, 142b may be configured to perform or support other functions such as outer loop power control, load control, admission control, packet scheduling, handoff control, macro diversity, security functions, data encryption, and the like.

The core network 106 shown in fig. 1C may include a Media Gateway (MGW)144, a Mobile Switching Center (MSC)146, a Serving GPRS Support Node (SGSN)148, and/or a Gateway GPRS Support Node (GGSN) 150. Although each of the above elements are described as part of the core network 106, it should be appreciated that any of these elements may be owned and/or operated by an entity other than the core network operator.

RNC 142a in RAN103 may be connected to MSC 146 in core network 106 via an IuCS interface. MSC 146 may be connected to MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network, such as the PSTN108, to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices.

The RNC 142a in the RAN103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be coupled to a GGSN 150. The SGSN 148 and GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

As described above, the core network 106 may also be connected to the network 112, and the network 112 may include other wired or wireless networks owned and/or operated by other service providers.

Fig. 1D is a system diagram of RAN 104 and core network 107 according to an embodiment. As described above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. RAN 104 may also communicate with a core network 107.

RAN 104 may include eNode-bs 160a, 160B, 160c, although it should be appreciated that RAN 104 may include any number of eNode-bs while remaining consistent with embodiments. The eNode-bs 160a, 160B, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102B, 102c over the air interface 116. In an embodiment, eNode-bs 160a, 160B, 160c may implement MIMO technology. Thus, for example, eNode-B160 a may use multiple antennas to send and receive wireless signals to and from WTRU102 a.

Each eNode-B160 a, 160B, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in fig. 1D, eNode-bs 160a, 160B, 160c can communicate with each other over an X2 interface.

The core network 107 shown in fig. 1D may include a mobility management gateway (MME)162, a serving gateway 164, and a Packet Data Network (PDN) gateway 166. Although each of the above elements are described as part of the core network 107, it should be appreciated that any of these elements may be owned and/or operated by an entity other than the core network operator.

MME 162 may be connected to each of eNode-bs 160a, 160B, and 160c in RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, and so on. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

Serving gateway 164 may be connected to each of eNode-bs 160a, 160B, and 160c in RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102 c. The serving gateway 164 may also perform other functions such as anchoring the user plane during inter-eNode B handovers, triggering paging when downlink data is available to the WTRUs 102a, 102B, 102c, managing and storing the context of the WTRUs 102a, 102B, 102c, and the like.

The serving gateway 164 may also be connected to a PDN gateway 166, which the PDN gateway 166 may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network (such as the internet 110) to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

The core network 107 may facilitate communication with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to a line-switched network, such as the PSTN108, to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, the core network 107 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the network 112, which network 112 may include other wired or wireless networks owned and/or operated by other service providers.

Fig. 1E is a system diagram of RAN 105 and core network 109 according to an embodiment. The RAN 105 may be an Access Service Network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As described further below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105 and the core network 109 may be defined as reference points.

As shown in fig. 1E, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, although it should be appreciated that the RAN 105 may include any number of base stations and ASN gateways while still remaining consistent with embodiments. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In an embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, for example, the base station 180a may use multiple antennas to transmit wireless signals to the WTRU102a and to receive wireless signals from the WTRU102 a. The base stations 180a, 180b, 180c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, etc. The ASN gateway 182 may act as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as the R1 reference point for implementing the IEEE 802.16 specification. In addition, each WTRU102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point that may be used for authentication, authorization, IP host configuration management, and/or mobility management.

The communication link between the various base stations 180a, 180b, and 180c may be defined as the R8 reference point, the R8 reference point including protocols that facilitate WTRU handoffs, as well as the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols that facilitate mobility management based on mobility events associated with the respective WTRUs 102a, 102b, 102 c.

As shown in fig. 1E, RAN 105 may be connected to core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, the R3 reference point including, for example, protocols that facilitate data transfer and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA)184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. Although each of the above elements are described as part of the core network 109, it should be appreciated that any of these elements may be owned and/or operated by an entity other than the core network operator.

The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to a line-switched network, such as the PSTN108, to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices. Additionally, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the network 112, which may include other wired or wireless networks owned and/or operated by other service providers.

Although not illustrated in fig. 1E, it should be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN and the other ASN may be defined as an R4 reference point, which may include protocols for coordinating mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASN. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between the home core network and the visited core network.

The core network entities described herein and illustrated in fig. 1-6 are identified using names assigned to these entities in certain existing 3GPP specifications, although it should be understood that in the future these entities and functions may be identified by other names, and that in future specifications published by 3GPP, including future 3GPP NR specifications, certain entities or functions may be combined. Thus, the particular network entities and functions described and illustrated in fig. 1-6 are provided as examples only, and it is to be understood that the subject matter disclosed and claimed herein may be embodied or carried out in any similar communication system, whether presently defined or defined in the future.

The 5G core network 170 shown in fig. 1F may include an access and mobility management function (AMF)172, a Session Management Function (SMF)174, a User Plane Function (UPF)176, a user data management function (UDM)178, an authentication server function (AUSF)180, a network open function (NEF), a Policy Control Function (PCF)184, a non-3 GPP interworking function (N3IWF)192, and an Application Function (AF) 188. Although each of the above elements are described as part of the 5G core network 170, it should be appreciated that any of these elements may be owned and/or operated by an entity other than the core network operator. It should also be appreciated that the 5G core network may not be comprised of all of these elements, may be comprised of additional elements, and may be comprised of multiple instances of each of these elements. Fig. 1F shows the network functions directly connected to each other, but it should be appreciated that they may communicate via a routing agent (such as a diameter routing agent) or a message bus.

The AMF 172 may be connected to each of the RANs 103/104/105/103b/104b/105b via an N2 interface and may act as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF 172 may generally route and forward NAS packets to and from the WTRUs 102a, 102b, 102 c.

The SMF 174 may be connected to the AMF 172 via an N11 interface, may be connected to the PCF 184 via an N7 interface, and may be connected to the UPF 176 via an N4 interface. SMF 174 may act as a control node. For example, the SMF 174 may be responsible for session management, management and configuration of traffic steering rules in the IP address assignment & UPF 176 of the WTRUs 102a, 102b, 102c, and generation of downlink data notifications.

The SMF 174 may also be connected to a UPF 176, which UPF 176 may provide the WTRUs 102a, 102b, 102c with access to a Data Network (DN)190, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. SMF 174 may manage and configure traffic steering rules in UPF 176 via the N4 interface. The UPF 176 may be responsible for interconnecting Packet Data Unit (PDU) sessions with the data network, packet routing and forwarding, policy rule enforcement, quality of service processing for user plane traffic, and downlink packet buffering.

The AMF 172 may also be connected to the N3IWF 192 via an N2 interface. The N3IWF facilitates connectivity between the WTRUs 102a, 102b, 102c and the 5G core network 170 via radio interface technologies not defined by 3 GPP.

PCF 184 may be connected to SMF 174 via an N7 interface, to AMF 172 via an N15 interface, and to an Application Function (AF)188 via an N5 interface. PCF 184 may provide policy rules to control plane nodes, such as AMF 172 and SMF 174, allowing the control plane nodes to enforce the rules.

The UDM 178 acts as a repository for authentication credentials and subscription information. The UDM may be connected to other functions such as AMF 172, SMF 174, and AUSF 180.

The AUSF 180 performs authentication-related operations, connects to the UDM 178 via an N13 interface, and connects to the AMF 172 via an N12 interface.

The NEF opens capabilities and services in the 5G core network 170. The NEF may connect to the AF 188 via an interface and it may connect to other control plane functions and user plane functions (180, 178, 172, 184, 176 and N3IWF) in order to open up the capabilities and services of the 5G core network 170.

The 5G core network 170 may facilitate communication with other networks. For example, the core network 170 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the 5G core network 170 and the PSTN 108. For example, the core network 170 may include or communicate with a Short Message Service (SMS) service center that facilitates communication via a short message service. For example, the 5G core network 170 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, 102c and a server. In addition, the core network 170 may provide the WTRUs 102a, 102b, 102c with access to the network 112, which may include other wired or wireless networks owned or operated by other service providers.

Fig. 1G is a block diagram of an example computing system 90 that may contain one or more devices of a communication network illustrated or described herein, such as certain nodes or functional entities in RAN103/104/105, core network 106/107/109, PSTN108, internet 110, or other network 112.

The computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever or in any manner such software is stored or accessed. Such computer readable instructions may be executed in the processor 91 to cause the computing system 90 to operate. The processor 91 may be a general-purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 91 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor other than main processor 91 that may perform additional functions or assist processor 91. Processor 91 and/or coprocessor 81 may receive, generate, and process data associated with the methods and apparatus disclosed herein.

In operation, processor 91 fetches, decodes, and executes instructions and transfers information to and from other resources via the computing system's main data transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines a medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is a PCI (peripheral component interconnect) bus.

The memory coupled to system bus 80 includes Random Access Memory (RAM)82 and Read Only Memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. The ROM 93 typically contains stored data that is not easily modified. The data stored in the RAM 82 may be read or changed by the processor 91 or other hardware devices. Access to the RAM 82 and/or ROM 93 may be controlled by a memory controller 92. The memory controller 92 may provide address translation functionality that translates virtual addresses to physical addresses when instructions are executed. The memory controller 92 may also provide memory protection functions that isolate processes within the system and isolate system processes from user processes. Thus, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes is set, it cannot access memory within the virtual address space of other processes.

In addition, the computing system 90 may include a peripheral device controller 83, the peripheral device controller 83 being responsible for communicating instructions from the processor 91 to peripheral devices, such as a printer 94, a keyboard 84, a mouse 95, and a disk drive 85.

The display 86, controlled by a display controller 96, is used to display visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a Graphical User Interface (GUI). The display 86 may be implemented using a CRT based video display, an LCD based flat panel display, a gas plasma based flat panel display, or a touch panel. The display controller 96 includes the electronic components necessary to generate the video signals that are sent to the display 86.

Further, computing system 90 may contain communication circuitry, such as network adapter 97, that may be used to connect computing system 90 to external communication networks (such as RAN103/104/105, core network 106/107/109, PSTN108, internet 110, or other networks 112 of fig. 1-6) to enable computing system 90 to communicate with other nodes or functional entities of these networks. The communication circuitry may be used to perform the transmitting and receiving steps of certain devices, nodes or functional entities described herein, either alone or in combination with the processor 91.

It should be appreciated that any or all of the devices, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which when executed by a processor, such as processor 118 or 91, cause the processor to perform and/or implement the systems, methods, and processes described herein. In particular, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions executed on a processor of a device or computing system configured for wireless and/or wired network communication. Computer-readable storage media include volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information, although such computer-readable storage media do not include signals. Computer-readable storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium which can be used to store the desired information and which can be accessed by a computing system.

Fig. 2A is a block diagram of a non-roaming network architecture for a 5G network with a service-based interface within the control plane of the network. Fig. 2B is a block diagram representing another view of the 5G network of fig. 2A and illustrating reference points through which various network functions interact. Note that the mobility management function and the session management function are separate. The single N1 NAS connection is used for registration management and connection management (RM/CM) and SM related messages and procedures for the UE. The single termination point of N1 is located in the AMF. The AMF forwards SM related NAS information to the SMF. The AMF handles the registration management and connection management part of the NAS signaling exchanged with the UE. The SMF handles the session management part of the NAS signaling exchanged with the UE.

A 5G system architecture is defined to support data connectivity and services, enabling deployments to use technologies such as Network Function Virtualization (NFV) and Software Defined Networking (SDN). The 5G system architecture is designed to leverage service-based interactions between identified Control Plane (CP) network functions.

As mentioned above, NF is a processing function in a network that has a defined functional behavior and defined interfaces. The NF may be implemented as a network element on dedicated hardware, or as a software instance running on dedicated hardware, or as a virtualization function instantiated on a suitable platform, such as on a cloud infrastructure.

As further described above, NF services are a type of capability opened by NFs ("NF service providers") to other authorized NFs ("NF service consumers") through a service-based interface. The NF may open one or more NF services. Typically, NF services provide capabilities to authorized consumers. NFs may provide different capabilities to different consumers, thereby providing different NF services. Each NF service provided by an NF is designed to be self-contained, reusable, and to use management schemes independently of other NF services provided by the same NF, e.g., for scaling, repair, etc. Each NF service is designed to be accessible through an interface. An interface may consist of one or more operations. Figure 3 shows the relationship between NF, NF services and their operation.

The interaction between two network functions (consumer and provider) within such an NF service framework follows two mechanisms:

"request-response": a control plane NF _ B (NF service provider) is requested by another control plane NF _ a (NF service consumer) to provide a certain NF service, which acts and/or provides information. The NF _ B provides NF services based on the request of the NF _ a. To satisfy the request, the NF _ B may in turn consume NF services from other NFs. In this request-response mechanism, communication between two NFs (consumer and provider) is one-to-one, and a one-time response by the provider to a consumer's request is expected to be completed within a certain time frame. Figure 4 shows the flow of the request-response communication mechanism.

"subscribe-notify": a control plane NF _ a (NF service consumer) subscribes to NF services provided by another control plane NF _ B (NF service provider). Multiple control plane NFs may subscribe to the same control plane NF service. The NF _ B notifies the result of the NF service to one or more interested NFs subscribed to the NF service. The subscription request should include a notification endpoint (e.g., a notification URL) of the NF service consumer to which event notifications from the NF service provider should be sent. Additionally, the subscription request may include a notification request for notifications that are periodically updated or that are triggered by some event (e.g., the requested information is changed, a certain threshold is reached, etc.). Figure 5 shows the flow of the subscription-notification communication mechanism.

For example, table 1 shows the results in 3GPP TS23.502, Procedures for the 5G System; stage 2, v15.1.0, Release 15, 2018-03, and AMF service operations.

Table 1: list of AMF services

Network slicing is a mechanism that a mobile network operator can use to support multiple "virtual" networks behind the air interface that span the fixed portion of the mobile operator's network (both backhaul and core networks). This involves "slicing" the network into multiple virtual networks to support different Radio Access Networks (RANs) or different service types running across a single RAN. Network slicing enables operators to create customized networks to provide optimized solutions for different market scenarios requiring different requirements, e.g. in terms of functionality, performance and isolation.

As described above, a network slice may include a logical network that provides particular network capabilities and network characteristics. The network slice within the PLMN includes a core network control plane and a user plane NF. The network slice instance includes the required resources (e.g., computing, storage, and networking resources) and a set of NF instances that form the deployed network slice.

Network slices may differ due to supported characteristics and network function optimizations, in which case such network slices may have different slices/service types. An operator may deploy multiple network slice instances that deliver the same features but for different groups of UEs, e.g., when they deliver different committed services and/or because they are dedicated to customers, in which case such network slices may have the same slice/service type but be distinguished by different slice specifiers.

The network may simultaneously serve a single UE via the 5G-AN with one or more network slice instances associated with up to 8 different total S-NSSAIs, regardless of the access type (i.e., 3GPP access and/or N3GPP access) with which the UE is registered. The AMF instance of the serving UE logically belongs to each network slice instance of the serving UE, i.e., is common to the network slice instances of the serving UE.

The network slice is identified by S-NSSAI, which consists of:

slice/service type (SST), which refers to the expected network slice behavior in terms of features and services;

slice Specifier (SD), which is optional information that supplements a slice/service type to distinguish multiple network slices of the same slice/service type.

The S-NSSAI may have a standard value (i.e., such S-NSSAI consists of only SST with a standardized SST value, without SD), or a non-standard value (i.e., such S-NSSAI consists of both SST and SD, or consists of only SST without a standardized SST value, without SD). The S-NSSAI with non-standard values identifies a single network slice within the PLMN associated therewith. In any other PLMN than the PLMN with which the S-NSSAI is associated, the UE should not use S-NSSAI with non-standard values in the access stratum procedures. Table 2 shows the data structure in 3GPP TS 23.501, System Architecture for the 5G System; standard SST values as defined in Stage 2, v15.1.0, Release 15, 2018-03.

NSSAI is a collection of S-NSSAIs. The NSSAI may be a configured NSSAI, a requested NSSAI, or an allowed NSSAI. There may be up to 8S-NSSAIs among the allowed NSSAIs and the requested NSSAIs sent in signaling messages between the UE and the network. The requested NSSAI signaled by the UE to the network allows the network to select a serving AMF, network slice, and network slice instance for the UE.

TABLE 2 normalized SST values

Slice/service type	SST value	Characteristics of
			eMBB	1	Slice suitable for 5G enhanced moving broadband processing.
URLLC	2	Slicing suitable for processing of ultra-reliable low-latency communications.
			MIoT	3	Slicing suitable for processing of large-scale IoT.

Based on the operator' S operational or deployment requirements, a network slice instance may be associated with one or more S-NSSAIs, and an S-NSSAI may be associated with one or more network slice instances. Multiple network slice instances associated with the same S-NSSAI may be deployed in the same or different tracking areas. When multiple network slice instances associated with the same S-NSSAI are deployed in the same tracking area, the AMF instance of the serving UE may logically belong to (i.e., be common to) more than one network slice instance associated with the S-NSSAI.

Referring to fig. 6, and as described above, the 5GC defines a service-based architecture (SBA) based on the concept of network slicing and virtualized Network Function (NF). Different network functions (e.g., AMF, SMF, and PCF) provide different network function services via a service-based interface. This means that the service consumer can use the same messages and the same procedures to communicate with the service provider. For example, any NF may subscribe to the same event with an event open service provided by the AMF. On the other hand, various network capabilities such as non-IP data transfer (NIDD), Background Data Transfer (BDT), and Power Save Mode (PSM) may be implemented by a set of NF services. Under current SBA architectures, a UE may configure and access a network via NSSAI indicating a request to identify a network slice. However, the UE has no way to directly indicate the required network capabilities.

For example, a vehicle running a V2X application may want to use Background Data Transfer (BDT), multimedia broadcast/multicast service (MBMS), and event monitoring capabilities. The UE or a corresponding V2X application server needs to establish a configuration with the Core Network (CN) so that the network slice serving the UE has the required network capabilities. On the other hand, a smart home device that integrates sensors and cameras may want to use a different set of network capabilities, such as NIDD, data caching, group messaging, and device triggering. The device may not have a graphical interface that allows human intervention, which is common for many IoT devices. For a network, it would be desirable to be able to automatically configure network slices based on different levels of input from the devices (e.g., levels of network capabilities, levels of network slice identifiers, or levels of NF services).

As further described above, the service-based architecture of the 5GC is composed of a plurality of virtualized network functions. Each network function provides a set of network function services through a service-based interface. Thus, network capabilities (e.g., event monitoring, location services) may be implemented by a set of network function services. Any entity (e.g., NF, UE, and SCS/AS) can subscribe to the service by invoking the same operations. However, there are some limitations to the existing SBA defined by 5 GC.

First, the granularity of network function services prevents flexible network capability configuration. Each network function provides various network function services from different aspects (e.g., AMF provides mobility management, location management, and event monitoring/open services), and each network capability may require a different set of network function services from different network functions. For example, an IoT device may require a MIoT service by setting the value of the slice/service type to MIoT. However, the UE has no way of indicating some specific network capabilities it wants, such as non-IP data transfer or event monitoring/reporting capabilities. In another example, a V2X Application Server (AS) may need to enable a Background Data Transfer (BDT) capability. Based on the current network functional framework, the BDT capability requires the Npcf _ BDTPolicyControl NF service provided by PCF and the Nnef _ bdtpnotification NF service provided by NEF to determine the BDT policy. Furthermore, the Nsmf _ PDU session provided by SMF is required to manage PDU sessions for future data transmission. It is difficult for the UE/AF/AS to understand what network function services are required for the BDT. In fact, the UE or SCS/AS need not be required to be aware of these network function services to enable the BDT. The UE and AS will be more concerned about network capabilities than NF services.

Second, when the UE registers with the core network, it may provide an indication of the type of slice it wants to connect to-e.g., in the requested NSSAI. However, this information may be PLMN-specific rather than standardized, and as a result, it may not be known to the UE-e.g., when the UE first registers, or when the UE is roaming. In this case, it is not possible for the UE to include this information when it attempts to register with the network.

Third, some IoT devices are constrained such that automatic network capability configuration in the core network is desirable to help these devices dynamically configure network capabilities. Based on existing approaches, dynamically adding or removing network capabilities (i.e., updating the network slice to which the UE is registered) will trigger the UE configuration update procedure, which further triggers the registration procedure and sometimes requires the UE to enter idle mode and repeat the entire registration procedure. This should not be necessary and may be overly complex for constrained IoT devices.

Fourth, the range of existing SBAs is limited to the control plane NF. User Plane Functions (UPF) are not involved. The UPF has some control functions such as QoS enforcement and event monitoring. It is desirable to define service-based interfaces and UPF services to enhance SBAs.

Fifth, when the UE sends a registration request to the core network, the UE has no way to indicate what network capabilities it needs.

Sixth, when the UE registers with the network, it receives an allowed NSSAI. The UE does not know whether the allowed NSSAI can support the capabilities required by the UE.

Seventh, when a UE context changes, such AS when the UE moves from EPS to 5G, or when there is a request from the AS, which may update the sliced network capabilities (e.g., maximum data rate, etc.), the PCC rules and network slice information for the UE may need to be changed (and thus the NCP). The PCF may be able to communicate such changes to the UE as UE policy updates. UE policies may need to be enhanced to incorporate NCP. The 5GS has no mechanism to communicate such enhanced UE policies to the UE.

Eighth, network slicing may have a limit on how many PDU sessions it can handle at one time. When the UE attempts to establish a PDU session with the network slice, and if the network slice's capability has reached its peak, the network slice cannot handle the UE's request. The 5G system does not currently handle this situation.

Ninth, another network capability may be the maximum number of UE registrations per network slice to process. When a UE attempts to register with a network slice and the network capabilities for the maximum UE registration in the slice have reached their limits, the UE should not be able to register. The current 5GS does not address this situation.

When a UE application attempts to initiate a data flow (e.g., an IP data flow), the UE needs to determine which slice and data network to associate the data flow with. The 5G system provides a solution to this problem in the URSP. The URSP rule may include an application identifier instructing the UE how to route traffic from a given application. A disadvantage of this approach is the need to provide the UE with an application identifier that matches the application it is installed in. Another method of determining which slice and data network to associate a data flow with is to allow the UE to indicate the slice (S-NSSAI) and data network (DNN) with which the data flow should be associated. The disadvantage of this approach is that the UE application needs to be provided with S-NSSAI and DNN, and these parameters need to be identifiable to the network.

Methods and apparatus are disclosed herein that enable a network to indicate to a UE the network capabilities of a slice, and how these capabilities are configured in a slice. The UE may use this information in case the UE applications may indicate to the UE the capabilities they need. The UE may then use this information during routing (i.e., during evaluation of the URSP when determining which slice and PDU session to use for the data flow). Methods are also disclosed for a UE to indicate to the network what network capabilities it desires and their desired configuration, and the network may provide the UE with a slice identifier that can provide these capabilities in the desired configuration.

The concept of Network Capability Profiles (NCPs) was introduced. NCP lists the capabilities of slices and how each capability is configured. Examples of network capabilities are provided below.

Disclosed below is a technical solution to the problems of existing service-based architectures and corresponding NF frameworks. These solutions may enable more dynamic and flexible operation in a service-based architecture and may improve programmability of the service-based architecture for end users (i.e., UEs and ASs). To make it easier for users (e.g., UEs and ASs) to configure required network capabilities and features through service-based interfaces and procedures, the following description is made.

First, a new framework is described that includes a network capability layer. The UE and AS may dynamically request network capabilities (e.g., background data transfer, non-IP data transfer, maximum UE DL/UL data rate, maximum delay tolerance, maximum guaranteed DL throughput, group characteristics, messaging options, etc.) to support their applications. In one implementation, the UE and AS may not need to know and care which network slice supports the requested network capabilities, or whether the serving network slice is capable of supporting the requested network capabilities. The core network entity may determine and configure a network slice that supports all requested network capabilities.

Second, a mechanism is described by which the network can communicate network capability information, referred to herein as a Network Capability Profile (NCP) of the network slice, to the UE. A method is also described in which the network may notify the UE of an alternative network slice with a comparable network capability profile based on the network capabilities requested by the UE.

Third, a method for a UE to initiate a network capability based registration to configure its required network capabilities is disclosed.

Fourth, a method for a UE to initiate a network capability based registration to configure its required network capabilities is described.

Fifth, a method for a UE to initiate a network capability based registration update when the UE has registered with the network and wants to dynamically reconfigure their network capabilities is described.

Sixth, a method for network capability based UE configuration update is described that allows the NF or application server to initiate a process to update network capabilities in a network slice for the UE.

Seventh, a method is disclosed by which a UE can receive a set of allowed NSSAIs and their corresponding NCPs during a general UE registration procedure. If the capabilities indicated by the received NCP are not sufficient for the application in the UE, the UE may be able to request an alternative network slice based on the NCP list of allowed S-NSSAIs received from the core network.

Eighth, a method is disclosed by which NCP of a network slice is transmitted to a UE as part of a UE policy during a UE policy update procedure.

Ninth, a method is disclosed by which the core network enforces a maximum number of PDU sessions per network slice during the PDU session setup procedure and handles requests received after a maximum limit is reached.

Tenth, a method is disclosed where the core network handles a maximum limit on the number of PDU sessions per network slice, where the network regularly informs the UE through NAS messages that the network slice has reached its maximum limit so that the UE can wait before reattempting.

Eleventh, a method is disclosed by which a core network enforces a maximum number of UE registrations per network slice and processes registration requests received after a maximum limit is reached.

Twelfth, an extended service-based architecture is described that includes an interface to a User Plane Function (UPF) and services provided by the UPF.

According to these aspects, the UE may send a network capability configuration request to configure network capabilities to support its applications, and the UE may receive a network capability configuration response with an identification of a network slice to support the required network capabilities. Based on these characteristics, the network entity receiving the request may do one or more of the following:

checking the network capability profile to determine whether the serving network slice can support the requested network capability;

select a new network slice to provide all requested network capabilities for the UE;

in case the UE cannot be served with any existing network slice, initiate a new network slice (instance) to provide all requested network capabilities to the UE;

selecting a new entity providing the newly selected network slice, the new entity terminating NAS signaling with the UE;

updating the network capability profile of the selected network slice; and

a response to send information with serving network slice and network capabilities to the UE.

The network capability profile may include one or more of the following:

an identifier of a network slice and a corresponding network slice instance;

an identifier of a supported network capability list;

an identifier of the serving PLMN; and

service area information for each network capability.

The network capability configuration request may contain one or more of the following:

an identification of one or more required network capabilities;

an identifier of the application requiring network capabilities;

the NSSAI assigned by the UE during the previous registration procedure, which may be a configured NSSAI or an allowed NSSAI;

an identifier associated with the UE;

service area information of the requested network capabilities;

availability scheduling of required network capabilities;

QoS level of required network capacity (e.g., service response time);

required multi-tenant level (e.g., how many applications on the UE will need to use one or more network capabilities).

Further, in accordance with various aspects described above, the network entity may perform one or more of the following operations:

receiving a network capability configuration request from a network entity that triggers a network capability configuration update procedure for the UE;

determining whether it is necessary to select a new network slice and/or a new network entity for the UE as a NAS signal termination point;

selecting a new network slice and/or a new NAS termination point for the UE;

sending a configuration update message to the UE; and

sending a response to the triggering network entity.

The network entity receiving the request may further perform one or more of the following:

checking the network capability profile to determine whether the serving network slice can support the requested network capability;

select a new network slice to provide all requested network capabilities for the UE;

selecting a new entity providing the newly selected network slice, the new entity terminating NAS signaling with the UE;

updating the network capability profile of the selected network slice; and

sending a notification of information with serving network slice and network capabilities to the UE.

Alternatively, instead of the network entity triggering the network capability configuration update procedure for the UE, the application server may decide to trigger the procedure by sending a network capability configuration request.

The UE may perform one or more of the following:

send a registration request.

Receive a registration response, the response including the NCP of the network slice.

Further, according to the various aspects described above, one or more of the following operations may be performed:

the response may come from the AMF.

AMF can obtain NCP of subscribed S-NSSAI from UE subscription information in UDM.

AMF can obtain the NCP of allowed S-NSSAI from other network functions such as UDM, NSSF or NRF.

The response may contain the S-NSSAI that is not in the registration request, and the response may include the NCP for each S-NSSAI.

The UE may request an alternative network slice based on the NCP list of S-NSSAIs received from the core network.

The UE may receive the NCP as part of the UE policy received in the NAS message.

Further, in accordance with various aspects described above, the network entity may perform one or more of the following operations:

receive a trigger to update the NCP policy of the UE.

Check the latest PSI to find the UE policy and NCP policy (NCCP) of the S-NSSAI to be sent to the UE.

Integrating NCPP with UE policies.

Transmit NCPP to UE using UE policy container.

Further, according to the various aspects described above, the UE may use the information in the NCPP when selecting a route during evaluation of the URSP rule. For example, where the maximum data rate in the slice associated with a higher priority route is lower, the UE may choose to establish the route described in the lower priority RSD.

The UE may perform one or more of the following:

attempt to establish a PDU session with the network.

Rejected and receives a reason code indicating that the maximum PDU session limit and wait timer for the slice has been reached.

No attempt is made to PDU session setup before waiting for the timer to expire or before the UE terminates the PDU session.

Further, in accordance with various aspects described above, the network entity may perform one or more of the following operations:

employing a counter that increments or decrements for each PDU session established or terminated.

When the maximum limit is reached, the UE's request to establish a PDU session may be blocked and a cause code containing the reason for the denial of access and the wait timer sent to the UE in response.

The UE may perform one or more of the following:

receive NAS notification, which indicates that the maximum PDU session limit has been reached and a wait timer.

Wait for the wait timer to expire or wait until the UE terminates another PDU session in the same slice before requesting PDU session establishment.

Further, in accordance with various aspects described above, the network entity may perform one or more of the following operations:

employing a counter that increments or decrements for each PDU session established or terminated.

Notify the UE when the condition is cleared.

Further, in accordance with various aspects described above, the UE may perform one or more of the following:

receive a NAS message from the network indicating that the condition has been cleared.

Reset the wait timer and retry the PDU session setup procedure.

Wait until the wait timer expires and retry the PDU session setup procedure.

The UE may perform one or more of the following operations:

request UE registration procedure.

Rejected with a cause code indicating that the maximum UE registration limit has been reached and a waiting timer.

No UE registration is requested before the waiting timer expires or before a certain UE de-registers from the slice.

Further, in accordance with various aspects described above, the network entity may perform one or more of the following operations:

employing a counter that increments or decrements for each UE registered or deregistered.

When the maximum limit is reached, the network entity may block the UE's registration request and send a reason code to the UE in response, where the reason code contains the reason for the denial of access and the wait timer.

Notify the UE that the condition has been cleared.

Further, in accordance with various aspects described above, the UE may perform one or more of the following:

the wait timer is observed.

A NAS message is received from the network indicating that the condition has been cleared.

The wait timer is reset and the UE registration request is reattempted and attempted.

Framework for network slicing in 5g core networks

Fig. 7 represents a network architecture with a layer of network capabilities (e.g., BDT, NIDD, and event monitoring) between a network slice (with corresponding NF and NF services) and a UE/AS. The network capability layer may make the granularity of network slice configuration finer and may make it easier for the UEs/AS to configure their network features. The new layer may comprise a logical layer that allows the UE and SCS/AS to request the required network capabilities by indicating in place of or in addition to what type of network slice is desired (e.g., BDT, NIDD, and event monitoring).

The UE/AS may send a request to the core network directly indicating the required network capabilities, and a new NF, referred to herein AS a Network Capability Management Function (NCMF), may be operable to configure the network slice to provide the required network capabilities to the UE/AS. NCMF can implement management functions of the network capability layer in the core network.

This new NF may make the granularity of configuring network services finer. In an aspect, the UE/AS may directly indicate what network capabilities it wants without knowing the available NFs and NF services (e.g., background data transfer, event monitoring, etc.). This allows the UE/AS to request specific capabilities without the UE/AS needing to know how the network slice provides the capabilities. The UE and AS may only be concerned with the level of network capabilities for their applications. On the other hand, the core network entity may maintain the operation of NF and NF service levels without any change in the existing architecture due to the request of network capability level from the UE/AS.

The NCMF may have one or all of the following functions.

First, NCMF can manage and maintain information that provides a mapping between network capabilities and NF services. That is, the mapping information may indicate a set of NFs and corresponding NF services needed to support the network capabilities. This information may be used to determine whether a network slice is capable of supporting network capabilities, subject to which NFs and NF services are included in the network slice.

Second, NCMF can manage and maintain a profile that includes information identifying a set of network capabilities supported by a network slice. This network capability profile information may be useful when the UE/AS requests to add or update network capabilities for its applications.

Third, NCMF can also interface with network operations and management (O & M) systems to obtain information about network slices, NFs, NF services, and/or network capabilities. The NCMF may also request that the O & M system manage network slices, network slice instances, NFs, and/or NF services to support the required network capabilities.

The NCMF may be a stand-alone network function, a logical function residing in other network functions, such as an AMF, SMF, or PCF, or a service provided by a network function.

Mapping information between network capabilities and NF services

In order to determine whether a network slice can support a certain network capability, it is necessary to maintain mapping information to indicate what NF services are needed to support the network capability. For example, a Background Data Transfer (BDT) capability requires an Npcf _ BDTPolicyControl service provided by a PCF and an Nnef _ bdtpnotification service provided by a NEF in order to determine a BDT policy. In addition, the Nsmf _ PDU service provided by SMF is required to manage PDU sessions for future data transmission. Table 3 shows an example of a data structure for providing mapping information between network capabilities and NF services required by the network.

Table 3: mapping information between network capabilities and NF services

The NCMF can obtain mapping information from the O & M system of the network. The mapping information may be managed and stored at the NCMF. The NCMF may be co-located with the NSSF or NRF, and thus the mapping information may also be managed and stored in the NSSF or NRF.

Network capability profiling

The network capability profile may include an information profile for each network slice maintained by the NCMF that indicates what network capabilities are supported by each network slice. Table 4 shows one example of information fields that may be included in a network capability profile for a given network slice. Note that the Network Capability Profile (NCP) is a collection of information elements for each slice.

Table 4: network capability profiling

The NCMF can manage and maintain the information shown in tables 3 and 4. When the core network NF receives a request from the UE/AS to add network capabilities or update network capabilities (e.g., modify one or more parameters of the network capabilities), the request may be forwarded to the NCMF to determine whether the serving network slice already supports the requested network capabilities. If not, the NCMF may further determine whether the serving network slice may be configured to support the requested network capabilities. That is, whether a service slice can be functionally configured to support network capabilities, and whether a service slice has sufficient resources (e.g., available processor and memory resources) to be configured to support network capabilities.

Alternatively, the information in tables 3 and 4 may be managed and maintained instead or in addition at the NSSF or NRF, in which case the NCMF may be co-located with the NSSF or NRF where the NF and NF service information is maintained.

Another alternative is to store this information in the UDR. This may provide an easier way for any NF to obtain this information by accessing the data store without the need to discover and communicate with the NCMF, NSSF, or NRF.

As another alternative, the network capability profile may be implemented as an embodiment of a slice Specifier (SD) in S-NSSAI, such that it may be indicated what network capabilities are supported by the network slice. This may allow for differentiating network slices with the same slice/service type (SST) (e.g., MIoT, eMBB) value of the network slice, but supporting different network capabilities.

On the UE/AS side, the UE/AS may maintain information about what network capabilities are supported by the serving network slice once the registration or registration update procedure is completed. Furthermore, the UE/AS may maintain information about which application the network capabilities supported by the network slice are used for, since there may be multiple network slices serving different applications running on the UE.

Network slicing capability configuration

The network capability profile of table 4 includes a network slicing capability field for each network slicing capability supported by the slicing. This field indicates the specific capabilities supported by the slice. Examples of capabilities that slices may support are listed below; the network may indicate support for these capabilities to the UE:

maximum number of UEs per network slice

Maximum number of PDU sessions per network slice

Maximum UL and DL data rates per UE in the network slice

Support for deterministic communication

Support for group communication

Support for indicated isolation levels

Support for location-based messaging

Support for maximum packet size

Support for mission critical communications

Support for MMTel

Support for performance monitoring

Support for indicated Session and Service Continuity (SSC) patterns

Support for non-IP data transfer (NIDD) and/or Reliable Data Services (RDS)

Support for certain RATs

Support for specific device speeds

Support for specific vertical applications such as V2X communication and mIoT communication

Support for a specific service area, where only those UEs located in that service area are allowed to access/connect to the network slice. The service area may be represented by a tracking area, a registration area, or a geographic area.

The maximum number of network slice instances that can be instantiated for a network slice.

Support for certain relay mechanisms

Support for multiple tunneling mechanisms (L2TP tunnel, GRE tunnel, or VPN tunnel).

Support for coverage (global, national, regional, restricted to cells, sectors, base stations, etc.) of network slices

Support for delay tolerance for the UE.

Support for guaranteed DL throughput for the UE.

Support for describing how often the UE is provided with predicted values of KQI and KPI. The UE may send a request in advance and receive prediction information about the quality degradation (and thus switch slices if needed).

SSC pattern support (SSC pattern 1, SSC pattern 2, SSC pattern 3, SSC pattern 4)

Support for periodic traffic (deterministic communication), which can help optimize the scheduling/performance of the UE.

Support for multiple radio spectrums, as some terminals may be limited in terms of frequencies to use (e.g., n1, n77, n38, etc.).

Support for various access technologies.

Support for uplink throughput per network slice, which defines the achievable data rate of a network slice instance in the uplink, which is universally available within the coverage of the network slice.

Support for user data access, which defines how a network slice (or mobile network) should handle user data. For example, the UE may access the internet, data may be routed to a private network via tunneling, or all UE data may be left local. Support for a slice quality of service parameter defining all QoS related parameters supported by a network slice.

Support for the maximum packet size supported by the slice, which may be important for URLLC (ultra-reliable low latency communication) and MIoT (large-scale IoT), or indicate the Maximum Transmission Unit (MTU) supported. Thus, the UE may need to follow the slice.

Support for network slice isolation level (physical or logical isolation). This may affect or support the UE being isolated on a slice basis.

Note that some of the capabilities listed above may require additional configurations. For example, the capability for "support for guaranteed DL throughput for a UE" may be associated with a particular DL throughput value (e.g., 100 Mbps). This information will be captured in the "parameters of network capabilities" field of table 4. The "parameters of network capabilities" may be indicated by the network to the UE.

Network capability based registration

With the network capability layer of fig. 7, which may be implemented in the form of NCMF, the UE is able to request the network capabilities it needs, and the UE does not need to know whether a particular NF and NF service is available in a certain network slice.

Fig. 8 shows an example of a method for network capability based registration. When the UE registers, the UE may include an indication of a set of required network capabilities to support its applications, and the network may reply with NSSAI and NSI IDs identifying the network slice that supports all the requested network capabilities. The response of the network may also indicate which S-NSSAIs are associated with each capability. The steps of the registration method are shown in fig. 8. Note that only information related to network capability configuration is described below for descriptive purposes only. During the registration process, other information is involved, such as information related to mobility management, session management, etc.

In step 1, the UE may send a registration request message to a RAN node of the communication network. In the request message, the UE may indicate the following information:

a list of requested network capabilities, each identified by a network capability Identifier (ID). This information may be captured in a network capability profile as described in table 4. This information may be associated with the requesting NSSAI and may provide one network capability profile per S-NSSAI in the NSSAI. When the UE first initiates registration, it may not have network capability mapping information. The UE may insert some requirements on network capabilities so that a network entity (e.g., AMF, NCMF) can decide whether an existing network slice can serve the UE based on these requirements. Some requirements are discussed below, such as a required network capability availability schedule, a required network capability QoS level, and a required multi-tenant level. The UE may determine the type of network capability requested based on the type of application being run on the UE. One application may require multiple network capabilities. Thus, the UE may need to maintain some information about which applications need what network capabilities in the 5G core network. When the UE communicates with the AS, the UE may obtain this information through application layer signaling.

Previous NSSAI: if available, the UE may include its assigned S-NSSAI or S-NSSAIs, if the UE was previously registered with the PLMN. This may help the RAN node select the AMF and may be used by the AMF to configure/select a network slice that supports the requested network capabilities. The included NSSAI may be a configured NSSAI or an allowed NSSAI provided to the UE during a previous registration procedure. This parameter is optional.

Application ID: indicating a set of applications that are requesting the requested network capabilities. It is possible for a UE to be served by multiple network slices, and each network slice may serve a different set of applications, such as mliot and eMBB. Accordingly, applications and network capabilities may be partitioned and supported by different network slices. The UE may then maintain information indicating which application is served by which network slice with a set of network capabilities. It is possible that a certain network capability is supported by more than one network slice serving different applications in the UE. Alternatively, the UE may provide the application IDs without binding them to any network capabilities, and will contact the SCS/AS to determine which application is associated with which network capabilities. This may reduce UE responsibility and may be useful for restricted devices.

PLMN ID: this indicates the PLMN the UE intends to register to if the UE has this information. The PLMN ID may facilitate network slicing and AMF selection since different PLMNs may configure different network slices to provide the same network capabilities.

UE identifiers such as GUTI and/or SUPI, if available.

Region information: for selecting a network slice serving the UE. This information may be in the form of a TAI, registration area, or geographic area.

Required network capacity availability schedule.

Required network capability QoS level (e.g., service response time).

Required multi-tenant level (e.g., how many applications on the UE will need to use the network capabilities). This information, along with the network capability requirements described above, may be used by the network O & M system to determine whether existing sliced instances, NFs, and NF services are available to satisfy requests for network capabilities, or whether new instances need to be instantiated (e.g., based on availability and scalability requirements).

At step 2, upon receiving the registration request, the RAN node may select an AMF based on the requested network capabilities and the following information:

NSSAI and AMF association information indicating which AMF serves which network slice identified by NSSAI; and

mapping information of network capabilities to S-NSSAI.

The RAN node may obtain the information by transmitting the information to the RAN node by the AMF in an N2message appended thereto. Alternatively, the RAN node may obtain this information by the core network periodically sending it to the RAN node to advertise its network slice information and supported network capability information.

If the RAN node does not have any of the above information, or does not know any AMF supporting the requested network capabilities, the RAN node may select a default AMF based on its local configuration. In this case, additional AMFs may be selected later to serve the UE.

At step 3, the RAN node may forward the registration request to the selected AMF.

In step 4, the AMF may choose to contact the UDM to retrieve some subscription information and/or contact the UDR to obtain some UE context information as well as network capability information.

At step 5, the AMF then queries the NCMF to obtain information about which network slice or slices can support the requested network capabilities and network capability usage requirements of the UE (such as the required network capability availability schedule, required network capability QoS level, and required multi-tenant level as described above). The AMF may include the requested network capability information in the message. Alternatively, the AMF may query the NCMF to check whether the S-NSSAI in the requested NSSAI is capable of providing the capabilities indicated in the network capability profile of step 1.

At step 6, the NCMF may examine the existing network slice to network capability mapping information and may return NSSAI to the AMF to identify the network slice that supports all requested network capabilities. If the NCMF cannot identify any existing network slice that can support all of the requested network capabilities, the NCMF may indicate this in the response message. The NCMF may provide the AMF with a new set of S-NSSAIs that the UE may use to obtain the requested service. The NCMF may provide the AMF with the NSID of each S-NSSAI. The NCMF may provide the AMF with a network capability profile for each S-NSSAI.

At step 7, the AMF may compare the received NSSAI with locally stored network slice information to decide whether the AMF can serve all NSSAIs needed for all requested network capabilities. If the AMF is able to do so, the AMF will update the UE context and proceed to step 10. Otherwise, the AMF may request the NSSF for network slice selection and proceed with steps 8 and 9 for any of the following: (1) AMF cannot serve all NSSAIs; (2) the AMF cannot decide whether it can serve NSSAI; or (3) the NCMF indicates that no existing network slice can support all the requested network capabilities.

At step 8, the AMF requests the NSSF to select a network slice instance by providing the requested network capability information, PLMN ID and, if available, UE information (such as 5G-GUTI capability and SUPI).

Based on the UE ID and PLMN ID, the NSSF may verify the NSSAI in the request and may select a network slice instance to provide all requested network capabilities for the UE, step 9. The NSSF may also select an NRF if a new set of AMFs is selected to serve a network slice, so that the new AMF may select an NF instance and an NF service instance in the selected network slice. The NSSF may return one or all of the following information in the response:

·NSSAI；

the selected NSI ID corresponding to the NSSAI in the request;

NRF address; and

the selected AMF set and/or AMF address.

If an existing network slice cannot serve the UE, the NSSF may contact an operations and management (O & M) system to initiate a new network slice and corresponding network slice instance to serve the UE.

Upon receiving the response, the AMF may inform the NCMF of the mapping information between the selected network slice and the network capabilities, step 10. This is necessary, for example, if the NCMF does not find any network slice that supports all the requested network capabilities in step 7.

At step 11, the NCMF may update mapping information between the selected network slice and the network capabilities.

In step 12a, if the current AMF is able to serve the UE, the AMF may send a registration response to the RAN node, which forwards the response to the UE. The N2message from the AMF to the RAN node may contain the network capability profile of the selected network slice, i.e., the selected network slice information and all information about the network capabilities supported by the network slice. Additionally, location information or registration area information may be included in the response and provided to the RAN node and UE such that the information may be mapped or associated with the selected network slice.

The registration accept message may include a network capability profile for each of the allowed NSSAIs. A network capability profile is an indication or description of the capabilities of a network slice. Table 4 lists the contents of the network capability profiles for the network slices.

In the case where the UE is served by multiple network slices, the UE may maintain information identifying which application is served by which network slice instance with what network capabilities.

If the network slice cannot support the capabilities requested by the UE, the AMF may send a reject message including an error/cause code indicating the reason for the inability to support the request.

Alternatively, the network may send the network capability profile of the network slice that closely matches the requested network capability profile to the UE. For example, if the UE requires 10Gbps of guaranteed DL throughput network capability, the network may be able to scan a matching network capability profile for an available network slice, and if the best available network capability for guaranteeing DL throughput is 8Gbps, the network may send the network capability profile to the UE to indicate whether the UE can accept the network capability profile and agree to register to the network slice. On the other hand, the sliced network capability profile may provide more network capabilities and/or better quality of service (e.g., average UE UL/DL data rate, average latency, etc.) than the UE desires.

If the network sends a reverse (counter) network capability profile to the UE, the UE may reject or accept the provided network capability profile.

If the UE accepts the provided network capability profile, the UE may send an acknowledgement to the AMF to indicate the acceptance.

If the UE rejects the offered network capability profile, it may reject by sending a reject message (reject code) to the AMF. In this case, the AMF may reply with a default network slice and its network capability profile.

Alternatively, if the requested network capabilities are not available, the network may give the UE NCP with a default slice of standard network capabilities.

At step 12b, if a new AMF is selected to serve the UE, as per 3GPP TS23.502, Procedures for the 5G System; stage 2, v15.1.0, Release 15, 2018-0, the current AMF may initiate an AMF relocation process by contacting the target AMF.

In general, the network capability request message transmitted in step 1 may be encapsulated in any NAS message, such as NAS-MM signaling between the UE and the AMF, or NAS-SM between the UE and the SMF. In this sense, the information may be encapsulated in the service request message as well as the session management related request message. The UE may include the network capability request in a NAS-SM message. For example, the UE may launch a new application that requires the use of network capabilities X, Y and Z. The UE may have registered and have a PDU session on the network slice. The UE may issue a PDU session setup request with an indication to start a new PDU session on the same network slice that supports network capabilities X, Y and Z. The AMF or SMF may trigger an exchange with NCMF to see if slice 1 is sufficient or if a new slice is needed for the PDU session.

Network capability based registration update

The UE may require new network capabilities even after registration is complete and the UE is served by the network slice. For example, a new IoT application may be launched in a UE and require NIDD features that are not supported by the serving network slice. Fig. 9 shows one example of a method for UE-initiated network capability based registration update.

The network capability information provided in step 1 may be considered NCP.

In step 1, the UE may initiate a registration update procedure with a registration update request message, which may include one or all of the following information:

NSSAI: this is the configured and/or allowed NSSAI that the UE obtained during the previous registration procedure;

PLMN ID: this is used to indicate the PLMN where the UE is served by the network slice;

NSI ID: this indicates the network slice instance that is serving the UE;

application ID: this is an identifier of the application on the UE that needs new network capabilities;

requested network capabilities: the UE may determine the type of network capability requested based on the type of new application that is beginning to run on the UE. One application may require multiple network capabilities.

Information related to the network capability usage requirements of the UE, such as required network capability availability schedule, required network capability QoS level (e.g., service response time, etc.), and required multi-tenant level (e.g., how many applications on the UE will need to use the network capability).

Required network capability availability scheduling

Required network capability QoS level (e.g., service response time)

Required multi-tenant level (e.g., how many applications on the UE will need to use the network capabilities). This information, along with the network capability requirements described above, may be used by the network O & M system to determine whether existing sliced instances, NFs, NF services are available to satisfy the request, or whether new instances need to be instantiated (e.g., based on availability and scalability requirements).

In step 2, the serving AMF may verify whether the UE is allowed to require new network capabilities and whether the information provided by the UE is valid.

In step 3, the serving AMF may optionally choose to contact the UDM/UDR to retrieve some more information about the UE and UE context in the UDR.

At step 4, the serving AMF may decide whether the newly requested network capabilities may be supported by any network slice served by the AMF. If the serving AMF is capable of supporting the requested network capabilities, whether this is supported by the serving network slice or a different network slice, the AMF will proceed to step 12.

In step 5, if the serving AMF cannot support the required network capabilities and network capability usage requirements of the UE, or if the serving AMF cannot decide whether it can support the required network capabilities and network capability usage requirements of the UE, the serving AMF may send a network capability configuration request to the NCMF, the request including the UE context, NSSAI and required network capability information stored in the AMF.

At step 6, upon receiving the request, the NCMF may examine the mapping information between the available network slices and its network capabilities, as well as the network capability profile, to find a network slice that supports the requested network capabilities.

At step 7, the NCMF may then determine whether the requested network capabilities can be supported by any network slice without changing the serving AMF.

In step 8a, if the NCMF decides that the serving network slice cannot support the network capabilities requested by the UE, it will request the NSSF to select a new network slice.

At step 9a, the NSSF may select one or more network slice instances, potentially a new set of AMFs and NRFs. The NSSF may return any selection result, including the NSI ID, NSSAI, NRF address, and AMF set. If a new AMF is selected, an AMF relocation procedure may be triggered at step 12 b. If a new network slice is selected without changing the AMF, the UE may connect to both network slices simultaneously. If an existing network slice cannot serve the UE, the NSSF may contact an operations and management (O & M) system to initiate a new network slice and corresponding network slice instance to serve the UE.

In step 8b, if the NCMF determines that the serving network slice can support the network capabilities requested by the UE, but the network capabilities are not yet enabled, the NCMF may send a request to the NSSF to update the serving network slice information to indicate that the network slice will support the network capabilities. The NCMF may include the requested network capability information, the NSI ID serving the UE, and the NSSAI being served by the AMF in the request message.

In step 9b, the NSSF may update the network slice information and may reply to the NCMF for confirmation.

The NCMF may also update the mapping information to indicate that the network slice supports the network capabilities requested by the UE, step 10.

At step 11, the NCMF may send a response to the serving AMF, with all or some of the following information:

·NSSAI；

a new NSI ID for case "a" where a new network slice is selected;

a new AMF set for case "a" where a new network slice is selected; and

configuration results for case "b" where the service AMF and service network slice are able to support network capabilities.

In step 12, the serving AMF may update the UE context and serving network slice information for case "b" or may initiate a procedure to relocate the AMF for case "a".

At step 13, if the serving AMF is not changed, the serving AMF may reply to the UE with a registration update response to indicate serving network slice information. If the NSSF selects a new AMF, the target AMF may contact to confirm the registration update if the new network capability is enabled.

Network capability based UE configuration update

In addition to the UE, the network or AS may also initiate an update of the UE configuration due to a network capability update in the serving network slice. For example, the following events may trigger the network or AS to start the process:

new applications are started in the SCS/AS and the UE subscribes to new application services at the SCS/AS. As a result, new network capabilities are needed to support the new application.

For some reasons, such as load balancing issues or shrinking of network function/network slice instances in the serving network slice, the network wants to switch to a new network slice to serve the UE.

Fig. 10 illustrates a method for network capability based UE configuration update.

At step 0, this is a pre-requisite step assuming that the UE has completed registration with the network, and the UE has a connection to an Application Server (AS) through the network.

In step 1a, the AS may decide to add or update network capabilities in the network slice serving the UE due to certain events (e.g. a new application session is required). In the case of a new application, the AS may determine the type of network capability requested based on the type of the new application.

In step 1b, the AMF decides to change the network slice serving the UE for some reason (e.g., load balancing of the serving network slices).

In step 2a, the AS sends a network capability configuration request message to the NCMF via the NEF. The information provided in this step may be NCP, and may include the following information:

UE ID, such as SUPI, GUTI, or external UE ID;

NSSAI, which indicates the serving network slice for the connection between the UE and the AS;

new network capability information to be added to the network slice to support communication between the UE and the AS;

information related to network capability usage requirements for communication between the UE and the AS, such AS required network capability availability scheduling, required network capability QoS levels (e.g., service response time, etc.), and required multi-tenant levels (e.g., how many applications on the UE or AS will need to use the requested network capability);

an application ID, which indicates the application associated with the requested network capability;

a reference ID used to refer to the network capability configuration process; this may be assigned by NEF; and

NSI ID: indicating the network slice instance serving the UE.

At step 2b, the AMF sends a network capability configuration request message to the NCMF.

In step 3, upon receiving the request, the NCMF may optionally choose to contact the UDM/UDR to retrieve the UE context and some more subscription information of the UE in the UDR.

At step 4, the NCMF may examine the network slice information and the requested network capability information. The purpose of these checks is:

information provided by the authentication AS or network function, such AS network slice information, network slice instance information; and

deciding whether the serving network slice can support the requested network capabilities and network capability usage requirements of the UE and AS. This may be accomplished by examining the network capability profile of the network slice. If not, step 5 will be performed.

At step 5, if the NCMF finds that the serving network slice cannot support the requested network capabilities, the NCMF may resort to the NSSF to select a new network slice or to formulate a new network slice. It is also possible that the NCMF finds that the serving network slice is overloaded, and if so, it can request the NSSF to select a new slice.

At step 6, the NCMF or NSSF informs the AMF to proceed with the network configuration procedure. If the procedure is triggered by the AS (i.e. steps 1a and 2a), the AMF will be provided with UE ID, NSSAI, NSI ID, SCS/AS ID, NEF ID and reference ID. This information can be used by the AMF to contact the NEF at a later time.

At step 7, the AMF communicates with the UE to trigger a UE configuration update. In the message, the AMF will inform the UE of the NCP of the slice, which NCP includes one or more of the following information:

new network capability information;

NSSAI identifying a network slice, especially for the case where a new network slice is selected;

a reference ID; and

·SCS/AS ID。

in step 8, the UE initiates the registration update procedure represented in fig. 9.

Once the registration update procedure is complete, the AMF sends a message via the NEF to reply to the AS, step 9, for the case where the AS initiates the procedure.

Note that fig. 10 shows a scenario where the AMF starts the process as an example of the network entity initiating the process. Other network entities may also initiate the process. For example, the PCF may initiate the procedure due to a UE policy change or a network slice selection policy change. The PCF may then trigger a network slice selection procedure, which may potentially affect the provision of network capabilities to the UE.

Registration procedure for network capability profiles for requested NSSAI

The NCMF can configure network capabilities for network slices and establish a Network Capability Profile (NCP) for each slice. This section details the methods described previously in this document and describes methods by which NCPs can be transmitted to UEs along with NSSAIs (e.g., one NCP per S-NSSAI). This method is depicted in fig. 13 and illustrates how the initial registration procedure may be enhanced to support the configuration of network capabilities, however it should be appreciated that the same enhancements may be applied to the mobility registration update procedure and the periodic registration update procedure.

Fig. 13 illustrates how the initial registration procedure, the mobility registration procedure, and the periodic registration procedure defined in 3GPP TS23.502 may be updated. Fig. 13 particularly focuses on the portion of the registration process that may be enhanced or that requires the most enhancement. Some steps are omitted. Note that fig. 13 shows that NCMF is an independent NF or logic function. It may instead be part of an OAM system, or part of another NF such as an SMF or AMF.

As shown in fig. 13, the AMF may determine the capability of the slice to which the UE will be registered and provide the capability information to the UE. In addition, the UE may request certain capabilities. In addition, the network may provide the UE with a list of S-NSSAIs and associated NCPs with which the UE may register.

In step 1, the UE sends a registration request, which includes the requested NSSAI, to the AMF via the (R) AN node. The registration request may be an initial registration, a mobility registration update, or a periodic registration update. As previously described in this document, the registration request may include an NCP to indicate to the network what capabilities are desired for each of the NSSAIs.

At step 2, the (R) AN node selects the AMF as described in TS 23.501[1], clause 6.3.5.

In step 3, (R) the AN node forwards the registration request message to the AMF.

At step 4, based on the registration request from the UE, the AMF may query the UDM/UDR to obtain the subscription of the UE. The UE subscription may include a subscribed S-NSSAI.

At step 5, if no information was obtained in the previous step, the AMF may request a network capability profile from the NCMF for each S-NSSAI of the allowed NSSAIs. The keywords of such a query should include S-NSSAI (i.e., NSSAI).

Alternatively, the AMF may obtain the NCP associated with each S-NSSAI by querying other NFs, such as NSSF or NRF, to obtain the NCP associated with each S-NSSAI.

At step 6, the NCMF may send the NCP of the requested S-NSSAI back to the AMF.

At step 7, the AMF sends the allowed NSSAIs and the configured NSSAIs, as well as the NCP for each of the allowed NSSAIs and the NCP for each of the configured NSSAIs, to the UE as part of the registration accept message. The NCP may be considered part of the allowed NSSAI and the configured NSSAI.

Optionally, the network may send an advertisement NSSAI to the UE. The advertisement NSSAI is a list of S-NSSAIs and their corresponding NCPs. This list and the corresponding S-NSSAI may be an indication of which slices of advertisements are available to the UE and the capabilities of each slice. The S-NSSAI in the advertisement NSSAI may not be part of the requested NSSAI or the allowed NSSAI. The purpose of advertising an NSSAI may be to provide the UE with information about which slices it may request to add to its configured NSSAI or allowed NSSAI. Alternatively, the advertisement NSSAI may be part of a configured NSSAI.

At step 8, if the UE determines that the allowed NSSAI and/or any NCP provided with the S-NSSAI is not sufficient, in the sense that the slicing capability is not sufficient, the UE may evaluate the advertised NSSAI and, if it finds a suitable S-NSSAI within the advertised NSSAI, begin the registration update process and include the S-NSSAI in the advertised NSSAI in the requested NSSAI. The UE and the network may then perform a registration update procedure, and the network may update the UE's allowed NSSAI and configured NSSAI accordingly.

Network capability profile delivery with UE policy update

The UE policies related to NCP may be referred to as NCP policies or NCPP. This section describes a method by which the core network may be able to transmit NCPs to the UE as part of the UE policy. Note that the NCP policy may be sent to the UE by using the UE configuration update for the transparent UE policy transfer procedure defined in 3GPP TS 23.502. Fig. 14 illustrates this approach by focusing on how existing processes can be enhanced. The method may be triggered by a number of events described in step 0.

At step 0, an event may occur. A notification of the event may be sent to the PCF, enabling the PCF to determine if the NCP policy needs to be updated. Examples of events are:

the OAM system or authorized AS may send the update and request for NCP. The request may be sent via the NEF. For example, the AS or OAM may send a request to the NEF to increase the maximum UL or DR data rate allowed for the UE in the slice, or to increase or decrease the maximum number of PDU sessions allowed in the slice.

The PCF receives notification from the AMF that the UE has changed location (e.g., the UE policy may be limited to a geographical area, and thus a new policy may need to be updated).

The PCF receives notification that the subscribed S-NSSAI has changed for the UE or a group of UEs (e.g., a network administrator may update the UE subscription with a new S-NSSAI).

The PCF receives notification that the UE has moved from EPS to 5 GS. The UE will receive a new set of UE policies for 5 GS.

The UE sends a policy update request to the PCF (via NAS). The UE request for UE policy updates may be in response to downloading, launching, and/or installing an application requiring new network capabilities. For example, a user may download a gaming application that requires AR/VR settings. This may require a new set of policies to accommodate changes in data rates and other CN resources. The request may include an application or OS identifier.

The PCF receives notification from the OAM or from the NRF that the network functions associated with the slice are reconfigured (e.g., instantiates or removes a new NF, existing NFs are scaled up or down).

The NCMF sends the PCF updated NCP information for the S-NSSAI.

In step 1, the PCF checks the up-to-date list of PSI to decide which policies related to UE access selection and/or PDU session selection must be sent to the UE. Alternatively, the PCF must contact the NCMF to obtain a new set of NCPs for the S-NSSAI, or the NCMF may send the PCF new NCP information for the S-NSSAI. PCF populates enhanced UE policies including NCPP.

In step 2, the PCF invokes the Namf _ Communication _ N1N2MessageTransfer service operation of the AMF. The message includes SUPI, UE policy container. The UE policy container includes NCPP for the UE. In other words, NCP is treated by 5GS as UE policy as any other UE policy; either as a stand-alone policy or information integrated with the ANDSP or URSP policies.

At step 3, if the UE is registered with either a 3GPP access or a non-3 GPP access and reachable by the AMF, the AMF will transparently transmit the UE policy container (which includes the NCPP) to the UE via one of the registered and reachable accesses, based on the AMF local policy.

In step 4, the UE receives and stores the NCPP policy. The policies may be considered as independent policies, or NCP information described herein as part of the policies may be provided to the UE as part of the URSP rules or ANDSP.

Examples of how the UE may take action based on the policy are:

if the NCP policy indicates a new periodic flow gauge, the UE may need to update the reception or transmission period of the periodic flow. On the other hand, if the UE has no policy on periodic traffic, the UE may implement a new policy by transmitting and receiving messages within a specified time period. For example, the UE may need to continuously send sensor readings to the server every 10 seconds, which may be updated to 5 seconds when the UE is expected to travel at high speed. By enhancing the authentication criteria of the URSP, the periodic flow gauge may be integrated into the URSP rules so that the communication period may be indicated to the UE. The UE may then consider this information when evaluating the URSP rule.

If the NCP policy indicates a maximum UL and/or DL data rate, then when the UE evaluates the URSP rule, it may consider the maximum UL and DL data rates provided in the NCP information. The UE may choose not to establish the route described in the RSD or URSP, but to establish a lower priority route. For example, lower priority routes may allow higher UL or DL maximum data rates. When a route is established, the UE may provide the maximum UL and/or DL data rate to the application that initiated the traffic as well as any other applications that use the same route after the route is established. In addition, if the NCP indicates a maximum UL throughput per slice, the UE enforces this restriction by monitoring the total throughput of all PDU sessions in the slice.

If the NCP policy indicates location-based messaging and the UE appears to be in a restricted location, the UE may need to stop receiving or sending data in the message. The network may provide this information to the UE as a validation criterion in the URSP rules, or the network may provide this information to the UE as an independent NCP policy that is considered when evaluating all of the URSP rules. In other words, the NCP policy may be considered when evaluating all routes that include S-NSSAI from the policy.

The UE may send a registration update request to the network to register with a different slice that may allow for more favorable NCP policies. In other words, the UE may send a mobility registration update request, and the request may include an updated requested NSSAI, and the updated requested NSSAI may not include the S-NSSAI for which the UE just received the policy.

Handling maximum number of PDU sessions

This section describes the procedure how the network handles the predefined PDU session number limit per network slice and how the request can be handled if the UE finds that no more PDU sessions can be established.

Handling a maximum PDU session during a PDU session establishment procedure

The network may support a maximum limit on the number of PDU sessions that can be established within a network slice. There may be situations where the network slice may reach its maximum limit, but it may still receive a PDU session setup request from the UE. This section describes how such requests may be handled. Fig. 15 describes this method and illustrates how the existing PDU session establishment procedure defined in 3GPP TS23.502 may be enhanced. Fig. 15 particularly focuses on the portion of the registration process that should be enhanced or that requires the most enhancement.

At step 0, the network slice is configured with a limit on the maximum allowed number of PDU sessions per slice. This is either configured in NCMF. The NCMF includes a PDU session counter that counts the number of PDU sessions joined in the network slice. The session counter increments or decrements the number by 1 for each PDU session established or released, respectively. The NCMF may receive a notification from the SMF when the PDU session is established.

In step 1, the UE sends a PDU session setup request to the AMF via the (R) AN node.

In step 2, upon receiving a PDU session setup request from the UE, the AMF or SMF sends a request to the NCMF to check whether a new PDU session can be established in the slice. The request includes an S-NSSAI. The NCMF checks the PDU session counter of the slice to see if the number of PDU sessions in the slice is below a maximum value. If the NCMF indicates that the number of PDU sessions is below the maximum value, the PDU session will be allowed, otherwise it will not be allowed, and the PDU session setup request will be rejected.

In step 3, the rest of the PDU session setup procedure of TS 23.501 is performed and a PDU session setup response is sent to the UE. If the NCMF indicates to the AMF or SMF that the PDU session should not be allowed (i.e., the slice has reached the maximum number of PDU sessions), the AMF or SMF may send an error/cause code to the UE to indicate that the network slice has reached its maximum limit for the PDU session count and reject the request. In this case, the UE may reevaluate its URSP rule and attempt to establish a PDU session within a different slice. The response may also include a wait timer that indicates how long the UE must wait before attempting to establish a PDU session within the same slice. However, if the UE terminates the PDU session with the same slice before the waiting timer expires, the UE may reset the waiting timer and try again. The latency may be integrated into the time window (route selection verification criteria) in the URSP rule. Thus, the URSP rules are re-evaluated before re-attempting to establish a PDU session.

After receiving the PDU session setup reject message, the UE may:

in case it is known that a reject slice is not available, reevaluate its URSP rule and attempt to establish a PDU session based on a lower priority URSP or RSD rule.

Wait for the duration of the waiting timer and then reevaluate its URSP rule and attempt to establish a PDU session again within the same slice.

Terminate the PDU session with the same slice, if the wait timer has not expired, clear/invalidate the wait timer, then reevaluate its URSP rule and attempt to establish the PDU session again within the same slice. A modify PDU session setup request is proposed to allow the UE to indicate the PDU session ID in a slice that can be terminated. Such enhancements to the PDU session establishment procedure may be desirable if the slicing is PDU session limited and the UE is willing to terminate lower priority PDU sessions, provided that the UE can immediately re-establish a new, higher priority PDU session.

Handling maximum PDU sessions using NAS notification

This section describes methods in which NAS notification is used to notify the UE that the network slice has reached its maximum limit. This method is depicted in fig. 16.

At step 0, the network slice is configured with a limit on the maximum allowed number of PDU sessions per slice. This is either configured in NCMF. The NCMF includes a PDU session counter that counts the number of PDU sessions joined in the network slice. The session counter increments or decrements the number by 1 for each PDU session established or released, respectively. The NCMF may receive a notification from the SMF when the PDU session is established. AMFs and SMFs within a slice subscribe to NCMF in order to be notified when the number of PDU sessions within a slice reaches a maximum or falls below a maximum.

In step 1, the UE and the network perform a PDU session setup procedure as described in section 4.3.2.2.1 of 3GPP TS 23.502. Upon receiving a PDU session setup request from the UE, the AMF or SMF sends a request to the NCMF to check whether a new PDU session can be established in the slice. The request includes an S-NSSAI. The NCMF checks the PDU session counter of the slice to see if the number of PDU sessions in the slice is below a maximum value. If the NCMF indicates that the number of PDU sessions is below the maximum value, the PDU session will be allowed, otherwise it will not be allowed, and the PDU session setup request will be rejected. The case where the PDU session is rejected is described previously in this document. In the example of this procedure, it is assumed that the PDU session establishment is successful.

At step 2, the AMF or SMF receives a notification from the NCMF that the network slice has reached the maximum number of PDU sessions.

In step 3, the AMF sends NAS notification to all UEs registered to the slice. The NAS notification includes a wait timer that indicates how long the UE must wait before attempting to establish a PDU session within the slice. However, if the UE terminates the PDU session with the same slice before the waiting timer expires, the UE may reset the waiting timer and try again. The latency may be integrated into the time window of the routing verification criteria in the URSP rule. The URSP rules will be reevaluated before re-attempting to establish a PDU session.

In step 4, wait for the timer to expire or the UE terminates the PDU session with the same slice.

In step 5, the PDU session termination procedure decrements the NCMF counter, thereby dropping the PDU session counter below a predetermined value. When the number of PDU sessions within a slice is below a predetermined value, the NCMF sends a notification to the AMF and SMF.

At step 6, the AMF sends NAS notification to all UEs registered to the slice. The NAS notification indicates that the status has been cleared so that a PDU session can now be established in the slice. Alternatively, the notification may be sent only to UEs whose PDU session establishment request was rejected with the reason code.

In step 7, the UE may reset the waiting timer and attempt to establish a PDU session in the slice.

Handling maximum number of UEs in a network slice

The network may be provided with the capability to limit the maximum number of UEs that can be simultaneously registered with the network slice. There may be situations where the network may receive a request from a UE to register to a network slice that has reached its maximum registered UE limit. This section describes methods for handling this situation. Fig. 17 depicts this approach.

At step 0, a counter may be maintained in the NCMF. For each UE registered or deregistered, the counter increments or decrements the count by 1. When the UE registers or deregisters, the AMF may send an indication/notification to the NCMF so that the counter may be incremented or decremented accordingly. The NCMF may have subscribed to all AMFs in a slice so that it can receive notifications when a UE registers to that slice. The subscription request may indicate S-NSSAI and the notification from the AMF may include the UE ID and S-NSSAI, so that the NCMF may track which UEs are registered, query the status of the registered UEs, and avoid counting errors in case of receiving notification about registration or de-registration of a UE. The NCMF may also indicate to the AMF that the number of UEs registered to the slice is limited, so that the AMF knows to verify with the NCMF the permission to register new UEs (i.e., check that the limit has not been reached).

In step 1, the UE (UE1) and the network perform a UE registration procedure as described in section 4.2.2.2.2 of 3GPP TS 23.502. Upon receiving a UE registration request from the UE1, the AMF sends a request to the NCMF or invokes the NCMF service to check if a new UE can be registered in the slice. The request includes an S-NSSAI. The NCMF checks the UE registration counter of the slice to see if the number of UEs registered in the slice is below the maximum value. If the NCMF indicates that the number of UEs registered in the slice is below the maximum value, UE registration is allowed, otherwise UE registration will not be allowed and the UE registration request will be rejected. In this step of the procedure, it is assumed that the UE registration from the UE1 was successful.

In step 2, the AMF may receive notification from the NCMF that the network slice has reached the maximum number of UEs. The NCMF may provide a wait timer to the AMF to indicate how long the UE should wait before re-attempting to register with the S-NSSAI.

In step 3, a different UE (e.g., UE2) may send a UE registration request to the network. For each slice, the request may indicate that if registration for the slice is denied, the UE wishes to receive a notification when the denial reason is cleared.

Note that: if the AMF has not received notification from the NCMF that the network slice has reached the maximum number of UEs, the AMF may query the NCMF to check if the UEs can be registered, as described in step 1.

At step 4, if the AMF has been informed that the network slice has reached its maximum number of UE registration limits, the AMF may send a UE registration response message to the UE2 indicating that the request has been rejected and a cause value indicating that the request was rejected because the slice has reached the maximum number of registered UEs. The rejection may also provide the UE with a wait timer that the UE should use to determine when it may attempt to request UE registration again in the same slice. Otherwise, if the slice limit is not reached, the UE2 and the network perform a registration procedure as described in section 4.2.2.2.2 of 3GPP TS 23.502.

At step 5, a UE (e.g., UE3) that has registered in the network slice may deregister from the network slice.

At step 6, the AMF may inform the NCMF that the UE deregisters. NCMF can decrement the counter. In addition, the NCMF may send a notification so that the AMF knows that the network slice is now below its maximum limit.

At step 7, the AMF may send a NAS notification to any UE (e.g., UE2) that is denied registration with a reason code (i.e., a message that the maximum limit and wait timer is reached for the network slice) and has a wait timer still running. The NAS notification indicates that the restriction condition has been removed.

At step 8, upon receiving the NAS message from the network, the UE2 may reset the wait timer and attempt to register with the slice.

Alternatively, the UE may attempt UE registration after the wait timer expires.

Note that this process can be considered an extension or enhanced interpretation of the network capability based registration process described earlier in this document.

Processing of maximum UL and DL data rates within a slice

As described above, the network may provide the UE with the maximum UL and DL data rates that the UE may use within a slice. These maximum data rates apply to all PDU sessions within a slice.

The network may also provide this information to the UE whenever a PDU session is established within a slice.

The network may send a NAS notification to the UE whenever the network detects that the UE has exceeded the maximum UL or DL data rate within the slice. The notification may indicate a maximum UL or DL data rate to the UE so that the UE may perform the maximum UL or DL data rate.

NCMF service

As described above, NCMF is responsible for managing and maintaining information related to network capabilities and network slices. Table 5 represents a list of NCMF services that may be provided to enable these operations.

Table 1: list of NCMF services

Alternatively, if the NCMF is co-located with the NSSF or UDM/UDR, the NCMF service shown in table 5 may be defined as an NSSF service or UDM/UDR service.

New UPF service

In the 5G service-based architecture, the UPF is not involved as a user plane function. However, it can be seen that the UPF has some control functions, such as QoS enforcement, data caching, and event monitoring. By extending the service-based architecture to UPFs, some UPF services can be added. Figure 11 shows an extended service-based architecture with UPF and Nupf interfaces. Table 6 shows a list of UPF services.

Table 2: list of UPF services

Nupf_EventExposure

The service provides that other NFs subscribe to certain events at the UPF and are notified when the subscribed events occur. The UPF may provide subscription services for the following events:

DL data packets buffered in the UPF are discarded due to a timeout threshold or limited storage space. This may be per QoS flow, per session, per UE, or per UPF.

The UPF is selected as the branch point for the uplink classifier or multi-homed PDU session of the local data network.

The UPF is selected as the anchor point for the PDU session via 3GPP access or non-3 GPP access (i.e., through N3 IWF).

Packets are dropped because policy rules are enforced on specific traffic by UPF, including information of the SCS/AS that originated the traffic, and what specific rules are enforced.

The total number of connected UEs supported by the UPF exceeds a certain threshold.

The total number or ratio of rejected or failed connection attempts exceeds a threshold. This may further qualify to request a notification if the total number or ratio of rejected or failed connection attempts with a particular cause value exceeds a threshold.

The computational resources are below a threshold.

The total number of sessions being managed by the UPF exceeds a certain threshold.

The total (guaranteed) data rate of the session that the UPF is managing exceeds a certain threshold.

The utilization of the memory allocated for the downlink data buffer exceeds a certain threshold.

In case no PDR fits the application data, the mapping of DL data flow to QoS flow fails.

The following information may be involved in the (de) subscription request or notification message:

subscription ID

Notification Address/ID

Event ID and corresponding parameters: for example, if the event that occurs is PDU session congestion, then PDU session ID, QFI and resource utilization will be included. If the event that occurs is that a packet is dropped, the reason for the drop, the session ID, QFI, and the number of packets buffered in the UPF will be provided.

The NEF may be a service consumer in case the AF cannot directly access the UPF via the service based interface.

Nupf_StatusMonitoring

The service provides the NF with an opportunity to obtain information from the UPF regarding the PDU session status and QoS enforcement status. The UPF may provide the following information through the service:

the number of PDU sessions the UPF acts as anchor point, branch point or uplink classifier, respectively.

The amount of downlink data buffered at the UPF. This may be per application, per UE, per group of UEs, per PDU session, per QoS flow, or per location (i.e., within the network area).

The number of PDU sessions connecting the UE via non-3 GPP access.

The currently implemented bit rate. This may be per application, per UE, per group of UEs, per PDU session, per QoS flow, or per location (i.e., within the network area).

Packet error rate (loss rate). This may be per application, per UE, per group of UEs, per PDU session, per QoS flow, or per location (i.e., within the network area).

The percentage of storage resources used for data caching. Charging related information such as CDR.

The NEF may be a service consumer in case the AF cannot directly access the UPF via the service based interface.

Nupf_PDUSession

This service provides SMF the ability to initiate certain procedures to manage PDU sessions, such as creating, updating, and releasing PDU sessions. The SMF may include the following information for the PDU session related procedure:

PDU Session ID and associated network slice ID, such as S-NSSAI and network slice instance ID

·DNN

PDU session type, e.g. non-IP, Ethernet or IP type

Session and Service Continuity (SSC) mode

QFI and related QoS parameters, such as maximum bit rate per QoS, maximum aggregated bit rate per session, maximum packet loss rate

Indication of support for reflection QoS

Packet Detection Rules (PDR) for both DL and UL traffic

SMF information, such as SMF ID, SMF instance ID

Tunnel information for N3 and N6 (e.g., for NIDD forwarding) tunnels, respectively

Charging policy ID

An indication to add or remove a UPF as an uplink classifier or branching point associated with a PDU session.

UE IDs, such as 5G-GUTI and SUPI

IP address and port number

Example graphical user interface

Fig. 12 shows an example user interface that may be used to configure network capabilities in a 5G network. The user interface may be displayed by or for a terminal device (UE), a service provider (SCS/AS), a network operator, or other network entity or user. For example, the user interface may be displayed on the displays 128 or 86 of FIGS. 1B and 1G, respectively.

Fig. 18 depicts a user interface through which a UE may receive NCPs for allowed S-NSSAIs from a network. Based on the application requirements, the UE may accept network slices based on the received NCPs or request new NCPs/network slices from the core network.

It should be understood that the above-described network entities, including those performing the steps shown in fig. 8-10, such AS the UE, (R) AN, AMF, NCMF, NSSF, UDR/UDSF, UDM/UDR, NRF, NEF, PCF, NF, SCS/AS, (R) AN, SMF, etc., may be logical entities that may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of a device configured for wireless and/or network communication or a computer system such AS shown in fig. 1B or fig. 1G and executed on a processor thereof. That is, the methods shown in FIGS. 8-10 may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of a device, such as the device or computer system shown in FIG. 1B or FIG. 1G, that when executed by a processor of the device, perform the steps shown in FIGS. 8-10. It should also be understood that the functions shown in fig. 8-10 may be implemented as a set of virtualized network functions. The network functions do not necessarily communicate directly, but rather they may communicate via forwarding or routing functions. It should also be understood that any of the transmitting and receiving steps shown in fig. 8-10 may be performed by the communication circuitry of the device under the control of the processor of the device and computer-executable instructions (e.g., software) executed by the processor.

Additional embodiments may include:

1. an apparatus comprising a processor and a memory, the memory storing computer-executable instructions that, when executed by the processor, cause the apparatus to perform operations comprising:

sending a network capability configuration request to an entity of a core network of a communication network, the request including a list of one or more network capabilities requested by the device; and

receiving a response from an entity of the core network containing an identifier of a network slice supporting the requested one or more network capabilities.

2. The apparatus as in embodiment 1, wherein the request further comprises one or more of:

an identifier of each of the requested one or more network capabilities;

network slice selection information and/or one or more network slice IDs to support the requested one or more network capabilities; and

an identifier of each of one or more applications hosted on the device that require the requested network capabilities.

3. An apparatus as in embodiment 2, wherein the request further comprises one or more of:

an identifier of the device;

an identifier of a Public Land Mobile Network (PLMN) with which the device can register;

information associated with a geographic area in which the device is requesting network capabilities.

4. An apparatus as in embodiment 2, wherein the request further comprises one or more of:

information specifying an availability schedule associated with the requested one or more network capabilities;

information specifying a quality of service (QoS) level associated with the requested one or more network capabilities; and

information specifying a multi-tenant level associated with the requested one or more network capabilities.

5. A method by a User Equipment (UE), comprising:

sending a network capability configuration request to an entity of a core network of a communication network, the request comprising a list of one or more network capabilities requested by the UE; and

receiving a response from an entity of the core network containing an identifier of a network slice supporting the requested one or more network capabilities.

6. A method as described in embodiment 5, wherein the request further includes one or more of:

an identifier of each of the requested one or more network capabilities;

network slice selection information and/or one or more network slice IDs to support the requested one or more network capabilities; and

an identifier of each of one or more applications hosted on the UE that require the requested network capabilities.

7. A method as described in embodiment 6, wherein the request further includes one or more of:

an identifier of the UE;

an identifier of a Public Land Mobile Network (PLMN) to which the UE may be registered;

information associated with a geographic area in which the UE is requesting network capabilities.

8. A method as described in embodiment 6, wherein the request further includes one or more of:

information specifying an availability schedule associated with the requested one or more network capabilities;

information specifying a quality of service (QoS) level associated with the requested one or more network capabilities; and

information specifying a multi-tenant level associated with the requested one or more network capabilities.

9. An apparatus that implements an entity of a core network, the apparatus comprising a processor and a memory, the memory storing computer-executable instructions that, when executed by the processor, cause the entity of the core network to perform operations comprising:

receiving, from a User Equipment (UE), a request including a list of one or more network capabilities requested by the UE;

determining whether a network slice currently serving the UE supports the requested one or more network capabilities based on a network capability profile associated with the network slice currently serving the UE;

if the network slice currently serving the UE cannot support the requested one or more network capabilities, formulating or selecting a new network slice capable of supporting the requested one or more network capabilities to serve the UE; and

sending a response to the UE including an identifier of a network slice selected to support the requested one or more network capabilities.

10. An apparatus as in embodiment 9, wherein the network capability profile comprises one or more of:

an identifier of a network slice and a corresponding network slice instance;

a list of identifiers of supported network capabilities;

an identifier of a serving PLMN; and

service area information for each network capability.

11. An apparatus as in embodiment 9, wherein the request further comprises one or more of:

an identifier of each of the requested one or more network capabilities;

network slice selection information and/or one or more network slice IDs to support the requested one or more network capabilities; and

an identifier of each of one or more applications hosted on the user device that require the requested network capabilities.

12. An apparatus as in embodiment 9, wherein the instructions further cause an entity of the core network to perform operations comprising initiating a new network slice.

13. An apparatus as in embodiment 9, wherein the instructions further cause an entity of the core network to perform operations comprising: a new core network entity is selected that terminates non-access stratum (NAS) signaling with the UE serving the newly selected network slice.

14. An apparatus as in embodiment 9, wherein the instructions further cause an entity of the core network to perform operations comprising updating a network capability profile associated with the newly selected network slice.

15. A method performed by an entity of a core network, comprising:

receiving, from a User Equipment (UE), a request including a list of one or more network capabilities requested by the UE;

determining whether a network slice currently serving the UE supports the requested one or more network capabilities based on a network capability profile associated with the network slice currently serving the UE;

if the network slice currently serving the UE cannot support the requested one or more network capabilities, formulating or selecting a new network slice capable of supporting the requested one or more network capabilities to serve the UE; and

sending a response to the UE including an identifier of a network slice selected to support the requested one or more network capabilities.

16. A method as described in embodiment 15, wherein the network capability profile includes one or more of:

an identifier of a network slice and a corresponding network slice instance;

a list of identifiers of supported network capabilities;

an identifier of a serving PLMN; and

service area information for each network capability.

17. A method as described in embodiment 15, wherein the request further includes one or more of:

an identifier of each of the requested one or more network capabilities;

network slice selection information and/or one or more network slice IDs to support the requested one or more network capabilities; and

an identifier of each of one or more applications hosted on the user device that require the requested network capabilities.

18. A method as described in embodiment 15, further comprising initiating a new network slice.

19. The method as in embodiment 15 further comprising selecting a new core network entity that terminates non-access stratum (NAS) signaling with the UE serving the newly selected network slice.

20. A method as described in embodiment 15, further comprising updating the network capability profile associated with the newly selected network slice.

21. An apparatus comprising a processor and a memory, the memory storing computer-executable instructions that, when executed by the processor, cause the apparatus to perform operations comprising:

receiving a message from an access and mobility management function (AMF) of a network slice in a core network of a communication network, wherein the message comprises a request to determine whether a threshold is satisfied; and

sending a response to the message to the AMF.

22. An apparatus as in embodiment 21, where the apparatus may have subscribed to access and mobility management functions in the network slice, such that the apparatus may be notified when a user equipment requests registration to the slice or attempts to establish a PDU session with the network slice.

23. The apparatus as in embodiment 21, where the request contains a network slice identifier and a user equipment identification.

24. An apparatus as in embodiment 21, where the apparatus employs a counter that counts up or down for each user equipment that registers or deregisters to a network slice of a core network.

25. An apparatus as in embodiment 21, where the apparatus employs a counter that increments or decrements for each PDU session that the user equipment establishes or terminates with a network slice of a core network.

26. An apparatus as in embodiment 21, wherein the response to the AMF comprises a notification indicating that the network slice has reached its threshold.

27. The apparatus as in embodiment 21, where the response to the access and mobility management functions includes a wait timer indicating how long the user equipment should wait before reattempting to register with the network slice or reattempting to establish a PDU session with the network slice when the threshold is reached.

The illustrations of aspects described herein are intended to provide a general understanding of the structure, function, and operation of the aspects. The illustrations are not intended to serve as a complete description of all of the elements and features of apparatus and systems that utilize the structures or methods described herein. Many other aspects may be apparent to those of skill in the art upon reading this disclosure. Other aspects may be utilized and derived from the disclosure, such that structural and logical substitutions and changes may be made without departing from the scope of the disclosure. The present disclosure and figures are, therefore, to be regarded as illustrative rather than restrictive.

The description of these aspects is provided to enable its manufacture or use. Various modifications to these aspects will be readily apparent, and the generic principles defined herein may be applied to other aspects without departing from the scope of the disclosure. Thus, the present disclosure is not intended to be limited to the aspects shown herein but is to be accorded the widest scope possible consistent with the principles and novel features as defined by the following claims.