Methods for strengthening protocols in 5G NAS

Abstract

To provide methods, systems, and apparatuses for PDU session management over different access technologies (ATs).SOLUTION: A WTRU may receive a first message from a network over a first access technology. The first message may include an indication for the WTRU to reestablish resources for one or more PDU sessions over a second access technology. The WTRU may determine that the one or more PDU sessions are locally deactivated by the WTRU. The WTRU may determine that it is in a limited service state associated with the second access technology. The WTRU may send a second message via the first access technology. The second message may include a PDU session status information element (IE) indicating the PDU sessions are locally deactivated such that the network releases the PDU sessions.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 62 / 616,687, filed on January 12, 2018; U.S. Provisional Patent Application No. 62 / 653,817, filed on April 6, 2018; and U.S. Provisional Patent Application No. 62 / 716,516, filed on August 9, 2018, the contents of which are incorporated herein by reference.

Background Art

[0002] The 5th generation (5G) mobile network can enable a wireless transmit - receive unit (WTRU) to register with the same access and mobility function (AMF) via both 3rd Generation Partnership Project (3GPP) access technology and non - 3GPP access technology (e.g., WiFi) within the same public land mobile network (PLMN).

Summary of the Invention

[0003] A method for managing protocol data unit (PDU) sessions via separate access technologies (ATs) is disclosed. A radio transceiver unit (WTRU) can receive a first message from a network via a first access technology. The first message can trigger the activation or reactivation of one or more PDU sessions via a second access technology. The WTRU can determine that one or more PDU sessions are locally deactivated by the WTRU. The WTRU can determine that they are in a limited service state associated with the second access technology. The WTRU can send a second message via the first access technology. The second message can include a PDU session status information element (IE) indicating that one or more PDU sessions are locally deactivated, thereby causing the network to release the PDU sessions.

[0004] A WTRU is disclosed. This WTRU may include an antenna and a processor operably coupled to the antenna. The processor and antenna may be configured to receive a first message from the network via a first access technology. The first message may trigger the activation or reactivation of one or more PDU sessions via a second access technology. The processor may be configured to determine that one or more PDU sessions are locally deactivated. The processor may be further configured to determine that the WTRU is in a limited service state via a second access technology. The processor and antenna may be further configured to send a second message via the first access technology. The second message may include a PDU session status information element (IE) indicating that one or more PDU sessions are locally deactivated, thereby causing the network to release the PDU sessions. [Brief explanation of the drawing]

[0005] A more detailed understanding can be obtained from the following explanation provided with the attached drawings, and similar reference numbers in the drawings refer to the same elements. [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments can be implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transceiver unit (WTRU) that can be used in the communication system shown in Figure 1A, according to an embodiment. [Figure 1C] This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that can be used in the communication system shown in Figure 1A according to an embodiment. [Figure 1D] This is a system diagram showing further exemplary RANs and exemplary CNs that can be used in the communication system shown in Figure 1A according to an embodiment. [Figure 2] This flowchart illustrates the procedure for transferring Protocol Data Units (PDUs) via separate Access Technologies (ATs). [Figure 3] This flowchart illustrates the procedure for managing PDUs via separate ATs. [Figure 4A] This flowchart shows the first example of signaling for handling race conditions. [Figure 4B] This flowchart shows a second example of signaling for handling race conditions. [Figure 4C] This flowchart illustrates a third example of signaling for handling race conditions. [Figure 5] This is a diagram showing Extended Protocol Identifiers (EPDs). [Figure 6] This diagram shows how to use the method to renew your subscription type. [Modes for carrying out the invention]

[0006] Figure 1A shows an exemplary communication system 100 in which one or more disclosed embodiments can be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcasting, etc., to multiple radio users. The communication system 100 may enable multiple radio users to access such content through the sharing of system resources, including radio bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), quadrature FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filtered bank multicarrier (FBMC), etc.

[0007] As shown in Figure 1A, the communication system 100 may include radio transceiver units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments assume any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d, any of which can be called “stations” and / or “STAs,” can be configured to transmit and / or receive radio signals and can include user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, IoT devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics, and devices operating on commercial and / or industrial wireless networks. Any of WTRU102a, 102b, 102c, and 102d may be referred to as UEs.

[0008] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, e.g., CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be a base transceiver station (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR Node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are shown as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0009] Base station 114a may be part of RAN 104 / 113, 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), and relay nodes. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for radio services to a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In embodiments, the base station 114a may employ MIMO technology and utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0010] Base stations 114a and 114b are capable of communicating with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, the air interface 116 can be any suitable radio communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 can be established using any suitable radio access technology (RAT).

[0011] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRU 102a, 102b, 102c in RAN 104 / 113 can implement radio technologies such as UMTS (Universal Mobile Telecommunications System) Terrestrial Radio Access (UTRA), which can establish air interfaces 115 / 116 / 117 using broadband CDMA (WCDMA®). WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

[0012] In embodiments, base stations 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA) that can establish an air interface 116 using Long-Term Evolution (LTE) and / or LTE Advanced (LTE-A) and / or LTE Advanced Pro (LTE-A Pro).

[0013] In the embodiment, base stations 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as NR radio access, which enables the establishment of an air interface 116 using New Radio (NR).

[0014] In embodiments, base stations 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base stations 114a and WTRUs 102a, 102b, and 102c can implement both LTE and NR radio access, for example, using a dual-connection (DC) principle. Thus, the air interface utilized by WTRUs 102a, 102b, and 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to and from multiple types of base stations (e.g., eNBs and gNBs).

[0015] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c can implement wireless technologies such as IEEE 802.11 (i.e., WiFi (Wireless Fidelity)), IEEE 802.16 (i.e., WiMAX (Worldwide Interoperability for Microwave Access)), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), GSM (Registered Trademark) (Global System for Mobile Communications), EDGE (Enhanced Data Rates for GSM Evolution), and GSM EDGE (GERAN).

[0016] In Figure 1A, base station 114b can be, for example, a wireless router, home Node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas, such as businesses, homes, vehicles, campuses, industrial facilities, aerial walkways (e.g., for drone use), and roadways. In one embodiment, base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRU 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. As shown in Figure 1A, base station 114b can have a direct connection to the internet 110. Therefore, base station 114b may not be required to access the internet 110 via CN 106 / 115.

[0017] RAN104 / 113 can be in communication with CN106 / 115, which can be any type of network configured to provide voice, data, applications, and / or VoIP services to one or more of WTRU102a, 102b, 102c, and 102d. The data can have various quality of service (QoS) requirements, such as separate throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 can provide call control, billing services, mobile location services, prepaid calling, internet connectivity, video distribution, and / or perform high-level security functions, such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 can be in direct or indirect communication with other RANs employing the same RAT as RAN104 / 113 or different RATs. For example, CN106 / 115 can be connected to RAN104 / 113, which is capable of utilizing NR radio technology, and can also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0018] CN106 / 115 can also serve as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 can include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols, such as TCP, UDP, and / or IP in the TCP / IP Internet protocol suite. The network 112 can include wired communication networks and / or wireless communication networks that are owned and / or operated by other service providers. For example, the network 112 can include another CN that is connected to one or more RANs that can employ the same RAT or a different RAT as the RAN104 / 113.

[0019] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 can include a multi-mode function (e.g., the WTRU102a, 102b, 102c, 102d can include multiple transceivers to communicate with different wireless networks via separate wireless links). For example, the WTRU102c shown in Figure 1A can be configured to communicate with a base station 114a that can employ a cellular-based wireless technology and a base station 114b that can employ IEEE802 wireless technology.

[0020] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 can include, among other things, a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a GPS chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU 102 can include any sub-combination of the above elements while maintaining consistency with the embodiments.

[0021] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an ASIC, an FPGA circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, and the transceiver 120 can be coupled to the transmitting / receiving element 122. Although Figure 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0022] The transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmitting / receiving element 122 can be an emitter / detector configured to transmit and / or receive, for example, IR signals, UV signals, or visible light signals. In yet another embodiment, the transmitting / receiving element 122 can be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmitting / receiving element 122 can be configured to transmit and / or receive any combination of radio signals.

[0023] Although the transmitting / receiving element 122 is shown as a single element in Figure 1B, the WTRU 102 can include any number of transmitting / receiving elements 122. More specifically, the WTRU 102 can employ MIMO technology. Therefore, in one embodiment, the WTRU 102 can include two or more transmitting / receiving elements 122 (e.g., multiple antennas) to transmit and receive radio signals via the air interface 116.

[0024] The transceiver 120 can be configured to modulate the signal to be transmitted by the transmitting / receiving element 122 and to demodulate the signal received by the transmitting / receiving element 122. As described above, the WTRU 102 can have multimode functionality. Therefore, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0025] The processor 118 of the WTRU102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from there. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. The processor 118 can also access information from any type of suitable memory, such as a non-removable memory 130 and / or removable memory 132, and store data in those memories. The non-removable memory 130 can include RAM, ROM, a hard disk, or any other type of memory storage device. The removable memory 132 can include a SIM card, a memory stick, an SD memory card, etc. In other embodiments, the processor 118 can access information from memory on a server or home computer (not shown) that is not physically located on the WTRU102, and store data in that memory.

[0026] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 can include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), a solar cell, a fuel cell, etc.

[0027] The processor 118 may also be coupled to a GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more neighboring base stations. It will be understood that the WTRU 102 may acquire location information through any suitable location determination method while maintaining consistency with the embodiments.

