Methods for protocol enhancements 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 January 12, 2018, U.S. Provisional Patent Application No. 62 / 653,817, filed April 6, 2018, and U.S. Provisional Patent Application No. 62 / 716,516, filed August 9, 2018, the contents of which are incorporated herein by reference. [Background technology]

[0002] Fifth generation (5G) mobile networks may allow a wireless transmit / receive unit (WTRU) to be registered to the same access and mobility function (AMF) over both 3rd Generation Partnership Project (3GPP) access technologies and non-3GPP access technologies (e.g., WiFi) within the same public land mobile network (PLMN). Summary of the Invention

[0003] A method for protocol data unit (PDU) session management over separate access technologies (ATs) is disclosed. A wireless transmit / receive unit (WTRU) may receive a first message from a network over a first access technology. The first message may trigger activation or reactivation of one or more PDU sessions over a second access technology. The WTRU may determine that one or more PDU sessions have been 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 over the first access technology. The second message may include a PDU session status information element (IE) indicating that the one or more PDU sessions have been locally deactivated, causing the network to release the PDU sessions.

[0004] A WTRU is disclosed. The WTRU may include an antenna and a processor operably coupled to the antenna. The processor and the antenna may be configured to receive a first message from a network via a first access technology. The first message may trigger activation or reactivation of one or more PDU sessions via a second access technology. The processor may be configured to determine that the 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 the second access technology. The processor and the 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 the one or more PDU sessions are locally deactivated, causing the network to release the PDU sessions. [Brief explanation of the drawings]

[0005] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate similar elements and in which: [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system shown in FIG. 1A, according to an embodiment. [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, according to an embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and an exemplary CN that may be used within the communication system shown in FIG. 1A, according to an embodiment. [Figure 2] 1 is a flow diagram illustrating a procedure for the transfer of protocol data units (PDUs) over different access technologies (ATs). [Figure 3] 10 is a flow diagram illustrating a procedure for management of a PDU via separate ATs. [Figure 4A] 10 is a flow diagram illustrating a first example of signaling for handling a race condition. [Figure 4B] 10 is a flow diagram illustrating a second example of signaling for handling a race condition. [Figure 4C] 10 is a flow diagram illustrating a third example of signaling for handling a race condition. [Figure 5] FIG. 1 is a diagram illustrating an extended protocol identifier (EPD). [Figure 6] FIG. 10 illustrates using a method to update a subscription type. DETAILED DESCRIPTION OF THE INVENTION

[0006] 1A illustrates 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, broadcast, etc., to multiple wireless users. The communication system 100 may enable the multiple wireless users to access such content through the sharing of system resources, including wireless 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), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tailed unique word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0007] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, and 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspot 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 devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may alternatively be referred to as a UE.

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

[0009] The base station 114a may be part of the 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), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive wireless 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 wireless 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, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ MIMO technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

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

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

[0012] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE Advanced (LTE-A) and / or LTE Advanced Pro (LTE-A Pro).

[0013] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as New Radio (NR) radio access, which may establish the air interface 116 using NR.

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

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

[0016] 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. 1A, base station 114b may have a direct connection to the Internet 110. Thus, base station 114b may not be required to access the Internet 110 via CN 106 / 115.

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

[0018] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing Plain Old Telephone Service (POTS). The Internet 110 may 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 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0019] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with separate wireless networks over separate wireless links.) For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may employ a cellular-based wireless technology and with a base station 114b that may employ an IEEE 802.11 wireless technology.

[0020] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a GPS chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the above elements while remaining consistent with an embodiment.

[0021] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0023] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0024] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may 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 WTRU 102 may be coupled to and may receive user input data from the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. The processor 118 may also access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include RAM, ROM, a hard disk, or any other type of memory storage device. The removable memory 132 may include a SIM card, a memory stick, an SD memory card, etc. In other embodiments, the processor 118 may access information from and store data in memory not physically located on the WTRU 102, such as a server or home computer (not shown).

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

[0027] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. The WTRU 102 may receive location information over the air interface 116 from base stations (e.g., base stations 114a, 114b) in addition to or in place of information from the GPS chipset 136 and / or determine its location based on the timing of signals received from two or more neighboring base stations. It will be appreciated that the WTRU 102 may obtain location information through any suitable location determination method while remaining consistent with an embodiment.

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

[0029] The WTRU 102 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 for both the UL (e.g., for transmission) and the downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and / or substantially eliminate self-interference through signal processing in hardware (e.g., a choke) or via a processor (e.g., via a separate processor (not shown) or via the processor 118). In an embodiment, the WTRU 102 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 for either the UL (e.g., for transmission) or the downlink (e.g., for reception)) may be half-duplex.

[0030] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0031] The RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it will be understood that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNode-B 160a may use multiple antennas, for example, to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0032] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. As shown in FIG. 1C, the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0033] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the above elements is shown as part of the CN 106, 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 MME 162 is connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial connection of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0035] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as fixing the user plane during handover between eNode Bs, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

[0036] The SGW 164 may be connected to a PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0037] The CN 106 may facilitate communication with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. The CN 106 may also provide the WTRUs 102a, 102b, 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 depicted in FIGS. 1A-1D as a wireless terminal, in certain representative embodiments it is contemplated that such a terminal may be capable of using a wired communication interface (e.g., temporarily or permanently) with the communication network.

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

[0040] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic to and from the BSS. Traffic to a STA originating from outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within a BSS may be sent through the AP, for example, if the source STA can send traffic to the AP, which can then deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source STA and a destination STA using direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may have no APs, and STAs within or using an IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an "ad hoc" mode of communication.

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

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

[0043] A Very High Throughput (VHT) STA can support channels of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz width. A 40 MHz channel and / or an 80 MHz channel can be formed by combining adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight adjacent 20 MHz channels or two non-adjacent 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data can be passed through a segment parser, 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. The streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed and the combined data can be sent to the Medium Access Control (MAC).

[0044] Sub-1 GHz modes of operation are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support meter-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices can have limited capabilities, including support for (e.g., only support for) specific and / or limited bandwidths. MTC devices can 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, e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah, includes a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA supporting the smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for a STA (e.g., an MTC-type device) that supports (e.g., only supports) the 1 MHz mode, the primary channel may be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) configuration may depend on the status of the primary channel. If the primary channel is busy, for example due to STAs (that only support a 1 MHz mode of operation) transmitting to the AP, then the entire available frequency band may be considered busy, even though most of those frequency bands may remain idle and available.

[0046] In the United States, the available frequency bands that can be used by 802.11ah are from 902 MHz to 928 MHz. In South Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is 6 MHz to 26 MHz depending on the country code.

