Support during downtime related to congestion.

Description

1 / 86 Support during downtime related to congestion. Cross-reference to related orders

[001] The application claims the benefit of U.S. Provisional Application 63 / 457,504, filed April 6, 2023, the full content of which is incorporated herein by reference in its entirety. BACKGROUND

[002] Mobile communications using wireless communication continue to evolve. A fifth generation may be called 5G. A previous (legacy) generation of mobile communication may be, for example, the fourth generation (4G) of long-term evolution (LTE). SUMMARY

[003] Systems, methods and instrumentation are described herein related to supporting the downtime period while a wireless transmit / receive unit (WTRU) is registered in non-3GPP access (e.g., only in non-3GPP access).

[004] A device (e.g., a WTRU, network device, such as a device comprising 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), for example, via NAS signaling (non-access stratum). The registration request may include an initial duration (e.g., downtime duration associated with a WTRU). The device may receive a registration acceptance message. The registration acceptance message may indicate whether the device should inform the network entity when the WTRU is available (e.g., after a downtime event / duration has elapsed). The device may determine that a downtime event has ended. The WTRU may determine (e.g., with Petition 870250088649, dated 09 / 30 / 2025, p. 10 / 118 2 / 86 based on the registration acceptance message) the network entity must be informed that the WTRU is available. The device can send a registration update request. The registration update request can be sent based on the determination that the unavailability event has ended and the determination that the WTRU must inform the network entity when the WTRU is available. The registration update request can indicate that the WTRU is available.

[005] The device may receive an indication from the network, for example, indicating congestion. The device may receive an indication indicating a second duration (for example, a fallback duration associated with congestion). The second duration may be determined. The first duration may be greater than or equal to the second duration.

[006] The device may receive a registration request message (e.g., from a WTRU), which indicates an initial duration (e.g., downtime period associated with the WTRU). The registration request may be associated with downtime information. The device may determine whether the WTRU should send an update message (e.g., after the initial duration). The device may send a registration acceptance message (e.g., to the WTRU). The device may send the registration acceptance message, for example, based on the determination that the registration request is associated with downtime information. The registration acceptance message may indicate an acceptance associated with the registration request message. The registration acceptance message may indicate whether the WTRU should send an update message after the initial duration (e.g., based on the fact that the WTRU is associated with discontinuous coverage).The registration acceptance message may indicate that an update message should not be sent (e.g., after the first duration), for example, if WTRU is associated with discontinuous coverage. The device can determine if WTRU is available. Petition 870250088649, dated 09 / 30 / 2025, p. 11 / 118 3 / 86 after the first duration. The device can determine if an update message was received from the WTRU (e.g., before the first duration expires), for example, if the registration acceptance message indicates that the WTRU should send an update message after the first duration. The WTRU can be determined as available, for example, if the update message was received before the first duration expires. The device may send a rejection message, for example, associated with congestion. The rejection message may indicate a second duration. The first duration may be shorter than the second duration.

[007] The device may be a Multi-Universal Subscriber Identity Module (MUSIM) device. The device may send an initial registration request to a first network. The initial registration request may indicate enabling an unavailability period attribute with the second network. The registration request may indicate an initial unavailability duration associated with an unavailability period. The device may determine that an unavailability event has been triggered. The device may determine that the device (e.g., WTRU) will be unavailable for a period of time. The determination that the device will be unavailable during the time period may be based on the determination that the unavailability event has been triggered. The initial unavailability duration may be determined based on the determination that the device will be unavailable during the time period.The device may receive an initial registration response (e.g., from the first network). The initial registration response may be an initial registration acceptance message. The initial registration response may indicate an initial registration duration. The initial registration duration may be greater than or equal to the initial downtime duration. The device may determine a second downtime duration, for example, based on the initial downtime duration. The device may send a... Petition 870250088649, dated 09 / 30 / 2025, p. 12 / 118 4 / 86 Second registration request for a second network. The second registration request may indicate the activation of the downtime attribute with the second network. The second registration request may indicate the second downtime duration. The device may receive a second registration response from the second network. The second registration response may be a second registration acceptance message. The second registration response may indicate a second registration duration. The second registration duration may be greater than or equal to the second downtime duration. The second downtime duration may be greater than or equal to the first registration duration.

[008] A device can perform actions associated with dual registration. The device can receive a registration request (e.g., from a WTRU). The registration request can indicate information about the downtime period. The registration request can include an information element about the downtime period that can indicate information about the downtime period. The information about the downtime period can indicate a duration of downtime, for example, associated with the WTRU. The device can send a notification to an entity (e.g., mobility management entity). The notification can indicate that the WTRU will be unavailable for a period of time. The device can receive (e.g., from the entity) a notification response. The notification response can indicate that the entity accepted the WTRU downtime.The notification response may indicate the duration of the tracking area update time. The notification response may indicate that the entity has accepted the WTRU unavailability and a duration of the tracking area update time. The device may send a registration acceptance message (e.g., to the WTRU), for example, based on the notification response. The registration acceptance message may indicate the duration of the tracking area update time. A. Petition 870250088649, dated 09 / 30 / 2025, p. 13 / 118 5 / 86 registration acceptance message may instruct WTRU to perform a tracking area update with the entity, for example, based on the completion of an unavailability event.

[009] The device may perform actions associated with non-3GPP access. The device may receive a registration request (e.g., from a WTRU). The registration request may indicate a first duration. The first duration may be a period of unavailability. The registration request may include an information element, for example, indicating the first duration. The registration request may be sent via a non-3GPP access network. The device may send a registration response, for example, indicating that the first duration was accepted. The indication of acceptance of the first duration may indicate an accepted period of unavailability. The accepted period of unavailability may be equal to or greater than the requested first duration. The registration response may be sent based on receipt of the registration request via the non-3GPP access network and the registration request indicating the first duration.The device can determine that the WTRU is inaccessible, for example, based on the determination that a second duration has elapsed. The second duration may be associated with or equal to the duration of the unavailability period associated with the registration request. The device can send a connectivity loss report. The connectivity loss report may indicate an unavailability period. The connectivity loss report may indicate that the unavailability period is sent to a network exposure function. The device can receive a NAS message from the WTRU. The device can perform one or more of the following actions, for example, based on the received NAS message: interrupt a trace associated with the second duration; determine that the WTRU is accessible; determine that the WTRU is in a CONNECTED state; etc. The device can unregister the WTRU. Petition 870250088649, dated 09 / 30 / 2025, p. 14 / 118 6 / 86 based on the determination that the second duration has expired. BRIEF DESCRIPTION OF THE DRAWINGS

[010] Figure 1A is a system diagram that illustrates an exemplary communications system in which one or more disclosed modalities can be implemented.

[011] Figure 1B is a system diagram that illustrates an example of a wireless transmit and receive unit (WTRU) that can be used within the communications system illustrated in Figure 1A according to one embodiment.

[012] Figure 1C is a system diagram that illustrates an example of a radio access network (RAN) and an example of a core network (CN) that can be used within the communications system illustrated in Figure 1A according to a modality.

[013] Figure 1D is a system diagram that illustrates another example of RAN and another example of CN that can be used within the communications system illustrated in Figure 1A according to a modality.

[014] Figure 2 illustrates an example of an unavailability event while congestion control at the NAS level is active.

[015] Figure 3 illustrates an example when the downtime attribute is used by a WTRU registered via non-3GPP access.

[016] Figure 4 illustrates an example of unavailability coordination between networks.

[017] Figure 5 illustrates an example of unavailability coordination across multiple networks when multiple networks (e.g., both 5G networks) support an unavailability attribute.

[018] Figure 6 illustrates an example of unavailability coordination across multiple networks when one of the networks does not support an unavailability attribute of a WTRU MUSIM. Petition 870250088649, dated 09 / 30 / 2025, page 15 / 118 7 / 86

[019] Figure 7 illustrates an example of a dual record scenario where a WTRU has a 5GMM and EMM context.

[020] Figure 8 illustrates an example of using unavailability information to generate enhanced data analyses.

[021] Figure 9 illustrates an example of a relay WTRU entering a period of unavailability.

[022] Figure 10 illustrates an example of a remote WTRU entering a period of unavailability.

[023] Figure 11 illustrates an example of logic for handling WTRU of an unavailability period rejection. DETAILED DESCRIPTION

[024] Figure 1A is a diagram illustrating an exemplary communications system 100 in which one or more disclosed modalities can be implemented. The communications system 100 can be a multiple access system that provides content, such as voice, data, video, message exchange, broadcast, etc., to multiple wireless users. The communications system 100 can enable multiple wireless users to access this content through the sharing of system resources, including wireless bandwidth.For example, 100 communication systems may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tail single-word DFT spread OFDM (ZT UW DTS-s OFDM), single-word OFDM (UWOFDM), feature block filtered OFDM, filter bank multicarrier (FBMC), and the like.

[025] As shown in Figure 1A, the communications system 100 may include wireless transmit and receive units (WTRUs) 102a, 102b, 102c, Petition 870250088649, dated 09 / 30 / 2025, page 16 / 118 8 / 86 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110 and other networks 112, although it is appreciated that the disclosed embodiments encompass any number of WTRUs, base stations, networks and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or a “STA”, may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a mobile phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, an Internet access point or Mi-Fi device, an Internet of Things (IoT) device,A watch or other head-mounted display, wearable (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in industrial and / or automated process chain contexts), a consumer electronic device, a device operating on commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d may be referred to alternatively as a UE.

[026] Communication systems 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 interact with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110 and / or other networks 112. By way of example, base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, an eNode Petition 870250088649, dated 09 / 30 / 2025, p. 17 / 118 9 / 86 B Domestic, a gNB, a B NR Node, a site controller, an access point (AP), a wireless router, and the like. Although base stations 114a, 114b are each represented as a single element, it will be appreciated that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[027] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be called a cell (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service for a specific geographic area that may be relatively fixed or that may change over time. The cell may additionally be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors.Thus, in one embodiment, base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[028] Base stations 114a, 114b can communicate with one or more WTRUs 102a, 102b, 102c, 102d along an air interface 116, which can 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 can be established using any Petition 870250088649, dated 09 / 30 / 2025, p. 18 / 118 10 / 86 suitable radio access technology (RAT).

[029] More specifically, as noted above, communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and the like. For example, base station 114a in RAN 104 / 113 and WTRUs 102a, 102b, 102c 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 ​​UL Packet Access (HSUPA).

[030] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as 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).

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

[032] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c can implement LTE radio access and NR radio access together, for example, using dual connectivity (DC) principles. Thus, the air interface used by WTRUs 102a, 102b, 102c can be CHARACTERIZED by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB). Petition 870250088649, dated 09 / 30 / 2025, page 19 / 118 11 / 86

[033] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (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), GSM Evolution Enhanced Data Rate (EDGE), GSM EDGE (GERAN) and the like.

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

[035] RAN 104 / 113 may be in communication with 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 WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as different throughput requirements, latency requirements, Petition 870250088649, dated 09 / 30 / 2025, p. 20 / 118 12 / 86 error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be appreciated that RAN 104 / 113 and / or CN 106 / 115 may be in direct or indirect communication with other RANs employing the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to being connected to RAN 104 / 113, which may be using NR radio technology, CN 106 / 115 may also be communicating with another RAN (not shown) employing GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[036] CN 106 / 115 may also serve as a gateway for WTRUs 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110 and / or other networks 112. PSTN 108 may include circuit-switched telephone networks that provide simple traditional telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP) and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. Networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, 112 networks may include another CN connected to one or more RANs, which may employ the same RAT as RAN 104 / 113 or a different RAT.

[037] Some or all of the WTRUs 102a, 102b, 102c, 102d in communications system 100 may include multimode capabilities (for example, WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communication with different wireless networks over different wireless links). For example, WTRU Petition 870250088649, dated 09 / 30 / 2025, p. 21 / 118 13 / 86 Station 102c, shown in Figure 1A, can be configured to communicate with base station 114a, which may employ cellular-based radio technology, and with base station 114b, which may employ IEEE 802 radio technology.

[038] Figure 1B is a system diagram illustrating an example of a WTRU 102. As shown in Figure 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit and receive element 122, a speaker / microphone 124, a keyboard 126, a touchscreen / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chip set 136 and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any subcombination of the preceding elements, remaining consistent with an embodiment.

[039] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application-specific integrated circuits (ASICs), Field Programmable Gate Array (FPGA) circuits, any other type of integrated circuit (IC), a state machine, and the like. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functionality that allows WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting and receiving element 122.While Figure 1B depicts processor 118 and transceiver 120 as separate components, it will be appreciated that processor 118 and transceiver 120 can be integrated together in a single electronic package or chip.

[040] The 122 transmit and receive element can be configured to Petition 870250088649, dated 09 / 30 / 2025, page 22 / 118 14 / 86 transmit signals to, or receive signals from, a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, the transmitting and receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmitting and receiving element 122 may be a transmitter / detector configured to transmit and / or receive infrared, ultraviolet, or visible light signals, for example. In another embodiment, the transmitting and receiving element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmitting and receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[042] Transceiver 120 can be configured to modulate the signals that are to be transmitted by the transmit and receive element 122 and to demodulate the signals that are received by the transmit and receive element 122. As noted above, WTRU 102 can have multimode capabilities. Thus, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

[043] The WTRU 102 processor 118 can be coupled to, and can receive input data from, the speaker / microphone 124, keyboard 126 and / or the touch screen / pad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit). The processor 118 can also send user data to the speaker / microphone 124, the keyboard 126 Petition 870250088649, dated 09 / 30 / 2025, page 23 / 118 15 / 86 and / or the touchscreen / touchpad 128. Furthermore, the processor 118 can access information and store data in any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory card, a Secure Digital Memory Card (SD), and the like. In other embodiments, the processor 118 can access information and store data in memory that is not physically located in the WTRU 102, such as in a server or a home computer (not shown).

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