[0028] The processor 118 can be further coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide further features, functionality, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, e-compass, satellite transceiver, digital camera (for photos and / or video), USB port, vibration device, television transceiver, hands-free headset, Bluetooth® module, frequency modulation (FM) radio unit, digital music player, media player, video game player module, internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, and the like. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0029] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals (e.g., associated with a particular subframe with respect to both UL (e.g., for transmission) and downlink (e.g., for reception) can be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference through hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In embodiments, WRTU102 may include a half-duplex radio in which the transmission and reception of some or all of the signals (e.g., associated with a particular subframe with respect to either UL (e.g., for transmission) or downlink (e.g., for reception) can be in parallel and / or simultaneously.

[0030] Figure 1C is a system diagram showing RAN104 and CN106 according to an embodiment. As described above, RAN104 can employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 can also be in communication with CN106.

[0031] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with the embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers to communicate with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a may use multiple antennas, for example, to transmit radio signals to and / or receive radio signals from WTRU102a.

[0032] Each of the eNode-B160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle decisions regarding radio resource management, handover decisions, user scheduling in UL and / or DL, etc. As shown in Figure 1C, the eNode-B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0033] The CN106 shown in Figure 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the above elements is shown as part of CN106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0034] The MME162 can be connected to each of the eNode-B162a, 162b, and 162c in RAN104 via the S1 interface and can act as a control node. For example, the MME162 can be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial connection of WTRU102a, 102b, and 102c. The MME162 can also provide control plane functionality for switching between RAN104 and other RANs (not shown) employing GSM and / or other radio technologies such as WCDMA.

[0035] The SGW164 can be connected to eNode B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can also perform other functions, such as fixing the user plane during handovers between eNode B, triggering paging when DL data is available for WTRU102a, 102b, and 102c, and managing and storing the context of WTRU102a, 102b, and 102c.

[0036] SGW164 can be connected to PGW166, which can provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0037] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to circuit-switched networks such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial communication line devices. For example, CN106 can include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0038] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, it is assumed that such a terminal can use a wired communication interface with a communication network (for example, temporarily or permanently).

[0039] In a typical embodiment, the other network 112 may be a WLAN.

[0040] In Infrastructure Basic Service Set (BSS) mode, a WLAN can have access points (APs) for the BSS and one or more stations (STAs) associated with the APs. APs can have access to or interfaces with a distribution system (DS) or another type of wired / wireless network that carries traffic to and from the BSS. Traffic originating outside the BSS and destined for the STAs can be received through the APs and delivered to the STAs. Traffic originating from the STAs and destined for destinations outside the BSS can be sent to the APs and delivered to their respective destinations. Traffic between STAs within the BSS can be sent through the APs, for example, if the source STA can send traffic to the APs and the APs can deliver that traffic to the destination STAs. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between the source STA and the destination STA (e.g., directly) using a Direct Link Setup (DLS). In certain representative embodiments, the DLS can use either 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all of the STAs) can communicate directly with one another. The IBSS mode of communication may sometimes be referred to herein as the “ad-hoc” mode of communication.

[0041] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a 20 MHz bandwidth) or a dynamically set width via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In certain typical embodiments, for example in an 802.11 system, collision avoidance carrier-sensing multiple access (CSMA / CA) can be implemented. With respect to CSMA / CA, an STA, including the AP (e.g., any STA), can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that particular STA can withdraw. A single STA (e.g., only one station) can transmit at any given time on a given BSS.

[0042] High-throughput (HT) STAs can use a 40MHz wide channel for communication, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0043] Ultra-high throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz channels and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. 160 MHz channels can be formed by combining eight adjacent 20 MHz channels, or by combining two non-adjacent 80 MHz channels, which can be called an 80+80 configuration. For the 80+80 configuration, data can be passed through a segment parser after channel encoding, which can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. These streams can be mapped onto two 80 MHz channels, and data can be transmitted by the transmitting STA. In the receiver of the receiving STA, the above operation regarding the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0044] Sub-1GHz operation modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah can support meter-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including support for certain and / or limited bandwidths (e.g., support only for those). MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0045] A WLAN system capable of supporting multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, includes a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the case of 802.11ah, for an STA (e.g., an MTC type device) that supports (e.g., only supports) the 1MHz mode, the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is busy because an STA (which only supports 1MHz operating mode) is transmitting to an AP, the entire available frequency band may be considered busy, even if a large portion of those frequency bands could remain idle and be available.

[0046] In the United States, the available frequency band for use with 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is from 6 MHz to 26 MHz, depending on the country code.

[0047] Figure 1D is a system diagram showing RAN113 and CN115 according to an embodiment. As described above, RAN113 can employ NR radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN113 can also be in communication with CN115.

[0048] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with the embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers to communicate with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNB180a, 180b, and 180c. Thus, gNB180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a, for example. In embodiments, gNB180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB180a can transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In embodiments, gNB180a, 180b, and 180c can implement coordinated multipoint (CoMP) technology. For example, WTRU102a can receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0049] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable neurology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may differ for separate transmissions, separate cells, and / or separate parts of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTI) of varying or scalable lengths (e.g., including varying numbers of OFDM symbols and / or varying lengths of absolute time duration).

[0050] The gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, the WTRU102a, 102b, and 102c can communicate with the gNB180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, the WTRU102a, 102b, and 102c can use one or more of the gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, the WTRU102a, 102b, and 102c can communicate with the gNB180a, 180b, and 180c using signals in unlicensed bandwidth. In non-standalone configurations, WTRU102a, 102b, and 102c can communicate with / connect to gNB180a, 180b, and 180c, while also communicating with / connecting to other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c and one or more eNode-B160a, 160b, and 160c. In non-standalone configurations, eNode-B160a, 160b, and 160c can serve as mobility anchors for WTRU102a, 102b, and 102c, while gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0051] Each of the gNB180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, and routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b. As shown in Figure 1D, the gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0052] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and possibly a Data Network (DN)185a, 185b. While each of the above elements is shown as part of the CN115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0053] AMF182a and 182b can connect to one or more of gNB180a, 180b, and 180c in RAN113 via the N2 interface and act as control nodes. For example, AMF182a and 182b can be responsible for authenticating users of WTRU102a, 102b, and 102c, providing support for network slicing (e.g., handling separate PDU sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating NAS signaling, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of services utilized by WTRU102a, 102b, and 102c. For example, separate network slices can be established for different use cases, such as services that rely on ultra-high reliability low latency (URLLC) access, services that rely on extended capacity mobile broadband (eMBB) access, and services related to machine-type communications (MTC) access. The AMF162 can provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other wireless technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0054] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b, and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions, such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0055] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N3 interface, which can provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0056] CN115 can facilitate communication with other networks. For example, CN115 can include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN115 and PSTN108. CN115 can also provide WTRU102a, 102b, and 102c with access to other networks 112, which can include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, and 102c can be connected to DN185a and 185b via UPF184a and 184b through an N3 interface to UPF184a and 184b, and an N6 interface between UPF184a and 184b and local data networks (DNs) 185a and 185b.

[0057] Considering Figures 1A to 1D and their corresponding descriptions, one or more or all of the functions described herein in relation to one or more of the WTRU102a to d, base stations 114a to b, eNode-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to ab, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein can be performed by one or more emulation devices (not shown). An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device can be used to test other devices and / or to simulate network functions and / or WTRU functions.

[0058] Emulation devices can be designed to perform one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices can perform one, more, or all functions while being implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in that network. One or more emulation devices can perform one, more, or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Emulation devices can be directly coupled to another device for testing purposes and / or testing can be performed using over-the-air radio communication.

[0059] One or more emulation devices are capable of performing one or more functions, including all functions, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be used in a testing scenario in a testing laboratory and / or an undeployed (e.g., testing) wired and / or wireless communication network to perform testing of one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include one or more antennas) can be used by the emulation device to transmit and / or receive data.

[0060] As described above, a WTRU can be registered with the same AMF within the same Public Land Mobile Network (PLMN) via both 3G PTA Access Technology (AT) and non-3GPP AT (e.g., Wi-Fi). After a WTRU is registered via these access technologies, it can be in one or more of the following modes: A WTRU can be in 5GMM Connected Mode (CM) via both 3GPP AT and non-3GPP AT. A WTRU can be in CM via 3GPP AT and 5GMM Idle Mode (IM). A WTRU can be in IM via 3GPP AT and CM via non-3GPP AT. A WTRU can be in IM via both 3GPP AT and non-3GPP AT.

[0061] Paging procedures can be used to trigger a WTRU to transition from IM to CM via a service request procedure. However, paging can only occur via a 3GPP radio access network (RAN). Therefore, it may not be possible for a WTRU that is in IM via a non-3GPP AT to be paged. However, a WTRU may be in CM via one AT but not another. For example, if a WTRU is in CM via a 3GPP AT and in IM via a non-3GPP AT, the network may need to inform the WTRU that there is downlink (DL) data associated with a PDU session previously established via a non-3GPP AT. To do so, the network can use an alert procedure to inform the WTRU. The network can send an alert message to the WTRU. The alert message may include an indication for the WTRU to re-establish resources for one or more protocol data unit (PDU) sessions via a second access technology. That indication can be either implicit or explicit.

[0062] In the example, the WTRU can receive an announcement message via a non-3GPP AT. However, since the WTRU may be in an IM via a non-3GPP AT, the WTRU can respond to the announcement message via a 3GPP AT and inform the network that the PDU session in question is associated with a non-3GPP AT, but that it wishes to receive data via a 3GPP AT.