[0047] 1D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As described above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0048] The RAN 113 may include gNBs 180a, 180b, and 180c, although it will be understood that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO techniques. For example, the gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, the gNB 180a may use multiple antennas, for example, to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In an embodiment, the gNBs 180a, 180b, and 180c may implement coordinated multipoint (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0049] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may be different for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., including different numbers of OFDM symbols and / or different lengths of absolute time duration).

[0050] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect to a gNB 180a, 180b, 180c while also communicating / connecting to another RAN, such as an eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0051] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the 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 (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0052] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 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 CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0053] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling separate PDU sessions with separate requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service being utilized by the WTRUs 102a, 102b, 102c. For example, separate network slices may be established for separate use cases, such as services relying on Ultra-Reliable Low-Latency (URLLC) access, services relying on enhanced High-Capacity Mobile Broadband (eMBB) access, services related to Machine-Type Communications (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0054] The SMFs 183a and 183b may be connected to the AMFs 182a and 182b in the CN 115 via an N11 interface. The SMFs 183a and 183b may also be connected to the UPFs 184a and 184b in the CN 115 via an N4 interface. The SMFs 183a and 183b may select and control the UPFs 184a and 184b and configure the routing of traffic through the UPFs 184a and 184b. The SMFs 183a and 183b may perform other functions, such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0055] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may 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, providing mobility anchoring, etc.

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

[0057] 1A-1D and the corresponding descriptions thereof, one or more or all of the functions described herein in connection with one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

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

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

[0060] As described above, a WTRU may be registered with the same AMF via both a 3rd Generation Partnership Project (3GPP) access technology (AT) and a non-3GPP AT (e.g., WiFi) within the same Public Land Mobile Network (PLMN). After the WTRU is registered via these access technologies, the WTRU may be in one or more of the following modes: The WTRU may be in a 5GMM connected mode (CM) via both the 3GPP AT and the non-3GPP AT. The WTRU may be in a CM via the 3GPP AT and in a 5GMM idle mode (IM). The WTRU may be in an IM via the 3GPP AT and a CM via the non-3GPP AT. The WTRU may be in an IM via the 3GPP AT and a CM via the non-3GPP AT. The WTRU may be in an IM via the 3GPP AT and a non-3GPP AT.

[0061] A paging procedure may 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). Thus, a WTRU in IM via a non-3GPP AT may not be able to be paged. However, the WTRU may be in CM via one AT but not the other AT. For example, when 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 the non-3GPP AT. To do so, the network may use a notification procedure to inform the WTRU. The network may send a notification message to the WTRU. The notification message may include an indication for the WTRU to re-establish resources for one or more protocol data unit (PDU) sessions via the second access technology. The indication may be either implicit or explicit.

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

[0063] A service request message may be sent in the CM over 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 may tell the network which PDU sessions it is allowed to move by including an information element (IE) known as the allowed PDU session status. If the WTRU does not want to move any of its PDU sessions over the 3GPP AT or has locally deactivated one or more PDU sessions that were present on the 3GPP AT, the WTRU may respond with a notification response indicating that no user plane resources should be activated for these PDUs over the 3GPP AT.

[0064] The AMF may not be able to provide multiple network slice selection assistance information (NSSAI). For example, a first NSSAI may correspond to a separate network slice. When a WTRU is connected to a network slice with the first NSSAI value, the WTRU may not be able to connect to another network slice at the same time.

[0065] In an example, the notification message may include a PDU session identification (ID) corresponding to the PDU session in which the DL data for the WTRU resides. The WTRU may accept the transfer of the PDU to another access based on WTRU policy.

[0066] Furthermore, the PDU session for which the network is sending the notification message may be desired to be transferred to the 3GPP AT, but the WTRU may want to transfer other PDU sessions even if there is pending DL data at that moment.

[0067] Notification messages may be used only for data related to existing PDU sessions. However, this may limit the efficiency of the messages. For example, there may be other cases where notifications can be used to reduce paging on the wireless network of a 3GPP system and to trigger service requests from the WTRU. Therefore, the conventional use of notifications may be very limited. It may be desirable to extend the use of notification messages to cover new cases or to apply to services that are not related to existing PDU sessions.

[0068] In the case where the WTRU is in CM via a non-3GPP AT while in IM via a 3GPP AT, the WTRU may have data or signaling to perform via the 3GPP AT (e.g., to perform a periodic registration update). At the same time, the WTRU's NAS entity may receive a notification message from the AMF via the non-3GPP AT. The WTRU behavior in this case is unclear. The WTRU may not have a configured procedure for prioritizing signaling and may not know what to configure as the establishment factor in the RRC layer.

[0069] Also, in the case where the WTRU is in CM over a non-3GPP AT while in IM over a 3GPP AT, the network may have previously experienced some overload or congestion with respect to data traffic associated with the gateway (e.g., PGW or UPF) or associated with the Access Point Name (APN) or Data Network Name (DNN). The WTRU may receive a back-off timer at the session management level.

[0070] Receipt of the back-off timer may prohibit the WTRU from sending signaling related to that particular node / network. There may be means for the network to inform the WTRU that congestion has been removed on the network side, thus allowing the WTRU to start sending signaling / data traffic to the network. For this to be realized, the WTRU may need to be in CM. However, since the WTRU may be in IM via 3GPP AT and CM via non-3GPP AT, using this arrangement, there may be a way to inform the WTRU that congestion has been alleviated.

[0071] There may be several protocol entities at the NAS level, both in the WTRU and in the network. When a protocol entity in the WTRU / network needs to send a message to another "corresponding" protocol entity in the WTRU / network, the sender may use a specific (e.g., predefined) value in a special field in the header of the NAS message called the Protocol Identifier (PD). On the receiving side, the receiver may look at the value of the PD to understand which protocol entity is addressed. The PD field may indicate several protocol entities that have been added with the evolution of GPRS, UMTS, and EPS. There may not be any values ​​left to be allocated to new 5G protocol entities. A new NAS header may be used for 5G protocols, and an extended version of the PD called the 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, for example, changing the WTRU's identity (5G GUTI) and / or tracking area identity (TAI) list, providing a new service area list, and providing an authorized NSSAI. However, there may be some ambiguity with the use of the WTRU configuration update message. The AMF may update the WTRU configuration by providing the new parameter information with a command, or may request the WTRU to perform a new registration update with the network to update the parameters. The procedure may be initiated by the network and may be used when the WTRU has an established 5GMM context and is in 5GMM-CM. The AMF may require an acknowledgement to ensure that the parameters have been updated by the WTRU.

