Unavailability period support for musim devices

Abstract

The apparatus can be a multi-universal subscriber identity module (MUSiM) apparatus. The apparatus can send a first registration request to a first network, e.g., to enable an unavailable time period feature with a second network. The registration request can indicate a first unavailable duration. The apparatus can determine that an unavailable event is triggered. The apparatus can determine that the apparatus will be unavailable during a time period. The apparatus can receive a first registration response, e.g., a first registration accept message. The first registration response can indicate a first registration duration. The apparatus can determine a second unavailable duration. The apparatus can send a second registration request to a second network, e.g., indicating the second unavailable duration. The apparatus can receive a second registration response. The second registration response can be a second registration accept message. The second registration response can indicate a second registration duration.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 457,515, filed April 6, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0002] Mobile communications using wireless communication continue to evolve. The fifth generation can be referred to as 5G. The previous (traditional) generation of mobile communications can be, for example, the fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] This document describes systems, methods, and tools that support unavailable time periods while registering a Radio Transmit / Receive Unit (WTRU) via non-3GPP access (e.g., non-3GPP access only).

[0004] An apparatus (e.g., a WTRU, a network apparatus, such as an apparatus including Access and Mobility Functions (AMF)) may perform one or more of the following actions. For example, via Non-Access Stratum (NAS) signaling, the apparatus may send a registration request (e.g., to a network entity). The registration request may include a first duration (e.g., an unavailability duration associated with the WTRU). The apparatus may receive a registration acceptance message. The registration acceptance message may indicate whether the apparatus will notify the network entity when the WTRU becomes available (e.g., after the unavailability event / duration has passed). The apparatus may determine that the unavailability event has ended. The WTRU may determine (e.g., based on the registration acceptance message) whether to notify the network entity that the WTRU is available. The apparatus may send a registration update request. Based on the determination that the unavailability event has ended and the determination that the WTRU will notify the network entity when it becomes available, a registration update request may be sent. The registration update request may indicate that the WTRU is available.

[0005] The device may receive an indication from the network, such as an indication of congestion. The device may also receive an indication of a second duration (e.g., a backoff duration associated with the congestion). The second duration can be determined. The first duration may be greater than or equal to the second duration.

[0006] The device can receive a registration request message (e.g., from a WTRU) indicating a first duration (e.g., an unavailable period associated with the WTRU). The registration request may be associated with unavailability information. The device can determine whether the WTRU will send an update message (e.g., after the first duration). The device can send a registration acceptance message (e.g., to the WTRU). For example, based on determining that the registration request is associated with unavailability information, the device can send a registration acceptance message. The registration acceptance message may indicate acceptance associated with the registration request message. The registration acceptance message may indicate whether the WTRU will send an update message after the first duration (e.g., based on whether the WTRU is associated with discontinuous coverage). For example, if the WTRU is associated with discontinuous coverage, the registration acceptance message may indicate prohibition of sending update messages (e.g., after the first duration). The device can determine whether the WTRU is available after the first duration. For example, if the registration acceptance message indicates that the WTRU will send an update message after the first duration, the device can determine whether an update message has been received from the WTRU (e.g., before the first duration expires). For example, if an update message is received before the first duration expires, the WTRU can be determined to be available. The device can send a rejection message, for example, associated with congestion. The rejection message can indicate a second duration. The first duration can be shorter than the second duration.

[0007] The device may be a Multi-Universal Subscriber Identity Module (MUSIM) device. The device may send a first registration request to a first network. The first registration request may indicate the activation of an unavailability period feature for a second network. The registration request may indicate a first unavailability duration associated with the unavailability period. The device may determine that an unavailability event has been triggered. The device may determine that the device (e.g., a WTRU) will be unavailable for a certain period of time. The determination that the device will be unavailable during the certain period of time may be based on the determination that an unavailability event has been triggered. Based on the determination that the device will be unavailable during the certain period of time, a first unavailability duration may be determined. The device may receive a first registration response (e.g., from the first network). The first registration response may be a first registration acceptance message. The first registration response may indicate a first registration duration. The first registration duration may be greater than or equal to the first unavailability duration. For example, based on the first unavailability duration, the device may determine a second unavailability duration. The device may send a second registration request to a second network. The second registration request may indicate the activation of an unavailability period feature for the second network. The second registration request may indicate a second unavailability 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 the second registration duration. The second registration duration may be greater than or equal to the second unavailability duration. The second unavailability duration may be greater than or equal to the first registration duration.

[0008] The 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 an unavailable period information. The registration request may include an unavailable period information element, which indicates the unavailable period information. The unavailable period information can indicate, for example, the duration of unavailability 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 certain period. The device can receive a notification response (e.g., from the entity). The notification response can indicate that the entity has accepted the unavailability of the WTRU. The notification response can indicate the tracking area update duration. The notification response can indicate that the entity has accepted the unavailability of the WTRU and the tracking area update duration. For example, based on the notification response, the device can send a registration acceptance message (e.g., to the WTRU). The registration acceptance message can indicate the tracking area update duration. The registration acceptance message can instruct the WTRU to perform a tracking area update with the entity, for example, based on the completion of the unavailability event.

[0009] The device can perform actions associated with non-3GPP access. The device can receive a registration request (e.g., from a WTRU). The registration request can indicate a first duration. The first duration can be an unavailable period. The registration request can include information elements, such as those indicating the first duration. The registration request can be sent via a non-3GPP access network. The device can send a registration response, such as one indicating that the first duration is accepted. The indication of acceptance of the first duration can indicate the accepted unavailable period duration. The accepted unavailable period duration can be equal to or greater than the requested first duration. Based on receiving the registration request via a non-3GPP access network and the registration request indicating the first duration, the registration response can be sent. For example, based on determining that a second duration has elapsed, the device can determine that the WTRU is unreachable. The second duration can be associated with or equal to the unavailable period duration associated with the registration request. The device can send a connection loss report. The connection loss report can indicate an unavailable period. The connection loss report can indicate that the unavailable period was sent to the Network Exposure Function. The device can receive a NAS message from the WTRU. For example, based on receiving a NAS message, the device may perform one or more of the following operations: stop tracking associated with the second duration; determine that the WTRU is reachable; determine that the WTRU is connected; and so on. Based on determining that the second duration has expired, the device may deregister the WTRU. Attached Figure Description

[0010] Figure 1A This is a system diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments.

[0011] Figure 1B The illustration is based on an embodiment and can be used Figure 1A The diagram shows a system diagram of an exemplary wireless transmit / receive unit (WTRU) used in a communication system.

[0012] Figure 1C The illustration is based on an embodiment and can be used Figure 1A The diagram shows an exemplary radio access network (RAN) and an exemplary core network (CN) used within a communication system.

[0013] Figure 1D The illustration is based on an embodiment and can be used Figure 1A The diagram shows another exemplary RAN and another exemplary CN used within the communication system.

[0014] Figure 2 The illustration shows an example of an unavailability event while NAS-level congestion control is active.

[0015] Figure 3 The illustration shows an example of when the unavailable time period feature is used by a WTRU registered via non-3GPP access.

[0016] Figure 4 The illustration shows an example of unavailable coordination across networks.

[0017] Figure 5 The illustration shows an example of unavailability coordination across multiple networks when multiple networks (e.g., two 5G networks) support unavailability features.

[0018] Figure 6 The illustration shows an example of unavailability coordination across multiple networks when one of the networks does not support the unavailability feature of MUSIM WTRU.

[0019] Figure 7 The illustration shows an example of a dual registration scenario where the WTRU has both 5GMM and EMM contexts.

[0020] Figure 8 The illustration shows an example of using unavailable information to produce improved data analysis results.

[0021] Figure 9 The diagram illustrates an example of a relay WTRU entering an unavailable period.

[0022] Figure 10 The illustration shows an example of a remote WTRU entering an unavailable period.

[0023] Figure 11 This diagram illustrates an example of the logic for handling WTRU rejections when the time period is unavailable. Detailed Implementation

[0024] Figure 1A This is a diagram illustrating an exemplary communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcasting, etc., to multiple wireless users. The communication system 100 enables multiple wireless users to access this content through the sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero Tail Unique Word DFT Spread Spectrum OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Library Set Multicarrier (FBMC), etc.

[0025] like Figure 1AAs shown, the communication system 100 may include Wireless Transmit / Receive Units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain scenarios), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any WTRU in WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0026] The communication system 100 may also include base station 114a and / or base station 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (such as CN 106 / 115, Internet 110, and / or other networks 112). As an example, base stations 114a and 114b may be base transceivers (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR Node B, field controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are depicted as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

[0028] Through air interface 116, base stations 114a and 114b can communicate with one or more WTRUs among WTRUs 102a, 102b, 102c, and 102d. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

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

[0030] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro) to establish air interface 116.

[0031] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish air interface 116.

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

[0033] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, transitional standard 2000 (IS-2000), transitional standard 95 (IS-95), transitional standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0034] Figure 1ABase station 114b can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can use any suitable RAT to facilitate wireless connectivity in a local area, such as a commercial location, home, vehicle, campus, industrial facility, air corridor (e.g., used by a drone), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement 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 radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet 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 pico or femtocell. Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0035] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more WTRUs of WTRUs 102a, 102b, 102c, and 102d. Data may have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not mentioned in Figure 1A As shown, but will be understood, RAN 104 / 113 and / or CN 106 / 115 may communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may use NR radio technology, CN 106 / 115 may also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0036] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

[0037] Some or all of the WTRUs 102a, 102b, 102c, and 102d in communication system 100 may include multi-mode capability (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks on different wireless links). For example, Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a, which can employ cellular-based radio technology, and with base station 114b, which can employ IEEE 802 radio technology.

[0038] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It will be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0039] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. Although... Figure 1B While the processor 118 and transceiver 120 are depicted as separate components, it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0042] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 may have multi-mode capability. Thus, for example, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate over various RATs (such as NR and IEEE 802.11).

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

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

[0045] Processor 118 may also be coupled to GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of WTRU 102. In addition to or alternative to information from GPS chipset 136, WTRU 102 may receive location information via air interface 116 from base stations (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0046] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, such as gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

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

[0048] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0049] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. Each eNode-B 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, eNode-B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

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

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

[0052] The MME 162 can be connected to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, activating / deactivating bearers, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies (such as GSM and / or WCDMA).

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

[0054] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0055] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication devices. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), or can communicate with said IP gateway, which serves as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0056] Although WTRU is Figure 1A-1D While described as a wireless terminal, it is conceivable that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0058] A WLAN in an Infrastructure Basic Services 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 access a Distribution System (DS) or another type of wired / wireless network, or have an interface with a Distribution System (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the AP via the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be transmitted via the AP, for example, where a source STA can send traffic to the AP and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Using Direct Link Establishment (DLS), peer-to-peer traffic can be transmitted between source and destination STAs (e.g., directly between source and destination STAs). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using Standalone BSS (IBSS) mode may not have access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs within a STA) can communicate directly with each other. IBSS communication mode may sometimes be referred to herein as "ad-hoc" communication mode.

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

[0060] For example, a high-throughput (HT) STA can communicate using a 40 MHz wide channel by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0061] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight adjacent 20 MHz channels, or by combining two non-adjacent 80 MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data is delivered via a segment resolver, which divides the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. The streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

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

[0063] WLAN systems that 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 may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel may be 1 MHz wide even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Assignment Vector (NAV) settings may depend on the status of the primary channel. If, for example, the primary channel is busy due to a STA (that only supports the 1 MHz operating mode) transmitting to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

[0064] In the United States, the available frequency bands for 802.11ah are from 902 MHz to 928 MHz. In South Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. Depending on the country code, the total bandwidth available for 802.11ah is 6 MHz to 26 MHz.

[0065] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

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