[0063] A request for service message can be sent via CM through the 3GPP AT to inform the network to set up resources for PDU sessions that the WTRU has moved to the 3GPP AT. The WTRU can inform the network which PDU sessions are permitted to be moved by including an information element (IE) known as the permitted PDU session status. If the WTRU does not want any of its PDU sessions to be moved via the 3GPP AT, or has locally deactivated one or more PDU sessions that were on the 3GPP AT, the WTRU can respond with an informative response indicating that no user plane resources should be activated for those PDUs via the 3GPP AT.

[0064] AMF may not be able to supply multiple Network Slice Selection Assistance Information (NSSAI). For example, the first NSSAI may correspond to a separate network slice. If a WTRU is connected to a network slice with the value of the first NSSAI, the WTRU may not be able to connect to another network slice at the same time.

[0065] In the example, the notification message may also include a PDU session identifier (ID) corresponding to the PDU session containing DL data for the WTRU. The WTRU can accept the transfer of the PDU to another access based on the WTRU policy.

[0066] Furthermore, while a PDU session for which the network is sending notification messages may be expected to be forwarded to a 3GPP AT, a WTRU may want to forward other PDU sessions even if there is pending DL data at that moment.

[0067] Notification messages can be used only for data related to existing PDU sessions. However, this may limit the efficiency of the message. There may be other cases where notifications can be used, for example, to reduce paging on wireless networks in 3GPP systems, and to trigger service requests from WTRUs. Therefore, the conventional use of notifications can be very limited. It may be desirable to extend the use of notification messages to cover new cases or to apply them to services not related to existing PDU sessions.

[0068] In cases where a WTRU is in CM via a non-3GPP AT while being in IM via a 3GPP AT, the WTRU may have data or signaling to be executed via the 3GPP AT (for example, to perform periodic registration updates). At the same time, the WTRU's NAS entity may receive notification messages from AMF via a non-3GPP AT. The WTRU's behavior in this case is unclear. The WTRU may not have established procedures for prioritizing signaling and may not know what to set as the establishing factor at the RRC layer.

[0069] Furthermore, in cases where a WTRU is in a CM via a non-3GPP AT while being in an IM via a 3GPP AT, the network may have previously experienced some overload or congestion related to data traffic associated with the gateway (e.g., PGW or UPF) or the Access Point Name (APN) or Data Network Name (DNN). A WTRU can receive a backoff timer at the session management level.

[0070] Receiving a backoff timer can prevent a WTRU from sending signaling associated with that particular node / network. It is possible that a means exists for the network to inform the WTRU that congestion has been cleared on the network side, thus allowing the WTRU to begin sending signaling / data traffic to that network. For this to be achieved, the WTRU may need to be in the CM. However, since a WTRU can be in the IM via a 3GPP AT, and in the CM via a non-3GPP AT, it is possible that a method exists to inform the WTRU that congestion has been relieved using this arrangement.

[0071] In both WTRUs and networks, several protocol entities may exist at the NAS level. When a protocol entity in a WTRU / network needs to send a message to another "corresponding" protocol entity in the WTRU / network, the sender can use a specific (e.g., predefined) value in a special field in the NAS message header called a Protocol Identifier (PD). On the receiving end, the recipient can look at the PD value to understand which protocol entity is addressed. The PD field can indicate several protocol entities that have been added with the evolution of GPRS, UMTS, and EPS. There may be no values ​​left to assign to new 5G protocol entities. A new NAS header may be used for 5G protocols, and an extended version of the PD called an Extended Protocol Identifier (EPD) may be incorporated. It may be desirable to further define the EPD.

[0072] A 5G system may have defined procedures for updating a WTRU with new parameters related to several needs, such as changing the WTRU identity (5G GUTI) and / or tracking area identity (TAI) list, providing a new service area list, and providing an authorized NSSAI. However, there can be some ambiguity associated with the use of WTRU configuration update messages. The AMF can update the WTRU configuration by providing new parameter information with commands, or by requesting the WTRU to perform a new registration update with the network to update the parameters. The procedure can be initiated by the network and can be used if the WTRU has an established 5GMM context and is in 5GMM-CM. The AMF may require an acknowledgment to ensure that the parameters have been updated by the WTRU.

[0073] Parameters such as 5G-GUTI, TAI list, service area list, authorized NSSAI, network identity and time zone information (e.g., full network name, network abbreviation, local time zone, universal time and local time zone, network daylight saving time), and Local Area Data Network (LADN) information can be supported by a general WTRU configuration update procedure without requiring the triggering of a WTRU registration update procedure. This procedure can update one or more configuration parameters (e.g., policy information). Configurations provided by NFs other than AMFs can be covered by this procedure, or can be provided by different NAS procedures, such as WTRU route selection policies (RSPs) provided by PCFs.

[0074] The Mobile Initiated Connection Only (MICO) parameter may require the WTRU registration update procedure to be triggered. The MICO mode of operation can be used for power saving in the WTRU. When a WTRU adopts MICO, it can deactivate its radio access capability and enter sleep mode. Sleep mode can be extended, allowing the WTRU to "disappear" from the network. If a WTRU is configured to operate in MICO, a mechanism may be desirable for the WTRU and the CN (e.g., AMF) to inform each other about the use of this mode of operation. The WTRU can inform the CN (e.g., AMF) about this capability during the registration procedure. For example, the WTRU can send a parameter or IE in the registration request message informing the CN that it wants to apply MICO mode.

[0075] This procedure can be performed in one or more of the following examples. A new IE can be introduced to reflect the ability to use a function, such as but not limited to MICO, which the network may require to accept its use. This new IE can be a requested function use IE. This IE can be a single octet, and each bit position can reflect a request by the WTRU to use a particular function. For example, bit position 0 can be the least significant bit, and bit position 8 can be the most significant bit. Bit position 0 can correspond to the MICO function. Therefore, if a WTRU wants to use the MICO function, it can set the bits of this IE to "xxxxxxxxx1". Thus, a value of 1 can represent a request to use the function, and a value of 0 can represent an indication that the WTRU does not need to use the function.

[0076] When extending this IE to apply to further functionality, the most significant bit of this octet can be reserved to indicate whether the IE is being extended. For example, if bit position 8 has a value of 1, then there can be a further octet following this IE to extend it. The interpretation of the subsequent octet can be defined according to what is required for the further functionality. For example, if the WTRU wants to reflect the use of seven functionality, it can set bit position 8 to a value of 0. If the WTRU has more than seven functionality to reflect, it can set bit position 8 to a value of 1 and use a further octet. Bit position 8 of the further octet can be reserved for the same purpose of indicating further functionality. If the AMF accepts or permits the use of functionality, it can return a value of 1 with respect to the bit position associated with the functionality. Otherwise, it can set the bit position to 0. Note that the specific bit positions used above are provided as examples. Other bit positions can be defined or reserved to reflect any of the above.

[0077] Another way a WTRU can indicate the use of MICO is by using bit positions in the registration type IE. For example, the registration type IE in a registration request message can be one octet long. It can be a type-value (TV) IE. This type can reflect that it is an IE about registration types, and the value indicates a specific type of registration, such as initial registration or registration update. The value field can be four bits long, with three bits used to reflect the registration type. The fourth bit can be reserved for the use of MICO. For example, bit 1001 can be interpreted as follows: The first least significant bit (001) can be defined to reflect a registration type of "initial registration". The WTRU can set the MICO bit (e.g., the fourth and most significant bit of the half-octet) to a value of 1 to indicate the need to use MICO.

[0078] The AMF can use a similar procedure to reflect the registration result. The registration result can also be defined using four bits. The least significant bit can reflect the type of registration accepted by the AMF, and the fourth bit can indicate to the WTRU whether or not MICO is permitted for use. When the WTRU receives the registration result, it can verify the fourth bit position to determine whether MICO is permitted. If the fourth bit position has a value of 1, the WTRU can consider MICO permitted and begin using the operation. If the fourth bit position has a value of 0, the WTRU can consider MICO not permitted for use.

[0079] The MICO mode of an operation can be terminated by the WTRU by transitioning from IM to CM along with a registration procedure or a service request procedure. If the network is congested, the CN can reject the request and provide the WTRU with a backoff timer. The WTRU can directly apply MICO (i.e., deactivate its radio capabilities), activate the backoff timer, and then initiate a new procedure when the backoff timer expires.

[0080] WTRU configuration update messages can be sent to a WTRU if the WTRU is in CM. There may be no dependency on the AT that intervenes when the message can be sent. Upon receiving a WTRU configuration update message, the expected action by the WTRU may be re-registration. The WTRU may need to re-register with the network. However, some parameters and functions, such as MICO, are applicable only to 3GPP ATs. Parameters applicable to 3GPP ATs cannot be negotiated through non-3GPP ATs. Upon receiving a WTRU configuration update message with an indication that registration is required, the WTRU may perform the registration update after transitioning to idle mode. However, the AT that should be used to perform the registration update may not be specified.

[0081] Other parameters, such as the 5G GUTI and its associated TAI list, can be applied equally to both ATs. Receiving a new NSSAI in a state requiring registration may affect both ATs because an authorized NSSAI can be associated with a TAI list, and separate ATs can have separate TAI lists. The WTRU cannot know which AT will perform the registration update. The WTRU cannot have complete information about the actions that should be taken. If the WTRU receives a new TAI list, it cannot know which AT can be associated with that TAI list. It may be desirable to avoid ambiguity in the WTRU.