[0073] The following parameters may be supported by a general WTRU configuration update procedure without the need to trigger a WTRU registration update procedure: 5G-GUTI, TAI list, service area list, allowed NSSAI, network identity and time zone information (e.g., network full name, network abbreviation, local time zone, universal time and local time zone, network daylight saving time), and local area data network (LADN) information. This procedure may update one or more configuration parameters (e.g., policy information). Configuration provided by a different NF than the AMF may be covered by this procedure or may be provided by a different NAS procedure, e.g., a WTRU route selection policy (RSP) provided by the PCF.

[0074] The Mobile Initiated Connection Only (MICO) parameter may require triggering a WTRU registration update procedure. The MICO mode of operation may be used for power savings in the WTRU. If the WTRU employs MICO, it may deactivate its radio access capabilities and enter a sleep mode. The sleep mode may be extended so that the WTRU "disappears" from the network. If the 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 may inform the CN (e.g., AMF) of this capability during the registration procedure. For example, the WTRU may send a parameter or IE in the registration request message that informs the CN that it wants to apply MICO mode.

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

[0076] When extending this IE to apply to additional features, the most significant bit of this octet may be reserved to indicate whether the IE is extended. For example, if bit position 8 has a value of 1, this IE may be followed by additional octets to extend it. The interpretation of the subsequent octets may be defined as needed for the additional features. For example, if the WTRU wants to reflect the use of seven features, it may set bit position 8 to a value of 0. If the WTRU has more than seven features to reflect, it may set bit position 8 to a value of 1 and use the additional octet. Bit position 8 of the additional octet may be reserved for the same purpose of indicating the additional feature. If the AMF accepts or allows the use of the feature, it may return a value of 1 for the bit position associated with the feature. Otherwise, it may set the bit position to 0. Note that the specific bit positions used above are provided as examples. Other bit positions may be defined or reserved to reflect any of the above.

[0077] Another way for the WTRU to indicate the use of MICO may be to use a bit position in the Registration Type IE. For example, the Registration Type IE in a Registration Request message may be one octet long. It may be a Type Value (TV) IE. The type may reflect that this is an IE for registration type, and the value indicates a specific type of registration, such as initial registration or registration update. The Value field may be four bits long, and three bits may be used to reflect the registration type. The fourth bit may be reserved for MICO use. For example, bits 1001 may be interpreted as follows: The first least significant bit (001) may be defined to reflect a registration type of "initial registration." The WTRU may set the MICO bits (e.g., the fourth and most significant bits of a half octet) to a value of 1 to indicate the need to use MICO.

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

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

[0080] The WTRU Configuration Update message may be sent to the WTRU when the WTRU is in CM. There may be no dependency on the AT through which the message may be sent. Upon receiving the WTRU Configuration Update message, the expected action by the WTRU may be to re-register. The WTRU may need to re-register with the network. However, some parameters and features, such as MICO, are only applicable to a 3GPP AT. Parameters that are applicable to a 3GPP AT cannot be negotiated via a non-3GPP AT. Upon receiving a WTRU Configuration Update message with an indication that registration is required, the WTRU may perform a 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 may apply equally to both ATs, such as the 5G GUTI and the associated TAI list. Receiving a new NSSAI with registration required may affect both ATs because an allowed NSSAI may be associated with a TAI list and different ATs may have different TAI lists. The WTRU may not know which AT will perform the registration update. The WTRU may not have complete information about the action to be taken. When the WTRU receives a new TAI list, it may not know which AT the TAI list may be associated with. It may be desirable to avoid ambiguity in the WTRU.

[0082] New network and WTRU behaviors for using the NAS notification message may be described herein. This may include various interpretations in the WTRU and responses from the WTRU in various cases and scenarios. The following description may also include extensions to the notification message to optimize system signaling and may not be limited to session management signaling. New WTRU behaviors for handling conflict situations between simultaneous NAS procedures over 3GPP AT and non-3GPP AT may be described below. How the AMF can use the notification message to inform the WTRU that at least session management congestion has ended may be described. The WTRU may use this information to stop the session management back-off timer. The following description may include new definitions for the EPD to support other types of mobility management message types. New procedures may also be defined for interpretation of the new EPD in the WTRU and the network.

[0083] The following description may include methods and procedures for minimizing ambiguity with the use of the WTRU Configuration Update message. The AMF may indicate the AT type for parameters included in the WTRU Configuration Update message. The WTRU may update the parameters of the indicated AT with new values. For a new NSSAI received via a non-3GPP AT, the WTRU may start with registration via a 3GPP AT if AT information is not provided in the WTRU Configuration Update message.

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

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

[0086] In an example, resources may be re-established via a second access technology. This may be because there is DL data associated with one or more PDU sessions in the 3GPP AT. The WTRU may have, for example, two PDUs, PDU X and PDU Y, associated with a non-3GPP AT. The notification message may relate to the PDU sessions over the 3GPP AT, but the WTRU may want to forward all data for PDU Y to the 3GPP AT. For PDU Y, no data is yet available, but the WTRU may want to indicate this in advance to the network, so that the network associates other PDUs with the 3GPP AT for subsequent DL data.

[0087] The WTRU can then still decide if it wants other PDU IDs to be moved to the 3GPP AT. As described above, this decision can be based on local policy, or the WTRU can display a message to the user, who can change the settings and set preferences. The WTRU can then send a service request and include the list of PDU IDs in the Allowed PDU Session Status IE.

[0088] In an example, the notification message may also include one or more PDU session IDs associated with non-3GPP ATs to which the network can forward data to the 3GPP AT. The WTRU may validate the received PDU session ID (PDU ID) against its local policy. The WTRU may have a policy indicating which PDU IDs are allowed to be forwarded via the target access technology. The WTRU may verify whether the received PDU ID is allowed to be forwarded via a different target access technology. The WTRU may further validate the details in its policy to make such a decision. The 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 can decide to do so, the WTRU may send a service request message to the network. The service request message may include a list of PDU IDs that the WTRU wants to forward to the 3GPP AT. The list of PDU IDs may be included in the Allowed PDU Session Status IE. In other words, the WTRU may use the received PDU ID to verify against its local policy and determine which PDU IDs may be forwarded to the 3GPP AT.

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

[0090] The WTRU may include a NAS level establishment cause in the service request message to inform the AMF why the service request is being sent. The details of this NAS level establishment cause may be defined in more detail below. The WTRU may include the NAS level establishment cause or other type of information explaining why it is sending the service request message and / or the service type that the WTRU wants to request. For example, the WTRU may include a service type set to "transfer PDUs from non-3GPP to 3GPP" to indicate that the WTRU wants to transfer at least one PDU session (e.g., identified by the Allowed PDU Session Status IE) from a non-3GPP AT to a 3GPP AT.

