Dynamic network capacity configuration

Abstract

Methods and devices for configuring desired network capabilities in a service-based network are described, including a method for a UE to initiate a network capabilities-based registration to configure its desired network capabilities, a method for UEs to initiate a network capabilities-based registration upgrade when UEs are already registered in the network and wish to dynamically reconfigure their network capabilities, and a method for a network capabilities-based UE configuration upgrade, which allows NFs or ASs to initiate the upgrade of network capabilities in a portion of the network for the UE.

Description

Dynamic network capacity configuration Cross-reference to related applications This application claims the benefit of priority of U.S. application No. 62 / 817811, filed on March 13, 2019, and U.S. application No. 62 / 931376, filed on November 6, 2019. Background The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities, encompassing 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. 3GPP has begun work on standardizing the next-generation cellular technology, called New Radio (NR), which is also referred to as "5G." The 5G core network (5GC) comprises a service-based architecture (SBA) based on the concept of network segmentation and virtualized network functions (NFs). Different network functions, such as the Access and Mobility Management Function (AMF), the Session Management Function (SMF), and the Policy Control Function (PCF), provide different network function services through the service-based interface. This means that the service consumer can use the same message and procedure to communicate with the service provider. For example, any NF can subscribe to the same event using the event exposure service provided by the AMF. Furthermore, various network capabilities, such as non-IP data distribution (NIDD), background data transfer (BDT), and power saving mode (PSM), can be implemented through a set of NF services.Under the current SBA framework, a UE can configure and access the network by providing the requested Network Segment Selection Assistance Information (NSSAI), which identifies network segment(s). There is no way for the UE to directly specify desired network capabilities. US Patent 2019 / 029065 A1 discloses a method for a user team to update a policy in a wireless communication system. US Patent 2018 / 034924 A1 discloses a network segment selection. Summary While under the current 5GC SBA framework, a UE can configure and access the network by indicating the requested NSSAI, which identifies network segment(s), there is no way for the UE to directly indicate desired network capabilities. This document discloses methods and apparatus for configuring desired network capabilities in a service-based network. The invention is defined by the appended claims. In one aspect, a new framework is described that includes a network capacity layer. An UE and an AS can dynamically request network capacity (e.g., background data transfer, non-IP data delivery) to support their applications. In one implementation, the UE and AS may not need to know or care about which network segment supports the requested network capacity, or even whether the service network segment can support it. A central network entity can determine and configure a network segment that supports all the requested network capacities. In another aspect, a method is described for a UE to initiate a network capability-based registration to configure its desired network capabilities. In another aspect, a method is described for UEs to initiate a network capability-based registration update when UEs are already registered on the network and want to dynamically reconfigure their network capabilities. In another aspect, a method is described for a UE configuration update based on network capability, which allows NFs or application servers to initiate the update of network capabilities in the network segment for the UE. An extended service-based architecture is also described, which includes interfaces with a User Plane Function (UPF) and services provided by a UPF. A mechanism by which the network can deliver network capacity information called Network Capacity Profile (NCP) for a network segment to the UE. A method by which a UE can be informed by the network about an alternative network segment with a comparable network capacity profile based on the network capacity requested by the UE. A mechanism for UEs to initiate a network capacity-based registration to configure their desired network capabilities. A mechanism by which a UE can receive a set of permitted S-NSSAIs with their corresponding NCPs during the general UE registration procedure. The UE may be able to request an alternative network segment based on the list of permitted S-NSSAI NCPs received from the core network if the capacities indicated by the received NCPs are insufficient for the applications in the UE. A mechanism by which NCPs for network segment(s) are delivered to the UE as part of the UE Policies during the UE Policy update procedure. The mechanisms by which the core network applies the maximum number of PDU sessions per network segment and handles requests received after the maximum limit has been reached during the PDU session establishment procedure. A mechanism in which the core network manages the maximum limit on the number of PDU sessions per network segment in which the network periodically informs the UE via the NAS message that the network segment has reached its maximum limit so that the UE can wait before trying again. A mechanism by which the core network applies the maximum number of EU registrations per network segment and handles registration requests received after the maximum limit has been reached. This summary is provided to introduce a selection of concepts in a simplified manner, which are further described below in the detailed description. This summary is not intended to identify key features or essential characteristics 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 by limitations that resolve any or all of the disadvantages noted anywhere in this disclosure. Brief description of the drawings A more detailed understanding can be obtained from the following description, given as an example along with the accompanying drawings, in which: Figure 1A illustrates an example communications system; Figure 1B is a block diagram of an example apparatus or device configured for wireless communications such as, for example, a wireless transmit / receive unit (WTRU); Figure 1C is a system diagram of an example radio access network (RAN) and core network; Figure 1D is a system diagram of another example RAN and core network; Figure 1E is a system diagram of another example RAN and core network; Figure 1F is a system diagram of another example RAN and core network; Figure 1G is a block diagram of an example computer system in which a node, entity, device, or other apparatus of a communication system can be materialized; Figure 2A shows the non-roaming 5G reference architecture with service-based interfaces to the control plane; Figure 2B shows the architecture of the non-roaming 5G system in reference point representation; Figure 3 shows an example of network function, NF service and NF service operation; Figure 4 shows an example of an NF "request-response" service; Figure 5 shows an example of an NF "subscriber notification" service; Figure 6 shows a network capacity configuration use case; Figure 7 shows an example network architecture with a network capacity layer; Figure 8 shows a method for registration based on network capacity; Figure 9 shows a method for updating the record based on network capacity; Figure 10 shows a method for UE configuration update based on network capacity; Figure 11 shows an example extended service-based architecture with a UPF interface and a Nupf interface; and Figure 12 shows an example graphical user interface (GUI) for network configuration capability in a communications network. Figure 13 shows a method for the registration procedure with network capacity profile for the requested NSSAI. Figure 14 shows a method for delivering the network capacity profile to the EU as part of EU policy. Figure 15 shows a method for handling the maximum number of PDU sessions on a network segment per network. Figure 16 shows a method for handling the maximum number of PDU sessions on a network segment using a NAS notification. Figure 17 shows a procedure for handling the maximum number of UEs in a network segment. Figure 18 shows an example graphical user interface (GUI) that shows the UE receiving NCPs from the network and the UE accepting NCPs or being able to request new NCPs. Detailed description of illustrative realizations The following is a list of acronyms that may appear in the description below. Unless otherwise specified, the acronyms used in this report refer to the corresponding terms listed below: 5GC 5G Core AF Application Function AMF Access and Mobility Management Function AS Application Server CN Central Network CP Control Plane DL Downlink DNN Data Network Name EPC Evolved Package Core GUTI Globally Unique Temporary Identifier LTE Long-term evolution MBMS Multimedia Broadcasting / Multicasting Service MME Mobility Management Entity NAS Unaccessible Stratum NCMF Network Capacity Management Function NCP Network Capability Profile NEF Network Exposure Function NF Network function NIDD Non-IP Data Delivery NRF NF deposit function NSSAI Network Segment Selection Support Information NSSF Network Segment Selection Function NSI Network Segment Instance 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 Capacity Server SD Segment Differentiator SM Session Management SMF Session Management Function SMSF Short Message Service (SMS) function S-NSSAI Single Network Segment Selection Support Information SST Segment / Service Type SUPI Permanent Subscription Identifier UDM / UDR Unified Data Management / Unified Data Repository EU User Team UL Uplink UPF User Plane Function The following terms may have the following meanings: "Core network" refers to the central, or core, part of a telecommunications network, which provides numerous communication services to customers interconnected by the radio access network. A core network typically comprises several entities that perform core network functionality. As used herein, the term "core network entity" refers to any entity that performs core network functionality, such as, for example, an AMF, UDR / UDSF, UDM / UDR, NRF, NEF, PCF, NF, SMF, AUSF, NSSF, or similar, as described herein. Such core network entities may be logical entities implemented in the form of software (i.e., computer-executable instructions) stored in memory and executed on a processor, an apparatus configured for wireless and / or network communications, or a computer system such as those illustrated in Figure 1B or Figure 1G. "Network Function (NF)" refers to a processing function in a network, which has a defined functional behavior and defined interfaces. An NF can be implemented as a network element on dedicated hardware, or as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform, for example, in a cloud infrastructure. "Network function instance" refers to an identifiable instance of an NF. A "network function (NF) service" can be a type of capability exposed by one NF ("NF service producer") to another authorized NF ("NF service consumer") through a service-based interface. A network function can expose one or more NF services. For example, the 5G AMF provides a Namf_ResourceRequest 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. A "network capability" comprises a transport network feature that the core network implements and provides to its users (for example, a UE or application server). Examples of network capabilities include background data transfer and event monitoring. A network capability is enabled through one or more Network Functions (NFs) services. A "network segment" is a logical network that provides specific network capabilities and features. A "network segment instance" comprises a set of NF instances and the required resources (e.g., computing, storage, and network resources) that form a deployed network segment. A "network capability profile" is an information profile for each network segment maintained by NCMF, indicating what network capabilities are supported by a network segment. A "network capacity management function" is a network configuration (NF) that configures the network segment to serve the UE / AS with a desired set of network capabilities. The NCMF can be part of the OAM system. The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, the 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. 3GPP has begun working on the standardization of next-generation cellular technology, called New Radio (NR), also known as "5G." The development of NR standards by 3GPP is expected to include the definition of next-generation radio access technology (New RAT), which is expected to include the provision of flexible new radio access below 6 GHz and the provision of ultramobile broadband new radio access above 6 GHz.Flexible radio access is expected to consist of a new, non-backward compatible radio access in a new spectrum below 6 GHz. It is expected to include different operating modes that can be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with divergent requirements. Ultramobile broadband is expected to include centimeter-wave and millimeter-wave spectrum, providing ultramobile broadband access opportunities for applications such as indoors and hotspots. In particular, ultramobile broadband is expected to share a common design structure with flexible radio access below 6 GHz, with centimeter-wave and millimeter-wave-specific design optimizations. 3GPP has identified a variety of use cases that New Radio (NR) is expected to support, resulting in a wide range of user experience requirements for data rate, latency, and mobility. These use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, indoor ultra-high-speed broadband access, broadband access in crowds, 50+ Mbps everywhere, ultra-low-cost broadband access, mobile broadband in vehicles), mission-critical communications, massive machine-type communications, network operations (e.g., network segmentation, routing, migration and interconnection, power saving), and enhanced vehicle-to-everything (eV2X) communications.Specific services and applications in these categories include, for example, monitoring and sensor networks, remote device control, two-way remote control, personal cloud computing, video streaming, cloud-based wireless office, first responder connectivity, automotive e-calling, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, and virtual reality, to name a few. All of these use cases and others are covered in this document. Figure 1A illustrates an embodiment of an exemplary communications system 100 in which the methods and apparatus described and claimed herein may be materialized. As shown, the exemplary communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c and / or 102d (which may generally or collectively be referred to as WTRU 102), a radio access network (RAN) 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 will be appreciated that disclosed embodiments include any number of WTRUs, base stations, networks and / or network elements. Each of the WTRU 102a, 102b, 102c, 102d, 102e can be any type of appliance or device configured to operate and / or communicate in a wireless environment.Although each WTRU 102a, 102b, 102c, 102d, 102e is represented in Figures 1A-G as a handheld wireless communications apparatus, it is understood that with the wide variety of use cases envisaged for 5G wireless communications, each WTRU may comprise or materialize in any type of apparatus or device configured to transmit 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 cell phone, a personal digital assistant (PDA), a smartphone, a laptop computer, a tablet, an electronic organizer, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smartwatch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train or airplane, and the like. The 100 communications system may also include a 114a base station and a 114b base station. Base stations 114a can be any type of device configured to interact wirelessly with at least one of the WTRU 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, Internet 110 and / or the other 112 networks. Base stations 114b can be any type of device configured to interact wired and / or wirelessly with at least one of the RRH (Remote Radio Heads) 118a, 118b and / or TRP (Transmit and Receive Points) 119a, 119b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, Internet 110 and / or the other 112 networks.RRH 118a, 118b can be any type of device configured to interact wirelessly with at least one of the WTRU 102c, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, Internet 110, and / or the other 112 networks. TRP 119a, 119b can be any type of device configured to interact wirelessly with at least one of the WTRU 102d, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, Internet 110, and / or the other 112 networks. For example, base stations 114a, 114b can be a Base Transceiver Station (BTS), a Node-B, an eNode-B, a Local Node-B, a Local eNode-B, a Site Controller, an Access Point (AP), or a Wireless Router and similar.Although base stations 114a, 114b are each represented as a single element, it will be appreciated that base stations 114a, 114b can include any number of interconnected base stations and / or network elements. Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), relay nodes, etc. Base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), relay nodes, etc. Base station 114a may be configured to transmit and / or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The 114b base station can be configured to transmit and / or receive wired and / or wireless signals within a particular geographic region, which can be called a cell (not shown). The cell can be further divided into cell sectors.For example, the cell associated with base station 114a can be divided into three sectors. Therefore, in one embodiment, base station 114a can include three transceivers, for example, one for each sector of the cell. In one embodiment, base station 114a can employ multiple-input multiple-output (MIMO) technology and, therefore, can use multiple transceivers for each sector of the cell. The 114a base stations can communicate with one or more of the 102a, 102b, and 102c WTRUs via an air interface 115 / 116 / 117, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115 / 116 / 117 can be established using any suitable radio access technology (RAT). Base stations 114b can communicate with one or more RRH 118a, 118b and / or TRP 119a, 119b via a wired or air interface 115b / 116b / 117b, which can be any suitable wired (e.g., cable, fiber optic, etc.) or wireless (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.) communication link. The air interface 115b / 116b / 117b can be established using any suitable radio access technology (RAT). The RRH 118a, 118b and / or the TRP 119a, 119b can communicate with one or more of the WTRU 102c, 102d via an air interface 115c / 116c / 117c, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115c / 116c / 117c can be established using any suitable radio access technology (RAT). More specifically, as stated above, the 100 communications system can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base station 114a in RAN 103 / 104 / 105 and WTRUs 102a, 102b, 102c, or RRHs 118a, 118b and TRPs 119a, 119b in RAN 103b / 104b / 105b and WTRUs 102c, 102d, can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interface 115 / 116 / 117 or 115c / 116c / 117c respectively using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or HSPA Evolved (HSPA+). HSPA may include high-speed downlink packet access (HSDPA) and / or high-speed uplink packet access (HSUPA). In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c, or RRHs 118a and 118b and TRPs 119a and 119b in RAN 103b / 104b / 105b and WTRUs 102c and 102d, can implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish air interface 115 / 116 / 117 or 115c / 116c / 117c respectively using Long-Term Evolution (LTE) and / or LTE Advanced (LTE-A). In the future, air interface 115 / 116 / 117 can implement 3GPP NR technology. In one embodiment, base station 114a in RAN 103 / 104 / 105 and WTRUs 102a, 102b, 102c or RRHs 118a, 118b and TRPs 119a, 119b in RAN 103b / 104b / 105b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA20001X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), and Data Rates Improved for GSM Evolution (EDGE), GSM Edge (GERAN) and similar. The 114c base station in Figure 1A can be a wireless router, a home Node B, a home eNode B, or an access point, for example, and can utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the 114c base station and the 102e WTRUs can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the 114c base station and the 102d WTRUs can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the 114c base station and the 102e WTRU can use a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell.As shown in Figure 1A, base station 114b can have a direct connection to Internet 110. Therefore, base station 114c may not be required to access Internet 110 through the core network 106 / 107 / 109. RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b may be in communication with core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. For example, core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be seen that RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that use the same RAT as RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT. For example, in addition to connecting to RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may be using E-UTRA radio technology, core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that uses GSM radio technology. The core network 106 / 107 / 109 can also serve as a gateway for WTRUs 102a, 102b, 102c, 102d, and 102e to access PSTN 108, Internet 110, and / or other 112 networks. PSTN 108 may include circuit-switched telephone networks providing Plain Old Telephone Service (POTS). Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) within the TCP / IP Internet protocol suite. 112 networks may include wired or wireless communication networks owned and / or operated by other service providers. For example, 112 networks may include another core network connected to one or more RANs, which may employ the same RAT as RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT. Some or all of the WTRU 102a, 102b, 102c, and 102d units in the 100 communications system may include multimode capabilities. For example, WTRU 102a, 102b, 102c, 102d, and 102e units may include multiple transceivers to communicate with different wireless networks over different wireless links. For example, the WTRU 102e unit shown in Figure 1A may be configured to communicate with base station 114a, which may employ cellular-based radio technology, and with base station 114c, which may employ IEEE 802 radio technology. Figure 1B is a block diagram of an example apparatus or device configured for wireless communications according to the embodiments illustrated herein, such as, for example, a WTRU 102. As shown in Figure 1B, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, a display / touch panel / indicators 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the above elements while remaining consistent with one embodiment.Furthermore, the embodiments contemplate that base stations 114a and 114b, and / or the nodes that base stations 114a and 114b can represent, such as, but not limited to, a base transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), an evolved home node-B (HeNB), a home evolved B gateway, and proxy nodes, among others, may include some or all of the elements represented in Figure 1B and described herein. The processor 118 can 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 array circuits (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122.Although Figure 1B depicts the processor 118 and transceiver 120 as separate components, it will be seen that the processor 118 and transceiver 120 can be integrated together into one electronic package or chip. Transmit / receive element 122 can be configured to transmit signals to, or receive signals from, a base station (e.g., base station 114a) via air interface 115 / 116 / 117. For example, in one embodiment, transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmit / receive element 122 can be configured to transmit and receive both RF and light signals. It will be appreciated that transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals. Furthermore, although transmit / receive element 122 is represented in Figure 1B as a single element, the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can employ MIMO technology. Therefore, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) to transmit and receive wireless signals over the air interface 115 / 116 / 117. Transceiver 120 can be configured to modulate signals to be transmitted by transmit / receive element 122 and to demodulate signals received by transmit / receive element 122. As mentioned earlier, the WTRU 102 can have multimode capabilities. Therefore, transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate over multiple RATs, such as UTRA and IEEE 802.11, for example. The WTRU 102 processor 118 can be coupled to, and can receive user input data from, the speaker / microphone 124, the keyboard 126, and / or the display / touch panel / indicators 128 (for example, a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker / microphone 124, the keyboard 126, and / or the display / touch panel / indicators 128. In addition, the processor 118 can access information from, and store data in, any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.Removable memory 132 may include a subscriber identity module (SIM) card, a memory card, a secure digital memory (SD) card, and the like. In one embodiment, the processor 118 can access information from, and store data in, memory that is not physically located in the WTRU 102, such as in a server or a home computer (not shown). The processor 118 can receive power from the power source 134, and can be configured to distribute and / or control power to the other components in the WTRU 102. The power source 134 can be any device suitable for powering the WTRU 102. For example, the power source 134 can include one or more dry cell batteries, solar cells, fuel cells, and the like. The 118 processor can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) relative to the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 can receive location information via the air interface 115 / 116 / 117 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 can acquire location information by any suitable location determination method while remaining consistent with an embodiment. The processor 118 can also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, peripherals 138 may include various sensors such as an accelerometer, biometric sensors (e.g., fingerprint), an electronic compass, a satellite transceiver, a digital camera (for stills or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, and the like. The WTRU 102 can be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smartwatch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, or a vehicle such as a car, truck, train, or airplane. The WTRU 102 can be connected to other components, modules, or systems of such apparatuses or devices through one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 138. Figure 1C is a system diagram of the RAN 103 and the core network 106 according to one embodiment. As previously stated, RAN 103 can employ UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c over air interface 115. RAN 103 can also communicate with core network 106. As shown in Figure 1C, RAN 103 can include Node-Bs 140a, 140b, and 140c, each of which can include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c over air interface 115. Node-Bs 140a, 140b, and 140c can each be associated with a particular cell (not shown) within RAN 103. RAN 103 can also include RNCs 142a and 142b. It will be appreciated that RAN 103 can include any number of Nodes-B and RNCs while remaining consistent with an implementation. As shown in Figure 1C, Nodes-B 140a and 140b can communicate with RNC 142a. Additionally, Node-B 140c can communicate with RNC 142b. Nodes-B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via an Iub interface. RNCs 142a and 142b can communicate with each other via a lur interface. Each RNC 142a and 142b can be configured to control the respective Nodes-B 140a, 140b, and 140c to which it is connected. In addition, each of the RNC 142a, 142b can be configured to perform or support other functionality, such as external loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like. The core network 106 shown in Figure 1C may include a Media Gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a GPRS Service Support Node (SGSN) 148 and / or a GPRS Gateway Support Node (GGSN) 150. Although each of the above elements is represented as part of the core network 106, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator. RNC 142a on RAN 103 can be connected to MSC 146 on core network 106 via an IuCS interface. MSC 146 can be connected to MGW 144. MSC 146 and MGW 144 can provide WTRU 102a, 102b, and 102c with access to circuit-switched networks, such as PSTN 108, to facilitate communication between WTRU 102a, 102b, and 102c and traditional landline communication devices. RNC 142a on RAN 103 can also connect to SGSN 148 on core network 106 via an IuPS interface. SGSN 148 can be connected to GGSN 150. SGSN 148 and GGSN 150 can provide WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as Internet 110, to facilitate communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. As mentioned previously, core network 106 can also be connected to networks 112, which may include other wired or wireless networks owned and / or operated by other service providers. Figure 1D is a system diagram of RAN 104 and core network 107 according to one embodiment. As stated above, RAN 104 can employ E-UTRA radio technology to communicate with WTRU 102a, 102b, and 102c over air interface 116. RAN 104 can also be in communication with core network 107. RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it should be noted that RAN 104 can include any number of eNode-Bs while remaining consistent with one implementation. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, WTRU 102a. Each of the eNode-B 160a, 160b, and 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, uplink and / or downlink user scheduling, and similar tasks. As shown in Figure 1D, the eNode-B 160a, 160b, and 160c can communicate with each other via an X2 interface. The core network 107 shown in Figure 1D may include a Mobility Management Gateway (MME) 162, a Service Gateway 164, and a Packet Data Network (PDN) Gateway 166. Although each of the above elements is represented as part of the core network 107, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator. MME 162 can be connected to each of the eNode-B 160a, 160b, and 160c in RAN 104 via an S1 interface and can serve as a control node. For example, MME 162 can be responsible for authenticating users of WTRU 102a, 102b, and 102c, carrier activation / deactivation, selecting a particular service gateway during an initial connection of WTRU 102a, 102b, and 102c, and similar tasks. MME 162 can also provide a control plane function for switching between RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA. The service gateway 164 can be connected to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via interface S1. The service gateway 164 can route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The service gateway 164 can also perform other functions, such as anchoring user planes during handovers between eNode-Bs, triggering localization when downlink data is available for WTRUs 102a, 102b, and 102c, managing and storing contexts for WTRUs 102a, 102b, and 102c, and similar functions. The service gateway 164 can also be connected to the PDN gateway 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks, such as Internet 110, to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. The 107 core network can facilitate communications with other networks. For example, the 107 core network can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between WTRUs 102a, 102b, and 102c and traditional landline communication devices. For example, the 107 core network may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the 107 core network and the PSTN 108. Additionally, the 107 core network can provide WTRUs 102a, 102b, and 102c with access to 112 networks, which may include other wired or wireless networks owned and / or operated by other service providers. Figure 1E is a system diagram of RAN 105 and core network 109 according to one embodiment. RAN 105 can be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 117. As will be further explained later, the communication links between the various functional entities of WTRUs 102a, 102b, 102c, RAN 105, and core network 109 can be defined as reference points. As shown in Figure 1E, RAN 105 can include base stations 180a, 180b, 180c, and an ASN gateway 182, although it will be appreciated that RAN 105 can include any number of base stations and ASN gateways while remaining consistent with one embodiment. Base stations 180a, 180b, and 180c can each be associated with a particular cell in RAN 105 and can include one or more transceivers to communicate with WTRUs 102a, 102b, and 102c via air interface 117. In one embodiment, base stations 180a, 180b, and 180c can implement MIMO technology. Thus, base station 180a, for example, can use multiple antennas to transmit wireless signals to, and receive wireless signals from, WTRU 102a.Base stations 180a, 180b, and 180c can also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and similar functions. ASN gateway 182 can serve as a traffic aggregation point and may be responsible for radio paging, subscriber profile caching, routing to the 109 core network, and similar functions. Air interface 117 between WTRUs 102a, 102b, 102c and RAN 105 can be defined as an R1 reference point implementing the IEEE 802.16 specification. Additionally, each of WTRUs 102a, 102b, and 102c can establish a logical interface (not shown) with core network 109. The logical interface between WTRUs 102a, 102b, 102c and core network 109 can be defined as an R2 reference point, which can be used for authentication, authorization, IP host configuration management, and / or mobility management. The communication link between each of the base stations 180a, 180b, and 180c can be defined as an R8 reference point, which includes protocols to facilitate WTRU handovers and data transfer between base stations. The communication link between base stations 180a, 180b, 180c, and the ASN 182 gateway can be defined as an R6 reference point. The R6 reference point can include protocols to facilitate mobility management based on mobility events associated with each of the WTRUs 102a, 102b, and 102c. As shown in Figure 1E, RAN 105 can be connected to core network 109. The communication link between RAN 105 and core network 109 can be defined as a reference point R3 that includes protocols to facilitate data transfer and mobility management capabilities, for example. Core network 109 can include a mobile IP local agent (MIP-HA) 184, an authentication, authorization, and accounting (AAA) server 186, and a gateway 188. Although each of the above elements is represented as part of core network 109, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator. The MIP-HA can be responsible for IP address management and can enable WTRU 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 can provide WTRU 102a, 102b, and 102c with access to packet-switched networks, such as the Internet, to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. The AAA server 186 can be responsible for user authentication and supporting user services. The gateway 188 can facilitate interoperability with other networks. For example, gateway 188 can provide WTRU 102a, 102b, 102c with access to circuit-switched networks, such as PSTN 108, to facilitate communication between WTRU 102a, 102b, 102c and traditional landline communication devices.Additionally, gateway 188 can provide WTRU 102a, 102b, 102c access to 112 networks, which may include other wired or wireless networks owned and / or operated by other service providers. Although not shown in Figure 1E, it will be seen that RAN 105 can connect to other ASNs, and core network 109 can connect to other core networks. The communication link between RAN 105 and the other ASNs can be defined as reference point R4, which may include protocols for coordinating the mobility of WTRUs 102a, 102b, and 102c between RAN 105 and the other ASNs. The communication link between core network 109 and the other core networks can be defined as reference point R5, which may include protocols for facilitating interoperability between home core networks and visited core networks. The core network entities described herein and illustrated in Figures 1 through 6 are identified by the names given to those entities in certain existing 3GPP specifications. However, it is understood that in the future, those entities and functionalities may be identified by other names, and certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Therefore, the particular network entities and functionalities described and illustrated in Figures 1 through 6 are provided by way of example only, and it is understood that the subject matter disclosed and claimed herein may be materialized or implemented in any similar communication system, whether currently defined or defined in the future. The 5G 170 core network shown in Figure 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 Exposure Function (NEF), a Policy Control Function (PCF) 184, a Non-3GPP Interworking Function (N3IWF) 192, and an Application Function (AF) 188. Although each of the above elements is depicted as part of the 5G 170 core network, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator. It should also be noted that a 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these elements.Figure 1F shows that network functions connect directly to each other; however, it should be appreciated that they can communicate through routing agents such as diameter routing agents or message buses. The AMF 172 can connect to each of the RAN 103 / 104 / 105 / 103b / 104b / 105b modules via an N2 interface and can serve as a control node. For example, the AMF 172 can be responsible for registration management, connection management, accessibility management, access authentication, and access authorization. The AMF 172 can route and forward NAS packets to / from the WTRU 102a, 102b, and 102c modules. SMF 174 can connect to AMF 172 via an N11 interface, to PCF 184 via an N7 interface, and to UPF 176 via an N4 interface. SMF 174 can serve as a control node. For example, SMF 174 can be responsible for session management, IP address allocation and management for WTRU 102a, 102b, and 102c, traffic direction rule configuration on UPF 176, and generation of downlink data notifications. SMF 174 can also be connected to UPF 176, which can provide WTRU 102a, 102b, and 102c with access to a 190 data network (DN), such as Internet 110, to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. SMF 174 can manage and configure traffic direction rules on UPF 176 via interface N4. UPF 176 can be responsible for interconnecting a packet data unit (PDU) session with a data network, routing and forwarding packets, enforcing policy rules, managing quality of service for user plane traffic, and buffering downlink packets. The AMF 172 can also connect to the N3IWF 192 via an N2 interface. The N3IWF facilitates a connection between the WTRU 102a, 102b, 102c and the 5G core network 170 via radio interface technologies not defined by 3GPP. The PCF 184 can connect to the SMF 174 via an N7 interface, to the AMF 172 via an N15 interface, and to an application function (AF) 188 via an N5 interface. The PCF 184 can provide policy rules to control plane nodes such as the AMF 172 and SMF 174, allowing the control plane nodes to enforce these rules. The UDM 178 acts as a repository for authentication credentials and subscription information. The UDM can connect to other functions such as AMF 172, SMF 174, and AUSF 180. The AUSF 180 performs authentication-related operations and connects to the UDM 178 via an N13 interface and to the AMF 172 via an N12 interface. The NEF exposes capabilities and services on the 5G 170 core network. The NEF can connect to an AF 188 via an interface and can connect to other control plane and user plane functions (180, 178, 172, 172, 184, 176 and N3IWF) to expose the capabilities and services of the 5G 170 core network. The 5G 170 core network can facilitate communication with other networks. For example, the 170 core network may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the 5G 170 core network and PSTN 108. For example, the 170 core network may include, or communicate with, a Short Message Service (SMS) service center that facilitates communication via SMS. For example, the 5G 170 core network may facilitate the exchange of non-IP data packets between WTRUs 102a, 102b, and 102c and servers. Furthermore, the 170 core network may provide WTRUs 102a, 102b, and 102c with access to 112 networks, which may include other wired or wireless networks owned and / or operated by other service providers. Figure 1G is a block diagram of an exemplary computer system 90 in which one or more devices of the communications networks illustrated or described herein may be materialized, such as certain nodes or functional entities in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110 or other networks 112. The computer 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 by whatever means such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91, to cause the computer system 90 to perform work. 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 array circuits (FPGAs), any other type of integrated circuit (IC), a state machine, and the like.The processor 91 can perform signal encoding, data processing, power control, input / output processing, and / or any other functionality that enables the computer system 90 to operate on a communications network. The coprocessor 81 is an optional processor, distinct from the main processor 91, that can perform additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 can receive, generate, and process data related to the methods and apparatus disclosed herein. In operation, the processor fetches, decodes, and executes instructions, and transfers information to and from other resources through the computer system's main data transfer path, the system bus. This system bus connects the components in the computer system and defines the means for data exchange. The system bus 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 is the PCI (Peripheral Component Interconnect) bus. The memories connected to the system bus include random-access memory (RAM) and read-only memory (ROM). These memories include circuitry that allows information to be stored and retrieved. ROM generally contains stored data that cannot be easily modified. Data stored in RAM can be read or changed by the processor or other hardware devices. Access to RAM and / or ROM can be controlled by the memory controller. The memory controller may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. The memory controller may also provide a memory protection function that isolates processes within the system and separates system processes from user processes.Therefore, a program running in first mode can only access memory mapped by its own process virtual address space; it cannot access memory within the virtual address space of another process unless memory sharing between the processes has been established. In addition, the computer system 90 may contain a peripheral controller 83 responsible for communicating instructions from the processor 91 to peripherals, such as the printer 94, keyboard 84, mouse 95 and disk drive 85. The display 86, controlled by the display controller 96, is used to display the visual output generated by the computer system 90. This visual output can include text, graphics, animated graphics, and video. The visual output can be provided in the form of a graphical user interface (GUI). The display 86 can be implemented with 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 required to generate a video signal that is sent to the display 86. In addition, the computer system 90 may contain communication circuitry, such as a network adapter 97, which can be used to connect the computer system 90 to an external communications network, such as the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, or other networks 112 in Figures 1-6, to enable the computer system 90 to communicate with other nodes or functional entities on those networks. The communication circuitry, alone or in combination with the processor 91, can be used to perform the transmission and reception stages of certain devices, nodes, or functional entities described herein. It is understood 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. These instructions, when executed by a processor, such as the 118 or 91 processors, cause the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions, executed by the processor of a computer device or system configured for wireless and / or wired network communications.Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented using any non-transient (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVDs) or other optical disc storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium that can be used to store the desired information and that can be accessed by a computer system. Figure 2A is a block diagram of a non-roaming network architecture for the 5G network with service-based interfaces within the network control plane. Figure 2B is a block diagram presenting another view of the 5G network in Figure 2A and illustrating the reference points through which various network functions interact. Note that the mobility management and session management functions are separate. A single NAS N1 connection is used for both registration management and connection management (RM / CM), as well as for SM-related messages and procedures for a UE. The single N1 termination point is located in the AMF. The AMF forwards SM-related NAS information to the SMF. The AMF handles the registration management and connection management portions of the NAS signaling exchanged with the UE. The SMF handles the session management portion of the NAS signaling exchanged with the UE. The 5G system architecture is defined to support data connectivity and services that enable deployments using techniques such as network function virtualization (NFV) and software-defined networking (SDN). The 5G system architecture is designed to leverage service-based interactions between control plane (CP) network functions once they are identified. As defined above, a Network Function (NF) is a processing function in a network, with defined functional behavior and interfaces. An NF can be implemented as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform, such as a cloud infrastructure. As defined above, an NF service is a type of capability exposed by one NF ("NF service producer") to another authorized NF ("NF service consumer") through a service-based interface. An NF can expose one or more NF services. Generally, an NF service offers a capability to authorized consumers. NFs can offer different capabilities, and therefore different NF services, to different consumers.Each of the NF services offered by an NF is designed to be autonomous, reusable, and use management schemes independently of other NF services offered by the same NF, for example, for scaling, curing, etc. Each NF service is designed to be accessible through an interface. An interface can consist of one or more operations. Figure 3 shows the relationships between an NF service and its operations. The interaction between two network functions (consumer and producer) within this NF service framework follows two mechanisms: "Request-response": Another Control Plane NF_B (an NF service producer) requests a Control Plane NF_A (an NF service consumer) to provide a certain NF service, which performs an action, provides information, or both. NF_B provides an NF service based on NF_A's request. To fulfill the request, NF_B may, in turn, consume NF services from other NFs. In this request-response mechanism, communication is one-to-one between two NFs (consumer and producer), and a one-time response from the producer to the consumer's request is expected within a certain timeframe. Figure 4 illustrates the flow of the request-response communication mechanism. "Subscribe-Notify": A Control Plane NF_A (NF service consumer) subscribes to the NF service offered by another Control Plane NF_B (NF service producer). NFs in the Multiple Control Plane can subscribe to the same Control Plane NF Service. NF_B notifies the results of this NF service to the interested NFs that subscribe to it. The subscription request will include the notification endpoint (e.g., the notification URL) of the NF service consumer to which the event notification should be sent from the NF service producer. Additionally, the subscription request can include a notification request for periodic updates or a notification triggered by certain events (e.g., the requested information changes, reaches a certain threshold, etc.). Figure 5 illustrates the flow of the subscription-notification communication mechanism. As an example, Table 1 shows the AMF Services and AMF Service Operations defined in 3GPP TS 23.502, Procedures for the 5G System; Phase 2, v15.1.0, Version 15, 2018-03. Table 1: List of AMF services Network slicing is a mechanism that mobile network operators can use to support multiple virtual networks behind the air interface across the fixed portion of their network, including both the backhaul and core networks. This involves "segmenting" the network into multiple virtual networks to support different radio access networks (RANs) or different types of service running over a single RAN. Network slicing enables operators to create customized networks to provide optimized solutions for different market scenarios with varying requirements, such as functionality, performance, and isolation. As defined above, a network segment can comprise a logical network that provides specific network capabilities and characteristics. A network segment within a PLMN includes the core network control plane and the user-plane network functions (NFs). A network segment instance comprises a set of NF instances and the required resources (e.g., compute, storage, and network resources) that form a deployed network segment. Network segments can differ in terms of supported features and network function optimizations, in which case such network segments may be of different segment / service types. An operator may deploy multiple network segment instances that provide the same features but to different UE groups, for example, because they provide a different committed service and / or because they are dedicated to a single customer, in which case such network segments may be of the same segment / service type but are distinguished by different segment differentiators. The network can serve a single UE with one or more network segment instances simultaneously over a 5G-AN and associated with a maximum of eight different S-NSSAIs in total, regardless of the access type(s) the UE is registered for (i.e., 3GPP access and / or N3GPP access). The AMF instance serving the UE logically belongs to each of the network segment instances serving the UE; that is, this AMF instance is common to the network segment instances serving a UE. A network segment is identified by an S-NSSAI, which is composed of: A Segment / Service type (SST), which refers to the expected behavior of the network segment in terms of features and services; A Segment Differentiator (SD) is optional information that supplements the Segment / Service type(s) to differentiate between multiple network segments of the same Segment / Service type. An S-NSSAI can have standard values ​​(i.e., such an S-NSSAI consists only of an SST with a standardized SST value and no SD) or non-standard values ​​(i.e., such an S-NSSAI consists of both an SST and an SD, or only an SST without a standardized SST value and without an SD). An S-NSSAI with a non-standard value identifies a single network segment within the PLMN with which it is associated. An S-NSSAI with a non-standard value will not be used by the UE in access stratum procedures on any PLMN other than the one with which the S-NSSAI is associated. Table 2 shows the standardized SST values ​​as defined in 3GPP TS 23.501, System Architecture for System 5G; Phase 2, v15.1.0, Version 15, 2018-03. The NSSAI is a collection of S-NSSAIs. An NSSAI can be a Configured NSSAI, a Requested NSSAI, or an Allowed NSSAI. There can be a maximum of eight S-NSSAIs in the Allowed and 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 the service AMF, network segment(s), and network segment instance(s) for this UE. Table 2: Normalized SST values Based on the operator's operational or deployment needs, a network segment instance can be associated with one or more S-NSSAIs, and an S-NSSAI can be associated with one or more network segment instances. Multiple network segment instances associated with the same S-NSSAI can be deployed in the same or different monitoring areas. When multiple network segment instances associated with the same S-NSSAI are deployed in the same monitoring areas, the AMF instance serving the UE can logically belong to (i.e., be common to) more than one network segment instance associated with that S-NSSAI. With reference to Figure 6, and as mentioned earlier, the 5GC defines a service-based architecture (SBA) based on the concept of network segmentation and virtualized network functions (NFs). Different network functions (e.g., AMF, SMF, and PCF) provide different network function services through the service-based interface. This means that the service consumer can use the same message and procedure to communicate with the service provider. For example, any NF can subscribe to the same event using the event exposure service provided by the AMF. Furthermore, various network capabilities, such as non-IP data distribution (NIDD), background data transfer (BDT), and power saving mode (PSM), can be implemented through a set of NF services.Under the current SBA framework, the UE can configure and access the network by specifying the requested NSSAI, which identifies network segment(s). However, there is no way for a UE to directly specify desired network capabilities. For example, a vehicle running a V2X application might want to use Background Data Transfer (BDT), Media Broadcast / Multicast Service (MBMS), and event monitoring capabilities. The UE or corresponding V2X application server needs to establish a configuration with the core network (CN) so that the network segment serving the UE has the desired network capabilities. On the other hand, a smart home device integrating sensors and a camera might want to use a different set of network capabilities, such as NIDD, data staging, group messaging, and device triggering. The device might not have a graphical interface for human intervention, which is common for many IoT devices.It would be desirable for the network to be able to automatically configure the network segment based on the different levels (e.g., network capacity level, network segment identifier level, or NF service level) of input from the devices. As explained above, the 5GC service-based architecture consists of multiple virtualized network functions. Each network function provides a set of network function services through service-based interfaces. Therefore, network capabilities (e.g., event monitoring, location services) can be implemented through a set of network function services. Any entity (e.g., NF, UE, and SCS / AS) can subscribe to a service by invoking the same operations. However, there are a few restrictions on the existing ABS defined by 5GC. First, the granularity of network function services prevents flexible network capability configurations. Each network function provides various network function services from different perspectives (for example, AMF provides mobility management, location management, and event monitoring / reporting 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 MIoT services by setting the Segment / Service type to MIoT. However, there is no way for the UE to specify a particular network capability it wants, such as non-IP data delivery or event monitoring / reporting capabilities. In another example, a V2X application server (AS) may require the Background Data Transfer (BDT) capability to be enabled.Based on the current network function framework, the BDT capability requires the NF service Npcf_BDTPolicyControl provided by the PCF and the NF service Nnef_BDTPNegotiation provided by the NEF to determine the BDT policy. Additionally, the Nsmf_PDUSession service provided by the SMF is required to manage the PDU session for future data transfer. It is difficult for a UE / AF / AS to determine which network function services are needed for BDT. In fact, it is not necessary to require the UE or SCS / AS to be aware of these network function services to enable BDT. The UE and AS will be more interested in the network capabilities than the NF services. Secondly, when a UE registers with the core network, it can provide an indication of the segment type it wishes to connect to, for example, in the requested NSSAI. However, this information may be PLMN-specific and non-standardized, and as a result, may not be known to the UE—for example, the first time the UE registers, or if a UE is roaming. In such cases, the UE cannot include this information when attempting to register with the network. Third, some IoT devices are constrained, so automatic configuration of network capacity on the core network is desirable to help these devices dynamically configure their network capacity. Based on existing methods, dynamically adding or removing network capacity (i.e., updating the network segment to which the UE registers) will trigger a UE configuration update process, which will further trigger the registration process, and sometimes requires the UE to enter idle mode and repeat the entire registration process. This should not be necessary and may be overly complicated for a constrained IoT device. Fourth, the scope of the existing ABS is limited to the NFs control plane. The user plane function (UPF) is not involved. The UPF has some control functionalities, such as QoS enforcement and event monitoring. The goal is to define a service-based interface and UPF services to enhance the ABS. Fifth, when a UE sends a registration request to the core network, there is no way for the UE to indicate what network capabilities it requires. Sixth, when a UE registers on the network, it receives an allowed NSSAI. The UE does not know if the allowed NSSAI is capable of supporting the UE's required capabilities. Seventh, when there is a change in the UE context, for example, when a UE moves from EPS to 5G, or there is a request from an AS that may update the network capacity of the segment (e.g., maximum data rate, etc.), there may be a required change in the PCC rules and network segment information (and therefore a change in NCP) for the UE. The PCF may transmit such a change to the UE as a UE policy update. The UE policies may need to be enhanced to incorporate NCP. 5GS does not have a mechanism to deliver such enhanced UE policies to the UE. Eighth, a network segment may have a limit on how many PDU sessions it can handle simultaneously. When a UE attempts to establish a PDU session with a network segment, and the network segment's capacity has reached its peak, it cannot handle the UE's request. The 5G system does not currently handle this condition. Ninth, another network capacity may be handling a maximum number of UE registrations per network segment. When a UE attempts to register with a network segment and the network capacity for the maximum UE registration on that segment has reached its limit, it should not be able to register. The current 5GS does not address such a case. When a UE application attempts to initiate a data flow (for example, an IP data flow), the UE needs to determine which data segment and network to associate the flow with. The 5G system provides a way to address this issue in URSP. A URSP rule can include application identifiers and thus instruct the UE on how to route traffic from a given application. A drawback of this approach is that the UE needs to be provided with application identifiers that match its installed applications. Another approach to determining which data segment and network to associate a flow with is to allow the UE to specify the segment (S-NSSAI) and data network (DNN) with which the flow should be associated. A drawback of this approach is that the UE application needs to be provided with an S-NSSAI and DNN, and these parameters need to be recognizable to the network. This document discloses methods and devices for enabling a network to inform the UE about the network capabilities of a segment and how those capabilities are configured within that segment. This information can be used by the UE in situations where UE applications can indicate their required capabilities to the UE. The UE can then use this information during route selection (i.e., during URSP evaluation, when determining which segment and PDU session to use for a data flow). Methods are also described for a UE to inform the network of its desired network capabilities and their configuration, and for the network to provide the UE with segment identifiers that can deliver those capabilities in the desired configuration. The concept of a Network Capacity Profile (NCP) is introduced. An NCP lists the capabilities of a segment and how each capability is configured. Examples of network capabilities are provided later in this document. The following describes technical solutions to problems in the existing service-based architecture and the corresponding NF framework. These solutions can enable more dynamic and flexible operation of the service-based architecture and improve its programmability for the end user (i.e., UE and AS). To facilitate users (e.g., UE and AS) in configuring desired network capabilities and features through service-based interfaces and procedures, the following is described. First, a new framework is described that includes a network capacity layer. A UE and an AS can dynamically request network capacity (e.g., background data transfer, non-IP data delivery, maximum UE DL / UL data rates, maximum delay tolerance, maximum guaranteed DL throughput, group features, message delivery options, etc.) to support their applications. In a typical implementation, the UE and AS may not need to know or be concerned about which network segment supports the requested network capacity(ies), or whether the service network segment can support the requested network capacity(ies). A central network entity can determine and configure a network segment that supports all the requested network capacity(ies). Second, a mechanism is described by which the network can deliver network capacity information, referred to herein as a Network Capacity Profile (NCP) for a network segment, to the UE. A method is also described by which the network can inform a UE about an alternative network segment with a comparable network capacity profile based on the network capacity requested by the UE. Third, a method is disclosed for a UE to initiate a network capacity-based registration to configure its desired network capacities. Fourth, a method is described for a UE to initiate a network capability-based registration to configure its desired network capabilities. Fifth, a method is described for UEs to initiate a network capability-based registration upgrade when UEs are already registered on the network and want to dynamically reconfigure their network capabilities. Sixth, a method is described for a UE configuration update based on network capability, which allows NF or Application Servers to initiate the process to update network capabilities on the network segment for the UE. Seventh, a method is disclosed whereby a UE can receive a set of permitted NSSAIs with their corresponding NCPs during a general UE registration procedure. The UE may be able to request an alternative network segment based on the list of permitted S-NSSAI NCPs received from the core network if the capacities indicated by the received NCPs are insufficient for the applications in the UE. Eighth, a method is described whereby NCPs for network segment(s) are delivered to the UE as part of the UE Policies during the UE Policy update procedure. Ninth, a method is described whereby the core network applies the maximum number of PDU sessions per network segment and handles requests received after the maximum limit has been reached during the PDU Session Establishment procedure. Tenth, a method is described in which the core network manages the maximum limit on the number of PDU sessions per network segment, whereby the network periodically informs the UE via the NAS message that the network segment has reached its maximum limit so that the UE can wait before attempting to retry. Eleventh, a method is disclosed whereby a core network enforces the maximum number of UE registrations per network segment and handles registration requests received after the maximum limit has been reached. Twelfth, an extended service-based architecture is described that includes interfaces with a User Plane Function (UPF) and services provided by the UPF. Based on these aspects, a UE can send a network capacity configuration request to configure the network capabilities to support its applications, and the UE can receive a network capacity configuration response with the identity of the network segment that supports the desired network capabilities. Based on these characteristics, the network entity receiving the request can perform one or more of the following operations: • Check a network capacity profile to determine if the service network segment can support the requested network capacity(ies); • Select a new network segment to serve the UE for all requested network capabilities; • Initiate a new network segment (instance) to serve the UE with all requested network capabilities in case the UE cannot be served by any existing network segment; • Select a new entity that terminates NAS signaling with the UE serving the newly selected network segment; • Update the network capacity profile of the selected network segment; and • Send a response to the UE with information on the service network segment and network capabilities. The network capacity profile may include one or more of: • an identifier of a network segment and the corresponding network segment instances; • identifiers from a list of supported network capabilities; • an identifier of a service PLMN; and • Service area information for each network capacity. The network capacity configuration request may contain one or more of the following: • an identification of one or more desired network capabilities; • application identifiers that require the network capabilities; • an NSSAI, which can be a configured NSSAI or an allowed NSSAI, to which the UE was assigned during a previous registration process; • identifiers associated with the EU; • Service area information for the requested network capabilities; • availability programs for the required network capacity(ies); • a QoS level (e.g., service response time) for the required network capability(s); • a required multi-tenancy level (e.g., how many applications in the UE will require the use of one or more network capabilities). Furthermore, in accordance with the above aspects, a network entity may perform one or more of the following operations: • receive a network capacity configuration request from a network entity that triggers a network capacity configuration update process for a UE; • Determine if it is necessary to select a new network segment and / or a new network entity as the NAS signal termination point for the UE; • Select a new network segment and / or a new NAS termination point for the UE; • send a configuration update message to the UE; and • send a response to the triggering network entity. The network entity receiving the request may also perform one or more of the following: • Check a network capacity profile to determine if the service network segment can support the requested network capacity(ies); • Select a new network segment to serve the UE for all requested network capabilities; • Select a new entity that terminates NAS signaling with the UE serving the newly selected network segment; • Update the network capacity profile of the selected network segment; and • Send notification to the UE with information on the service network segment and network capabilities. Alternatively, instead of a network entity triggering a network capacity configuration update process for the UE, an application server can choose to trigger the process by sending a network capacity configuration request. The EU may perform one or more of the following: • Submit a Registration Request. • Receive a Registration Response, the response includes an NCP for a Network Segment. Furthermore, in accordance with the above aspects, one or more of the following operations may take place: • The Response may come from an AMF. • The AMF can obtain the NCPs for the subscribed S-NSSAIs from the UE subscription information in the UDM. • The AMF can obtain the NCPs for the permitted S-NSSAIs from another network function such as the UDM, NSSF, or NRF. • The Response may contain S-NSSAIs that were not in the Registration Request and the response may include n NCPs for each S-NSSAI. • The UE can request an alternative network segment based on the S-NSSAI NCP list received from the core network. A UE can receive an NCP as part of the UE policies received in a NAS message. Furthermore, in accordance with the above aspects, a network entity may perform one or more of the following operations: • Receive the trigger to update the EU's NCP policies. • Check the latest PSIs to find the UE policies and NCP policies (NCCP) for S-NSSAIs to be sent to the UE. • Integrate NCPP with EU policies. • Deliver the NCPP using the EU policy container to the EU. Furthermore, in accordance with the above aspects, the UE can use the information in the NCPP when selecting routes during the URSP rule evaluation. For example, the UE can choose to establish routes described in lower-priority RSD in situations where the maximum data rate on the segment associated with a higher-priority route is lower. The EU may perform one or more of the following: • Attempt to establish a PDU session with the network. • It is rejected and receives a cause code indicating that the maximum PDU session limit for the segment has been reached and a wait timer. • Do not attempt to establish a PDU session until the standby timer expires or until the UE terminates a PDU session. Furthermore, in accordance with the above aspects, a network entity may perform one or more of the following operations: • Employ a counter, which increments or decrements a count for each PDU session established or terminated. • After reaching a maximum limit, you can block the UE's request to establish a PDU session and send a cause code to the UE in response, where the cause code contains a reason for denying access with a hold timer. The EU may perform one or more of the following: • Receive a NAS notification, indicating that the maximum PDU session limit has been reached and a wait timer has started. • Wait for the standby timer to expire or wait until the UE finishes another PDU session on the same segment, before requesting PDU session establishment. Furthermore, in accordance with the above aspects, a network entity may perform one or more of the following operations: • Employ a counter, which increments or decrements a count for each PDU session established or terminated. • Notify the EU when the condition has been cleared. Furthermore, in accordance with the above aspects, the EU may carry out one or more of the following operations: • Receive a NAS message from the network, indicating that the condition has been cleared. • Reset the standby timer and retry the PDU session establishment process. • Wait until the wait timer expires and retry the PDU session establishment process The EU may perform one or more of the following operations: • Request the EU registration procedure. • It was rejected with a cause code, which indicated that the maximum UE registration limit and a wait timer had been reached. • Do not request UE registration until the timer expires or until something in the UE is unregistered from the segment. Furthermore, in accordance with the above aspects, a network entity may perform one or more of the following operations: • Use a counter, which increments or decrements a count for each registered or unregistered UE. • After reaching a maximum limit, a network entity may block the UE's request to register and send a cause code to the UE in response, where the cause code contains a reason for denying access with a hold timer. • Notify the EU that the condition has been cleared. Furthermore, in accordance with the above aspects, the EU may carry out one or more of the following operations: • Stick to the standby timer. • Receive a NAS message from the network, indicating that the condition has been cleared. • Reset the wait timer and retry the UE registration request. Framework for network segmentation in the 5G core network Figure 7 shows a network architecture that has a network capability layer (e.g., BDT, NIDD, and event monitoring) between network segments (with corresponding NF and NF services) and UE / AS. The network capability layer enables finer granularity in network segment configuration and provides an easier way for a UE / AS to configure its network characteristics. The new layer can include a logic layer, which allows a UE and a SCS / AS to request desired network capabilities by specifying which network capabilities (e.g., BDT, NIDD, and event monitoring) are desired, instead of, or in addition to, specifying the desired network segment type. A UE / AS can send a request to the core network directly indicating the desired network capabilities, and a new NF—referred to herein as a Network Capacity Management Function (NCMF)—can operate to configure a network segment to serve the UE / AS with the desired network capabilities. The NCMF can implement network capacity layer management functionality in the core network. This new NF enables finer granularity in configuring network services. On one hand, an UE / AS can directly specify which network capability(s) (e.g., background data transfer, event monitoring, etc.) they require without knowing the available NFs and NF services. This allows a UE / AS to request specific capabilities without needing to understand how the network segment provides them. A UE and an AS can focus solely on the network capabilities level for their applications. On the other hand, core network entities can maintain operations at the NF and NF services level without any changes to the existing framework due to a UE / AS request at the network capability level. The NCMF may have one or all of the following functionalities. First, the NCMF can manage and maintain information that provides a mapping between network capabilities and NF services. That is, the mapping information can indicate a set of NFs and the corresponding NF services required to support a network capability. This information can be used to determine whether a network segment can support a given network capability, and whether the NF services are included in that network segment. Secondly, the NCMF can manage and maintain a profile that includes information identifying a set of network capabilities supported by a network segment. This network capability profile information can be useful when a UE / AS requests to add or upgrade a network capability for its applications. Third, the NCMF can also interact with a network operation and management (O&M) system to obtain information about a network segment, NF, NF service, and / or network capacity. The NCMF can also request the O&M system to manage the network segment, network segment instance, NF, and / or NF service to support one or more desired network capabilities. The NCMF can be an independent network function, a logical function that resides in other network functions such as the AMF, SMF or PCF, or a service that provides a network function. Mapping information between network capacity and NF service To determine if a network segment can support a certain network capacity, it is necessary to maintain mapping information to indicate which network facilities (NFs) services are required to support that capacity. For example, background data transfer (BDT) capacity requires the Npcf_BDTPolicyControl service provided by the PCF and the Nnef_BDTPNegotiation service provided by a NEF to determine a BDT policy. Additionally, the Nsmf_PDUSession service provided by the SMF is required to manage the PDU session for future data transfer. Table 3 shows an example of a data structure for providing mapping information between a network capacity and its required NF services. Table 3: Information on network capacity and NF service The NCMF can obtain mapping information from the network's O&M system. This mapping information can be managed and stored within the NCMF. The NCMF can be located in conjunction with an NSSF or NRF, so the aforementioned mapping information can also be managed and stored within the NSSF or NRF. Network capacity profile A network capacity profile can comprise an information profile for each network segment maintained by the NCMF, indicating which network capacities are supported by each segment. Table 4 shows an example of the information fields that can be included in a network capacity profile for a given network segment. Note that the Network Capacity Profile (NCP) is a set of information elements per segment. Table 4: Network acidity profile The NCMF can manage and maintain the information shown in Table 3 and Table 4. When the NF core network receives a request from a UE / AS to add or upgrade a network capability (for example, modifying one or more parameters of the network capability), the request can be forwarded to the NCMF to determine whether the service network segment already supports the requested capability. If not, the NCMF can further determine whether the service network segment can be configured to support the requested capability. That is, whether the service segment can be functionally configured to support the capability, and whether the service segment has sufficient resources (for example, available processor and memory resources) to be configured to support the capability. Optionally, the information in Tables 3 and 4 can be managed and maintained in place or also in an NSSF or NRF, in which case the NCMF can 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 can provide an easier way for any NF to obtain this information by accessing the data store, without discovering or communicating with the NCMF, NSSF, or NRF. Alternatively, the network capacity profile can be implemented as a Segment Differentiator (SD) implementation in an S-NSSAI, allowing the specification of the network capabilities supported by a network segment. This enables the differentiation of network segments with the same Segment / Service Type (SST) value (e.g., MIoT, eMBB) but supporting different network capabilities. On the UE / AS side, once the registration or registration update procedure is complete, the UE / AS can maintain information about which network capabilities are supported by the service network segment. Furthermore, the UE / AS can maintain information about which network capability(s) supported by a network segment are for which application, since there may be multiple network segments serving different applications running on a single UE. Network segment capacity configuration The network capacity profile in Table 4 includes a network segment capacity field for each network segment capacity supported by the segment. This field indicates the specific capacity supported by the segment. Examples of capacities that a segment might support are listed below; support for these capacities can be indicated by the network to the UE: Maximum number of UEs per network segments Maximum number of PDU sessions per Network Segment Maximum UL and DL data rate per UE in the network segment Support for deterministic communication Group communication support Support for a specified level of insulation Support for location-based message delivery Support for a maximum package size Mission-critical communication support MMTel Support Support for performance monitoring Support for a specified session and service continuity (SSC) mode Support for non-IP data distribution (NIDD) and / or reliable data service (RDS) Support for certain RATs Support for a specific device speed Support for a specific vertical application, such as V2X communications and mIoT communication Support for a specific service area, where only UEs located within that area can access / connect to the network segment. The service area could be defined as a monitoring area, registration area, or geographic area. Maximum number of network segment instances that can be instantiated for a network segment. Support for certain transmission mechanisms Support for multiple tunneling mechanisms (L2TP tunnel, GRE tunnel or VPN tunnel). Support for the coverage area of ​​network segments (global, national, regional, cell-limited, sectors, base station, etc.) Support for delay tolerance around EU. Guaranteed DL performance support for the EU. Support for Prediction Frequency describes how often KQI and KPI prediction values ​​are provided to the UE. The UE can send the request and receive prediction information in advance about the quality drop (and therefore switch the segment if necessary). SSC mode support (SSC mode 1, SSC mode 2, SSC mode 3, SSC mode 4) Support periodic traffic (deterministic communication) which can help optimize scheduling / performance for the UE. Support for multiple radio spectrum, such as some terminals, could be restricted in terms of frequencies to be used (e.g., n1, n77, n38, etc.). Support for various access technologies. Support for uplink throughput per network segment, which defines the achievable data rate of the network segment instance on the uplink that is available ubiquitously across the network segment coverage area. Support for user data access, which defines how the network segment (or mobile network) should handle user data. For example, a UE can have internet access, data can be routed to the private network via tunneling, or all UE data can remain local. Support for segment quality of service parameters, which defines all relevant QoS parameters supported by the network segment. Support for the maximum packet size supported by the segment, which may be important for URLLC (Ultra-Reliable Low-Latency Communication) and MIoT (Massive IoT), or to indicate a maximum supported transmission unit (MTU). Therefore, the UE may need to comply with this segment. Support for network segment isolation level (physical or logical isolation). This can affect or support UEs that will be isolated based on the segment. Note that some of the capabilities listed above may require additional configuration. For example, the "Support for guaranteed DL throughput for the UE" capability may be associated with a specific DL throughput value (e.g., 100 Mbps). This information will be captured in the "Network capability parameters" field of Table 4. The "Network capability parameters" may be specified by the network to the UE. Network capacity-based logging With the network capability layer in Figure 7, which can be implemented in the form of the NCMF, a UE can request its desired network capabilities, and a UE does not need to know if a specific NF and NF services are available on a network segment. Figure 8 shows an example of a network capacity-based registration method. When a UE registers, the UE can include an indication of a set of desired network capabilities to support its applications, and the network can respond with an NSSAI and NSI ID that identify a network segment supporting all the requested network capabilities. The network response can also indicate which S-NSSAIs are associated with each capability. The stages of the registration method are shown in Figure 8. Note that, for descriptive purposes only, only information related to network capacity configuration is described below. Other information, such as information related to mobility management, session management, etc., is involved in the registration procedure. In stage 1, the UE can send a registration request message to a RAN node in a communications network. In the request message, the UE can indicate the following information: A list of requested network capacities, each identified by a network capacity identifier (ID). This information can be captured in a Network Capacity Profile as described in Table 4. The information can be associated with the NSSAI Request, and a Network Capacity Profile per S-NSSAI can be provided in the NSSAI. When the UE initiates registration for the first time, it may not have the network capacity mapping information. The UE can insert some network capacity requirements so that the network entity (e.g., AMF, NCMF) can determine whether the existing network segment can serve the UE based on these requirements. Some requirements are discussed below, such as the required network capacity availability schedule, the required network capacity QoS level, and the required multi-tenancy level.The UE can determine the types of network capabilities requested based on the types of applications running on it. A single application may require multiple network capabilities. Consequently, the UE may need to maintain information about which applications require which network capabilities on the 5G core network. The UE can obtain this information through application-level signaling when communicating with the AS. Previous NSSAI: If available, the UE can include one or more S-NSSAIs that it was assigned if it previously registered with the PLMN. This can help the RAN node select an AMF and can be used by the AMF to configure / select a network segment that supports the requested network capabilities. The included NSSAI can be a configured NSSAI or an allowed NSSAI provided to the UE during a previous registration process. This parameter is optional. Application IDs: These indicate a set of applications requesting the requested network capabilities. The UE may be served by multiple network segments, and each network segment may serve a different set of applications, such as mIoT and eMBB. Correspondingly, applications and network capabilities may be divided and supported by different network segments. Therefore, the UE can maintain information indicating which application is served by which network segment with a given set of network capabilities. A network capability may be supported by more than one network segment, serving different applications on the UE. Alternatively, the UE can provide Application IDs without linking them to any network capability, and a SCS / AS will be contacted to determine which application is associated with which network capability. This can reduce the UE's responsibility and may be useful for constrained devices. PLMN ID: This indicates the PLMN to which the UE intends to register, if the UE has this information. Since different PLMNs can configure different network segments to provide the same network capacity, the PLMN ID can facilitate the selection of network segments and AMF. EU identifiers such as GUTI and / or SUPI, if available. Area information: Used to select a network segment to serve the UE. This information may be in the form of a TAI, registration area, or geographic area. Required network capacity availability program. Required network capacity QoS level (e.g., service response time). Required level of multi-tenancy (e.g., how many applications in the UE will require the use of network capacity(s)). This information, along with the network capacity requirements above, can be useful for a network O&M system to determine whether the existing segment instance(s), NFs, and NF services can be used to meet the network capacity request or whether new instances need to be instantiated (e.g., based on availability and scalability requirements). In stage 2, after receiving the registration request, the RAN node can select an AMF based on the requested network capabilities as well as the following information: NSSAI and AMF association information indicating which AMF serves which network segment identified by the NSSAI; and network capacity mapping information and S-NSSAI. The RAN node can obtain the above information by sending it via the AMF to the RAN node, adding the above information to an N2 message. Alternatively, the RAN node can obtain the above information from the Core Network by periodically sending the above information to the RAN node to advertise its network segment information and supported network capacity information. If the RAN node does not have any of the above information, or does not know of any AMF that supports the requested network capabilities, the RAN node can select a default AMF based on its local configuration. In this case, a different AMF can be selected later to serve the UE. In stage 3, the RAN node can forward the registration request to the selected AMF. In stage 4, the AMF may choose to contact a UDM to retrieve some subscription information, and / or a UDR to obtain some UE context information, as well as network capacity information. In stage 5, the AMF then consults the NCMF to obtain information on which network segment(s) can support the requested network capacity(ies) and the UE's network capacity usage requirements, such as the required network capacity availability schedule, the required network capacity QoS level, and the required multi-tenancy level, as discussed previously. The AMF may include the requested network capacity information in the message. Alternatively, the AMF may consult the NCMF to verify whether the S-NSSAIs in the requested NSSAI can provide the capacities indicated in the network capacity profiles from stage 1. In stage 6, the NCMF can verify the mapping information of existing network segments and network capabilities and return the NSSAI to the AMF to identify network segments that support all the requested network capabilities. If the NCMF cannot identify any existing network segment capable of supporting all the requested network capabilities, it can indicate this in the response message. The NCMF can provide the AMF with a new set of S-NSSAIs that the UE can use to obtain the requested services. The NCMF can provide the AMF with an NSID for each S-NSSAI. The NCMF can provide the AMF with a Network Capacity Profile for each S-NSSAI. In step 7, the AMF can compare the received NSSAI and locally stored network segment information to determine if it can serve the entire required NSSAI for all requested network capabilities. If the AMF can do so, it will update the UE context and perform step 10. Otherwise, the AMF can request the NSSF to perform the network segment selection and proceed to steps 8 and 9 for any of the following cases: (1) the AMF cannot serve the entire NSSAI; (2) the AMF cannot determine if it can serve the NSSAI; or (3) the NCMF indicates that there is no existing network segment that can support all requested network capabilities. In stage 8, the AMF requests the NSSF to select a network segment instance by providing requested network capacity information, PLMN ID, and UE information if available, such as 5G-GUTI and SUPI capabilities. In step 9, based on the UE ID and PLMN ID, the NSSF can verify the NSSAI in the request and select a network segment instance to serve the UE for all requested network capabilities. If a new set of AMFs is selected to serve the network segment, the NSSF can also select an NRF so that the new AMF can select an NF instance and an NF service instance within the selected network segment. The NSSF may return one or all of the following information in its response: NSSAI; Selected NSI ID corresponding to the NSSAI in the application; NRF address; and selected AMF set and / or AMF address. In the event that existing network segments cannot serve the UE, the NSSF may contact an operation and management (O&M) system to initiate a new network segment and the corresponding network segment instance to serve the UE. In step 10, once the response is received, the AMF can notify the NCMF about the mapping information between the selected network segment and the network capabilities. This is necessary in cases where the NCMF does not find any network segment that supports all the requested network capabilities, for example, in step 7. In stage 11, the NCMF can update the mapping information between the selected network segment and the network capabilities. In step 12a, if the current AMF is capable of serving the UE, the AMF can send the registration response to the RAN node, which forwards the response to the UE. The N2 message from the AMF to the RAN node can contain a network capacity profile of the selected network segment—that is, information about the selected network segment, as well as all information relating to the network capabilities supported by that segment. Additionally, location information or registration area information can be included in the response and provided to both the RAN node and the UE, so that the information can be mapped or associated with the selected network segment. The Registration Acceptance message may include a network capacity profile for each S-NSSAI in the allowed NSSAI. The network capacity profile is an indication or description of the capabilities of a network segment. Table 4 lists the contents of a network capacity profile for a network segment. If a UE is served by multiple network segments, the UE may maintain information that identifies which application is served by which network segment instance with which network capabilities. If the network segment is unable to support the capabilities requested by the UE, then the AMF may send a rejection message that includes an error / cause code, indicating reasons behind the failure to support the request. Alternatively, the network can send the UE network capacity profiles for network segments that closely match the requested network capacity profile(s). For example, if the UE requested guaranteed DL throughput network capacity of 10 Gbps, the network may be able to scan for matching network capacity profile(s) for available network segments. If the best available network capacity for the guaranteed DL throughput is 8 Gbps, the network can send the network capacity profile(s) to the UE to indicate whether it can accept them and agree to register with a network segment. On the other hand, a segment's network capacity profile may offer more network capacity and / or better quality of service (e.g., average UL / DL data rate, average latency, etc.) than the UE requires. If the network sends one or more meter network capacity profiles to the UE, the UE can either reject or accept the offered network capacity profile. If the UE accepts the offered network capacity profile(s), the UE can send an acknowledgment to the AMF, indicating acceptance. If the UE rejects the offered network capacity profile(s), it can do so by sending a rejection message (a rejection code) to the AMF. In this case, the AMF can respond with a default network segment and its corresponding network capacity profile. Alternatively, if the requested network capabilities are not available, the network may grant the UE a default segment NCP that has standard network capabilities. In step 12b, if a new AMF is selected to serve the UE, the current AMF can initiate an AMF relocation process by contacting the target AMF, according to the procedure described in this 3GPP TS 23.502, Procedures for the 5G System; Phase 2, v15.1.0, Version 15, 2018-0. In general, the network capacity request information delivered in stage 1 can be encapsulated in any NAS message, such as NAS-MM signaling between the UE and the AMF, or NAS-SM signaling between the UE and the SMF. In this sense, the information can be encapsulated in the service request message as well as in the session management-related request message. A UE can include the network capacity request in a NAS-SM message. For example, a UE might start a new application that needs to use network capacities X, Y, and Z. The UE might already be registered and have PDU sessions on a network segment. The UE can issue a PDU session establishment request with an indication to start a new PDU session on the same network segment that supports network capacities X, Y, and Z.The AMF or SMF can trigger the exchange with the NCMF to see if segment 1 is sufficient or if a new segment is needed for this PDU session. Registry update based on network capacity A UE can request new network capacity even after registration is complete, and the UE is served by a network segment. For example, a new IoT application might start on the UE and require a NIDD feature that is not supported by the serving network segment. Figure 9 shows an example of a method for UE-initiated network capacity-based registration updates. The network capacity information provided in stage 1 can be considered an NCP. In stage 1, the UE team can initiate the registry update process with a registry update request message, which may include one or all of the following information: NSSAI: This is the configured NSSAI and / or the permitted NSSAI that the UE obtained during a previous registration process; PLMN ID: This is used to indicate the PLMN on which the network segment serves the UE; NSI ID: This indicates the network segment instance that is serving the UE Application ID: This is an identifier for the application in the UE for which the new network capability is needed; Requested network capacity: The UE can determine the requested network capacity types(s) based on the type of new application that starts running on the UE. An application can require multiple network capacities. Information related to the UE's network capacity usage requirements, such as the required network capacity availability schedule, the required network capacity QoS level (e.g., service response time, etc.), and the required multi-tenancy level (e.g., how many applications on the UE will require the network capacity usage). Planning for the availability of required network capacity Required network capacity QoS level (e.g., service response time) Required level of multi-tenancy (e.g., how many applications in the UE will require the use of network capacity). This information, along with the network capacity requirements above, can be useful for a network O&M system to determine whether the existing segment instance(s), NFs, and NF services can be used to meet the request, or whether new instances need to be instantiated (e.g., based on availability and scalability requirements). In stage 2, the service AMF can verify whether the UE is allowed to request the new network capabilities, and the information provided by the UE is valid. In stage 3, the duty MFA can optionally choose to contact a UDM / UDR to retrieve some further information about the EU and EU-in-UDR context. In step 4, the service AMF can decide whether the requested new network capability(s) can be supported by any network segment that the AMF serves. If the service AMF can support the requested network capability, regardless of whether this is by the service network segment or a different network segment, the AMF will perform step 12. In stage 5, if the service AMF cannot support the required network capacity and the UE's network capacity usage requirements, or if the service AMF cannot determine whether it can support it, the service AMF can send a network capacity configuration request to the NCMF. This request includes the UE context stored in the AMF, the NSSAI, and the required network capacity information. In stage 6, upon receiving the request, the NCMF can check the mapping information between available network segments and their network capacities, as well as the network capacity profile, to find a network segment that supports the requested network capacity(ies). In stage 7, the NCMF can then determine if the requested network capabilities can be supported by any network segment without changing the service AMF. In step 8a, if the NCMF determines that the service network segment is not capable of supporting the network capacity requested by the UE, it will request the NSSF to select a new network segment. In step 9a, the NSSF can select one or more network segment instances, potentially a new AMF set and an NRF. The NSSF can return any selection result, including the NSI ID, NSSAI address, NRF address, and AMF set. If a new AMF is selected, an AMF relocation process can be triggered in step 12b. If a new network segment is selected without an AMF change, the UE can connect to both network segments simultaneously. If the existing network segments cannot serve the UE, the NSSF can contact an operations and management (O&M) system to initiate a new network segment and the corresponding network segment instance to serve the UE. In step 8b, if the NCMF determines that the service network segment can support the network capacity requested by the UE, but the network capacity is not yet enabled, the NCMF may send a request to the NSSF to update the service network segment information to indicate that the network segment will support the network capacity. The NCMF may include in the request message the requested network capacity information, the NSI ID serving the UE, and the NSSAI serving the AMF. In stage 9b, the NSSF can update the network segment information and can respond to the NCMF for confirmation. In stage 10, the NCMF can also update the mapping information to indicate that the network segment is supporting the network capacity requested by the UE. In step 11, the NCMF may send a response to the duty AMF with all or part of the following information: NSSAI; New NSI ID for case "a" where a new network segment is selected; New AMF established for case "a" in which a new network segment is selected; and The configuration results in case "b" that the service AMF and the service network segment can support the network capacity. In step 12, the service AMF can update the UE context and service network segment information for case "b", or it can initiate the procedure to relocate the AMF for case "a". In stage 13, the service AMF can respond to the UE with a record update response to indicate the service network segment information if the service AMF is not changed. If the NSSF selects a new AMF, the target AMF can contact them to confirm the record update with the new network capability enabled. UE configuration update based on network capacity In addition to the UE, the network or an AS can also initiate a UE configuration update due to an upgrade of network capabilities in the service network segment. For example, the following events can trigger the network or an AS to start the process: A new application starts on the SCS / AS, and the UE subscribes to a new application service on the SCS / AS. As a result, new network capacity is required to support the new application. The network wishes to switch to a new network segment to serve the UE due to some reasons, such as a load balancing problem or scaling down the network function / network segment instance in the serving network segment. Figure 10 shows a method for UE configuration update based on network capability: In stage 0, this is a prerequisite stage assuming the UE completes registration with the network, and the UE has the connection to the application server (AS) through the network. In stage 1a, the AS may decide to add or upgrade network capacity on a network segment serving the UE due to a specific event, such as the requirement of a new application session. In the case of a new application, the AS may determine the requested network capacity types based on the type of new application. In stage 1b, the AMF decides to change the network segment that serves the UE for some reason, such as load balancing of the serving network segment. In stage 2a, the AS server sends a network capacity configuration request message to the NCMF via the NEF network. The information provided in this stage may be an NCP and may include the following information: EU ID such as SUPI, GUTI or external EU ID; NSSAI, which indicates the service network segment for the connection between the UE and the AS; New network capacity information that will be added to the network segment to support communication between the UE and the AS; Information related to the network capacity usage requirements for communication between the UE and the AS, such as a required network capacity availability schedule, a required network capacity QoS level (e.g., service response time, etc.), and a required multi-tenancy level (e.g., how many applications on the UE or AS will require the use of the requested network capacity(s); Application ID, indicating the application associated with the requested network capacity(s); Reference ID, which is used to refer to this network capacity configuration process; this can be assigned by the NEF; and NSI ID: Indicates the network segment instances that are serving the UE. In step 2b, the AMF sends the network capacity configuration request message to the NCMF. In stage 3, once it receives the request, the NCMF may optionally choose to contact the UDM / UDR to retrieve some further EU subscription information and EU context in the UDR. In stage 4, the NCMF can verify the network segment information and the requested network capacity information. The purpose of these checks is: Verify the information provided by the AS or network functions, such as network segment information, network segment instance information; and Determine whether the service network segment can support the requested network capacity and the network capacity usage requirements of the UE and AS. This can be done by checking the network capacity profile of the network segment. If not, proceed to step 5. In stage 5, if the NCMF finds that the service network segment cannot support the requested network capacity(ies), the NCMF may request the NSSF to select a new network segment or formulate a new network segment. It is also possible that the NCMF may find the service network segment is overloaded, and if so, it may request the NSSF to select a new segment. In step 6, the NCMF or NSSF notifies the AMF to continue with the network configuration process. If the process is triggered by the AS (i.e., steps 1a and 2a), the AMF will be provided with the 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 later. In step 7, the AMF communicates with the UE to trigger the UE configuration update. In the message, the AMF will notify the UE with an NCP for the segment that includes one or more of the following information: New network capacity information; NSSAI that identifies the network segment, especially in the case of selecting a new network segment; Reference ID; and SCS / AS ID. In stage 8, the UE initiates the registration update process, which is shown in figure 9. In stage 9, once the record update process has been completed, the AMF sends the message to respond to the AS through the NEF in case the AS initiates the process. Note that Figure 10 shows the scenario where the AMF initiates the process as an example of a network entity initiating the process. It is also possible for other network entities to initiate the process. For example, the PCF might initiate the process due to a UE policy change or a network segment selection policy change. Therefore, the PCF could trigger a network segment selection process, which could potentially affect the provisioning of network capacity for the UE. Registration procedure with network capacity profile for requested NSSAI The NCMF can configure network capabilities for network segments and build a Network Capability Profile (NCP) for each segment. This section elaborates on the methods described earlier in this document and describes a method by which NCPs can be delivered to the UE along with the NSSAI (for example, one NCP per S-NSSAI). Figure 13 represents the method and illustrates how the Initial Registration procedure can be enhanced to support network capability configuration; however, it should be noted that the same enhancements can be applied to the Mobility Registration Update and Periodic Registration Update procedures. Figure 13 illustrates how the initial registration, mobility registration, and periodic registration procedures, defined in 3GPP TS 23.502, can be updated. Figure 13 focuses particularly on the parts of the Registration procedure that can be improved or require the most improvement. Some steps are omitted. Note that Figure 13 shows the NCMF as a standalone NF or logical function. Instead, it may be part of the OAM system or part of another NF such as the SMF or AMF. As illustrated in Figure 13, the AMF can determine the capacities of the segments to which the UE will register and provide this capacity information to the UE. Additionally, the UE may request specific capacities. Furthermore, the network can provide the UE with a list of associated S-NSSAIs and NCPs to which the UE can register. In stage 1, the UE submits a registration request. This request includes a UE-requested NSSAI that submits a request to the AMF via the (R)AN node. The registration request can be an initial registration, a mobility registration update, or a periodic registration update. As described earlier in this document, the Registration Request can include an NCP to indicate to the network what capabilities are desired for each S-NSSAI within the NSSAI. In stage 2, node (R) AN selects an AMF as described in TS 23.501 [1], clause 6.3.5. In stage 3, the (R) AN node forwards the registration request message to the AMF. In stage 4, based on the EU registration request, the AMF may consult the UDM / UDR to obtain the EU subscription. The EU subscription may include the S-NSSAI Subscribed. In stage 5, if the information was not obtained in the previous stage, then, for each S-NSSAI in the permitted NSSAI, the AMF may request the NCMF's network capacity profile. The key for such a query should include the S-NSSAIs (i.e., the NSSAI). Alternatively, the AMF can obtain the NCP that is associated with each S-NSSAI by querying another NF such as the NSSF or the NRF to obtain the NCP that is associated with each S-NSSAI. In step 6, the NCMF can send the NCP(s) for the requested S-NSSAI back to the AMF. In step 7, as part of the registration acceptance message, the AMF sends an allowed NSSAI and a configured NSSAI to the UE, and an NCP for each S-NSSAI in the allowed NSSAI and an NCP for each S-NSSAI in the configured NSSAI. The NCP can be considered part of the allowed NSSAI and the configured NSSAI. Optionally, the network can send an Advertisement NSSAI to the UE. An Advertisement NSSAI is a list of S-NSSAIs and their corresponding NCPs. This list and the corresponding S-NSSAIs can serve as an advertisement for which segments are available to the UE and an indication of the capabilities of each segment. The S-NSSAIs in the Advertisement NSSAI might not be part of the Request NSSAI or the Permitted NSSAI. The purpose of the Advertisement NSSAI could be to provide the UE with information about which segments it can request to be added to its Configured NSSAI or Permitted NSSAI. Alternatively, the Advertisement NSSAI could be part of the Configured NSSAI. In step 8, if the UE determines that the permitted NSSAI and / or any of the NCPs provided by the S-NSSAI are insufficient in the sense that the segment capabilities are inadequate, then the UE can evaluate the advertising NSSAI and, if it finds one or more suitable S-NSSAIs within the advertising NSSAI, initiate a record update procedure and include the S-NSSAIs from the advertising NSSAI in the requested NSSAI. The UE and the network can then execute the record update procedure, and the network can update the UE's permitted NSSAI and configured NSSAI accordingly. Delivery of network capacity profile with EU policy update EU policies related to NCPs may be referred to as NCP policies or NCPPs. This section describes a method by which a core network can deliver one or more NCPs as part of the EU policies to the UE. Note that NCP policies can be sent to the UE using the UE configuration update for the transparent UE policy delivery procedure defined in 3GPP TS 23.502. Figure 14 illustrates the method, focusing on how the existing procedure can be improved. This method can be triggered by several events, which are described in Step 0. In stage 0, an event may occur. An event notification may be sent to the PCF so that the PCF can determine if the NCP policies need to be updated. Examples of events are: The OAM system or an authorized AS can send an upgrade and NCP request. The request can be sent through a NEF. For example, an AS or the OAM can send a request to the NEF to increase the maximum UL or DR data rate allowed per UE on the segment, or to increase or decrease the maximum number of PDU sessions allowed on a segment. The PCF receives a notification from an AMF that a UE has changed location (for example, the UE's policies may be restricted to a geographical region and therefore may need to be updated with new policies). The PCF receives a notification that there has been a change in the Subscribed S-NSSAI for a UE or group of UEs (for example, the network administrator can update the UE's subscription with a new S-NSSAI). The PCF receives a notification that a UE has moved from EPS to 5GS. The UE will receive a new set of UE policies for 5GS. A UE sends a policy update request to the PCF (via NAS). The UE's request for a UE policy update might be in response to the download, launch, and / or installation of an application that requires new network capabilities. For example, a user might download a game application that requires AR / VR settings. This might necessitate a new set of policies to accommodate the change in data rate and other CN resources. The request might include an Application or OS Identifier. The PCF receives a notification from the OAM or NRF that the network functions associated with the segment are being reconfigured (e.g., new NFs are instantiated or removed, existing NFs are scaled up or down). The NCMF sends updated NCP information for an S-NSSAI to the PCF. In stage 1, the PCF checks the latest PSI list to decide which policies related to UE access selection and / or PDU session selection need to be sent to the UE. Alternatively, the PCF may contact the NCMF to obtain a new set of NCPs for the S-NSSAI, or the NCMF may send new NCP information for the S-NSSAI to the PCF. The PCF populates the enhanced UE policy, which includes the NCPP. In stage 2, the PCF invokes the AMF's Namf_Communication_N1N2MessageTransfer service operation. The message includes SUPI, the UE Policy Container. The UE Policy Container includes the NCPP for the UE. In other words, the NCPs, like any other UE policy, are treated as UE policies by 5GS; they are either standalone policies or the information is integrated with ANDSP or URSP policies. In stage 3, if the UE is registered and reachable by the AMF on the 3GPP access or on the non-3GPP access, the AMF will transparently transfer the UE policy container (which includes the NCPP) to the UE through one of the registered and reachable accesses based on the AMF local policy. In stage 4, the UE receives and stores the NCPP policies. The policies can be considered standalone policies, or the NCP information described here as part of policies can be provided to the UE as part of URSP or ANDSP rules. Examples of how the EU can take action based on policies are: If the NCP policy specifies a new periodic traffic rule, the UE may need to update the receive or transmit period for periodic traffic. Conversely, if the UE did not have a policy for periodic traffic, it can implement a new policy by sending and receiving messages within a specified time period. For example, the UE might need to continuously send a sensor reading to a server every 10 seconds, which could be updated to 5 seconds as the UE is expected to travel at high speed. Periodic traffic rules can be integrated into URSP rules by improving the URSP validation criteria so that communication periods can be specified to the UE. The UE can then consider this information when evaluating the URSP rules. If the NCP policy specifies a maximum UL and / or DL ​​data rate, then when the UE evaluates the URSP rules, it can consider the maximum UL and DL data rates provided in the NCP information. The UE can choose not to establish a route described in an RSD or URSP and instead establish a lower precedence route. For example, the lower precedence route might allow a higher maximum UL or DL ​​data rate. When the route is established, the UE can provide the maximum UL and / or DL ​​data rates to the application that initiated the traffic and to any other application that uses the same route after the route is established. Additionally, if the NCP specifies a maximum UL throughput per segment, the UE enforces the limit by monitoring the aggregate throughput of all PDU sessions on the segment. If the NCP policy specifies location-based messaging and the UE appears to be in the 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 validation criteria in URSP rules, or the network may provide this information to the UE as a separate NCP policy that is considered when evaluating all URSP rules. In other words, the policy may be considered when evaluating all routes that include the S-NSSAI based on the NCP policy. The UE can send a registration update request to the network to register with a different segment that may allow for more favorable NCP policies. In other words, the UE can send a mobility registration update request, and the request may include an updated requested NSSAI, but the updated requested NSSAI may not include an S-NSSAI for which the UE has just received policies. Managing the maximum number of PDU sessions This section describes procedures on how the network handles the predefined limit for a number of PDU sessions per network segment and how the UE can handle the request if it finds that no more PDU sessions can be established. Handling maximum PDU sessions during the PDU session establishment process The network can support a maximum limit on the number of PDU sessions that can be established within a network segment. There may be scenarios where the network segment reaches its maximum limit but can still receive PDU session establishment requests from UEs. This section describes how such a request can be handled. Figure 15 illustrates the method and demonstrates how the existing PDU Session Establishment procedure defined in 3GPP TS 23.502 can be improved. Figure 15 focuses particularly on the parts of the Registration procedure that need improvement or require the most enhancement. In stage 0, the network segment is configured with a limit on the maximum number of PDU sessions allowed per segment. This is configured in the NCMF. The NCMF includes a PDU session counter, which counts the number of PDU sessions that join the network segment. This session counter increments or decrements by 1 for each PDU session established or released, respectively. The NCMF can receive a notification from the SMF when a PDU session is established. In stage 1, the UE sends a PDU session establishment request to the AMF via the (R)AN node. In stage 2, after receiving the PDU session establishment request from the UE, the AMF or SMF sends a request to the NCMF to check if a new PDU session can be established on the segment. The request includes the S-NSSAI. The NCMF checks the segment's PDU session counter to see if the number of PDU sessions on the segment is below the maximum value. If the NCMF indicates that the number of PDU sessions is below the maximum value, then the PDU session will be allowed; otherwise, it will not be allowed, and the PDU session establishment request will be rejected. In step 3, the remainder of the TS 23.501 PDU session establishment procedure is executed, and the PDU session establishment response is sent to the UE. If the NCMF informed the AMF or SMF that the PDU session should not be allowed (i.e., that the segment has reached its maximum number of PDU sessions), then the AMF or SMF may send an error / cause code to the UE indicating that the network segment has reached its maximum limit for PDU session count and reject the request. In this case, the UE may re-evaluate its URSP rules and attempt to establish a PDU session within a different segment. The response may also include a wait timer, indicating how long the UE should wait before attempting to establish a PDU session within the same segment.Although the UE can reset the wait timer and retry if a PDU session with the same segment ends before the wait timer expires, the wait time can be integrated into the time window (route selection validation criteria) in the URSP rules. Therefore, the URSP rule is re-evaluated before attempting to establish a PDU session. After receiving a PDU session establishment rejection message, the UE can: Re-evaluate your URSP rules with the knowledge that the reject segment is unavailable and attempt to establish a PDU session based on a lower precedence URSP or RSD rule. Wait for the duration of the wait timer and then re-evaluate your URSP rules and attempt to establish a PDU session again within the same segment. Terminate a PDU session with the same segment, clear / override the wait timer if it hasn't expired, and then re-evaluate your URSP rules and attempt to establish a new PDU session within the same segment. It is proposed that the PDU Session Establishment Request be modified to allow the UE to specify the PDU Session IDs from the segment that can be terminated. This improvement to the PDU session establishment procedure may be desirable in cases where a segment is PDU session-limited and the UE is willing to terminate a lower-priority PDU session on the condition that it can immediately establish a new, higher-priority PDU session. Managing maximum PDU sessions using a NAS notification This section describes a method that uses NAS notification to inform the UE that a network segment has reached its maximum limit. Figure 16 illustrates the method. In stage 0, the network segment is configured with a limit on the maximum number of PDU sessions allowed per segment. This is configured in the NCMF. The NCMF includes a PDU session counter, which counts the number of PDU sessions that join the network segment. This session counter increments or decrements by 1 for each PDU session established or released, respectively. The NCMF can receive a notification from the SMF when a PDU session is established. The AMFs and SMFs within the segment subscribe to the NCMF to be notified when the number of PDU sessions within the segment reaches or falls below the maximum value. In stage 1, a UE and the network execute the PDU session establishment procedure as described in section 4.3.2.2.1 of 3GPP TS 23.502. Upon receiving the PDU session establishment request from the UE, the AMF or SMF sends a request to the NCMF to check if a new PDU session can be established on the segment. The request includes the S-NSSAI. The NCMF checks the segment's PDU session counter to see if the number of PDU sessions on the segment is below the maximum value. If the NCMF indicates that the number of PDU sessions is below the maximum value, then the PDU session is allowed; otherwise, it is not allowed, and the PDU session establishment request is rejected. The case where the PDU session is rejected is described earlier in this document. In the example for this procedure, it is assumed that the PDU session establishment is successful. In stage 2, the AMF or SMF receives a notification from the NCMF that the network segment has reached the maximum number of PDU sessions. In stage 3, the AMF sends a NAS notification to all UEs registered in the segment. The NAS notification includes a wait timer, indicating how long the UE must wait before attempting to establish a PDU session within the segment. The UE can reset the wait timer and attempt again if it completes a PDU session with the same segment before the wait timer expires. This wait time can be integrated into the time window of the route selection validation criteria in the URSP rules. The URSP rules would then be re-evaluated before attempting to establish a PDU session. In Stage 4, the Hold Timer expires or a UE terminates a PDU session with the same segment. In Stage 5, the PDU Session Termination Procedure decrements the NCMF counter and causes the PDU Session Counter to fall below a predetermined value. The NCMF sends a notification to the AMF and SMF when the number of PDU sessions within the segment falls below the predetermined value. In step 6, the AMF sends a NAS notification to all UEs registered in the segment. The NAS notification indicates that the condition has been cleared and that PDU sessions can now be established in the segment. Alternatively, the notification can be sent only to UEs whose PDU session establishment requests were rejected with a cause code. In Stage 7, the UE can reset the standby timer and attempt to establish a PDU session on the segment. Managing the maximum number of UEs in a network segment The network may be equipped with the capability to limit the maximum number of UEs that can register with the network segment at one time. There may be scenarios where the network receives a request from a UE to register with a network segment that has reached its maximum limit of registered UEs. This section describes a method for handling such a case. Figure 17 illustrates the method. In Stage 0, the counter can be maintained at the NCMF. The counter increments or decrements by 1 for each registered or deregistered UE. When a UE is registered or deregistered, the AMF can send an indication / notification to the NCMF so that the counter can be incremented or decremented accordingly. The NCMF may have subscribed to all AMFs in the segment so that it can receive a notification when a UE registers in the segment. The subscription request may indicate the S-NSSAI, and the AMF notification may include the UE ID and the S-NSSAI so that the NCMF can track which UEs are registered, check the status of registered UEs, and avoid counting errors in situations where notifications are received about UE registration or deregistration.The NCMF may also indicate to the AMF that the number of UEs registered in the segment is limited, so the AMF must check with the NCMF for permission to register a new UE (i.e., check that the limit has not been reached). In stage 1, a UE (UE1) and the network execute the UE registration procedure as described in section 4.2.2.2 of 3GPP TS 23.502. Upon receiving the UE registration request from UE1, the AMF sends a request to the NCMF, or invokes an NCMF service, to check whether a new UE can register on the segment. The request includes the S-NSSAI. The NCMF checks the segment's UE registration counter to see if the number of UEs registered on the segment is below the maximum value. If the NCMF indicates that the number of UEs registered on the segment is below the maximum value, then UE registration is permitted; otherwise, it is not permitted, and the UE registration request is rejected. At this stage of the procedure, UE registration from UE1 is assumed to be successful. In stage 2, the AMF may receive a notification from the NCMF that the network segment has reached the maximum number of UEs. The NCMF may provide the AMF with a hold timer to indicate how long the UE should wait before attempting to register with the S-NSSAI again. In stage 3, a different UE (for example, UE2) can send a UE registration request to the network. The request can specify, for each segment, that if registration is rejected on a segment, the UE would like to be notified when the cause of rejection has been resolved. Note: If the AMF has not already received a notification from the NCMF that the network segment has reached the maximum number of UEs, the AMF may consult the NCMF to check if it is OK to register the UE, as described in Step 1. In step 4, if the AMF has been informed that the network segment has reached its maximum UE registration limit, the AMF may send a UE registration response message to UE2, indicating that the request was rejected and a cause value indicating that the request was rejected because the segment has reached the maximum number of registered UEs. The rejection may also provide the UE with a hold timer that the UE should use to determine when it can attempt to request UE registration again on the same segment. Otherwise, if the segment limit has not been reached, UE2 and the network execute the registration procedure as described in section 4.2.2.2 of 3GPP TS 23.502. In stage 5, a UE (e.g., UE3), which was already registered in the network segment, can unregister from the network segment. In stage 6, the AMF can notify the NCMF about this UE deregistration. The NCMF can then decrease the counter. Additionally, the NCMF can send a notification informing the AMF that the network segment is now below its maximum limit. In stage 7, the AMF can send a NAS notification to any UE (e.g., UE2) that was rejected from logging with a cause code (i.e., a message about the network segment reaching the maximum limit and a hold-down timer) and still has a hold-down timer running. This NAS notification indicates that the limit condition has been cleared. In stage 8, after receiving the NAS message from the network, the UE2 can reset the standby timer and attempt to register with the segment. Alternatively, the UE can attempt UE registration after the standby timer expires. Note that this procedure can be considered an extension, or improved explanation, of the network capacity-based registration procedure described earlier in this document. Handling maximum UL and DL data rates within a segment As described above, the network can provide the UE with the maximum UL and DL data rates that the UE can use within a segment. These maximum data rates apply across all PDU sessions within the segment. The network can also provide this information to the UE whenever a PDU session is established within the segment. The network can send a NAS notification to the UE whenever it detects that the UE has exceeded the maximum UL or DL ​​data rate within the segment. The notification can specify the maximum UL or DL ​​data rate to the UE so that the UE can apply it. NCMF Service As described above, the NCMF is responsible for managing and maintaining information related to network capabilities and network segments. Table 5 shows a list of NCMF services that can be provided to enable these operations. Table 1: List of NCMF services Alternatively, if the NCMF is co-located with the NSSF or the UDM / UDR, the NCMF services shown in Table 5 can be defined as NSSF services or UDM / UDR services. New UPF service In the 5G service-based architecture, the UPF is not explicitly defined as a user plane function. However, the UPF does provide some control functionalities, such as QoS enforcement, data buffering, and event monitoring. Additional UPF services can be added by extending the service-based architecture to include the UPF. Figure 11 illustrates an extended service-based architecture with a UPF and Nupf interface. Table 6 lists the available UPF services. Table 2: UPF Service Lists Nupf_EventExposure This service allows other NFs to subscribe to certain events at the UPF and are notified when those subscribed events occur. The UPF can provide subscription service for the following events: The DL data packet temporarily stored at the UPF is discarded due to a timeout threshold or limited storage. This could be due to QoS flow, session, UE, or UPF. A UPF is selected as the uplink classifier for the local data network or branch point for the multi-entry PDU session. The UPF is selected as the anchor point of a PDU session via either 3GPP access or non-3GPP access (i.e., via N3IWF). A packet is dropped because the policy rule applies to a particular traffic by the UPF, including information from SCS / AS that originates the traffic, and which specific rule applies. The total number of connected UEs supported by UPF exceeds a certain threshold. The total number, or rate, of rejected or failed connection attempts exceeds a threshold. This could be further configured to request a notification if the total number, or rate, of rejected or failed connection attempts with a particular cause exceeds a threshold. Computing resources are below a threshold. The total number of sessions that UPF is managing exceeds a certain threshold. The total (guaranteed) data rates of the sessions that UPF is managing exceed a certain threshold. The use of the memory allocated for temporary storage of downlink data exceeds a certain threshold. The mapping of DL data traffic to the QoS flow fails without any PDR adjusting the application data. The following information may be involved in the (non-)subscription request or notification message: Subscription ID notification address / ID Event ID and corresponding parameters: For example, if the event is that a PDU session is congested, then the PDU session ID, QFI, and resource utilization percentage will be included. If the event is that a packet is dropped, then the cause of the drop, the session ID, the QFI, and the number of packets temporarily stored in UPF will be provided. The NEF can be a service consumer in the event that the AF cannot direct access to the UPF through the service-based interface. Nupf_StatusMonitoring This service offers NFs the opportunity to obtain information from UPF regarding the PDU session status and the QoS application status. UPF can provide the following information through this service: The number of PDU sessions is serving UPF as an anchor point, branching point, or uplink classifier, respectively. Amount of downlink data temporarily stored in UPF. This could be per application, per UE, per UE group, per PDU session, per QoS flow, or per location (i.e., within a network area). The number of PDU sessions that connect a UE via non-3GPP access. The bit rate currently being implemented. This could be per application, per UE, per UE group, per PDU session, per QoS flow, or per location (i.e., within a network area). The packet error rate (loss rate). This could be per application, per UE, per UE group, per PDU session, per QoS flow, or per location (i.e., within a network area). Percentage of storage resources used for temporary data storage. Information related to characterization, such as CDR. The NEF can be a service consumer in the event that the AF cannot direct access to the UPF through the service-based interface. Nupf_PDUSession This service provides the SMF with the ability to initiate certain procedures for managing PDU sessions, such as creating, updating, and releasing a PDU session. The SMF can include the following information for the PDU session-related procedure: PDU session ID and associated network segment ID, such as S-NSSAI and network segment instance ID DNN PDU session type, for example, non-IP, Ethernet, or IP type Session mode and service continuity (SSC) The QFI and related QoS parameters, such as maximum bit rate per QoS, maximum aggregate bit rate per session, and maximum packet loss rate. Indication of reflective QoS support Packet detection rules (PDR) for both DL and UL traffic SMF information, such as SMF ID, SMF instance ID Tunnel information for tunnels N3 and N6 (e.g., for NIDD forwarding) respectively Pricing policy identifier Indication that the UPF is added or removed as an uplink classifier or branch point related to a PDU session. UE IDs, such as 5G-GUTI and SUPI IP address and port number Example graphical user interface Figure 12 shows an exemplary user interface that can be used to configure network capacity(ies) in a 5G network. The user interface can be viewed by or for an end device (UE), a service provider (SCS / AS), a network operator, or another network entity or user. For example, the user interface can be viewed in display 128 or 86 in Figures 1B and 1G, respectively. Figure 18 depicts a user interface through which a UE can receive NCPs for permitted S-NSSAI from the network. Based on application requirements, the UE can accept a network segment based on the received NCPs or request a new NCP / network segment from the core network. It is understood that the network entities described above, including those that perform the steps illustrated in Figures 8-10, such as UE, (R)AN, AMF, NCGF, NSSF, UDR / UDSF, UDM / UDR, NRF, NEF, PCF, NF, SCS / AS, (R)AN, SMF and the like, may be logical entities that can be implemented in the form of software (i.e., computer executable instructions) stored in a memory of, and executed on a processor of, an apparatus configured for wireless and / or network communications or a computer system such as those illustrated in Figure 1B or Figure 1G.That is, the method(s) illustrated in Figures 8-10 can be implemented as software (i.e., computer-executable instructions) stored in the memory of a device, such as the device or computer system illustrated in Figure 1B or Figure 1G. These computer-executable instructions, when executed by the device's processor, perform the steps illustrated in Figures 8-10. It is also understood that the functionality illustrated in Figures 8-10 can be implemented as a set of virtualized network functions. These network functions may not necessarily communicate directly but may instead communicate through a forwarding or routing function.It is also understood that any transmission and reception stage illustrated in Figures 8-10 can be carried out by means of the device's communication circuitry under the control of the device's processor and the computer-executable instructions (e.g., software) that it executes. The illustrations of the aspects described herein are intended to provide a general understanding of the structure, function, and operation of the various aspects. The illustrations are not intended to serve as a complete description of all the elements and features of the apparatus and systems that utilize the structures or methods described herein. Many other aspects may be evident to those skilled in the art after reviewing the disclosure. Other aspects may be used and derived from the disclosure, so that structural and logical substitutions and changes may be made without departing from the scope of the disclosure. Accordingly, the disclosure and figures should be considered illustrative rather than restrictive. The description of the aspects is provided to enable the implementation or use of those aspects. Various modifications to these aspects will be readily apparent, and the generic principles defined herein may be applied to other aspects without exceeding the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein but should be given the broadest possible scope consistent with the scope defined by the following claims.

Claims

1. A wireless transmit / receive unit, WTRU, (102) comprising a processor (118) and a memory (130), the memory storing instructions which, when executed by the processor, cause the WTRU to perform operations comprising: sending, to a network function, an initial message indicating that an operation is requested on a network segment, wherein the operation comprises a segment register; and receiving, from the network function, a response comprising a rejection code indicating that the operation is rejected as a result of the network segment having reached a maximum number of registered WTRUs.

2. The WTRU according to claim 1, wherein the network function comprises an Access and Mobility Management Function, AMF.

3. The WTRU according to claim 1,wherein the response further comprises an indication of a quantity of time that the wireless transmit / receive unit must wait before sending another message indicating a request for the operation to be performed.

4. The WTRU according to claim 3, wherein the instructions further cause the WTRU to send, after the expiration of the quantity of time, another message indicating a request for the operation to be performed.

5. The WTRU according to claim 1, wherein the instructions further cause the WTRU, based on the response, to terminate the segment registration.

6. The WTRU according to claim 1, wherein the instructions further cause the WTRU to: receive, from the network function, a non-access stratum (NAS) message comprising an indication that the operation may be requested again; and send, in response to the NAS message,another message indicating a request for the operation to be performed.

7. A method implemented by a wireless transmit / receive unit, WTRU, the method comprising: sending to a network function a first message indicating that an operation is requested to be performed on a network segment, wherein the operation comprises a segment registration; and receiving from the network function a response comprising a rejection code indicating that the operation is rejected as a result of the network segment having reached a maximum number of registered WTRUs.

8. The method according to claim 7, wherein the network function comprises an Access and Mobility Management Function, AMF.

9. The method according to claim 7,wherein the response further comprises an indication of a quantity of time that the wireless transmit / receive unit must wait before sending another message indicating a request for the operation to be performed.

10. The method of claim 7, wherein the method comprises sending, after the expiration of the quantity of time, another message indicating a request for the operation to be performed.

11. The method of claim 7, wherein the method comprises, based on the response, terminating the segment registration.

12. The method of claim 7, wherein the method comprises: receiving, from the network function, a no-access stratum (NAS) message comprising an indication that the operation may be requested again; and sending, in response to the NAS message,another message indicating a request for the operation to be performed.

13. An apparatus (90) implementing a first network function and comprising a processor (91) and a memory (82), the memory storing instructions that, when executed by the processor, cause the apparatus to perform operations comprising: receiving, by means of the first network function from a wireless transmit / receive unit, WTRU, (102), a first message, wherein the first message indicates a request to perform an operation on a network segment and wherein the operation comprises a segment register; sending, by means of the first network function to a second network function, a second message, wherein the second message indicates a request for a determination of whether a threshold related to the operation is met, wherein the threshold is associated with a maximum number of WTRUs that can be registered with the network segment; receiving,by means of the first network function from the second network function, a first response indicating whether the threshold has been met; and sending, by means of the first network function to the WTRU, a second response comprising an indication of whether the operation is permitted, wherein, when the operation is not permitted, the second response comprises a rejection code indicating that the operation is rejected as a result of the network segment having reached the maximum number of registered WTRUs.

14. The apparatus according to claim 13, wherein the first network function comprises an Access and Mobility Management Function, AMF.

15. A method carried out by an apparatus (90) implementing a first network function, the method comprising: receiving, by means of the first network function from a wireless transmit / receive unit, WTRU, a first message,wherein the first message indicates a request to perform an operation on a network segment, and wherein the operation comprises a segment registration; sending, via the first network function to a second network function, a second message, wherein the second message indicates a request for a determination of whether a threshold related to the operation is met, wherein the threshold is associated with a maximum number of WTRUs that can be registered with the network segment; receiving, via the first network function from the second network function, a first response indicating the determination of whether the threshold is met; and sending, via the first network function to the WTRU, a second response comprising an indication of whether the operation is permitted, wherein, when the operation is not permitted,The second response comprises a rejection code indicating that the operation is rejected as a result of the network segment having reached the maximum number of registered WTRUs.

Images