[0082] New network and WTRU behaviors for using NAS notification messages can be described herein. This can include various interpretations by the WTRU, as well as responses from the WTRU in various cases and scenarios. Furthermore, the following descriptions can include, and are not limited to, extensions of notification messages to optimize system signaling. New WTRU behaviors for handling conflict situations between simultaneous NAS procedures via 3GPP AT and non-3GPP AT can be described below. A method can be described in which the AMF can use notification messages to inform the WTRU that at least session management congestion has ended. The WTRU can use this information to stop the session management backoff timer. The following descriptions can include new definitions for EPDs to support other types of mobility management message types. New procedures for the interpretation of new EPDs by the WTRU and network can also be defined.

[0083] The following explanation may include methods and procedures to minimize ambiguity associated with the use of WTRU configuration update messages. The AMF may indicate the AT type for parameters included in the WTRU configuration update message. The WTRU can update the parameters of the indicated AT with new values. For new NSSAI received via a non-3GPP AT, the WTRU may begin registration via a 3GPP AT if AT information is not provided in the WTRU configuration update message.

[0084] NAS notification procedures can be optimized through WTRU and network behavior. Note that the following explanation assumes the WTRU is in the CM via 3GPP AT and the IM via a non-3GPP AT. However, the provided examples can be applied to any of the other connectivity scenarios mentioned above.

[0085] A WTRU can receive notification messages from the network via a 3GPP AT. An AMF can send notification messages to a WTRU via a non-3GPP AT. Notification messages may include an indication for the WTRU to re-establish resources for one or more protocol data unit (PDU) sessions. This indication may be implicit or explicit.

[0086] In this example, the resource can be re-established via a second access technique. This may be because there is DL data associated with one or more PDU sessions in the 3GPP AT. A WTRU may have, for example, two PDUs, PDU X and PDU Y, associated with a non-3GPP AT. An alert message may be related to the PDU session via the 3GPP AT, but the WTRU may also want to forward all data regarding PDU Y to the 3GPP AT. Regarding PDU Y, no data is yet available, but the WTRU may want to indicate this to the network in advance, so that the network associates the other PDUs with the 3GPP AT for subsequent DL data.

[0087] Therefore, the WTRU can still decide whether it wants other PDU IDs to be moved to the 3GPP AT. As mentioned above, this decision can be based on local policy, or the WTRU can display a message to users who are able to change settings and set preferences. The WTRU can then send a service request and include a list of PDU IDs in the permitted PDU session status IE.

[0088] In the example, the notification message may also include one or more PDU session IDs associated with non-3GPP ATs that the network is capable of forwarding data to a 3GPP AT. The WTRU can verify the received PDU session IDs (PDU IDs) against its local policy. The WTRU may have a policy indicating which PDU IDs are permitted to be forwarded via target access technologies. The WTRU can verify whether the received PDU IDs are permitted to be forwarded via different target access technologies. The WTRU can further examine the details in its policy to make such a decision. Policy details may include, for example, time, location, and whether the PDU session is associated with an LADN. If any of the PDU IDs in the notification message are eligible for forwarding to another access, and the WTRU is capable of deciding to do so, the WTRU can send a request for service message to the network. The request for service message may include a list of PDU IDs that the WTRU wishes to forward to a 3GPP AT. The list of PDU IDs may include permitted PDU session statuses. In other words, the WTRU can use the received PDU ID to validate it against its local policy and determine which PDU IDs are eligible to be forwarded to the 3GPP AT.

[0089] A WTRU may have uplink data to send associated with at least one PDU ID associated with a non-3GPP AT. However, a WTRU may not be in coverage of a non-3GPP AT, or a WTRU may have a policy to move PDU sessions to a 3GPP AT. In this case, the WTRU will not be paged, but it may be able to send a service request and include an authorized PDU session status IE to indicate to the network that it wants to transfer the indicated PDU session from a non-3GPP AT to a 3GPP AT.

[0090] A WTRU may include a NAS-level establishing factor in its service request message to inform the AMF why the service request is being sent. The details of this NAS-level establishing factor can be defined in more detail below. A WTRU may include a NAS-level establishing factor, or other types of information explaining why it is sending the service request message, and / or the type of service the WTRU wishes to request. For example, a WTRU may include a service type set to "Transfer PDU from non-3GPP to 3GPP" to indicate that the WTRU wishes to transfer at least one PDU session (identified, for example, by the permitted PDU session status IE) from a non-3GPP AT to a 3GPP AT.

[0091] The AMF can receive a service request message (or other NAS message) with an authorized PDU session status IE that identifies at least one PDU ID that the WTRU wishes to transfer from a non-3GPP AT to a 3GPP AT. The WTRU may also include NAS level establishing factors or other information, such as a service type indicating "transfer PDU from non-3GPP to 3GPP" as described above. The AMF can verify the PDU ID and determine that at least one PDU ID does not have pending DL data. The AMF's actions may differ depending on whether the WTRU initiated the service request itself, or whether it is responding to paging or an alert message.

[0092] The AMF can determine whether the WTRU is initiating a service request on its own (i.e., the message is not a response to paging or an alert message) by verifying that the establishing factor is received from a lower layer (i.e., RAN). Alternatively, the AMF can determine this by verifying the NAS-level establishing factor or service type as described above. If the AMF can determine that the WTRU is initiating a service request on its own, the AMF can proceed with the procedure and inform the SMF to change the associated AT from non-3GPP to 3GPP. The SMF can receive a request using a defined reference point, for example (e.g., Nsmf_PDUSession_UpdateSMContext Request), which wants to set up resources for a PDU session identified by the PDU ID. The request may include an AT type. If the AT type is not the same as the AT type in the WTRU's session management (SM) context, the SMF can update the AT type to reflect the AT type received from the AMF. The SMF can take other actions and inform other network nodes about the updated AT associated with the identified PDU session. For example, SMF can inform PCRF about this change using the appropriate reference point.

[0093] If the AMF can determine that the WTRU has initiated the request itself, and the AMF has received at least one PDU session that the WTRU wishes to forward from a non-3GPP AT to a 3GPP AT, the AMF can proceed with the service request procedure, thereby setting up user plane resources and connectivity for the WTRU. If accepted by the AMF, the AMF can respond to the WTRU with a service acceptance message and indicate the PDU session ID that the AMF has accepted to set up the user plane resources.

[0094] If the AMF pages a WTRU through a 3GPP AT with respect to data related to a non-3GPP AT PDU session, and the WTRU contains at least one PDU ID associated with a non-3GPP AT that it wishes to move to a 3GPP AT, the AMF may take any of the following actions described herein:

[0095] AMF can verify whether the provided PDU ID is associated with pending DL data. If the PDU ID is associated with pending DL data, AMF can set up the resources as described above. If the PDU ID is associated with pending DL data (i.e., there is a PDU ID in a service request message that does not contain DL data), AMF can take one of the following actions:

[0096] The AMF can reject a request for service message. The AMF can send a denial-of-service message to the WTRU, and the denial-of-service message can include a factor code to indicate to the WTRU that there is no pending DL data at that moment. The AMF can also indicate whether a PDU connection is now considered to be associated with a 3GPP AT, or whether it is still associated with a non-3GPP AT. The AMF can have a preference or policy to determine this. Alternatively, as mentioned above, the WTRU can include its preference in the request for service message, and in the request for service message, for each PDU ID, the WTRU can inform the network whether it wants to associate the PDU with a different AT. The WTRU can determine this using its local policy. If the AMF determines that the PDU session referred to by the PDU ID can be associated with a 3GPP AT, the AMF can include the PDU ID and the associated AT. The WTRU can then update its local information to indicate that its PDU ID is associated with another AT, and its type can be indicated in a NAS message (e.g., a denial-of-service message).

[0097] The AMF can accept a service request message and include a factor code to indicate that the resource was intentionally not set up (for example, due to the unavailability of pending DL data as described above). The AMF can also include further information in the NAS message to inform the WTRU that the PDU session identified by the PDU ID is considered to be being transferred to another AT or is now associated with another AT. The WTRU can receive a denial-of-service message with a new factor code indicating that the list of PDU IDs does not have the resources set up for them. The message can indicate that the PDU session mentioned by the PDU ID is not associated with another AT. The WTRU can update its local SM context to reflect the new AT now associated with each of the PDU sessions identified by the PDU ID.

[0098] A WTRU can receive an Accept Service message in response to sending a request for service message indicating a list of PDU IDs that it wants to forward or associate with another AT. The WTRU can expect that the resources will be set up as a result of receiving the Accept Service message. However, if the resources are not set up (for example, if the RRC layer in the WTRU does not receive a configuration message to set up the radio resources), the WTRU can assume that there is a failure either locally or in the network.

[0099] To avoid the WTRU considering the procedure unsuccessful, the WTRU may use the information provided in the service acceptance message to determine whether the service request procedure was successful. The WTRU may use any of the above-mentioned IEs that can be included in the NAS message by the AMF. For example, the WTRU may use a factor code with a value indicating that the network has intentionally not set up user plane resources as a means of determining that the service request procedure was successful even though user plane resources or wireless resources for the user plane were not set up.

[0100] Alternatively, as a means of determining that the wireless resources were not set up but the service request procedure was successfully completed, the WTRU may use a factor code or provide further information that the list of PDU sessions mentioned by the PDU ID is now associated with a different AT. The WTRU may update its local context to reflect that the PDU session identified by the PDU ID is now associated with a different AT.