[0091] The AMF may receive a service request message (or other NAS message) with an Allowed PDU Session Status IE that identifies at least one PDU ID that the WTRU wants to forward from a non-3GPP AT to a 3GPP AT. The WTRU may also include an NAS level establishment cause or other information, such as a service type indicating "forward PDUs from non-3GPP to 3GPP" as described above. The AMF may verify the PDU IDs and determine that at least one PDU ID does not have DL data pending. The AMF's behavior may differ depending on whether the WTRU is initiating the service request itself or whether it is responding to a paging or notification message.

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

[0093] If the AMF can determine that the WTRU has initiated the request itself and has received at least one PDU session that the WTRU wants to transfer from a non-3GPP AT to a 3GPP AT, the AMF can proceed with the service request procedure, whereby user plane resources and a connection are set up for the WTRU. If accepted by the AMF, the AMF can respond to the WTRU with a service accept message and indicate the PDU session ID that the AMF accepted to set up the user plane resources.

[0094] When the AMF pages a WTRU via a 3GPP AT for data related to a non-3GPP AT PDU session, and the WTRU includes at least one PDU ID associated with the non-3GPP AT that it wants to move to the 3GPP AT, the AMF may take any of the following actions described herein:

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

[0096] The AMF may reject the service request message. The AMF may send a service rejection message to the WTRU, which may include a cause code to indicate to the WTRU that there is no DL data pending at that moment. The AMF may also indicate whether the 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 may have preferences or policies for determining this. Alternatively, as described above, the WTRU may include preferences in the service request message, where, for each PDU ID, the WTRU may inform the network whether it wants to associate the PDU with another AT. The WTRU may use its local policy to determine this. If the AMF determines that the PDU session referred to by the PDU ID can be associated with a 3GPP AT, the AMF may include the PDU ID and the associated AT. The WTRU may then update its local information to indicate that the PDU ID is associated with another AT, the type of which may be indicated in the NAS message (e.g., a service denial message).

[0097] The AMF may accept the service request message and include a cause code to indicate that resources are not intentionally set up (e.g., due to unavailability of pending DL data as described above). The AMF may also include further information in the NAS message to inform the WTRU that the PDU sessions identified by the PDU IDs are considered to be forwarded to another AT or are now associated with another AT. The WTRU may receive a service denial message with a new cause code indicating that a list of PDU IDs do not have resources set up for them. The message may indicate that the PDU sessions referred to by the PDU IDs are not associated with another AT. The WTRU may update its local SM context to reflect the new ATs now associated with each of the PDU sessions identified by the PDU IDs.

[0098] The WTRU may receive a service accept message in response to sending a service request message indicating a list of PDU IDs that the WTRU wants to forward or associate to another AT. The WTRU may expect that resources will be set up due to receipt of the service accept message. However, if resources are not set up (e.g., if the RRC layer at the WTRU did not receive a configuration message to set up radio resources), the WTRU may 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 accept message to determine whether the service request procedure is successful. The WTRU may use any of the above-mentioned IEs that may be included in the NAS message by the AMF. For example, the WTRU may use a cause code with a value indicating that the network has not intentionally set up user plane resources or radio resources for the user plane as a means to determine that the service request procedure is successful.

[0100] Alternatively, the WTRU may use the cause code as a means to consider that the radio resources were not set up but the service request procedure was completed successfully, or further information may indicate that the list of PDU sessions referenced by the PDU IDs are now associated with another AT. The WTRU may update its local context to reflect that the PDU sessions identified by the PDU IDs are now associated with another AT.

[0101] As noted above, the above proposals can occur across any AT and any connection mode. Note that the WTRU can send a service request message instead of a notification response message, which can include any and all of the information described herein. The procedures for sending a notification response message by the WTRU can apply in a similar manner if the WTRU sends a service request message instead.

[0102] Referring to Figure 2, a flow diagram illustrating a procedure for the transfer of PDUs through separate ATs is shown. Figure 2 illustrates how some of the above proposals may be used. The procedure for the transfer of PDUs may involve the WTRU 202, the 3GPP RAN 204, the non-3GPP AN 206, the AMF 208, and the SMF 210.

[0103] As shown in step 0, the WTRU 202 may be in a CM at a 3GPP AT and in an IM at a non-3GPP AT. The WTRU 202 may have PDU A associated with the 3GPP AT and may have PDU B and PDU C associated with the non-3GPP AT.

[0104] In step 1, the WTRU 202 may receive a notification message from the AMF 208. The notification message may include an indication for the WTRU to re-establish resources for one or more protocol data unit (PDU) sessions. The indication may be either implicit or explicit. In an example, the resources may be re-established via a second access technology. In step 2, the WTRU 202 may use local policies or preferences to determine whether one or more PDUs should be moved to a 3GPP AT.

[0105] In step 3, the WTRU 202 may send a service request message to the AMF 208. The service request message may include the allowed PDU session status (e.g., PDU B and / or PDU C). The service request message may also include further information indicating the permanent forwarding of PDU C to the 3GPP AT.

[0106] In step 4, the AMF 208 may determine which PDUs may be forwarded to the 3GPP AT.

[0107] In step 5, the AMF 208 may send the updated context to the SMF 210. The updated context may include access information for one or more of PDU B and PDU C.

[0108] In step 6, the AMF 208 may send a service accept message to the WTRU 202. The service accept message may include further information indicating the permanent transfer of PDU C to the 3GPP AT.

[0109] In step 7, the WTRU 202 may use the information received in the service accept message to update the SM context to reflect that PDU C is being forwarded to the 3GPP AT.

[0110] The WTRU 202 may decide not to forward any PDU sessions, regardless of whether there is pending DL data. The WTRU 202 may have a preference to temporarily refuse to forward PDU sessions. In this case, based on the WTRU policy, the WTRU 202 sends a notification response message to the network indicating that the WTRU 202 temporarily refuses to forward PDU sessions. The WTRU 202 may include a new cause code for each PDU session referenced by a PDU ID indicating that the WTRU 202 does not want to forward to another AT. Alternatively, the WTRU 202 may have a policy not to forward PDUs to another AT. In this case, the WTRU 202 may include an indicating cause code. The WTRU 202 may also send a service request message instead of a notification response message. The WTRU 202 may also indicate a time window during which future requests for PDU transfers across ATs are or are not allowed.

