Downtime support for musim devices

Description

1 / 86 “SUPPORT DURING THE UNAVAILABILITY PERIOD FOR MUSIM DEVICES” CROSS-REFERENCE TO RELATED REQUESTS

[001] The application claims the benefit of U.S. Provisional Application 63 / 457,515, filed April 6, 2023, which is incorporated herein by reference in its entirety. FUNDAMENTALS OF THE INVENTION

[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 long-term evolution (LTE) of fourth generation (4G). SUMMARY OF THE INVENTION

[003] Systems, methods and tools are described here in relation to support for downtime while a wireless transmit / receive unit (WTRU) is registered in non-3GPP access (i.e., only in non-3GPP access).

[004] 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 non-access stratum signaling (NAS). 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 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 Petition 870250084746, dated 09 / 19 / 2025, p. 9 / 119 2 / 86 WTRU is available. The device can send a log update request. The log update request can be sent based on the determination that the unavailability event has ended and the determination that WTRU must inform the network entity when WTRU is available. The log update request can indicate that 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 wait time 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 first duration (e.g., based on whether the WTRU is associated with discontinuous coverage). The registration acceptance message may indicate that the WTRU should not send an update message (e.g., after the first duration), for example, if the WTRU is associated with discontinuous coverage. The device can determine if the WTRU is available after the first duration. The device can determine if a message... Petition 870250084746, dated 09 / 19 / 2025, p. 10 / 119 3 / 86 of the update 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 may be considered 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 outage period feature with the second network. The registration request may indicate an initial outage duration associated with an outage period. The device may determine that an outage event is 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 this period may be based on the determination that the outage event was triggered. The initial outage duration may be determined based on the determination that the device will be unavailable during this period.The device may receive an initial registration response (for example, 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 second registration request to a second network. The second... Petition 870250084746, dated 09 / 19 / 2025, page 11 / 119 4 / 86 The registration request may indicate enabling the downtime feature 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 downtime information. The registration request can include a downtime information element that can indicate the downtime information. The downtime information can indicate a duration of unavailability, for example, associated with the WTRU. The device can send a notification to an entity (e.g., a mobility management entity). The notification can indicate that the WTRU is unavailable for a period of time. The device can receive (e.g., from the entity) a response to the notification. The response to the notification can indicate that the entity accepted the WTRU's unavailability.The response to the notification may indicate the duration of the tracking area update. The response to the notification may indicate that the entity has accepted the WTRU unavailability and the duration of the tracking area update. The device may send a registration acceptance message (e.g., to the WTRU), based on the response to the notification. The registration acceptance message may indicate the duration of the tracking area update. The registration acceptance message may instruct the WTRU to perform a tracking area update. Petition 870250084746, dated 09 / 19 / 2025, p. 12 / 119 5 / 86 entity, for example, based on the conclusion 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 greater than or equal to 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 second duration has elapsed. The second duration may be associated with or equal to an unavailability period duration 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 the CONNECTED state, etc. The device can deregister the WTRU based on the determination that the second duration has expired. BRIEF DESCRIPTION OF THE DRAWINGS Petition 870250084746, dated 09 / 19 / 2025, page 13 / 119 6 / 86

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

[011] Figure 1B is a system diagram illustrating an exemplary wireless transmit / 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 exemplary radio access network (RAN) and an exemplary central network (CN) that can be used in the communications system illustrated in Figure 1A, according to one modality.

[013] Figure 1D is a system diagram that illustrates an additional exemplary RAN and an additional exemplary CN that can be used in the communications system illustrated in Figure 1A, according to one embodiment.

[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 where the downtime feature 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 feature.

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

[019] Figure 7 illustrates an example of a dual record scenario in which a WTRU has a 5GMM and EMM context. Petition 870250084746, dated 09 / 19 / 2025, page 14 / 119 7 / 86

[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 WTRU to handle an out-of-off time rejection. DETAILED DESCRIPTION

[024] Figure 1A is a diagram illustrating an exemplary 100 communications system, in which one or more described modalities can be implemented. The 100 communications system can be a multiple access system that provides content, such as voice, data, video, messages, transmission, etc., to multiple wireless users. The 100 communications system can allow multiple wireless users to access such content by sharing system resources, including wireless bandwidth.For example, communication systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tailed single-word DFT propagation 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 / receive units (WTRUs) 102a, 102b, 102c, 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 important to note that the Petition 870250084746, dated 09 / 19 / 2025, page 15 / 119 8 / 86 The described modalities consider 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. By way of 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, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, virtual reality glasses (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 in commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to 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, a Home eNode B, a gNB, an NR NodeB, a site controller, an access point (AP), a wireless router and the like. Although base stations 114a, 114b are Petition 870250084746, dated 09 / 19 / 2025, p. 16 / 119 9 / 86 represented as a single element, it is important to note 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 be further 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 the desired spatial directions.

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

[029] More specifically, as noted above, the system of Petition 870250084746, dated 09 / 19 / 2025, page 17 / 119 10 / 86 communications 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 similar ones. 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 HSPA Enhanced (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink (UL) Packet Access (HSUPA).

[030] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology, such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE 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 may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may 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 may 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).

[033] In other modes, base station 114a and WTRUs 102a, 102b, Petition 870250084746, dated 09 / 19 / 2025, p. 18 / 119 11 / 86 102c devices can 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), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and similar technologies.

[034] Base station 114b in Figure 1A can be a wireless router, a Home NodeB, a Home eNodeB, or an access point, for example, and can utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a commercial location, a residence, 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. Thus, base station 114b may not need 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 of WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as different requirements for throughput, latency, error tolerance, reliability, data throughput, mobility and Petition 870250084746, dated 09 / 19 / 2025, page 19 / 119 12 / 86 similar. CN 106 / 115 can provide call control, billing services, location-based mobile 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 is important to note that RAN 104 / 113 and / or CN 106 / 115 may be in direct or indirect communication with other RANs that use the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to being connected to RAN 104 / 113, which may use NR radio technology, CN 106 / 115 may also be in communication with another RAN (not shown) that uses 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 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 NC connected to one or more RANs, which may use 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 via different wireless links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with station Petition 870250084746, dated 09 / 19 / 2025, p. 20 / 119 13 / 86 base 114a, which may employ cellular-based radio technology, and base station 114b, which may employ IEEE 802 radio technology.

[038] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a numeric keypad 126, a touchscreen / touch surface 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136 and / or other peripherals 138, among others. It should be noted that the WTRU 102 may include any subcombination of the above elements, while 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 Arrays (FPGAs), 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 transmit / receive element 122.While Figure 1B depicts processor 118 and transceiver 120 as separate components, it is important to note that processor 118 and transceiver 120 can be integrated into a single electronic package or chip.

[040] The transmit / receive element 122 can be configured to transmit to or receive signals from a base station (e.g., station Petition 870250084746, dated 09 / 19 / 2025, page 21 / 119 14 / 86 base 114a) via air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmit / receive element 122 may be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It is important to note that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[042] Transceiver 120 can be configured to modulate the signals to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, WTRU 102 can have multimode capabilities. Thus, transceiver 120 can include multiple transceivers to allow 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 with and receive user input data from the speaker / microphone 124, the numeric keypad 126 and / or the screen / touch surface 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit). The processor 118 can also send user data to the speaker / microphone 124, the numeric keypad 126 and / or the screen / touch surface 128. In addition Petition 870250084746, dated 09 / 19 / 2025, page 22 / 119 15 / 86 of this, 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 SIM card (subscriber identity module), a memory card, a secure digital memory card (SD), and the like. In other embodiments, processor 118 can access information and store data in memory that is not physically located in 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 can also be coupled to GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) pertaining to the current location of WTRU 102. In addition to, or in substitution for, GPS chipset 136 information, WTRU 102 can 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. Importantly, WTRU 102 can acquire location information by any suitable location determination method, remaining consistent with a mode. Petition 870250084746, dated 09 / 19 / 2025, page 23 / 119 16 / 86

[046] The processor 118 may also be coupled with other peripherals 138, which may include one or more software and / or hardware modules that provide additional wired or wireless features, functionality and / or connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for stills and / or video), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker and the like. Peripherals 138 may include one or more sensors.The sensors may be one or more of a 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 a 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 specific subframes for UL (e.g., for transmission) and DL (e.g., for reception) may be simultaneous. The full-duplex radio may include an interference management unit to substantially reduce and / or eliminate self-interference by means of hardware (e.g., an inductor) or signal processing by means of a processor (e.g., a separate processor (not shown) or by means of processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be simultaneous. Petition 870250084746, dated 09 / 19 / 2025, p. 24 / 119 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 important to note that RAN 104 may include any number of eNode-Bs, remaining consistent with one embodiment. eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communication with WTRUs 102a, 102b, 102c via wireless interface 116. In one 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 specific cell (not shown) and can be configured to handle radio resource management decisions, transfer 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) (PGW) 166. Although the above elements are represented 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 of Petition 870250084746, dated 09 / 19 / 2025, page 25 / 119 18 / 86 WTRUs 102a, 102b, 102c, carrier activation / deactivation, selection of a specific service gateway 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] The SGW 164 can be connected to each of the B eNodes 160a, 160b, 160c in RAN 104 via the S1 interface. The SGW 164 can generally route and forward user data packets to / from WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions, such as anchoring user planes during transfers between B eNodes, initiating 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. Additionally, 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 terminal without Petition 870250084746, dated 09 / 19 / 2025, p. 26 / 119 19 / 86 wire, it is considered that, in certain representative embodiments, such a terminal may use (for example, temporarily or permanently) wired communication interfaces 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 may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or an interface with a Distribution System (DS) or other type of wired / wireless network that carries inbound and / or outbound traffic from the BSS. Traffic to the STAs originating from outside the BSS may arrive through the AP and be delivered to the STAs. Traffic originating from the STAs to destinations outside the BSS may be sent to the AP to be delivered to the respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the originating STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may 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 System (DLS) configuration.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 dynamically defined width. The primary channel can be the BSS operating channel and can be used by STAs to Petition 870250084746, dated 09 / 19 / 2025, p. 27 / 119 20 / 86 establish a connection with the AP. In certain representative modes, Carrier Sense Multiple Access and Collision Avoidance (CSMA / CA) can be implemented, for example, in 802.11 systems. For CSMA / CA, STAs (e.g., each STA), including APs, can detect the primary channel. If the primary channel is detected and / or determined to be occupied by a specific STA, the specific STA can back off. An STA (e.g., only one station) can transmit at any time on a given BSS.