[0101] As stated above, the above proposals can occur across any AT and any connection mode. Note that a WTRU may send a request for service message instead of an alert response message, and may include any of the information described herein. The procedure for a WTRU to send an alert response message can be applied in a similar manner if the WTRU sends a request for service message instead.

[0102] Referring to Figure 2, a flowchart illustrating the procedure for transferring PDUs via separate ATs is shown. Figure 2 illustrates how some of the above proposals may be used. Procedures for transferring PDUs may include WTRU202, 3GPP RAN204, non-3GPP AN206, AMF208, and SMF210.

[0103] As shown in Step 0, WTRU202 may be a CM in a 3GPP AT and an IM in a non-3GPP AT. WTRU202 may have PDU A associated with a 3GPP AT, and may have PDU B and PDU C associated with a non-3GPP AT.

[0104] In step 1, WTRU202 may receive an alert message from AMF208. The alert message may include an indication for WTRU to re-establish resources for one or more protocol data unit (PDU) sessions. The indication may be either implicit or explicit. In the example, those resources may be re-established via a second access technique. In step 2, WTRU202 may use local policy or preference to determine whether one or more PDUs should be moved to the 3GPP AT.

[0105] In step 3, WTRU202 can send a service request message to AMF208. The service request message may include the authorized PDU session status (e.g., PDU B and / or PDU C). The service request message may also include further information indicating the permanent transfer of PDU C to 3GPP AT.

[0106] In step 4, the AMF208 can determine which PDUs are eligible to be forwarded to the 3GPP AT.

[0107] In step 5, the AMF208 can send the updated context to the SMF210. The updated context may include access information for one or more of PDU B and PDU C.

[0108] In step 6, AMF208 can send a service acceptance message to WTRU202. The service acceptance message may include further information indicating the permanent transfer of PDU C to 3GPP AT.

[0109] In step 7, WTRU202 can update the SM context using the information received in the service acceptance message to reflect that the PDU C has been forwarded to the 3GPP AT.

[0110] WTRU202 can decide not to forward any PDU session, regardless of whether there is pending DL data. WTRU202 can have a preference to temporarily deny the forwarding of PDU sessions. In this case, based on the WTRU policy, WTRU202 sends a notice response message to the network indicating that WTRU202 is temporarily denying the forwarding of PDU sessions. WTRU202 can include a new factor code for each PDU session mentioned by the PDU ID, indicating that WTRU202 does not want to forward it to another AT. Alternatively, WTRU202 can have a policy of not forwarding PDUs to another AT. In this case, WTRU202 can include a factor code indicating this. WTRU202 can also send a request for service message instead of a notice response message. WTRU202 can also indicate a time window in which future requests for PDU forwarding between ATs are permitted or not permitted.

[0111] The AMF208 may receive a NAS message (e.g., an alert response message or a service request message) containing information indicating that certain PDU sessions, referred to by their PDU IDs, cannot be transferred to another AT. The cause code or information in the NAS message may indicate a temporary or permanent denial. The AMF208 may send an alert message to the SMF210 to indicate whether this is a permanent or temporary denial. The AMF208 may include the time frame during which the SMF210 can or cannot request such a transfer. The SMF210 may update its local information accordingly.

[0112] Referring to Figure 3, a flowchart illustrating the procedure for managing PDUs via separate ATs is shown. Procedures for PDU transfer may include WTRU302, 3GPP RAN304, non-3GPP AN306, AMF308, and SMF310.

[0113] As shown in step 0, WTRU302 can be in a limited state in a 3GPP AT and in a CM in a non-3GPP AT. WTRU302 can have PDU A associated with a 3GPP AT, and can have PDU B and PDU C associated with a non-3GPP AT.

[0114] In step 1, WTRU302 can receive an alert message from AMF308. The alert message may include an indication for WTRU to re-establish resources for one or more protocol data unit (PDU) sessions. In the example, those resources may be re-established via a second access technique. In the example, AMF308 may start a timer. In step 2, WTRU302 may use local policy or preference to determine whether other PDUs should be moved to the 3GPP AT.

[0115] In step 3, WTRU302 can send a notification response message to AMF308. The notification response message may include the PDU session status IE. The notification response message may be a NAS message. Upon receiving the notification response message, AMF308 can stop the timer.

[0116] In step 4, the AMF308 can determine which PDUs can be removed.

[0117] In step 5, the AMF308 can send the updated context to the SMF310.

[0118] If WTRU302 is in a CM for 3GPP ATs and an IM for non-3GPP ATs, or in a CM for non-3GPP ATs and an IM for 3GPP ATs, WTRU302 may have several PDU sessions. WTRU302 may keep several PDU sessions locally deactivated without signaling to the network. If WTRU302 receives an announcement message with a list of PDUs the network has pending DL data, or if the network wants to forward data to another AT, WTRU302 can verify whether the PDU sessions mentioned by the PDU IDs are still active. If they are not active, WTRU302 may send an announcement response message including a PDU session status IE to indicate that several PDU sessions have been deactivated by WTRU302. Alternatively, WTRU302 may send a request for service message instead of an announcement response message to indicate that the PDU sessions have been locally deactivated. The AMF308 can then begin deactivating the corresponding PDU session for the SMF310.

[0119] Therefore, WTRU302 can send an alert response message indicating that the PDU session has been deactivated. Alternatively, if WTRU302 receives a paging request via a 3GPP AT with an access type indicating non-3GPP access, and WTRU302 has deactivated the PDU session associated with the non-3GPP AT, WTRU3023 can send a request for service message indicating that there are no active PDU sessions in WTRU302 associated with the non-3GPP AT. A new IE may be used to indicate this, or the PDU session status IE may be used.

[0120] Notification messages can be extended to be used beyond the transfer of PDU sessions, which may be further detailed herein. The use of notification messages can be extended to make the entire system more efficient. For example, if a WTRU is in a CM via a non-3GPP AT and an IM via a 3GPP AT, the AMF can have a policy to deliver Short Message Service (SMS) via the 3GPP AT. To avoid paging and the resulting signaling in the system, the AMF can send notification messages to the WTRU via a non-3GPP AT to indicate the need to establish a NAS connection via 3GPP, even if the reason is not for user plane data. The AMF can include indications in its notification messages to let the WTRU know whether the message is being sent regarding a particular service that is not necessarily related to user plane data. User plane data can refer to any type of data that does not travel through the control plane and can be IP or non-IP.

[0121] In another scenario, a WTRU may be in an unauthorized tracking area (i.e., camped on a cell with a tracking area identity that has been determined to be an unauthorized tracking area identity), and the WTRU may be in the state "5GMM-REGISTERED.NON-ALLOWED-SERVICE". In this state, the WTRU may not perform mobility and periodic registration renewal procedures using the uplink data status IE, except for emergency services. Furthermore, the WTRU may not be permitted to initiate service request procedures.

[0122] However, if a WTRU is in a CM via a non-3GPP AT and has received an alert message, the WTRU may send an alert response to indicate to the network that it is not possible to reactivate its user plane resources via the 3GPP AT. The WTRU may also indicate why this is not possible (i.e., the WTRU may inform the network why it is not possible to send a request for service message). The WTRU may send an IE, which may be defined and included in a NAS message (e.g., an alert response), indicating that the WTRU is in an unauthorized area. Other factor codes or IEs may be defined to reflect existing reasons (e.g., the WTRU is in a limited state, or the WTRU is looking for a PLMN) or new reasons why the WTRU may not be able to reactivate its user plane resources via the 3GPP AT.

[0123] Therefore, if a WTRU is in a CM via a non-3GPP AT and an IM via a 3GPP AT, and the WTRU's 3GPP status is "5GMM-REGISTERED.NON-ALLOWED-SERVICE", the WTRU may send a notification response message (or any NAS denial message that can be defined) if it receives a notification with a list of PDU IDs associated with 3GPP access, or a notification with any other indication (e.g., regarding network-triggered signaling or SMS) that the WTRU should set up its NAS connection via a 3GPP AT.

[0124] The methods and procedures described below can be used to handle race conditions related to NAS procedures via 3GPP AT and non-3GPP AT. A WTRU can be a CM via a non-3GPP AT and an IM via a 3GPP AT. A WTRU can activate a periodic registration timer to protect periodic registration updates via a 3GPP AT. Periodic registration may not be supported via a non-3GPP AT. In one scenario, a WTRU can receive a notification message about pending DL data corresponding to a PDU session identified by a PDU ID associated with a 3GPP AT. The WTRU may receive this notification message a few seconds or milliseconds before performing a registration update (i.e., it may be very close to its periodic registration timer expiring). By the time the notification message is received, the WTRU may have to perform the periodic registration as described above. In this case, the WTRU may face a race condition. For example, the notification message may trigger a service request, and at the same time, the WTRU's periodic registration timer may have expired.

[0125] A WTRU can prioritize registration renewal procedures over service requests. Upon receiving a notification message (via a non-3GPP AT) accompanied by a list of PDU IDs associated with a 3GPP AT, the WTRU can verify whether the PDU session is still active in the WTRU. If the PDU session is active, the WTRU can send a registration renewal message via the 3GPP AT and include the uplink data status IE. The WTRU can set the value of the uplink data status IE to include at least the PDU IDs that were present in the notification message. The WTRU can also include other PDU IDs in the uplink data status IE if it has uplink data to send.