[0111] The AMF 208 may receive a NAS message (e.g., a notification response message or a service request message) with information indicating that some PDU sessions referenced by PDU IDs cannot be forwarded to another AT. The cause code or information in the NAS message may indicate a temporary or permanent refusal. The AMF 208 may send a notification message to the SMF 210 to indicate whether this is a permanent or temporary refusal. The AMF 208 may include the time during which the SMF 210 is or is not able to request such forwarding. The SMF 210 may update its local information accordingly.

[0112] 3, a flow diagram illustrating a procedure for management of PDUs via separate ATs is shown. The procedure for transfer of PDUs may involve the WTRU 302, the 3GPP RAN 304, the non-3GPP AN 306, the AMF 308, and the SMF 310.

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

[0114] In step 1, the WTRU 302 may receive a notification message from the AMF 308. The notification message may include an indication for the WTRU to re-establish resources for one or more protocol data unit (PDU) sessions. In an example, the resources may be re-established via a second access technology. In an example, the AMF 308 may start a timer. In step 2, the WTRU 302 may use local policies or preferences to determine whether other PDUs should be moved to the 3GPP AT.

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

[0116] In step 4, the AMF 308 can determine which PDUs can be deleted.

[0117] In step 5, the AMF 308 can send the updated context to the SMF 310.

[0118] If the WTRU 302 is in a CM for a 3GPP AT and an IM for a non-3GPP AT, or in a CM for a non-3GPP AT and an IM for a 3GPP AT, the WTRU 302 may have several PDU sessions. The WTRU 302 may keep some PDU sessions locally deactivated without signaling with the network. When the WTRU 302 receives a notification message with a list of PDUs for which the network has pending DL data, or the network wants to transfer to another AT, the WTRU 302 may verify whether the PDU sessions referenced by the PDU IDs are still active. If not, the WTRU 302 may send a notification response message and include a PDU session status IE to indicate that some PDU sessions have been deactivated by the WTRU 302. Alternatively, the WTRU 302 may send a service request message instead of a notification response message and indicate that the PDU sessions have been locally deactivated. The AMF 308 can then initiate the deactivation of the corresponding PDU session towards the SMF 310.

[0119] Thus, the WTRU 302 may send a notification response message and indicate that the PDU session has been deactivated. Alternatively, if the WTRU 302 receives a paging request over a 3GPP AT with an access type indicating non-3GPP access, and the WTRU 302 has deactivated its PDU session associated with the non-3GPP AT, the WTRU 3023 may send a service request message and indicate that there are no active PDU sessions in the WTRU 302 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] The notification message may be extended for use beyond the transfer of PDU sessions, which may be further detailed herein. The use of the notification message may be extended to make the overall system more efficient. For example, if the WTRU is in CM via a non-3GPP AT and in IM via a 3GPP AT, the AMF may have a policy to deliver Short Message Service (SMS) via the 3GPP AT. To avoid paging and resulting signaling in the system, the AMF may send a notification message to the WTRU via the 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 may include an indication in the notification message to let the WTRU know if the notification message is being sent for a particular service that is not necessarily related to user plane data. User plane data may refer to any type of data that does not travel via the control plane and may be IP or non-IP.

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

[0122] However, if the WTRU is in CM over a non-3GPP AT and receives the notification message, the WTRU can send a notification response to indicate to the network that it is not able to reactivate its user plane resources over the 3GPP AT. The WTRU can also indicate the reason why this is not possible (i.e., the WTRU can inform the network why it is not able to send the service request message). The WTRU can send an IE, which can be defined and included in the NAS message (e.g., notification response), that the WTRU is in a unauthorized area. Other cause codes or IEs can also 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 over the 3GPP AT.

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

[0124] The methods and procedures described hereinafter may be used to handle race conditions for NAS procedures via a 3GPP AT and a non-3GPP AT. A WTRU may be in a CM via a non-3GPP AT and in an IM via a 3GPP AT. The WTRU may run a periodic registration timer to protect periodic registration updates via the 3GPP AT. Periodic registration may not be supported via a non-3GPP AT. In one scenario, the WTRU may receive a notification message regarding pending DL data corresponding to a PDU session identified by a PDU ID, which is associated with a 3GPP AT. The WTRU may receive this notification message seconds or milliseconds before performing a registration update (i.e., it may be very close to expiring its periodic registration timer). By the time the notification message is received, the WTRU may also have to perform 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] The WTRU may prioritize a registration update procedure instead of a service request. Upon receiving a notification message (via a non-3GPP AT) with a list of PDU IDs associated with the 3GPP AT, the WTRU may verify whether the PDU session is still active at the WTRU. If the PDU session is active, the WTRU may send a registration update message via the 3GPP AT and include an uplink data status IE. The WTRU may 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 may also include other PDU IDs in the uplink data status IE if it has uplink data to send.

[0126] Another scenario for a race condition may occur when the WTRU is in IM via a 3GPP AT and a non-3GPP AT. The WTRU may receive a paging message with the 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 the non-3GPP AT. As described above, the WTRU's periodic registration timer may be expiring or may have just expired when the WTRU receives the paging message. In this case, the WTRU may also prioritize performing a registration update over a service request. Additionally, the WTRU may include an allowed PDU session status IE in the registration message.

[0127] These procedures may also be performed when the WTRU is in the "ATTEMPTING-REGISTRATION-UPDATE" state and the WTRU receives a paging message. In this case, if the WTRU receives a paging message with the AT type set to non-3GPP, the WTRU may send a Registration Request message and may include the Allowed PDU Session Status IE in the periodic registration message.

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

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

[0130] Similarly, if the AMF sent a notification message and started a timer to secure the response from the WTRU, the AMF may stop the timer using the received Registration Request message as described above. The AMF may consider the notification procedure successful.

[0131] As described above, in the case where the WTRU sends a registration request message, the AMF may perform one or more of the following actions: The AMF may take all actions related to receiving the service request message or the notification response message (if applicable) as described above. For example, the AMF may verify whether the included allowed PDU status IE contains PDU IDs that do not have pending DL data but that the WTRU wants to transfer to a 3GPP AT. The AMF may decide whether the transfer is allowed based on the WTRU's subscription and / or local policy. If the transfer is accepted, the AMF may inform the SMF (associated with the respective PDU ID) that the AT has changed to a 3GPP AT. The SMF may 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-described IEs in the registration accept message. For example, the registration accept message may include information to inform the WTRU whether other PDU sessions referenced by the PDU IDs are considered to be permanently associated with the 3GPP AT, even if no resources have been set up for these PDUs. The WTRU may use the included information in the registration accept message in the same manner as proposed for receiving information in a service accept or service denial message as described above. For example, the WTRU may receive a registration accept message with information that at least one PDU is now associated with a 3GPP AT. The WTRU may use this information to update its session management context so that the indicated PDU sessions are now associated with the 3GPP AT.

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