[060] High Throughput (HT) STAs can use a 40 MHz wide channel for communication, for example, by combining 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 called 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 streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each stream separately. Streams can be mapped to the two 80 MHz channels, and data can be transmitted via 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] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. The operating channel bandwidths and carriers are reduced by Petition 870250084746, dated 09 / 19 / 2025, page 28 / 119 21 / 86 802.11af and 802.11ah differ from those used in 802.11ne and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, 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 may support Meter Type Control / Machine Type Communications (MTC), 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 bandwidths and / or limited bandwidths. MTC devices may include a battery with a lifespan exceeding a certain limit (e.g., to maintain a very long lifespan).

[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 operating mode with the lowest bandwidth. In the 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only support) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings may depend on the primary channel state.If the primary channel is busy, for example, due to an STA (which only supports 1 MHz operating mode) transmitting to the AP, all available frequency bands can be considered occupied, even if most of them remain idle and could be available. Petition 870250084746, dated 09 / 19 / 2025, p. 29 / 119 22 / 86

[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 available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available 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 important to note that RAN 113 may include any number of gNBs, remaining consistent with a modality. gNBs 180a, 180b, 180c may each include one or more transceivers for communication with WTRUs 102a, 102b, 102c via the 116 air interface. In a modality, gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may use beamforming to transmit to and / or receive signals from gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, can use multiple antennas to transmit to and / or receive wireless signals from the 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 the 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 Coordinated Multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c). Petition 870250084746, dated 09 / 19 / 2025, p. 30 / 119 23 / 86

[067] WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the spacing of OFDM symbols and / or the spacing of OFDM subcarriers can 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 or scalable lengths (e.g., containing a variable number of OFDM symbols and / or with variable absolute time duration).

[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., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c can use one or more of 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 / connect to gNBs 180a, 180b, and 180c, while also communicating / connecting to other RANs, 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 eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, eNode-Bs 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 support WTRUs 102a, 102b, 102c. Petition 870250084746, dated 09 / 19 / 2025, p. 31 / 119 24 / 86

[069] Each of the gNBs 180a, 180b, 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, transfer decisions, user scheduling in the UL and / or DL, network slicing support, DC, 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, the 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 the above elements are represented 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] AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in RAN 104 via an N2 interface and can serve as a control node. For example, AMF 182a, 182b can be responsible for authenticating users of WTRUs 102a, 102b, 102c, for supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), for selecting a specific SMF 183a, 183b, for managing the log area, for terminating non-access stratum signaling (NAS), for mobility management, 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 in 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. Petition 870250084746, dated 09 / 19 / 2025, page 32 / 119 25 / 86 (URLLC), services that rely on enhanced massive mobile broadband (eMBB) access, services for MTC access and similar services. AMF 182a, 182b may provide a control plane function to switch between RAN 113 and other RANs (not shown) that employ other radio technologies such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies such as WiFi.