[0126] Another scenario regarding race conditions may arise when a WTRU is in an IM via a 3GPP AT and an IM via a non-3GPP AT. A WTRU may receive a paging message with an AT type set to non-3GPP, which may indicate that the paging message is triggered by pending DL data for a PDU session associated with a non-3GPP AT. As mentioned above, when a WTRU receives that paging message, its periodic registration timer may be running out or has just run out. In this case, the WTRU may also prioritize performing a registration update over a service request. Furthermore, the WTRU may include an allowed PDU session status IE in the registration message.

[0127] These procedures can also be performed if the WTRU is in the "ATTEMPTING-REGISTRATION-UPDATE" state and has received a paging message. In this case, if the WTRU receives a paging message with an AT type set to non-3GPP, the WTRU can send a registration request message and include the permitted PDU session status IE in the periodic registration message.

[0128] These procedures also require registration requests to be sent by the WTRU under any other triggers or conditions, and are not limited to the case of periodic registration. For example, a WTRU may perform registration updates for other parameters related to other functions, such as but not limited to the use of MICO operations and network slicing. Another example of a trigger could be the WTRU entering a new tracking area list, creating a need to perform a registration update, and receiving an alert message via a non-3GPP AT.

[0129] When the AMF sends a paging message, it can start a timer to protect the time it expects for a response (i.e., a service request) from the WTRU. In the example above, receiving a registration request message from the WTRU can cause the AMF to stop the timer. Alternatively, receiving a service request message with an authorized PDU session IE can cause the AMF to stop the timer. If an authorized PDU session IE is not present in the registration update message, the AMF can check whether a PDU status IE is included. If the PDU status IE contains a PDU ID corresponding to a non-3GPP AT that triggered paging (for example, due to pending DL data associated with a PDU ID), the AMF can use this as a trigger to stop the timer. The AMF can then consider the paging procedure successful.

[0130] Similarly, if the AMF sends a notification message and starts a timer to protect the response from the WTRU, the AMF can stop the timer using the received registration request message, as described above. The AMF can then consider the notification procedure successful.

[0131] As described above, in cases where a WTRU sends a registration request message, the AMF can perform one or more of the following actions: The AMF can take any action regarding the receipt of a service request message or an alert response message (if applicable) as described above. For example, the AMF can verify whether the included authorized PDU status IE contains PDU IDs that the WTRU wants to forward to a 3GPP AT, even though they do not have pending DL data. The AMF can determine whether the forwarding is permitted based on the WTRU's subscription and / or local policies. If the forwarding is accepted, the AMF can inform the SMF (associated with each PDU ID) that the AT has changed to a 3GPP AT. The SMF can update the context for the WTRU to reflect that the AT associated with the PDU is now 3GPP.

[0132] The AMF may also include one or more of the above-mentioned IEs in the registration acceptance message. For example, the registration acceptance message may include information to inform the WTRU whether other PDU sessions mentioned by the PDU ID are considered to be permanently associated with the 3GPP AT, even if no resources have been set up for these PDUs. The WTRU can use the information included in the registration acceptance message in the same manner as proposed for receiving information in service acceptance or denial of service messages as described above. For example, the WTRU may receive a registration acceptance message with information that at least one PDU is now associated with the 3GPP AT. The WTRU can use this information to update its session management context so that the indicated PDU session is now associated with the 3GPP AT.

[0133] It should be noted that these procedures can be applied in any combination via any AT. Specific ATs are used only as examples, and the procedures are not intended to be limited to the specific ATs mentioned. ATs may be switched with respect to the procedures described above.

[0134] Referring to Figures 4A to 4C, flowcharts illustrating signaling for handling race conditions are shown. Figure 4A shows a first example of the signaling used in the procedure described above. Figure 4B shows a second example of the signaling used in the procedure described above. Figure 4C shows a third example of the signaling used in the procedure described above. This signaling procedure may include WTRU402, 3GPP RAN404, non-3GPP AN406, and AMF408.

[0135] As shown in Figure 4A, in step 1a, AMF408 can send a notification to WTRU402. In the example, the notification may include a list of PDU IDs for 3GPP ATs via non-3GPP ATs. Additionally, or alternatively, in step 1b, AMF can send paging using non-3GPP access types via 3GPP ATs. In step 2, WTRU402 can check whether one or more PDUs are active. In step 3a, WTRU402 can send a notification response to AMF408 along with the PDU status IE. Additionally, or alternatively, in step 3b, WTRU402 can send a service request to AMF408 along with the PDU status IE.

[0136] As shown in Figure 4B, in step 1, AMF408 can send a notification to WTRU402. In the example, the notification may include a list of PDU IDs related to 3GPP ATs via non-3GPP ATs. In step 2, WTRU402 can trigger a TAU. In step 3, WTRU402 can send a registration request to AMF408. This registration request may include authorized PDU IEs. WTRU402 may include PDU IDs based on local policies. In step 4, AMF408 can stop the notification timer. In step 5, AMF408 can verify whether the PDUs in the registration request can be forwarded to 3GPP ATs. In step 6, AMF408 can send an acceptance message to WTRU402. This acceptance message may include information about which PDUs are being forwarded to 3GPP ATs, even if no user plane resources have been set up at all.

[0137] In Figure 4C, in step 1, AMF408 can send a UCU message to WTRU402 via a non-3GPP AT. The UCU message may contain one or more authorized NSSAI and AT types. In step 2, WTRU402 can proceed to IM on the non-3GPP AT. In step 3, WTRU can send a registration request message to AMF via a 3GPP AT. In step 4, WTRU402 can perform registration on the non-3GPP AT.

[0138] The following procedure can address congestion in the WTRU. Upon receiving an indication from the SMF that congestion associated with a particular DNN has been cleared, the AMF can send an announcement message to the WTRU via a non-3GPP AT. This announcement message may carry an indicator (e.g., IE) pointing to the previously congested network. This announcement message may include an explicit indicator that the congestion has been resolved, or it may include the PDU ID and further information such as, but not limited to, the DNN and / or S-NSSAI.

[0139] A WTRU may receive a notification message containing at least a list of PDU IDs and optionally a DNN and / or S-NSSAI. This notification message may also include an explicit indication of congestion termination for each PDU ID. Upon receiving this message, the WTRU can verify whether it has any backoff timers running for each PDU ID, DNN, S-NSSAI, or any combination thereof. If the WTRU has corresponding session management backoff timers running for at least one of the PDU IDs in the notification message, the WTRU can stop the corresponding backoff timers and consider session management to have ended for at least the SMF, DNN, S-NSSAI, or any combination thereof. The WTRU can then begin session management signaling to the SMF (identified by the PDU ID, DNN, S-NSSAI, or any combination thereof).

[0140] Notification messages can also be used by the AMF to inform the WTRU of the initiation of congestion control for either mobility management or session management. If the AMF or SMF determines that it is congested, the AMF can send a notification message indicating that congestion control should be applied by the WTRU for mobility management and / or session management signaling. The AMF may include corresponding mobility management backoff timers and / or session management timers. The latter may be related to SMF congestion, DNN congestion, S-NSSAI congestion, or a combination thereof. Upon receiving a notification message, the WTRU may activate the corresponding backoff timers (i.e., mobility management and / or session management) and, accordingly, refrain from sending messages to the AMF and / or SMF.

[0141] The procedure described above for indicating to the WTRU that congestion has ended at the session management level can also be used at the mobility management level. For example, a notification message can be sent to the WTRU via a non-3GPP AT with an explicit indication that congestion control at the mobility management layer has ended. The WTRU can then use this as an indication to stop the mobility management backoff timer.

[0142] If congestion is severe, the CN can inform the RAN to withdraw any devices requesting RRC connections. A RAN node (e.g., a gNB) can reject RRC connection request messages from WTRUs and provide them with a so-called extended latency (EXT). The EXT can function as a backoff timer. When a WTRU receives an EXT from a RAN node, it can only directly apply MICO mode as described above, and attempt to transition from IM mode to CM mode once the timer expires.

[0143] As mentioned above, a new field can be used for EPD. Table 1 shows the legacy values ​​for PD, which can now be used.

[0144] [Table 1]

[0145] The code point "1110" can be reserved for the extension of the PD field to one octet. This means that when a receiver reads "1110", it understands that the actual value of the PD (or EPD in this case) can be realized across the entire octet.

[0146] A conventional 5G system can have two NAS protocol entities: 5GMM and 5GSM. Only two code points may need to be assigned to these two protocol entities. However, there are a total of 16 available values / code points that may need to be defined.

[0147] The value "zero" can be omitted and instead indicate an error or abnormal situation. The reasoning behind this proposal is that certain L3 NAS messages historically had a "skip indicator" that was all zero and resided in the left half of the first octet. Examples of such protocols would be MM, GMM, and EMM.

[0148] Two distinct values ​​can be assigned to existing 5G NAS protocols (i.e., 5GMM and 5GSM). For example, the value "0001 1110" can be used for 5GMM, and the value "0010 1110" can be used for 5GSM. The actual EPD value for 5GMM can be "30", and the actual value for 5GSM can be "46". Note that other values ​​can also be used to refer to the 5GMM or 5GSM protocol. For example, if bits 8 through 5 have the value "1110", the WTRU and / or AMF can assume that the EPD is further extended by at least one more octet. The WTRU and / or AMF can then process the additional octet to determine the protocol. The additional octet can introduce 256 new values. These values ​​can start with "0" (i.e., all bits are zero), or they can start with the value of the previous octet having the bit position "11101110" (the decimal value 238) plus 256. A new octet can have new spare values ​​that can be defined as needed.