[0067] Using transmissions associated with scalable digital theory, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. Using various or scalable length subframes or transmission time intervals (TTIs) (e.g., containing a varying number of OFDM symbols and / or an absolute time of continuously varying length), WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c.

[0068] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without also accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more gNBs from gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate with / connect to gNBs 180a, 180b, and 180c, and also communicate with / connect to another RAN, such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-B 160a, 160b, and 160c can be used as mobility anchors for WTRU 102a, 102b, and 102c, and gNB 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRU 102a, 102b, and 102c.

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

[0070] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0071] AMF 182a and 182b can be connected to one or more gNBs (gNBs) 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slices (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slices can be used by AMF 182a and 182b to customize CN support for WTRU 102a, 102b, and 102c based on the type of services used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and services for Machine Type Communication (MTC) access. AMF 162 can provide control plane functionality for switching between RAN 113 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0072] SMF 183a and 183b can be connected to AMF 182a and 182b in CN 115 via the N11 interface. SMF 183a and 183b can also be connected to UPF 184a and 184b in CN 115 via the N4 interface. SMF 183a and 183b can select and control UPF 184a and 184b, and configure the routing of services through UPF 184a and 184b. SMF 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, or Ethernet-based.

[0073] UPF 184a and 184b can be connected via the N3 interface to one or more gNBs 180a, 180b, and 180c in RAN 113. This provides WTRU 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

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

[0075] Considering Figure 1A-1D and Figure 1A-1D The corresponding descriptions herein regarding 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, SMF183a-b, DN 185a-b, and / or any other device(s) described herein, and / or the functions described herein, may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0076] The simulation device may be designed to perform one or more tests on other devices in a laboratory environment and / or in a carrier network environment. For example, while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network, the one or more simulation devices may perform one or more or all of the functions to test other devices within the communication network. While being temporarily implemented / deployed as part of a wired and / or wireless communication network, the one or more simulation devices may perform one or more or all of the functions. The simulation device may be directly coupled to another device for testing purposes, and / or may use over-the-air wireless communication to perform the tests.

