Unavailability interval support in connection with congestion

Abstract

To provide systems, methods, and instrumentalities related to unavailability period support while a wireless transmit / receive unit (WTRU) is registered for non 3GPP access.SOLUTION: The device sends a registration request via non-access stratum signaling, where the registration request includes a first period. The device receives a registration accept message, the registration accept message indicating whether the device is to notify the network entity when the WTRU is available. The device determines that the unavailability event has ended. The WTRU determines whether to notify a network entity that the WTRU is available. The device transmits a registration update request based on the determination that the unavailability event has ended and the determination that the WTRU is to notify the network entity when the WTRU is available, wherein the registration update request indicates that the WTRU is available.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Application No. 63 / 457,504, filed April 6, 2023, the contents of which are incorporated herein by reference in their entirety. [Background technology]

[0002] Mobile communications using radio communications continues to evolve. The fifth generation is sometimes referred to as 5G. Previous (traditional) generations of mobile communications may be, for example, fourth generation (4G) long term evolution (LTE). Summary of the Invention

[0003] Systems, methods, and means relating to unavailable period support while a wireless transmit / receive unit (WTRU) is registered to (eg, only to) a non-3GPP access are described herein.

[0004] A device (e.g., a network device such as a WTRU, a device with an Access and Mobility Function (AMF)) may perform one or more of the following actions: The device may send a registration request (e.g., to a network entity), e.g., via Non-Access Stratum (NAS) signaling. The registration request may include a first period of time (e.g., an unavailable period of time associated with the WTRU). The device may receive a registration accept message. The registration accept message may indicate whether the device will notify the network entity when the WTRU is available (e.g., after an unavailable event / period has passed). The device may determine that the unavailable event has ended. The WTRU may determine (e.g., based on the registration accept message) whether to notify the network entity that the WTRU is available. The device may send a registration update request. The registration update request may be sent based on a determination that the unavailable event has ended and that the WTRU should notify the network entity when the WTRU is available. The registration update request may indicate that the WTRU is available.

[0005] For example, the device may receive an indication from a network indicating congestion. The device may receive an indication indicating a second period of time (e.g., a backoff period associated with the congestion). The second period of time may be determined. The first period of time may be greater than or equal to the second period of time.

[0006] The device may receive a registration request message (e.g., from the WTRU) indicating a first period of time (e.g., an unavailability period associated with the WTRU). The registration request may be associated with the unavailability information. The device may determine whether the WTRU should transmit an update message (e.g., after the first period of time). The device may transmit a registration accept message (e.g., to the WTRU). The device may transmit the registration accept message based, for example, on a determination that the registration request is associated with the unavailability information. The registration accept message may indicate an acceptance associated with the registration request message. The registration accept message may indicate whether the WTRU will transmit an update message after the first period of time (e.g., based on whether the WTRU is associated with discontinuous coverage). The registration accept message may indicate, for example, to refrain from transmitting an update message (e.g., after the first period of time) if the WTRU is associated with discontinuous coverage. The device may determine whether the WTRU is available after the first period of time. The device may determine whether an update message is received from the WTRU (e.g., before the first period expires), for example, if the registration accept message indicates that the WTRU should send an update message after a first period. The WTRU may be determined to be available, for example, if an update message is received before the first period expires. The device may send a rejection message, for example, associated with congestion. The rejection message may indicate a second period. The first period may be less than the second period.

[0007] The device may be a Multi-Universal Subscriber Identity Module (MUSIM) device. The device may send a first registration request to the first network. The first registration request may indicate enabling unavailable period functionality with the second network. The registration request may indicate a first unavailable period associated with the unavailable period. The device may determine that an unavailability event has been triggered. The device may determine that the device (e.g., the WTRU) will be unavailable for a period of time. The determination that the device will be unavailable for a period of time may be based on the determination that an unavailability event is triggered. The first unavailability period may be determined based on the determination that the device will be unavailable for a period of time. The device may receive a first registration response (e.g., from the first network). The first registration response may be a first registration accept message. The first registration response may indicate a first registration period. The first registration period may be equal to or greater than the first unavailability period. The device may determine a second unavailability period, for example, based on the first unavailability period. The device may send a second registration request to the second network. The second registration request may indicate enabling an unavailability period feature with the second network. The second registration request may indicate a second unavailability period. The device may receive a second registration response from the second network. The second registration response may be a second registration accept message. The second registration response may indicate a second registration period. The second registration period may be equal to or greater than the second unavailable period. The second unavailable period may be equal to or greater than the first registration period.

[0008] The device may perform actions associated with dual registration. The device may receive a registration request (e.g., from the WTRU). The registration request may indicate unavailable period information. The registration request may include an unavailable period information element, which may indicate the unavailable period information. The unavailable period information may indicate, for example, an unavailable period associated with the WTRU. The device may send a notification to an entity (e.g., a mobility management entity). The notification may indicate that the WTRU will be unavailable for a period of time. The device may receive a notification response (e.g., from the entity). The notification response may indicate an indication that the entity has accepted the WTRU's unavailability. The notification response may indicate a tracking area update period. The notification response may indicate an indication that the entity has accepted the WTRU's unavailability and the tracking area update period. The device may, for example, send a registration accept message (e.g., to the WTRU) based on the notification response. The registration accept message may indicate the tracking area update period. The registration accept message may, for example, indicate to the WTRU to perform a tracking area update with the entity based on the unavailability event being completed.

[0009] The device may perform an action associated with non-3GPP access. The device may receive a registration request (e.g., from the WTRU). The registration request may indicate a first period of time. The first period of time may be an unavailable period of time. The registration request may include, for example, an information element indicating the first period of time. The registration request may be transmitted via the non-3GPP access network. The device may, for example, transmit a registration response indicating that the first period of time has been accepted. The indication of acceptance of the first period of time may indicate an accepted unavailable period of time. The accepted unavailable period of time may be equal to or greater than the requested first period of time. The registration response may be transmitted based on receiving the registration request via the non-3GPP access network and the registration request indicating the first period of time. The device may determine that the WTRU is unreachable based, for example, on determining that a second period of time has elapsed. The second period of time may be associated with or equal to the unavailable period of time associated with the registration request. The device may transmit a connectivity loss repost. The connectivity loss report may indicate the unavailable period of time. The connectivity loss report may indicate that a period of unavailability is sent to the network exposure function. The device may receive a NAS message from the WTRU. The device may perform one or more of, for example, based on the received NAS message, stopping tracking associated with the second period of time, determining that the WTRU is reachable, determining that the WTRU is in a connected state, etc. The device may deregister the WTRU based on determining that the second period of time has expired. [Brief explanation of the drawings]

[0010] [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 exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system illustrated in FIG. 1A, according to one 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 illustrated in FIG. 1A, according to one embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 2] 1 illustrates an example of an unavailable event while NAS-level congestion control is active. [Figure 3] 10 illustrates an example where the unavailable period feature is used by a WTRU registered via non-3GPP access. [Figure 4] 1 illustrates an example of network-wide unavailability coordination. [Figure 5] 1 illustrates an example of unavailability coordination across multiple networks when multiple networks (e.g., both 5G networks) support unavailability features. [Figure 6] 10 illustrates an example of unavailability coordination across multiple networks when one of the networks does not support the unavailability feature for the MUSIM WTRU. [Figure 7] 1 illustrates an example of a dual registration scenario in which a WTRU has 5GMM and EMM contexts. [Figure 8] An example of using unavailable information to generate improved data analysis is provided. [Figure 9] 10 illustrates an example of a relay WTRU entering an unavailable period. [Figure 10] 1 illustrates an example where a remote WTRU enters an unavailable period. [Figure 11] 10 illustrates example logic for a WTRU's handling of unavailable period rejection. DETAILED DESCRIPTION OF THE INVENTION

[0011] 1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. The communication system 100 may enable the multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use 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 multiple carrier (FBMC), etc.

[0012] As shown in FIG. 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone networks (PSTNs) 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 the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 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, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspot or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain contexts), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0013] 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, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base station transceiver station (BTS), a Node B, an eNodeB, a Home Node B, a Home eNodeB, 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 depicted 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.

[0014] 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 radio signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for 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 one embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers per sector of the cell, for example, using beamforming to transmit and / or receive signals in desired spatial directions.

[0015] 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).

[0016] More specifically, as noted above, the communication system 100 may be a multiple-access system, but may use 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+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0017] In one 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).

[0018] In one 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 technology.

[0019] In one 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 jointly implement 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 and from multiple types of base stations (e.g., eNBs and gNBs).

[0020] 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., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0021] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, 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 road, 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 one 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, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114b may not need to access the Internet 110 through the CN 106 / 115.

[0022] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput, latency, error tolerance, reliability, data throughput, and mobility requirements. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, 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 communicate directly or indirectly 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 communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0023] 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, which use common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) of 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 use the same RAT as the RAN 104 / 113 or a different RAT.

[0024] 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 different wireless networks over different wireless links.) For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based wireless technology, and a base station 114b, which may employ an IEEE 802.2 wireless technology.

[0025] 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 global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0026] 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 application specific integrated circuit (ASIC), a field programmable gate array (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.

[0027] The transmit / receive element 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF 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.

[0028] 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.

[0029] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As noted 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, for example, NR and IEEE 802.11.

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

[0031] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components in the WTRU 102. The power source 134 may be any suitable device for providing power to 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.

[0032] 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. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0033] 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 functions, features, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, 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, a direction 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.

[0034] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals associated with a particular subframe (e.g., for both the UL (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference through either hardware (e.g., a choke) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for transmission and reception of either some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or downlink (e.g., for reception)).

[0035] 1C is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As mentioned 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 .

[0036] The RAN 104 may include eNodeBs 160a, 160b, and 160c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 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 an embodiment, the eNodeBs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNodeB 160a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0037] Each of the eNodeBs 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 eNodeBs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0038] 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 foregoing elements is depicted 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.

[0039] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function 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 attach 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) that employ other radio technologies such as GSM and / or WCDMA.

[0040] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNodeB handover, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0041] The SGW 164 may be coupled to the PGW 166 and 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.

[0042] The CN 106 may facilitate communications 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 communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may 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.

[0043] Although the WTRU is illustrated in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may use a wired communication interface (e.g., temporarily or permanently) with the communication network.

[0044] In a representative embodiment, the other network 112 may be a WLAN.

[0045] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. An AP may have access or interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of a BSS. Traffic originating outside the BSS to a STA may arrive through the AP and be transmitted to the STA. Traffic originating at a STA destined for a destination outside the BSS may be transmitted to the AP to be transmitted to its respective destination. Traffic between STAs within a BSS may be transmitted through the AP, for example, where the source STA may transmit traffic to the AP, and the AP may transmit 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 transmitted between (e.g., directly between) a source STA and a destination STA using direct link setup (DLS). In certain representative embodiments, DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad hoc" communication mode.

[0046] 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 a fixed width (e.g., a 20 MHz wide bandwidth) or a width that is dynamically set via signaling. The primary channel may be the operating channel of the BSS, but may be used by STAs to establish a connection with the AP. In certain representative 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 and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit in a given BSS at any given time.

[0047] High Throughput (HT) STAs may use 40 MHz wide channels for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

[0048] A very high throughput (VHT) STA may support channels of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz width. A 40 MHz and / or 80 MHz channel may be formed by combining multiple adjacent 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or by combining two non-adjacent 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data may pass through a segment parser that may separate the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed, and the combined data may be transmitted to the medium access control (MAC).

[0049] Sub-1 GHz operating modes 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 may support meter-type control / machine-type communications, such as MTC devices within macro coverage areas. An MTC device may have certain limited capabilities, including support for (eg, only support) certain and / or limited bandwidths. An MTC device may include a battery with a battery life above a threshold (eg, to maintain a very long battery life).