[0149] Referring to Figure 5, a diagram illustrating the EPD is shown. A code point can be reserved for future use. For example, a code point can be used to indicate the use of a different mechanism, or even a different protocol. This can be done either by using the value in the entire EPD octet, or by using only one or more bits. In the latter case, the most significant bit of the octet (i.e., bit number 8, shown as "X" in Figure 5) can serve this purpose. If this bit is zero, the EPD can indicate a 5G NAS protocol entity. However, if the bit value changes to "1", a different protocol can be used, and the interpretation of the subsequent octets can be different.

[0150] To ensure correct WTRU behavior, additional information may be provided in WTRU configuration update messages. As mentioned above, WTRU configuration update messages may lack certain information, which may result in WTRU behavior not being as expected or not being fully realized upon receipt. To eliminate ambiguity on the WTRU side so that the correct procedure is operated through the correct AT, the WTRU may handle WTRU configuration update messages as described below.

[0151] In the example, the network can send WTRU configuration update messages via separate ATs to update parameters specific to that AT. If a WTRU is registered via a 3GPP AT and the network wants to provide the WTRU with updated parameters related to features only available on 3GPP ATs (e.g., MICO, LADN, new service areas, NSSAI), the AMF can send the WTRU configuration update via the 3GPP AT. The WTRU can then respond via the same AT. If the WTRU is in a CM via a 3GPP AT, the AMF can send a WTRU configuration update message to the WTRU. However, if the WTRU is in an IM via a 3GPP AT, the AMF can first page the WTRU and then execute the WTRU configuration update procedure directed to the WTRU.

[0152] Alternatively, if a WTRU is also registered via a non-3GPP AT, and the WTRU is in a CM via a non-3GPP AT while being in an IM via a 3GPP AT, the AMF can first send an notification message via a non-3GPP AT and then instruct the WTRU to establish its NAS connection via a 3GPP AT for signaling purposes. The notification message may include a new IE to indicate to the WTRU that it must establish its NAS connection via a 3GPP AT. Alternatively, an indication from the AMF in a WTRU configuration update message may explicitly inform the WTRU (e.g., via a new IE) that a NAS connection must be established using a service request or registration request message.

[0153] If a WTRU is in a CM via a non-3GPP AT and receives a WTRU configuration update message via the non-3GPP AT with new parameters (e.g., GUTI, TAI, and / or NSSAI), the WTRU can consider those parameters to only affect the non-3GPP AT. Therefore, the WTRU can update its non-3GPP parameters with the parameters received via the non-3GPP AT. For example, if a WTRU receives a new TAI, it can consider the previous TAI received via the non-3GPP AT invalid and use the newly received TAI as the latest valid TAI. The WTRU can also update its 5G GUTI with a new value. However, if the WTRU is also registered with the same AMF within the same PLMN, the WTRU can also consider the new 5G GUTI to be valid for both ATs.

[0154] Another way to ensure that the WTRU knows which parameters to use for each AT is to send a WTRU configuration update message on either AT and include further information to tell the WTRU which AT the received parameters apply to.

[0155] If a WTRU receives a WTRU configuration update message through a specific AT, and that message contains parameters related to the same or a different AT through which the WTRU configuration update message was received, the WTRU can first send a configuration update completion message through the same AT through which the WTRU configuration update message was received. Alternatively, the WTRU can have a policy of sending the configuration update completion message using a different AT.

[0156] A WTRU can receive a WTRU configuration update message via a non-3GPP AT indicating that new MICO parameters need to be negotiated, or that a WTRU configuration update message has been sent due to an update in MICO parameters. An indication that registration is required may be provided in the message. If a WTRU is in an IM via a 3GPP AT, it can remain in a CM via a non-3GPP AT, but can initiate a registration procedure to the network to negotiate new MICO parameters (i.e., send a registration request message).

[0157] If the AMF wants to send a new 5G GUTI and TAI list to the WTRU, the AMF can inform the WTRU whether the TAI is applicable to a 3GPP AT or a non-3GPP AT. This information can be included regardless of the AT involved when the WTRU configuration update message is sent. The AMF can also send different AT indications for each TAI, or TAIs can be sent per AT. The TAI field can be defined so that it has the associated AT type. Indication of the TAI's association with an AT type can be important because the AMF may want to change a parameter that is associated with one AT but not another. Similarly, the AMF can inform the WTRU about the association of each parameter with an AT whenever applicable. For example, for any list of NSSAIs, the AMF can inform the WTRU whether the new NSSAI provided in the WTRU configuration update is applicable to one AT or both.

[0158] When a WTRU receives a WTRU configuration update message with a new 5G GUTI and / or TAI, the WTRU can verify which types of ATs the TAI list applies to or affects. The WTRU can update the TAI list for the indicated AT accordingly. A WTRU may receive multiple TAI lists and AT type IEs. The WTRU can represent a valid TAI list for each AT using the provided TAI list, thereby allowing the previous TAI list for each AT to be considered invalid by the WTRU.

[0159] When a WTRU receives a new authorized NSSAI, it can verify the AT associated with that new NSSAI. The WTRU can then update its list of authorized NSSAIs associated with the indicated AT accordingly.

[0160] A WTRU configuration update message can include newly authorized NSSAIs and indicate the need for registration by the WTRU. If a WTRU receives a new NSSAI via a non-3GPP AT, the WTRU can verify whether the message contains a new list of authorized NSSAIs. If the message does contain a new list of authorized NSSAIs, the WTRU can verify the AT associated with that new list and update the list accordingly. Furthermore, if the WTRU configuration update indicates that registration is required, the WTRU can perform the registration on the indicated AT without transitioning to an IM on a non-3GPP AT. The WTRU can remain in a CM via a non-3GPP AT.

[0161] If a WTRU configuration update message includes a new authorized NSSAI and an indication that registration is required, but does not include the AT type, the WTRU may perform one or more of the following actions: The WTRU may deactivate the 5G GUTI with respect to both ATs. The WTRU may locally deactivate all of its PDU connections associated with both 3GPP ATs and non-3GPP ATs. The WTRU may send a registration request via a 3GPP AT and provide its SUPI and new authorized NSSAI to a lower layer.

[0162] After successful registration on a 3GPP AT, a WTRU can re-register via a non-3GPP AT and use the 5G GUTI obtained via the 3GPP AT. A WTRU can have a policy of first registering via a non-3GPP AT and then subsequently registering using a 3GPP AT. For example, a WTRU can first register via the AT through which the WTRU configuration update message was received.

[0163] A WTRU can establish its PDU session through any of the ATs as needed. The PDU session can be established based on the permitted NSSAI and WTRU policies.

[0164] AMF can have a policy for using a specific AT type for short SMS signaling. For example, AMF may prefer to use a 3GPP AT for SMS based on a local policy. This policy can change over time and is not static. AMF can determine the preferred AT to use for SMS based on one or more of the following: local policy, subscription information, and subscription information updates from Unified Data Management (UDM) functionality. AMF can inform WTRUs about any new ATs that should be used. For WTRUs that are already registered, AMF can page them first if they are in idle mode. AMF can use WTRU configuration update messages to indicate the preferred AT to use for SMS. A WTRU configuration update can include one or more IEs indicating the affected service (e.g., SMS or location services) and the AT to use. Alternatively, if the WTRU is already in CN via either a 3GPP AT or a non-3GPP AT, the AMF may send a WTRU configuration update message with proposed information which may include the affected service (e.g., SMS) and the preferred AT to use for that service.

[0165] The WTRU can receive WTRU configuration update messages with updated parameters and information. The WTRU can only verify the indicated or affected services and their associated preferred access techniques.

[0166] AMF can use the WTRU configuration update command procedure to update slice coexistence parameters in the WTRU. If slice coexistence information changes on the network side (for example, due to network configuration), AMF can be notified by one of the following: network functions such as Network Slice Selection Function (NSSF), Unified Data Management (UDM) function, and Policy Control Function (PCF), or by the Operations and Maintenance (O&M) system. AMF can send the new slice coexistence information to the WTRU in a WTRU configuration command message.

[0167] If a WTRU is connected to both a 3GPP AT and a non-3GPP AT simultaneously, the AMF can send WTRU configuration update messages through both ATs. Coexistence information may affect NSSAI configured or permitted in both 3GPP and non-3GPP ATs. The AMF can send this information on the AT that has an NSSAI affected by the change in slice coexistence information. Alternatively, the AMF can send a WTRU configuration update message on either a 3GPP AT or a non-3GPP AT, and the new slice coexistence information may include the relevant AT values.

[0168] The slice coexistence information sent by AMF may include one or more single NSSAIs (S-NSSAIs) belonging to the separated slices, or one or more S-NSSAIs that cannot be included with the requested NSSAI.

[0169] When a WTRU receives a WTRU configuration update message with updated slice coexistence information, it can perform one or more of the following actions: The WTRU can compare the received slice coexistence information with the existing coexistence information to determine whether the permitted NSSAI is still valid. If the permitted NSSAI is no longer valid (for example, because it includes an NSSAI that is now marked as isolated in the new slice coexistence information), the WTRU can perform a registration update procedure (e.g., a mobility type registration update). The WTRU can delete the existing slice coexistence information and replace it with the new slice coexistence information. When the WTRU performs a re-registration procedure, it can determine the required NSSAI, taking into account the received coexistence information. The required NSSAI can be included in the registration request message to the AMF. The WTRU can choose not to include the received isolated S-NSSAI in the required NSSAI.