[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 UE IP addresses, managing PDU sessions, controlling policy and QoS enforcement, providing DL data notifications, and similar functions. A PDU session type can be IP-based, non-IP-based, Ethernet-based, and similar.

[073] UPF 184a, 184b can be connected to one or more of 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, temporary packet storage (DL), mobility tethering, and similar functions.

[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, 102c Petition 870250084746, dated 09 / 19 / 2025, p. 33 / 119 26 / 86 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, 102c may be connected to a local DN 185a, 185b via UPF 184a, 184b, via the N3 interface to UPF 184a, 184b and an N6 interface between UPF 184a, 184b and DN 185a, 185b

[075] Considering Figures 1A-1D and the corresponding description of Figures 1A-1D, one or more, or all, of the functions described herein, in relation to one or more of: 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 device 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 may be designed to implement one or more tests of other devices in a laboratory environment and / or in a carrier network environment. For example, one or more emulation devices may perform one or more, or all, functions while fully or partially deployed and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more emulation devices may perform one or more, or all, functions while temporarily deployed / 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 perform tests using wireless over-the-air communications.

[077] One or more emulation devices can perform one or more, including all functions, while not implemented / deployed as Petition 870250084746, dated 09 / 19 / 2025, p. 34 / 119 27 / 86 part of a wired and / or wireless communication network. For example, emulation devices may be used in a test scenario in a test laboratory and / or in an undeployed (e.g., under test) wired and / or wireless communication network to implement the testing of one or more components. The emulation device(s) may be test equipment. Direct RF coupling and / or wireless communications via RF circuit assemblies (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 described herein may refer to the determination of a time or the determination of a period of time. The reference to the expiration of a timer described herein may refer to the determination that time has elapsed or that the period of time has expired. The reference to a timer described herein 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 version) compared to a later version / release of the technology (e.g., later NR version). The reference to a specific timer described herein may be given as an example of a timer.

[079] Systems, methods and tools are described herein relating to support for downtime while a wireless transmit / receive unit (WTRU) is registered in non-3GPP access (i.e., only in non-3GPP access).

[080] A device (for example, 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 request Petition 870250084746, dated 09 / 19 / 2025, page 35 / 119 28 / 86 registration (e.g., for a network entity), for example, via Stratum No Access (NAS) signaling. The registration request may include an initial duration (e.g., downtime 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., 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.A log 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 log update request can 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 of a second duration (for example, a wait time 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 Petition 870250084746, dated 09 / 19 / 2025, p. 36 / 119 29 / 86 associated with unavailability 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 first duration (e.g., based on the fact that the WTRU is associated with discontinuous coverage). The registration acceptance message may indicate that the update message should be avoided (e.g., after the first duration), for example, if the WTRU is associated with discontinuous coverage. The device can determine if the WTRU is available 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.A WTRU (Water Transfer Retention Time) can be considered available, for example, if the update message was received before the first duration expires. The device may send a rejection message, for example, related to 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 enabling an outage period feature with the second network. The registration request may indicate an initial outage duration associated with an outage period. The device may determine that an outage event is 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 for the period of time may be based on the determination that the outage event was triggered. The initial duration Petition 870250084746, dated 09 / 19 / 2025, page 37 / 119 30 / 86 downtime can be determined based on the determination that the device will be unavailable for that period of time. 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 second registration request to a second network. The second registration request may indicate enabling the downtime period feature 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 downtime information. The registration request can include a downtime information element that can indicate the downtime information. The downtime information can indicate a duration of unavailability, for example, associated with the WTRU. The device can send a notification to an entity (e.g., a mobility management entity). The notification can indicate that the WTRU is unavailable for a period of time. The device can receive (e.g., from the entity) a Petition 870250084746, dated 09 / 19 / 2025, p. 38 / 119 31 / 86 Response to notification. The response to the notification may indicate that the entity has accepted the WTRU unavailability. The response to the notification may indicate the duration of the tracking area update. The response to the notification may indicate that the entity has accepted the WTRU unavailability and the duration of the tracking area update. The device may send a registration acceptance message (e.g., to the WTRU), for example, based on the response to the notification. The registration acceptance message may indicate the duration of the tracking area update. 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 greater than or equal to 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 may determine that the WTRU is inaccessible, for example, based on the determination that a second duration has expired. The second duration may be associated with, or equal to, an unavailability period duration associated with the registration request. The device may send a... Petition 870250084746, dated 09 / 19 / 2025, p. 39 / 119 32 / 86 Connectivity Loss Report. The connectivity loss report may indicate a period of unavailability. The connectivity loss report may indicate that the period of unavailability was sent to a network exposure function. The device may receive a NAS message from the WTRU. The device may 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 the CONNECTED state, etc. The device may deregister the WTRU based on the determination that the second duration has expired.

[086] Systems, methods and tools are described here in relation to downtime support while a WTRU is registered on a non-3GPP access (i.e., only on 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 via a non-3GPP access network and / or based on the request including the information element of 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 unavailability 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...) Petition 870250084746, dated 09 / 19 / 2025, page 40 / 119 33 / 86 the downtime duration information element) determine to send a registration response, for example, which may include an indication that the downtime duration request has been accepted and that the network. The device may indicate acceptance of the downtime duration, for example, by sending an accepted downtime duration to a wireless transmit / receive unit (WTRU). The device may assign an accepted downtime duration that is greater than or equal to the requested downtime duration. The device may (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 in an idle state (e.g., a 5GMM-IDLE state).The device can (for example, based on the fact that the WTRU is inaccessible and in an idle state (e.g., 5GMM-IDLE 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) to 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 for the WTRU by an application function (AF). The device can receive an initial non-access stratum (NAS) message from the WTRU.The device may (e.g., based on receiving the initial NAS message) determine to stop duration tracking (e.g., stop the standby timer), consider the WTRU accessible and in a connected state (e.g., a 5GMM-CONNECTED state). The device may (e.g., alternatively), based on duration expiration (e.g., standby timer expiration), determine (e.g., Petition 870250084746, dated 09 / 19 / 2025, page 41 / 119 34 / 86 example, implicitly) the cancellation of the WTRU registration.

[088] An exemplary device may include a processor configured to perform one or more actions. For example, a device (e.g., a network device, such as a device comprising an AMF) may receive a registration request from a wireless transmit / receive unit (WTRU). The registration request may include unavailability information (e.g., an unavailability period duration information element). 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 include 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 the receipt of the registration request by the non-3GPP access network and the registration request comprising the downtime duration information element. The indication of acceptance of the downtime duration request may indicate an accepted downtime duration. The accepted downtime duration may be greater than or equal to 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: interrupt tracing. Petition 870250084746, dated 09 / 19 / 2025, p. 42 / 119 35 / 86 of the duration (e.g., stopping the timer), determine if the WTRU is accessible, or determine if the WTRU is in the CONNECTED state. The device (e.g., the processor) can be further configured to implicitly deregister the WTRU based on the timer expiration.

[090] Systems, methods and tools are described here in relation 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 performed with more than two (e.g., three (3)) parties involved, such as 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 the 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 unavailability period (e.g., a period of time during which the WTRU is unavailable).

[092] Systems, methods and tools are described herein relating to the management of an unavailability period for one or more scenarios, such as when a wait 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 feature, if (e.g., when) a WTRU is registered on Petition 870250084746, dated 09 / 19 / 2025, page 43 / 119 36 / 86 various networks (e.g., both evolved packet system (EPS) and fifth-generation system (5GS)), for analytics support (e.g., Network Data Analysis (NWDAF) function) for the unavailability feature, if (e.g., when) a remote WTRU and / or a relay WTRU enters the unavailability period, if (e.g., when) a Mobile Device-Only Initiated Connection Mode (MICO) and / or the Strictly Periodic Log Timer feature 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., required) events, such as one or more of the following: (a) silent modem reboot; (b) security patch updates; (c) OS 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 OS update, a silent reboot on the modem or modem software updates (e.g., also called binary updates) can be performed with multiple (e.g., three (3)) parties involved, such as the device, the operator and the application function.

[095] A WTRU can transfer a binary. The time it takes for the WTRU 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 execute it (e.g., because storage capacity or battery level is low). Petition 870250084746, dated 09 / 19 / 2025, page 44 / 119 37 / 86 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 become unavailable without prior knowledge of the core network and / or the application function. WTRU unavailability may impact critical operations of an application server, for example, if the application server depends on WTRU availability during the unavailability period (e.g., a period during which the WTRU is unavailable).

[096] A network (e.g., the 5G System) may allow a WTRU to provide a period of unavailability (e.g., duration of unavailability) to the network, for example, in a 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 period of unavailability, for example, if an event is triggered on the WTRU that makes it 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 Unavailability Period to the network, for example, if the WTRU can store its contexts.The network (e.g., the Access and Mobility Function (AMF)) may take into account the Downtime Duration, for example, when determining the duration of a Periodic Log Update (e.g., the 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., after the event making the WTRU unavailable is completed in the WTRU or the event is postponed). Petition 870250084746, dated 09 / 19 / 2025, p. 45 / 119 38 / 86 for 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 Period in the Registration Request message. Depending on the WTRU status, the Registration procedure may be an Initial Registration procedure or a Mobility Registration Update procedure.

[097] AMF can provide an indication of the Strictly Periodic Registration duration (e.g., Strictly Periodic Registration timer indication) to the WTRU, for example, along with the Periodic Registration timer value. The Periodic Registration timer feature can be applied, for example, if (e.g., when) the WTRU uses MICO mode. AMF can provide the indication to the WTRU based on the expected behavior of the WTRU. For example, AMF may (e.g., wish to) configure the WTRU to be available for downlink data (e.g., in CM-CONNECTED mode) every hour (e.g., every hour) to receive downlink data. The Periodic Registration duration feature (e.g., timer) can be useful, for example, if (e.g., when) the WTRU uses MICO mode. The Periodic Registration duration feature (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 logging timer of 4 hours and (e.g., always) applies a 10-minute active timer, it can be known that the WTRU will be available every 4 hours for 10 minutes. By enabling the strictly periodic logging duration feature (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 Petition 870250084746, dated 09 / 19 / 2025, page 46 / 119 39 / 86 other network functions to collect data. The data collected by NWDAF can be used by NWDAF to determine analytical information. Analytical information may include statistics and predictions.

[099] AMF can be an example of a network function (NF) from which NWDAF can collect data. NWDAF can use the AMF's Namf_EventExposure service to obtain data from AMF. NWDAF can provide an 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 slicing 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: load level statistics and predictions for the first instance of the network slice; load level statistics and predictions for the second network slice; load level statistics and predictions for the third network function; load level statistics and predictions for the fourth network function; communication statistics and predictions for the WTRU farm; and abnormal behavior statistics and predictions for the sixth WTRU.

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

[0102] A period of unavailability 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 given period of unavailability. A WTRU and a network (e.g., 5GC) can coordinate the period of unavailability and / or Petition 870250084746, dated 09 / 19 / 2025, page 47 / 119 40 / 86 is the architecture-level workflow for resource unavailability.

[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 a Registration Acceptance message.

[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 it 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., a 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 deregistered. 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 temporary data storage, downlink temporary data storage status reporting, etc. If there is a Loss of Connectivity event subscription for the WTRU by the AF, the AMF can trigger a Loss of Connectivity event report, which may include a... Petition 870250084746, dated 09 / 19 / 2025, p. 48 / 119 41 / 86 period of unavailability towards NEF. The period of unavailability can be reported to the respective signed AF.

[0105] A WTRU can (for example, choose to) store WTRU contexts (e.g., MM and SM contexts), for example, if (e.g., when) a WTRU is ready to execute an event (e.g., for OS update or device reboot). The way the WTRU stores the context may depend on the WTRU implementation. The WTRU can store some or all of the WTRU contexts in the USIM using the USIM functionality.

[0106] The WTRU may trigger a registration procedure to resume regular service, for example, as soon as the event that renders the WTRU unavailable is completed on the WTRU 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 is 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 wait durations are active (e.g., timers running). While non-access layer (NAS) wait durations (e.g., timers or other wait timers) are running on the WTRU (e.g., T3346 / T3347 / T3396, other wait 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 downlink paging / NOTIFICATION (DL), high signaling). Petition 870250084746, dated 09 / 19 / 2025, p. 49 / 119 42 / 86 priority UL or emergency services). A WTRU (for example, in this case) may refrain from sending (e.g., not sending) a registration request to the network for the duration of the downtime period.

[0108] The network may attempt to contact (e.g., unsuccessfully contact) the WTRU for terminated mobile services while the waiting period (e.g., timer) is running, for example, if a WTRU refrains from sending (e.g., does not send) an unavailability period to the network and performs actions that may cause the WTRU to become unavailable while the waiting period (e.g., timer) is running. The attempt to contact the WTRU for terminated mobile services may fail.

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

[0110] Downtime support can be provided while the WTRU is registered on a non-3GPP access and no other access (e.g., registered only on a 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 a non-3GPP access. The WTRU can (e.g., then) be accessible for mobile-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 on a non-3GPP access point can (for example, generally) remain in 5GMM-CONNECTED mode unless the WTRU disconnects from the network. Petition 870250084746, dated 09 / 19 / 2025, p. 50 / 119 43 / 86 not 3GPP.

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

[0112] A WTRU that is registered via non-3GPP access may indicate a period of unavailability to the network, for example, so that the network and the WTRU can maintain the registration status of the WTRU and / or so that the network understands that the WTRU may not be accessible for mobile terminated communication.

[0113] Downtime support can be provided for MUSIM devices. One or more examples described herein may indicate how a downtime feature can be managed for MUSIM devices registered on two (2) or more different networks.

[0114] In some examples, multiple networks (e.g., both) may support the downtime feature. In some examples, both networks may receive the same downtime period duration. In some examples, the downtime 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 downtime feature.

[0115] A WTRU MUSIM 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 considered) during communication with the network regarding 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 (e.g., all networks support the Petition 870250084746, dated 09 / 19 / 2025, p. 51 / 119 44 / 86 feature unavailability, or one or more networks do not support the unavailability feature) may indicate a period of unavailability for the network(s), for example, so that the network(s) and the WTRU MUSIM can maintain the WTRU MUSIM registration status and / or so that the network understands that the WTRU is not accessible for mobile terminated communication.

[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 both EPS and 5GS. A WTRU registered on EPS can be considered to be in S1 mode. A WTRU registered on 5GS can be considered to be 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 NAS S1 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 mobile-terminated communication (e.g., when) the WTRU is performing the event that renders it temporarily unavailable.

[0119] Analytics (e.g., NWDAF) can be supported for the downtime feature. 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 duration in a log request or by providing a downtime duration in Petition 870250084746, dated 09 / 19 / 2025, page 52 / 119 45 / 86 a request to cancel registration.

[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 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 with the network within the duration of the unavailability period).

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

[0122] Downtime feature support can be provided for relay WTRUs. One or more examples described herein may indicate how to manage the scenario for relay WTRUs, manage 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 (for example, via the network) to use Petition 870250084746, dated 09 / 19 / 2025, page 53 / 119 46 / 86 a recording duration feature (e.g., strictly periodic) (e.g., timer). As described above, a strictly periodic recording timer feature can be configured so that a WTRU is in CMCONNECTED mode and available to receive downlink data at predictable times. This feature can be useful for devices that use a MICO mode and / or enter long periods of hibernation, for example, to save power. The occasions when these devices (e.g., WTRUs) are available for downlink data may be very rare (e.g., with intervals of hours or even days). If the WTRU requests a period of unavailability that overlaps with the period when the WTRU is expected to be available for downlink data, this may cause the WTRU to miss downlink data that may be sent from a server that predicted the WTRU would be available at the expected time.

[0124] Multiple parties (e.g., three parties) may be involved in the execution of certain events (e.g., operations), such as an OS 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 WTRU unavailability may impact 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 unavailability period (e.g., a period of time during which the WTRU is unavailable). Petition 870250084746, dated 09 / 19 / 2025, p. 54 / 119 47 / 86

[0126] Systems, methods and tools are described herein related to the management of the downtime feature for multiple scenarios, such as whether (e.g., when) a wait duration (e.g., timer) can be running, whether (e.g., when) the WTRU can be registered on a network (e.g., 5GS) via (e.g., only) non-3GPP access, whether (e.g., when) a MUSIM device can be registered on multiple networks with and without downtime feature support, whether (e.g., when) the WTRU is registered on multiple networks (e.g., EPS and 5GS) for analysis support (e.g., NWDAF) for the downtime feature, whether (e.g., when) the remote WTRU and / or the relay WTRU enter a downtime period, whether (e.g., when) the MICO mode and / or the strictly periodic registration duration feature (e.g., timer) is enabled, etc.

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

[0128] AMF can (for example, if / when general congestion control at the NAS level is active) reject a NAS message and include a value for the mobility management (MM) wait duration (e.g., timer, e.g., T3346) in the rejection messages. WTRU can then start tracking a duration (e.g., the timer, e.g., T3346). Petition 870250084746, dated 09 / 19 / 2025, page 55 / 119 48 / 86 with the value received in MM rejection messages (e.g., 5GMM). The WTRU may refrain from (e.g., be prevented from) sending one or more (e.g., certain) NAS messages (e.g., a Mobility Registration Update), for example, if (e.g., when) the wait duration (e.g., timer) is running. The WTRU may respond to network-initiated signaling (e.g., a page that was triggered by downlink data), for example, if (e.g., when) the wait duration (e.g., timer) is running.

[0129] A WTRU can inform the network about the start of an unavailability period, for example, based on the detection of an event in the WTRU that could (for example, would make) the WTRU unavailable for a certain period of time. The WTRU can inform the network about the start of the unavailability period via the REGISTRATION REQUEST message (for example, including the IE unavailability period), for example, if the WTRU manages 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, unable to inform) the network (e.g., AMF) about the WTRU's unavailability in one or more scenarios. For example, WTRU may refrain from triggering (i.e., not be allowed to trigger) the UL NAS signaling to send the Mobility Log 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 make it 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 the action that makes it unavailable (e.g., a software update). Petition 870250084746, dated 09 / 19 / 2025, p. 56 / 119 49 / 86

[0131] A WTRU can (for example, be allowed to) send a Mobility Log Update to the network, for example, if (for example, even when) the wait duration (e.g., timer) is running. The WTRU can generate NAS signaling to inform the network about the downtime period and then to inform the network that the WTRU is available again. The signaling can be generated while the wait duration (e.g., timer) is running. In some examples, multiple WTRUs in the same area may be running the same software update. Downtime and availability signaling from multiple WTRUs can trigger a significant amount of NAS signaling to be managed by the network, for example, even during a congestion situation.

[0132] A WTRU may (for example, be permitted to) send a REGISTRATION REQUEST message (for example, including the IE downtime period) while NAS-level congestion control 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) subsequent requests, uplink data status information, and / or permitted PDU session status information. The WTRU may (for example, also) be configured (for example, restrict itself) to (for example, only) request a Downtime Duration greater than or equal to the remaining time in the NAS standby duration (for example, timer, for example, T3346).

[0133] The AMF (for example, based on receipt of a Registration Request that includes a Periodic Unavailability Request while the standby timer is running) may respond to the WTRU with information including, for example, one or more of the following (for example, Petition 870250084746, dated 09 / 19 / 2025, p. 57 / 119 50 / 86 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 wait duration (e.g., timer, e.g., T3346) can continue to run and not be reset, e.g., indicating to WTRU that WTRU can still consider NAS-level congestion control as active; (iii) a new wait duration value (e.g., timer) (e.g., T3346) to indicate to WTRU that WTRU can still consider NAS-level congestion control as active; (iv) an indication that WTRU can inform AMF when WTRU becomes available again, e.g., even if the wait duration (e.g., timer) is running (e.g., T3346);and / or (v) an indication that the WTRU CANNOT inform the AMF when the WTRU becomes available again if the wait duration (e.g., timer) is running (e.g., T3346).

[0134] The previous illustrative indications 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 NAS-level congestion control may be active. As shown in Figure 2, in 210, NAS-level congestion control 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). NAS-level congestion control may be active on the WTRU. The duration (e.g., or other durations) may be running (e.g., T3346 and / or other wait timer(s) may be running). The WTRU may refrain from Petition 870250084746, dated 09 / 19 / 2025, p. 58 / 119 51 / 86 trigger (i.e., do not trigger, may not be allowed to trigger) signaling at the NAS level, for example, except in cases intended for high-priority access, emergency services, and / or the WTRU is responding to paging from the network side.

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

[0137] At 230 in Figure 2, the WTRU can trigger the Registration Request procedure towards the AMF. The WTRU can provide the IE downtime period to inform the network about the duration of the WTRU downtime. The WTRU (e.g., if the standby timer is running on the WTRU) can (e.g., determine) set the downtime period to the duration determined at 220, for example, if the duration is greater than the remaining time in the standby duration (e.g., a timer such as T3346). The WTRU can otherwise (e.g., determine) request a time greater than or equal to the remaining time in the standby duration (e.g., timer).

[0138] In 240 in Figure 2, the AMF can take into account the presence of the IE unavailability period, refrain from rejecting (e.g., not rejecting) the registration request and / or respond with the REGISTRATION ACCEPT message. The AMF can (e.g., also) use the REGISTRATION ACCEPT message to indicate that the previously provided wait duration (e.g., timer, e.g., T3346) can continue to run and not be reset, to provide a new wait 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 Petition 870250084746, dated 09 / 19 / 2025, p. 59 / 119 52 / 86 or to provide an indication of whether the WTRU can inform the AMF when the WTRU is available again, for example, even if the wait 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 of the modem, security patch updates, OS update, modem software updates and / or device reboot upon changes to modem settings via OMA-DM.

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

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

[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 may consider the congestion situation applicable and / or how long the restriction is applicable. The WTRU may begin tracking a wait duration (e.g., a wait timer), for example, based on receiving the duration (e.g., 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 it unavailable for a (for example, specified) period of time. The WTRU can detect the amount of time during which 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 wait time (e.g., timer value), for example, based on the wait time (e.g., timer) running and / or based on the wait time (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 can receive a registration acceptance message from the network. The registration acceptance message Petition 870250084746, dated 09 / 19 / 2025, pp. 61 / 119 The 54 / 86 log may include an indication that the previously provided wait duration (e.g., timer, e.g., T3346) may continue to run and not be reset, which may cause WTRU to continue applying NAS-level congestion control or trigger it. The log acceptance message may include a different (e.g., new) value for the wait duration (e.g., timer) (e.g., T3346) to indicate to WTRU that WTRU may still consider NAS-level congestion control active, which may cause WTRU to continue applying NAS-level congestion control and / or assign a different (e.g., new) value to the wait duration (e.g., timer).The registration acceptance message may include an indication that the WTRU can inform the AMF when the WTRU is available again, for example, even if the wait duration (e.g., timer) is running (e.g., T3346), which may cause the WTRU to send a registration update request to the network when the unavailability event ends. The registration update request may refrain from including (e.g., not include) the duration of the unavailability period.The registration acceptance message may include an indication that the WTRU may not inform (e.g., not notify) the AMF when the WTRU becomes available again if the wait duration (e.g., timer) is running (e.g., T3346), which may cause the WTRU not to send a registration update request to the network when the unavailability event ends while the wait duration (e.g., timer) is still running. The WTRU may (e.g., determine) send a registration update request to the network when the wait duration (e.g., timer) expires. The registration update request may refrain from including (e.g., not include) the duration of the unavailability period. Petition 870250084746, dated 09 / 19 / 2025, p. 62 / 119 55 / 86

[0146] Downtime support may be provided while the WTRU is registered (e.g., only) on non-3GPP access. A network (e.g., a 5G system) may allow (e.g., indicate to) a WTRU to send a Registration Request to the AMF via non-3GPP access. The Registration Request may include downtime information (e.g., an information element (IE) of the downtime duration).

[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. For example, the AMF can be triggered to perform one or more of the following actions.

[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 greater than or equal to the requested downtime duration.

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

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

[0151] AMF may consider the WTRU inaccessible until the WTRU sends an initial NAS message. Examples of initial NAS messages include, for example, a registration request, a service request, and / or a request Petition 870250084746, dated 09 / 19 / 2025, page 63 / 119 56 / 86 control plan service.

[0152] AMF may consider the WTRU to have its registration cancelled (e.g., in the 5GMM-DEREGISTERED state), for example, if the duration (e.g., standby timer) expires before AMF receives an initial NAS message from the WTRU.

[0153] Figure 3 illustrates an example of when the downtime feature is used by a WTRU registered via non-3GPP access. For example, Figure 3 shows support for a downtime feature 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, WTRU can be registered in 5GCN via non-3GPP access (e.g., only). Non-3GPP access can be trusted or untrusted.

[0155] In 320, an event may occur in the WTRU that may make it unavailable for a (for example, specified) 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 (for example, the unavailability period duration information element).

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

[0158] In 350, AMF may send a Registration Acceptance Message to WTRU. The Registration Acceptance Message may indicate acceptance of the requested downtime duration and / or may provide WTRU with a downtime duration value that WTRU may use. AMF may Petition 870250084746, dated 09 / 19 / 2025, p. 64 / 119 57 / 86 (for example, now) consider WTRU as being 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 Loss of Connectivity event report towards NEF, for example, if there is a Loss of Connectivity event subscription for the WTRU by the AF. The Loss of Connectivity event report can include a period of unavailability. The period of unavailability can (for example, also) be reported to the subscribed AF.

[0159] In 360, 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 software updates and / or device reboot after changes to 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.,) 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] Downtime support 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 (by Petition 870250084746, dated 09 / 19 / 2025, p. 65 / 119 58 / 86 example, among multiple networks). The registration request may include a duration of the downtime period. The first network may respond with a registration acceptance message and / or a periodic registration duration (e.g., timer), which may be greater than or equal to the requested downtime period. WTRU may (e.g., then) send a registration request to a second network. WTRU may include a second downtime period duration in the request to the second network. WTRU may (e.g., choose to) set the duration of the second downtime period to a value greater than or equal to the periodic registration timer received from the first network. This approach may help ensure that the second network refrains from indicating (e.g., does not indicate) to WTRU that WTRU may re-register before (e.g., much earlier) the time associated with (e.g., requested by) the first network.

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

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

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

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

[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. Petition 870250084746, dated 09 / 19 / 2025, p. 66 / 119 59 / 86

[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, the WTRU can determine the duration of the second downtime period. The WTRU can set the duration of the second downtime period to a value greater than or equal to the periodic registration timer received from the first network. Setting the duration of the second downtime period in this way can ensure that the WTRU has sufficient time to contact the multiple (e.g., both) networks at the end of the downtime period.

[0171] In 460, WTRU can send a registration request to the second network. The registration request can include the duration of 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 periodic second log duration (e.g., timer), which can be greater than or equal to the duration of the second downtime period.

[0173] In some examples, multiple networks (e.g., both or all) may support an unavailability period feature. 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 on multiple (e.g., two) different networks (e.g., 5G). Other configurations may be implemented.

[0174] Figure 5 illustrates an example of unavailability coordination in Petition 870250084746, dated 09 / 19 / 2025, page 67 / 119 60 / 86 multiple networks when multiple networks (e.g., both 5G networks) support an unavailability feature.

[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 feature.

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

[0177] In 530, the WTRU MUSIM can select / choose the first network, for example, AMF-1. The WTRU can send a REGISTRATION REQUEST message to AMF-1. The message can include the IE duration of the downtime period, for example, along with an initial delay (e.g., Δt). The Initial Delay (At) can inform the AMF-1 network that the downtime period may account for the delay with the given initial delay duration value and / or the actual duration for which the WTRU would be unavailable, e.g., downtime period duration + At. The Initial 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, At can be calculated as At = (N=1) x (Time requested (e.g., required) for (cancellation of) registration informing about unavailability for AMF-2 + registration to inform the network (AMF2) 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 example scenario shown in Figure 5, there may be one more (1) event of. Petition 870250084746, dated 09 / 19 / 2025, pp. 68 / 119 61 / 86 registration to inform AMF-2 about the period of unavailability. The time associated with (e.g., required (e.g., requested) 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) for which WTRU may wait for a response from the network. WTRU MUSIM may consider a cancellation of registration (e.g., implicit), for example, if there is no response from the network.

[0178] On 440, AMF-1 can respond with the message REGISTRATION ACCEPT. AMF-1 can (for example, subsequently) release the RRC signaling connection.

[0179] In 550, the WTRU MUSIM can send a Registration Request to the second AMF, for example, AMF-2, as the last instance that needs to be informed about the unavailability. The initial delay can be set to zero (0), for example, Δt = 0.

[0180] At 560, AMF-2 can respond with the REGISTRATION ACCEPT message. AMF-2 can (e.g., subsequently) release the connection (e.g., the RRC signaling connection).

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

[0182] In 580, WTRU MUSIM may send a REGISTRATION REQUEST message to AMF-2 (e.g., refraining from including (e.g., not including) the IE duration of the unavailability period), informing Petition 870250084746, dated 09 / 19 / 2025, pp. 69 / 119 62 / 86 for the network that WTRU MUSIM is (e.g., currently) available. There may be a sequence for exiting unavailability. For example, the network last informed of the unavailability period may be the first to be informed of availability. In the example scenario, AMF-2 may have priority over AMF-1 in informing of WTRU availability. The initial delay given to AMF-1 may take into account the delay in informing the other network of the unavailability, which may be followed by availability and / or corresponding procedure times.

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

[0184] With reference to Figure 5, an example is given in which multiple networks (e.g., both or all) can support an unavailability period feature. A WTRU MUSIM can perform one or more of the following actions.

[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 feature. An event can occur on the WTRU that can make it unavailable for a (e.g., determined) period of time. The WTRU (e.g., as a MUSIM device) can communicate with the network (e.g., 5GS) sequentially. The WTRU MUSIM can take into account a delay in relation to the (cancellation)registration procedure.

[0186] As shown in Figure 5, in 530 / 540, the WTRU MUSIM can select / choose the first network (e.g., AMF-1) and send a message. Petition 870250084746, dated 09 / 19 / 2025, pp. 70 / 119 63 / 86 REGISTRATION REQUEST, which may include the IE duration of the downtime period and / or an initial delay At. The initial delay (At) may inform the AMF-1 network that the downtime period may be responsible for the delay with the initial delay duration value provided. The actual duration for which the WTRU may be unavailable may be the downtime period duration + At. The initial delay may be calculated, for example, by taking into account the number of pending registration (cancellation) procedures that the WTRU MUSIM may (e.g., need to) perform to inform other networks about the downtime.

[0187] In the example shown in Figure 5, for example, At can be determined as At = (N=1) x (Time requested (e.g., required) for the (cancellation of) registration informing about the unavailability to 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 example scenario shown in Figure 5, there may be one more (1) registration event to inform AMF-2 about the unavailability period.

[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) for which the WTRU may wait for a network response. The WTRU MUSIM 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 ACCEPT message.

[0189] As shown in Figure 5, in 550 / 560, WTRU MUSIM can send a Registration Request to the second AMF (e.g., AMF-2), as Petition 870250084746, dated 09 / 19 / 2025, pp. 71 / 119 64 / 86 is the last instance that needs to be informed about the unavailability. The initial delay can be set to zero (0), for example, Δt = 0. The AMF-2 can respond with the REGISTRATION ACCEPT message. The AMF-2 can (for example, subsequently) release the connection (for example, RRC signaling connection).

[0190] As shown in Figure 5, on 570 / 580 / 590, the WTRU can (e.g., successfully) execute the event that made it unavailable, for example, silent modem reboot, security patch updates, OS update, modem software updates, and / or device reboot after modem configuration changes via OMA-DM. The WTRU MUSIM can send a REGISTRATION REQUEST message to AMF-2 (e.g., without including the downtime duration IE), informing the network that the WTRU MUSIM is (e.g., now) available. There may be a sequence to exit unavailability. For example, the network informed last about the downtime period may be the first to be informed about availability. For example, as shown in Figure 5, AMF-2 may have priority over AMF-1 in informing about WTRU availability.The initial delay provided to AMF-1 may take into account the delay in receiving information from the other network about the unavailability, for example, followed by availability and the corresponding procedure times. WTRU MUSIM may send a REGISTRATION REQUEST message to AMF-1 (e.g., without including the IE of the unavailability period duration), informing the network that WTRU MUSIM is (e.g., now) available.

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

[0192] Figure 6 illustrates an example of unavailability coordination between multiple networks when one of the networks does not support an unavailability feature of a WTRU MUSIM. Petition 870250084746, dated 09 / 19 / 2025, p. 72 / 119 65 / 86

[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) on 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 a deadlock feature or a 5G network (e.g., AMF) that does not support the deadlock feature.

[0194] In 620, an event may occur in the WTRU that may render it unavailable for a (e.g., specified) period of time. The WTRU (e.g., as a MUSIM device) may communicate sequentially with the network (e.g., 5GS). The WTRU MUSIM may take into account the delay in relation to the deregistration procedure.

[0195] In 630, WTRU MUSIM can select / choose the first network (e.g., AMF-1) to which to send a REGISTRATION REQUEST message, for example, including the IE of the downtime period duration and / or an initial delay Δt. The initial delay (Δt) can inform the AMF-1 network that the downtime period may be responsible for the delay with the initial delay duration value provided. The actual duration for which WTRU may be unavailable may be the downtime period duration + Δt. The initial delay Δt can be calculated, for example, by taking into account the number of pending (deregistration) procedures that WTRU MUSIM 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 downtime feature (e.g., EPS or 5GS with unsupported feature).The initial delay may take into account the associated duration (e.g., the time it may take) for the WTRU to be deregistered from the other network.

[0196] In 640, AMF-1 can respond with a message Petition 870250084746, dated 09 / 19 / 2025, pp. 73 / 119 66 / 86 REGISTRATION ACCEPT. The AMF-1 can (for example, subsequently) release the RRC signaling connection.

[0197] In 650, the second network (AMF-2 / MME) may not support the feature. 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).

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

[0199] In some instances, a deregistration may be performed first. WTRU MUSIM may deregister the network that does not support the downtime feature. WTRU MUSIM may (for example, subsequently) perform the downtime procedure with the second supporting network.

[0200] In 660, WTRU may (for example, successfully) execute the event that made it unavailable, for example, silent modem reboot, security patch updates, OS update, modem software updates and / or device reboot after modem configuration changes via OMA-DM. Petition 870250084746, dated 09 / 19 / 2025, pp. 74 / 119 67 / 86

[0201] In 670, the WTRU MUSIM can send a REGISTRATION REQUEST message to AMF-2 (e.g., omitting the downtime duration IE), informing the network that the WTRU MUSIM is (e.g., now) available. There may be a sequence for exiting downtime. For example, the network informed last 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 the WTRU of availability. The initial delay provided to AMF-1 may take into account the delay in informing the other network of the downtime, for example, followed by availability and corresponding procedure times.

[0202] On 680, WTRU MUSIM can send a REGISTRATION REQUEST message to AMF-1 (e.g., without including the downtime duration IE), which can inform the network that WTRU MUSIM 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 feature. 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., the WTRU) can have two (2) active USIM cards. The WTRU MUSIM can be successfully registered on two (2) different networks, e.g., AMF-1 and AMF2 / MME. In an exemplary scenario, the second network can be an EPS that does not support an unavailability feature or a 5G network (e.g., AMF) that does not support the unavailability feature. 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. WTRU MUSIM can take into account the delay relative to Petition 870250084746, dated 09 / 19 / 2025, pp. 75 / 119 68 / 86 registration (cancellation) procedure.

[0205] As shown in Figure 6, on 630 / 640, the WTRU MUSIM can select the first network, for example, AMF-1, and send a REGISTRATION REQUEST message, for example, including the IE of the duration of the unavailability period and / or an initial delay Δt. The initial delay (Δt) can inform the AMF-1 network that the unavailability period may be responsible for the delay with the initial delay duration value provided. The actual duration for which the WTRU may be unavailable can be calculated as the duration of the unavailability period + Δt. The initial delay Δt can be calculated, for example, by taking into account the number of pending (deregistration) procedures that the WTRU MUSIM may (e.g., need to) perform to inform other networks about the unavailability. For example, as shown in Figure 6, the other network does not support the unavailability feature (e.g., EPS or 5GS with unsupported feature).The initial delay may take into account the time it may take to cancel the WTRU MUSIM registration from the other network. AMF-1 may respond with the REGISTRATION ACCEPT message. AMF-1 may (e.g., subsequently) 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 feature. The WTRU can trigger deregistration towards the network, for example, by sending a DEREGISTRATION REQUEST message, for example, with a cause code such as shutdown.

[0207] In some instances, WTRU MUSIM and AMF-2 / MME may support MICO mode. WTRU MUSIM 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 uptime for MICO mode. The uptime may not coincide with the downtime. Petition 870250084746, dated 09 / 19 / 2025, pp. 76 / 119 69 / 86 Active time can start after the downtime period has ended. The network can (for example, alternatively) set the periodic registration duration (e.g., timer duration) to be greater than or equal to the downtime period, 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.

[0208] In some examples, a deregistration step may be the first step. For example, WTRU MUSIM may deregister the network that does not support the downtime feature. WTRU may (for example, subsequently) perform the downtime procedure with the second supporting network.

[0209] As shown in Figure 6, on 660 / 670 / 680, the WTRU can (e.g., successfully) execute the event that made it unavailable, for example, silent modem reboot, security patch updates, OS update, modem software updates, and / or device reboot after modem configuration changes via OMA-DM. The WTRU MUSIM can send a REGISTRATION REQUEST message to AMF-2 (e.g., without including the downtime duration IE), informing the network that the WTRU MUSIM is (e.g., now) available. There may be a sequence to exit unavailability. For example, the network informed last about the downtime period may be the first to be informed about availability. For example, as shown in Figure 6, AMF-2 / MME may have priority over AMF-1 in informing about WTRU availability.The initial delay provided to AMF-1 may take into account the delay in receiving information from the other network regarding unavailability, for example, followed by availability and the corresponding procedure times. WTRU MUSIM. Petition 870250084746, dated 09 / 19 / 2025, p. 77 / 119 70 / 86 can send a REGISTRATION REQUEST message to AMF-1 (e.g., without including the downtime duration IE), informing the network that WTRU MUSIM 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 already registered on the EPC, for example, the AMF may receive an initial registration request from a WTRU whose EMM status is EMM-REGISTERED. The AMF can detect that the WTRU is registered on the EPS, for example, if the Initial Registration Request includes the WTRU's State Information element with the N1 mode register bit of the WTRU's State Information element set to 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 the need to execute an event that may render the WTRU unavailable for a period. The WTRU can (for example, determine) send a duration of the unavailability period 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] AMF may (e.g., based on a registration request) send a notification to MME (e.g., via the N26 interface), for example, if AMF detects that the WTRU is capable of operating in S1 and N1 modes, has a common registration for 5G and EPS access, or has dual registration, and, in instances, AMF receives a registration request from the WTRU that includes the duration of the unavailability period. The notification may indicate to MME that the WTRU is about to become unavailable for a period of time. The notification may include the duration of the unavailability period or the Periodic Registration Time that AMF may send to Petition 870250084746, dated 09 / 19 / 2025, pp. 78 / 119 71 / 86 WTRU in the Registration Response. The MME can determine (e.g., be informed) how long the WTRU will be unavailable, for example, based on the duration of the unavailability period or the Periodic Registration Time in the notification. The MME can perform one or more (e.g., any combination) of the following actions based on receipt of the notification.

[0213] For example, the MME may (e.g., begin to) consider the WTRU inaccessible and / or may reject a (e.g., 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 (e.g., also) adjust a duration (timer, e.g., the implicit cancellation timer) that may 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 it does not agree to maintain the WTRU context while WTRU is unavailable and / or that AMF may indicate to WTRU that WTRU may consider WTRU as having its registration cancelled from EPS, for example, and that WTRU may transition from EMM-REGISTERED to EMM-REGISTERED. MME's response may (for example, also) include a different (e.g., new) value for the duration of the periodic tracking area update (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 Petition 870250084746, dated 09 / 19 / 2025, pp. 79 / 119 72 / 86 completed; an indication that the downtime period was rejected by MME and / or that WTRU considers WTRU to have its registration cancelled from the EPS, for example, and the transition from the EMM-REGISTERED state to the EMMDEREGISTERED state; and / or a value (e.g., new value) that WTRU can assign to its EPS the duration value of the periodic update of the tracking area (e.g., timer).

[0216] The WTRU may conclude the downtime period. The WTRU may (for example, after the downtime period ends) perform a registration area update procedure with 5GS and a tracking area update procedure with EPS. The tracking area update procedure may be performed, for example, (for example, only) if the WTRU has not transitioned to the EMM-DEREGISTERED state. The WTRU may perform a registration procedure with EPS, for example, if the WTRU has transitioned to the EMM-DEREGISTERED 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: the NAS EPS signaling may not be changed (e.g., it does not need to be changed); 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 in which 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. WTRU can be successfully updated in both 5GMM and EMM. Petition 870250084746, dated 09 / 19 / 2025, pp. 80 / 119 73 / 86 (for example, the registration state in S1 mode is EMM-REGISTERED, and the registration state in N1 mode is 5GMM-REGISTERED). The WTRU may currently be encamped in a 5G cell in idle mode. 5GS or EPS may indicate (for example, in the last registration procedure) support for interoperability with N26 as part of the 5GS network feature support IE or EPS network feature support IE with the N26 WK bit set to “interoperability without N26 interface not supported”.

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

[0221] In 730, WTRU can trigger the Registration Request procedure towards AMF. WTRU can provide the downtime period IE to inform the network about the duration of WTRU's downtime.

[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 the expected unavailability period for WTRU, 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 (for example, begin to) consider the WTRU inaccessible. The MME may reject (for example, 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 (for example) Petition 870250084746, dated 09 / 19 / 2025, pp. 81 / 119 74 / 86 example, also) adjust a duration (e.g., a timer, for example, the implicit cancellation timer) associated with the WTRU, for example, by assigning to the duration (e.g., assigning to 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 WTRU as having its registration cancelled from EPS and / or that WTRU (for example, may) transition from EMM-REGISTERED state to EMM-REGISTERED. MME's response may (for example, also) include a value (e.g., new) for the duration of the periodic update of the tracking area (e.g., timer) for AMF to send to WTRU.

[0226] On 760, MME can respond to the notification from AMF (e.g., via the N26 interface). MME’s response may include information indicating, for example, whether the WTRU’s unavailability request was accepted / rejected by MME and / or the duration of the periodic recording 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 EMMREGISTERED; 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 the EMM-REGISTERED state to the EMM-DEREGISTERED state; and / or a new value that WTRU may assign to the WTRU's EPS tracking area periodic update timer value. Petition 870250084746, dated 09 / 19 / 2025, p. 82 / 119 75 / 86

[0228] On 780, 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 software updates and / or device reboot upon changes to modem settings via OMA-DM.

[0229] In 790, the WTRU that exits the downtime period can execute the registration procedure with 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 MME via AMF) trigger an EMM Tracking Area Update Procedure (for example, if the EMM status is EMM-REGISTERED) or an EMM ATTACH procedure (for example, if the EMM status is EMM-DEREGISTERED) to indicate to MME that the downtime period has ended and that the WTRU is accessible again.

[0231] Analytics (e.g., NWDAF) can be supported for the downtime feature. The AMF Namf_EventExposure service can support an invoking NF (e.g., NWDAF) subscribing to an event (e.g., a WTRU downtime event). AMF can report WTRU downtime information to the invoking NF 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 signs or invokes the Namf_EventExposure signing service operation and provides an Event ID, such as (for example, equal to) one or more of the following: Registration Status Report, a Report of Petition 870250084746, dated 09 / 19 / 2025, p. 83 / 119 76 / 86 Connectivity Status, an Accessibility Report, UEs in Area Report, 5GS User Status Report, Frequent Mobility Log Report, UE Access Behavior Trends, and / or UE MM Transaction Report. Additionally and / or alternatively, an Event ID (e.g., a new Event ID) can be defined (e.g., WTRU unavailability information). AMF can provide WTRU unavailability information if (e.g., when) the invoking NF signs or invokes the Namf_EventExposure Subscription service operation and provides an Event ID (e.g., that equals “WTRU unavailability information”).

[0233] The downtime information provided by AMF to the NF invoker for a WTRU may be, for example, one or more of the following: equal to the duration of the downtime period requested by the WTRU; defined as an absolute time value based on the duration of the downtime period requested by the WTRU; defined as a value indicating how long AMF expects or needs to elapse until the downtime expires; and / or equal to a periodic log duration value (e.g., timer) provided to the WTRU by AMF.

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

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

[0236] AMF may indicate that WTRU should (e.g., wait) perform Petition 870250084746, dated 09 / 19 / 2025, p. 84 / 119 77 / 86 an initial registration if (for example, when) the downtime period ends, for example, if WTRU has informed 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 consuming 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 consuming NF may (e.g., be able to) generate more accurate statistics and / or predictions, for example, if the consuming NF (e.g., NWDAF) is informed of 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 the statistics and / or predictions to a consuming 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 consuming 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 a 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 Function load level statistics and predictions; Network load level statistics and predictions; WTRU communication statistics and predictions; and / or abnormal behavior statistics and predictions. Petition 870250084746, dated 09 / 19 / 2025, p. 85 / 119 78 / 86 Friday WTRU.

[0241] In 820, NWDAF may (for example, begin to) collect data that may be necessary to determine the information requested in 810. 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; Area UEs Report; 5GS User Status Report; Frequent Mobility Registration Report; UE Access Behavior Trends; UE MM Transaction Report; and / or “WTRU unavailability information”.

[0242] In 830, the AMF may receive a NAS Registration Request or a NAS Deregistration Request, which may include a period of unavailability. In examples, operations in 830 may occur before operations in 820.

[0243] On 840, an operation may depend on the operation on 820. 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 the information for one or more WTRUs. For example, if the action on 820 is a subscription operation, then 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 the information for one or more WTRUs. Petition 870250084746, dated 09 / 19 / 2025, p. 86 / 119 79 / 86

[0244] In 850, NWDAF can derive the analyses (e.g., statistics or predictions) that were requested in 810. The analyses can be derived based on downtime information and / or the indication of an expected action when WTRU is available.

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

[0246] An unavailability period feature 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 in which the WTRU may be unavailable.

[0248] In some instances, remote WTRUs and relay WTRUs can be connected (e.g., via the PC5 connection). Either a relay WTRU or a remote WTRU can 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 it unavailable for a period of time (e.g., a specified period).

[0252] In 920, the relay WTRU may enter the downtime period, for example, by sending a REGISTRATION REQUEST message to the AMF. The message may include the downtime period IE and / or the list of remote WTRUs that may be connected to the relay WTRU. Petition 870250084746, dated 09 / 19 / 2025, p. 87 / 119 80 / 86 relay, for example, via PC5. The list of remote WTRUs can inform AMF about connected remote WTRUs that may no longer be available via the relay WTRU.

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

[0254] In 940, AMF can respond with the REGISTRATION ACCEPT message, providing the list of remote WTRUs, for example, confirming the status of receiving the list.

[0255] In 950, the relay WTRU can inform connected remote WTRUs about the unavailability of the relay WTRU, for example, along with the duration of the unavailability 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 store UL activity in temporary storage, trigger selection for a different relay WTRU, establish a direct connection to the network (e.g., 5G), and / or provide unavailability period information (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 can be triggered in WTRU Petition 870250084746, dated 09 / 19 / 2025, pp. 88 / 119 81 / 86 remote, which may make it unavailable for a period of time (for example, a specified period).

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

[0262] In 1030, the remote WTRU can provide information about the unavailability to the relay WTRU (e.g., by means of an Unavailability Notification message), which may include the duration of the unavailability period and / or the 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 the unavailability) can temporarily store DL notifications / 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] A remote WTRU (for example, when becoming 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] Accounting can be provided for the expected availability of the WTRU when a period of unavailability is requested. As described herein, a WTRU can use MICO mode. A WTRU can apply a feature of Petition 870250084746, dated 09 / 19 / 2025, pp. 89 / 119 82 / 86 strictly periodic recording timer when using a MICO mode.

[0267] A WTRU can send a registration request message to the network. The registration request message may include, for example, one or more of the following information elements: a request to use MICO mode; an indication of whether 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 the network; an active duration value (e.g., timer) (e.g., T3324); and / or a registration duration value (e.g., timer) (e.g., requested value T3512).

[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 unavailability period. The AMF may detect that the unavailability period overlaps with a period in which 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 Petition 870250084746, dated 09 / 19 / 2025, pp. 90-119 83 / 86 WTRU becomes inaccessible immediately after the registration acceptance message is sent and remains in an inaccessible state for the duration of the downtime. AMF may indicate in a Registration Acceptance Message that the downtime has not been accepted. WTRU may (for example, then) determine when it may be acceptable to request the downtime again.

[0271] The registration acceptance message may indicate that the strictly periodic registration duration feature (e.g., timer) is enabled and that the downtime period has not been accepted. The 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, send a registration request based on the expiration of the registration duration (e.g., timer), and enter the CMIDLE state when 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).This approach can be useful, for example, in cases where WTRU requests a downtime period when the strictly periodic registration time is about to expire.

[0272] The registration acceptance message may indicate that the strictly periodic registration timer feature 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). Petition 870250084746, dated 09 / 19 / 2025, pp. 91-119 84 / 86

[0273] WTRU may (for example, alternatively) determine (for example, again) request a duration of the downtime period, for example, if WTRU receives a WTRU Configuration Update message or other Registration Acceptance Message that disables MICO mode or the strictly periodic registration duration feature (e.g., 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 wait duration (e.g., timer) expires and the WTRU has entered the CM-IDLE state.

[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 WTRU management of a rejected downtime period. Figure 11 shows an example of how to account for WTRU's expected availability when a downtime period is requested.

[0277] As shown in Figure 11, a WTRU can (for example, when MICO mode and the strictly periodic logging timer / duration feature are 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 timer feature is enabled, and that the downtime duration is not allowed. The WTRU can then decide to send a Petition 870250084746, dated 09 / 19 / 2025, pp. 92-119 85 / 86 Second registration request that includes a second downtime period duration under conditions where a periodic registration duration (e.g., timer) has expired, the WTRU has entered the CM-IDLE 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 period duration.

[0278] As shown in Figure 11, a WTRU can (for example, when MICO mode and the strictly periodic registration timer feature are not enabled) send a registration request that includes an unavailability period duration. The WTRU may receive a registration acceptance message, which may indicate that MICO mode is enabled, the strictly periodic registration duration feature (e.g., timer) is not enabled, and that the unavailability period duration is not allowed. The WTRU may determine to send a second registration request that includes a second unavailability period duration, for example, under conditions where the WTRU has entered the CM-IDLE state and an active duration (e.g., timer) is not running. The WTRU may send the second registration request, for example, that includes a second unavailability 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 (for example, 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 (for example, start a timer) with the downtime duration. The WTRU may determine to send a second registration request that includes a second downtime duration, provided that Petition 870250084746, dated 09 / 19 / 2025, pp. 93-119 86 / 86 duration (e.g., timer) is not running and the WTRU has entered the CM-IDLE state. The WTRU can send a second registration request that includes a second downtime period duration.

[0280] Although the resources and elements described above are described in specific combinations, each resource or element can be used in isolation, without the other resources and elements of the preferred modalities, or in various combinations with or without other resources and elements.

[0281] Although the implementations described herein may consider specific 3GPP protocols, it is understood that the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, although the solutions described herein consider specific LTE, LTE-A, New Radio (NR) or 5G protocols, it is understood that the solutions described herein are not limited to this scenario and are also applicable to other wireless systems.

[0282] The processes described above can 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 by 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), register, cache memory, semiconductor memory devices, magnetic media such as, but are not limited to, internal and removable hard 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 870250084746, dated 09 / 19 / 2025, pp. 94 / 119

Claims

1 / 5 CLAIMS 1. Wireless Transmit / Receive Unit (WTRU) for multiple USIMs (MUSIMs), CHARACTERIZED in that it comprises: a processor configured to: initiate registration with a first network and a second network; determine that an event that is triggered would render the WTRU unavailable; initiate a first mobility registration update procedure with the first network, wherein the first mobility registration update procedure comprises sending a first registration request to the first network, wherein the first registration request indicates a first unavailability duration associated with an unavailability period; receive a first registration response from the first network, wherein the first registration response indicates a first periodic registration timer value;Initiate a second mobility registration update procedure with the second network, wherein the second mobility registration update procedure comprises sending a second registration request to the second network, wherein the second registration request indicates the second duration of unavailability; and receiving a second registration response from the second network, wherein the second registration response indicates a second periodic registration timer value.

2. WTRU MUSIM, according to claim 1, CHARACTERIZED in that the second downtime duration differs from the first downtime duration.

3. WTRU MUSIM, according to claim 1, CHARACTERIZED by the fact that the second duration of unavailability is equal to the first duration of Petition 870250084746, dated 09 / 19 / 2025, page 115 / 119 2 / 5 unavailability.

4. WTRU MUSIM, according to claim 1, CHARACTERIZED in that the first periodic record timer value is based on the downtime period.

5. WTRU MUSIM, according to claim 1, CHARACTERIZED in that the second periodic record timer value is based on the second downtime duration.

6. WTRU MUSIM, according to claim 1, CHARACTERIZED in that the first registration response additionally indicates that the first network does not support unavailability, and in that the processor is additionally configured to initiate a first deregistration procedure with the first network, wherein the deregistration procedure comprises sending a first deregistration request to the first network.

7. WTRU MUSIM, according to claim 6, CHARACTERIZED in that the second registration response further indicates that the second network does not support unavailability, and in that the processor is further configured to initiate a second deregistration procedure with the second network, wherein the second deregistration procedure comprises sending a second deregistration request to the second network.

8. WTRU MUSIM, according to claim 1, CHARACTERIZED in that the processor is additionally configured to execute the event that would render the WTRU unavailable.

9. WTRU, according to claim 1, CHARACTERIZED in that the second periodic record timer value is greater than or equal to the first downtime duration.

10. WTRU, according to claim 1, CHARACTERIZED by the fact that the first registration request additionally indicates a request to activate Petition 870250084746, dated 09 / 19 / 2025, page 116 / 119 3 / 5 a downtime feature with the first network.

11. Method executed by a multi-USIM wireless transmit / receive unit (WTRU), CHARACTERIZED in that it comprises: initiating registration with a first network and a second network; determining that a triggered event would render the WTRU unavailable; initiating a first mobility registration update procedure with the first network, wherein the first mobility registration update procedure comprises sending a first registration request to the first network, wherein the first registration request indicates a first unavailability duration associated with an unavailability period; receiving a first registration response from the first network, wherein the first registration response indicates a first periodic registration timer value;Initiate a second mobility registration update procedure with the second network, wherein the second mobility registration update procedure comprises sending a second registration request to the second network, wherein the second registration request indicates the second duration of unavailability; and receiving a second registration response from the second network, wherein the second registration response indicates a second periodic registration timer value.

12. Method, according to claim 11, CHARACTERIZED in that the second downtime duration differs from the first downtime duration.

13. Method, according to claim 11, CHARACTERIZED by the fact that the second duration of unavailability is equal to the first duration of unavailability.

14. Method according to claim 11, CHARACTERIZED in that the first periodic record timer value is based on the downtime period.

15. Method according to claim 11, CHARACTERIZED in that the second periodic record timer value is based on the second unavailability period.

16. Method according to claim 11, CHARACTERIZED in that the first registration response further indicates that the first network does not support downtime, wherein the method further comprises initiating a first deregistration procedure with the first network, and wherein the first deregistration procedure comprises sending a first deregistration request to the first network.

17. Method according to claim 16, CHARACTERIZED in that the second registration response further indicates that the second network does not support downtime, wherein the method further comprises initiating a second deregistration procedure with the second network, and wherein the second deregistration procedure comprises sending a second deregistration request to the second network.

18. Method, according to claim 11, CHARACTERIZED in that it further comprises executing the event that would render the WTRU unavailable.

19. Method according to claim 11, CHARACTERIZED in that the second periodic recording timer value is greater than or equal to the first downtime duration.

20. Method, according to claim 11, CHARACTERIZED in that the first registration request additionally indicates a request to activate a downtime feature with the first network. Petition 870250084746, dated 09 / 19 / 2025, p. 118 / 119 5 / 5

Images