[0134] 4A-4C, flow diagrams illustrating signaling for handling a race condition are shown. FIG. 4A shows a first example of signaling used in the procedure described above. FIG. 4B shows a second example of signaling used in the procedure described above. FIG. 4C shows a third example of signaling used in the procedure described above. The signaling procedure may include a WTRU 402, a 3GPP RAN 404, a non-3GPP AN 406, and an AMF 408.

[0135] As shown in FIG. 4A , in step 1a, the AMF 408 may send a notification to the WTRU 402. In an example, the notification may include a list of PDU IDs for the 3GPP AT over the non-3GPP AT. Additionally or alternatively, in step 1b, the AMF may send a page using an access type of non-3GPP over the 3GPP AT. In step 2, the WTRU 402 may check whether one or more PDUs are active. In step 3a, the WTRU 402 may send a notification response to the AMF 408 with a PDU status IE. Additionally or alternatively, in step 3b, the WTRU 402 may send a service request to the AMF 408 with the PDU status IE.

[0136] As shown in FIG. 4B , in step 1, the AMF 408 may send a notification to the WTRU 402. In an example, the notification may include a list of PDU IDs for the 3GPP AT via a non-3GPP AT. In step 2, the WTRU 402 may trigger a TAU. In step 3, the WTRU 402 may send a registration request to the AMF 408. The registration request may include an allowed PDU IE. The WTRU 402 may include the PDU ID based on local policy. In step 4, the AMF 408 may stop the notification timer. In step 5, the AMF 408 may verify whether the PDUs in the registration request can be forwarded to the 3GPP AT. In step 6, the AMF 408 may send a registration accept message to the WTRU 402. The registration accept message may include information about which PDUs are being forwarded to the 3GPP AT, even if no user plane resources have been set up.

[0137] In FIG. 4C , in step 1, the AMF 408 may send a UCU message to the WTRU 402 over the non-3GPP AT. The UCU message may include one or more allowed NSSAIs and an AT type. In step 2, the WTRU 402 may proceed to IM at the non-3GPP AT. In step 3, the WTRU may send a registration request message to the AMF over the 3GPP AT. In step 4, the WTRU 402 may perform registration on the non-3GPP AT.

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

[0139] The WTRU may receive a notification message including at least a list of PDU IDs and, optionally, a DNN and / or S-NSSAI. This notification message may also include an explicit indication regarding the end of congestion for each PDU ID. Upon receiving this message, the WTRU may verify whether it has any back-off timers running for each PDU ID, DNN, S-NSSAI, or any combination. If the WTRU has corresponding session management back-off timers running for at least any of the PDU IDs in the notification message, the WTRU may stop the corresponding back-off timers and consider session management for at least the SMF, DNN, S-NSSAI, or combination thereof to be over. The WTRU may then start session management signaling toward the SMF (identified by the PDU ID, DNN, S-NSSAI, or combination thereof).

[0140] The notification message may also be used by the AMF to inform the WTRU of the initiation of congestion control for either mobility management or session management. If it determines that the AMF or SMF is congested, the AMF may send a notification message and indicate that congestion control should be applied by the WTRU for mobility management and / or session management signaling. The AMF may include corresponding mobility management back-off 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 the notification message, the WTRU may start the corresponding back-off timers (i.e., mobility management and / or session management) and may refrain from sending messages to the AMF and / or SMF accordingly.

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

[0142] In case of severe congestion, the CN can inform the RAN to back off any device requests for an RRC connection. The RAN node (e.g., gNB) can reject RRC connection request messages from the WTRU and provide them with a so-called extended waiting time (EXT). The EXT can function as a back-off timer. If the WTRU receives an EXT from the RAN node, it can only apply MICO mode directly and attempt to transition from IM mode to CM mode when the timer expires, as described above.

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

[0144] [Table 1]

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

[0146] A conventional 5G system may 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" may not be used and may instead indicate an error or abnormal condition. The reasoning behind this proposal is that certain L3 NAS messages have historically had a "skip indicator" that was all zeros and was present in the left half octet of the first octet. Examples of such protocols would be MM, GMM, EMM.

[0148] Two separate values ​​may be allocated to existing 5G NAS protocols (i.e., 5GMM and 5GSM). For example, a value of “0001 1110” may be used for 5GMM, and a value of “0010 1110” may be used for 5GSM. The actual EPD value for 5GMM may be “30,” and the actual value for 5GSM may be “46.” Note that other values ​​may 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 may consider the EPD to be further extended by at least one additional octet. The WTRU and / or AMF may then process the additional octet to determine the protocol. The additional octet may introduce 256 new values. The values ​​can start with a "0" (i.e., all bits are zero), or they can start with the value of the previous octet having bit positions of "11101110" (decimal value of 238) plus 256. New octets can have new spare values ​​that can be defined as needed.

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

[0150] To ensure correct WTRU behavior, further information can be provided in the WTRU Configuration Update message. As mentioned above, the WTRU Configuration Update message may be missing certain information, which may cause the WTRU behavior, when received, to be not as expected or complete. To remove ambiguity on the WTRU side so that the correct procedure is performed via the correct AT, the WTRU may handle the WTRU Configuration Update message as described below.

[0151] In an example, the network may send a WTRU Configuration Update message via a separate AT to update parameters specific to that AT. If the WTRU is registered via a 3GPP AT and the network wants to provide the WTRU with updated parameters related to features that are only available over the 3GPP AT (e.g., MICO, LADN, new service area, NSSAI), the AMF may send a WTRU Configuration Update via the 3GPP AT so that the WTRU can respond via the same AT. If the WTRU is in CM via the 3GPP AT, the AMF may send a WTRU Configuration Update message to the WTRU. However, if the WTRU is in IM via the 3GPP AT, the AMF may first page the WTRU and then perform a WTRU Configuration Update procedure directed to the WTRU.

[0152] Alternatively, if the WTRU is also registered via a non-3GPP AT, and the WTRU is in CM via the non-3GPP AT while in IM via the 3GPP AT, the AMF may first send a notification message via the non-3GPP AT and indicate to the WTRU to establish its NAS connection via the 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 the 3GPP AT. Alternatively, an indication from the AMF in the 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 the WTRU is in CM via a non-3GPP AT and receives a WTRU Configuration Update message via the non-3GPP AT with new parameters (e.g., a GUTI, TAI, and / or NSSAI), the WTRU may consider those parameters to only affect the non-3GPP AT. Thus, the WTRU may update its non-3GPP parameters with the parameters received via the non-3GPP AT. For example, if the WTRU receives a new TAI, it may consider the previous TAI received via the non-3GPP AT invalid and use the newly received TAI as the latest valid TAI. The WTRU may also update its 5G GUTI with the new value. However, if the WTRU is also registered with the same AMF in the same PLMN, the WTRU may 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 may be 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 the WTRU receives a WTRU Configuration Update message via a particular AT and the message contains parameters for the same or a different AT through which the WTRU Configuration Update message was received, the WTRU may first send a Configuration Update Complete message via the same AT through which the WTRU Configuration Update message was received. Alternatively, the WTRU may have a policy of sending the Configuration Update Complete message using a different AT.