[0170] With the introduction of the IP Multimedia Subsystem (IMS), SMS messages can be sent over IP networks. SMS messages can be exchanged in the user plane, and routing can be performed using IP packets. This version of SMS can be called "SMS over IP" or "SMS over IMS." To support SMS over IP / IMS, network operators may need to reinforce their infrastructure with a specific gateway called an IP-SM-GW.

[0171] With the deployment of 5G networks, operators will have more freedom in their network selection. This means that during the registration phase, WTRUs and the network can negotiate how SMS will be supported and implemented. For example, the network can inform the WTRU that the legacy "SMS via NAS" will not be used, meaning that the only option for the WTRU to send / receive SMS will be SMS via IP / IMS.

[0172] Regarding the actual transmission of SMS messages via a NAS, the corresponding signaling protocols can be found in the WTRU and the SMS function (SMSF) on the core network side. At the NAS level, SMS messages and their corresponding acknowledgments can be exchanged between the WTRU and the SMSF.

[0173] In 5G systems, Cellular Internet of Things (CIoT) small data can be delivered via NAS signaling using behavior similar to SMS via NAS. During the registration phase, the WTRU and the network can negotiate how small data via NAS will be supported and implemented. If small data via NAS is enabled, the WTRU can send / receive small data via NAS signaling to / from the AMF.

[0174] At some point, a user's subscription may change based on the operator's operations and maintenance (O&M) and network configuration. If this occurs, the home database, Unified Data Management (UDM), can notify the anchor node of the mobility to which the WTRU is registered and update it. In 5G systems (5GS), this anchor node may be the AMF. Note that the only way a WTRU can be notified of any possible changes is by performing a registration update procedure to the AMF.

[0175] In 5GS, the AMF node only needs to be responsible for mobility management signaling. Service-related signaling messages can be exchanged between the WTRU and SMF (to establish a so-called PDU session), between the WTRU and SMSF (for "SMS via NAS" traffic), or between other nodes. The AMF can function as a relay with respect to service-related signaling traffic, sending and receiving messages to and from the WTRU and SMF / SMSF.

[0176] Two special NAS messages can be used between the WTRU and AMF (for example, at the mobility management level). These messages can be called uplink / downlink (UL / DL) NAS transport messages and can contain a container, which can be either a 5GSM message (for WTRU-SMF communication) or an SMS message (for WTRU-SMSF communication). In either direction, the AMF can extract the container and forward it to the correct (SMF or SMSF) node. An information element (IE) can be defined in the message that indicates the type of container. This IE can be called the payload container type. This IE can also indicate other nodes in the network.

[0177] A WTRU may not be aware of (or when) a change in subscription has occurred on the network side. The only way to synchronize both the WTRU and AMF regarding subscription changes may be to have the WTRU go through a registration renewal procedure. While a WTRU is typically scheduled to register periodically (e.g., according to a timer expiration), it may take a very long time before it actually does so. The timer may be reset on both the WTRU and the network side each time the WTRU transitions from idle to connected mode at the NAS level.

[0178] These issues can also exist with CIoT small data distribution (i.e., small data via NAS signaling). For example, a WTRU subscription on the CIoT functionality may change to "not permitted" for small data via the NAS. In this case, the WTRU may not be aware of the change in subscription on the network side.

[0179] Considering the issues mentioned above, a mechanism may be needed for the network / AMF to notify the WTRU of changes in the subscription.

[0180] Referring to Figure 6, a diagram illustrating the method for updating the subscription type is shown. In Step 1, if WTRU602 wants to send SMS or small data via the NAS in idle mode, it can initiate signaling traffic via a service request procedure and transition to connected mode. The service request procedure may include sending a service request message to the network. In Step 2, AMF604 can receive subscription change notifications from UDM or other NFs regarding SMS or small data.

[0181] In step 3, WTRU602 can send the first part of an SMS message or small data in a UL NAS transport message. It may also be possible for the WTRU to send SMS or small data in a service request message.

[0182] In step 4, AMF604 may determine that the subscription for SMS or small data has changed, and therefore AMF may choose not to transfer the container to SMSF (for SMS) or Network Exposure Function (NEF) / SMF (for small data).

[0183] In step 5, the AMF604 can extract and discard containers containing SMS or small data.

[0184] In step 6, AMF604 can send a DL NAS transport message or DL ​​NAS error message containing a dummy container (i.e., meaningless) and a specific cause code. A new payload container type can be defined to indicate that this particular container is a dummy. In step 7, the cause code can trigger a new action in WTRU602.

[0185] In step 8, WTRU602 initiates the registration procedure. During the registration procedure, the network (AMF604) may inform WTRU602 that SMS or small data via the NAS is no longer permitted. WTRU may receive such an indication in the registration acceptance message.

[0186] If AMF604 needs to contact WTRU602 for other reasons (e.g., a UCU procedure triggered by the modification or deletion of a network slice), it should be noted that AMF604 can communicate the subscription change to WTRU602 before receiving a service request procedure from WTRU602. This can prevent WTRU602 from requesting an SMS small data transmission. AMF604 can use the existing "registered / not registered" indication to have WTRU602 register.

[0187] When WTRU602 enters connected mode, SMS or small data can be sent by WTRU602 in a service request message. When AMF604 receives a service request with a small data or SMS container, it can perform the procedures described above. Upon receiving the service request, AMF604 can determine that the subscription for SMS or small data has changed. AMF604 can discard the container in the UL NAS message and create a response with a factor code to inform WTRU602 that the subscription for the service (SMS or small data) has changed. AMF604 can send the factor code in either an accept service or denial service NAS message. Upon receiving the factor code, WTRU602 can be informed that SMS or SD is not supported due to the subscription change. WTRU602 can then perform the registration procedure triggered by this factor code.

[0188] Alternatively, the AMF604 can transfer SMS or small data via the NAS to an SMSF or NEF / SMF. The AMF604 can include the response from the SMSF or NEF / SMF in the DL NAS transport message and add a cause code, as described above, to prompt the WTRU602 to perform a registration update.

[0189] In another example, WTRU Configuration Update (UCU) command messages can be used. In this example, if there is a change in the subscription for SMS or small data via the NAS, the WTRU602 may be in connected mode for reasons other than SMS traffic.

[0190] The AMF604 can send UCU command messages to the WTRU602 over an existing NAS signaling connection to inform the WTRU602 that there are changes in a subscription that require re-registration by the WTRU602. The UCU command messages may include specific cause codes as described above.

[0191] While features and elements are described above in specific combinations, a standard technician in the art will understand that each feature or element can be used alone or in any combination with other features and elements. The methods described herein can be implemented in computer programs, software, or firmware embedded in computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as ROM, RAM, registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital multi-purpose disks (DVDs). A processor associated with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for operating a wireless transceiver unit (WTRU), Connecting to the network using the first network slice and the second network slice simultaneously, Receiving a configuration update command from the network, wherein the configuration update command includes updated slice coexistence information for multiple network slices and indicates registration requirements according to the updated slice coexistence information, The updated slice coexistence information does not include slice information for using the first network slice and the second network slice simultaneously, The registration update procedure is performed based on the receipt of the configuration update command containing the updated slice coexistence information, wherein in the registration update procedure, the WTRU displays the updated slice coexistence information for the plurality of network slices in accordance with the received updated slice coexistence information. A method that includes this.

2. The method according to claim 1, wherein the updated slice coexistence information received in the configuration update command affects both 3GPP access technology (AT) and non-3GPP AT connections.

3. The method of claim 1, wherein the configuration update command is received from the Access and Mobility Function (AMF).

4. The method of claim 1, wherein the updated slice coexistence information further identifies one or more network slices associated with permitted network slice selection assistance information (NSSAI).

5. A wireless transceiver unit (WTRU) equipped with a processor, The aforementioned processor, Connecting to the network using the first network slice and the second network slice simultaneously, Receiving a configuration update command from the network, wherein the configuration update command includes updated slice coexistence information for multiple network slices and indicates registration requirements according to the updated slice coexistence information, The updated slice coexistence information does not include slice information for using the first network slice and the second network slice simultaneously, The registration update procedure is performed based on the receipt of the configuration update command containing the updated slice coexistence information, wherein in the registration update procedure, the WTRU displays the updated slice coexistence information for the plurality of network slices in accordance with the received updated slice coexistence information. WTRU is configured to execute.

6. The WTRU of claim 5, wherein the updated slice coexistence information received in the configuration update command affects both 3GPP access technology (AT) and non-3GPP AT connections.

7. The WTRU of claim 5, wherein the updated slice coexistence information further identifies one or more network slices associated with permitted network slice selection assistance information (NSSAI).

8. A method of communication using network devices, Communicating with a wireless transceiver unit (WTRU) using the first network slice and the second network slice simultaneously, Sending a configuration update command to the WTRU, wherein the configuration update command includes updated slice coexistence information for multiple network slices and indicates registration requirements according to the updated slice coexistence information, and the updated slice coexistence information does not include slice information for using the first network slice and the second network slice simultaneously. Receiving a registration update from the WTRU, wherein the WTRU displays updated slice coexistence information for the plurality of network slices in accordance with the updated slice coexistence information included in the configuration update command, A method that includes this.

9. The method of claim 8, wherein the configuration update command is transmitted from the Access and Mobility Function (AMF).

Images