[045] Processor 118 may also be coupled to GPS chip set 136, which may be configured to provide location information (e.g., longitude and latitude) relative to the current location of WTRU 102. In addition to, or instead of, information from GPS chip set 136, WTRU 102 may receive location information via air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that WTRU 102 may acquire location information by any suitable location determination method, remaining consistent with a mode. Petition 870250088649, dated 09 / 30 / 2025, page 24 / 118 16 / 86

[046] The processor 118 may additionally be coupled with other peripherals 138, which may include one or more software and / or hardware modules that provide additional attributes, functionality and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photographs and / or video), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a handset, 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 and the like.Peripherals 138 may include one or more sensors, the sensors may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor; altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor and / or humidity sensor.

[047] The WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with particular subframes for UL (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit to substantially reduce and / or eliminate self-interference via hardware (e.g., an inductor) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous. Petition 870250088649, dated 09 / 30 / 2025, p. 25 / 118 17 / 86

[048] Figure 1C is a system diagram illustrating RAN 104 and CN 106 according to one mode. As noted above, RAN 104 can employ E-UTRA radio technology to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN 104 can also be in communication with CN 106.

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

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

[051] The CN 106 shown in Figure 1C may include a mobility management entity (MME) 162, a service gateway (SGW) 164, and a packet data network gateway (PDN) (or PGW) 166. Although each of the above elements is described as part of CN 106, it is important to note that any of these elements may be owned and / or operated by an entity other than the CN operator.

[052] MME 162 can be connected to each of the eNode-Bs 162a, 162b, 162c in RAN 104 via an S1 interface and can serve as a control node. For example, MME 162 can be responsible for authenticating users from WTRUs 102a, 102b, 102c, carrier activation / deactivation, and selecting a service gateway. Petition 870250088649, dated 09 / 30 / 2025, page 26 / 118 18 / 86 particular during an initial connection of WTRUs 102a, 102b, 102c and similar. MME 162 can provide a control plane function to switch between RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[053] SGW 164 can be connected to each of the eNodes Bs 160a, 160b, 160c in RAN 104 via the S1 interface. SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, 102c. SGW 164 can perform other functions such as anchoring user planes during handovers between eNodes B, triggering paging when DL data is available for WTRUs 102a, 102b, 102c, managing and storing contexts of WTRUs 102a, 102b, 102c and similar.

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

[055] CN 106 can facilitate communications with other networks. For example, CN 106 can provide WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as PSTN 108, to facilitate communications between WTRUs 102a, 102b, 102c and traditional fixed-line communication devices. For example, CN 106 can include, or communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108. In addition, CN 106 can provide WTRUs 102a, 102b, 102c with access to other 112 networks, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[056] Although the WTRU is described in Figures 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may use (e.g., temporarily or permanently) wired communication interfaces. Petition 870250088649, dated 09 / 30 / 2025, p. 27 / 118 19 / 86 with the communication network.

[057] In representative modalities, the other 112 network may be a WLAN.

[058] A WLAN in Basic Services Infrastructure Set (BSS) mode can have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or other type of wired / wireless network that carries inbound and / or outbound traffic from the BSS. Traffic to STAs originating outside the BSS can arrive via the AP and be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS can be sent to the AP to be delivered to the respective destinations. Traffic between STAs within the BSS can be sent via the AP, for example, where the originating STA can send traffic to the AP and the AP can deliver the traffic to the destination STA. Traffic between STAs within a BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between (e.g., directly between) the source and destination STAs with a Direct Link Establishment (DLS).In certain representative configurations, DLS may use either 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to here as an “ad-hoc” communication mode.

[059] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit a beacon on a fixed channel, such as a primary channel. The primary channel can have a fixed width (e.g., 20 MHz bandwidth) or a width defined dynamically via signaling. The primary channel can be the BSS operating channel and can be used by STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) Petition 870250088649, dated 09 / 30 / 2025, p. 28 / 118 20 / 86 can be implemented, for example, in 802.11 systems. For CSMA / CA, STAs (e.g., each STA), including APs, can sense the primary channel. If the channel is sensed and / or detected as occupied by a particular STA, that particular STA can back off. An STA (e.g., just one station) can transmit at any given time on a given BSS.

[060] High-throughput (HT) STAs can use a 40 MHz wide channel for communication, for example, via a combination of the 20 MHz primary channel with an adjacent or non-adjacent 20 MHz channel to form a 40 MHz wide channel.

[061] Very high throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, can be passed through a segment analyzer that can split the data into two continuous streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each continuous stream separately. Continuous streams can be mapped to the two 80 MHz channels, and the data can be transmitted by a STA transmitter.At the receiving STA, the operation described above for the 80+80 configuration can be reversed, and the combined data can be sent to the Medium Access Control (MAC).

[062] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The operating channel bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the Space spectrum. Petition 870250088649, dated 09 / 30 / 2025, page 29 / 118 21 / 86 Television White Wire (TVWS), and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support Meter Type Control / Machine Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities, including support for (e.g., support only for) certain and / or limited bandwidths. MTC devices may include a battery with a lifespan exceeding a certain limit (e.g., to maintain a very long battery life).

[063] WLAN systems, which 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 the primary channel. The primary channel can have a bandwidth equal to the highest common operational bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be defined and / or limited by an STA, among all STAs operating in a BSS, that supports the lowest bandwidth operating mode. In the 802.11ah example, the primary channel may have a 1 MHz bandwidth for STAs (e.g., MTC-type devices) that support (e.g., only support) a 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 Sense and / or Network Allocation Vector (NAV) settings may depend on the primary channel status.If the primary channel is busy, for example, due to an STA (which only supports a 1 MHz operating mode) transmitting to the AP, all available frequency bands can be considered occupied, even if most frequency bands remain idle and could be available.

[064] In the United States, the available frequency bands that can be used by 802.11ah are from 902 MHz to 928 MHz. In Korea, the bands are Petition 870250088649, dated 09 / 30 / 2025, p. 30 / 118 The available 22 / 86 frequencies are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is from 6 MHz to 26 MHz, depending on the country code.

[065] Figure 1D is a system diagram illustrating RAN 113 and CN 115 according to a modality. As noted above, RAN 113 can employ NR radio technology to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN 113 can also be in communication with CN 115.

[066] RAN 113 may include gNBs 180a, 180b, 180c, although it is possible that RAN 113 may include any number of gNBs while remaining consistent with a mode. gNBs 180a, 180b, 180c may each include one or more transceivers for communication with WTRUs 102a, 102b, 102c via air interface 116. In a mode, gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may use beamforming to transmit signals and / or receive signals from gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, WTRU 102a. In one embodiment, the gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, the gNB 180a can transmit multiple component carriers to WTRU 102a (not shown).A subset of these component carriers may be in unlicensed spectrum, while the remaining component carriers may be in licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement CoMP (Coordinated Multipoint) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[067] WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. By Petition 870250088649, dated 09 / 30 / 2025, p. 31 / 118 23 / 86 For example, the OFDM symbol spacing and / or the OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying lengths or scalable lengths (e.g., containing a variable number of OFDM symbols and / or lasting various absolute time lengths).

[068] gNBs 180a, 180b, 180c can be configured to communicate with WTRUs 102a, 102b, 102c in a standalone and / or non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c can use one or more gNBs 180a, 180b, 180c as a mobility docking point. In a standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in an unlicensed band. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate with / connect to gNBs 180a, 180b, and 180c, while also communicating with / connecting to another RAN, such as eNode-Bs 160a, 160b, and 160c.For example, WTRUs 102a, 102b, 102c can implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodes 160a, 160b, 160c substantially simultaneously. In the non-autonomous configuration, eNodes 160a, 160b, 160c can serve as a mobility anchor for WTRUs 102a, 102b, 102c, and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput to serve WTRUs 102a, 102b, 102c.

[069] Each of the gNBs 180a, 180b, 180c can be associated with a specific cell (not shown) and can be configured to handle decisions of Petition 870250088649, dated 09 / 30 / 2025, p. 32 / 118 24 / 86 radio resource management, handover decisions, user escalation in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, user plane data routing to User Plane Function (UPF) 184a, 184b, control plane information routing to Access and Mobility Management Function (AMF) 182a, 182b and similar. As shown in Figure 1D, gNBs 180a, 180b, 180c can communicate with each other via an Xn interface.

[070] The CN 115 shown in Figure 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. Although each of the above elements is described as part of the CN 115, it is important to note that any of these elements may be owned and / or operated by an entity other than the CN operator.

[071] The AMF 182a, 182b can be connected to one or more gNBs 180a, 180b, 180c in RAN 113 via an N2 interface and can serve as a control node. For example, the AMF 182a, 182b can 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 the log area, terminating NAS signaling, managing mobility, and the like. Network slicing can be used by AMF 182a, 182b to customize CN support for WTRUs 102a, 102b, 102c based on the types of services used by WTRUs 102a, 102b, 102c.For example, different network slices can be established for different use cases, such as services that rely on ultra-reliable low-latency access (URLLC), services that rely on enhanced massive mobile broadband (eMBB) access, services for machine-type communication (MTC) access, and / or similar services. AMF 162 can provide a control plane function to switch between RAN 113 and others. Petition 870250088649, dated 09 / 30 / 2025, page 33 / 118 25 / 86 RANs (not shown) that employ other radio technologies, such as LTE, ITEA, LTE-A Pro and / or non-3GPP access technologies, such as WiFi.

[072] SMF 183a, 183b can be connected to AMF 182a, 182b on CN 115 via an N11 interface. SMF 183a, 183b can also be connected to UPF 184a, 184b on CN 115 via an N4 interface. SMF 183a, 183b can select and control UPF 184a, 184b and configure traffic routing through UPF 184a, 184b. SMF 183a, 183b can perform other functions such as managing and allocating EU IP addresses, managing PDU sessions, controlling policy and QoS enforcement, providing downlink data notifications, and the like. A PDU session type can be IP-based, non-IP-based, Ethernet-based, and the like.

[073] UPF 184a, 184b can be connected to one or more gNBs 180a, 180b, 180c in RAN 113 via an N3 interface, which can provide WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between WTRUs 102a, 102b, 102c and IP-enabled devices. UPF 184, 184b can perform other functions such as packet routing and forwarding, user plane policy enforcement, support for multihomed PDU sessions, user plane QoS handling, downlink packet buffering, mobility tethering provision, and the like.

[074] CN 115 can facilitate communications with other networks. For example, CN 115 can include, or communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between CN 115 and PSTN 108. Additionally, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other 112 networks, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to a Network Petition 870250088649, dated 09 / 30 / 2025, p. 34 / 118 26 / 86 local Data Network (DN) 185a, 185b via UPF 184a, 184b via N3 interface to UPF 184a, 184b and an N6 interface between UPF 184a, 184b and DN 185a, 185b.

[075] In view of Figures 1A-1D and the corresponding description of Figures 1A-1D, one or more, or all, of the functions described herein with respect to one or more of the following: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b and / or any other devices described herein may be performed by one or more emulation devices (not shown). Emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, emulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

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