[0077] While not implemented / deployed as part of a wired and / or wireless communication network, the one or more simulation devices may perform the one or more functions (including all functions). For example, the simulation devices may be used in test scenarios in test laboratories and / or non-deployed (e.g., test) wired and / or wireless communication networks to perform testing of one or more components. The one or more simulation devices may be test equipment. Wireless communication via direct RF coupling and / or through an RF circuit system (e.g., the RF circuit system may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

[0078] In this document, references to timers can refer to the determination of a time or a period of time. References to timer expiration can refer to the occurrence of the determined time or the expiration of the period of time. References to timers can refer to time, period of time, tracking time, tracking period, etc. References to legacy technologies or legacy handovers can indicate: legacy technologies, such as LTE compared to NR; or legacy versions of technologies, such as earlier versions / releases of the technology compared to a recent version / release (e.g., a recent NR release). References to specific timers may be provided as examples of timers.

[0079] This document describes systems, methods, and tools that support unavailable time periods while registering a Radio Transmit / Receive Unit (WTRU) via non-3GPP access (e.g., non-3GPP access only).

[0080] An apparatus (e.g., a WTRU, a network apparatus, such as an apparatus including Access and Mobility Functions (AMF)) may perform one or more of the following actions. For example, via Non-Access Stratum (NAS) signaling, the apparatus may send a registration request (e.g., to a network entity). The registration request may include a first duration (e.g., an unavailability duration associated with the WTRU). The apparatus may receive a registration acceptance message. The registration acceptance message may indicate whether the apparatus will notify the network entity when the WTRU becomes available (e.g., after the unavailability event / duration has passed). The apparatus may determine that the unavailability event has ended. The WTRU may determine (e.g., based on the registration acceptance message) whether to notify the network entity that the WTRU is available. The apparatus may send a registration update request. Based on the determination that the unavailability event has ended and the determination that the WTRU will notify the network entity when it becomes available, a registration update request may be sent. The registration update request may indicate that the WTRU is available.

[0081] The device may receive an indication from the network, such as an indication of congestion. The device may also receive an indication of a second duration (e.g., a backoff duration associated with the congestion). The second duration can be determined. The first duration may be greater than or equal to the second duration.

[0082] The device can receive a registration request message (e.g., from a WTRU) indicating a first duration (e.g., an unavailable period associated with the WTRU). The registration request may be associated with unavailability information. The device can determine whether the WTRU will send an update message (e.g., after the first duration). The device can send a registration acceptance message (e.g., to the WTRU). For example, based on determining that the registration request is associated with unavailability information, the device can send a registration acceptance message. The registration acceptance message may indicate acceptance associated with the registration request message. The registration acceptance message may indicate whether the WTRU will send an update message after the first duration (e.g., based on whether the WTRU is associated with discontinuous coverage). For example, if the WTRU is associated with discontinuous coverage, the registration acceptance message may indicate prohibition of sending update messages (e.g., after the first duration). The device can determine whether the WTRU is available after the first duration. For example, if the registration acceptance message indicates that the WTRU will send an update message after the first duration, the device can determine whether an update message has been received from the WTRU (e.g., before the first duration expires). For example, if an update message is received before the first duration expires, the WTRU can be determined to be available. The device can send a rejection message, for example, associated with congestion. The rejection message can indicate a second duration. The first duration can be shorter than the second duration.

[0083] The device may be a Multi-Universal Subscriber Identity Module (MUSIM) device. The device may send a first registration request to a first network. The first registration request may indicate the activation of an unavailability period feature for a second network. The registration request may indicate a first unavailability duration associated with the unavailability period. The device may determine that an unavailability event has been triggered. The device may determine that the device (e.g., a WTRU) will be unavailable for a certain period of time. The determination that the device will be unavailable during the certain period of time may be based on the determination that an unavailability event has been triggered. Based on the determination that the device will be unavailable during the certain period of time, a first unavailability duration may be determined. The device may receive a first registration response (e.g., from the first network). The first registration response may be a first registration acceptance message. The first registration response may indicate a first registration duration. The first registration duration may be greater than or equal to the first unavailability duration. For example, based on the first unavailability duration, the device may determine a second unavailability duration. The device may send a second registration request to a second network. The second registration request may indicate the activation of an unavailability period feature for the second network. The second registration request may indicate a second unavailability 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 the second registration duration. The second registration duration may be greater than or equal to the second unavailability duration. The second unavailability duration may be greater than or equal to the first registration duration.

[0084] The 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 an unavailable period information. The registration request may include an unavailable period information element, which indicates the unavailable period information. The unavailable period information can indicate, for example, the duration of unavailability 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 certain period. The device can receive a notification response (e.g., from the entity). The notification response can indicate that the entity has accepted the unavailability of the WTRU. The notification response can indicate the tracking area update duration. The notification response can indicate that the entity has accepted the unavailability of the WTRU and the tracking area update duration. For example, based on the notification response, the device can send a registration acceptance message (e.g., to the WTRU). The registration acceptance message can indicate the tracking area update duration. The registration acceptance message can instruct the WTRU to perform a tracking area update with the entity, for example, based on the completion of the unavailability event.

[0085] The device can perform actions associated with non-3GPP access. The device can receive a registration request (e.g., from a WTRU). The registration request can indicate a first duration. The first duration can be an unavailable period. The registration request can include information elements, such as those indicating the first duration. The registration request can be sent via a non-3GPP access network. The device can send a registration response, such as one indicating that the first duration is accepted. The indication of acceptance of the first duration can indicate the accepted unavailable period duration. The accepted unavailable period duration can be equal to or greater than the requested first duration. Based on receiving the registration request via a non-3GPP access network and the registration request indicating the first duration, the registration response can be sent. For example, based on determining that a second duration has elapsed, the device can determine that the WTRU is unreachable. The second duration can be associated with or equal to the unavailable period duration associated with the registration request. The device can send a connection loss report. The connection loss report can indicate an unavailable period. The connection loss report can indicate that the unavailable period was sent to the Network Exposure Function. The device can receive a NAS message from the WTRU. For example, based on receiving a NAS message, the device may perform one or more of the following operations: stop tracking associated with the second duration; determine that the WTRU is reachable; determine that the WTRU is connected; and so on. Based on determining that the second duration has expired, the device may deregister the WTRU.

[0086] This document describes systems, methods, and tools that support unavailable periods of time while registering a WTRU via non-3GPP access (e.g., non-3GPP access only).

[0087] An apparatus (e.g., a network apparatus, such as an apparatus including Access and Mobility Functions (AMF)) may (e.g., be configured to) perform one or more of the following actions. The apparatus may receive a registration request. The registration request may include unavailability information (e.g., an unavailability period duration information element (IE)), for example, the request may be sent via a non-3GPP access network. The apparatus may (e.g., based on receiving the registration request via a non-3GPP access network and / or based on the request including the unavailability period duration information element) determine to start a tracking duration (e.g., start a wait timer). The apparatus may assign an initial value to the duration (e.g., the wait timer), for example, the initial value may be equal to the unavailability period duration provided in the registration request. The apparatus may (e.g., based on receiving the registration request via a non-3GPP access network and / or based on the request including the unavailability period duration information element) determine to send a registration response, for example, the response may include an indication that the unavailability period duration request is accepted and the network... For example, the device can indicate acceptance of an unavailable time period duration by sending the accepted unavailable time period duration to the Radio Transmit / Receive Unit (WTRU). The device can assign the accepted unavailable time period duration, which is equal to or greater than the requested unavailable time period duration. The device can determine (e.g., based on receiving the registration request via a non-3GPP access network and / or based on the request including an unavailable time period duration information element) that the WTRU is considered unreachable and in an idle state (e.g., 5GMM-IDLE state). The device can send an indication to the Session Management Function (SMF) stating that the WTRU is unreachable (e.g., based on the WTRU being unreachable and in an idle state (e.g., 5GMM-IDLE state)). This indication can be sent in response to a downlink data notification from the SMF. For example, if there is a connection loss event subscription for the WTRU by an Application Function (AF), the device can trigger a connection loss event report (e.g., the report may include an unavailable time period) towards the Network Exposure Function (NEF), and / or the unavailable time period can be reported to the subscribed AF. The device can receive an Initial Non-Access Layer (NAS) message from the WTRU. The device can (e.g., based on receiving the NAS Initial NAS message) determine to stop tracking the duration (e.g., stop waiting for a timer), treating the WTRU as reachable and in a connected state (e.g., 5GMM-CONNECTED state). Based on the expiration of the duration (e.g., the waiting timer expires), the device can (e.g., alternatively, implicitly) determine to deregister the WTRU.

[0088] Exemplary apparatus may include a processor configured to perform one or more actions. For example, an apparatus (e.g., a network apparatus, such as an apparatus including an AMF) may receive a registration request from a Radio Transmitter / Receiver 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 apparatus may begin tracking the duration (e.g., start a timer). The apparatus may send a registration response. The registration response may include an indication that the unavailability period duration request has been accepted. The apparatus may determine that the WTRU is unreachable. The apparatus may send a connection loss report.

[0089] The value of the duration (e.g., a timer) may be associated with or equal to the unavailable time period duration associated with the registration request. A registration response may be sent based on the registration request being received via a non-3GPP access network and the registration request including an unavailable time period duration information element. An indication of acceptance of the unavailable time period duration request may indicate the accepted unavailable time period duration. The accepted unavailable time period duration may be equal to or greater than the requested unavailable time period duration. A connection loss report may indicate the unavailable time period. A connection loss report indicating the unavailable time period may be sent to the network exposure function. The device (e.g., a processor) may also be 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 operations: stop tracking the duration (e.g., stop the timer), determine that the WTRU is reachable, or determine that the WTRU is in a connected state. The device (e.g., a processor) may also be configured to implicitly revoke the registration of the WTRU based on the timer expiring.

[0090] This document describes systems, methods, and tools that relate to mechanisms for making unavailable time periods available to a network. Some events, such as operating system (OS) upgrades, silent resets of modems, or modem software updates (e.g., also known as binary updates), can be performed involving more than two (e.g., three (3)) parties, such as devices, operators, and application functions.

[0091] While event operations are being performed, for example, a WTRU performing a multi-party event may become unavailable (e.g., unable to interact with the 5G system) for a period of approximately several minutes. For instance, if an application server relies on the availability of the WTRU during a period of unavailability (e.g., the period during which the WTRU is unavailable), the unavailability of the WTRU may affect the (e.g., critical) operation of the application server if the core network and / or application functions are not known in advance.

[0092] This document describes systems, methods, and tools that relate to handling unavailability periods for one or more scenarios, such as: when the fallback duration is active (e.g., a timer is running); if the WTRU is registered to a network (e.g., 5GS) via non-3GPP access (e.g., only via non-3GPP access) (e.g., when the WTRU is registered to a network (e.g., 5GS) via non-3GPP access (e.g., only via non-3GPP access); if a Multi-Universal Subscriber Identity Module (MUSIM) device is registered to multiple networks that support and do not support the unavailability feature (e.g., when a Multi-Universal Subscriber Identity Module (MUSIM) device is registered to multiple networks that support and do not support the unavailability feature); if the WTRU is registered To multiple networks (e.g., both Evolved Packet System (EPS) and Generation 5 (5GS)) (e.g., when a WTRU is registered to multiple networks (e.g., both Evolved Packet System (EPS) and Generation 5 (5GS))); to support the ability to analyze unavailability features (e.g., Network Data Analysis Function (NWDAF)); if a remote WTRU and / or a trunk WTRU enters an unavailability period (e.g., when a remote WTRU and / or a trunk WTRU enters an unavailability period); if the Mobile Initiated Connection (MICO) mode and / or the Strict Periodic Registration Timer feature are enabled (e.g., when the Mobile Initiated Connection (MICO) mode and / or the Strict Periodic Registration Timer feature are enabled), etc.

[0093] An unavailability period can be a certain duration during which the WTRU is unavailable, for example, unable to interact with the network (e.g., a 5G system). An unavailability period can be, for example, approximately a few minutes. The WTRU's unavailability period can (e.g., is expected) be long enough for the WTRU to perform (e.g., necessary) events, such as one or more of the following: (a) a silent reset of the modem; (b) a security patch update; (c) an OS upgrade; (d) a modem software (SW) update; and / or (e) a device restart upon a change in modem settings (e.g., via Open Mobile Alliance Device Management (OMA-DM)).

[0094] Seamless WTRU context recovery can be performed. Certain events, such as OS upgrades, silent resets of the modem, or modem software updates (e.g., also known as binary updates), can be performed involving multiple (e.g., three (3)) parties, such as devices, operators, and application functions.

[0095] The WTRU can download binary files. The timing of WTRU upgrades is determined by the WTRU implementation. Some WTRU implementations can use (e.g., seek) user input. For example, if the WTRU may be unable to perform an event (e.g., due to insufficient storage capacity or battery levels), the WTRU may delay the execution of the event. For example, if such an operation is performed (e.g., when such an operation is performed), the WTRU may become unavailable (e.g., unable to interact with the 5G system) for approximately a few minutes. The WTRU may become unavailable if core network and / or application functions are not known in advance. For example, if an application server depends on the availability of the WTRU during the unavailable period (e.g., the period during which the WTRU is unavailable), the WTRU unavailability may affect the critical operations of the application server.

[0096] The network (e.g., a 5G system) may allow the WTRU to provide an unavailable period (e.g., unavailability duration) to the network, for example, in a registration or deregistration request. For instance, if an event that would render the WTRU unavailable for a period of time is triggered in the WTRU, the WTRU may store its Mobility Management (MM) and Session Management (SM) contexts in a Universal Subscriber Identity Module (USIM) or non-volatile memory so that the MM and SM contexts can be reused after the WTRU's unavailability period. For instance, if the WTRU can store its context, the WTRU may trigger a mobility registration update procedure or a deregistration procedure and provide the unavailability period duration to the network. For instance, if a periodic registration update duration (e.g., a periodic registration update timer value) is determined (e.g., when determining the periodic registration update duration (e.g., a periodic registration update timer value)), the network (e.g., the Access and Mobility Function (AMF)) may take the unavailability period duration into account. The AMF may provide a periodic registration update time longer than or equal to the unavailability period duration, for example, to avoid interfering with the WTRU's processing of events that cause unavailability. Later (e.g., once the event that made the WTRU unavailable is completed in the WTRU, or the event is delayed to a future time, or canceled in the WTRU), the WTRU may trigger a registration procedure to restore normal service. The WTRU may prohibit the inclusion of the unavailable period in the registration request message (e.g., not including the unavailable period in the registration request message). Depending on the WTRU state, the registration procedure may be an initial registration procedure or a mobility registration update procedure.

[0097] For example, along with the periodic registration timer value, the AMF can provide a strict periodic registration duration indication (e.g., a strict periodic registration timer indication) to the WTRU. For example, if the WTRU uses MICO mode (e.g., when the WTRU uses MICO mode), the periodic registration timer feature can be applied. Based on the desired WTRU behavior, the AMF can provide this indication to the WTRU. For example, the AMF might (e.g., want) configure the WTRU to be available for downlink data every hour (e.g., on the hour) to receive downlink data. For example, if the WTRU uses MICO mode (e.g., when the WTRU uses MICO mode), the periodic registration duration (e.g., timer) feature can be useful. The periodic registration duration (e.g., timer) feature can be used to ensure that the WTRU is in CM-CONNECTED mode (e.g., at a predictable time). For example, if the WTRU runs a strict periodic registration timer for 4 hours and (e.g., always) applies a 10-minute active timer, it is likely known that the WTRU is available every 4 hours for a period of 10 minutes. By enabling the strictly periodic registration duration (e.g., timer) feature, AMF can configure availability events (e.g., 10-minute availability events) to occur at predictable times.

[0098] The Network Data Analysis Function (NWDAF) can interact with other network functions to collect data. The data collected by NWDAF can then be used by NWDAF to determine analytical results. These results can include statistical data and forecasts.

[0099] 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 the AMF. NWDAF can provide the Nnwdaf_AnalyticsInfo service, which can be used by network functions to obtain statistics and forecasts from NWDAF. Policy Control Function (PCF), Access and Mobility Management Function (AMF), Network Slice Selection Function (NSSF), Network Exposure Function (NEF), Session Management Function (SMF), and 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 NFs that call or consume the Nnwdaf_AnalyticsInfo service: First, network slice instance load level statistics and forecasts; second, network slice load level statistics and forecasts; third, network function load level statistics and forecasts; fourth, network load level statistics and forecasts; fifth, WTRU communication statistics and forecasts; and sixth, WTRU abnormal behavior statistics and forecasts.

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

[0102] In 5GS, unavailable periods can be determined for WTRUs (e.g., specific WTRUs). WTRU and / or network actions can be based on the determined unavailable periods. WTRUs and networks (e.g., 5GCs) can coordinate architecture-level workflows for unavailable periods and / or unavailable characteristics.

[0103] WTRU may provide an indication of support for unavailable time periods, for example, in a registration request message (e.g., during the registration process). AMF may indicate support for unavailable time periods, for example, in a registration acceptance message.

[0104] For example, if an event is triggered in the WTRU that supports an unavailable period and will render the WTRU unavailable for a certain period (e.g., for OS upgrade or device reboot), the WTRU may store its MM context in the USIM or non-volatile memory so that the MM context can be reused (e.g., after the WTRU's unavailable period). For example, if the WTRU is ready to execute the event (e.g., when the WTRU is ready to execute the event), the WTRU may trigger a mobility registration or deregistration procedure that includes the unavailable period. Based on the unavailable period indicated by the WTRU, the AMF may provide a periodic registration update duration (e.g., a timer), for example, the AMF may provide a periodic registration update duration longer than the unavailable period. For example, if the WTRU is not deregistered, the AMF may store information about the WTRU's unavailability in the WTRU context. The AMF may treat the WTRU as unreachable until the unavailable period has passed or the WTRU enters a CM-CONNECTED state. While the WTRU is unreachable, (e.g., all) high-latency communication solutions may be applicable (e.g., if supported), such as extended data buffers, downlink data buffer status reporting, etc. If there is a connection loss event subscription to the WTRU by the AF, the AMF may trigger a connection loss event report to the NEF, which may include the unavailability period. The unavailability period may be reported to the corresponding subscribed AF.

[0105] For example, if the WTRU is ready to execute an event (e.g., for an OS upgrade or device reboot) (e.g., when the WTRU is ready to execute an event (e.g., for an OS upgrade or device reboot)), the WTRU may (e.g., optionally) store the WTRU context (e.g., MM and SM contexts). How the WTRU stores the context may depend on the WTRU implementation. Using the USIM feature, the WTRU may store some or all of the WTRU contexts in the USIM.

[0106] For example, once an event that renders the WTRU unavailable is completed within the WTRU, or if the event is delayed to a future time or canceled within the WTRU (e.g., due to insufficient storage capacity, insufficient battery levels, or the completion of an event that renders the WTRU unavailable), the WTRU may trigger a registration procedure to restore normal service. The WTRU may prohibit the inclusion of an unavailable period in the registration request message (e.g., not including an unavailable period in the registration request message). For example, depending on the final state of the WTRU after the event, the registration procedure may be an initial registration procedure or a mobility registration update procedure.

[0107] While the fallback duration is active (e.g., a timer is running), unavailable time period support can be provided. While a non-access stratum (NAS) fallback duration (e.g., a timer or other fallback timer) is running in the WTRU (e.g., T3346 / T3347 / T3396, other fallback timers), the NAS layer mobility management entity can prohibit the triggering of mobility registration procedures toward the core network (e.g., not triggering mobility registration procedures toward the core network or not being allowed to trigger mobility registration procedures toward the core network) (e.g., excluding one or more exceptions, such as downlink (DL) paging / notification, UL high-priority signaling, or emergency services). The WTRU (e.g., in this case) can prohibit sending registration requests with unavailable time period durations to the network (e.g., not sending registration requests with unavailable time period durations to the network).

[0108] For example, if the WTRU is to prevent the transmission of the unavailable time period duration to the network (e.g., not transmit the unavailable time period duration to the network) and performs an action that would render the WTRU unavailable while the fallback duration (e.g., a timer) is running, the network may attempt to contact (e.g., unsuccessfully contact) the WTRU for termination of service for mobility while the fallback duration (e.g., a timer) is running. Attempts to contact the WTRU for termination of service for mobility may fail.

[0109] One or more examples described in this document may indicate how the WTRU handles MM signaling when the MM backoff duration (e.g., a timer) is running and the WTRU may (e.g., needs to) execute an event that would render the WTRU unusable.

[0110] While a WTRU is accessing a non-3GPP network and not registered with any other access (e.g., only registered with a non-3GPP network), unavailability period support can be provided. For example, if the WTRU's NAS layer receives notification from a lower layer that non-3GPP access is available, the WTRU can send an initial NAS message to establish an N1 NAS signaling connection with the AMF. The NAS can (e.g., then) treat the WTRU as being in 5GMM-CONNECTED mode via non-3GPP access. For mobile termination communications from the network, the WTRU can (e.g., then) be reachable. For example, the WTRU can receive a NAS notification message from the network indicating that downlink data is available to the WTRU. For example, a WTRU in 5GMM-CONNECTED mode via non-3GPP access can (e.g., typically) remain in 5GMM-CONNECTED mode unless the WTRU disconnects from the non-3GPP network.

[0111] For example, if a WTRU is registered via a non-3GPP access network (e.g., when a WTRU is registered via a non-3GPP access network), the periodic registration update procedure may be prohibited (e.g., the periodic registration update procedure may not be performed).

[0112] For example, a WTRU registered via non-3GPP access can indicate unavailable periods to the network, thereby enabling the network and the WTRU to maintain the WTRU's registration status, and / or enabling the network to understand that the WTRU may be unreachable for mobile termination communication.

[0113] For MUSIM devices, unavailability period support can be provided. One or more examples described in this document can indicate how unavailability features can be handled for MUSIM devices registered to two (2) or more different networks.

[0114] In some examples, multiple (e.g., two) networks may support the unavailability feature. In some examples, two networks may provide (e.g., the same) unavailability duration. In some examples, the unavailability duration can be determined based on results from the first network. In some examples, at least one of the networks may not support the unavailability feature.

[0115] A MUSIM WTRU can be registered to multiple networks. NAS signaling procedures can be executed sequentially (e.g., only sequentially). While communicating with the network about unavailability periods, there may be elements of delay (e.g., these elements of delay can be taken into account). Sequentially reporting unavailability to the network while removing it can be considered, for example, to ensure the network is notified within a specified time frame.

[0116] For example, one or more examples described herein may indicate how a MUSIM WTRU with different configurations (e.g., all networks support the unavailability feature or one or more networks do not support the unavailability feature) can indicate unavailability periods to one or more networks, so that one or more networks and the MUSIM WTRU can maintain the registration status of the MUSIM WTRU, and / or so that the network understands that the WTRU is not reachable for mobile termination communication.

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

[0118] One of several networks (e.g., EPS) may not support negotiation of unavailability periods for the S1 NAS interface, for example, between the WTRU and the EPS's Mobility Management Entity (MME). One or more examples described herein may indicate how the EPS knows (e.g., determines) to prohibit (e.g., not to delete) the context of the WTRU and / or how it knows (e.g., determines) to prohibit attempts to contact the WTRU for mobility termination communication (e.g., not to contact the WTRU for mobility termination communication).

[0119] For unavailability period characteristics, analytical capabilities (e.g., NWDAF) can be provided. As described herein, NWDAF can provide statistics and / or predictions to other network functions. As described herein, for example, by sending the duration of the unavailability period in a registration request or by providing the duration of the unavailability period in a deregistration request, the WTRU can indicate to the AMF that the WTRU may be unavailable for a certain period of time.

[0120] Several scenarios need to be considered. First, the unavailability period provided by the WTRU to the AMF may not be a public event. For example, an unavailability period may occur (e.g., only when the WTRU is installing a software upgrade). Second, multiple (e.g., many) WTRUs in the area may install software upgrades at the same or similar times. Multiple WTRUs may become unavailable and then become available again at approximately the same time. Third, the unavailability period provided by the WTRU can be a strong indication of when the WTRU can attempt to perform registration procedures with the network (e.g., it can be expected that the WTRU can attempt to register with the network during the duration of the unavailability period).

[0121] The duration of unavailability periods requested by WTRUs can significantly influence future events that may occur in the network. The duration of unavailability periods requested by WTRUs can also affect the accuracy of statistics and forecasts provided by NWDAF to other network functions. NWDAF can obtain the duration of unavailability periods and / or can take the duration of unavailability periods into account when generating statistics and forecasts (e.g., using one or more features described herein).

[0122] For trunk WTRUs, unavailability period feature support can be provided. One or more examples described in this document can indicate how to handle situations involving trunk WTRUs, how to handle unavailability events of trunk WTRUs and remote WTRUs, and / or how to maintain coordination between connected trunk WTRUs and remote WTRUs.

[0123] The WTRU can be configured (e.g., configured by the network) to use a (e.g., strictly periodic) registration duration (e.g., timer) feature. As described above, the strictly periodic registration timer feature can be configured so that the WTRU is in CM-CONNECTED mode and can be used to receive downlink data at predictable times. This feature can be useful for devices that use MICO mode and / or enter long sleep durations, for example, to save power. The opportunities when these devices (e.g., WTRUs) are available for downlink data may be very infrequent (e.g., every few hours or even days). If the WTRU request overlaps with an unavailable period of time when the WTRU is expected to be available for downlink data, this can cause the WTRU to miss downlink data that can be sent from a server that the server expects the WTRU to be available at the expected time.

[0124] Multiple parties (e.g., third parties) may be involved to perform certain events (e.g., operations), such as OS upgrades, silent resets of the modem, or modem software updates (e.g., also known as binary updates). The involved parties may include, for example, devices (e.g., WTRUs), operators, and application functions.

[0125] Whenever such an operation is performed, the WTRU may become unavailable for a period of approximately several minutes (e.g., it may be unable to interact with the 5G system). The WTRU may become unavailable without prior knowledge of the core network and / or application functions. For example, if an application server relies on the availability of the WTRU during a period of unavailability (e.g., a period when the WTRU is unavailable), unexpected WTRU unavailability could impact the operation of the application server (e.g., critical operations).

[0126] This document describes systems, methods, and tools that address unavailability time period characteristics in various scenarios, such as: if a fallback duration (e.g., a timer) might be running (e.g., when a fallback duration (e.g., a timer) might be running); if the WTRU might be registered to a network (e.g., 5GS) via non-3GPP access (e.g., only via non-3GPP access) (e.g., when the WTRU might be registered to a network (e.g., 5GS) via non-3GPP access (e.g., only via non-3GPP access)); if the MUSIM device can be registered to multiple networks that support and do not support unavailability characteristics (e.g., when the MUSIM device can be registered to multiple networks that support and do not support unavailability characteristics). (When multiple networks do not support the unavailability feature); if the WTRU is registered to multiple networks (e.g., both EPS and 5GS) (e.g., when the WTRU is registered to multiple networks (e.g., both EPS and 5GS)); to support the analysis capability of the unavailability feature (e.g., NWDAF); if a remote WTRU and / or a trunk WTRU enters an unavailability period (e.g., when a remote WTRU and / or a trunk WTRU enters an unavailability period); if the MICO mode and / or strictly periodic registration duration (e.g., timer) feature is enabled (e.g., when the MICO mode and / or strictly periodic registration duration (e.g., timer) feature is enabled), etc.

[0127] While the fallback duration (e.g., a timer) is running, unavailable time periods can be provided. For example, when mobility management (e.g., 5GMM) signaling congestion is detected, the AMF can perform (e.g., normal) NAS-level congestion control. The WTRU (e.g., under 5GMM signaling congestion conditions) can prohibit the transmission (e.g., not transmit, not allowed to transmit) of mobility registration update messages, for example, except for one or more situations such as emergency situations and / or high-priority services.

[0128] AMF may (e.g., if normal NAS-level congestion control is active / when normal NAS-level congestion control is active) reject NAS messages and include a value for the Mobility Management (MM) backoff duration (e.g., a timer, such as T3346) in the rejection message. WTRU may begin tracking the duration (e.g., a timer, such as T3346) with the value received in the MM (e.g., 5GMM) rejection message. For example, if the backoff duration (e.g., the timer) is running (e.g., while the backoff duration (e.g., the timer) is running), the WTRU may prohibit (e.g., be blocked) sending one or more (e.g., certain) NAS messages (e.g., mobility registration updates). For example, if the backoff duration (e.g., the timer) is running (e.g., while the backoff duration (e.g., the timer) is running), the WTRU may respond to network-initiated signaling (e.g., paging triggered by downlink data).

[0129] For example, based on the detection of an event in the WTRU that may (e.g., will) render the WTRU unavailable for a certain (e.g., a specific) period of time (e.g., when the event is detected), the WTRU may notify the network of the start of the unavailable period. For example, if the WTRU is able to maintain both the MM (e.g., 5GMM) and SM (e.g., 5GSM) contexts, the WTRU may notify the network of the start of the unavailable period via a registration request message (e.g., including the unavailable period IE). However, in one or more situations, the WTRU may prohibit notification of its unavailability to the network (e.g., AMF) (e.g., not notifying the network (e.g., AMF) of the WTRU's unavailability, or being unable to notify the network (e.g., AMF) of the WTRU's unavailability). For example, if NAS-level congestion control is active (e.g., when NAS-level congestion control is active), the WTRU may prohibit (e.g., not allow triggering) ULNAS signaling to send mobility registration updates.

[0130] Without notifying the network, the WTRU can prevent (e.g., not perform) actions that would render the WTRU unusable. For example, if the network is not notified, it can initiate signaling to the WTRU and find that the WTRU does not respond. For instance, the WTRU might not respond because it may be performing an action that renders it unusable (e.g., a software upgrade).

[0131] For example, if a fallback duration (e.g., a timer) is running (e.g., even while the fallback duration (e.g., a timer) is running), the WTRU may (e.g., be permitted) send a mobility registration update to the network. The WTRU may generate NAS signaling to notify the network of the unavailability period, and then notify the network again that the WTRU is available again. This signaling can be generated while the fallback duration (e.g., a timer) is running. In some examples, multiple WTRUs in the same area may be performing the same software upgrade. For example, even during congestion scenarios, unavailability and availability signaling from multiple WTRUs may trigger a large number of NAS signaling requests that will be handled by the network.

[0132] While NAS-level congestion control is active (e.g., while a duration or timer is running, such as T3346), the WTRU may (e.g., be permitted) send a registration request message (e.g., including an unavailable period IE). The WTRU may (e.g., be configured to) prevent or avoid (e.g., constrained to ensure the registration request message does not include) subsequent requests, uplink data condition IEs, and / or permitted PDU session condition IEs. The WTRU may (e.g., also) be configured (e.g., constrained) to (e.g., only) request an unavailable period duration greater than or equal to the amount of time remaining on the NAS backoff duration (e.g., timer, such as T3346).

[0133] The AMF (e.g., based on a registration request that includes an unavailable time period request received while a rollback timer is running) can respond to the WTRU with information including one or more of the following indications (e.g., indications indicated in the registration acceptance message): (i) registration and the unavailable time period are accepted; (ii) a previously provided rollback duration (e.g., a timer, such as T3346) can continue to run and is not reset, for example, indicating to the WTRU that the WTRU can still consider NAS-level congestion control active; (iii) a new rollback duration (e.g., a timer) value (e.g., T3346) to indicate to the WTRU that the WTRU can still consider NAS-level congestion control active; (iv) for example, the WTRU can notify the AMF when the WTRU becomes available again, even though the rollback duration (e.g., a timer) is running (e.g., T3346); and / or (v) if the rollback duration (e.g., a timer) is running (e.g., T3346), the WTRU can not notify the AMF when the WTRU becomes available again.

[0134] The example indication in the registration acceptance message allows AMF to control whether the WTRU generates additional signaling when it becomes available again. Figure 2An exemplary procedure is shown whereby the WTRU signals a period of unavailability and the AMF (e.g., still) limits the amount of NAS signaling.

[0135] Figure 2 The diagram illustrates an example of unavailability events that may occur while NAS-level congestion control is active. For example... Figure 2 As shown in Figure 210, for example, NAS-level congestion control may be active for the WTRU because the WTRU receives a rejection response from the AMF. The rejection response may include a duration (e.g., a timer, such as the T3346 timer). NAS-level congestion control may be active in the WTRU. This duration (e.g., or other durations) may be running (e.g., the T3346 and / or (one or more) other backoff timers may be running). The WTRU may disable (e.g., not trigger, or may not be allowed to trigger) NAS-level signaling, for example, except in cases where high-priority access, emergency services, and / or the WTRU is responding to a paging from the network side.

[0136] exist Figure 2 In section 220, the WTRU may detect an event that requires execution within the WTRU, which could render the WTRU unavailable for a certain period of time. The WTRU may also detect, for example, the amount of time during which the WTRU is expected to be available. This time value may be provided by an application or the operating system.

[0137] exist Figure 2 In section 230, the WTRU may trigger a registration request procedure toward the AMF. The WTRU may provide an unavailable period (IE) to notify the network of the WTRU's unavailable duration. For example, if the duration determined in section 220 is greater than the amount of time remaining on the fallback duration (e.g., a timer, such as T3346), the WTRU (e.g., if a fallback timer is running in the WTRU) may (e.g., determine) set the unavailable period to the duration determined in section 220. Otherwise, the WTRU may (e.g., determine) request a time greater than or equal to the amount of time remaining on the fallback duration (e.g., a timer).

[0138] exist Figure 2In section 240, the AMF may take into account the existence of an unavailable period (IE), prohibit the rejection (e.g., not reject) of registration requests, and / or respond using a registration accept message. The AMF may (e.g., also) use the registration accept message to indicate that a previously provided backoff duration (e.g., a timer, such as T3346) can continue to run and not be reset, to provide a new backoff duration (e.g., a timer) value (e.g., T3346) to indicate to the WTRU that the WTRU can still consider NAS-level congestion control active, and / or to provide an indication, for example, whether the WTRU can notify the AMF when the WTRU becomes available again, even if the backoff duration (e.g., a timer) is running.

[0139] exist Figure 2 In section 250, the WTRU can (for example, successfully) perform events that render the WTRU unusable, such as a silent modem reset, security patch update, OS upgrade, modem SW update, and / or device reboot upon modem setting changes via OMA-DM.

[0140] exist Figure 2 In option 260, for example, if the fallback duration (e.g., a timer) is no longer running, or if the AMF indicates in option 240 (e.g., even if the fallback timer is running) that the WTRU may notify the AMF when the WTRU becomes available again, then the WTRU may notify the AMF (e.g., successfully) that an unavailability event has been performed. For example, by sending a registration request message, such as prohibiting the inclusion (e.g., exclusion) of the unavailability period IE, the WTRU may notify the AMF (e.g., successfully) that an unavailability event has been performed. For example, if the fallback duration (e.g., a timer) is running, or if the AMF indicates in option 240 that the WTRU may prohibit notification (e.g., not notify) the AMF when the WTRU becomes available again while the fallback duration (e.g., a timer) is running, then the WTRU may wait until the fallback duration (e.g., a timer) expires, and then notify the AMF (e.g., successfully) that an unavailability event has been performed. The WTRU can wait until the fallback duration (e.g., a timer) expires, and then notify the AMF (e.g., that the unavailable event was successfully executed) by sending a registration request message, such as prohibiting the inclusion (e.g., exclusion) of the unavailable time period IE.

[0141] Reference Figure 2 For cases where a rollback duration (e.g., a timer) is in progress, another exemplary procedure is provided. WTRU can perform one or more of the following operations.

[0142] like Figure 2As shown, at 210, the WTRU may receive a NAS rejection message indicating that the WTRU is constrained due to a congestion scenario in the network. The NAS rejection message may include a duration (e.g., a timer value) indicating how long the WTRU can consider the congestion scenario applicable and / or how long the constraint applies. For example, based on receiving this duration (e.g., the timer value), the WTRU may begin tracking a fallback duration (e.g., a fallback timer).

[0143] like Figure 2 As shown in Figure 220, the WTRU may detect an event that requires execution within the WTRU, which could render the WTRU unavailable for a certain (e.g., a specific) time period. The WTRU can detect the amount of time during which the WTRU is expected to be available.

[0144] like Figure 2 As shown in Figure 230, the WTRU may send a registration request to the network. The registration request may include the duration of WTRU unavailability. For example, the duration of WTRU unavailability may be set to a value greater than or equal to the fallback duration (e.g., a timer value) based on the run fallback duration (e.g., a timer) and / or based on a fallback duration (e.g., a timer value) greater than the amount of time the WTRU is expected to be available.

[0145] like Figure 2As shown, at 240, the WTRU can receive a registration acceptance message from the network. The registration acceptance message may include an indication that a previously provided rollback duration (e.g., a timer, such as T3346) can continue to run and not be reset, which may cause or trigger the WTRU to continue applying NAS-level congestion control. The registration acceptance message may include a different (e.g., a new) rollback duration (e.g., a timer) value (e.g., T3346) to indicate to the WTRU that the WTRU can still consider NAS-level congestion control active, which may cause or trigger the WTRU to continue applying NAS-level congestion control and / or assign a different (e.g., a new) value to the rollback duration (e.g., the timer). The registration acceptance message may include, for example, an indication that the WTRU can notify the AMF even if the rollback duration (e.g., the timer) is running (e.g., T3346) when the WTRU becomes available again, which may trigger the WTRU to send a registration update request to the network when the unavailability event ends. The registration update request may prohibit (e.g., exclude) the unavailability period duration. The registration acceptance message may include an indication that the WTRU may prevent notification (e.g., not notify) of the AMF when it becomes available again while the rollback duration (e.g., a timer) is running (e.g., T3346). This may cause or trigger the WTRU not to send a registration update request to the network when the unavailability event ends, while the rollback duration (e.g., a timer) is still running. When the rollback duration (e.g., a timer) expires, the WTRU may (e.g., determine) send a registration update request to the network. The registration update request may exclude (e.g., exclude) the unavailability period duration.

[0146] While registering the WTRU via non-3GPP access (e.g., non-3GPP access only), unavailability period support can be provided. The network (e.g., a 5G system) can allow (e.g., instruct) the WTRU to send a registration request to the AMF via non-3GPP access. The registration request may include unavailability information (e.g., an unavailability period duration information element (IE)).

[0147] Based on receiving unavailability information (e.g., unavailability duration information element) from a WTRU that is not registered for 3GPP access (e.g., when unavailability information is received from that WTRU), the AMF may (e.g., be triggered to) perform one or more actions. For example, the AMF may be triggered to perform one or more of the actions below.

[0148] The AMF can send a registration response to the WTRU to indicate, for example, that the unavailable time duration request is accepted and that the network now considers the WTRU to be in an idle state (e.g., 5GMM-IDLE state). For example, the AMF can indicate the acceptance of the unavailable time duration by sending an accepted unavailable time duration to the WTRU. The AMF can assign the accepted unavailable time duration, which is equal to or greater than the requested unavailable time duration.

[0149] AMF can treat WTRU as being in an idle state (e.g., 5GMM-IDLE state).

[0150] AMF can begin tracking durations (e.g., wait timers). AMF can assign an initial value to this duration (e.g., wait timers), which can be equal to the unavailable time period duration provided in the registration request.

[0151] AMF can treat the WTRU as unreachable until the WTRU sends an initial NAS message. Examples of initial NAS messages include, for example, a registration request, a service request, and / or a control plane service request.

[0152] For example, if the duration (e.g., a wait timer) expires before the AMF receives the initial NAS message from the WTRU, the AMF can consider the WTRU as having been deregistered (e.g., in a 5GMM-DEREGISTERED state).

[0153] Figure 3 The illustration shows an example when the unavailable time period feature is used by a WTRU registered via non-3GPP access. For example, Figure 3 This demonstrates support for unavailable time period features when the WTRU can be registered to the network (e.g., 5GCN) via non-3GPP access (e.g., only via non-3GPP access).

[0154] like Figure 3 As shown in Figure 310, the WTRU can be registered to the 5GCN via non-3GPP access (e.g., non-3GPP access only). Non-3GPP access can be trusted or untrusted.

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

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

[0157] At 340, the AMF can begin tracking durations (e.g., wait timers). The AMF can initially set this duration (e.g., wait timer) value to be equal to or greater than the duration of the unavailable period.

[0158] At 350, the AMF can send a registration acceptance message to the WTRU. The registration acceptance message can indicate acceptance of the requested unavailability period duration, and / or can provide the WTRU with a value for the unavailability period duration available to the WTRU. The AMF can (e.g., now) consider the WTRU to be in an idle state (e.g., 5GMM-IDLE state) and unreachable. For example, if downlink data notifications are available from the SMF, the AMF can indicate to the SMF that the WTRU is unreachable. For example, if there is a connection loss event subscription for the WTRU by the AF, the AMF can trigger a connection loss event report to the NEF. The connection loss event report can include the unavailability period. The unavailability period can (e.g., also) be reported to the corresponding subscribed AF.

[0159] At 360, the WTRU can (for example, successfully) execute events that render the WTRU unusable, such as a silent modem reset, security patch update, OS upgrade, modem SW update, and / or device reboot upon modem setting changes via OMA-DM.

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

[0161] At 380, for example, based on the receipt of the initial NAS message (e.g., upon receipt of the initial NAS message), the AMF may stop tracking the duration (e.g., stop the wait timer). The AMF may treat the WTRU as being in a connected state (e.g., 5GMM-CONNECTED state) and / or as being reachable. For example, if the message provided at 370 is not received or is not received before the end of the wait time, the AMF may (e.g., implicitly) revoke the WTRU's registration.

[0162] For MUSIM devices, support for unavailability periods is available. Unavailability coordination can be provided across networks.

[0163] A WTRU can be registered to multiple (e.g., two (2)) networks. The WTRU can send a registration request to a first network (e.g., among multiple networks). This registration request may include an unavailable period duration. The first network may respond using a registration acceptance message and / or a periodic registration duration (e.g., a timer), which may be greater than or equal to the requested unavailable period duration. The WTRU may (e.g., then) send the registration request to a second network. The WTRU may include a second unavailable period duration in its request to the second network. The WTRU may (e.g., optionally) set the second unavailable period duration to be equal to or greater than the value of the periodic registration timer received from the first network. This approach helps ensure that the second network prohibits (e.g., does not instruct) the WTRU to re-register before (e.g., well before) the time associated with the first network (e.g., requested by the first network).

[0164] Figure 4 This demonstrates an example of how WTRU can use unavailable time period features in situations where MUSIM features are also used.

[0165] Figure 4 The diagram illustrates an exemplary procedure for unavailable coordination across networks.

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

[0167] At 420, the WTRU can detect an event that the WTRU needs to execute, which can be associated with the WTRU being unavailable for a certain period of time (e.g., requiring the WTRU to be unavailable). The WTRU can determine the duration of the first unavailable period.

[0168] At 430, the WTRU may send a registration request to the first network. This registration request may include the duration of the first unavailable period.

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

[0170] At 450, the WTRU can determine the duration of the second unavailable period. The WTRU can set the duration of the second unavailable period to be equal to or greater than the value of the periodic registration timer received from the first network. Setting the duration of the second unavailable period in this way ensures that the WTRU has sufficient time to contact multiple (e.g., two) networks when the unavailable period ends.

[0171] At 460, the WTRU can send a registration request to a second network. This registration request may include the duration of a second unavailable period.

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

[0173] In some examples, multiple (e.g., two or all) networks may support the unavailability period feature. For example, a MUSIM WTRU may have multiple SIM cards, such as more than two (2) USIM cards. A MUSIM WTRU may be registered to different networks. In some examples (e.g., Figure 5 In the example shown below, the MUSIM WTRU can be equipped with multiple (e.g., two) USIM cards and / or can be registered to multiple (e.g., two) different (e.g., 5G) networks. Other configurations can be implemented.

[0174] Figure 5 The illustration shows an example of unavailability coordination across multiple networks when multiple networks (e.g., two 5G networks) support unavailability features.

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

[0176] In 520, an event may occur in the WTRU that renders the WTRU unavailable for a certain period of time. The WTRU (e.g., as a MUSIM device) may communicate sequentially with the network (e.g., 5GS). The MUSIM WTRU may account for delays in the registration process (revocation of registration).

[0177] In 530, the MUSIM WTRU can select / choose a first network, such as AMF-1. The WTRU can send a registration request message to AMF-1. For example, this message may include the duration of the unavailability period (IE) and a start delay (e.g., Δt). The delay start (Δt) can be notified to network AMF-1: the unavailability period can take into account the delay with the provided delay start duration value and / or the actual duration for which the WTRU will be unavailable, e.g., unavailability period duration + Δt. The delay start can be estimated considering the number of pending (revoked registration) registration procedures that the MUSIM WTRU may execute (e.g., need to) to notify other networks of unavailability. For example, Δt can be estimated as Δt = (N=1) x (the time requested (e.g., required) for a (revoked registration) to notify AMF-2 of unavailability + registrations used to notify network (AMF-2) of the end of the unavailability period), where N can be the number of (revoked registration) registrations that MUSIM may (e.g., need to) execute. Figure 5 In the exemplary scenario shown, there may also be a registration event to notify the AMF-2 of a period of unavailability. The time associated with the (revocation) registration (e.g., the time required for (revocation) registration, e.g., the requested time) may take into account best and / or worst-case scenarios, such as retransmitting timers / counters, retrying timers / counters, etc. Revocation of registration as a power outage may take into account the duration (e.g., a timer) for which the WTRU can wait for a response from the network. For example, if no response is received from the network, the MUSIM WTRU may consider (e.g., implicitly) revocation of registration.

[0178] At 440, using the registration acceptance message, AMF-1 can respond. AMF-1 can (for example, subsequently) release the RRC signaling connection.

[0179] At 550, the MUSIM WTRU can send the registration request to a second AMF, such as AMF-2, as the last instance that needs to be notified of unavailability. The delay start can be set to zero (0), for example, Δt = 0.

[0180] At 560, using the registration acceptance message, AMF-2 can respond. AMF-2 can (e.g., subsequently) release the connection (e.g., RRC signaling connection).

[0181] In 570, the MUSIM WTRU can (for example, successfully) perform events that render the MUSIM WTRU unusable, such as a silent modem reset, security patch update, OS upgrade, modem SW update, and / or device restart upon modem setting changes via OMA-DM.

[0182] At 580, the MUSIM WTRU can send a registration request message to AMF-2 (e.g., prohibiting the inclusion (e.g., excluding) of the unavailability period duration IE) to notify the network that the MUSIM WTRU is now available. There may be an order for exiting unavailability. For example, the network last notified of the unavailability period may be the first network to be notified of availability. In an exemplary scenario, AMF-2 may be given priority over AMF-1 in notifying the WTRU of availability. The delay provided to AMF-1 may take into account the delay for notifying the other network of unavailability, which may be followed by availability and / or corresponding procedural timing.

[0183] At 590, the MUSIM WTRU can send a registration request message to AMF-1 (e.g., excluding the unavailable period duration IE) to notify the network that the MUSIM WTRU is available (e.g., now).

[0184] Reference Figure 5 This provides an example where multiple (e.g., two or all) networks can support unavailable time period characteristics. MUSIM WTRU can perform one or more of the following operations.

[0185] like Figure 5 As shown in Figures 510-520, a MUSIM device (e.g., a WTRU) with two (2) active USIM cards can (e.g., successfully) register to two (2) different (e.g., 5G) networks, such as AMF-1 and AMF-2, that support the unavailability feature. An event may occur in the WTRU that renders it unavailable for a certain (e.g., a specific) time period. The WTRU (e.g., as a MUSIM device) can communicate sequentially with the network (e.g., 5GS). The MUSIM WTRU can account for delays in the registration process (revocation of registration).

[0186] like Figure 5 As shown, at 530 / 540, the MUSIM WTRU may select / choose a first network (e.g., AMF-1) and send a registration request message, which may include the unavailability period duration (IE) and / or the start delay Δt. The delay start (Δt) may be notified to network AMF-1: the unavailability period may take into account the delay with the provided delay start duration value. The actual duration for which the WTRU may be unavailable may be the unavailability period duration + Δt. For example, the delay start can be estimated by taking into account the number of pending (revoked registration) registration procedures that the MUSIM WTRU may perform (e.g., need to) to notify other networks of unavailability.

[0187] exist Figure 5 In the example shown, for instance, Δt can be determined as Δt = (N=1) x (the time requested (e.g., required) for a (revoked registration) to notify AMF-2 of unavailability + the number of registrations used to notify the network (AMF-2) of the end of the unavailability period), where N can be the number of (revoked registrations) that MUSIM can (e.g., needs) to perform. Figure 5 In the exemplary scenario shown, there may also be a registration event to notify AMF-2 of the unavailable time period.

[0188] The time associated with (revoking registration) registration (e.g., the time required for (revoking registration) registration) may take into account best and / or worst-case scenarios, such as retransmitting timers / counters, retrying timers / counters, etc. Revoking registration as a power-down event may take into account the duration for which the WTRU can wait for a response from the network (e.g., timer duration). For example, if no response is received from the network, the MUSIM WTRU may consider revoking registration (e.g., implicit revoking registration). For example, if AMF-1 responds with a registration accept message, AMF-1 may (e.g., then) release the RRC signaling connection.

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

[0190] like Figure 5 As shown, at 570 / 580 / 590, the WTRU can (e.g., successfully) execute events that render the WTRU unavailable, such as a silent modem reset, security patch update, OS upgrade, modem SW update, and / or device reboot upon modem setting changes via OMA-DM. The MUSIM WTRU can send a registration request message to AMF-2 (e.g., excluding the unavailability period duration IE) to notify the network that the MUSIM WTRU is now available. There may be a certain order for exiting unavailability. For example, the network last notified of the unavailability period may be the first network to be notified of availability. For example, as... Figure 5As shown, AMF-2 can be given priority over AMF-1 in notifying the WTRU of its availability. The delay provided to AMF-1 may take into account the delay for notifying the other network of unavailability, for example, followed by availability and corresponding procedure timing. The MUSIM WTRU may send a registration request message to AMF-1 (e.g., excluding the unavailability period duration IE) to notify the network that the MUSIM WTRU (e.g., is now available).

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

[0192] Figure 6 The illustration shows an example of unavailability coordination across multiple networks when one of the networks does not support the unavailability feature of MUSIM WTRU.

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

[0194] In 620, an event may occur in the WTRU that renders it unavailable for a certain period of time. The WTRU (e.g., as a MUSIM device) may communicate sequentially with the network (e.g., 5GS). The MUSIM WTRU may account for delays in the registration process (revocation of registration).

[0195] In 630, the MUSIM WTRU can selectively send the registration request message to the first network (e.g., AMF-1), for example, the message including the unavailability period duration IE and / or the start delay Δt. The delay start (Δt) can be notified to network AMF-1: the unavailability period can take into account the delay with the provided delay start duration value. The actual duration for which the WTRU may be unavailable can be the unavailability period duration + Δt. For example, the delay start Δt can be estimated by taking into account the number of pending (revoked registration) registration procedures that the MUSIM WTRU may execute (e.g., need to) to notify other networks of unavailability. For example, as... Figure 6As shown, the other network may not support unavailable features (e.g., EPS or 5GS that do not support the feature). The delay initiation may take into account the duration associated with revoking WTRU registration from the other network (e.g., the duration that revoking WTRU registration from the other network may take).

[0196] At 640, using the registration acceptance message, AMF-1 can respond. AMF-1 can (for example, subsequently) release the RRC signaling connection.

[0197] In the 650, the second network (AMF-2 / MME) may not support this feature. For example, the WTRU can trigger deregistration towards that network by sending a deregistration request message (e.g., with a reason code as a power failure).

[0198] In some examples, MUSIM WTRU and AMF-2 / MME can support MICO mode, whereby the MUSIM WTRU can initiate MICO mode, for example, as an alternative to the deregistration procedure. When setting the active time for MICO mode, the network can take into account the duration of the available unavailability period. The active time may not coincide with the unavailability period. The active time may begin after the duration of the unavailability period. The network can (e.g., alternatively) set a periodic registration duration (e.g., a timer duration) equal to or greater than the duration of the unavailability period, which ensures that the WTRU can perform periodic registration when it becomes available again. During periodic registration, the network can reconfigure the WTRU using anticipated parameters (e.g., the new periodic registration duration / timer value).

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

[0200] In 660, the WTRU can (for example, successfully) perform events that render the WTRU unusable, such as a silent modem reset, security patch update, OS upgrade, modem SW update, and / or device restart upon modem setting changes via OMA-DM.

[0201] At 670, the MUSIM WTRU can send a registration request message to AMF-2 (e.g., prohibiting the inclusion (e.g., excluding) of the unavailability period duration IE) to notify the network that the MUSIM WTRU is now available. There may be a certain order for removing unavailability. For example, the network last notified of the unavailability period may be the first network to be notified of availability. For example, as... Figure 5As shown, AMF-2 / MME can be given priority over AMF-1 in notifying WTRU of availability. The delay start provided to AMF-1 can take into account the delay for notifying the other network of unavailability, for example, followed by availability and corresponding procedure timing.

[0202] At 680, the MUSIM WTRU can send a registration request message to the AMF-1 (e.g., excluding the unavailable period duration IE), which notifies the network that the MUSIM WTRU is available (e.g., now).

[0203] Reference Figure 6 Here is another exemplary procedure: one of the networks may not support the unavailable time period feature. MUSIMWTRU can implement one or more of the following operations.

[0204] like Figure 6 As shown in diagrams 610-620, a MUSIM device (e.g., a WTRU) may have two (2) active USIM cards. The MUSIM WTRU may be successfully registered to two (2) different networks, such as AMF-1 and AMF-2 / MME. In an exemplary scenario, the second network may be an EPS that does not support unavailability features or a 5G network (e.g., AMF) that does not support unavailability features. An event may occur in the WTRU that renders it unavailable for a period of time. The WTRU (e.g., as a MUSIM device) may (e.g., sequentially) communicate with 5GS. The MUSIM WTRU may account for delays in the registration process (revocation of registration).

[0205] like Figure 6 As shown, at 630 / 640, the MUSIM WTRU may select a first network (e.g., AMF-1) and send a registration request message, including, for example, the duration of the unavailability period IE and / or the start delay Δt. The delay start (Δt) may be notified to network AMF-1: the unavailability period may take into account the delay with the provided delay start duration value. The actual duration for which the WTRU may be unavailable can be estimated as the unavailability period duration + Δt. For example, the delay start Δt can be estimated by taking into account the number of pending (revoked registration) registration procedures that the MUSIM WTRU may perform (e.g., need to) to notify other networks of unavailability. For example, as... Figure 6 As shown, the other network does not support unavailable features (e.g., EPS or 5GS that do not support the feature). The delay initiation can take into account the duration that may be spent revoking the MUSIM WTRU registration from the other network. The AMF-1 can respond using the registration acceptance message. The AMF-1 can (e.g., subsequently) release the connection (e.g., RRC signaling connection).

[0206] like Figure 6 As shown, at 650, the second network (e.g., AMF-2 / MME) may not support this feature. For example, the WTRU can trigger deregistration towards that network by sending a deregistration request message (e.g., with a reason code as a power outage).

[0207] In some examples, MUSIM WTRU and AMF-2 / MME can support MICO mode. MUSIM WTRU can initiate MICO mode, for example, as an alternative to a deregistration procedure. When setting the active time for MICO mode, the network can take into account the duration of the available unavailability period. The active time may not coincide with the unavailability period. The active time may begin after the duration of the unavailability period. The network can (e.g., alternatively) set a periodic registration duration (e.g., a timer duration) equal to or greater than the duration of the unavailability period, which ensures that the WTRU can perform periodic registration when it becomes available again. During periodic registration, the network can reconfigure the WTRU using anticipated parameters (e.g., the new periodic registration duration / timer value).

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

[0209] like Figure 6 As shown, at 660 / 670 / 680, the WTRU can (e.g., successfully) execute events that render the WTRU unavailable, such as a silent modem reset, security patch update, OS upgrade, modem SW update, and / or device reboot upon modem setting changes via OMA-DM. The MUSIM WTRU can send a registration request message to AMF-2 (e.g., excluding the unavailability period duration IE) to notify the network that the MUSIM WTRU is now available. There may be a certain order for exiting unavailability. For example, the network last notified of the unavailability period may be the first network to be notified of its availability. For example, as... Figure 6 As shown, AMF-2 / MME can be given priority over AMF-1 in notifying the WTRU of its availability. The delay provided to AMF-1 may take into account the delay for notifying the other network of unavailability, for example, followed by availability and corresponding procedural timing. The MUSIM WTRU may send a registration request message to AMF-1 (e.g., excluding the unavailability period duration IE) to notify the network that the MUSIM WTRU (e.g., is now available).

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

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

[0212] For example, if the AMF detects that the WTRU is capable of operating in both S1 and N1 modes, has a public registration for 5G and EPS access, or is dually registered, and in this example, the AMF receives a registration request from the WTRU including the duration of an unavailable period, the AMF may (e.g., based on the registration request) send a notification to the MME (e.g., via the N26 interface). This notification may indicate to the MME that the WTRU will be unavailable for a certain period. This notification may include the duration of the unavailable period or a periodic registration time that the AMF may send to the WTRU in a registration response. For example, based on the duration of the unavailable period or the periodic registration time in the notification, the MME may determine (e.g., make known) how long the WTRU is expected to be unavailable. Based on receiving this notification, the MME may perform one or more of the following actions (e.g., any combination thereof).

[0213] For example, the MME may (e.g., begin) treat the WTRU as unreachable and / or may reject (e.g., any) downlink data notifications associated with the WTRU, for example, until at least the time period indicated in the notification has elapsed. For example, the MME may (e.g., also) adjust the duration (e.g., the timer) that can be associated with the WTRU by assigning a value (at least the time period indicated in the notification) to that duration (timer, e.g., an implicit detached timer).

[0214] For example, the MME may respond to the AMF with the following indication: the MME disagrees with maintaining the WTRU's context while the WTRU is unavailable, and / or the AMF may instruct the WTRU, for example, that the WTRU may be considered to have been deregistered from EPS, and that the WTRU may transition from EMM-REGISTERED to EMM-DEREGISTERED status. The response from the MME may (e.g., also) include different (e.g., new) periodic tracking area update duration (e.g., timer) values ​​for the AMF to send to the WTRU.

[0215] For example, based on sending a notification to the MME and receiving a response from the MME (e.g., upon sending a notification to the MME and receiving a response from the MME), the AMF may send a registration response to the WTRU. The registration response may include one or more of the following indications: an indication that the unavailable time period is shared with the MME and / or that the WTRU may perform a tracking area update with the MME when the unavailable event may be completed; an indication that the unavailable time period is rejected by the MME and / or, for example, that the WTRU is considered to have been deregistered from the EPS and transitioned from an EMM-REGISTERED state to an EMM-DEREGISTERED state; and / or a value (e.g., a new value) that the WTRU may assign to its EPS periodic tracking area for a new duration (e.g., a timer) value.

[0216] The WTRU can complete periods of inactivity. The WTRU can (e.g., upon completion of an inactivity period) perform a registration area update procedure with the 5GS and a tracking area update procedure with the EPS. For example, if the WTRU has not transitioned to an EMM-DEREGISTERED state (e.g., only if the WTRU has not transitioned to an EMM-DEREGISTERED state), the tracking area update procedure can be performed. For example, if the WTRU has transitioned to an EMM-DEREGISTERED state, the WTRU can perform an attachment procedure with the EPS.

[0217] The advantages provided by unavailability support for devices registered to multiple networks (e.g., EPC and 5GC) may include one or more of the following advantages: EPS NAS signaling can prevent changes (e.g., no changes are required); the EPS context can be maintained while the WTRU is unavailable; and / or the WTRU can determine (e.g., make it known) whether the MME is unable or unwilling to maintain the EPS context while the WTRU is unavailable.

[0218] Figure 7 The illustration shows an example of a dual registration scenario where the WTRU has both 5GMM and EMM contexts.

[0219] like Figure 7 As shown, in 710, the WTRU can be enabled for both 5GMM and EMM. The WTRU can operate in single-registration mode. For 3GPP-accessed 5GMM and EMM, the WTRU can maintain (e.g., one) a public registration. The WTRU can be successfully updated on both 5GMM and EMM (e.g., the S1 mode registration status is EMM-REGISTERED, and the N1 mode registration status is 5GMM-REGISTERED). The WTRU can currently camp on a 5G cell in idle mode. 5GS or EPS can (e.g., in the last registration procedure) indicate support for interoperability with N26 as part of the 5GS network feature support IE or the EPS network feature support IE, with the WK N26 bit set to "interoperability without N26 interface not supported".

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

[0221] At 730, the WTRU can trigger a registration request procedure toward the AMF. The WTRU can provide an unavailability period (IE) to notify the network of the duration of the WTRU's unavailability.

[0222] At 740, for example via the N26 interface, the AMF can send a notification to the MME. This notification may indicate to the MME that the WTRU (e.g., soon) will be unavailable for a certain period of time. The notification may include the duration of the unavailability period or a periodic registration time that the AMF may send to the WTRU in a registration response. For example, based on the duration of the unavailability period or the periodic registration time in the notification, the MME may be able to determine for how long the WTRU is expected to be unavailable.

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

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

[0225] For example, the MME may respond to the AMF with the following indication: if the MME disagrees with maintaining the WTRU's context while the WTRU is unavailable, the AMF may (e.g., indicate to the WTRU that the WTRU may be treated as having been deregistered from EPS, and / or the WTRU may (e.g., transition from EMM-REGISTERED to EMM-DEREGISTERD state). The response from the MME may (e.g., also) include (e.g., a new) periodic tracking area update duration (e.g., a timer) value for the AMF to send to the WTRU.

[0226] At 760, the MME may (e.g., via the N26 interface) respond to notifications from the AMF. The MME response may include information indicating, for example, whether an unavailability request from the WTRU has been accepted / rejected by the MME and / or the duration of a periodic registration timer that may be forwarded back to the WTRU, for example, via the AMF.

[0227] At 770, the AMF may offer registration acceptance to the WTRU. The registration response may include one or more of the following indications: the unavailable period is shared with the MME; when the unavailable event completes, the WTRU may perform a tracking area update with the MME, and / or the EMM status may be EMM-REGISTERED; the unavailable period is rejected by the MME, the WTRU may consider itself to have been deregistered from EPS, and / or the WTRU may change from EMM-REGISTERED to EMM-DEREGISTERED status; and / or the WTRU may assign a new value to the WTRU's EPS periodic tracking area update timer value.

[0228] In 780, the WTRU can (for example, successfully) perform events that render the WTRU unusable, such as a silent modem reset, security patch update, OS upgrade, modem SW update, and / or device restart upon modem setting changes via OMA-DM.

[0229] In 790, WTRUs that are excluded from unavailable time periods can perform registration procedures with AMF, for example, excluding unavailable time periods (IE).

[0230] In 795, the WTRU may (e.g., based on the results and responses received by the WTRU from the MME via the AMF) trigger an EMM tracking area update procedure (e.g., in the case where the EMM status is EMM-REGISTERED) or an EMM attachment procedure (e.g., in the case where the EMM status is EMM-DEREGISTERED) to indicate to the MME that the unavailable period has ended and the WTRU is accessible again.

[0231] For unavailability period characteristics, analytical capabilities (e.g., NWDAF) are supported. AMF's Namf_EventExposure service allows NF callers (e.g., NWDAF) to subscribe to events (e.g., WTRU unavailability events). When an event occurs, AMF can report WTRU unavailability information to the NF caller. WTRU unavailability information may include one or more of the following messages: (one or more) WTRU identifiers; (e.g., unavailability time information for each) WTRU identifier; and / or, for example, an indication of the expected action when each WTRU becomes available.

[0232] If the caller NF subscribes to or invokes the Namf_EventExposure subscription service operation and provides an event ID (e.g., when the caller NF subscribes to or invokes the Namf_EventExposure subscription service operation and provides an event ID), the AMF can provide WTRU unavailability information. The event ID is one or more event IDs such as those listed below (e.g., equal to one or more event IDs listed below): Registration-State-Report, Connectivity-State-Report, Reachability-Report, UEs-In-Area-Report, 5GS-User-State-Report, Frequent-Mobility-Registration-Report, UE-Access-Behavior-Trends, and / or UE-MM-Transaction-Report. Additionally and / or alternatively, an event ID (e.g., a new event ID) may be defined (e.g., WTRU unavailability information). If the caller NF subscribes to or invokes the Namf_EventExposure subscription service operation and provides an event ID (e.g., equal to "WTRU unavailable information"), then AMF can provide WTRU unavailable information.

[0233] The unavailability time information of the WTRU provided by the AMF to the caller NF can be one or more of the following: equal to the duration of the unavailability period requested by the WTRU; set to an absolute time value based on the duration of the unavailability period requested by the WTRU; set to a value indicating how much time the AMF expects or needs to elapse until the unavailability period expires; and / or equal to the periodic registration duration (e.g., timer) value provided by the AMF to the WTRU.

[0234] The indication of the expected action when the WTRU becomes available may indicate that the WTRU (e.g., expected) performs mobility registration when the unavailable period ends (e.g., when the unavailable period ends), or indicate that the WTRU (e.g., expected) performs initial registration when the unavailable period ends (e.g., when the unavailable period ends).

[0235] AMF may instruct that if the unavailable period ends (e.g., when the unavailable period ends), for example, if the WTRU provides the duration of the unavailable period in the mobility registration request, then the WTRU (e.g., is expected) to perform mobility registration.

[0236] AMF may instruct that if the unavailable period ends (e.g., when the unavailable period ends), for example, if the WTRU provides the duration of the unavailable period in the deregistration request, then the WTRU (e.g., is expected) to perform initial registration.

[0237] For example, providing consumer NFs (e.g., NWDAFs) with indications of expected actions when the WTRU becomes available (e.g., when the WTRU becomes available) can be useful (e.g., important) because the expected actions may affect the amount of network activity that might be required when the WTRU becomes available (e.g., when the WTRU becomes available). For example, an initial registration procedure may result in more signaling compared to a mobility registration procedure. For example, if consumer NFs (e.g., NWDAFs) are informed of what actions are expected, they may (e.g., be able to) generate more accurate statistics and / or predictions.

[0238] Figure 8 This illustrates an exemplary procedure by which the AMF provides unavailable information to the NWDAF. The NWDAF can use this unavailable information to generate more accurate statistics and / or forecasts. The NWDAF can then provide these statistics and / or forecasts to consumer NFs such as the PCF, AMF, NSSF, NEF, SMF, and / or AF.

[0239] Figure 8 The illustration shows an example of using unavailable information to produce improved data analysis results.

[0240] like Figure 8As shown in Figure 810, a consumer NF (e.g., PCF, AMF, NSSF, NEF, SMF, or AF) may invoke a service (e.g., the Nnwdaf_AnalytcisInfo service of NWDAF). The type of service invocation can be a request or subscription operation. The type of the requested analysis results can be one or more of the following types: network slice instance load level statistics and predictions; network slice load level statistics and predictions; network function load level statistics and predictions; network load level statistics and predictions; WTRU communication statistics and predictions; and / or sixth, WTRU anomalous behavior statistics and predictions.

[0241] At 820, the NWDAF may (e.g., begin) collect data that may be necessary to determine the information requested at 810. As part of the process of collecting the necessary data, the NWDAF may invoke the AMF's Namf_EventExposure service operation. The type of service invocation may be a request or subscription operation. In this operation, the event ID value that the NWDAF may provide to the AMF can be one or more of the following values: Registration-State-Report; Connectivity-State-Report; Reachability-Report; UEs-In-Area-Report; 5GS-User-State-Report; Frequent-Mobility-Registration-Report; UE-Access-Behavior-Trends; UE-MM-Transaction-Report; and / or "WTRU Unavailable Information".

[0242] At 830, the AMF can receive NAS registration requests or NAS deregistration requests, which may include the duration of an unavailable period. In the example, the operation at 830 may occur prior to the operation at 820.

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

[0244] At 850, NWDAF can derive the analysis results (e.g., statistics or predictions) requested at 810. These analysis results can be derived based on information about unavailability time and / or indications of the expected actions when the WTRU becomes available.

[0245] In 860, NWDAF can send analytics results to consumers via NF in notification or response service operations.

[0246] For trunk WTRUs, unavailable time period characteristics are supported. Trunk WTRUs can enter unavailable time periods.

[0247] In the exemplary procedure, the relay WTRU can detect that it needs to enter a time period when the WTRU may be unavailable.

[0248] In some examples, remote WTRUs and relay WTRUs can be connected (e.g., via PC5). Due to an unavailability event, one or the other WTRU, either the relay WTRU or the remote WTRU, may become unavailable.

[0249] Figure 9 The diagram illustrates an example of a relay WTRU entering an unavailable period.

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

[0251] In 910, an unavailability event can be triggered on a trunk WTRU, which can make the trunk WTRU unavailable for a certain period of time (e.g., a specific time period).

[0252] In 920, for example, a trunk WTRU can enter an unavailable period by sending a registration request message to the AMF. This message may include the unavailable period IE and / or a list of remote WTRUs that can be connected to the trunk WTRU, for example, via PC5. The list of remote WTRUs can notify the AMF of remote WTRUs whose connections via the trunk WTRU may no longer be available.

[0253] In 930, for connection loss events, a list of remote WTRU information can be submitted by the AMF to the AF (e.g., if the AF has registered the connection loss event for the corresponding remote WTRU).

[0254] At 940, by utilizing the registration acceptance of the list of remote WTRUs provided, the AMF can respond, for example, by confirming the status of the receipt of the list.

[0255] In 950, the relay WTRU can notify connected remote WTRUs of, for example, the unavailability of the relay WTRU and the duration of the unavailability period.

[0256] In 960, a remote WTRU may be aware of the unavailability of a relay WTRU. The remote WTRU may use the unavailability of the relay WTRU as a trigger for the following actions: buffering UL activities, triggering the selection of different relay WTRUs, establishing a direct connection with (e.g., 5G) networks, and / or (e.g., via a registration procedure) providing information about the unavailability period to the network.

[0257] Remote WTRUs can enter periods of unavailable operation.

[0258] Figure 10 The illustration shows an example of a remote WTRU entering an unavailable period.

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

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

[0261] In 1020, for example, a remote WTRU may trigger unavailability via a relay WTRU, such as by notifying the AMF / AF of an unavailability event via a relay WTRU.

[0262] At 1030, the remote WTRU can provide information about unavailability to the relay WTRU (e.g., via an unavailability notification message), such as the duration of the unavailability period and / or the remote WTRU ID.

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

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

[0265] Remote WTRUs (e.g., when they become available again) can be used Figure 10 The same or similar procedures are shown to indicate availability. For example, the remote WTRU can provide an unavailability notification message to the relay WTRU, indicating that unavailability is not applicable. The remote WTRU can provide its remote WTRU ID. In the example, the relay WTRU can broadcast availability information to other connected remote WTRUs.

[0266] When an unavailable period is requested, considerations for the desired WTRU availability can be provided. As described in this document, the WTRU can use the MICO mode. When using the MICO mode, the WTRU can apply strictly periodic registration timer characteristics.

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

[0268] AMF may send a registration acceptance message to WTRU. The registration acceptance message may include one or more of the following information elements: an indication of using MICO mode; an indication of whether the network supports strictly periodic registration timers; an active duration (e.g., timer) value (e.g., T3324); and / or a registration duration (e.g., timer) value (e.g., the requested T3512 value).

[0269] As described in this document, the AMF can be configured to use the MICO mode for the WTRU, thus ensuring that the WTRU is available at a predictable time. This configuration can be achieved by selecting values ​​for the T3324 and T3512 times via the AMF and / or by determining whether to enable strictly periodic registration durations (e.g., timers) via the AMF.

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

[0271] A registration acceptance message may indicate that a strictly periodic registration duration (e.g., a timer) feature is enabled and an unavailable period has not been accepted. The WTRU may (e.g., in response to a registration acceptance message) wait to request the unavailable period duration again until the registration duration (e.g., the timer) expires, send a registration request based on the expiration of the registration duration (e.g., the timer), and enter the CM-IDLE state when the active duration (e.g., the timer) is not running. By waiting until these conditions are met, it is ensured that the WTRU's expected available time has ended (e.g., just passed). For example, this approach may be useful in situations where the WTRU requests an unavailable period duration as the strictly periodic registration time approaches its expiration.

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

[0273] For example, if the WTRU receives a WTRU configuration update message or another registration acceptance message that disables the MICO mode or the strictly periodic registration duration (e.g., timer) feature, the WTRU may (e.g., alternatively) determine (e.g., again) request the duration of the unavailable time period.

[0274] The registration acceptance message may indicate that MICO mode is not enabled and the unavailable period has not been accepted. The WTRU may (e.g., in response to the registration acceptance message) use the unavailable period to track the duration (e.g., configure a timer) and may prevent re-requesting of the unavailable period (e.g., not re-request) until the waiting duration (e.g., the timer) expires and the WTRU has entered the CM-IDLE state.

[0275] The WTRU may (e.g., alternatively) (e.g., at any time) determine (e.g., again) the duration of the unavailable period sent in the deregistration request. An example of this procedure is illustrated in... Figure 11 middle.

[0276] Figure 11 This diagram illustrates an example of the logic for handling WTRU rejections when the time period is unavailable. Figure 11 This example illustrates how to consider the expected WTRU availability when an unavailable period is requested.

[0277] like Figure 11As shown, the WTRU may (e.g., when MICO mode and the strict periodic registration duration / timer feature are enabled) send a registration request that includes an unavailable time period duration. The WTRU may receive a registration acceptance message indicating that MICO mode is enabled, the strict periodic registration timer feature is enabled, and the unavailable time period duration is not permitted. If a periodic registration duration (e.g., a timer) expires, the WTRU has entered a CM-IDLE state, and the active duration (e.g., a timer) is not running, the WTRU may determine to send a second registration request that includes a second unavailable time period duration. The WTRU may send a second registration request that may include the second unavailable time period duration.

[0278] like Figure 11 As shown, the WTRU may (e.g., when MICO mode and the strictly periodic registration timer feature are not enabled) send a registration request that includes the duration of an unavailable period. The WTRU may receive a registration acceptance message indicating that MICO mode is enabled, the strictly periodic registration duration (e.g., timer) feature is not enabled, and the duration of an unavailable period is not permitted. For example, if the WTRU is in CM-IDLE state and the active duration (e.g., timer) is not running, the WTRU may determine to send a second registration request that includes a second duration of an unavailable period. The WTRU may send a second registration request, for example, that includes a second duration of an unavailable period.

[0279] like Figure 11 As shown, the WTRU may (e.g., when MICO mode is not enabled) send a registration request that may include the duration of an unavailable period. The WTRU may receive a registration acceptance message that prohibits (e.g., does not indicate) that MICO mode is enabled and the unavailable period is not permitted. Using the unavailable period, the WTRU may configure and begin tracking the duration (e.g., start a timer). If the duration (e.g., the timer) is not running and the WTRU has entered a CM-IDLE state, the WTRU may determine to send a second registration request that includes a second unavailable period. The WTRU may send a second registration request that includes the second unavailable period.

[0280] Although the above features and elements are described in a specific combination, each feature or element may be used alone without other features and elements of the preferred embodiment, or in various combinations with or without other features and elements.

[0281] While the implementations described herein may take into account 3GPP-specific protocols, it should be understood that the implementations described herein are not limited to this case and are applicable to other wireless systems. For example, while the solutions described herein take into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to this case and are also applicable to other wireless systems.

[0282] The above processes can be implemented in computer programs, software, and / or firmware included in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as CD-ROMs and / or DVDs). The processor associated with the software can be used to implement a radio frequency transceiver for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A multi-USIM (MUSIM) wireless transmitter / receiver unit (WTRU), comprising: The processor is configured as follows: Initiate registration with the first and second networks; It is determined that an event that will render the WTRU unusable will be triggered; Initiating a first mobility registration update procedure with the first network, wherein the first mobility registration update procedure includes sending a first registration request to the first network, wherein the first registration request indicates a first unavailability duration associated with an unavailability period; A first registration response is received from the first network, wherein the first registration response indicates a first periodic registration timer value; Initiating a second mobility registration update procedure with the second network, wherein the second mobility registration update procedure includes sending a second registration request to the second network, wherein the second registration request indicates a second unavailability duration; and A second registration response is received from the second network, wherein the second registration response indicates a second periodic registration timer value.

2. The MUSIM WTRU as claimed in claim 1, wherein the second unavailability duration is different from the first unavailability duration.

3. The MUSIM WTRU as claimed in claim 1, wherein the second unavailability duration is the same as the first unavailability duration.

4. The MUSIM WTRU as claimed in claim 1, wherein the first periodic registration timer value is based on the unavailable time period.

5. The MUSIM WTRU as claimed in claim 1, wherein the second periodic registration timer value is based on the second unavailable duration.

6. The MUSIM WTRU of claim 1, wherein the first registration response further indicates that the first network does not support unavailability, and wherein the processor is further configured to initiate a first deregistration procedure with the first network, wherein the first deregistration procedure includes sending a first deregistration request to the first network.

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

8. The MUSIM WTRU of claim 1, wherein the processor is further configured to execute an event that would render the WTRU unusable.

9. The MUSIM WTRU of claim 1, wherein the second periodic registration timer value is greater than or equal to the first unavailable duration.

10. The MUSIM WTRU of claim 1, wherein the first registration request further indicates a request characterized by the first network activation unavailable time period.

11. A method performed by a multiple USIM (MUSIM) wireless transmit / receive unit (WTRU), the method comprising: Initiate registration with the first and second networks; It is determined that an event that will render the WTRU unusable will be triggered; Initiating a first mobility registration update procedure with the first network, wherein the first mobility registration update procedure includes sending a first registration request to the first network, wherein the first registration request indicates a first unavailability duration associated with an unavailability period; A first registration response is received from the first network, wherein the first registration response indicates a first periodic registration timer value; Initiating a second mobility registration update procedure with the second network, wherein the second mobility registration update procedure includes sending a second registration request to the second network, wherein the second registration request indicates a second unavailability duration; and A second registration response is received from the second network, wherein the second registration response indicates a second periodic registration timer value.

12. The method of claim 11, wherein the second unavailability duration is different from the first unavailability duration.

13. The method of claim 11, wherein the second unavailability duration is the same as the first unavailability duration.

14. The method of claim 11, wherein the first periodic registration timer value is based on the unavailable time period.

15. The method of claim 11, wherein the second periodic registration timer value is based on the second unavailable duration.

16. The method of claim 11, wherein the first registration response further indicates that the first network does not support unavailability, wherein the method further includes initiating a first deregistration procedure with the first network, and wherein the first deregistration procedure includes sending a first deregistration request to the first network.

17. The method of claim 16, wherein the second registration response further indicates that the second network does not support unavailability, wherein the method further includes initiating a second deregistration procedure with the second network, and wherein the second deregistration procedure includes sending a second deregistration request to the second network.

18. The method of claim 11, wherein the method further comprises executing an event that would render the WTRU unusable.

19. The method of claim 11, wherein the second periodic registration timer value is greater than or equal to the first unavailable duration.

20. The method of claim 11, wherein the first registration request further indicates a request characteristic of the first network activation unavailable time period.

Images