[0050] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be configured and / or limited by the STAs among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah embodiment, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only support) the 1 MHz mode, 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 can depend on the status of the primary channel. For example, if the primary channel is active due to a STA (that only supports 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered active, even though most of the frequency band may remain inactive and available.

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

[0052] 1D is a system diagram illustrating the RAN 113 and the CN 115, according to one embodiment. As noted 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 communicate with the CN 115.

[0053] 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 an embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNB 180a, 180b may transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c using beamforming. Thus, the gNB 180a may transmit and / or receive wireless signals to and / or from the WTRU 102a using, for example, multiple antennas. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. 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 unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement coordinated multipoint (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0054] 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 vary 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 different or scalable lengths (e.g., including different numbers of OFDM symbols and / or lasting different lengths of absolute time).

[0055] 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 another RAN (e.g., eNodeBs 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 with and connect to gNBs 180a, 180b, 180c while also communicating with and connecting to another RAN, such as eNodeBs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 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.

[0056] 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.

[0057] 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 foregoing elements is depicted 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.

[0058] 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 function 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 different PDU sessions with different 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 the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on Ultra-Reliable Low-Latency (URLLC) access, services relying on enhanced Massive Mobile Broadband (eMBB) access, services for 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) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0059] 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 allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notification. PDU session types may be IP-based, non-IP-based, Ethernet-based, etc.

[0060] 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 communications 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 policy, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0061] 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. In addition, the CN 115 may 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 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.

[0062] 1A-1D and their corresponding descriptions, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, 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 simulate network and / or WTRU functions.

[0063] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or 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 communication network to test other devices in the communication 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 communication network. The emulation devices may be directly coupled to another device for testing purposes and / or may perform the tests using terrestrial wireless communication.

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

[0065] References herein to a timer may refer to determining a time or determining a period of time. References herein to a timer expiry may refer to determining that a time has occurred or that a period of time has expired. References herein to a timer may refer to time, a period of time, time tracking, period tracking, etc. References to legacy technology or legacy handover may refer to legacy technology, such as LTE compared to NR, or legacy versions of technology, e.g., an earlier version / release of technology (e.g., an earlier NR release) compared to a later version / release of technology (e.g., a later NR release). References herein to a particular timer may be provided as an example of a timer.

[0066] Systems, methods, and means relating to unavailable period support while a wireless transmit / receive unit (WTRU) is registered to (eg, only to) a non-3GPP access are described herein.

[0067] A device (e.g., a network device such as a WTRU, a device with an Access and Mobility Function (AMF)) may perform one or more of the following actions: The device may send a registration request (e.g., to a network entity), e.g., via Non-Access Stratum (NAS) signaling. The registration request may include a first period of time (e.g., an unavailable period of time associated with the WTRU). The device may receive a registration accept message. The registration accept message may indicate whether the device will notify the network entity when the WTRU is available (e.g., after an unavailable event / period has passed). The device may determine that the unavailable event has ended. The WTRU may determine (e.g., based on the registration accept message) whether to notify the network entity that the WTRU is available. The device may send a registration update request. The registration update request may be sent based on a determination that the unavailable event has ended and that the WTRU should notify the network entity when the WTRU is available. The registration update request may indicate that the WTRU is available.

[0068] For example, the device may receive an indication from a network indicating congestion. The device may receive an indication indicating a second period of time (e.g., a backoff period associated with the congestion). The second period of time may be determined. The first period of time may be greater than or equal to the second period of time.

[0069] The device may receive a registration request message (e.g., from the WTRU) indicating a first period of time (e.g., an unavailability period associated with the WTRU). The registration request may be associated with the unavailability information. The device may determine whether the WTRU should transmit an update message (e.g., after the first period of time). The device may transmit a registration accept message (e.g., to the WTRU). The device may transmit the registration accept message based, for example, on a determination that the registration request is associated with the unavailability information. The registration accept message may indicate an acceptance associated with the registration request message. The registration accept message may indicate whether the WTRU will transmit an update message after the first period of time (e.g., based on whether the WTRU is associated with discontinuous coverage). The registration accept message may indicate, for example, to refrain from transmitting an update message (e.g., after the first period of time) if the WTRU is associated with discontinuous coverage. The device may determine whether the WTRU is available after the first period of time. The device may determine whether an update message is received from the WTRU (e.g., before the first period expires), for example, if the registration accept message indicates that the WTRU should send an update message after a first period. The WTRU may be determined to be available, for example, if an update message is received before the first period expires. The device may send a rejection message, for example, associated with congestion. The rejection message may indicate a second period. The first period may be less than the second period.

[0070] The device may be a Multi-Universal Subscriber Identity Module (MUSIM) device. The device may send a first registration request to the first network. The first registration request may indicate enabling unavailable period functionality with the second network. The registration request may indicate a first unavailable period associated with the unavailable period. The device may determine that an unavailability event has been triggered. The device may determine that the device (e.g., the WTRU) will be unavailable for a period of time. The determination that the device will be unavailable for a period of time may be based on the determination that an unavailability event is triggered. The first unavailability period may be determined based on the determination that the device will be unavailable for a period of time. The device may receive a first registration response (e.g., from the first network). The first registration response may be a first registration accept message. The first registration response may indicate a first registration period. The first registration period may be equal to or greater than the first unavailability period. The device may determine a second unavailability period, for example, based on the first unavailability period. The device may send a second registration request to the second network. The second registration request may indicate enabling an unavailability period feature with the second network. The second registration request may indicate a second unavailability period. The device may receive a second registration response from the second network. The second registration response may be a second registration accept message. The second registration response may indicate a second registration period. The second registration period may be equal to or greater than the second unavailable period. The second unavailable period may be equal to or greater than the first registration period.

[0071] The device may perform actions associated with dual registration. The device may receive a registration request (e.g., from the WTRU). The registration request may indicate unavailable period information. The registration request may include an unavailable period information element, which may indicate the unavailable period information. The unavailable period information may indicate, for example, an unavailable period associated with the WTRU. The device may send a notification to an entity (e.g., a mobility management entity). The notification may indicate that the WTRU will be unavailable for a period of time. The device may receive a notification response (e.g., from the entity). The notification response may indicate an indication that the entity has accepted the WTRU's unavailability. The notification response may indicate a tracking area update period. The notification response may indicate an indication that the entity has accepted the WTRU's unavailability and the tracking area update period. The device may, for example, send a registration accept message (e.g., to the WTRU) based on the notification response. The registration accept message may indicate the tracking area update period. The registration accept message may, for example, indicate to the WTRU to perform a tracking area update with the entity based on the unavailability event being completed.

[0072] The device may perform an action associated with non-3GPP access. The device may receive a registration request (e.g., from the WTRU). The registration request may indicate a first period of time. The first period of time may be an unavailable period of time. The registration request may include, for example, an information element indicating the first period of time. The registration request may be transmitted via the non-3GPP access network. The device may, for example, transmit a registration response indicating that the first period of time has been accepted. The indication of acceptance of the first period of time may indicate an accepted unavailable period of time. The accepted unavailable period of time may be equal to or greater than the requested first period of time. The registration response may be transmitted based on receiving the registration request via the non-3GPP access network and the registration request indicating the first period of time. The device may determine that the WTRU is unreachable based, for example, on determining that a second period of time has elapsed. The second period of time may be associated with or equal to the unavailable period of time associated with the registration request. The device may transmit a connectivity loss repost. The connectivity loss report may indicate the unavailable period of time. The connectivity loss report may indicate that a period of unavailability is sent to the network exposure function. The device may receive a NAS message from the WTRU. The device may perform one or more of, for example, based on the received NAS message, stopping tracking associated with the second period of time, determining that the WTRU is reachable, determining that the WTRU is in a connected state, etc. The device may deregister the WTRU based on determining that the second period of time has expired.

[0073] Described herein are systems, methods, and means relating to unavailable period support while a WTRU is registered with non-3GPP access (eg, non-3GPP access only).

[0074] A device (e.g., a network device such as a device with an Access and Mobility Function (AMF)) may perform (e.g., be configured to perform) one or more of the following actions: The device may receive a registration request. The registration request may include unavailability information (e.g., an unavailability period information element (IE)), which may be sent, for example, via a non-3GPP access network. The device may decide (e.g., based on receiving the registration request via the non-3GPP access network and / or based on the request including the unavailability period information element) to start tracking a period (e.g., start a wait timer). The device may assign the period (e.g., the wait timer) an initial value, which may be equal to the unavailability period given in the registration request. The device may decide (e.g., based on receiving the registration request via the non-3GPP access network and / or based on the request including the unavailability period information element), to send a registration response, which may include, for example, that the unavailability period request has been accepted and a notification to the network. The device may indicate acceptance of the unavailable period, for example, by sending the accepted unavailable period to a wireless transmit / receive unit (WTRU). The device may allocate an allowed unavailable period that is equal to or greater than the requested unavailable period. The device may determine to consider the WTRU unreachable and in an idle state (e.g., a 5GMM-IDLE state) (e.g., based on receiving a registration request over a non-3GPP access network and / or based on a request including an unavailable period information element). The device may send an indication that the WTRU is unreachable to a session management function (SMF) (e.g., based on the WTRU being unreachable and in an idle state (e.g., a 5GMM-IDLE state)). The indication may be sent in response to a downlink data notification from the SMF.The device may trigger a connectivity loss event report (e.g., which may include an unavailable period) to a network exposure function (NEF), and / or, if there is a connectivity loss event subscription for the WTRU by, for example, an application function (AF), the unavailable period may be reported to a subscribed AF. The device may receive an initial non-access stratum (NAS) message from the WTRU. The device may decide to stop tracking the period (e.g., stop a wait timer) (e.g., based on receiving the NAS initial NAS message) and may consider the WTRU reachable and in a connected state (e.g., 5GMM-connected state). The device may (e.g., alternatively) decide to (e.g., implicitly) deregister the WTRU based on expiration of the period (e.g., expiration of a wait timer).

[0075] An example device may include a processor configured to perform one or more actions. For example, a device (e.g., a network device such as a device with AMF) may receive a registration request from a wireless transmit / receive unit (WTRU). The registration request may comprise unavailability information (e.g., an unavailable period information element). The registration request may be sent over a non-3GPP access network. The device may start tracking the period (e.g., start a timer). The device may send a registration response. The registration response may include an indication that the unavailable period request was accepted. The device may determine that the WTRU is unreachable. The device may send a connectivity loss report.

[0076] The value of the period (e.g., timer) may be related to or equal to the unavailable period associated with the registration request. The registration response may be sent based on receiving the registration request over the non-3GPP access network and the registration request including the unavailable period information element. The indication of acceptance of the unavailable period request may indicate the accepted unavailable period. The accepted unavailable period may be equal to or greater than the requested unavailable period. A connectivity loss report may indicate the unavailable period. The connectivity loss report indicating the unavailable period may be sent to a network exposure function. The device (e.g., a processor) may be further configured to receive a NAS message from the WTRU and to perform one or more of: stopping tracking of the period (e.g., stopping a timer) (e.g., based on receiving the NAS message), determining that the WTRU is reachable, or determining that the WTRU is in a connected state. The device (e.g., a processor) may be further configured to implicitly deregister the WTRU based on expiration of the timer.

[0077] Described herein are systems, methods, and means for mechanisms for providing periods of network unavailability. Some events, such as an operating system (OS) upgrade, a silent reset in a modem, or a modem software update (e.g., also referred to as a binary update), may be performed with more than two (e.g., three) parties involved, e.g., the device, the operator, and the application function.

[0078] A WTRU performing a multi-party event may, for example, become unavailable (e.g., unable to interact with the 5G system) while the event operation is being performed (e.g., on the order of minutes). WTRU unavailability without prior knowledge from the core network and / or application functionality may, for example, impact (e.g., significantly) the operation of an application server if the application server depends on the availability of the WTRU during the unavailable period (e.g., the period when the WTRU is unavailable).

[0079] Described herein are systems, methods, and means related to handling unavailable periods for one or more scenarios, such as when a backoff period is active (e.g., a timer is running), when (e.g., when) a WTRU is registered with a network (e.g., 5GS) via non-3GPP access (e.g., only), when (e.g., when) a Multi-Universal Subscriber Identity Module (MUSIM) device is registered with multiple networks with and without support for unavailable features, when (e.g., when) a WTRU is registered with multiple networks (e.g., both an Evolved Packet System (EPS) and a 5th Generation System (5GS)), when (e.g., when) a remote WTRU and / or a relay WTRU enter an unavailable period for support of analysis for unavailable features (e.g., a Network Data Analysis Function (NWDAF)), and when (e.g., when) a Mobile Initiated Connection Only (MICO) mode and / or a strict periodic registration timer function is enabled.