[077] One or more emulation devices may perform one or more functions, including all, without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in a test scenario in a test lab. Petition 870250088649, dated 09 / 30 / 2025, page 35 / 118 27 / 86 and / or an undeployed wired and / or wireless communication network (e.g., test) to implement the testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via an RF circuit array (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[078] The reference to a timer here may refer to the determination of a time or the determination of a period of time. The reference to the expiration of a timer here may refer to the determination that the time has elapsed or that the period of time has expired. The reference to a timer here may refer to a time, a period of time, time tracking, time period tracking, etc. The reference to a legacy technology or legacy handover may indicate a legacy technology, such as LTE compared to NR, or a legacy version of a technology, for example, an earlier version / release of a technology (e.g., earlier NR release) compared to a later version / release of the technology (e.g., later NR release). The reference to a specific timer here may be provided as an example of a timer.

[079] Systems, methods and instrumentation are described herein related to supporting the downtime period while a wireless transmit / receive unit (WTRU) is registered in non-3GPP access (e.g., only in non-3GPP access).

[080] A device (e.g., a WTRU, a network device, such as a device comprising 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), for example, via NAS signaling (non-access stratum). The registration request may include an initial duration (e.g., downtime associated with a Petition 870250088649, dated 09 / 30 / 2025, page 36 / 118 28 / 86 (WTRU). The device may receive a registration acceptance message. The registration acceptance message may indicate whether the device should inform the network entity when the WTRU is available (e.g., after the end of an unavailability event / duration). The device may determine that an unavailability event has ended. The WTRU may determine (e.g., based on the registration acceptance message) whether to inform 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 the determination that the unavailability event has ended and the determination that the WTRU should inform the network entity when the WTRU is available. The registration update request may indicate that the WTRU is available.

[081] The device may receive an indication from the network, for example, indicating congestion. The device may receive an indication indicating a second duration (for example, a fallback duration associated with congestion). The second duration may be determined. The first duration may be greater than or equal to the second duration.

[082] The device may receive a registration request message (e.g., from a WTRU), which indicates an initial duration (e.g., downtime period associated with the WTRU). The registration request may be associated with downtime information. The device may determine whether the WTRU should send an update message (e.g., after the initial duration). The device may send a registration acceptance message (e.g., to the WTRU). The device may send the registration acceptance message, for example, based on the determination that the registration request is associated with downtime information. The registration acceptance message may indicate an acceptance associated with the registration request message. The registration acceptance message may indicate whether the WTRU should send a Petition 870250088649, dated 09 / 30 / 2025, p. 37 / 118 29 / 86 update message after the first duration (e.g., based on the fact that WTRU is associated with discontinuous coverage). The registration acceptance message may indicate that an update message should not be sent (e.g., after the first duration), for example, if WTRU is associated with discontinuous coverage. The device can determine if WTRU is available after the first duration. The device can determine if an update message was received from WTRU (e.g., before the first duration expires), for example, if the registration acceptance message indicates that WTRU should send an update message after the first duration. WTRU can be determined as available, for example, if the update message was received before the first duration expires. The device may send a rejection message, for example, associated with congestion. The rejection message may indicate a second duration.The first duration may be shorter than the second duration.

[083] The device may be a Multi-Universal Subscriber Identity Module (MUSIM) device. The device may send an initial registration request to a first network. The initial registration request may indicate the activation of an unavailability period attribute with the second network. The registration request may indicate an initial unavailability duration associated with an unavailability period. The device may determine that an unavailability event has been triggered. The device may determine that the device (e.g., WTRU) will be unavailable for a period of time. The determination that the device will be unavailable during the time period may be based on the determination that the unavailability event has been triggered. The initial unavailability duration may be determined based on the determination that the device will be unavailable during the time period.The device may receive an initial registration response (for example, from the first). Petition 870250088649, dated 09 / 30 / 2025, page 38 / 118 30 / 86 network). The first registration response may be a first registration acceptance message. The first registration response may indicate a first registration duration. The first registration duration may be greater than or equal to the first downtime duration. The device may determine a second downtime duration, for example, based on the first downtime duration. The device may send a second registration request to a second network. The second registration request may indicate the activation of the downtime period attribute with the second network. The second registration request may indicate the second downtime duration. The device may receive a second registration response from the second network. The second registration response may be a second registration acceptance message. The second registration response may indicate a second registration duration.The second registration duration may be greater than or equal to the second downtime duration. The second downtime duration may be greater than or equal to the first registration duration.

[084] A device can perform actions associated with dual registration. The device can receive a registration request (e.g., from a WTRU). The registration request can indicate information about the downtime period. The registration request can include an information element about the downtime period that can indicate information about the downtime period. The information about the downtime period can indicate a duration of downtime, for example, associated with the WTRU. The device can send a notification to an entity (e.g., mobility management entity). The notification can indicate that the WTRU will be unavailable for a period of time. The device can receive (e.g., from the entity) a notification response. The notification response can indicate that the entity accepted the WTRU downtime.The notification response may indicate the duration of the tracking area update time. The notification response. Petition 870250088649, dated 09 / 30 / 2025, p. 39 / 118 31 / 86 may indicate that the entity has accepted the WTRU unavailability and a duration for updating the tracking area. The device may send a registration acceptance message (e.g., to the WTRU), for example, based on the notification response. The registration acceptance message may indicate the duration for updating the tracking area. The registration acceptance message may instruct the WTRU to perform a tracking area update with the entity, for example, based on the completion of an unavailability event.

[085] The device may perform actions associated with non-3GPP access. The device may receive a registration request (e.g., from a WTRU). The registration request may indicate a first duration. The first duration may be a period of unavailability. The registration request may include an information element, for example, indicating the first duration. The registration request may be sent via a non-3GPP access network. The device may send a registration response, for example, indicating that the first duration was accepted. The indication of acceptance of the first duration may indicate an accepted period of unavailability. The accepted period of unavailability may be equal to or greater than the requested first duration. The registration response may be sent based on receiving the registration request via the non-3GPP access network and the registration request indicating the first duration.The device can determine that the WTRU is inaccessible, for example, based on the determination that a duration of one second has elapsed. The second duration may be associated with, or equal to, the duration of the unavailability period associated with the registration request. The device can send a connectivity loss report. The connectivity loss report may indicate an unavailability period. The connectivity loss report may indicate that the unavailability period is sent to a network exposure function. Petition 870250088649, dated 09 / 30 / 2025, p. 40 / 118 32 / 86 The device may receive a NAS message from the WTRU. Based on the received NAS message, the device may perform one or more of the following actions: interrupt a trace associated with the second duration; determine that the WTRU is accessible; determine that the WTRU is in a CONNECTED state; etc. The device may deregister the WTRU based on the determination that the second duration has expired.

[086] Systems, methods and instrumentation are described here related to downtime support while a WTRU is registered in non-3GPP access (i.e., only in non-3GPP access).

[087] A device (for example, a network device, such as a device comprising an access and mobility function (AMF)) may (for example, 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 (for example, an information element (IE) of the duration of the unavailability period), for example, which may be sent over a non-3GPP access network. The device may (for example, based on receiving the registration request over a non-3GPP access network and / or based on the request, including the information element about the duration of the unavailability period) determine the start of tracking for a duration (for example, start a standby timer).The device can assign an initial value to the duration (e.g., standby timer), for example, which can be equal to the duration of the downtime period provided in the registration request. The device can (e.g., based on receiving the registration request via a non-3GPP access network and / or based on the request, including the downtime duration information element) determine whether to send a registration response, for example, which may include an indication that the downtime duration request was accepted and that the network... Petition 870250088649, dated 09 / 30 / 2025, page 41 / 118 33 / 86 The device can indicate acceptance of the downtime duration, for example, by sending an accepted downtime duration to a wireless transmit / receive unit (WTRU). The device can assign an accepted downtime duration that is equal to or greater than the requested downtime duration. The device can (for example, based on receiving the registration request via a non-3GPP access network and / or based on the request, including the downtime duration information element) determine that the WTRU is inaccessible and idle (e.g., a 5GMM-IDLE state). The device can (for example, based on the WTRU being inaccessible and idle (e.g., 5GMMIDLE state)) send an indication to a session management function (SMF) that the WTRU is inaccessible.The indication can be sent in response to a downlink data notification from the SMF. The device can trigger a connectivity loss event report (e.g., which may include a period of unavailability) regarding a Network Exposure Function (NEF), and / or the period of unavailability can be reported to the subscribed AF, for example, if there is a connectivity loss event subscription to the WTRU by an application function (AF). The device can receive an initial non-access stratum (NAS) message from the WTRU. The device can (e.g., based on receiving the initial NAS message from the NAS) determine to stop tracking the duration (e.g., stop the standby timer), consider the WTRU reachable, and in a connected state (e.g., a 5GMMCONNECTED state).The device may (for example, alternatively), based on the expiring duration (e.g., timeout), determine (e.g., implicitly) the cancellation of the WTRU registration.

[088] An example device might include a processor configured to perform one or more actions. For example, a device (e.g., Petition 870250088649, dated 09 / 30 / 2025, page 42 / 118 34 / 86 A network device (such as a device comprising an AMF) may receive a registration request from a wireless transmit / receive unit (WTRU). The registration request may contain unavailability information (e.g., an information element about the duration of the unavailability period). The registration request may be sent over a non-3GPP access network. The device may begin tracking a duration (e.g., start a timer). The device may send a registration response. The registration response may contain an indication that the unavailability period duration request was accepted. The device may determine that the WTRU is unreachable. The device may send a connectivity loss report.

[089] A duration value (e.g., timer) may be associated with or equal to a downtime duration associated with the registration request. The registration response may be sent based on receipt of the registration request via the non-3GPP access network and the registration request comprising the downtime duration information element. An indication of acceptance of the downtime duration request may indicate an accepted downtime duration. The accepted downtime duration may be equal to or greater than the requested downtime duration. The connectivity loss report may indicate a downtime period. The connectivity loss report indicating the downtime period may be sent to a network exposure function.The device (e.g., the processor) can be further configured to receive a NAS message from the WTRU and (e.g., based on receiving the NAS message) perform one or more of the following: stop tracking duration (e.g., stop the timer), determine if the WTRU is accessible, or determine if the WTRU is in a CONNECTED state. The device (e.g., the processor) can be further configured to... Petition 870250088649, dated 09 / 30 / 2025, p. 43 / 118 35 / 86 implicitly cancel the WTRU registration based on the timer expiration.

[090] Systems, methods and instrumentation are described here relating to mechanisms for providing a period of unavailability to a network. Some events, such as an operating system (OS) update, a silent reboot on a modem or modem software updates (e.g., also called binary updates) may be executed with more than two (e.g., three (3)) parties involved, e.g., the device, the operator and the application function.

[091] A WTRU performing a multi-party event may become unavailable (e.g., unable to interact with the 5G System), for example (e.g., on the order of minutes) while the event operations are performed. The unavailability of the WTRU without prior knowledge of the core network and / or application function may impact (e.g., critically) the operations of an application server, for example, if the application server depends on the availability of the WTRU during the period of unavailability (e.g., a period of time during which the WTRU is unavailable).

[092] Systems, methods, and instrumentation are described herein related to handling an unavailability period for one or more scenarios, such as when a rollback duration is active (e.g., the timer is running), if (e.g., when) a WTRU is registered on a network (e.g., 5GS) via (e.g., only) non-3GPP access, if (e.g., when) a Multi-Universal Subscriber Identity Module (MUSIM) device is registered on multiple networks with and without support for an unavailability attribute, if (e.g., when) a WTRU is registered on multiple networks (e.g., Evolved Packet System (EPS) and Fifth Generation System (5GS)), for analytics support (e.g., Network Data Analytics Function (NWDAF)) for the unavailability attribute, if (e.g., when) a remote WTRU and / or a WTRU Petition 870250088649, dated 09 / 30 / 2025, page 44 / 118 36 / 86 retransmission enters the unavailability period if (for example, when) a Cellular-only Initiated Connection Mode (MICO) and / or the Strictly Periodic Log Timer attribute is enabled, etc.

[093] An unavailability period may be a duration during which a WTRU is unavailable, for example, it cannot interact with a network (e.g., the 5G System). An unavailability period may be, for example, on the order of minutes. An unavailability period for a WTRU may be (e.g., expected to be) long enough for the WTRU to perform (e.g., requires) events such as one or more of the following: (a) silent modem reboot; (b) security patch updates; (c) operating system update; (d) modem software (SW) updates; and / or (e) device reboot following changes to modem settings (e.g., via Open Mobile Alliance Device Management (OMA-DM)).

[094] Continuous recovery of the WTRU context can be performed. Certain events, for example, an operating system update, a silent restart on the modem or modem software updates (e.g., also called binary updates) can be performed with multiple (e.g., three (3)) parties involved, e.g., the device, the operator and the application function.

[095] A WTRU can download a binary. The time the WTRU takes to perform the update is left to the WTRU implementation. Some WTRU implementations may use (e.g., fetch) user input. The WTRU may delay the execution of the event, for example, if a WTRU cannot perform it (e.g., because storage capacity or battery level is insufficient). The WTRU may become unavailable (e.g., it may not interact with the 5G System), for example, (e.g., on the order of minutes) if (e.g., when) such operations are performed. WTRUs may Petition 870250088649, dated 09 / 30 / 2025, p. 45 / 118 37 / 86 become unavailable without prior knowledge of the core network and / or the application function. WTRU unavailability can affect critical application server operations, for example, if the application server depends on WTRU availability during the downtime period (e.g., a period of time during which WTRU is unavailable).

[096] A network (e.g., the 5G System) may allow a WTRU to provide a period of unavailability (e.g., downtime duration) to the network, for example, upon registration or deregistration request. The WTRU may store its mobility management (MM) and session management (SM) contexts in the Universal Subscriber Identity Module (USIM) or in non-volatile memory so that it can reuse the MM and SM contexts after the WTRU's downtime period, for example, if an event is triggered on the WTRU that would render the WTRU unavailable for a certain period of time. The WTRU may trigger a mobility registration update procedure or a deregistration procedure and provide the duration of the downtime period to the network, for example, if the WTRU can store the WTRU contexts.The network (e.g., the Access and Mobility Function (AMF)) may take into account the Downtime Duration, for example, if (e.g., when) it determines a Periodic Log Update duration (e.g., Periodic Log Update timer value). The AMF may provide a Periodic Log Update time greater than or equal to the Downtime Duration, for example, to avoid interfering with the WTRU's handling of the event causing the downtime. Subsequently (e.g., when the event making the WTRU unavailable is completed in the WTRU, or the event is postponed to a future time or canceled in the WTRU), the WTRU may trigger the registration procedure to resume regular service. The WTRU may refrain from including (e.g., not include) the Downtime Duration in the message. Petition 870250088649, dated 09 / 30 / 2025, p. 46 / 118 38 / 86 Registration Request. Depending on the WTRU state, the registration procedure may be an initial registration procedure or a Mobility Registration update procedure.

[097] The AMF can provide a Strictly Periodic Registration duration indication (e.g., Strictly Periodic Registration timer indication) to the WTRU, for example, along with the Periodic Registration timer value. The Periodic Registration timer attribute can be applied, for example, if (e.g., when) the WTRU uses a MICO mode. The AMF can provide the indication to the WTRU based on the expected behavior of the WTRU. For example, the AMF may (e.g., want to) configure the WTRU to be available for downlink data (e.g., in CM-CONNECTED mode) every hour (e.g., at the right time) to receive downlink data. The Periodic Registration duration attribute (e.g., timer) can be useful, for example, if (e.g., when) the WTRU uses MICO Mode.The periodic registration duration attribute (e.g., timer) can be used to ensure that the WTRU is in CM-CONNECTED mode (e.g., at predictable times). For example, if the WTRU runs a strictly periodic registration timer for 4 hours and (e.g., always) applies a 10-minute active timer, then it can be known that the WTRU is available every 4 hours for 10 minutes. By enabling the Strictly Periodic Registration duration attribute (e.g., Timer), AMF can configure availability events (e.g., 10-minute availability events) to occur at predictable times.

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

[099] AMF can be an example of a network function (NF) from the Petition 870250088649, dated 09 / 30 / 2025, p. 47 / 118 39 / 86 which NWDAF can collect data. NWDAF can use the AMF's Namf_EventExposure service to obtain AMF data. NWDAF can provide a Nnwdaf_AnalyticsInfo service that can be used by network functions to obtain statistics and predictions from NWDAF. The Policy Control Function (PCF), the Access and Mobility Management Function (AMF), the Network Slice Selection Function (NSSF), the Network Exposure Function (NEF), the Session Management Function (SMF), and the Application Function (AF) are examples of network functions that can invoke or consume the Nnwdaf_AnalyticsInfo service.

[0100] The following items may include examples of information that can 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; WTRU Farm communication statistics and predictions; and Sixth WTRU abnormal behavior statistics and predictions.

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

[0102] An unavailability period can be determined in 5GS for a WTRU (e.g., a specific WTRU). The actions of the WTRU and / or the network can be based on a determined unavailability period. A WTRU and a network (e.g., 5GC) can coordinate the unavailability period and / or workflow at the architecture level of the unavailability attribute.

[0103] A WTRU can provide an indication of support for a Period of Unavailability, for example, in a Registration Request message (e.g., during a registration procedure). The AMF can indicate support for the Period of Unavailability, for example, in an Acceptance message. Petition 870250088649, dated 09 / 30 / 2025, page 48 / 118 40 / 86 Registration.

[0104] The WTRU can store its MM context in USIM or non-volatile memory so that the MM context can be reused (e.g., after the WTRU's downtime period), for example, if a WTRU and a network support a Downtime Period and an event is triggered on the WTRU that would make the WTRU unavailable for a certain period of time (e.g., for OS update or device reboot). The WTRU can trigger mobility registration or a deregistration procedure, including the downtime period, for example, if (e.g., when) the WTRU is ready to execute the event. The AMF can provide a Periodic Registration Update duration (e.g., timer) based on the downtime period indicated by the WTRU, for example, the AMF can provide a Periodic Registration Update time longer than the downtime period.The AMF can store information that the WTRU is unavailable in the context of the WTRU, for example, if the WTRU is not canceled. The AMF can consider the WTRU inaccessible until the unavailability period has passed or the WTRU enters the CM-CONNECTED state. While the WTRU is inaccessible, (e.g., all) high-latency communication solutions can be applied (e.g., if supported), such as extended data buffering, downlink data buffering status reporting, etc. If there is a Connectivity Loss event subscription for the WTRU by the AF, the AMF can trigger a Connectivity Loss event report, which may include an unavailability period relative to the NEF. The unavailability period can be reported to the respective subscribed AF.

[0105] A WTRU can (for example, choose) store the WTRU contexts (for example, MM and SM contexts), for example, if (for example, when) a WTRU is ready to execute an event (for example, for an update). Petition 870250088649, dated 09 / 30 / 2025, page 49 / 118 41 / 86 of the operating system or device reboot). The way WTRU stores context may depend on the WTRU implementation. WTRU may store some or all WTRU contexts in the USIM using USIM functionality.

[0106] The WTRU may trigger a registration procedure to resume regular service, for example, once the event that renders the WTRU unavailable on the WTRU is completed or the event is postponed to a future time or canceled on the WTRU (for example, due to insufficient storage capacity, insufficient battery level, or the event rendering the WTRU unavailable has been completed). The WTRU may refrain from including (e.g., not include) the Unavailability Period in the Registration Request message. The registration procedure may be an initial registration procedure or a mobility registration update procedure, for example, depending on the state the WTRU is in after the event.

[0107] Downtime support can be provided while pullback durations are active (e.g., timers are running). While non-access stratum (NAS) pullback durations (e.g., timers or other pullback timers) are running on the WTRU (e.g., T3346 / T3347 / T3396, other pullback timers), the NAS layer mobility management entity may refrain from triggering (e.g., not triggering or not being allowed to) triggering a mobility registration procedure towards the core network (e.g., excluding one or more exceptions such as paging / downlink notification (DL), high priority signaling UL, or emergency services). A WTRU (e.g., in this case) may refrain from sending (e.g., not sending) a registration request to the network with downtime duration.

[0108] The network may attempt to contact (e.g., contact without Petition 870250088649, dated 09 / 30 / 2025, p. 50 / 118 42 / 86 success) a WTRU for terminated mobile services while the rollback duration (e.g., timer) is running, for example, if a WTRU refrains from sending (e.g., does not send) a network downtime duration and performs actions that may cause the WTRU to become unavailable while the rollback duration (e.g., timer) is running. Attempting to contact the WTRU for terminated mobile services may fail.

[0109] One or more examples described here may indicate how a WTRU handles MM signaling when the MM backoff duration (e.g., timer) is running and the WTRU may (e.g., need to) execute an event that would make the WTRU unavailable.

[0110] Downtime support can be provided while the WTRU is registered for non-3GPP access and no other access (e.g., registered only for non-3GPP access). The WTRU can send an initial NAS message to establish the NAS N1 signaling connection with the AMF, for example, if the NAS layer of a WTRU receives a notification from lower layers that non-3GPP access is available. The NAS can (e.g., then) consider the WTRU to be in 5GMM-CONNECTED mode on non-3GPP access. The WTRU can (e.g., then) be accessible for cellular-terminated communication from the network. For example, the WTRU can receive a NAS notification message from the network indicating that downlink data is available to the WTRU. A WTRU in 5GMM-CONNECTED mode via non-3GPP access can (for example, usually) remain in 5GMM-CONNECTED mode unless the WTRU disconnects from the non-3GPP network.

[0111] The periodic registry update procedure can be avoided (i.e., it can not be run), for example, if (e.g., when) the WTRU is registered via non-3GPP access.

[0112] A WTRU registered via non-3GPP access may indicate a Petition 870250088649, dated 09 / 30 / 2025, p. 51 / 118 43 / 86 period of unavailability for the network, for example, so that the network and the WTRU can maintain the WTRU registration state and / or so that the network understands that the WTRU may not be accessible for communication terminated on mobile devices.

[0113] Support during the period of unavailability may be provided for MUSIM devices. One or more examples described herein may indicate how an unavailability attribute may be handled for MUSIM devices registered on two (2) or more different networks.

[0114] In some examples, multiple networks (e.g., both) may support the unavailability attribute. In some examples, both networks may be provided with an unavailability period duration (e.g., the same). In some examples, an unavailability duration may be determined based on a result from the first network. In some examples, at least one of the networks may not support the unavailability attribute.

[0115] A MUSIM WTRU can be registered on multiple networks. NAS signaling procedures can be performed (e.g., only) sequentially. There may be a delay element (e.g., which can be accounted for) when communicating with the network about the downtime period. Reporting downtime to networks sequentially can be taken into account when exiting downtime, for example, to ensure that networks are informed within the stipulated timeframes.

[0116] One or more examples described here may indicate how a WTRU MUSIM with a different configuration (for example, all networks support the unavailability attribute, or one or more networks do not support the unavailability attribute) may indicate a period of unavailability for the network(s), for example, so that the network(s) and the WTRU MUSIM can maintain the registration state of the WTRU MUSIM and / or so that the network understands that the WTRU is not accessible for cellular-terminated communication. Petition 870250088649, dated 09 / 30 / 2025, p. 52 / 118 44 / 86

[0117] Downtime support can be provided for devices registered on multiple networks (e.g., EPC and 5GC). A WTRU (e.g., capable of operating in S1 and N1 modes) can be registered on EPS and 5GS. A WTRU registered on EPS can be considered in S1 mode. A WTRU registered on 5GS can be considered in N1 mode. A dual-registered WTRU can be in S1 and N1 modes (e.g., simultaneously).

[0118] One of the multiple networks (e.g., EPS) may not support the negotiation of an unavailability period, for example, via the S1 NAS interface between the WTRU and the EPS mobility management entity (MME). One or more examples described herein may indicate how the EPS knows (e.g., determines) that it should refrain from deleting (e.g., not deleting) the WTRU context and / or knows (e.g., determines) that it should refrain from attempting to contact (e.g., not attempt to contact) the WTRU for terminated mobile communication if (e.g., when) the WTRU is performing the event that renders it temporarily unavailable.

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

[0120] There may be several scenarios to consider. First, a period of unavailability provided by a WTRU to the AMF may not be a common event. For example, a period of unavailability may occur (e.g., only) if (e.g., when) the WTRU is installing a software update. Second, multiple (e.g., many) WTRUs in an area may install Petition 870250088649, dated 09 / 30 / 2025, p. 53 / 118 45 / 86 a software update at the same time or at a similar time. Multiple WTRUs may become unavailable and available again at approximately the same time. Third, a period of unavailability provided by a WTRU may be a strong indication of when the WTRU may attempt to perform a network registration procedure (e.g., it may be predicted that the WTRU may attempt to register on the network within the period of unavailability).

[0121] The duration of downtime requested by WTRUs can have a strong influence on future events that may occur on the network. The durations of downtime requested by WTRUs can influence the accuracy of statistics and predictions provided by NWDAF for other network functions. NWDAF can obtain downtime durations and / or consider downtime durations when generating statistics and predictions (for example, using one or more attributes described here).

[0122] Support for the downtime attribute can be provided for relay WTRUs. One or more examples described here may indicate how to handle the scenario for relay WTRUs, the handling of the downtime event for the relay WTRU and remote WTRUs, and / or how coordination can be maintained between the connected relay WTRU and remote WTRUs.

[0123] A WTRU can be configured (e.g., via the network) to use a recording duration attribute (e.g., strictly periodic) (e.g., timer). As described above, a strictly periodic recording timer attribute can be configured so that a WTRU is in CMCONNECTED mode and available to receive downlink data at predictable times. This attribute can be useful for devices that use MICO mode and / or enter long periods of hibernation, e.g., to save power. The occasions when these devices (e.g., WTRUs) are available for data Petition 870250088649, dated 09 / 30 / 2025, page 54 / 118 46 / 86 downlinks can be very infrequent (for example, with intervals of hours or even days). If WTRU requests a period of unavailability that overlaps with the period in which WTRU is expected to be available for downlink data, this may cause WTRU to lose downlink data that may be sent from a server that anticipated that WTRU would be available at the expected time.

[0124] Multiple parties (e.g., three parties) may be involved in performing certain events (e.g., operations), such as an operating system update, a silent reboot on a modem, or modem software updates (e.g., also called binary updates). The multiple parties involved may include, for example, the device (e.g., WTRU), the operator, and the application function.

[0125] A WTRU may become unavailable (e.g., it may not interact with the 5G System), for example, on the order of minutes, whenever such operations are performed. WTRUs may become unavailable without prior knowledge of the core network and / or the application function. Unexpected unavailability of the WTRU may affect the operations (e.g., critical operations) of an application server, for example, if the application server depends on the availability of the WTRU during the period of unavailability (e.g., a period of time during which the WTRU is unavailable).

[0126] Systems, methods, and instruments are described here related to handling the downtime attribute for multiple scenarios, such as whether (e.g., when) a rollback duration (e.g., timer) might be running, whether (e.g., when) WTRU might be registered on a network (e.g., 5GS) via (e.g., only) non-3GPP access, whether (e.g., when) a MUSIM device might be registered on multiple networks with and without support for the downtime attribute, whether (e.g., when) WTRU is registered on multiple networks (e.g., EPS and 5GS), for analysis support (by Petition 870250088649, dated 09 / 30 / 2025, page 55 / 118 47 / 86 example, NWDAF) for the unavailability attribute, if (e.g., when) the remote WTRU and / or the relay WTRU enter an unavailability period, if (e.g., when) the MICO mode and / or the strictly periodic recording duration (e.g., timer) attribute is enabled, etc.

[0127] Support for downtime periods can be provided while wait durations (e.g., timers) are running. The AMF can, for example, upon detecting congestion in mobility management signaling (e.g., 5GMM), perform NAS-level congestion control (e.g., general). The WTRU (e.g., under 5GMM signaling congestion conditions) can refrain from sending (e.g., not sending, not being allowed to send) a mobility log update message, for example, except for one or more scenarios, such as emergency and / or high-priority services.

[0128] AMF can (e.g., if / when NAS-level general congestion control is active) reject a NAS message and include a value for the mobility management (MM) delay duration (e.g., timer, e.g., T3346) in the rejection messages. WTRU can start tracking a duration (e.g., the timer, e.g., T3346) with the value received in the MM rejection messages (e.g., 5GMM). WTRU can refrain from (e.g., be prevented from) sending one or more (e.g., certain) NAS messages (e.g., a mobility log update), e.g., if (e.g., when) the delay duration (e.g., timer) is running. WTRU can respond to network-initiated signaling (e.g., a page that was triggered by downlink data), e.g., if (e.g., when) the delay duration (e.g., timer) is running.

[0129] A WTRU can inform the network about the start of a period of Petition 870250088649, dated 09 / 30 / 2025, p. 56 / 118 48 / 86 unavailability, for example, based on (e.g., after) detection of an event in the WTRU that may (e.g., would make) the WTRU unavailable for a (e.g., certain) period of time. The WTRU may inform the network about the start of the unavailability period via the REGISTRATION REQUEST message (e.g., including the unavailability period IE), for example, if the WTRU is able to save the MM context (e.g., 5GMM) and the SM context (e.g., 5GSM). However, the WTRU may refrain from informing (e.g., not informing, not being able to inform) the network (e.g., AMF) about the WTRU unavailability in one or more scenarios. For example, the WTRU may refrain from triggering (e.g., not being allowed to trigger) the UL NAS signaling to send the mobility registration update if (e.g., when) congestion control at the NAS level is active.

[0130] A WTRU may refrain from performing (i.e., not perform) an action that would render the WTRU unavailable without informing the network. The network may initiate signaling to the WTRU and find that the WTRU does not respond, for example, if the network is not informed. The WTRU may not respond, for example, because it may be performing an action that renders it unavailable (e.g., a software update).

[0131] A WTRU may (for example, be permitted to) send a mobility log update to the network, for example, if (for example, even when) the rollback duration (e.g., timer) is running. The WTRU may generate NAS signaling to inform the network about the downtime period and, again, to inform the network that the WTRU is available again. The signaling may be generated while the rollback duration (e.g., timer) is running. In some examples, multiple WTRUs in the same area may be performing the same software update. The downtime and availability signaling of multiple WTRUs may trigger a Petition 870250088649, dated 09 / 30 / 2025, p. 57 / 118 49 / 86 significant amount of NAS signaling being handled by the network, for example, even during a congestion situation.

[0132] A WTRU may (for example, be allowed to) send a REGISTRATION REQUEST message (for example, including the downtime period IE) while congestion control at the NAS level is active (for example, while a duration or timer is running, for example, while T3346 is running). The WTRU may (for example, be configured to) prevent or avoid (for example, restrict itself to ensuring that the REGISTRATION REQUEST message does not include) follow-up requests, uplink data status IE, and / or allowed PDU session status IE. The WTRU may (for example, also) be configured (for example, restricted) to (for example, only) request a Downtime Period Duration that is greater than or equal to the amount of time remaining in the NAS rollback duration (for example, timer, for example, T3346).

[0133] The AMF (e.g., based on receiving a Registration Request that includes a Periodic Downtime Request while the hold timer is running) may respond to the WTRU with information including, for example, one or more of the following (e.g., indicated in a Registration Acceptance message): (i) an indication that the Registration and Downtime Period has been Accepted; (ii) an indication that the previously provided backoff duration (e.g., timer, e.g., T3346) may continue to run and not be reset, e.g., indicating to the WTRU that the WTRU may still consider NAS-level congestion control as active; (iii) a new backoff duration value (e.g., timer) (e.g., T3346) to indicate to the WTRU that the WTRU may still consider NAS-level congestion control as active;(iv) an indication that WTRU can inform AMF when WTRU is available again, for example, even; Petition 870250088649, dated 09 / 30 / 2025, p. 58 / 118 50 / 86 that the recoil duration (e.g., timer) is rotating (e.g., T3346); and / or (v) an indication that the WTRU may NOT inform the AMF when the WTRU is available again if the recoil duration (e.g., timer) is rotating (e.g., T3346).

[0134] The indications from the previous example in a Registration Acceptance message can give the AMF control over whether the WTRU generates additional signaling when the WTRU becomes available again. Figure 2 shows an exemplary procedure for the WTRU to signal a period of unavailability and for the AMF (e.g., still) to limit the amount of NAS signaling.

[0135] Figure 2 illustrates an example of an unavailability event while congestion control at the NAS level may be active. As shown in Figure 2, at 210, congestion control at the NAS level may be active for the WTRU, for example, because the WTRU received a rejection response from AMF. The rejection response may have included a duration (e.g., timer, for example, timer T3346). Congestion control at the NAS level may be active on the WTRU. The duration (e.g., or other durations) may be running (e.g., T3346 and / or other rollback timer(s) may be running). The WTRU may refrain from triggering (e.g., not triggering, may not be allowed to trigger) NAS-level signaling, for example, except in cases intended for high-priority access, emergency services, and / or the WTRU is responding to network-side paging.

[0136] In 220 in Figure 2, the WTRU can detect the need to execute an event in the WTRU that may make the WTRU unavailable for a certain period of time. The WTRU can (for example, also) detect the amount of time the WTRU is expected to be available. For example, the time value may be provided by an application or by the Operating System.

[0137] In 230 in Figure 2, the WTRU can trigger the procedure of Petition 870250088649, dated 09 / 30 / 2025, p. 59 / 118 51 / 86 REQUEST FOR REGISTRATION with AMF. The WTRU can provide the downtime period, i.e., to inform the network about the duration of the WTRU's unavailability. The WTRU (e.g., if the retraction timer is running on the WTRU) can (e.g., determine) set the downtime period to the duration that was determined in 220, for example, if the duration is greater than the amount of time remaining in the retraction duration (e.g., a timer such as T3346). The WTRU can otherwise (e.g., determine) request a time greater than or equal to the time remaining in the retraction duration (e.g., timer).

[0138] In 240 in Figure 2, the AMF can take into account the presence of the unavailability period IE, refrain from rejecting (e.g., not rejecting) the registration request and / or respond with the REGISTRATION ACCEPTANCE message. The AMF can (e.g., also) use the REGISTRATION ACCEPTANCE message to indicate that the previously provided backoff duration (e.g., timer, e.g., T3346) can continue to run and not be reset, to provide a new backoff duration value (e.g., timer) (e.g., T3346) to indicate to the WTRU that the WTRU can still consider NAS-level congestion control as active and / or to provide an indication of whether the WTRU can inform the AMF when the WTRU becomes available again, e.g., even if the backoff duration (e.g., timer) is running.

[0139] In 250 in Figure 2, the WTRU can (for example, successfully) execute the event that made it unavailable, for example, silent reboot on the modem, security patch updates, OS update, modem SW updates and / or device reboot upon changes to modem settings via OMA-DM.

[0140] In 260 in Figure 2, tA WTRU can inform AMF about the execution (e.g., successful) of the WTRU of the unavailability event, for example, Petition 870250088649, dated 09 / 30 / 2025, page 60 / 118 52 / 86 if the rollback duration (e.g., timer) is no longer running or if AMF indicated in 240 that WTRU can inform AMF when WTRU is available again (e.g., even if the rollback timer is running). WTRU can inform AMF about the (e.g., successful) execution of the WTRU unavailability event, e.g., by sending the REGISTRATION REQUEST message, e.g., by refraining from including (e.g., not including) the unavailability period IE. The WTRU can wait until the rollback duration (e.g., timer) expires and then inform the AMF about the WTRU's execution (e.g., successful) of the unavailability event, for example, if the rollback duration (e.g., timer) is running or if the AMF indicated in 240 that the WTRU can refrain from informing (e.g., not inform) the AMF when the WTRU is available again if the rollback duration (e.g., timer) is running.The WTRU can wait until the rollback duration (e.g., timer) expires and then inform the AMF about the (e.g., successful) execution of the WTRU of the unavailability event, for example, by sending the REGISTRATION REQUEST message, for example, by refraining from including (e.g., not including) the IE unavailability period.

[0141] With reference to Figure 2, an additional example procedure is provided for the case where a backoff duration (e.g., timer) is running. A WTRU can perform one or more of the following.

[0142] As shown in Figure 2, in 210, the WTRU may receive a NAS rejection message indicating that the WTRU is restricted due to a network congestion situation. The NAS rejection message may include a duration (e.g., timer value) indicating how long the WTRU can consider the congestion situation applicable and / or how long the restriction is in effect. The WTRU may begin tracking a rollback duration. Petition 870250088649, dated 09 / 30 / 2025, p. 61 / 118 53 / 86 (for example, a rewind timer), for example, based on receiving the duration (for example, timer value).

[0143] As shown in Figure 2, in 220, the WTRU can detect the need to execute an event on the WTRU that may make the WTRU unavailable for a (for example, certain) period of time. The WTRU can detect the amount of time the WTRU is expected to be available.

[0144] As shown in Figure 2, in 230, the WTRU can send a registration request to the network. The registration request can include a WTRU downtime duration. The WTRU downtime duration can be defined as a value greater than or equal to the backoff duration (e.g., timer value), for example, based on the running backoff duration (e.g., timer) and / or based on the backoff duration (e.g., timer) value being greater than the amount of time the WTRU is expected to be available.

[0145] As shown in Figure 2, in 240, the WTRU may receive a network registration acceptance message. The registration acceptance message may include an indication that the previously provided backoff duration (e.g., timer, e.g., T3346) may continue running and not be reset, which may cause, or trigger, the WTRU to continue applying congestion control at the NAS level. The registration acceptance message may include a different (e.g., new) backoff duration (e.g., timer) value (e.g., T3346) to indicate to the WTRU that the WTRU may still consider NAS-level congestion control as active, which may cause, or trigger, the WTRU to continue applying congestion control at the NAS level and / or assign a different (e.g., new) value to the backoff duration (e.g., timer).The registration acceptance message may include an indication that WTRU can inform AMF when... Petition 870250088649, dated 09 / 30 / 2025, p. 62 / 118 54 / 86 If WTRU becomes available again, for example, even if the backoff duration (e.g., timer) is running (e.g., T3346), this may trigger WTRU to send a log update request to the network when the unavailability event ends. The log update request may refrain from including (e.g., not include) an unavailability period duration. The log acceptance message may include an indication that WTRU may refrain from informing (e.g., not inform) AMF when WTRU becomes available again if the backoff duration (e.g., timer) is running (e.g., T3346), which may cause, or trigger, WTRU not to send a log update request to the network when the unavailability event ends while the backoff duration (e.g., timer) is still running.WTRU can (for example, determine) send a log update request to the network when the rollback duration (e.g., timer) expires. The log update request can choose not to include (e.g., not include) a downtime period duration.

[0146] Downtime support can be provided while the WTRU is registered (e.g., only) on non-3GPP access. A network (e.g., a 5G system) can enable (e.g., indicate to) a WTRU to send a Registration Request to the AMF via non-3GPP access. The registration request can include downtime information (e.g., a Downtime Duration Information Element (EI)).

[0147] An AMF can (for example, be triggered to) perform one or more actions based on (for example, after) receiving unavailability information (for example, a duration of unavailability information element) from a WTRU registered on a non-3GPP access. In the examples, the AMF can perform one or more of the following actions. Petition 870250088649, dated 09 / 30 / 2025, page 63 / 118 55 / 86

[0148] The AMF can send a Log Response to the WTRU, for example, to indicate that the downtime duration request has been accepted and that the network now considers the WTRU to be in an idle state (e.g., state 5GMMIDLE). The AMF can indicate acceptance of the downtime duration, for example, by sending an Accepted Downtime Duration to the WTRU. The AMF can assign an Accepted Downtime Duration that is equal to or greater than the requested Downtime Duration.

[0149] AMF may consider that WTRU is in an idle state (e.g., 5GMM-IDLE state).

[0150] AMF can start tracking a duration (e.g., a standby timer). AMF can assign the duration (e.g., standby timer) an initial value, which can be equal to the duration of the downtime period provided in the Registration Request.

[0151] AMF may consider the WTRU inaccessible until it 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.

[0152] AMF may consider that the WTRU is unregistered (e.g., in the 5GMM-REGISTRATION CANCELED state), for example, if the duration (e.g., hold timer) expires before AMF receives an initial NAS message from the WTRU.

[0153] Figure 3 illustrates an example of when the downtime attribute is used by a WTRU registered via non-3GPP access. For example, Figure 3 shows support for a downtime attribute when a WTRU can be registered on a network (e.g., 5GCN) via (e.g., only) non-3GPP access.

[0154] As shown in Figure 3, in 310, the WTRU can be registered Petition 870250088649, dated 09 / 30 / 2025, page 64 / 118 56 / 86 on the 5GCN via a non-3GPP access point (e.g., only). The non-3GPP access point can be trusted or untrusted.

[0155] In 320, an event may occur in the WTRU that may make the WTRU unavailable for a (for example, certain) period of time.

[0156] In 330, WTRU can send a registration request to AMF, for example, via the non-3GPP access network. The registration request can include unavailability information (e.g., information element about the duration of the unavailability period).

[0157] In 340, AMF can start tracking a duration (e.g., a standby timer). AMF can initially set the duration value (e.g., standby timer) to be equal to or greater than the duration of the downtime period.

[0158] In 350, the AMF can send a Registration Acceptance Message to the WTRU. The Registration Acceptance Message can indicate acceptance of the requested downtime duration and / or can provide the WTRU with a downtime duration value that the WTRU can use. The AMF can (for example, now) consider the WTRU to be in an idle state (e.g., 5GMM-IDLE state) and inaccessible. The AMF can indicate to the SMF that the WTRU is inaccessible, for example, if a downlink data notification can be received from an SMF. The AMF can trigger a Connectivity Loss event report to the NEF, for example, if there is a Connectivity Loss event subscription for the WTRU by the AF. The Connectivity Loss event report can include a downtime period. The downtime period can (for example, also) be reported to the subscribed AF.

[0159] In 360, WTRU may (for example, successfully execute) the event that made WTRU unavailable, for example, silent reboot on the modem, security patch updates, OS update, SW updates from Petition 870250088649, dated 09 / 30 / 2025, p. 65 / 118 57 / 86 modem and / or device restart due to changes in modem settings via OMA-DM.

[0160] In 370, the WTRU can send an initial NAS message to the network, for example, to indicate to the AMF that the WTRU is now accessible.

[0161] At 380, the AMF may stop tracking the duration (e.g., stop the wait timer), for example, based on (e.g., after) 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 accessible. 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.

[0162] Support during downtime can be provided for MUSIM devices. Downtime coordination can be provided between networks.

[0163] A WTRU can be registered on multiple networks (e.g., two (2)). The WTRU can send a registration request to the first network (e.g., between multiple networks). The registration request can include a downtime duration. The first network can respond with a registration acceptance message and / or a periodic registration duration (e.g., timer), which can be greater than or equal to the requested downtime duration. The WTRU can (e.g., then) send a registration request to a second network. The WTRU can include a second downtime duration in the request to the second network. The WTRU can (e.g., choose) set the second downtime duration to a value equal to or greater than the periodic registration timer that was received from the first network.This approach can help ensure that the second network refrains from indicating (e.g., does not indicate) to WTRU that WTRU can re-register before (e.g., much before) the time associated with (e.g., requested by) the first network. Petition 870250088649, dated 09 / 30 / 2025, p. 66 / 118 58 / 86 network.

[0164] Figure 4 shows an example of how a WTRU can use the downtime attribute in a scenario where the MUSIM attribute is also used.

[0165] Figure 4 illustrates an exemplary procedure for coordinating unavailability between networks.

[0166] As shown in Figure 4, in 410, the MUSIM WTRU can be registered on multiple (e.g., two (2)) networks.

[0167] In 420, the WTRU may detect that it needs to execute an event that may be associated with WTRU unavailability (for example, requiring the WTRU to be unavailable) for a period of time. The WTRU may determine an initial duration of the unavailability period.

[0168] In 430, WTRU can send a registration request to the first network. The registration request can include the duration of the first downtime period.

[0169] In 440, the AMF of the first network can send a Log Response to the WTRU. The Log Response can include a periodic log duration (e.g., timer), which can be greater than or equal to the duration of the first downtime period.

[0170] In 450, WTRU may determine a second downtime period. WTRU may adjust the second downtime period duration to a value equal to or greater than the periodic registration timer received from the first network. Adjusting the second downtime period duration in this way may ensure that WTRU has sufficient time to contact the multiple networks (e.g., both) at the end of the downtime period.

[0171] In 460, WTRU can send a registration request to the Petition 870250088649, dated 09 / 30 / 2025, page 67 / 118 59 / 86 second network. The registration request may include the second downtime period.

[0172] In 470, the AMF of the second network can send a Log Response to the WTRU. The Log Response can include a second periodic log duration (e.g., timer), which can be greater than or equal to the second downtime period duration.

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

[0174] Figure 5 illustrates an example of unavailability coordination across multiple networks when multiple networks (e.g., both 5G networks) support an unavailability attribute.

[0175] As shown in Figure 5, in 510, a MUSIM device with two (2) active USIM cards can be successfully registered on two (2) different networks (e.g., 5G) (e.g., AMF-1 and AMF-2) that support the unavailability attribute.

[0176] In 520, an event may occur in the WTRU that may render the WTRU unavailable for a (e.g., certain) period of time. The WTRU (e.g., as a MUSIM device) may communicate with the network (e.g., 5GS) sequentially. The MUSIM WTRU may take into account delays with respect to the deregistration (cancellation) procedure.

[0177] At 5:30 am, MUSIM WTRU can select / choose the first network, Petition 870250088649, dated 09 / 30 / 2025, p. 68 / 118 60 / 86 for example, AMF-1. A WTRU can send a REGISTRATION REQUEST message to AMF-1. The message can include the downtime duration IE, for example, along with a start delay (e.g., Δt). The Start Delay (Δt) can inform the AMF-1 network that the downtime period may account for the delay with the provided start delay duration value and / or the actual duration for which the WTRU would be unavailable, e.g., downtime duration + Δt. The Start Delay can be calculated taking into account the number of pending (deregistration) procedures that a WTRU MUSIM may (e.g., need to) perform to inform other networks about the downtime.For example, Δt can be calculated as Δt = (N=1) x (Time requested (e.g., required) for (cancellation of) registration informing about the unavailability for the AMF-2 registration to inform the network (AMF-2) about the end of the unavailability period), where N can be the number of (cancellations of) registrations that MUSIM can (e.g., need) to perform. In the exemplary scenario shown in Figure 5, there may be one more (1) registration event to inform AMF-2 about the unavailability period. The time associated with (e.g., required (e.g., requested) for (cancellation of) registration can take into account the best and / or worst possible case, e.g., retransmission timers / counters, retry timers / counters, etc. A registration cancellation as a shutdown can take into account the duration (e.g., timer) for which WTRU can wait for the network response.MUSIM WTRU may consider deregistering (e.g., implicitly), for example, if there is no response from the network.

[0178] On 440, AMF-1 may respond with the message REGISTRATION ACCEPTED. AMF-1 may (for example, later) release the RRC signaling connection.

[0179] In 550, MUSIM WTRU can send a REQUEST FOR Petition 870250088649, dated 09 / 30 / 2025, page 69 / 118 61 / 86 The record for the second AMF, for example, AMF-2, is the last instance that needs to be informed about the unavailability. The Delay Start can be set to zero (0), for example, Δt = 0.

[0180] At 560, AMF-2 may respond with the message RECORD ACCEPTED. AMF-2 may (e.g., later) release the connection (e.g., RRC signaling connection).

[0181] In 570, MUSIM WTRU may (for example, successfully) execute the event that made MUSIM WTRU unavailable, for example, silent modem reboot, security patch updates, OS update, modem SW updates and / or device reboot due to changes in modem settings via OMA-DM.

[0182] In 580, MUSIM WTRU can send a REGISTRATION REQUEST message to AMF-2 (e.g., by omitting (e.g., not including) the downtime duration IE), informing the network that MUSIM WTRU is (e.g., now) available. There may be a sequence for exiting downtime. For example, the last network informed of the downtime may be the first to be informed of availability. In the exemplary scenario, AMF-2 may have priority over AMF-1 in informing about WTRU availability. The start delay provided to AMF-1 may take into account the delay relative to the other network's notification of downtime, which may be followed by availability and / or corresponding procedure times.

[0183] In 590, MUSIM WTRU can send a REGISTRATION REQUEST message to AMF-1 (e.g., without including the downtime duration IE), informing the network that MUSIM WTRU is (e.g., now) available.

[0184] With reference to Figure 5, an example is given in which multiple Petition 870250088649, dated 09 / 30 / 2025, p. 70 / 118 62 / 86 networks (e.g., both or all) can support an unavailability period attribute. A MUSIM WTRU can perform one or more of the following.

[0185] As shown in Figure 5, in 510-520, a MUSIM device (e.g., WTRU) with two (2) active USIM cards can be (e.g., successfully) registered on two (2) different networks (e.g., 5G), e.g., AMF-1 and AMF-2, which support the unavailability attribute. An event may occur on the WTRU that may make it unavailable for a (e.g., certain) period of time. The WTRU (e.g., as a MUSIM device) can communicate with the network (e.g., 5GS) sequentially. The MUSIM WTRU can take into account a delay in relation to the (cancellation of) registration procedure.

[0186] As shown in Figure 5, on 530 / 540, the MUSIM WTRU can select / choose the first network (e.g., AMF-1) and send a REGISTRATION REQUEST message, which may include the duration of the unavailability period (IE) and / or a start delay Δt. The Start Delay (Δt) can inform the AMF-1 network that the unavailability period may be responsible for the delay with the provided start delay duration value. The actual duration for which the WTRU may be unavailable may be the unavailability period duration Δt. The Start Delay can be calculated, for example, by taking into account the number of pending (deregistration) procedures that the MUSIM WTRU may (e.g., need to) perform to inform other networks about the unavailability.

[0187] In the example shown in Figure 5, for instance, Δt can be determined as Δt = (N=1) x (Time requested (e.g., required) for (cancellation of) registration informing about unavailability for AMF-2 registration to inform the network (AMF-2) about the end of the unavailability period), where N can be the number of (cancellations of) registrations that MUSIM can (e.g., need) perform. In the exemplary scenario shown in Figure 5, there may be Petition 870250088649, dated 09 / 30 / 2025, page 71 / 118 63 / 86 plus one (1) registration event to inform AMF-2 about the period of unavailability.

[0188] The time associated with (e.g., required for) (cancellation of) registration may take into account the best and / or worst possible case, e.g., retransmission timers / counters, retry timers / counters, etc. A cancellation of registration as a shutdown may take into account the duration (e.g., timer duration) that the WTRU may wait for a network response. The MUSIM WTRU may consider a cancellation of registration (e.g., an implicit cancellation), e.g., if there is no network response. AMF-1 may (e.g., subsequently) release the RRC signaling connection, e.g., if AMF-1 responds with the REGISTRATION ACCEPTED message.

[0189] As shown in Figure 5, on 550 / 560, the MUSIM WTRU can send a REGISTRATION REQUEST to the second AMF (e.g., AMF-2), as the last instance that needs to be informed about the unavailability. The Delay Start can be set to zero (0), for example, Δt = 0. AMF-2 can respond with the REGISTRATION ACCEPTANCE message. AMF-2 can (e.g., later) release the connection (e.g., RRC signaling connection).

[0190] As shown in Figure 5, on 570 / 580 / 590, the WTRU can (for example, successfully) execute the event that made the WTRU unavailable, for example, silent modem reboot, security patch updates, operating system update, modem SW updates and / or device reboot due to changes in modem settings via OMA-DM. The MUSIM WTRU can send a REGISTRATION REQUEST message to AMF-2 (for example, without including the downtime duration IE), informing the network that the MUSIM WTRU is (for example, now) Petition 870250088649, dated 09 / 30 / 2025, page 72 / 118 64 / 86 available. There may be a sequence for exiting unavailability. For example, the last network informed about the unavailability period may be the first to be informed about availability. For example, as shown in Figure 5, AMF2 may have priority over AMF-1 in informing about WTRU availability. The start delay provided to AMF-1 may take into account the delay relative to the other network's unavailability notification, for example, followed by availability and corresponding procedure times. MUSIM WTRU may send a REGISTRATION REQUEST message to AMF-1 (e.g., without including the duration of the unavailability period), informing the network that MUSIM WTRU is (e.g., now) available.

[0191] In some examples, one of the networks may not support an unavailability period attribute.

[0192] Figure 6 illustrates an example of unavailability coordination across multiple networks when one of the networks does not support an unavailability attribute of a WTRU MUSIM.

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

[0194] In 620, an event may occur in the WTRU that may render the WTRU unavailable for a (e.g., certain) period of time. The WTRU (e.g., as a MUSIM device) may communicate sequentially with the network (e.g., 5GS). The MUSIM WTRU may take into account delays with respect to the deregistration (cancellation) procedure. Petition 870250088649, dated 09 / 30 / 2025, p. 73 / 118 65 / 86

[0195] In 630, the MUSIM WTRU can select / choose the first network (e.g., AMF-1) to which to send a REGISTRATION REQUEST message, for example, including the downtime duration IE and / or a delay start Δt. The Delay Start (Δt) can inform the AMF-1 network that the downtime period may be responsible for the delay with the provided delay start duration value. The actual duration for which the WTRU may be unavailable may be the downtime duration + Δt. The Delay Start Δt can be calculated, for example, by taking into account the number of pending (deregistration) procedures that the MUSIM WTRU may (e.g., need to) perform to inform other networks about the downtime. For example, as shown in Figure 6, the other network may not support the unavailability attribute (e.g., EPS or 5GS with the attribute not supported).The Delay Start date may take into account the associated duration (e.g., the time it may take) for the other network's WTRU registration to be cancelled.

[0196] On 640, AMF-1 can respond with a REGISTRATION ACCEPTANCE message. AMF-1 can (for example, later) release the RRC signaling connection.

[0197] In 650, the second network (AMF-2 / MME) may not support the attribute. The WTRU may trigger deregistration on the network, for example, by sending a DEREGISTRATION REQUEST message (for example, with a cause code such as shutdown).

[0198] In some instances, MUSIM WTRU and AMF-2 / MME may support MICO mode; MUSIM WTRU may initiate MICO mode, for example, instead of the deregistration procedure. The network may take into account the duration of the downtime provided when configuring the active time for MICO mode. The active time may not coincide with the downtime. The active time may begin after the downtime. The network may (by Petition 870250088649, dated 09 / 30 / 2025, p. 74 / 118 66 / 86 example, alternatively) set the periodic registration duration (e.g., timer duration) equal to or greater than the downtime period duration, which can ensure that the WTRU can perform periodic registration when it is accessible again. The network can reconfigure the WTRU with the desired parameters (e.g., new periodic registration duration / timer value) during periodic registration.

[0199] In some instances, a deregistration may be performed first. MUSIM WTRU may deregister the network that does not support the unavailability attribute. MUSIM WTRU may (e.g., subsequently) perform the unavailability procedure with the second supporting network.

[0200] In 660, the WTRU may (for example, successfully) execute the event that made the WTRU unavailable, for example, silent modem reboot, security patch updates, OS update, modem SW updates and / or device reboot after modem configuration changes via OMA-DM.

[0201] In 670, MUSIM WTRU can send a REGISTRATION REQUEST message to AMF-2 (e.g., by omitting (e.g., not including) the downtime duration IE), informing the network that MUSIM WTRU is (e.g., now) available. There may be a sequence for exiting downtime. For example, the last network informed about the downtime may be the first to be informed about availability. For example, as shown in Figure 5, AMF-2 / MME may have priority over AMF-1 in informing about WTRU availability. The start delay provided to AMF-1 may take into account the delay relative to the other network's information about downtime, for example, followed by availability and the corresponding procedure times. Petition 870250088649, dated 09 / 30 / 2025, p. 75 / 118 67 / 86

[0202] On 680, MUSIM WTRU can send a REGISTRATION REQUEST message to AMF-1 (e.g., not including the downtime duration IE), which can inform the network that MUSIM WTRU is (e.g., now) available.

[0203] With reference to Figure 6, an additional example procedure is provided in which one of the networks may not support an unavailability period attribute. A WTRU MUSIM may implement one or more of the following.

[0204] As shown in Figure 6, in 610-620, the MUSIM device (e.g., WTRU) can have two (2) active USIM cards. MUSIM WTRU can be successfully registered on two (2) different networks, e.g., AMF-1 and AMF2 / MME. In an example scenario, the second network can be an EPS that does not support an unavailability attribute or a 5G network (e.g., AMF) that does not support the unavailability attribute. An event can occur on the WTRU that can make it unavailable for a certain period of time. The WTRU (e.g., as a MUSIM device) can communicate (e.g., sequentially) with the 5GS. The MUSIM WTRU can take into account delays regarding the (cancellation) registration procedure.

[0205] As shown in Figure 6, on 630 / 640, the MUSIM WTRU can choose the first network, for example, AMF-1, and send a REGISTRATION REQUEST message, for example, including the downtime duration IE and / or a delay start Δt. The Delay Start (Δt) can inform the AMF-1 network that the downtime period may be responsible for the delay with the provided delay start duration value. The actual duration that the WTRU may be unavailable can be calculated as the downtime duration + Δt. The Delay Start Δt can be calculated, for example, by taking into account the number of pending (deregistration) procedures that the MUSIM WTRU may (e.g., need to) perform to inform other networks about Petition 870250088649, dated 09 / 30 / 2025, p. 76 / 118 68 / 86 unavailability. For example, as shown in Figure 6, the other network does not support the unavailability attribute (e.g., EPS or 5GS with unsupported attribute). The Delay Start may take into account the duration it may take to cancel the MUSIM WTRU registration from the other network. AMF-1 may respond with the REGISTRATION ACCEPTANCE message. AMF-1 may (e.g., later) release the connection (e.g., RRC signaling connection).

[0206] As shown in Figure 6, in 650, the second network (e.g., AMF-2 / MME) may not support the attribute. The WTRU can trigger deregistration on the network, for example, by sending a DEREGISTRATION REQUEST message, for example, with a cause code such as shutdown.

[0207] In some instances, MUSIM WTRU and AMF-2 / MME may support MICO mode. The MUSIM WTRU may initiate MICO mode, for example, instead of the deregistration procedure. The network may take into account the duration of the provided downtime when configuring the active time for MICO mode. The active time may not coincide with the downtime. Active time may begin after the downtime. The network may (for example, alternatively) set the periodic registration duration (e.g., timer duration) equal to or greater than the downtime duration, which may ensure that the WTRU can perform periodic registration when the WTRU becomes accessible again. The network may reconfigure the WTRU with the desired parameters (e.g., new periodic registration duration / timer value) during periodic registration.

[0208] In some examples, a deregistration step may be the first step. For example, MUSIM WTRU may deregister a network that does not support the unavailability attribute. WTRU may (for example, Petition 870250088649, dated 09 / 30 / 2025, page 77 / 118 69 / 86 subsequently) perform the unavailability procedure with the second support network.

[0209] As shown in Figure 6, on 660 / 670 / 680, the WTRU can (for example, successfully) execute the event that made the WTRU unavailable, for example, silent modem reboot, security patch updates, operating system update, modem SW updates, and / or device reboot due to changes in modem settings via OMA-DM. The MUSIM WTRU can send a REGISTRATION REQUEST message to AMF-2 (for example, without including the downtime duration IE), informing the network that the MUSIM WTRU is (for example, now) available. There may be a sequence to exit unavailability. For example, the last network informed about the downtime period may be the first to be informed about availability. For example, as shown in Figure 6, AMF2 / MME may have priority over AMF-1 in informing about WTRU availability.The start delay provided to AMF-1 may take into account the delay in relation to the other network's information about unavailability, for example, followed by availability and the corresponding procedure times. MUSIM WTRU may send a REGISTRATION REQUEST message to AMF-1 (e.g., without including the duration of the unavailability period), informing the network that MUSIM WTRU is (e.g., now) available.

[0210] Downtime support can be provided for devices registered on multiple networks (e.g., EPC and 5GC). The AMF can 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 on the EPC, for example, the AMF may receive an initial registration request from a WTRU whose EMM status is REGISTERED EMM. The AMF can detect that the WTRU is registered on the EPS, for example, if the initial registration request includes Petition 870250088649, dated 09 / 30 / 2025, pp. 78 / 118 70 / 86 the WTRU state information element with the N1 mode register bit of the WTRU state information element set to a value of 1, which may indicate that the WTRU is in the EMM-REGISTERED state.

[0211] A WTRU capable of operating in S1 and N1 modes can detect that an event needs to be executed, which may make the WTRU unavailable for a period. The WTRU can (e.g., determine) send a duration of unavailability to the AMF, for example, so that the AMF knows that the WTRU may be inaccessible and / or that the WTRU context must be maintained by the network (e.g., 5GS) while the WTRU is executing the event and unavailable.

[0212] The AMF may (e.g., based on the registration request) send a notification to the MME (e.g., via the N26 interface), 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 instances, the AMF receives a registration request from the WTRU that includes the duration of the unavailability period. The notification may indicate to the MME that the WTRU will be unavailable for a period of time. The notification may include the duration of the unavailability period or the Periodic Registration Time that the AMF may send to the WTRU in the Registration Response. The MME may determine (e.g., be informed) how long to expect the WTRU to be unavailable, e.g., based on the duration of the unavailability period or the Periodic Registration Time in the notification.MME may take one or more (for example, any combination) of the following actions upon receiving the notification.

[0213] For example, the MME may (for example, begin to) consider the WTRU inaccessible and / or may reject (for example, any) downlink data notification associated with the WTRU, for example, until at least the time period indicated in the notification has elapsed. The MME may (for example, also) set a duration (timer, for example, the timer). Petition 870250088649, dated 09 / 30 / 2025, p. 79 / 118 71 / 86 of implicit detachment) which can be associated with the WTRU, for example, by assigning to the duration (e.g., timer) a value that is at least the time period indicated in the notification.

[0214] For example, MME may respond to AMF indicating that MME does not agree to maintain the WTRU context while WTRU is unavailable and / or that AMF may indicate to WTRU that WTRU may consider that WTRU has its EPS registration cancelled, for example, and that WTRU may transition from the EMM-REGISTERED state to the EMM-DESREGISTERED state. MME's response may (for example, also) include a different (e.g., new) periodic tracking area update duration value (e.g., timer) for AMF to send to WTRU.

[0215] AMF may send a registration response to WTRU, for example, based on (e.g., after) sending the notification to MME and receiving a response from MME. The Registration Response may include, for example, one or more of the following indications: an indication that the downtime period was shared with MME and / or that WTRU may perform a Tracking Area Update with MME when the downtime event is completed; an indication that the downtime period was rejected by MME and / or that WTRU considers WTRU to have its EPS registration cancelled, for example, a transition from the EMM-REGISTERED state to the EMM-REGISTERED state; and / or a value (e.g., new value) that WTRU may assign to its EPS the duration value (e.g., timer) for periodic tracking area updates.

[0216] WTRU may complete the downtime period. WTRU may (for example, after the downtime period is over) perform a registration area update procedure with 5GS and a tracking area update procedure with EPS. The update procedure of Petition 870250088649, dated 09 / 30 / 2025, pp. 80 / 118 72 / 86 area tracking can be performed, for example, (only) if the WTRU has not transitioned to the EMM-REGISTRATION CANCELED state. The WTRU can perform an attachment procedure with the EPS, for example, if the WTRU has transitioned to the EMM-REGISTRATION CANCELED state.

[0217] The advantages provided by downtime support for devices registered on multiple networks (e.g., EPC and 5GC) may include, for example, one or more of the following: EPS NAS signaling may not change (e.g., it does not need to change); EPS context may be maintained while the WTRU is in downtime; and / or the WTRU may determine (e.g., be informed) whether the MME cannot or does not wish to maintain the EPS context while the WTRU is in downtime.

[0218] Figure 7 illustrates an example of a dual record scenario where a WTRU has a 5GMM and EMM context.

[0219] As shown in Figure 7, in 710, the WTRU can be enabled for 5GMM and EMM. WTRU can operate in a single register mode. The WTRU can maintain a common register for 5GMM for 3GPP and EMM access. The WTRU can be successfully updated in both 5GMM and EMM (e.g., the S1 mode register status is EMM-REGISTERED, and the N1 mode register status is 5GMM-REGISTERED). The WTRU can be currently encamped in a 5G cell in idle mode. 5GS or EPS can indicate (e.g., in the last register procedure) support for interoperability with N26 as part of the 5GS network attribute support IE or EPS network attribute support IE with the N26 WK bit set for unsupported N26 interface interoperability.

[0220] In 720, an event may occur in the WTRU that may make the WTRU unavailable for a (for example, certain) period of time.

[0221] At 7:30 am, WTRU can initiate the REQUEST procedure. Petition 870250088649, dated 09 / 30 / 2025, pp. 81 / 118 73 / 86 REGISTRATION with AMF. WTRU can provide the downtime period, i.e., to inform the network about the duration of WTRU's unavailability.

[0222] In 740, AMF can send a notification to MME, for example, via the N26 interface. The notification can indicate to MME that WTRU is (for example, about to become) unavailable for a period of time. The notification can include the duration of the unavailability period or the Periodic Log Time that AMF can send to WTRU in the Log Response. MME can be informed about how long WTRU may be unavailable, for example, based on the duration of the unavailability period or the Periodic Log Time in the notification.

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

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

[0225] For example, MME may respond to AMF with an indication that MME does not agree to maintain the WTRU context while WTRU is unavailable, that AMF (for example, may) indicate to WTRU that WTRU may consider canceling WTRU from EPS, and / or that WTRU (for example, may) transition from EMM-REGISTERED state to EMM-REGISTERED state. MME's response may (for example, also) include a (for example, new) periodic update duration value for the tracking area. Petition 870250088649, dated 09 / 30 / 2025, p. 82 / 118 74 / 86 (e.g., timer) for AMF to send to WTRU.

[0226] On 760, MME can respond to AMF notification (e.g., via the N26 interface). MME's response may include information indicating, for example, whether the WTRU unavailability request was accepted / rejected by MME and / or the duration of the periodic registration timer that can be relayed to WTRU, e.g., via AMF.

[0227] In 770, AMF may provide REGISTRATION ACCEPTANCE to WTRU. The Registration Response may include one or more of the following indications: an indication that the downtime period was shared with MME, that WTRU may perform a Tracking Area Update with MME when the downtime event is completed and / or that the EMM status may be EMM-REGISTERED; an indication that the downtime period was rejected by MME, that WTRU may consider itself canceled from EPS and / or that WTRU may transition from EMM-REGISTERED status to EMM-DESREGISTERED status; and / or a new value that WTRU may assign to the WTRU EPS tracking area periodic update timer value.

[0228] On 780, WTRU can (for example, successfully) execute the event that made WTRU unavailable, for example, silent reboot on the modem, security patch updates, OS update, modem SW updates and / or device reboot after changes to modem settings via OMA-DM.

[0229] In 790, the WTRU that exits the downtime period can perform the registration procedure in the AMF, for example, without including the downtime period IE.

[0230] In 795, the WTRU may (for example, depending on the result and response that the WTRU received from the MME via AMF) trigger an EMM Tracking Area Update Procedure (for example, if the EMM status is Petition 870250088649, dated 09 / 30 / 2025, p. 83 / 118 75 / 86 REGISTERED EMM) or an ATTACH EMM procedure (for example, if the EMM status is REGISTERED EMM) to indicate to MME that the downtime period has ended and that WTRU is accessible again.

[0231] Analysis (e.g., NWDAF) can be supported for the downtime attribute. The AMF Namf_EventExposure service can support an NF invoker (e.g., NWDAF) subscribing to an event (e.g., a WTRU downtime event). AMF can report WTRU downtime information to the NF invoker when the event occurs. WTRU downtime information can include one or more of the following: WTRU identifier(s); information about the downtime of a (e.g., each) WTRU identifier; and / or an indication of an expected action, e.g., when each WTRU becomes available.

[0232] AMF can provide WTRU unavailability information if (for example, when) the invoking NF subscribes to or invokes the Namf_EventExposure subscription service operation and provides an event ID, such as (for example, equal to), for example, one or more of the following: Registration status report, a connectivity status report, an accessibility report, an area UE report, a 5GS user status report, a frequent mobility registration report, UE access behavior trends, and / or a UE-MM transaction report. Additionally and / or alternatively, an Event ID (e.g., new Event ID) can be defined (e.g., WTRU unavailability information).AMF can provide WTRU unavailability information if (for example, when) the invoking NF subscribes to or invokes the Namf_EventExposure Subscribe service operation and provides an event ID (for example, one that equals “WTRU unavailability information”).

[0233] The downtime information provided by AMF to the invoking NF for a WTRU may be, for example, one or more of the following: Petition 870250088649, dated 09 / 30 / 2025, p. 84 / 118 76 / 86 equal to the duration of the downtime period requested by WTRU; defined as an absolute time value that is based on the duration of the downtime period requested by WTRU; defined as a value indicating how much time AMF expects or needs to pass before the downtime expires; and / or equal to a periodic record duration value (e.g., timer) that was provided to WTRU by AMF.

[0234] The indication of an expected action when the WTRU becomes available may indicate that the WTRU should (e.g., is expected) perform a mobility registration if (e.g., when) the unavailability period ends, or indicate that the WTRU should (e.g., is expected) perform an initial registration if (e.g., when) the unavailability period ends.

[0235] AMF may indicate that WTRU should (e.g., is expected to) perform a mobility registration if (e.g., when) the downtime period ends, for example, if WTRU provided the duration of the downtime period in a mobility registration request.

[0236] AMF may indicate that WTRU should (e.g., is expected to) perform an initial registration if (e.g., when) the downtime period ends, for example, if WTRU provided the duration of the downtime period in a deregistration request.

[0237] Providing an indication of the expected action if (e.g., when) the WTRU becomes available to the consumer NF (e.g., NWDAF) can be useful (e.g., important), for example, because the expected action may impact the amount of network activity (e.g., that may be required) if (e.g., when) the WTRU becomes available. For example, an initial registration procedure may result in more signaling than a mobility registration procedure. The consumer NF may (e.g., be able to) generate more accurate statistics and / or predictions, for example, if the consumer NF (e.g., by Petition 870250088649, dated 09 / 30 / 2025, p. 85 / 118 77 / 86 example, NWDAF) is informed about what action is expected.

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

[0239] Figure 8 illustrates an example of using unavailability information to generate enhanced data analyses.

[0240] As shown in Figure 8, in 810, a consumer NF (e.g., PCF, AMF, NSSF, NEF, SMF, or AF) can invoke a service (e.g., the NWDAF Nnwdaf_AnalytcisInfo service). The service invocation type can be a request or subscription operation. The requested analysis type can 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.

[0241] At 8:20 AM, NWDAF may (for example, begin to) collect data that may be necessary to determine the information requested at 8:10 AM. As part of the process of collecting the necessary data, NWDAF may invoke the AMF's Namf_EventExposure service operation. The service invocation type may be a request or subscription operation. The event ID value that may be provided by NWDAF to AMF in the operation may be one or more of the following: a Registration Status Report; a Connectivity Status Report; an Accessibility Report; UEs in Area Report; 5GS User Status Report; Frequent Mobility Registration Report; UE Access Behavior Trends; UE MM Transaction Report; and / or Petition 870250088649, dated 09 / 30 / 2025, page 86 / 118 78 / 86 WTRU unavailability information.

[0242] At 8:30 AM, AMF may receive a NAS registration request or a NAS deregistration request, which may include a period of unavailability. For example, operations at 8:30 AM may occur before operations at 8:20 AM.

[0243] On 840, an operation may depend on the operation at 8:20. For example, if the action on 820 is a request operation, then on 840, the AMF may respond (e.g., immediately) to the NWDAF with downtime information and / or an indication of an expected action if (e.g., when) the WTRU becomes available. The response may provide information for one or more WTRUs. For example, if the action on 820 is a subscription operation, the NAS message on 830 may trigger the AMF to send a notification to the NWDAF on 840. The notification may include downtime information and / or an indication of an expected action when the WTRU becomes available. The notification may provide information for one or more WTRUs.

[0244] At 8:50, NWDAF can derive the analyses (e.g., statistics or predictions) that were requested at 8:10. The analysis can be derived based on downtime information and / or indication of an expected action when WTRU is available.

[0245] In 860, NWDAF can send analyses to the consumer's NF in a notification or response service operation.

[0246] An unavailability period attribute can be supported for relay WTRUs. A relay WTRU can enter an unavailability period.

[0247] In an exemplary procedure, a relay WTRU may detect that it needs to enter a period when the WTRU may be unavailable. Petition 870250088649, dated 09 / 30 / 2025, p. 87 / 118 79 / 86

[0248] In some instances, remote WTRUs and relay WTRUs can be connected (e.g., via the PC5 connection). Either the relay WTRU or the remote WTRU may become unavailable due to the unavailability event.

[0249] Figure 9 illustrates an example of a relay WTRU entering a period of unavailability.

[0250] As shown in Figure 9, in 900, a relay WTRU and one or more remote WTRUs can be connected via PC5 connection.

[0251] In 910, an unavailability event may be triggered in the relay WTRU, which may make the relay WTRU unavailable for a (e.g., certain) period of time.

[0252] In 920, the relay WTRU may enter a period of unavailability, for example, by sending a REGISTRATION REQUEST message to the AMF. The message may include the IE unavailability period and / or the list of remote WTRUs that can 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.

[0253] In 930, a list of remote WTRU information can be passed by the AMF to the AF for the connectivity loss event (for example, provided that the AF has registered the connectivity loss event for the respective remote WTRUs).

[0254] In 940, AMF can respond with RECORD ACCEPTANCE providing the list of remote WTRUs, for example, confirming the list's reception status.

[0255] In 950, the relay WTRU can inform connected remote WTRUs about the unavailability of the relay WTRU, for example, Petition 870250088649, dated 09 / 30 / 2025, pp. 88 / 118 80 / 86 together with the duration of the downtime period.

[0256] In 960, remote WTRUs may be aware of the unavailability of the relay WTRU. Remote WTRUs may use the unavailability of the relay WTRU as a trigger to buffer UL activity, trigger selection for a different relay WTRU, establish a direct connection to the network (e.g., 5G), and / or provide information about the unavailability period (e.g., via a deregistration procedure) to the network.

[0257] A remote WTRU may enter a Period of Unavailability.

[0258] Figure 10 illustrates an example of a remote WTRU entering a period of unavailability.

[0259] As shown in Figure 10, in 1000, a relay WTRU and one or more remote WTRUs can be connected via PC5 connection.

[0260] In 1010, an unavailability event may be triggered on the remote WTRU, which may make the remote WTRU unavailable for a (e.g., certain) period of time.

[0261] In 1020, the remote WTRU can trigger the unavailability, for example, via the relay WTRU, for example, informing the AMF / AF about the unavailability event via the relay WTRU.

[0262] In 1030, the remote WTRU can provide information about the unavailability to the relay WTRU (for example, by means of an Unavailability Notification message), which may include the duration of the unavailability period and / or an ID of the remote WTRU.

[0263] In 1040, the relay WTRU can update the unavailability status of the remote WTRU to other connected WTRUs. The relay WTRU and / or the other connected WTRUs (e.g., aware of Petition 870250088649, dated 09 / 30 / 2025, p. 89 / 118 81 / 86 unavailability) can buffer notifications / DL data (e.g., while the remote WTRU is unavailable).

[0264] In 1050, the relay WTRU can inform other remote WTRUs about the unavailability of the remote WTRU. The relay WTRU can provide the ID of the remote WTRU and / or the duration of the unavailability period.

[0265] The remote WTRU (e.g., when it becomes available again) can use the same or a similar procedure shown in Figure 10 to indicate availability. For example, the remote WTRU can provide the relay WTRU with an unavailability notification message indicating unavailability as not applicable. The remote WTRU can provide its remote WTRU ID. The relay WTRU can, for example, transmit the availability information to other connected remote WTRUs.

[0266] The accounting of the expected availability of the WTRU can be provided when a period of unavailability is requested. As described here, a WTRU can use MICO mode. A WTRU can apply a strictly periodic log timer attribute when using MICO mode.

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

[0268] AMF can send a registration acceptance message to WTRU. The registration acceptance message may include, for example, one or more of the following information elements: an indication to use MICO mode; an indication of whether the strictly periodic registration timer is supported by Petition 870250088649, dated 09 / 30 / 2025, pages 90 / 118 82 / 86 network; an active duration value (e.g., timer) (e.g., T3324); and / or a recording duration value (e.g., timer) (e.g., requested T3512 value).

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

[0270] The WTRU may (for example, determine) send a registration request to the AMF. The registration request may include a duration of the downtime period. The AMF may detect that the downtime period overlaps with a period of time when the WTRU, which may be using MICO mode, is expected to be available for downlink data. The WTRU may not be accessible for downlink data at a time when the 5G System or an application server expects the WTRU to be available, for example, if the WTRU becomes inaccessible immediately after the registration acceptance message is sent and the WTRU remains in an inaccessible state during the downtime period. The AMF may indicate in a Registration Acceptance Message that the downtime period is not accepted. The WTRU may (for example, then) determine when it may be acceptable to request the downtime period again.

[0271] The registration acceptance message may indicate that the strictly periodic duration attribute of the registration (e.g., timer) is enabled and that the downtime period was not accepted. WTRU may (e.g., in response to the registration acceptance message) wait to request a downtime period duration again until the registration duration (e.g., timer) expires, or send a registration request based on the duration of the Petition 870250088649, dated 09 / 30 / 2025, pp. 91 / 118 83 / 86 registration (e.g., timer) expiring, and entering the CM-IDLE state when the active duration (e.g., timer) is not running. By waiting until these conditions are met, one can ensure that the expected WTRU availability time has ended (e.g., has just passed). This approach can be useful, for example, in cases where the WTRU requests a period of unavailability when the strictly periodic registration time is close to expiring.

[0272] The registration acceptance message may indicate that the strictly periodic registration timer attribute is not enabled and that the downtime period was not accepted. The WTRU may (e.g., in response to the registration acceptance message) wait to request a downtime period duration again until the WTRU enters the CM-IDLE state and the active duration (e.g., timer) is not running. By waiting until these conditions are met, it can be ensured that the expected WTRU uptime has ended (e.g., has just passed).

[0273] WTRU may (for example, alternatively) determine (for example, again) to request a period of unavailability, for example, if WTRU receives a configuration update message from WTRU or other registration acceptance message that disables MICO mode or the strictly periodic registration duration attribute (for example, timer).

[0274] The registration acceptance message may indicate that MICO mode is not enabled and that the downtime period has not been accepted. The WTRU may (e.g., in response to the registration acceptance message) track a duration (e.g., set a timer) with the downtime period and may refrain from requesting (e.g., not requesting) the downtime period again until the waiting duration (e.g., timer) expires and the WTRU has entered the CM-IDLE state. Petition 870250088649, dated 09 / 30 / 2025, pp. 92-118 84 / 86

[0275] WTRU may (for example, alternatively) determine (for example, at any time) send (for example, again) a downtime period duration in a deregistration request. An example of the procedure is illustrated in Figure 11.

[0276] Figure 11 illustrates an example of logic for handling WTRU for a rejected downtime period. Figure 11 shows an example of how to account for the expected availability of the WTRU when a downtime period is requested.

[0277] As shown in Figure 11, a WTRU can (for example, when MICO Mode and the strictly periodic registration duration / timer attribute are enabled) send a registration request that includes a downtime duration. The WTRU may receive a registration acceptance message, which may indicate that MICO Mode is enabled, the strictly periodic registration timer attribute is enabled, and that downtime duration is not allowed. The WTRU may determine to send a second registration request that includes a second downtime duration under the conditions that a periodic registration duration (e.g., timer) has expired, the WTRU has entered the CMOCIOSO state, and an active duration (e.g., timer) is not running. The WTRU may send the second registration request, which may include a second downtime duration.

[0278] As shown in Figure 11, a WTRU can (for example, when MICO Mode and the strictly periodic logging timer attribute are not enabled) send a logging request that includes a downtime duration. The WTRU can receive a logging acceptance message, which may indicate that MICO Mode is enabled, the strictly periodic logging duration attribute (e.g., timer) is not enabled, and that Petition 870250088649, dated 09 / 30 / 2025, pp. 93-118 85 / 86 the duration of the downtime period is not permitted. WTRU may determine to send a second registration request that includes a second downtime period duration, for example, under conditions where WTRU has entered the CM-IDLE state and an active duration (e.g., timer) is not running. WTRU may send the second registration request, for example, which includes a second downtime period duration.

[0279] As shown in Figure 11, a WTRU can (for example, when MICO mode is not enabled) send a registration request, which may include a downtime duration. The WTRU may receive a registration acceptance message that refrains from indicating (e.g., does not indicate) that MICO mode is enabled and that downtime duration is not allowed. The WTRU may configure and initiate tracking of a duration (e.g., start a timer) with the downtime duration. The WTRU may determine to send a second registration request that includes a second downtime duration under the conditions that the duration (e.g., timer) is not running and the WTRU has entered the CM-IDLE state. The WTRU may send the second registration request that includes a second downtime duration.

[0280] Although the attributes and elements described above are described in particular combinations, each attribute or element can be used alone, without the other attributes and elements of the preferred modalities, or in various combinations with or without other attributes and elements.

[0281] Although the implementations described here may consider specific 3GPP protocols, it is understood that the implementations described here are not restricted to this scenario and may be applicable to other wireless systems. For example, although the solutions described here consider specific protocols Petition 870250088649, dated 09 / 30 / 2025, pp. 94 / 118 86 / 86 Whether you use LTE, LTE-A, New Radio (NR), or 5G, it is understood that the solutions described here are not limited to this scenario and are also applicable to other wireless systems.

[0282] The processes described herein may be implemented in a computer program, software, and / or firmware embedded 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), a register, 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 discs (CD)-ROMs and / or digital versatile discs (DVDs).A processor, in conjunction with software, can be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer. Petition 870250088649, dated 09 / 30 / 2025, pages 95 / 118

Claims

1 / 3 CLAIMS 1. Wireless transmit and receive unit (WTRU), CHARACTERIZED in that it comprises: a processor configured to: receive signaling from a network entity indicating congestion, wherein the signaling indicates a pullback duration, wherein the pullback duration is associated with congestion; send a registration request to the network entity, wherein the registration request indicates an unavailability period and indicates that the WTRU cannot receive DL data during the unavailability period, and wherein the registration request is sent during the pullback period; receive a registration acceptance message, wherein the registration acceptance message comprises an indication indicating whether the WTRU should inform the network entity at the end of the unavailability period; determine that the unavailability period has ended; determine that the WTRU should inform the network entity at the end of the unavailability period;and send a registration update request to the network entity based on the determination that the downtime period has ended and the determination that the WTRU must inform the network entity at the end of the downtime period, where the registration update request indicates that the downtime period has ended.

2. WTRU, according to claim 1, CHARACTERIZED in that the processor is additionally configured to: determine that a pullback period is active based on the pullback duration indicated by the signaling, wherein the registration request is sent to the network entity based on the determination that the pullback period is active.

3. WTRU, according to claim 1, CHARACTERIZED by the fact Petition 870250088649, dated 09 / 30 / 2025, pp. 116 / 118 2 / 3 that the registration request is sent via NAS signaling.

4. WTRU, according to claim 1, CHARACTERIZED in that the registration update request comprises an indication that shows that WTRU is available.

5. Method, CHARACTERIZED by the fact that it comprises: receiving signaling from a network entity indicating congestion, wherein the signaling indicates a pullback duration, wherein the pullback duration is associated with the congestion; sending a registration request to the network entity, wherein the registration request indicates a period of unavailability and indicates that a wireless transmit / receive unit (WTRU) cannot receive DL data during the period of unavailability, and wherein the registration request is sent during the pullback period; receiving a registration acceptance message, wherein the registration acceptance message comprises an indication indicating whether to inform the network entity at the end of the period of unavailability; determining that the period of unavailability has ended; determining whether to inform the network entity at the end of the period of unavailability;and submit a registration update request to the network entity based on the determination that the downtime period has ended and the determination to inform the network entity at the end of the downtime period, where the registration update request indicates that the downtime period has ended.

6. Method, according to claim 5, CHARACTERIZED in that the method further comprises: determining that a pullback period is active based on the pullback duration indicated by the signaling, wherein the registration request is sent to the network based on the determination that the pullback period is active.

7. Method, according to claim 5, CHARACTERIZED in that the registration request is sent via NAS signaling.

8. Method, according to claim 5, CHARACTERIZED in that the registration update request comprises an indication indicating availability associated with WTRU. Petition 870250088649, dated 09 / 30 / 2025, pp. 118 / 118

Images