[0156] The WTRU may receive a WTRU Configuration Update message via the 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 MICO parameter update. An indication that registration is required may be provided in the message. If the WTRU is in IM via the 3GPP AT, the WTRU may remain in CM via the non-3GPP AT but may initiate a registration procedure (i.e., send a Registration Request message) to the network to negotiate new MICO parameters.

[0157] When the AMF wants to send a new 5G GUTI and TAI list to the WTRU, the AMF may inform the WTRU whether the TAI is applicable to a 3GPP AT or a non-3GPP AT. This information may be included regardless of the AT through which the WTRU Configuration Update message is sent. The AMF may also send a different AT indication for each TAI, or the TAI may be sent for each AT. The TAI field may be defined to have an associated AT type. The indication of the association of the TAI to the AT type may be important because the AMF may want to change parameters that are relevant to one AT but not the other AT. Similarly, the AMF may inform the WTRU about the association of each parameter to an AT whenever applicable. For example, for every list of NSSAIs, the AMF may inform the WTRU whether the new NSSAI provided in the WTRU Configuration Update is applicable to one AT or both.

[0158] When the WTRU receives a WTRU Configuration Update message with a new 5G GUTI and / or TAI, the WTRU may verify what type of AT the TAI list applies to or affects. The WTRU may update the TAI list of the indicated AT accordingly. The WTRU may receive multiple TAI lists and AT type IEs. The WTRU may use the provided TAI list for each AT to represent the valid TAI list for the WTRU per AT, whereby the previous TAI list per AT may be considered invalid by the WTRU.

[0159] If the WTRU receives a new allowed NSSAI, the WTRU may verify the AT associated with the new NSSAI and may update its list of allowed NSSAIs associated with the indicated AT accordingly.

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

[0161] If the WTRU Configuration Update message contains a new allowed NSSAI and an indication that registration is required, but does not contain an AT type, the WTRU may perform one or more of the following actions: The WTRU may consider the 5G GUTI as invalid for 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 the 3GPP AT and may provide its SUPI and new allowed NSSAI to lower layers.

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

[0163] The WTRU may establish its PDU sessions through each of the ATs as needed, which may be established based on the allowed NSSAI and WTRU policy.

[0164] The AMF may have a policy of using a particular AT type for short SMS signaling. For example, the AMF may prefer to use a 3GPP AT for SMS based on a local policy. This policy may change over time and may not be static. The AMF may determine a preferred AT to use for SMS based on one or more of the local policy, subscription information, and subscription information updates from a unified data management (UDM) function. The AMF may inform the WTRU of a new AT to be used. For an already registered WTRU, the AMF may first page the WTRU if it is in idle mode. The AMF may use a WTRU configuration update message to indicate a preferred AT to use for SMS. The WTRU configuration update may 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 the CN via either a 3GPP AT or a non-3GPP AT, the AMF may send a WTRU Configuration Update message with suggested information, which may include the affected service (e.g., SMS) and the preferred AT to use for that service.

[0165] The WTRU may receive a WTRU Configuration Update message with updated parameters and information. The WTRU may validate only the indicated or affected services and associated preferred access technologies.

[0166] The AMF may use a WTRU Configuration Update Command procedure to update slice coexistence parameters in the WTRU. If slice coexistence information changes on the network side (e.g., due to network configuration), the AMF may be notified by one of the network functions, such as a Network Slice Selection Function (NSSF), a Unified Data Management (UDM) function, and a Policy Control Function (PCF), or an Operation and Maintenance (O&M) system. The AMF may send the new slice coexistence information to the WTRU in a WTRU Configuration Command message.

[0167] If the WTRU is simultaneously connected to a 3GPP AT and a non-3GPP AT, the AMF may send a WTRU Configuration Update message via both ATs. The coexistence information may affect the NSSAIs configured or allowed in both the 3GPP AT and the non-3GPP AT. The AMF may send this information on the AT that has the NSSAI that is affected by the change in slice coexistence information. Alternatively, the AMF may send a WTRU Configuration Update message on either the 3GPP AT or the non-3GPP AT and may include the AT values ​​to which the new slice coexistence information is associated.

[0168] The slice coexistence information sent by the 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 along with the requested NSSAI.

[0169] Upon receiving the WTRU Configuration Update message with updated slice coexistence information, the WTRU may perform one or more of the following actions: The WTRU may compare the received slice coexistence information with the existing coexistence information to determine whether the allowed NSSAI is still valid. If the allowed NSSAI is no longer valid (e.g., due to it including an NSSAI that is now marked as detached in the new slice coexistence information), the WTRU may perform a registration update procedure (e.g., a mobility type registration update). The WTRU may delete the existing slice coexistence information and replace it with the new slice coexistence information. When the WTRU performs a re-registration procedure, the WTRU may determine a requested NSSAI taking into account the received coexistence information. The requested NSSAI may be included in a registration request message to the AMF. The WTRU may not include the received detached S-NSSAI in the requested 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 done 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 enhance their infrastructure with a specific gateway called an IP-SM-GW.

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

[0172] As for the actual transfer of SMS via the NAS, the corresponding signaling protocol may be in the WTRU and the SMS Function (SMSF) on the core network side. At the NAS level, SMS messages and their corresponding acknowledgments may be exchanged between the WTRU and the SMSF.

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

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

[0175] In 5GS, the AMF node may only be responsible for mobility management signaling. Service-related signaling messages can be exchanged either between the WTRU and the SMF (to establish so-called PDU sessions), between the WTRU and the SMSF (for "SMS over NAS" traffic), or between other nodes. The AMF can act as a relay when it comes to service-related signaling traffic by sending and receiving messages to / from the WTRU and the SMF / SMSF.

[0176] Two special NAS messages may be used between the WTRU and the AMF (e.g., at the mobility management level). These messages may be called uplink / downlink (UL / DL) NAS transport messages and may contain a container, which may 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) may be defined in the message that indicates the type of container. This IE may be called the payload container type. This IE may also point to other nodes in the network.