[0080] An unavailable period may be a period during which the WTRU is unavailable, e.g., unable to interact with a network (e.g., a 5G system). The unavailable period may be, for example, on the order of several minutes. The unavailable period for the WTRU may be long enough (e.g., expected to be long enough) for the WTRU to perform (e.g., required) events such as one or more of the following: (a) a silent reset in the modem, (b) a security patch update, (c) an OS upgrade, (d) a modem software (SW) update, and / or (e) a device reboot upon a modem configuration change (e.g., via Open Mobile Alliance Device Management (OMA-DM)).

[0081] Seamless WTRU context recovery can be performed. Some events, such as an OS upgrade, a silent reset in the modem, or a modem software update (e.g., also called a binary update), can be performed with multiple (e.g., three) involved parties, such as the device, the operator, and the application function.

[0082] The WTRU may download the binary. Time for the WTRU to perform the upgrade is left for the WTRU implementation. Some WTRU implementations may use user input (e.g., seeking). The WTRU may delay execution of an event, for example, if the WTRU is unable to perform the event (e.g., due to insufficient storage or battery level). The WTRU may, for example, be unavailable (e.g., may not interact with the 5G system) if (e.g., when) such an operation is to be performed (e.g., on the order of minutes). The WTRU may become unavailable without prior knowledge from the core network and / or application functions. For example, if an application server depends on the availability of the WTRU during periods of unavailability (e.g., periods when the WTRU is unavailable), WTRU unavailability may impact critical operation of the application server.

[0083] A network (e.g., a 5G system) may allow a WTRU to provide an unavailable period (e.g., an unavailable period) to the network, for example, in a registration request or a deregistration request. The WTRU may store its mobility management (MM) context and session management (SM) context in a universal subscriber identity module (USIM) or non-volatile memory so that the MM context and SM context can be reused after the WTRU's unavailable period, for example, if an event is triggered in the WTRU that makes the WTRU unavailable for a certain period. The WTRU may trigger a mobility registration update procedure or a deregistration procedure and provide the unavailable period to the network, for example, if the WTRU is able to store its context. The network (e.g., an access and mobility function (AMF)) may take the unavailable period into account, for example, when determining a periodic registration update period (e.g., a periodic registration update timer value). The AMF may provide a periodic registration update time that is equal to or greater than the unavailable period, for example, to avoid interfering with the WTRU dealing with the event that caused the unavailability. At a later time (e.g., once the event that caused the WTRU to become unavailable is completed at the WTRU, or the event is delayed to a future time or canceled at the WTRU), the WTRU may trigger a registration procedure to resume normal service. The WTRU may refrain from (e.g., not include) the unavailable period in the registration request message. Depending on the WTRU state, the registration procedure may be an initial registration procedure or a mobility registration update procedure.

[0084] The AMF may provide a strict periodic registration period indication (e.g., a strict periodic registration timer indication) to the WTRU, for example, along with a periodic registration timer value. The periodic registration timer function may apply, for example, if (e.g., when) the WTRU uses MICO mode. The AMF may provide the indication to the WTRU based on expected WTRU behavior. For example, the AMF may configure (e.g., want to configure) the WTRU to be available for downlink data (e.g., in CM-connected mode) every hour (e.g., on the hour) to receive downlink data. The periodic registration period (e.g., timer) function may be useful, for example, if (e.g., when) the WTRU uses MICO mode. The periodic registration period (e.g., timer) function may be used to ensure that the WTRU is in CM-connected mode (e.g., at predictable times). For example, if the WTRU operates a strict periodic registration timer of 4 hours and applies a 10-minute active timer (e.g., always), it may know that the WTRU is available every 4 hours for 10 minutes. By enabling a strict periodic registration period (e.g., timer) function, the AMF can be configured to ensure that availability events (e.g., 10-minute availability events) occur at predictable times.

[0085] The Network Data Analysis Function (NWDAF) may interact with other network functions to collect data. The data collected by the NWDAF may be used by the NWDAF to determine analytical information. The analytical information may include statistics and predictions.

[0086] The AMF may be an example of a network function (NF) from which the NWDAF may collect data. The NWDAF can use the Namf_EventExposure service of the AMF to obtain data from the AMF. The NWDAF may provide the Nnwdaf_AnalyticsInfo service, which can be used by network functions to obtain statistics and predictions from the NWDAF. The Policy Control Function (PCF), Access and Mobility Management Function (AMF), Network Slicing Selection Function (NSSF), Network Publishing Function (NEF), Session Management Function (SMF), and Application Function (AF) are examples of network functions that may invoke or consume the Nnwdaf_AnalyticsInfo service.

[0087] The following items may include examples of information that may be sent to an NF that invokes or consumes the Nnwdaf_AnalyticsInfo service: first, network slice instance load level statistics and predictions, second, network slice load level statistics and predictions, third, network function load level statistics and predictions, fourth, network load level statistics and predictions, fifth, WTRU communication statistics and predictions, and sixth, WTRU abnormal behavior statistics and predictions.

[0088] The predictions and statistics provided by the NWDAF to the network functions may be based at least in part on information collected from other network functions, such as the AMF.

[0089] The unavailable period may be determined in 5GS for a WTRU (e.g., a particular WTRU). WTRU and / or network actions may be based on the determined unavailable period. The WTRU and the network (e.g., 5GC) may coordinate on the architecture-level workflow of the unavailable period and / or unavailable function.

[0090] The WTRU may provide an indication of support for unavailable periods, for example, in a registration request message (e.g., during the registration procedure). The AMF may indicate support for unavailable periods, for example, in a registration accept message.