[0177] The WTRU may not be aware if (or when) a change in subscription on the network side occurs. The only way to synchronize both the WTRU and the AMF regarding changes in subscription may be to have the WTRU go through a registration update procedure. The WTRU is normally supposed to perform periodic registration (e.g., according to the expiration of a timer), but it may take a very long time before it actually does so. The timer may be reset on both the WTRU and the NW side every time the WTRU transitions from idle to connected mode at the NAS level.

[0178] These issues may also exist for CIoT small data delivery (i.e., small data via NAS signaling). For example, the WTRU subscription on the CIoT feature may change to "not allowed" for small data via NAS. In this case, the WTRU may not be aware of the subscription change on the network side.

[0179] Considering the above issues, a mechanism may be needed for the network / AMF to inform the WTRU about changes in subscriptions.

[0180] Referring to Figure 6, a diagram illustrating using a method for updating a subscription type is shown. In step 1, if the WTRU 602 wants to send SMS or small data via the NAS in idle mode, it can initiate signaling traffic through 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, the AMF 604 may receive a subscription change notification from the UDM or other NF for the SMS or small data.

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

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

[0183] In step 5, the AMF 604 can extract and discard the container containing the SMS or small data.

[0184] In step 6, the AMF 604 may send a DL NAS transport message or a DL NAS error message that includes a dummy container (i.e., no meaning) and a specific cause code. A new payload container type may be defined to indicate that this specific container is a dummy. In step 7, the cause code may trigger a new action in the WTRU 602.

[0185] In step 8, the WTRU 602 initiates the registration procedure. During the registration procedure, the network (AMF 604) may inform the WTRU 602 that SMS over NAS or small data over NAS is no longer allowed. The WTRU may receive such an indication in a registration accept message.

[0186] Note that if the AMF 604 needs to contact the WTRU 602 for other reasons (e.g., a UCU procedure triggered due to a network slice modification or deletion), the AMF 604 may communicate the subscription change to the WTRU 602 before receiving a service request procedure from the WTRU 602. This may prevent the WTRU 602 from requesting SMS small data transmission. The AMF 604 may use the existing "registered / unregistered" indication to force the WTRU 602 to register.

[0187] If the WTRU 602 transitions to connected mode, the SMS or small data may be sent by the WTRU 602 in a service request message. If the AMF 604 receives a service request with a small data or SMS container, it may perform the procedures described above. Upon receiving the service request, the AMF 604 may determine that the subscription for SMS or small data has changed. The AMF 604 may discard the container in the UL NAS message and may create a response with a cause code to inform the WTRU 602 that the subscription for the service (SMS or small data) has changed. The AMF 604 may send the cause code in either a service accept or service denial NAS message. Upon receiving the cause code, the WTRU 602 may be informed that SMS or SD is not supported due to the change in subscription. The WTRU 602 may then perform the registration procedure triggered by this cause code.

[0188] Alternatively, the AMF 604 can forward the SMS or small data via NAS to the SMSF or NEF / SMF. The AMF 604 can include the response from the SMSF or NEF / SMF in a DL NAS transport message and add a cause code to cause the WTRU 602 to perform a registration update, as described above.

[0189] In another example, a WTRU Configuration Update (UCU) command message may be used, in which case the WTRU 602 may be in connected mode for reasons other than SMS traffic if a change in subscription occurs for SMS or small data via the NAS.

[0190] The AMF 604 may send a UCU command message to the WTRU 602 over the existing NAS signaling connection to inform the WTRU 602 that there is a change in the subscription that requires re-registration by the WTRU 602. The UCU command message may include a specific cause code as described above.

[0191] Although features and elements are described above in particular combinations, one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. The methods described herein can be implemented in a computer program, software, or firmware embodied in a computer-readable medium 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, ROM, RAM, registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile 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. 1. A method of operating a wireless transmit / receive unit (WTRU), comprising: determining that a first network slice and a second network slice are authorized for use by the WTRU; receiving a configuration update command from a network, the configuration update command including slice coexistence information indicating that the WTRU cannot use the first network slice and the second network slice simultaneously; and performing a registration update procedure based at least on receiving the configuration update command including the slice coexistence information, wherein in the registration update procedure, the WTRU indicates one or more network slices according to the received slice coexistence information, and the one or more network slices indicated in the registration update procedure do not include at least one of the first network slice or the second network slice; A method comprising:

2. The method of claim 1 , further comprising determining that the updated slice coexistence information does not include slice information for simultaneous use of the first network slice and the second network slice.

3. The method of claim 1 , wherein the slice coexistence information in a configuration update command affects connections for both 3GPP access technology (AT) and non-3GPP ATs.

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

5. The method of claim 1 , wherein the slice coexistence information further identifies one or more network slices that cannot be simultaneously used for communication with a network.

6. 10. The method of claim 1, wherein the indicated one or more network slices are associated with allowed network slice selection assistance information (NSSAI).

7. 1. A wireless transmit / receive unit (WTRU) comprising a processor, The processor: determining that a first network slice and a second network slice are authorized for use by the WTRU; receiving a configuration update command from a network, the configuration update command including slice coexistence information indicating that the WTRU cannot use the first network slice and the second network slice simultaneously; and performing a registration update procedure based at least on receiving the configuration update command including the slice coexistence information, wherein in the registration update procedure, the WTRU indicates one or more network slices according to the received slice coexistence information, and the one or more network slices indicated in the registration update procedure do not include at least one of the first network slice or the second network slice; The WTRU is configured to perform the following:

8. 8. The WTRU of claim 7, wherein the processor is configured to determine that the updated slice coexistence information does not include slice information for simultaneously using the first network slice and the second network slice.

9. The WTRU of claim 7 , wherein the slice coexistence information in a configuration update command affects connections of both 3GPP access technologies (ATs) and non-3GPP ATs.

10. The WTRU of claim 7 , wherein the slice coexistence information further identifies one or more network slices that cannot be simultaneously used for communication with a network.

11. 8. The WTRU of claim 7, wherein the indicated one or more network slices are associated with allowed network slice selection assistance information (NSSAI).

12. 1. A method of communication by a network device, comprising: determining that a wireless transmit / receive unit (WTRU) is authorized to use a first network slice and a second network slice; sending a configuration update command to the WTRU, the configuration update command including slice coexistence information indicating that the WTRU cannot use the first network slice and the second network slice simultaneously; and receiving a registration update from the WTRU, wherein the WTRU indicates one or more network slices according to at least the received slice coexistence information, the one or more network slices indicated in the registration update including at least one of the first network slice, the second network slice, or another network slice; A method comprising:

13. 13. The method of claim 12, wherein the network device is an Access and Mobility Function (AMF), and the configuration update command is sent from the AMF.

Images