[0091] The WTRU may store its MM context in the USIM or non-volatile memory, for example, so that if the WTRU and the network support unavailable periods and an event is triggered in the WTRU that makes the WTRU unavailable for a certain period of time (e.g., due to an OS upgrade or device reboot), the MM context can be reused (e.g., after the WTRU's unavailable period). The WTRU may, for example, trigger a mobility registration or deregistration procedure that includes the unavailable period if (e.g., when) the WTRU is ready to perform the event. The AMF may provide a periodic registration update period (e.g., a timer) based on the unavailable period indicated by the WTRU. For example, the AMF may provide a periodic registration update time that is longer than the unavailable period. The AMF may, for example, store information that the WTRU is unavailable in the WTRU context if the WTRU is not deregistered. The AMF may consider the WTRU unreachable until the unavailable period has elapsed or the WTRU enters a CM-connected state. While the WTRU is unreachable, (e.g., all) high-latency communication solutions may be applied (e.g., if supported), such as enhanced data buffering, downlink data buffering status reporting, etc. If there is a connectivity loss event subscription for the WTRU by an AF, the AMF may trigger a connectivity loss event report that may include the unavailable period to the NEF. The unavailable period may be reported to each subscribing AF.

[0092] The WTRU may (e.g., select) store the WTRU context (e.g., MM and SM context), for example, if (e.g., when) the WTRU is ready to perform an event (e.g., for an OS upgrade or device reboot). How the WTRU stores the context may depend on the WTRU implementation. The WTRU may use USIM functionality to store some or all of the WTRU context in the USIM.

[0093] The WTRU may trigger a registration procedure to resume normal service, for example, if the event that caused the WTRU to become unavailable has completed within the WTRU, or if the event has been postponed to a future time or canceled within the WTRU (e.g., due to insufficient storage capacity, low battery level, or completion of the event that caused the WTRU to become unavailable). The WTRU may refrain from (e.g., not include) the unavailable period in the registration request message. The registration procedure may be, for example, an initial registration procedure or a mobility registration update procedure, depending on the state that the WTRU will be in after the event.

[0094] Unavailable period support may be provided while a backoff period is active (e.g., a timer is running). While a non-access stratum (NAS) backoff period (e.g., a timer, or other backoff timer) is running in the WTRU (e.g., T3346 / T3347 / T3396, other backoff timer), a mobility management entity of the NAS layer may refrain from (e.g., not trigger, or not be allowed to trigger) triggering a mobility registration procedure toward the core network (e.g., with one or more exceptions, such as downlink (DL) paging / notification, UL high priority signaling, or emergency services). The WTRU (e.g., in this case) may refrain from (e.g., not send) a registration request to the network during the unavailable period.

[0095] The network may attempt (e.g., fail to contact) the WTRU for mobile terminated services while the backoff period (e.g., timer) is running, for example, if the WTRU refrains from (e.g., does not transmit) an unavailable period to the network and performs an action that may cause the WTRU to become unavailable while the backoff period (e.g., timer) is running. The attempt to contact the WTRU for mobile terminated services may fail.

[0096] One or more examples described herein may illustrate how a WTRU handles MM signaling when an MM backoff period (e.g., a timer) is running and the WTRU can (e.g., needs to) perform an event that makes the WTRU unavailable.

[0097] Support for unavailable periods may be provided while a WTRU is registered to a non-3GPP access and not to other accesses (e.g., registered only to the non-3GPP access). For example, if the NAS layer of the WTRU receives notification from lower layers that non-3GPP access is available, the WTRU may send an initial NAS message to establish an N1 NAS signaling connection to the AMF. The NAS may (e.g., then) consider the WTRU to be in 5GMM-connected mode over the non-3GPP access. The WTRU may (e.g., then) be reachable for mobile-terminated communications from the network. For example, the WTRU may receive a NAS notification message from the network indicating that downlink data is available to the WTRU. A WTRU in 5GMM-connected mode over a non-3GPP access may (e.g., generally) remain in 5GMM-connected mode unless, for example, the WTRU disconnects from the non-3GPP network.

[0098] The periodic registration update procedure may be refrained from (eg, cannot be performed), for example, if (eg, when) the WTRU is registered via a non-3GPP access.

[0099] A WTRU registered via non-3GPP access may indicate periods of unavailability to the network so that the network and the WTRU can maintain the WTRU's registration state and / or so that the network understands that the WTRU may not be able to reach mobile-terminated communications.

[0100] Unavailability period support may be provided for MUSIM devices. One or more examples described herein may illustrate how the unavailability feature may be handled for MUSIM devices registered with two or more different networks.

[0101] In some examples, multiple (e.g., both) networks may support the unavailable feature. In some examples, both networks may be given (e.g., the same) unavailable period. In some examples, the unavailable period may be determined based on results from the first network. In some examples, at least one of the networks may not support the unavailable feature.

[0102] The MUSIM WTRU may register with multiple networks. NAS signaling procedures may be performed sequentially (e.g., sequentially only). There may be an element of delay (e.g., that may be considered) while communicating with the network for periods of unavailability. Reporting unavailability to the network may be considered sequentially while coming out of unavailability, e.g., to ensure that the network is notified within a specified time frame.

[0103] One or more examples described herein may show how a MUSIM WTRU having different configurations (e.g., all networks support the unavailable feature or one or more of the networks do not support the unavailable feature) can indicate the unavailable period to the network, for example, so that the network and the MUSIM WTRU can maintain the MUSIM WTRU's registration state and / or so that the network understands that the WTRU is not reachable for mobile-terminated communications.

[0104] Unavailable period support may be provided to devices registered with multiple networks (e.g., both EPC and 5GC). A WTRU (e.g., capable of operating in S1 and N1 modes) may be registered with both EPS and 5GS. A WTRU registered with EPS may be said to be in S1 mode. A WTRU registered with 5GS may be said to be in N1 mode. A dual-registered WTRU may be in both S1 and N1 modes (e.g., simultaneously).

[0105] One of the networks (e.g., the EPS) may not support negotiation of unavailable periods, e.g., via an S1 NAS interface between the WTRU and a mobility management entity (MME) of the EPS. One or more examples described herein may illustrate how the EPS knows (e.g., decides) to refrain from (e.g., not to) deleting the WTRU's context and / or how it knows (e.g., decides) to refrain from attempting to contact (e.g., not to attempt to contact) the WTRU for mobile-terminated communications when the WTRU is performing (e.g., is performing) an event that makes it temporarily unavailable.

[0106] Analytics (e.g., NWDAF) may be supported for unavailable period functionality. As described herein, the NWDAF may provide statistics and / or predictions to other network functions. As described herein, the WTRU may indicate to the AMF that the WTRU may be unavailable for a period of time, for example, by sending the unavailable period in a registration request or by providing the unavailable period in a deregistration request.

[0107] There may be several scenarios to consider. First, the unavailable period provided by the WTRU to the AMF may not be a common event. For example, the unavailable period may occur (only) if (e.g., when) the WTRU is installing a software upgrade. Second, multiple (e.g., many) WTRUs in an area may be installing software upgrades at the same time or at similar times. Multiple WTRUs may become unavailable and become available again at approximately the same time. Third, the unavailable period provided by the WTRU may strongly indicate when the WTRU is going to perform a registration procedure with the network (e.g., if the WTRU is expected to attempt to register with the network within the unavailable period).

[0108] The unavailable periods requested by the WTRU may have a strong impact on possible future events in the network. The unavailable periods requested by the WTRU may affect the accuracy of statistics and predictions provided by the NWDAF to other network functions. The NWDAF may obtain the unavailable periods and / or may take the unavailable periods into account when generating the statistics and predictions (e.g., using one or more features described herein).

[0109] Unavailability period feature support may be provided to the relay WTRU. One or more examples described herein may illustrate how to handle scenarios for the relay WTRU, handling of unavailable events for the relay WTRU and the remote WTRU, and / or how coordination may be maintained between connected relay WTRUs and remote WTRUs.

[0110] The WTRU may be configured (e.g., by the network) to use a (e.g., strict periodic) registration period (e.g., timer) function. As explained above, the strict periodic registration timer function may be configured so that the WTRU is in CM-connected mode and is available to receive downlink data at predictable times. This feature may be useful for devices that use MICO mode and / or enter long sleep periods, for example, to save power. The opportunities for these devices (e.g., the WTRU) to be available for downlink data may be very rare (e.g., hours or even days apart). If the WTRU requests an unavailable period that overlaps with when the WTRU is expected to be available for downlink data, it may cause the WTRU to miss downlink data that may be transmitted from a server that the WTRU expected to be available at the expected time.

[0111] Multiple parties (e.g., three parties) may be involved to perform an event (e.g., an operation), such as an OS upgrade, a silent reset on a modem, or a modem software update (e.g., also referred to as a binary update). The multiple parties involved may include, for example, a device (e.g., a WTRU), an operator, and an application function.

[0112] The WTRU may become unavailable (e.g., may not interact with the 5G system) whenever such an operation is performed, for example, on the order of minutes. The WTRU may become unavailable without prior knowledge from the core network and / or application functions. Unexpected WTRU unavailability may affect operation (e.g., critical operation), for example, of an application server if the application server depends on the availability of the WTRU during the unavailable period (e.g., the period when the WTRU is unavailable).

[0113] Described herein are systems, methods, and means for handling the unavailable period feature for multiple scenarios, such as when (e.g., when) a backoff period (e.g., a timer) may be operated, when (e.g., when) a WTRU may be registered to a network (e.g., 5GS) via non-3GPP access (e.g., only), when (e.g., when) a MUSIM device may be registered to multiple networks with and without support for the unavailable feature, when (e.g., when) a WTRU is registered to multiple networks (e.g., both EPS and 5GS) for support of analysis for the unavailable feature (e.g., NWDAF), when (e.g., when) a remote WTRU and / or a relay WTRU enter an unavailable period, and when (e.g., when) MICO mode and / or strict periodic registration period (e.g., timer) features are enabled.

[0114] While a backoff period (e.g., a timer) is running, unavailable period support may be provided. The AMF may perform (e.g., general) NAS-level congestion control, for example, upon detection of mobility management (e.g., 5GMM) signaling congestion. The WTRU may refrain from (e.g., not transmit, not be allowed to transmit) transmitting mobility registration update messages (e.g., under 5GMM signaling congestion conditions), except for one or more scenarios such as, for example, emergency services and / or high priority services.

[0115] The AMF may reject the NAS message (e.g., if / when general NAS-level congestion control is active) and include a mobility management (MM) back-off period (e.g., timer, e.g., T3346) value in the reject message. The WTRU may start tracking the period (e.g., timer, e.g., T3346) using the value received in the MM (e.g., 5GMM) reject message. The WTRU may, for example, refrain from (e.g., be prohibited from) sending one or more (e.g., specific) NAS messages (e.g., mobility registration updates) if (e.g., if) the back-off period (e.g., timer) is running. The WTRU may, for example, respond to network-initiated signaling (e.g., a page triggered by downlink data) if (e.g., if) the back-off period (e.g., timer) is running.

[0116] The WTRU may notify the network about the start of an unavailable period, for example, based on (e.g., in response to) detecting an event at the WTRU that may (e.g., causes) the WTRU to be unavailable for a (e.g., specific) period of time. The WTRU may notify the network about the start of an unavailable period via a Registration Request message (e.g., including an Unavailability Period IE), for example, if the WTRU is capable of storing an MM (e.g., 5GMM) context and an SM (e.g., 5GSM) context. However, the WTRU may refrain from (e.g., do not notify, cannot notify) notifying the network (e.g., AMF) about the WTRU's unavailability in one or more scenarios. For example, if (e.g., when) NAS-level congestion control is active, the WTRU may refrain from (e.g., not allow) triggering UL NAS signaling to send a mobility registration update.

[0117] The WTRU may refrain from (e.g., not perform) actions that would make the WTRU unavailable without notifying the network. The network may initiate signaling for the WTRU and, for example, find that the WTRU is unresponsive if the network is not notified. The WTRU may not respond because, for example, the WTRU may be performing an action (e.g., a software upgrade) that would make it unavailable.

[0118] The WTRU may, for example, send (e.g., be allowed to send) mobility registration updates to the network if (e.g., even if) a backoff period (e.g., a timer) is running. The WTRU may generate NAS signaling to inform the network about the unavailable period and then again to inform the network that the WTRU is available again. The signaling may be generated while the backoff period (e.g., a timer) is running. In some examples, multiple WTRUs in the same area may be performing the same software upgrade. Unavailability and availability signaling from multiple WTRUs may trigger a significant amount of NAS signaling to be processed by the network, for example, even during congestion situations.

[0119] It is possible for a WTRU to send a Registration Request message (e.g., including an Unavailable Period IE) while NAS-level congestion control is active (e.g., while a period or timer is running, e.g., while T3346 is running). The WTRU can (e.g., be configured to) prevent or avoid (e.g., be limited to ensuring that the Registration Request message does not include) a subsequent request, Uplink Data Status IE, and / or Allowed PDU Session Status IE. The WTRU may (e.g., further) be configured (e.g., limited) to request (e.g., only request) an unavailable period that is equal to or greater than the amount of time remaining on the NAS backoff period (e.g., a timer, e.g., T3346).

[0120] The AMF (e.g., based on receiving a registration request including an unavailable periodic request while the backoff timer is running) may respond to the WTRU (e.g., as indicated in a registration accept message) with information including, for example, one or more of the following: (i) an indication that the registration and unavailable period have been accepted; (ii) an indication that the previously provided back-off period (e.g., a timer, e.g., T3346) continues to run and is not reset, e.g., the WTRU may indicate to the WTRU that it may still consider NAS-level congestion control to be active; (iii) a new back-off period (e.g., timer) value (e.g., T3346) to indicate to the WTRU that it may still consider NAS-level congestion control to be active; (iv) an indication that the WTRU may notify the AMF when it becomes available again, e.g., even if the back-off period (e.g., timer) is running (e.g., T3346); and / or (v) an indication that the WTRU may not notify the AMF when it becomes available again if the back-off period (e.g., timer) is running (e.g., T3346).

[0121] The above example indication in the registration accept message may give the AMF control over whether the WTRU generates additional signaling when the WTRU becomes available again. Figure 2 shows an example procedure for the WTRU to signal an unavailable period and for the AMF to (e.g., still) limit the amount of NAS signaling.

[0122] 2 illustrates an example of an unavailable event during which NAS-level congestion control may be active. As shown in FIG. 2, at 210, NAS-level congestion control may be active for a WTRU, e.g., because the WTRU received a reject response from the AMF. The reject response may include a time period (e.g., a timer, e.g., a T3346 timer). NAS-level congestion control may be active at the WTRU. A time period (e.g., or other time period) may be running (e.g., T3346 and / or other backoff timers may be running). The WTRU may refrain from triggering (e.g., not triggering, not allowing triggering, etc.) NAS-level signaling except for, e.g., high priority access, emergency services, and / or when the WTRU is responding to paging from the network side.

[0123] 2, the WTRU may detect the need to perform an event at the WTRU that may cause the WTRU to be unavailable for a certain period of time. The WTRU may (e.g., also) detect an amount of time that the WTRU is expected to be available. For example, the time value may be provided by an application or an operating system.

[0124] At 230 of Figure 2, the WTRU may trigger a registration request procedure towards the AMF. The WTRU may provide an unavailable period IE to inform the network about the WTRU's unavailable period. The WTRU (e.g., if a back-off timer is running in the WTRU) may set (e.g., determine) the unavailable period to the period determined in 220, for example, if the period is greater than the amount of time remaining in the back-off period (e.g., a timer such as T3346). The WTRU may otherwise request (e.g., determine) a time that is greater than or equal to the amount of time remaining in the back-off period (e.g., a timer).

[0125] 2, the AMF may take into account the presence of the Unavailability Period IE and refrain from rejecting (e.g., not rejecting) the registration request and / or respond with a registration accept message. The AMF may also use the registration accept message to indicate that a previously provided back-off period (e.g., a timer, e.g., T3346) may continue to operate and may not be reset, to provide a new back-off period (e.g., timer) value (e.g., T3346) to indicate to the WTRU that the WTRU may still consider NAS-level congestion control active, and / or to indicate, for example, whether the WTRU may notify the AMF when it becomes available again even if the back-off period (e.g., timer) is running.

[0126] At 250 of FIG. 2, the WTRU may (e.g., successfully) perform a device reboot upon an event that rendered the WTRU unavailable, such as a silent reset on the modem, a security patch update, an OS upgrade, a modem SW update, and / or a modem configuration change via OMA-DM.

[0127] At 260 of FIG. 2, the WTRU may notify the AMF about the WTRU's (e.g., successful) performance of the unavailable event, for example, if the back-off period (e.g., timer) is no longer running or if the AMF indicated at 240 that the WTRU may notify the AMF when the WTRU becomes available again (e.g., even if the back-off timer is running). The WTRU may inform the AMF about the WTRU's performance (e.g., successful) of the unavailable event, for example, by sending a Registration Request message, for example, by refraining from (e.g., without) including the unavailable period IE. The WTRU may wait until the back-off period (e.g., timer) expires and then notify the AMF about the WTRU's (e.g., successful) performance of the unavailable event, for example, if the back-off period (e.g., timer) is running or if the AMF indicated at 240 that the WTRU may refrain from (e.g., not notify) the AMF when the WTRU becomes available again if the back-off period (e.g., timer) is running. The WTRU may wait until a backoff period (e.g., a timer) expires and then notify the AMF about the WTRU's (e.g., successful) execution of the unavailable event, e.g., by sending a registration request message, e.g., by refraining from (e.g., not including) the unavailable period IE.

[0128] 2, further example procedures are provided when a backoff period (eg, a timer) is running. The WTRU may perform one or more of the following:

[0129] 2, at 210, the WTRU may receive a NAS rejection message indicating that the WTRU is being restricted due to a congestion condition in the network. The NAS rejection message may include a period (e.g., a timer value) indicating how long the WTRU can consider the congestion condition applicable and / or how long the restriction is applicable. The WTRU may, for example, start tracking a backoff period (e.g., a backoff timer) based on receiving the period (e.g., the timer value).

[0130] 2, at 220, the WTRU may detect the need to perform an event at the WTRU that may cause the WTRU to be unavailable for a (e.g., specified) period of time. The WTRU may detect the amount of time that the WTRU is expected to be available.

[0131] 2, the WTRU may send a registration request to the network. The registration request may include a WTRU unavailable period. The WTRU unavailable period may be set to a value equal to or greater than a backoff period (e.g., timer value), for example, based on an operating backoff period (e.g., timer) and / or based on a backoff period (e.g., timer) value that is greater than the amount of time the WTRU is expected to be available.

[0132] As shown in FIG. 2 at 240, the WTRU may receive a registration accept message from the network. The registration accept message may include an indication that a previously provided back-off period (e.g., a timer, e.g., T3346) may continue to run and not be reset, which may cause or trigger the WTRU to continue applying NAS-level congestion control. The registration accept message may include a different (e.g., new) back-off period (e.g., timer) value (e.g., T3346) to indicate to the WTRU that the WTRU can still consider NAS-level congestion control active, which may cause or trigger the WTRU to continue applying NAS-level congestion control and / or assign a different (e.g., new) value to the back-off period (e.g., timer). The registration accept message may include an indication that the WTRU may notify the AMF when the WTRU becomes available again, for example, even if the back-off period (e.g., timer) is running (e.g., T3346), which may trigger the WTRU to send a registration update request to the network when the unavailability event ends. The registration update request may refrain from (e.g., do not) include the unavailable period. The registration accept message may refrain from (e.g., do not) notify the AMF when the WTRU becomes available again if a back-off period (e.g., timer) is running (e.g., T3346), which may include an instruction that causes or can trigger the WTRU to not send a registration update request to the network when an unavailable event ends while the back-off period (e.g., timer) is still running. The WTRU may send (e.g., decide to send) a registration update request to the network when the back-off period (e.g., timer) expires. The registration update request may refrain from (e.g., do not) include the unavailable period.

[0133] Unavailability period support may be provided while the WTRU is registered to (e.g., only to) a non-3GPP access. The network (e.g., a 5G system) may enable (e.g., indicate) the WTRU to send a registration request to the AMF over the non-3GPP access. The registration request may include unavailability information (e.g., an unavailable period information element (IE)).

[0134] The AMF may perform (e.g., be triggered to perform) one or more actions based on (e.g., upon) receipt of unavailability information (e.g., an unavailability period information element) from a WTRU registered via non-3GPP access. For example, the AMF may be triggered to perform one or more of the following:

[0135] The AMF may send a registration response to the WTRU, for example, indicating that the unavailable period request has been accepted and that the network now considers the WTRU to be in an idle state (e.g., 5GMM-IDLE state). The AMF may indicate acceptance of the unavailable period by, for example, sending the accepted unavailable period to the WTRU. The AMF may allocate an accepted unavailability period that is equal to or greater than the requested unavailability period.

[0136] The AMF may consider the WTRU to be in an idle state (eg, 5GMM-IDLE state).

[0137] The AMF may start tracking a period (e.g., a wait timer). The AMF may assign an initial value to the period (e.g., a wait timer), and the initial value may be equal to the unavailable period provided in the registration request.

[0138] The AMF may consider the WTRU unreachable until the WTRU sends an initial NAS message. Examples of initial NAS messages include, for example, a registration request, a service request, and / or a control plane service request.

[0139] The AMF may, for example, consider the WTRU to be deregistered (e.g., in 5GMM-DEREGISTERED state) if a period (e.g., a wait timer) expires before the AMF receives an initial NAS message from the WTRU.

[0140] 3 illustrates an example where the unavailable period feature is used by a WTRU registered via non-3GPP access. For example, FIG. 3 illustrates support for the unavailable period feature where the WTRU may register with a network (e.g., 5GCN) via non-3GPP access (e.g., non-3GPP access only).

[0141] 3, the WTRU may register with the 5GCN via non-3GPP access (e.g., only non-3GPP access) at 310. The non-3GPP access may be trusted or untrusted.

[0142] At 320, an event may occur at the WTRU that may cause the WTRU to become unavailable for a (eg, specified) period of time.

[0143] At 330, the WTRU may send a registration request to the AMF, for example, via a non-3GPP access network. The registration request may include unavailability information (e.g., an unavailability period information element).

[0144] At 340, the AMF may start tracking a period (e.g., a wait timer). The AMF may initially set the period (e.g., a wait timer) value to be equal to or greater than the unavailable period.

[0145] At 350, the AMF may send a registration accept message to the WTRU. The registration accept message may indicate acceptance of the requested unavailable period and / or may provide the WTRU with an unavailable period value that the WTRU can use. The AMF may consider the WTRU to be in an idle state (e.g., 5GMM-IDLE state) and unreachable (e.g., now). The AMF may indicate to the SMF that the WTRU is unreachable, for example, if a downlink data notification can be received from the SMF. The AMF may trigger a connectivity loss event report towards the NEF, for example, if there is a connectivity loss event subscription by the AF for the WTRU. The connectivity loss event report may include the unavailable period. The unavailable period may be (e.g., further) reported to each subscribing AF.

[0146] At 360, the WTRU may (e.g., successfully) perform an event that rendered the WTRU unavailable, such as a silent reset on the modem, a security patch update, an OS upgrade, a modem SW update, and / or a device reboot upon a modem configuration change via OMA-DM.

[0147] At 370, the WTRU may send an initial NAS message to the network, for example, to indicate to the AMF that the WTRU is now reachable.

[0148] At 380, the AMF may stop tracking the period (e.g., stop the wait timer), for example, based on (e.g., in response to) receiving the initial NAS message. The AMF may consider the WTRU to be in a connected state (e.g., 5GMM-connected state) and / or consider the WTRU to be reachable. The AMF may (e.g., implicitly) deregister the WTRU, for example, if the message provided at 370 is not received or is not received before the wait time expires.

[0149] Unavailability period support may be provided to MUSIM devices. Unavailability coordination may be provided across the network.

[0150] A WTRU may be registered with multiple (e.g., two) networks. The WTRU may send a registration request to a first network (e.g., of the multiple networks). The registration request may include an unavailable period. The first network may respond with a registration accept message and / or a periodic registration period (e.g., a timer), which may be equal to or greater than the requested unavailable period. The WTRU may (e.g., subsequently) send a registration request to a second network. The WTRU may include a second unavailable period in the request to the second network. The WTRU may set (e.g., select) the second unavailable period to a value equal to or greater than the periodic registration timer received from the first network. This approach may help ensure that the second network refrains from (e.g., does not) indicating to the WTRU that the WTRU may re-register before (e.g., significantly before) the time associated with (e.g., requested by) the first network.

[0151] FIG. 4 shows an example of how the unavailable period feature can be used by a WTRU in a scenario where the MUSIM feature is also used.

[0152] FIG. 4 illustrates an exemplary procedure for network-wide unavailability coordination.

[0153] As shown in FIG. 4, at 410, the MUSIM WTRU may be registered with multiple (eg, two) networks.

[0154] At 420, the WTRU may detect that the WTRU needs to perform an event that may be associated with the WTRU being unavailable (e.g., requiring the WTRU to be unavailable) for a period of time. The WTRU may determine a first period of unavailability.

[0155] The WTRU may send a registration request to the first network, at 430. The registration request may include the first period of unavailability.

[0156] The AMF of the first network may send a registration response to the WTRU, at 440. The registration response may include a periodic registration period (e.g., a timer), which may be greater than or equal to the first unavailable period.

[0157] At 450, the WTRU may determine a second unavailable period. The WTRU may set the second unavailable period to a value greater than or equal to the periodic registration timer received from the first network. Setting the second unavailable period in this manner may ensure that the WTRU may have sufficient time to contact multiple (e.g., both) networks upon completion of the unavailable period.

[0158] At 460, the WTRU may send a registration request to the second network. The registration request may include a second period of unavailability.

[0159] At 470, the AMF of the second network may send a registration response to the WTRU. The registration response may include a second periodic registration period (e.g., a timer), which may be greater than or equal to the second unavailable period.

[0160] In some examples, multiple (e.g., both or all) networks may support the unavailable period feature. For example, a MUSIM WTRU may have multiple SIM cards, e.g., more than two USIMs. The MUSIM WTRU may be registered with different networks. In some examples (e.g., the following example shown in FIG. 5), a MUSIM WTRU may be equipped with multiple (e.g., two) USIM cards and / or registered with multiple (e.g., two) different (e.g., 5G) networks. Other configurations may be implemented.

[0161] FIG. 5 shows an example of unavailability coordination across multiple networks when multiple networks (e.g., both 5G networks) support unavailability features.

[0162] As shown in FIG. 5, at 510, a MUSIM device with two active USIM cards may be successfully registered to two different (e.g., 5G) networks (e.g., AMF-1 and AMF-2) that support unavailable features.

[0163] At 520, an event may occur in the WTRU that may cause the WTRU to become unavailable for a (e.g., specified) period of time. The WTRU (e.g., as a MUSIM device) may communicate sequentially with the network (e.g., 5GS). The MUSIM WTRU may allow for delays related to (de)registration procedures.

[0164] At 530, the MUSIM WTRU may select / pick a first network, e.g., AMF-1. The WTRU may send a registration request message to AMF-1. The message may include, for example, an unavailable period IE along with a start delay (e.g., Δt). The delay start (Δt) may inform the network AMF-1 that the unavailable period may take into account a delay with a provided delay start period value and / or the actual period for which the WTRU will be unavailable, e.g., unavailable period + Δt. The delay start may be calculated taking into account the number of pending registration (de-registration) procedures that the MUSIM WTRU may perform (e.g., need to perform) to notify other networks about its unavailability. For example, Δt may be calculated as Δt=(N=1)×(time required (e.g., needed) to register (de-register) to notify AMF-2 about unavailability + registration to notify network (AMF-2) about end of unavailability period), where N may be the number of registrations that the MUSIM may perform (e.g., needs to perform). In the example scenario shown in FIG. 5, there may be one or more registration events to notify AMF-2 about the unavailability period. The time associated with (de)registration (e.g., needed (e.g., required) for) may take into account the best and / or worst possible cases, e.g., retransmission timers / counters, retry timers / counters, etc. Deregistration as a power down may take into account a period (e.g., timer) that the WTRU may wait for a response from the network. A MUSIM WTRU may, for example, consider (e.g., implicit) deregistration if there is no response from the network.

[0165] At 440, AMF-1 may respond with a registration accept message. AMF-1 may (e.g., subsequently) release the RRC signaling connection.

[0166] At 550, the MUSIM WTRU may send a registration request to a second AMF, e.g., AMF-2, as the last instance it needs to be notified of unavailability. The delay start may be set to zero (0), e.g., Δt=0.

[0167] At 560, AMF-2 may respond with a registration accept message. AMF-2 may (e.g., subsequently) release the connection (e.g., RRC signaling connection).

[0168] At 570, the MUSIM WTRU may (e.g., successfully) perform an event that rendered the MUSIM WTRU unavailable, such as a silent reset on the modem, a security patch update, an OS upgrade, a modem SW update, and / or a device reboot upon a modem configuration change via OMA-DM.

[0169] At 580, the MUSIM WTRU may send a Registration Request message to AMF-2 (e.g., refrain from (e.g., do not include) the Unavailability Period IE), informing the network that the MUSIM WTRU is (e.g., currently) available. There may be a sequence for exiting unavailability. For example, the network last notified of the unavailable period may be the first network notified of availability. In an example scenario, AMF-2 may be given higher priority than AMF-1 for notifying of the WTRU's availability. The delayed start provided to AMF-1 may take into account delays associated with notifying other networks of the unavailability, and may be followed by availability and / or corresponding procedure timing.

[0170] At 590, the MUSIM WTRU may send a registration request message to the AMF-1 (eg, without including the unavailable period IE) to inform the network that the MUSIM WTRU is (eg, currently) available.

[0171] 5, an example is provided in which multiple (e.g., both or all) networks may support the unavailable period feature. The MUSIM WTRU may perform one or more of the following:

[0172] As shown in FIG. 5, at 510-520, a MUSIM device (e.g., a WTRU) with two active USIM cards may be (e.g., successfully) registered with two different (e.g., 5G) networks that support unavailability features, e.g., AMF-1 and AMF-2. An event may occur in the WTRU that may cause the WTRU to become unavailable for a (e.g., specific) period of time. The WTRU (e.g., as a MUSIM device) may communicate sequentially with the network (e.g., 5GS). The MUSIM WTRU may account for delays associated with the registration (deregistration) procedure.

[0173] As shown in FIG. 5, at 530 / 540, the MUSIM WTRU may select / pick a first network (e.g., AMF-1) and send a registration request message that may include an unavailable period (IE) and / or a start delay Δt. The start delay (Δt) may inform the network AMF-1 that the unavailable period may consider a delay with the provided start delay period value. The actual period for which the WTRU may be unavailable may be the unavailable period + Δt. The start delay may be calculated, for example, by taking into account the number of pending registration (de-registration) procedures that the MUSIM WTRU may perform (e.g., need to perform) to notify other networks about its unavailability.

[0174] In the example shown in Figure 5, for example, Δt may be determined as Δt = (N = 1) x (time required (e.g., needed) for (de)registration to notify AMF-2 about unavailability + registration to notify network (AMF-2) about end of unavailability period), where N may be the number of (de)registrations that the MUSIM may perform (e.g., need to perform). In the example scenario shown in Figure 5, there may be one or more registration events to notify AMF-2 about unavailability period.

[0175] The time associated with (e.g., required for) registration (de-registration) may take into account the best and / or worst possible cases, e.g., retransmission timers / counters, retry timers / counters, etc. De-registration as a power down may take into account a period (e.g., a timer period) that the WTRU may wait for a response from the network. The MUSIM WTRU may consider de-registration (e.g., implicit de-registration), for example, if there is no response from the network. The AMF-1 may (e.g., subsequently) release the RRC signaling connection, for example, if the AMF-1 responds with a registration accept message.

[0176] As shown in FIG. 5, at 550 / 560, the MUSIM WTRU may send a registration request to a second AMF (e.g., AMF-2) as the last instance it needs to be notified of unavailability. The start delay may be set to zero (0), e.g., Δt=0. The AMF-2 may respond with a registration accept message. The AMF-2 may (e.g., subsequently) release the connection (e.g., RRC signaling connection).

[0177] As shown in FIG. 5, at 570 / 580 / 590, the WTRU may (e.g., successfully) perform an event that caused the WTRU to become unavailable, such as a silent reset in the modem, a security patch update, an OS upgrade, a modem SW update, and / or a device reboot upon a modem configuration change via OMA-DM. The MUSIM WTRU may send a Registration Request message to AMF-2 (e.g., without including an Unavailability Period IE) to notify the network that the MUSIM WTRU is (e.g., currently) available. There may be a sequence for exiting unavailability. For example, the network last notified of an unavailable period may be the first network notified of availability. For example, as shown in FIG. 5, AMF-2 may be given a higher priority than AMF-1 for notifying of the WTRU's availability. The delayed start provided to AMF-1 may take into account the delay associated with notifying other networks of the unavailability, e.g., followed by availability and corresponding procedure timing. The MUSIM WTRU may send a registration request message to the AMF-1 (eg, without the Unavailability Period IE) to inform the network that the MUSIM WTRU is (eg, currently) available.

[0178] In some instances, one of the networks may not support the unavailable period feature.

[0179] FIG. 6 shows an example of unavailability coordination across multiple networks when one of the networks does not support the unavailability feature for the MUSIM WTRU.

[0180] As shown in Figure 6, at 610, a MUSIM device (e.g., a WTRU) may have multiple (e.g., two) active USIM cards. The MUSIM WTRU may be registered (e.g., successfully registered) with two different networks, e.g., AMF-1 and AMF-2 / MME. In the example scenario shown in Figure 6, the second network may be an EPS that does not support unavailable features or a 5G network (e.g., AMF) that does not support unavailable features.

[0181] At 620, an event may occur in the WTRU that may cause the WTRU to become unavailable for a (e.g., specified) period of time. The WTRU (e.g., as a MUSIM device) may communicate sequentially with the network (e.g., 5GS). The MUSIM WTRU may allow for delays related to (de)registration procedures.

[0182] At 630, the MUSIM WTRU may select / choose a first network (e.g., AMF-1) to which to send a registration request message, for example, including an unavailable period IE and / or a start delay Δt. The start delay (Δt) may inform the network AMF-1 that the unavailable period may take into account a delay with the provided delay start period value. The actual period for which the WTRU may be unavailable may be the unavailable period + Δt. The delay start Δt may be calculated, for example, by taking into account the number of pending registration (de-registration) procedures that the MUSIM WTRU may perform (e.g., need to perform) to notify other networks about its unavailability. For example, as shown in FIG. 6, the other networks may not support the unavailable feature (e.g., EPS or 5GS feature not supported). The delay start may take into account the time period associated with (e.g., potentially taking to) de-register the WTRU from the other networks.

[0183] AMF-1 may respond with a registration accept message at 640. AMF-1 may (e.g., subsequently) release the RRC signaling connection.

[0184] At 650, the second network (AMF-2 / MME) may not support the functionality. The WTRU may trigger deregistration to the network, for example, by sending a deregistration request message (e.g., with a cause code as power down).

[0185] In some examples, the MUSIM WTRU and AMF-2 / MME may support MICO mode, and the MUSIM WTRU may initiate MICO mode, for example, instead of a de-registration procedure. The network may take the provided unavailable period into account while setting up the active time for MICO mode. The active time may not coincide with the unavailable period. The active time may start after the unavailable period. The network may (e.g., alternatively) set a periodic registration period (e.g., timer period) that is equal to or greater than the unavailable period, which may ensure that the WTRU can perform periodic registration when it becomes reachable again. The network may reconfigure the WTRU with desired parameters (e.g., new periodic registration period / timer value) during periodic registration.

[0186] In some examples, deregistration may be performed first. The MUSIM WTRU may deregister itself from a network that does not support the unavailability feature. The MUSIM WTRU may then (e.g., subsequently) perform an unavailability procedure with a second network that does support it.

[0187] At 660, the WTRU may (e.g., successfully) perform a device reboot upon an event that rendered the WTRU unavailable, such as a silent reset on the modem, a security patch update, an OS upgrade, a modem SW update, and / or a modem configuration change via OMA-DM.

[0188] At 670, the MUSIM WTRU may send a Registration Request message to AMF-2 (e.g., refrain from (e.g., do not include) the Unavailability Period IE) to notify the network that the MUSIM WTRU is (e.g., currently) available. There may be a sequence for coming out of unavailability. For example, the network last notified of an unavailable period may be the first network notified of availability. For example, as shown in FIG. 5, the AMF-2 / MME may be given higher priority than the AMF-1 for notifying of the WTRU's availability. The start delay provided to AMF-1 may take into account the delay associated with informing other networks about unavailability, for example, followed by availability and corresponding procedure timing.

[0189] At 680, the MUSIM WTRU may send a registration request message to the AMF-1 (e.g., without including the unavailable period IE), which may notify the network that the MUSIM WTRU is (e.g., currently) available.

[0190] 6, further example procedures are provided where one of the networks may not support the unavailable period feature. The MUSIM WTRU may implement one or more of the following:

[0191] As shown in FIG. 6, at 610-620, a MUSIM device (e.g., a WTRU) may have two active USIM cards. The MUSIM WTRU may successfully register with two different networks, e.g., AMF-1 and AMF-2 / MME. In an example scenario, the second network may be an EPS that does not support the unavailable feature, or a 5G network (e.g., AMF) that does not support the unavailable feature. An event may occur within the WTRU that may cause the WTRU to become unavailable for a certain period of time. The WTRU (as a MUSIM device) may communicate with 5GS (e.g., sequentially). The MUSIM WTRU may account for delays associated with the registration (deregistration) procedure.

[0192] As shown in FIG. 6, at 630 / 640, the MUSIM WTRU may choose a first network, e.g., AMF-1, and send a registration request message including, for example, an unavailable period IE and / or a start delay Δt. The start delay (Δt) may inform network AMF-1 that the unavailable period may account for a delay with the provided start delay period value. The actual period for which the WTRU may be unavailable may be calculated as the unavailable period + Δt. The start delay Δt may be calculated, for example, by taking into account the number of pending registration (de-registration) procedures that the MUSIM WTRU may perform (e.g., need to perform) to notify other networks about its unavailability. For example, as shown in FIG. 6, the other network does not support the unavailable feature (e.g., EPS or 5GS, where the feature is not supported). The delay start may take into account a period of time that may be taken to deregister the MUSIM WTRU from the other network. The AMF-1 may respond with a registration accept message. The AMF-1 may (e.g., subsequently) release the connection (e.g., RRC signaling connection).

[0193] 6, the second network (e.g., AMF-2 / MME) may not support the functionality at 650. The WTRU may trigger deregistration to the network by, for example, sending a deregistration request message with the reason code as power down.

[0194] In some examples, the MUSIM WTRU and the AMF-2 / MME may support MICO mode. The MUSIM WTRU may initiate MICO mode, for example, instead of a deregistration procedure. The network may take the provided unavailable period into account while setting up the active time for MICO mode. The active time does not have to coincide with the unavailable period. The active time may start after the unavailable period. The network may set the periodic registration period (e.g., timer period) to be equal to or greater than the unavailable period (e.g., alternatively), which may ensure that the WTRU can perform periodic registration when it becomes reachable again. The network may reconfigure the WTRU with desired parameters (e.g., new periodic registration period / timer values) during periodic registration.

[0195] In some examples, a deregistration step may be the first step. For example, a MUSIM WTRU may deregister itself from a network that does not support the unavailability feature. The WTRU may then (e.g., subsequently) perform an unavailability procedure with a second network that does support it.

[0196] As shown in FIG. 6, at 660 / 670 / 680, the WTRU may (e.g., successfully) perform an event that caused the WTRU to become unavailable, such as a silent reset in the modem, a security patch update, an OS upgrade, a modem SW update, and / or a device reboot upon a modem configuration change via OMA-DM. The MUSIM WTRU may send a Registration Request message to the AMF-2 (e.g., without including an Unavailability Period IE) to notify the network that the MUSIM WTRU is (e.g., currently) available. There may be a sequence for exiting unavailability. For example, the network last notified of an unavailable period may be the first network notified of availability. For example, as shown in FIG. 6, the AMF-2 / MME may be given a higher priority than the AMF-1 for notifying of the WTRU's availability. The delayed start provided to the AMF-1 may take into account the delay associated with notifying other networks of the unavailability, e.g., followed by availability and corresponding procedure timing. The MUSIM WTRU may send a registration request message (eg, not including the unavailable period IE) to the AMF-1 informing the network that the MUSIM WTRU is (eg, currently) available.

[0197] Unavailable period support may be provided to devices registered with multiple networks (e.g., both EPC and 5GC). The AMF may detect that the WTRU is capable of operating in S1 and N1 modes. For example, the AMF may receive an initial registration request from a WTRU that is already registered with the EPC, e.g., the AMF may receive an initial registration request from a WTRU whose EMM state is EMM-REGISTERED. The AMF may detect that the WTRU is registered with the EPS, for example, if the initial registration request includes a WTRU status information element with the N1 mode reg bit of the WTRU status information element set to a value of 1, which may indicate that the WTRU is in an EMM-REGISTERED state.

[0198] A WTRU capable of operating in S1 mode and N1 mode may detect that an event needs to be performed that may make the WTRU unavailable for a period of time. The WTRU may, for example, transmit (e.g., decide to transmit) the unavailable period to the AMF so that the AMF knows that the WTRU may be unreachable and / or that the WTRU is performing an event and that the WTRU's context should be maintained by the network (e.g., 5GS) while it is unavailable.

[0199] The AMF may send a notification to the MME (e.g., via the N26 interface) (e.g., based on the registration request), for example, if the AMF detects that the WTRU is capable of operating in S1 and N1 modes, has a common registration for 5G and EPS access, or is dual-registered, and in an example, the AMF receives a registration request from the WTRU that includes an unavailable period. The notification may indicate to the MME that the WTRU is becoming unavailable for a period of time. The notification may include an unavailable period or a periodic registration time, which the AMF may send to the WTRU in a registration response. The MME may determine (e.g., be aware of) the time for which the WTRU is expected to be unavailable, for example, based on the unavailable period or periodic registration time in the notification. The MME may perform one or more (e.g., any combination) of the following actions based on receiving the notification:

[0200] For example, the MME may (e.g., begin to) consider the WTRU unreachable and / or may reject (e.g., any) downlink data notifications associated with the WTRU, e.g., until at least the period indicated in the notification has elapsed. The MME may (e.g., further) adjust a period (timer, e.g., implicit detach timer) that may be associated with the WTRU, for example, by assigning the period (e.g., timer) a value that is at least the period indicated in the notification.

[0201] For example, the MME may respond to the AMF with an indication that the MME does not agree to maintaining the WTRU's context while the WTRU is unavailable, and / or the AMF may indicate to the WTRU that the WTRU may consider the WTRU deregistered from EPS and that the WTRU may transition from an EMM-registered state to an EMM-unregistered state. The response from the MME may (e.g., further) include a different (e.g., new) periodic tracking area update period (e.g., timer) value for the AMF to send to the WTRU.

[0202] The AMF may, for example, send a notification to the MME and, based on (e.g., in response to) receiving a response from the MME, send a registration response to the WTRU. The registration response may include, for example, one or more of the following indications: an indication that the unavailability period was shared with the MME and / or an indication that the WTRU can perform a tracking area update with the MME when the unavailability event may complete; an indication that the unavailability period was rejected by the MME and / or an indication that the WTRU considers itself deregistered from EPS, e.g., transitioning from an EMM-registered state to an EMM-unregistered state; and / or a value (e.g., a new value) that the WTRU can assign to its EPS periodic tracking area update period (e.g., timer) value.

[0203] The WTRU may complete the unavailable period. The WTRU may perform a registration area update procedure with the 5GS and a tracking area update procedure with the EPS (e.g., upon completion of the unavailable period). The tracking area update procedure may be performed, for example, if (e.g., only if) the WTRU has not transitioned to the EMM-DEREGISTERED state. The WTRU may perform an attach procedure with the EPS, for example, if the WTRU has transitioned to the EMM-DEREGISTERED state.

[0204] Advantages provided by unavailability support for devices registered with multiple networks (e.g., EPC and 5GC) may include, for example, one or more of the following: The EPS NAS signaling may refrain from changing (e.g., do not need to change). The EPS context may be maintained during the period when the WTRU is unavailable, and / or the WTRU may determine (e.g., become aware) if the MME is unable or unwilling to maintain the EPS context during the period when the WTRU is unavailable.

[0205] FIG. 7 shows an example of a dual registration scenario where the WTRU has 5GMM and EMM contexts.

[0206] As shown in FIG. 7, at 710, the WTRU may be 5GMM and EMM enabled. The WTRU may operate in single-registration mode. The WTRU may maintain a common registration (e.g., one) for 5GMM for 3GPP access and EMM. The WTRU may be successfully updated with both 5GMM and EMM (e.g., S1 mode registration status is EMM-registered and N1 mode registration status is 5GMM-registered). The WTRU may currently be camped on a 5G cell in idle mode. The 5GS or EPS may indicate support for interworking with N26 (e.g., in the last registration procedure) as part of the 5GS Network Capability Support IE or EPS Network Capability Support IE with the WK N26 bit set to "Interworking without N26 interface not supported."

[0207] At 720, an event may occur at the WTRU that may cause the WTRU to become unavailable for a (eg, specified) period of time.

[0208] The WTRU may trigger a registration request procedure to the AMF, at 730. The WTRU may provide an unavailable period IE to inform the network about the unavailable period of the WTRU.

[0209] At 740, the AMF may send a notification to the MME, for example, via the N26 interface. The notification may indicate to the MME that the WTRU is unavailable (e.g., is about to become unavailable) for a period of time. The notification may include an unavailable period or a periodic registration time, which the AMF may send to the WTRU in a registration response. The MME may know the time period for which the WTRU is expected to be unavailable, for example, based on the unavailable period or periodic registration time in the notification.

[0210] At 750, the MME may perform one or more (e.g., any combination) of the following actions based on receiving the notification from the AMF, for example, via the N26 interface:

[0211] For example, the MME may consider (e.g., begin to consider) the WTRU unreachable. The MME may, for example, reject (e.g., any) downlink data notifications that may be associated with the WTRU until at least the period indicated in the notification has elapsed. The MME may (e.g., further) adjust a period (e.g., a timer, e.g., an implicit detach timer) associated with the WTRU, for example, by assigning the period (e.g., assigning to the timer) a value that is at least the period indicated in the notification.

[0212] For example, the MME may respond to the AMF with an indication that the MME does not agree to maintaining the WTRU's context while the WTRU is unavailable, that the AMF indicates (e.g., can indicate) to the WTRU that the WTRU may consider the WTRU to be deregistered from EPS, and / or that the WTRU transitions (e.g., can transition) from an EMM-registered state to an EMM-unregistered state. The response from the MME may (e.g., further) include a (e.g., new) periodic tracking area update period (e.g., timer) value for the AMF to send to the WTRU.

[0213] At 760, the MME may respond to the notification from the AMF (e.g., via the N26 interface). The MME response may include, for example, information indicating whether the unavailability request from the WTRU was accepted / rejected by the MME and / or a periodic registration timer period, which may be relayed back to the WTRU via, for example, the AMF.

[0214] At 770, the AMF may provide a registration accept to the WTRU. The registration response may include one or more of the following indications: that the unavailable period was shared with the MME, that the WTRU may perform a tracking area update with the MME when the unavailability event completes and / or that the EMM state may be EMM-REGISTERED, that the unavailable period was rejected by the MME, that the WTRU may consider itself deregistered from EPS and / or that the WTRU may transition from an EMM-REGISTERED state to an EMM-DEREGISTERED state, and / or a new value that the WTRU may assign to its EPS periodic tracking area update timer value.

[0215] At 780, the WTRU may (e.g., successfully) perform an event that rendered the WTRU unavailable, such as a silent reset on the modem, a security patch update, an OS upgrade, a modem SW update, and / or a device reboot upon a modem configuration change via OMA-DM.

[0216] At 790, the WTRU exiting the unavailable period may perform a registration procedure with the AMF, for example, without including the unavailable period IE.

[0217] At 795, the WTRU may trigger an EMM Tracking Area Update procedure (e.g., if the EMM state is EMM-REGISTERED) or an EMM Attach procedure (e.g., if the EMM state is EMM-DEREGISTERED) (e.g., depending on the results and response the WTRU receives from the MME via AMF) to indicate to the MME that the unavailability period has ended and the WTRU is reachable again.

[0218] Analytics (e.g., NWDAF) may be supported for unavailable period functionality. The Namf_EventExposure service of the AMF may support an NF invoker (e.g., NWDAF) subscribing to an event (e.g., a WTRU unavailable event). The AMF may report WTRU unavailable information to the NF invoker when an event occurs. The WTRU unavailable information may include one or more of the following: a WTRU identifier, unavailable time information for (e.g., each) WTRU identifier, and / or an indication of expected actions, such as when each WTRU becomes available.

[0219] The AMF may provide the WTRU unavailability information if (e.g., when) the invoker NF subscribes to or invokes a Namf_EventExposure Subscribe service operation and, for example, provides an event ID such as (e.g., equal to) one or more of the following: registration-state-report, connectivity-state-report, reachability-report, UE-in-area-report, 5GS-user-state-report, frequent-mobility-registration-report, UE-access-behavior-trends, and / or UE-MM-transaction-report. Additionally and / or alternatively, an event ID (e.g., a new event ID) may be defined (e.g., WTRU unavailability information). The AMF may provide the WTRU unavailability information if (e.g., when) the invoker NF subscribes to or invokes a Namf_EventExposure Subscribe service operation and provides an event ID (e.g., equal to "WTRU unavailability information").

[0220] The unavailable time information provided by the AMF to the WTRU's invoker NF may, for example, be one or more of the following: equal to the unavailable period requested by the WTRU, set to an absolute time value based on the unavailable period requested by the WTRU, set to a value indicating how much time the AMF expects or needs to pass before the unavailable time expires, and / or equal to a periodic registration period (e.g., timer) value provided to the WTRU by the AMF.

[0221] The indication of the expected action when the WTRU becomes available may indicate that the WTRU will (e.g., is expected to) perform mobility registration if (e.g., when) the unavailable period ends, or may indicate that the WTRU will (e.g., is expected to) perform initial registration if (e.g., when) the unavailable period ends.

[0222] The AMF may indicate that the WTRU is (e.g., is expected to) perform mobility registration if (e.g., when) the unavailable period ends, e.g., if the WTRU provided the unavailable period in the mobility registration request.

[0223] The AMF may indicate that the WTRU will (e.g., is expected to) perform initial registration if (e.g., when) the unavailable period ends, e.g., if the WTRU provided the unavailable period in the deregistration request.

[0224] Providing an indication of expected actions when (e.g., when) a WTRU becomes available to a consumer NF (e.g., NWDAF) may be useful (e.g., important) because, for example, the expected actions may affect the amount of network activity (e.g., that may be required) when (e.g., when) the WTRU becomes available. For example, an initial registration procedure may result in more signaling than a mobility registration procedure. A consumer NF (e.g., NWDAF) may generate more accurate statistics and / or predictions if it is informed about what actions are expected.

[0225] 8 shows an example procedure by which an AMF provides unavailability information to an NWDAF. The NWDAF can use the unavailability information to generate more accurate statistics and / or predictions. The NWDAF can provide the statistics and / or predictions to consumer NFs, such as a PCF, an AMF, an NSSF, an NEF, an SMF, and / or an AF.

[0226] FIG. 8 shows an example of using unavailable information to generate improved data analysis.

[0227] As shown in FIG. 8, at 810, a consumer NF (e.g., a PCF, an AMF, an NSSF, an NEF, an SMF, or an AF) may invoke a service (e.g., an Nnwdaf_AnalytcisInfo service of an NWDAF). The type of service invocation may be a request or a subscription operation. The type of analysis requested may be, for example, one or more of the following: network slice instance load level statistics and predictions, network slice load level statistics and predictions, network function load level statistics and predictions, network load level statistics and predictions, WTRU communication statistics and predictions, and / or sixth WTRU abnormal behavior statistics and predictions.

[0228] At 820, the NWDAF may collect (e.g., begin collecting) data that may be necessary to determine the information requested at 810. As part of the process of collecting the necessary data, the NWDAF may invoke a Namf_EventExposure service operation of the AMF. The type of service call may be a request or a subscription operation. The event ID values ​​that may be provided by the NWDAF to the AMF in the operation may be one or more of the following: registration-status-report, connectivity-status-report, reachability-report, UE-in-area-report, 5GS-user-status-report, frequent-mobility-registration-report, UE-access-behavior-trend, UE-MM-transaction-report, and / or "WTRU-unavailability-info".

[0229] At 830, the AMF may receive a NAS registration request or a NAS deregistration request, which may include a period of unavailability. In an example, the operation at 830 may occur before the operation at 820.

[0230] At 840, the action may depend on the action at 820. For example, if the action at 820 is a request action, then at 840, the AMF may respond to the NWDAF (e.g., immediately) with unavailable time information and / or an indication of an expected action if (e.g., when) the WTRU becomes available. The response may provide information about one or more WTRUs. For example, if the action at 820 is a join action, then the NAS message at 830 may trigger the AMF to send a notification to the NWDAF at 840. The notification may include unavailable time information and / or an indication of an expected action when the WTRU becomes available. The notification may provide information to one or more WTRUs.

[0231] At 850, the NWDAF may derive the analysis (e.g., statistics or predictions) requested at 810. The analysis may be derived based on the unavailable time information and / or an indication of expected actions when the WTRU becomes available.

[0232] At 860, the NWDAF may send the analysis to the consumer NF in a notification or response service operation.

[0233] An unavailable period feature may be supported for a relay WTRU. A relay WTRU may enter an unavailable period.

[0234] In an example procedure, a relay WTRU may detect that it needs to enter a period during which the WTRU may be unavailable.

[0235] In some examples, the remote WTRU and the relay WTRU may be connected (eg, via a PC5 connection), and one or the other of the relay WTRU or the remote WTRU may become unavailable due to an unavailability event.

[0236] FIG. 9 shows an example of a relay WTRU entering an unavailable period.

[0237] As shown in FIG. 9, at 900, a relay WTRU and one or more remote WTRUs may be connected via a PC5 connection.

[0238] At 910, an unavailable event may be triggered in the relay WTRU, which may cause the relay WTRU to become unavailable for a (eg, specific) period of time.

[0239] At 920, the relay WTRU may enter an unavailable period, for example, by sending a registration request message to the AMF. The message may include the unavailable period IE and / or a list of remote WTRUs that may be connected to the relay WTRU, for example, via PC5. The list of remote WTRUs may inform the AMF about connected remote WTRUs that may no longer be available via the relay WTRU.

[0240] At 930, a list of remote WTRU information may be passed by the AMF to the AF for the connectivity loss event (eg, if the AF has registered for the connectivity loss event for each remote WTRU).

[0241] At 940, the AMF may respond with a registration acceptance and provide a list of remote WTRUs, and may check the status of receipt of the list, for example.

[0242] At 950, the relay WTRU may notify connected remote WTRUs about the relay WTRU's unavailability, eg, along with the duration of the unavailability.

[0243] At 960, the remote WTRU may recognize the relay WTRU's unavailability. The remote WTRU may use the relay WTRU's unavailability as a trigger to buffer UL activity, trigger selection to a different relay WTRU, establish a direct connection to the (e.g., 5G) network, and / or provide information regarding the period of unavailability to the network (e.g., via a (de)registration) procedure.

[0244] The remote WTRU may enter a period of unavailability.

[0245] FIG. 10 shows an example where a remote WTRU enters an unavailable period.

[0246] As shown in FIG. 10, at 1000, a relay WTRU and one or more remote WTRUs may be connected via a PC5 connection.

[0247] At 1010, an unavailable event may be triggered at the remote WTRU, which may cause the remote WTRU to become unavailable for a (eg, specified) period of time.

[0248] At 1020, the remote WTRU may trigger unavailability, eg, via the relay WTRU, such as by notifying the AMF / AF of the unavailability event via the relay WTRU.

[0249] At 1030, the remote WTRU may provide information regarding the unavailability to the relay WTRU (eg, via an unavailability notification message), which may include, for example, the duration of unavailability and / or the remote WTRU ID.

[0250] At 1040, the relay WTRU may update other connected WTRUs of the remote WTRU's unavailable status. The relay WTRU and / or other connected WTRUs (e.g., aware of the unavailability) may buffer DL notifications / data (e.g., while the remote WTRU is unavailable).

[0251] At 1050, the relay WTRU may notify other remote WTRUs about the remote WTRU's unavailability. The relay WTRU may provide the remote WTRU ID and / or the period of unavailability.

[0252] When the remote WTRU (e.g., becomes available again), it may indicate its availability using the same or similar procedure shown in Figure 10. For example, the remote WTRU may provide an unavailability notification message to the relay WTRU indicating that unavailability is not applicable. The remote WTRU may provide its remote WTRU ID. The relay WTRU may, in an example, broadcast availability information to other connected remote WTRUs.

[0253] When an unavailable period is requested, a description can be provided for expected WTRU availability. As described herein, the WTRU may use MICO mode. When using MICO mode, the WTRU may apply a strict periodic registration timer function.

[0254] The WTRU may send a registration request message to the network. The registration request message may include, for example, one or more of the following information elements: a request to use MICO mode, an indication of whether a strict periodic registration timer is supported by the WTRU, a requested active period (e.g., timer) value (e.g., T3324), and / or a requested registration period (e.g., timer) value (e.g., requested T3512 value).

[0255] The AMF may send a registration accept message to the WTRU. The registration accept message may include, for example, one or more of the following information elements: an indication to use MICO mode, an indication of whether a strict periodic registration timer is supported by the network, an active period (e.g., timer) value (e.g., T3324), and / or a registration period (e.g., timer) value (e.g., requested T3512 value).

[0256] As described herein, the AMF may configure a WTRU using MICO mode so that the WTRU is available at predictable times. The configuration may be implemented by the AMF selecting values ​​for T3324 and T3512 times and / or by the AMF determining whether to enable a strict periodic registration period (e.g., a timer).

[0257] The WTRU may send (e.g., determine) a registration request to the AMF. The registration request may include an unavailable period. The AMF may detect that the unavailable period overlaps with a period during which the WTRU, which may be using MICO mode, is expected to be available for downlink data. The WTRU may not be reachable for downlink data when the 5G system or application server expects the WTRU to be available, for example, if the WTRU becomes unreachable shortly after the registration accept message is sent and the WTRU remains unreachable for the unavailable period. The AMF may indicate in the registration accept message that the unavailable period is not accepted. The WTRU may (e.g., then) determine when it may be acceptable to request an unavailable period again.

[0258] The registration accept message may indicate that the strict periodic registration period (e.g., timer) feature is enabled and that the unavailable period was not accepted. The WTRU may wait (e.g., in response to the registration accept message) until the registration period (e.g., timer) expires before requesting an unavailable period again, send a registration request based on the registration period (e.g., timer) expiring, and enter the CM-IDLE state when the active period (e.g., timer) is not running. Waiting until these conditions are met may ensure that the WTRU's expected available time has ended (e.g., has just passed). This approach may be useful, for example, if the WTRU requests an unavailable period when the strict periodic registration time is about to expire.

[0259] The registration accept message may indicate that the strict periodic registration timer feature is not enabled and that the unavailable period was not accepted. The WTRU may wait to request an unavailable period again until the WTRU enters the CM-IDLE state (e.g., in response to the registration accept message) and the active period (e.g., timer) is no longer running. Waiting until these conditions are met may ensure that the WTRU's expected available time has ended (e.g., has just passed).

[0260] The WTRU may (e.g., alternatively) decide to request an unavailable period (e.g., again) if, for example, the WTRU receives a WTRU configuration update message or another registration accept message that disables the MICO mode or strict periodic registration period (e.g., timer) functionality.

[0261] The registration accept message may indicate that MICO mode is not enabled and that the unavailable period was not accepted. The WTRU may track (e.g., configure a timer) the duration of the unavailable period (e.g., in response to the registration accept message) and may refrain from (e.g., not request) the unavailable period again until the waiting period (e.g., timer) expires and the WTRU enters the CM-IDLE state.

[0262] The WTRU may (e.g., alternatively) decide (e.g., at any time) to send the unavailable period (e.g., again) in the deregistration request. An example procedure is illustrated in FIG.

[0263] Figure 11 shows an example of logic for WTRU handling of unavailable period rejection. Figure 11 shows an example of how expected WTRU availability is taken into account when an unavailable period is requested.

[0264] As shown in FIG. 11 , the WTRU may send a registration request that includes an unavailable period (e.g., when MICO mode and strict periodic registration period / timer function are enabled). The WTRU may receive a registration accept message, which may indicate that MICO mode is enabled, the strict periodic registration timer function is enabled, and that unavailable periods are not allowed. The WTRU may decide to send a second registration request that includes a second unavailable period, provided that the periodic registration period (e.g., timer) has expired, the WTRU has entered a CM-IDLE state, and an active period (e.g., timer) is not running. The WTRU may send the second registration request, which may include the second unavailable period.

[0265] As shown in FIG. 11 , the WTRU may send a registration request that includes an unavailable period (e.g., when MICO mode and the strict periodic registration timer function are not enabled). The WTRU may receive a registration accept message, which may indicate that MICO mode is enabled, that the strict periodic registration period (e.g., timer) function is not enabled, and that unavailable periods are not allowed. The WTRU may decide to send a second registration request that includes a second unavailable period, e.g., on the condition that the WTRU has entered a CM-IDLE state and an active period (e.g., timer) is not running. The WTRU may send the second registration request that includes the second unavailable period, e.g.,

[0266] As shown in FIG. 11, the WTRU may send a registration request that may include an unavailable period (e.g., when MICO mode is not enabled). The WTRU may receive a registration accept message that refrains from (e.g., does not indicate) that MICO mode is enabled and that unavailable periods are not allowed. The WTRU may configure a period with the unavailable period and start tracking (e.g., start a timer). The WTRU may decide to send a second registration request that includes a second unavailable period, provided that the period (e.g., timer) is not running and the WTRU has entered a CM-IDLE state. The WTRU may send the second registration request that includes the second unavailable period.

[0267] Although the above-described features and elements are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or may be used in various combinations with or without the other features and elements.

[0268] While the implementations described herein may consider 3GPP-specific protocols, it will be understood that the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, while the solutions described herein consider LTE, LTE-A, new radio (NR), or 5G-specific protocols, it will be understood that the solutions described herein are not limited to this scenario and may be applicable to other wireless systems.

[0269] The processes described above may be implemented in a computer program, software, and / or firmware embodied in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as Compact Disc (CD)-ROM disks and / or Digital Versatile Disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, a terminal, a base station, a Radio Network Controller (RNC), and / or any host computer.

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: sending a registration request to a network entity, the registration request indicating an unavailable period and indicating that the WTRU will not be able to receive DL data during the unavailable period; receiving a registration accept message, the registration accept message including an indication of whether the WTRU will notify the network entity upon expiration of the unavailable period; determining that the period of unavailability has ended; determining that the WTRU will notify the network entity at the end of the unavailable period; sending a registration update request to the network entity based on the determination that the unavailable period has ended and the determination that the WTRU will notify the network entity upon the end of the unavailable period, the registration update request indicating that the unavailable period has ended. A processor configured to 1. A WTRU comprising:

2. The processor: determining whether to preserve at least one of a mobility management (MM) context or a session management (SM) context for use after the unavailable period based on the unavailable event; 10. The WTRU of claim 1, further configured to:

3. The processor: determining that a backoff period associated with the network entity is active, and sending the registration request to the network entity based on the determination that the backoff period is active.

10. The WTRU of claim 1, further configured to:

4. The processor: determining a backoff duration, the unavailable period being equal to or greater than the backoff duration; 10. The WTRU of claim 1, further configured to:

5. 5. The WTRU of claim 4, wherein the registration request is sent during the backoff duration.

6. 10. The WTRU of claim 1, wherein the registration request is sent via NAS signaling.

7. 10. The WTRU of claim 1, wherein the registration update request includes an indication that the WTRU is available.

8. sending a registration request to a network entity, the registration request indicating a period of unavailability and indicating that a wireless transmit / receive unit (WTRU) will not be able to receive DL data during the period of unavailability; receiving a registration accept message, the registration accept message including an indication of whether the WTRU will notify the network entity upon expiration of the unavailable period; determining that the period of unavailability has ended; determining that the WTRU will notify the network entity at the end of the unavailable period; sending a registration update request to the network entity based on the determination that the unavailable period has ended and the determination that the WTRU will notify the network entity upon the end of the unavailable period, the registration update request indicating that the unavailable period has ended; A method comprising:

9. determining, based on the unavailability event, whether to preserve at least one of a mobility management (MM) context or a session management (SM) context for use after the unavailability period; The method of claim 8 further comprising:

10. determining that a back-off period associated with the network entity is active, wherein the registration request is sent to the network entity based on the determination that the back-off period is active. The method of claim 8 further comprising:

11. determining a backoff duration, the unavailable period being equal to or greater than the backoff duration; The method of claim 8 further comprising:

12. 12. The method of claim 11, wherein the registration request is sent during the backoff duration.

13. 9. The method of claim 8, wherein the registration request is sent via NAS signaling.

14. 10. The method of claim 8, wherein the registration update request includes an indication that the WTRU is available.

Images