Unavailable period support associated with congestion

Abstract

A device (e.g., a WTRU, a network device, such as a device including access and mobility functions (AMF)) may perform one or more of the following actions. The device may send a registration request via non-access stratum signaling. The registration request may include a first duration. The device may receive a registration accept message. The registration accept message may indicate whether the device is to inform the network entity of when the WTRU is available. The device may determine that the unavailable event has ended. The WTRU may determine whether to notify a network entity that the WTRU is available. The device may send a registration update request, for example, based on a determination that the unavailable event has ended and a determination that the WTRU is to notify a network entity of when the WTRU is available. The registration update request may indicate that the WTRU is available.

Description

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

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

[0003] This document describes systems, methods, and means related to support during unavailable periods when a Radio Transmit / Receive Unit (WTRU) is registered on a non-3GPP access (e.g., registered only on a non-3GPP access).

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

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

[0006] The device can receive (e.g., from a WTRU) a registration request message indicating a first duration (e.g., an unavailability period associated with the WTRU). The registration request can be associated with unavailability information. The device can determine whether the WTRU should send an update message (e.g., after the first duration). The device can send (e.g., to the WTRU) a registration acceptance message. The device can send the registration acceptance message, for example, based on the determination that the registration request is associated with unavailability information. The registration acceptance message can indicate acceptance associated with the registration request message. The registration acceptance message can indicate whether the WTRU should send an update message after the first duration (e.g., based on whether the WTRU is associated with discontinuous coverage). For example, if the WTRU is associated with discontinuous coverage, the registration acceptance message can indicate preventing the sending of 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 should 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 has expired). For example, if an update message has been received before the first duration has expired, the WTRU can be determined to be available. The device can send, for example, a rejection message 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 to 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 period of time. The determination that the device will be unavailable during this period may be based on the determination that an unavailability event has been triggered. The first unavailability duration may be determined based on the determination that the device will be unavailable during this period. 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. The device may determine a second unavailability duration, for example, based on the first 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 to 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 a second registration duration. The second registration duration can be greater than or equal to the second unavailability duration. The second unavailability duration can be greater than or equal to the first registration duration.

[0008] A device can perform actions associated with dual registration. The device can receive a registration request (e.g., from a WTRU). The registration request can indicate unavailability period information. The registration request may include an unavailability period information element, which can indicate unavailability period information. The unavailability 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 period of time. The device can receive a notification response (e.g., from the entity). The notification response can indicate that the entity has accepted the indication of the WTRU's unavailability. The notification response can indicate the tracking area update duration. The notification response can indicate that the entity has accepted the indication of the WTRU's unavailability 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 for the entity, for example, based on the unavailability event being completed.

[0009] This 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, for example, indicating the first duration. The registration request can be sent via a non-3GPP access network. The device can send a registration response, for example, indicating that the first duration is accepted. The indication of accepting 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. A registration response can be sent based on receiving the registration request and the registration request indicating the first duration via a non-3GPP access network. The device can determine that the WTRU is unreachable, for example, based on the determination that a second duration has elapsed. 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 is sent to the network exposure function. The device can receive NAS messages from the WTRU. The device may, for example, perform one or more of the following actions based on a received NAS message: stop tracking associated with the second duration; determine that the WTRU is reachable; determine that the WTRU is in a CONNECTED state; etc. The device may deregister the WTRU based on a determination that the second duration has expired. Attached Figure Description

[0010] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented.

[0011] Figure 1B The illustration shows a method according to one embodiment. Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

[0012] Figure 1C The illustration shows a method according to one embodiment. Figure 1A The diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used in the communication system.

[0013] Figure 1D The illustration shows a method according to one embodiment. Figure 1A The illustrated system diagram shows yet another example RAN and yet another example CN used in the communication system.

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

[0015] Figure 3 The illustration shows an example of an unavailable period feature when a WTRU registered via non-3GPP access uses this feature.

[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 multiple networks does not support the unavailability feature of MUSIM WTRU.

[0019] Figure 7 An example of a dual registration scenario is illustrated, in which the WTRU has both 5GMM and EMM contexts.

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

[0021] Figure 9 The illustration shows 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 The diagram illustrates an example of the logic for WTRU processing when an unavailable time period is rejected. Detailed Implementation

[0024] Figure 1A This is a schematic diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messages, and broadcasts to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing 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 UWDTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank 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 should 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 may be any type of device configured to operate and / or communicate in a wireless environment. For 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 environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of 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 base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), node B, eNode B, home node B, home eNode B, gNB, NR node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it should 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. The 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 one embodiment, 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] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. 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.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0029] More specifically, as described above, the communication system 100 can be a multi-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 establish air interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

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

[0031] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using a new radio (NR).

[0032] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can 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 can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0034] For example, Figure 1ABase station 114b can be a wireless router, home node B, home eNodeB, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies 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 utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b may not need to access the 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 of WTRUs 102a, 102b, 102c, and 102d. Data can have different 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, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although in Figure 1A Although not shown, it should be understood that RAN104 / 113 and / or CN 106 / 115 can 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 utilize NR radio technology, CN 106 / 115 can 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 the communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example... Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a, which may employ cellular-based radio technology, and to communicate with base station 114b, which may employ IEEE 802 radio technology.

[0038] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1B As shown, among other things, WTRU 102 may include, in particular, 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 should 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 encoding, 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, which may be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0040] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) over air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 can be, for example, a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 can 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 on air interface 116.

[0042] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, for example, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via multiple 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 therefrom. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 can access and store information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a user identification module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 can access and store information from memory that is not physically located on WTRU 102 (e.g., a server or home computer (not shown)).

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

[0045] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information on the 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 should be understood that the 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, 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, attitude sensors, biosensors, and / or humidity sensors.

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

[0048] Figure 1C This diagram illustrates a system diagram of 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; however, it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c on air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit 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, user scheduling in UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other on the X2 interface.

[0051] Figure 1C The 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. While each of the foregoing elements is described as part of CN 106, it should 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 connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, 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 connect 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 handover, 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 connect to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks such as Internet 110, so as 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 WTRU 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108, facilitating communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 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] Despite WTRU in 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, another network 112 may be a WLAN.

[0058] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can access or interface with a distributed system (DS) or another type of wired / wireless network that transmits traffic to and / or out of the BSS. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined for an external BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be transmitted via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be transmitted between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to here as an "ad-hoc" communication mode.

[0059] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a wide bandwidth of 20 MHz) 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 a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0060] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, 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 consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These 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 operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0062] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier in 802.11af and 802.11ah 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 whitespace (TVWS) spectrum, while 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 can support metering-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 for (e.g., only) 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 can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA among all STAs operating in the BSS that supports the minimum bandwidth operating mode. 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 can 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 Sense and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy, even if most of the available band remains idle and can be available.

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

[0065] Figure 1D This diagram illustrates a system diagram of RAN 113 and CN 115 according to one 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; however, it should 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 on air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In one embodiment, 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] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including a variable number of OFDM symbols and / or a continuously variable absolute time).

[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 accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of 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 / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with 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, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0069] Each of 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 user plane data to User Plane Functions (UPF) 184a and 184b, and routing 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 on 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 should 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 connect to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types 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 Time (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, and / or so on. AMF 162 can provide control plane functions for handover 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] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure the routing of services through UPFs 184a and 184b. SMFs 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, Ethernet-based, etc.

[0073] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. This N3 interface provides WTRU 102a, 102b, and 102c with access to packet-switched networks (such as 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, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and PSTN 108. Furthermore, CN 115 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. In one embodiment, WTRUs 102a, 102b, and 102c may be connected to local data networks (DNs) 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0075] Given Figure 1A-1D as well as Figure 1A-1D The corresponding descriptions herein indicate that one or more of the following functions can be performed by one or more emulation devices (not shown): 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. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

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

[0077] One or more simulation devices may perform one or more functions, including all functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices may be used to test test scenarios in laboratory and / or non-deployment (e.g., testing) wired and / or wireless communication networks to implement the testing of one or more components. One or more simulation devices may be test devices. Simulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[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 determination that a time has occurred or that a period of time has expired. References to timers can refer to time, period of time, tracking time, tracking that period of time, etc. References to legacy technologies or legacy handover can refer to legacy technologies (such as LTE compared to NR) or legacy versions of technologies (e.g., an earlier version / release of the technology compared to a later version / release of the technology (e.g., a later NR release)). References to specific timers in this document may be provided as examples of timers.

[0079] This document describes systems, methods, and means related to support during unavailable periods when a Radio Transmit / Receive Unit (WTRU) is registered on a non-3GPP access (e.g., registered only on a non-3GPP access).

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

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

[0082] The device can receive (e.g., from a WTRU) a registration request message indicating a first duration (e.g., an unavailability period associated with the WTRU). The registration request can be associated with unavailability information. The device can determine whether the WTRU should send an update message (e.g., after the first duration). The device can send (e.g., to the WTRU) a registration acceptance message. The device can send the registration acceptance message, for example, based on the determination that the registration request is associated with unavailability information. The registration acceptance message can indicate acceptance associated with the registration request message. The registration acceptance message can indicate whether the WTRU should send an update message after the first duration (e.g., based on whether the WTRU is associated with discontinuous coverage). For example, if the WTRU is associated with discontinuous coverage, the registration acceptance message can indicate preventing the sending of 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 should 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 has expired). For example, if an update message has been received before the first duration has expired, the WTRU can be determined to be available. The device can send, for example, a rejection message 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 to 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 period of time. The determination that the device will be unavailable during this period may be based on the determination that an unavailability event has been triggered. The first unavailability duration may be determined based on the determination that the device will be unavailable during this period. 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. The device may determine a second unavailability duration, for example, based on the first 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 to 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 a second registration duration. The second registration duration can be greater than or equal to the second unavailability duration. The second unavailability duration can be greater than or equal to the first registration duration.

[0084] A device can perform actions associated with dual registration. The device can receive a registration request (e.g., from a WTRU). The registration request can indicate unavailability period information. The registration request may include an unavailability period information element, which can indicate unavailability period information. The unavailability 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 period of time. The device can receive a notification response (e.g., from the entity). The notification response can indicate that the entity has accepted the indication of the WTRU's unavailability. The notification response can indicate the tracking area update duration. The notification response can indicate that the entity has accepted the indication of the WTRU's unavailability 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 for the entity, for example, based on the unavailability event being completed.

[0085] This 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, for example, indicating the first duration. The registration request can be sent via a non-3GPP access network. The device can send a registration response, for example, indicating that the first duration is accepted. The indication of accepting 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. A registration response can be sent based on receiving the registration request and the registration request indicating the first duration via a non-3GPP access network. The device can determine that the WTRU is unreachable, for example, based on the determination that a second duration has elapsed. 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 is sent to the network exposure function. The device can receive NAS messages from the WTRU. The device may, for example, perform one or more of the following actions based on a received NAS message: stop tracking associated with the second duration; determine that the WTRU is reachable; determine that the WTRU is in a CONNECTED state; etc. The device may deregister the WTRU based on a determination that the second duration has expired.

[0086] This document describes systems, methods, and means related to support during unavailable periods when the WTRU is registered on a non-3GPP access (e.g., only registered on a non-3GPP access).

[0087] A device (e.g., a network device, such as a device including Access and Mobility Functions (AMF)) may (e.g., be configured to) perform one or more of the following actions: The device may receive a registration request. The registration request may include unavailability information (e.g., an unavailability period duration information element (IE)), which may be transmitted via a non-3GPP access network. The device 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 tracking a duration (e.g., start a wait timer). The device may assign an initial value to the duration (e.g., the wait timer), which may be equal to the unavailability period duration provided in the registration request. The device 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, which may include an acceptance of the unavailability period duration request and an indication from the network. The device may indicate acceptance of the unavailability period duration, for example, by sending the accepted unavailability period duration to a Radio Transmit / Receive Unit (WTRU). The device can allocate an accepted unavailable period duration equal to or greater than the requested unavailable period duration. The device can determine, for example, that the WTRU is unreachable and in an idle state (e.g., 5GMM-IDLE state) based on a registration request received via a non-3GPP access network and / or based on a request including an unavailable period duration information element. The device can send an indication that the WTRU is unreachable to the Session Management Function (SMF), for example, 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 an Application Function (AF) subscribes to a connection loss event for the WTRU, the device can trigger a connection loss event report toward the Network Exposure Function (NEF) (e.g., which may include an unavailable period), and / or can report the unavailable period to the subscribed AF. The device can receive an Initial Non-Access Stratum (NAS) message from the WTRU. The device can (e.g., based on receiving the NAS initial NAS message) determine the duration of the stop tracking (e.g., a stop wait timer) to consider the WTRU to be reachable and in a connected state (e.g., 5GMM-CONNECTED state). The device can (e.g., alternatively) determine (e.g., implicitly) deregister the WTRU based on the expiration of the duration (e.g., the wait timer expires).

[0088] Example devices may include processors configured to perform one or more actions. For example, a device (e.g., a network device, such as one including an AMF) may receive a registration request from a Wireless Transmit / Receive Unit (WTRU). The registration request may include unavailability information (e.g., an unavailability period duration information element). The registration request may be sent over a non-3GPP access network. The device may begin tracking the duration (e.g., start a timer). The device may send a registration response. The registration response may include an indication that the unavailability period duration request has been accepted. The device may determine that the WTRU is unreachable. The device may send a connection loss report.

[0089] The value of the duration (e.g., a timer) can be associated with or equal to the unavailable period duration associated with the registration request. A registration response can be sent based on the receipt of the registration request via a non-3GPP access network and the registration request including the unavailable period duration information element. An indication of accepting the unavailable period duration request can indicate the accepted unavailable period duration. The accepted unavailable period duration can be equal to or greater than the requested unavailable period duration. A connection loss report can indicate an unavailable period. A connection loss report indicating an unavailable period can be sent to the network exposure function. The device (e.g., a processor) can be further configured to receive NAS messages from the WTRU and (e.g., based on receiving the NAS message) perform one or more of the following: 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., the processor) can be further configured to implicitly deregister the WTRU based on timer expiration.

[0090] This document describes systems, methods, and means related to mechanisms for providing unavailability periods to a network. Some events, such as operating system (OS) upgrades, silent resets at a modem, or modem software updates (e.g., also known as binary updates), can be performed by more than two parties involved (e.g., three (3) parties) (e.g., devices, operators, and application functions).

[0091] For example, when performing event operations (e.g., on the order of minutes), the WTRU performing the multi-party event may become unavailable (e.g., unable to interact with the 5G system). For example, if an application server relies on the availability of the WTRU during a period of unavailability (e.g., a period during which the WTRU is unavailable), the unavailability of the WTRU may affect the (e.g., critical) operation of the application server without prior knowledge from the core network and / or application functions.

[0092] This document describes systems, methods, and means for handling unavailability periods for one or more scenarios, such as when backoff duration activity (e.g., a timer is running), if (e.g., when) a WTRU (e.g., only) registers to a network (e.g., 5GS) via non-3GPP access, if (e.g., when) a Multi Universal Subscriber Identity Module (MUSIM) device registers to multiple networks that support and do not support unavailability features, if (e.g., when) a WTRU registers to multiple networks (both Evolved Packet System (EPS) and 5G System (5GS)) to support analysis of unavailability features (e.g., Network Data Analysis Function (NWDAF)), if (e.g., when) a remote WTRU and / or a relay WTRU enters an unavailability period, if (e.g., when) Mobile Initiated Connection (MICO) mode and / or strictly periodic registration timer features are enabled, and so on.

[0093] An unavailability period can be the duration during which the WTRU is unavailable (e.g., unable to interact with the network, such as a 5G system). For example, an unavailability period can be on the order of minutes. The unavailability period of the WTRU can be (e.g., expected) long enough for the WTRU to perform (e.g., required) events, such as one or more of the following: (a) a silent reset at the modem; (b) a security patch update; (c) an OS upgrade; (d) a modem software (SW) update; and / or (e) a device reboot when modem settings change (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 at the modem, or modem software updates (e.g., also known as binary updates)) can be performed by multiple parties involved (e.g., three (3) parties) (e.g., device, operator, and application functions).

[0095] The WTRU can download binary files. The time for the WTRU to perform upgrades is left to the WTRU implementation. Some WTRU implementations can use (e.g., look for) user input. For example, if the WTRU might not execute an event (e.g., due to insufficient storage capacity or battery power), the WTRU can delay the execution of the event. For example, if (e.g., when) such an operation is performed (e.g., on the order of minutes), the WTRU might become unavailable (e.g., might not interact with the 5G system). The WTRU might become unavailable without prior knowledge from 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 during which the WTRU is unavailable), the unavailability of the WTRU could impact the critical operations of the application server.

[0096] The network (e.g., a 5G system) can allow the WTRU to provide an unavailability period (e.g., unavailability duration) to the network, for example, in a registration or deregistration request. For instance, if an event is triggered in the WTRU that will render it unavailable for a period of time, the WTRU can 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 can trigger a mobility registration update procedure or deregistration procedure and provide the network with the duration of the unavailability period. For instance, if (e.g., when) a periodic registration update duration is determined (e.g., a periodic registration update timer value), the network (e.g., the Access and Mobility Function (AMF)) can consider the duration of the unavailability period. The AMF can provide a periodic registration update time that is longer than or equal to the duration of the unavailability period, 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 has been completed in the WTRU, or the event has been delayed to a future time or canceled in the WTRU), the WTRU may trigger a registration procedure to restore normal service. The WTRU may prevent the unavailability period from being included (e.g., excluded) in the registration request message. Depending on the WTRU state, the registration procedure can be an initial registration procedure or a mobility registration update procedure.

[0097] The AMF can provide the WTRU with a strictly periodic registration duration indication (e.g., a strictly periodic registration timer indication), for example, along with a periodic registration timer value. For example, if (e.g., when) the WTRU is using MICO mode, a periodic registration timer feature can be applied. The AMF can provide indications to the WTRU based on expected WTRU behavior. For example, the AMF may (e.g., want) configure the WTRU to be available for downlink data hourly (e.g., on the hour) to receive downlink data. For example, if (e.g., when) the WTRU is using MICO mode, a periodic registration duration (e.g., a timer) feature can be useful. The periodic registration duration (e.g., a timer) feature can be used to ensure the WTRU is in CM-CONNECTED mode (e.g., at predictable times). For example, if the WTRU runs a strictly periodic registration timer for 4 hours and (e.g., always) applies a 10-minute activity timer, it can be known that the WTRU is available for 10 minutes every 4 hours. By enabling the strictly periodic registration duration (e.g., timer) feature, AMF can configure available events (e.g., 10-minute available 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 the NWDAF can be used by the NWDAF to determine analytical information. This analytical information can include statistics and forecasts.

[0099] An AMF can be an example of a Network Function (NF) from which the NWDAF can collect data. The NWDAF can obtain data from the AMF using the AMF's Namf_EventExposure service. The NWDAF can provide the Nnwdaf_AnalyticsInfo service, which network functions can use to obtain statistics and forecasts from the 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 the NF that calls or consumes 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] For a WTRU (e.g., a specific WTRU), unavailability periods can be identified in 5GS. WTRU and / or network actions can be based on the identified unavailability periods. WTRUs and networks (e.g., 5GC) can coordinate architecture-level workflows regarding unavailability periods and / or unavailability characteristics.

[0103] WTRU can indicate support for unavailable periods, for example, in a registration request message (e.g., during the registration process). AMF can indicate support for unavailable periods, for example, in a registration acceptance message.

[0104] For example, if the WTRU and network support an unavailability period and an event is triggered in the WTRU that will render the WTRU unavailable for a period of time (e.g., for OS upgrades or device reboots), the WTRU can store its MM context in USIM or non-volatile memory so that the MM context can be reused (e.g., after the WTRU's unavailability period). For example, if (e.g., when) the WTRU is ready to execute an event, the WTRU can trigger a mobility registration or deregistration procedure that includes the unavailability period. The AMF can provide a periodic registration update duration (e.g., a timer) based on the unavailability period indicated by the WTRU; for example, the AMF can provide a periodic registration update time longer than the unavailability period. For example, if the WTRU is not deregistered, the AMF can store information that the WTRU is unavailable in the WTRU context. The AMF can consider the WTRU unreachable until the unavailability period has passed or the WTRU enters a CM-CONNECTED state. When the WTRU is unreachable, high latency communication solutions such as extended data buffering, downlink data buffer status reporting, etc. (e.g., all), can be applied (e.g., if supported). If an AF subscribes to a connection loss event for the WTRU, the AMF can trigger a connection loss event report, which may include an unavailability period directed toward the NEF. The unavailability period can be reported to the respective subscribed AF.

[0105] For example, if (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., selectively) store WTRU contexts (e.g., MM and SM contexts). How the WTRU stores contexts can depend on the WTRU implementation. The WTRU may use USIM functionality to store some or all WTRU contexts in the USIM.

[0106] For example, once the WTRU completes an event that renders it unavailable, or if the event in the WTRU is delayed to a future time or canceled (e.g., due to insufficient storage capacity, low battery power, or completion of an event that renders the WTRU unavailable), the WTRU can trigger a registration procedure to restore normal service. The WTRU can prevent the unavailability period from being included (e.g., excluded) in the registration request message. The registration procedure can be an initial registration procedure or a mobility registration update procedure, depending, for example, on the state of the WTRU after the event.

[0107] While the backoff duration is active (e.g., a timer is running), unavailability period support can be provided. When the non-access stratum (NAS) backoff duration (e.g., a timer or other backoff timer) is running in the WTRU (e.g., T3346 / T3347 / T3396, other backoff timers), the mobility management entity at the NAS layer can prevent (e.g., not trigger or not be allowed to trigger) the mobility registration process 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 prevent (e.g., not send) registration requests to the network with unavailability period durations.

[0108] For example, if the WTRU wants to prevent sending (e.g., not sending) the duration of unavailability to the network, and performs an action that could render the WTRU unavailable while the backoff duration (e.g., a timer) is running, the network can attempt to contact (e.g., fail to contact) the WTRU for termination of service while the backoff duration (e.g., a timer) is running. The attempt to contact the WTRU for termination of service may fail.

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

[0110] When a WTRU is on a non-3GPP access and not registered on any other access (e.g., registered only on a non-3GPP access), unavailability period support can be provided. For example, if the WTRU's NAS layer receives notification from a lower layer that a non-3GPP access is available, the WTRU can send an initial NAS message to establish an N1 NAS signaling connection to the AMF. The NAS can (e.g., then) consider the WTRU to be in 5GMM-CONNECTED mode via the 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. A WTRU in 5GMM-CONNECTED mode via a non-3GPP access can (e.g., typically) remain in 5GMM-CONNECTED mode, for example, unless the WTRU is disconnected from the non-3GPP network.

[0111] For example, if (e.g., when) the WTRU is registered via non-3GPP access, the periodic registration update procedure can be prevented (e.g., it can be omitted).

[0112] A WTRU registered via non-3GPP access can indicate unavailable periods to the network, for example, 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] Unavailability period support can be provided for MUSIM devices. One or more examples described herein can indicate how to handle unavailability features for MUSIM devices registered to two (2) or more different networks.

[0114] In some examples, multiple (e.g., two) networks can support the unavailability feature. In some examples, both networks can be provided with (e.g., the same) unavailability duration. In some examples, the unavailability duration can be determined based on the output 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 (e.g., only) execute sequentially. A slight delay may exist when communicating with a network during periods of unavailability (e.g., this may be taken into account). Upon exiting unavailability, it may be considered to report unavailability to the network sequentially, for example, to ensure that the network is notified within a specified time frame.

[0116] 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 of the networks do not support the unavailability feature) can indicate unavailability periods to one or more networks, for example, enabling one or more networks and the MUSIM WTRU to maintain the MUSIM WTRU's registration status and / or enabling the network to understand that the WTRU is unreachable for mobile termination communication.

[0117] Unavailability period support can be provided for devices registered to multiple networks (e.g., both EPC and 5GC). 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 be in both S1 and N1 modes (e.g., simultaneously).

[0118] One of several networks (e.g., EPS) may not support periods of unavailability, such as negotiation via the S1 NAS interface 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) the context to prevent the deletion (e.g., not to delete) of the WTRU and / or knows (e.g., determines) to prevent attempts to terminate communication for mobility (e.g., not to attempt to contact) the WTRU.

[0119] It can support the analysis of characteristics of unavailability periods (e.g., NWDAF). 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 period of time.

[0120] Several scenarios may need to be considered. First, the unavailability period provided by the WTRU to the AMF may not be a common event. For example, if (e.g., when) the WTRU is installing a software upgrade, an unavailability period may occur (e.g., only). Second, multiple (e.g., many) WTRUs in an area may install software upgrades at the same or similar times. Multiple WTRUs may become unavailable and become available again almost simultaneously. Third, the unavailability period provided by the WTRU can be a strong indication of when the WTRU can attempt to perform the registration procedure 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 requested by the WTRU can have a strong impact on future events that may occur in the network. The duration of unavailability requested by the WTRU can affect the accuracy of statistics and forecasts provided by the NWDAF to other network functions. The NWDAF can obtain the duration of unavailability and / or can take the duration of unavailability into account when generating statistics and forecasts (e.g., using one or more features described herein).

[0122] Unavailability period characteristics can be provided for trunk WTRUs. One or more examples described in this document can indicate how to handle scenarios for trunk WTRUs, how to handle unavailability events for 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., by the network) to use a (e.g., strictly periodic) registration duration (e.g., timer) feature. As described above, a 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 may be useful for devices using MICO mode and / or entering long sleep durations, for example, to save power. The times when these devices (e.g., WTRUs) are available for downlink data may be very rare (e.g., separated by 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, the WTRU may miss downlink data that could have been sent from a server where the WTRU was expected to be available at the expected time.

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

[0125] Whenever such an operation is performed, the WTRU may become unavailable (e.g., may not interact with the 5G system), for example, on the order of minutes. The WTRU may become unavailable without prior knowledge from the core network and / or application functions. For example, if an application server relies on the availability of the WTRU during a period of unavailability (e.g., a period during which 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 means related to handling unavailability period characteristics for multiple scenarios, such as if (e.g., when) a backoff duration (e.g., a timer) may be in operation, if (e.g., when) a WTRU can (e.g., only) register to a network via non-3GPP access (e.g., 5GS), if (e.g., when) a MUSIM device can register to multiple networks that support and do not support unavailability characteristics, if (e.g., when) a WTRU registers to multiple networks (e.g., both EPS and 5GS) to support analysis of unavailability characteristics (e.g., NWDAF), if (e.g., when) a remote WTRU and / or a relay WTRU enters an unavailability period, if (e.g., when) MICO mode and / or strictly periodic registration duration (e.g., timer) characteristics are enabled, and so on.

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

[0128] AMF can (e.g., if / when general 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 can use the value received in the MM (e.g., 5GMM) rejection message to begin tracking the duration (e.g., the timer, such as T3346). For example, if (e.g., when) the backoff duration (e.g., the timer) is running, WTRU can prevent (e.g., be prohibited from) sending one or more (e.g., certain) NAS messages (e.g., mobility registration updates). For example, if (e.g., when) the backoff duration (e.g., the timer) is running, WTRU can respond to network-initiated signaling (e.g., paging triggered by downlink data).

[0129] A WTRU can notify the network of the start of an unavailability period, for example, based on the detection of an event within the WTRU that may (e.g., will) render the WTRU unavailable for a period of time. For instance, if the WTRU is able to maintain both the MM (e.g., 5GMM) and SM (e.g., 5GSM) contexts, the WTRU can notify the network of the start of the unavailability period via a REGISTRATION REQUEST message (e.g., including the unavailability period IE). However, the WTRU can prevent notification of its unavailability to the network (e.g., AMF) in one or more scenarios (e.g., not notifying, not being able to notify). For example, if (e.g., when) NAS-level congestion control is active, the WTRU can prevent (e.g., not allowing triggering) UL NAS signaling to send mobility registration updates.

[0130] A WTRU can prevent (e.g., not perform) actions that would render it unusable without notifying the network. For example, without notifying the network, the network could initiate signaling to the WTRU and find that it does not respond. The WTRU might not respond, for example, because it might be performing an action that renders it unusable (e.g., a software upgrade).

[0131] For example, if (e.g., even when) a backoff duration (e.g., a timer) is in progress, the WTRU can (e.g., be permitted) send a mobility registration update to the network. The WTRU can generate NAS signaling to notify the network of the unavailability period, and then notify the network again that the WTRU is available again. Signaling can be generated while the backoff duration (e.g., a timer) is in progress. In some examples, multiple WTRUs in the same area can perform the same software upgrade. Unavailability and availability signaling from multiple WTRUs can trigger a large amount of NAS signaling to be processed by the network, for example, even during congestion situations.

[0132] When NAS-level congestion control is active (e.g., while a duration or timer is running, such as when T3346 is running), 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., limited to ensuring the REGISTRATION REQUEST message does not include) subsequent requests, uplink data state IEs, and / or permitted PDU session state IEs. The WTRU may (e.g., also) be configured (e.g., limited 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 a periodic unavailability request received while the backoff timer is running) may respond to the WTRU with one or more of the following information, such as (e.g., indicated in the registration acceptance message): (i) an indication that registration and the unavailability period is accepted; (ii) an indication that the previously provided backoff duration (e.g., a timer, such as T3346) may continue to run and not be reset, for example, indicating to the WTRU that the WTRU may still consider NAS-level congestion control to be active; (iii) a new backoff duration (e.g., a timer) value (e.g., T3346) to indicate to the WTRU that the WTRU may still consider NAS-level congestion control to be active; (iv) an indication that the WTRU may notify the AMF when the WTRU becomes available again, for example, even if the backoff duration (e.g., a timer) is running (e.g., T3346); and / or (v) an indication that the WTRU may not notify the AMF when the WTRU becomes available again if the backoff duration (e.g., a timer) is running (e.g., T3346).

[0134] The aforementioned example instruction in the registration acceptance message can give the AMF control over whether the WTRU generates additional signaling when the WTRU becomes available again. Figure 2 An example procedure is shown where the WTRU signals out unavailable periods and the AMF (e.g., still) limits the amount of NAS signaling.

[0135] Figure 2 The illustration shows an example of an event where congestion control at the NAS level might be active but unavailable. For example... Figure 2 As shown, at 210, NAS-level congestion control can be active for the WTRU, for example, because the WTRU receives a rejection response from the AMF. The rejection response can include a duration (e.g., a timer, such as the T3346 timer). NAS-level congestion control can be active in the WTRU. Durations (e.g., other durations) may be running (e.g., T3346 and / or (one or more) other backoff timers may be running). The WTRU can prevent the triggering (e.g., not trigger, or may not be allowed to trigger) of NAS-level signaling, for example, except in cases suitable for high-priority access, emergency services, and / or when the WTRU is responding to a paging from the network side.

[0136] exist Figure 2 At point 220, the WTRU can detect the need to perform an event within the WTRU that might render it unavailable for a period of time. The WTRU can also (for example, also) detect the amount of time the WTRU is expected to be available. For example, the time value can be provided by an application or the operating system.

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

[0138] exist Figure 2At point 240, the AMF may consider the existence of an unavailable period IE, prevent (e.g., not reject) registration requests, and / or respond with 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 to be active, and / or to provide an indication to the AMF whether the WTRU can notify the AMF when the WTRU becomes available again, for example, even if the backoff duration (e.g., a timer) is running.

[0139] exist Figure 2 At point 250, the WTRU can (for example, successfully) execute events that render the WTRU unusable, such as a silent reset at the modem, a security patch update, an OS upgrade, a modem SW update, and / or a device reboot via OMA-DM when modem settings change.

[0140] exist Figure 2 At point 260, for example, if the backoff duration (e.g., a timer) is no longer running, or if the AMF instructs at point 240 that the WTRU may notify the AMF when the WTRU becomes available again (e.g., even if the backoff timer is running), the WTRU may notify the AMF of the execution (e.g., successful) of the unavailable event. The WTRU may notify the AMF of the execution (e.g., successful) of the unavailable event, for example, by sending a REGISTRATION REQUEST message, such as preventing the inclusion (e.g., exclusion) of the unavailable period IE. For example, if the backoff duration (e.g., a timer) is running, or if the AMF instructs at point 240 that the WTRU may prevent notification (e.g., not notify) the AMF when the WTRU becomes available again if the backoff duration (e.g., a timer) is running, the WTRU may wait until the backoff duration (e.g., a timer) expires and then notify the AMF of the execution (e.g., successful) of the unavailable event. The WTRU may wait until the backoff duration (e.g., a timer) expires, and then notify the AMF, for example, by sending a REGISTRATION REQUEST message to prevent the WTRU from executing (e.g., successfully) the unavailable event, including (e.g., excluding) the unavailable period IE.

[0141] refer to Figure 2This provides yet another example procedure for the scenario where the backoff duration (e.g., a timer) is running. WTRU can execute one or more of the following.

[0142] like Figure 2 As shown, at 210, the WTRU can receive a NAS rejection message, which indicates that the WTRU is restricted due to congestion 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 to be in effect and / or how long the restriction to be in effect. For example, based on the reception duration (e.g., the timer value), the WTRU can begin tracking the backoff duration (e.g., a backoff timer).

[0143] like Figure 2 As shown, at 220, the WTRU can detect events that need to be performed within the WTRU, which could render the WTRU unavailable for a period of time (e.g., a certain period of time). The WTRU can also detect the amount of time it is expected to become available.

[0144] like Figure 2 As shown, at 230, the WTRU can send a registration request to the network. The registration request may include the duration of WTRU unavailability. For example, the duration of WTRU unavailability can be set to a value greater than or equal to the backoff duration (e.g., timer value) based on the backoff duration (e.g., timer) running and / or based on the backoff duration (e.g., timer) value being greater than the amount of time the WTRU is expected to become 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 backoff duration (e.g., a timer, such as T3346) can continue to run and not be reset, which can cause or trigger the WTRU to continue applying NAS-level congestion control. The registration acceptance message may include a different (e.g., 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, which can cause or trigger the WTRU to continue applying NAS-level congestion control and / or assign a different (e.g., a new) value to the backoff duration (e.g., a timer). The registration acceptance message may include an indication that the WTRU can notify the AMF when the WTRU becomes available again, for example, even if the backoff duration (e.g., a timer) is running (e.g., T3346), which can trigger the WTRU to send a registration update request to the network at the end of the unavailability event. The registration update request may prevent the inclusion (e.g., exclusion) of the unavailability period duration. The registration acceptance message may include an indication that if a backoff duration (e.g., a timer) is in progress (e.g., T3346), the WTRU may prevent notification (e.g., not notify) of the AMF when the WTRU becomes available again. This may cause or trigger the WTRU not to send a registration update request to the network while the unavailability event has ended and the backoff duration (e.g., a timer) is still running. When the backoff 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 include (e.g., exclude) the unavailability period duration.

[0146] When the WTRU registers (e.g., only) on a non-3GPP access, 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 a non-3GPP access. The registration request may include unavailability information (e.g., an unavailability period duration information element (IE)).

[0147] AMF can (e.g., be triggered to) perform one or more actions based on receiving unavailability information (e.g., unavailability period duration information element) from a WTRU registered via non-3GPP access (e.g., when receiving unavailability information (e.g., unavailability period duration information element) from a WTRU registered via non-3GPP access). For example, AMF can be triggered to perform one or more of the following actions.

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

[0149] AMF can assume that WTRU is 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 the duration (e.g., wait timers), which can be equal to the unavailable 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, registration requests, service requests, and / or control plane service requests.

[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 may assume that the WTRU is to be deregistered (e.g., in a 5GMM-DEREGISTERED state).

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

[0154] like Figure 3 As shown, at 310, the WTRU can (e.g., only) register with the 5GCN via a non-3GPP access. The non-3GPP access can be trusted or untrusted.

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

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

[0157] At 340, AMF can begin tracking durations (e.g., wait timers). AMF can initially set the 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 accept message to the WTRU. The registration accept message can indicate the duration of the unavailability period for accepting the request and / or can provide the WTRU with a value representing the duration of the unavailability period that the WTRU can use. 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 can be received 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 toward the NEF. The connection loss event report can include the unavailability period. The unavailability period can (e.g., also) be reported to the respective subscribed AFs.

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

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

[0161] At 380, the AMF can, for example, stop tracking the duration (e.g., stop the wait timer) based on the reception of the initial NAS message (e.g., upon receiving the initial NAS message). The AMF can assume that the WTRU is in a connected state (e.g., 5GMM-CONNECTED state) and / or that the WTRU is reachable. For example, if the message provided at 370 is not received or is not received before the wait time expires, the AMF can (e.g., implicitly) deregister the WTRU.

[0162] It can provide unavailability support for MUSIM devices. It can provide unavailability coordination across networks.

[0163] A WTRU can be registered to multiple (e.g., two (2)) networks. The WTRU can send a registration request to (e.g., one of the multiple networks) a first network. The registration request may include an unavailable period duration. The first network may respond with a registration accept message and / or a periodic registration duration (e.g., a timer) that may be greater than or equal to the requested unavailable period duration. The WTRU can (e.g., then) send a 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., selectively) 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 prevents (e.g., does not indicate) to the WTRU that the WTRU can re-register long before the time associated with (e.g., requested by) the first network.

[0164] Figure 4 An example is shown of how WTRU can use unavailable time period features in a scenario where MUSIM features are also used.

[0165] Figure 4 The illustration shows an example program for unavailable coordination across networks.

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

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

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

[0169] At 440, the AMF of the first network can send a registration response to the WTRU. The 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 point 460, the WTRU can send a registration request to the second network. The registration request may include the duration of the second unavailable period.

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

[0173] In some examples, multiple (e.g., two or all) networks can support unavailable period features. For example, a MUSIM WTRU can have multiple SIM cards, such as more than two (2) USIMs. The MUSIM WTRU can be registered to different networks. In some examples (e.g., Figure 5 As shown in the following example, 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 are possible.

[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, at 510, a MUSIM device with two (2) active USIM cards can successfully register to two (2) different (e.g., 5G) networks (e.g., AMF-1 and AMF-2) that support unavailable features.

[0176] At point 520, an event can occur within the WTRU that renders it unavailable for a period of time (e.g., a specific duration). The WTRU (e.g., as a MUSIM device) can communicate sequentially with the network (e.g., 5GS). The MUSIM WTRU can account for delays relative to the registration (deregistration) procedure.

[0177] At 530, the WTRU can select / choose a first network, such as AMF-1. The WTRU can send a REGISTRATION REQUEST message to AMF-1. This message can include the duration of the unavailability period, for example, along with a start delay (e.g., Δt). The delay start (Δt) can be used to notify network AMF-1 of the unavailability period, taking 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 calculated considering the number of pending registration (deregistration) procedures that the MUSIM WTRU can (e.g., needs to) perform to notify another network of unavailability. For example, Δt can be calculated as Δt = (N=1) × (the time requested (e.g., required) for registration (deregistration) to notify AMF-2 of unavailability + registration to network (AMF-2) of the end of the unavailability period), where N can be the number of registrations (deregistrations) that MUSIM can (e.g., needs to) perform. Figure 5 In the example scenario shown, there may be a single (1) multi-registration event that notifies AMF-2 of a period of unavailability. The time associated with (e.g., requesting) registration (deregistration) can take into account best and / or worst-case scenarios, such as retransmission timers / counters, retries / counters, etc. Deregistration during a power outage can 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 can consider (e.g., implicit) deregistration.

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

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

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

[0181] At 570, the MUSIM WTRU can (for example, successfully) execute events that render the MUSIM WTRU unusable, such as a silent reset at the modem, a security patch update, an OS upgrade, a modem SW update, and / or a device reboot via OMA-DM when modem settings change.

[0182] At 580, the MUSIM WTRU can send a REGISTRATION REQUEST message to AMF-2 (e.g., to prevent the inclusion (e.g., exclusion) of the unavailability period duration IE), thereby notifying the network that the MUSIM WTRU is now available. There can be an order of availability independent of unavailability. For example, the network last notified of the unavailability period could be the first network notified of availability. In the example scenario, AMF-2 can be given higher priority than notifying AMF-1 of the WTRU's availability. The delay provided to AMF-1 can begin with a delay relative to notifying another network of unavailability, followed by availability and / or corresponding procedural timings.

[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] refer to Figure 5 An example is provided in which multiple (e.g., two or all) networks can support unavailable period features. MUSIM WTRU can perform one or more of the following.

[0185] like Figure 5 As shown, at 510-520, a MUSIM device (e.g., a WTRU) with two (2) active USIM cards can (e.g., successfully) register with two (2) different (e.g., 5G) networks (e.g., AMF-1 and AMF-2) that support the unavailability feature. Events can occur within the WTRU that can render it unavailable for a period of time (e.g., a certain 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 relative to the registration (deregistration) procedure.

[0186] like Figure 5As shown, at 530 / 540, the MUSIM WTRU can 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 a start delay Δt. The delay start (Δt) can be used to notify network AMF-1 of the unavailability period, taking 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 can be calculated by considering the number of pending registration (deregistration) procedures that the MUSIM WTRU can (e.g., needs to) perform to notify another network of unavailability.

[0187] For example, in Figure 5 In the example shown, Δt can be determined as Δt = (N=1) × (the time requested (e.g., required) for a registration (deregistration) to notify AMF-2 of unavailability + the registration notifying the network (AMF-2) of the end of the unavailability period), where N can be the number of registrations (deregistrations) that MUSIM can (e.g., needs) to perform. Figure 5 In the example scenario shown, there may be a (1) multi-registration event that notifies AMF-2 of the unavailable period.

[0188] The time associated with registration (deregistration) (e.g., the time required for registration (deregistration)) can take into account best and / or worst-case scenarios, such as retransmission timers / counters, retries / counters, etc. Deregistration during a power outage can consider the duration 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 can consider deregistration (e.g., implicit deregistration). For example, if AMF-1 responds with a REGISTRATION ACCEPT message, AMF-1 can (e.g., subsequently) release the RRC signaling connection.

[0189] like Figure 5 As shown, at 550 / 560, as the last instance to be notified of unavailability, the MUSIM WTRU can send a REGISTRATION REQUEST to the second AMF (e.g., AMF-2). 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 5As shown, at 570 / 580 / 590, the WTRU can (e.g., successfully) execute events that render the WTRU unavailable, such as a silent reset at the modem, a security patch update, an OS upgrade, a modem SW update, and / or a device reboot via OMA-DM when modem settings change. The MUSIM WTRU can notify the network that it is available (e.g., now) by sending a REGISTRATIONREQUEST message to AMF-2 (e.g., excluding the unavailability period duration IE). There can be an order of availability. For example, the network last notified of the unavailability period can be the first network notified of its availability. For example, as... Figure 5 As shown, AMF-2 can be given higher priority than notifying AMF-1 of the WTRU's availability. The delay provided to AMF-1 can begin with a delay relative to notifying another network of unavailability, for example, followed by availability and / or the corresponding procedure timing. The MUSIM WTRU can notify the network that the MUSIM WTRU is available (e.g., now) by sending a REGISTRATION REQUEST message to AMF-1 (e.g., excluding the unavailability period duration IE).

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

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

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

[0194] At point 620, an event can occur within the WTRU that renders it unavailable for a period of time (e.g., a specific duration). The WTRU (e.g., as a MUSIM device) can communicate sequentially with the network (e.g., 5GS). The MUSIM WTRU can account for delays relative to the registration (deregistration) procedure.

[0195] At 630, the MUSIM WTRU can select / choose the first network (e.g., AMF-1) to send a REGISTRATION REQUEST message to it. This REGISTRATION REQUEST message includes, for example, the unavailability period duration IE and / or a start delay Δt. The delay start (Δt) can be taken into account when the unavailability period is notified to network AMF-1, taking 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 calculated by considering the number of pending registration (deregistration) procedures that the MUSIM WTRU can (e.g., needs) to perform to notify another network of unavailability. For example, as... Figure 6 As shown, another network may not support unavailable features (e.g., EPS or 5GS with unsupported features). The delay start can take into account the duration associated with deregistering the WTRU from another network (e.g., the duration that deregistering the WTRU from another network might take).

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

[0197] At 650, the second network (AMF-2 / MME) may not support this feature. WTRU can trigger deregistration toward the network, for example, by sending a DEREGISTRATION REQUEST message (e.g., with a reason code for the power outage).

[0198] In some examples, such as MUSIM WTRU and AMF-2 / MME, MICO mode can be supported. The MUSIM WTRU can initiate MICO mode instead of a deregistration procedure. When setting the activity time for MICO mode, the network can consider the duration of the available unavailability period. The activity time may not be consistent with the unavailability period. The activity time can begin after the duration of the unavailability period. The network can (e.g., alternatively) set the periodic registration duration (e.g., timer duration) to be equal to or greater than the unavailability period duration, which ensures that the WTRU can perform periodic registration when it becomes available again. During periodic registration, the network can reconfigure the WTRU with desired parameters (e.g., a new periodic registration duration / timer value).

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

[0200] At 660, the WTRU can (for example, successfully) execute events that render the WTRU unusable, such as a silent reset at the modem, a security patch update, an OS upgrade, a modem SW update, and / or a device reboot via OMA-DM when modem settings change.

[0201] At point 670, the MUSIM WTRU can send a DEREGISTRATION REQUEST message to AMF-2 (e.g., to prevent the inclusion (e.g., exclusion) of the unavailability period duration IE), thereby notifying the network that the MUSIM WTRU is now available. There can be an order of availability, excluding unavailability. For example, the network last notified of the unavailability period could be the first network notified of availability. For example, as... Figure 5 As shown, AMF-2 / MME can be given higher priority than notifying AMF-1 of the availability of the WTRU. The delay provided to AMF-1 can begin to take into account the delay relative to notifying another network of unavailability, for example, followed by availability and / or the corresponding procedural timing.

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

[0203] refer to Figure 6 This provides yet another example procedure where one of the networks may not support the unavailability period feature. MUSIM WTRU can implement one or more of the following.

[0204] like Figure 6 As shown, at 610-620, a MUSIM device (e.g., a WTRU) can have two (2) active USIM cards. The MUSIM WTRU can successfully register with two (2) different networks (e.g., AMF-1 and AMF-2 / MME). In the example scenario, the second network could be an EPS that does not support unavailability features or a 5G network that does not support unavailability features (e.g., AMF). Events can occur within the WTRU that can render it unavailable for a period of time. The WTRU (e.g., as a MUSIM device) can communicate sequentially with the 5GS. The MUSIM WTRU can account for delays relative to the registration (deregistration) procedure.

[0205] like Figure 6As shown, at 630 / 640, the MUSIM WTRU can select a first network (e.g., AMF-1) and send a REGISTRATION REQUEST message, which includes, for example, the unavailability period duration IE and / or a start delay Δt. The delay start (Δt) can be used to notify network AMF-1 of the unavailability period, taking into account the delay with the provided delay start duration value. The actual duration for which the WTRU may be unavailable can be calculated as the unavailability period duration + Δt. For example, the delay start Δt can be calculated by considering the number of pending registration (deregistration) procedures that the MUSIM WTRU can (e.g., needs to) perform to notify another network of unavailability. For example, as... Figure 6 As shown, another network does not support unavailable features (e.g., EPS or 5GS with unsupported features). The delay can be initiated considering the duration that might be spent deregistering the MUSIM WTRU from the other network. AMF-1 can respond with a REGISTRATIONACCEPT message. 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. The WTRU can trigger deregistration toward the network, for example, by sending a DEREGISTRATION REQUEST message (e.g., with a reason code for the power outage).

[0207] In some examples, MUSIM WTRU and AMF-2 / MME can support MICO mode. For example, a MUSIM WTRU can initiate MICO mode instead of a deregistration procedure. When setting the activity time for MICO mode, the network can consider the duration of the available unavailability period. The activity time may not be consistent with the unavailability period. The activity time can begin after the duration of the unavailability period. The network can (e.g., alternatively) set the periodic registration duration (e.g., timer duration) to be equal to or greater than the duration of the unavailability period, which ensures that the WTRU can perform periodic registration when the WTRU becomes available again. During periodic registration, the network can reconfigure the WTRU with desired parameters (e.g., a 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 for 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 reset at the modem, a security patch update, an OS upgrade, a modem SW update, and / or a device reboot via OMA-DM when modem settings change. The MUSIM WTRU can notify the network that it is now available by sending a REGISTRATIONREQUEST message to AMF-2 (e.g., excluding the unavailability period duration IE). There can be an order of availability. For example, the network last notified of the unavailability period can be the first network notified of its availability. For example, as... Figure 6 As shown, AMF-2 / MME can be given higher priority than notifying AMF-1 of the WTRU's availability. The delay provided to AMF-1 can begin with a delay relative to notifying another network of unavailability, for example, followed by availability and / or the corresponding procedure timing. The MUSIM WTRU can notify the network that the MUSIM WTRU is available (e.g., now) by sending a REGISTRATION REQUEST message to AMF-1 (e.g., excluding the unavailability period duration IE).

[0210] Unavailability period support can be provided for devices registered to multiple networks (e.g., both EPC and 5GC). The AMF can detect that a 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 EPC, or from a WTRU whose EMM state is EMM-REGISTERED. For instance, if the initial registration request includes a WTRU status information element (where the N1 mode reg bit of the WTRU status information element is set to a value of 1, indicating that the WTRU is in the EMM-REGISTERED state), the AMF can detect that the WTRU is registered to EPS.

[0211] A WTRU capable of operating in S1 and N1 modes can detect events that need to be executed, rendering the WTRU unavailable for a period of time. The WTRU can (e.g., determine) send the duration of the unavailability period to the AMF, for example, 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 an 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 joint registration for 5G and EPS access, or dual registration, and in this example, the AMF receives a registration request from the WTRU including the duration of the unavailability period, the AMF can (e.g., based on the registration request) send a notification to the MME (e.g., via the N26 interface). This notification can indicate to the MME that the WTRU will be unavailable for a period of time. The notification can include the duration of the unavailability period or a periodic registration time that the AMF can send to the WTRU in a registration response. The MME can determine (e.g., be informed) how long the WTRU is expected to be unavailable, for example, based on the duration of the unavailability period in the notification or the periodic registration time. The MME can perform one or more of the following actions (e.g., any combination) based on receiving the notification.

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

[0214] For example, the MME can respond to the AMF with an indication that the MME disagrees with maintaining the WTRU's context when the WTRU is unavailable and / or the AMF can indicate to the WTRU that the WTRU may consider deregistering from the EPS, for example, and the WTRU may transition from an EMM-REGISTERED state to an EMM-DEREGISTERED state. The response from the MME may (e.g., also) include a different (e.g., new) periodic tracking area update duration (e.g., timer) value sent by the AMF 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 can send a registration response to the WTRU. The registration response may include one or more of the following indications: an indication that the unavailable period is shared with the MME and / or that the WTRU can perform a tracking area update to the MME when the unavailable event is completed; an indication that the unavailable period is rejected by the MME and / or that the WTRU considers that the WTRU should be deregistered from EPS, for example, and a transition from EMM-REGISTERED to EMM-DEREGISTERED status; and / or a value (e.g., a new value) that the WTRU can assign to its EPS periodic tracking area update duration (e.g., a timer) value.

[0216] The WTRU can complete unavailability periods. The WTRU can (e.g., upon completing an unavailability period) perform registration area update procedures for the 5GS and tracking area update procedures for the EPS. For example, (e.g., only) if the WTRU has not yet transitioned to EMM-DEREGISTERED state, the tracking area update procedure can be performed. For example, if the WTRU has transitioned to EMM-DEREGISTERED state, the WTRU can perform an attachment procedure to 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: EPS NAS signaling can prevent changes (e.g., no changes are required); EPS context can be maintained when the WTRU is unavailable; and / or the WTRU can determine (e.g., be informed) whether the MME is unable or unwilling to maintain the EPS context when the WTRU is unavailable.

[0218] Figure 7 An example of a dual registration scenario is illustrated, in which the WTRU has both 5GMM and EMM contexts.

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

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

[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, the AMF can, for example, send a notification to the MME via the N26 interface. This notification can instruct the MME that the WTRU will be unavailable for a period of time (e.g., it will be). The notification may include the duration of the unavailability period or the periodic registration time that the AMF can 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 can be informed how long the WTRU is expected to be unavailable.

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

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

[0225] For example, the MME may respond to the AMF with the following indications: the MME disagrees with maintaining the WTRU's context when the WTRU is unavailable, the AMF (e.g., may) indicate to the WTRU that the WTRU may consider deregistering from EPS, and / or the WTRU (e.g., may) transition from EMM-REGISTERED to EMM-DEREGISTERED state. The response from the MME may (e.g., may also) include (e.g., a new) periodic tracking area update duration (e.g., a timer) value sent by the AMF to the WTRU.

[0226] At 760, the MME can respond to notifications from the AMF (e.g., via the N26 interface). 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 can be relayed back to the WTRU, for example, via the AMF.

[0227] At 770, the AMF can provide a registration acceptance to the WTRU. The registration response may include one or more of the following indications: sharing an unavailable period with the MME, the WTRU performing a tracking area update to the MME when the unavailable event is complete, and / or the EMM status being an indication of EMM-REGISTERED; the unavailable period being rejected by the MME, the WTRU considering itself to be deregistered from EPS, and / or the WTRU being able to transition from EMM-REGISTERED to EMM-DEREGISTERED status; and / or the WTRU assigning a new value to the EPS periodic tracking area update timer value.

[0228] At 780, the WTRU can (for example, successfully) execute events that render the WTRU unusable, such as a silent reset at the modem, a security patch update, an OS upgrade, a modem SW update, and / or a device reboot via OMA-DM when modem settings change.

[0229] At 790, WTRUs that are removed from unavailable periods can perform a registration procedure with the AMF, for example, excluding unavailable periods (IE).

[0230] At 795, the WTRU may (e.g., depending on the results and responses received by the WTRU from the MME via the AMF) trigger an EMM tracking area update procedure (e.g., if the EMM status is EMM-REGISTERED) or an EMM ATTACH procedure (e.g., if the EMM status is EMM-DEREGISTERED) to indicate to the MME that the unavailable period has ended and the WTRU is reachable again.

[0231] For unavailability period characteristics, analysis (e.g., NWDAF) can be supported. AMF's Namf_EventExposure service can support NF callers (e.g., NWDAF) that 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: one or more WTRU identifiers; unavailability time information for (e.g., each) WTRU identifier; and / or indications of expected actions, such as when each WTRU becomes available.

[0232] If (for example, when) the calling party NF subscribes to or invokes the Namf_EventExposure subscription service operation and provides an event ID, the AMF can provide WTRU unavailability information, such as (for example, equal to) one or more of the following: Registration-Status-Report, Connection-Status-Report, Reachability-Report, Area-In-UE-Report, 5GS-User-Status-Report, Frequent-Mobility-Registration-Report, UE-Access-Behavior-Trend, and / or UE-MM-Transaction-Report. Additionally and / or alternatively, an event ID (e.g., a new event ID) (e.g., WTRU unavailability information) can be defined. If (for example, when) the calling party NF subscribes to or invokes the Namf_EventExposure subscription service operation and provides an event ID (e.g., equal to "WTRU unavailability information"), the AMF can provide WTRU unavailability information.

[0233] The unavailability time information provided by the AMF to the WTRU caller NF can be one or more of the following: equal to the unavailability period duration requested by the WTRU; set to an absolute time value based on the unavailability period duration requested by the WTRU; set to a value indicating how long the AMF expects or needs to elapse until the unavailability time 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 can indicate that if (for example, when) the unavailable period ends, then (for example, expected) the WTRU performs mobility registration, or indicate that if (for example, when) the unavailable period ends, then (for example, expected) the WTRU performs initial registration.

[0235] AMF can instruct that if (for example, when) the unavailability period ends, for example, if the WTRU provides the duration of the unavailability period in the mobility registration request, then (for example, expected) the WTRU will perform mobility registration.

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

[0237] Providing indication of the expected action may be useful (e.g., important) if (for example, when) the WTRU becomes available to the consumer NF (e.g., NWDAF), for example, because the expected action may affect the amount of network activity (e.g., what might be needed) if (for example, when) the WTRU becomes available. For example, an initial registration procedure may result in more signaling than a mobility registration procedure. For example, if the consumer NF (e.g., NWDAF) is informed of what action is expected, the consumer NF can (e.g., be able to) generate more accurate statistics and / or predictions.

[0238] Figure 8 An example procedure is shown whereby 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 provide statistics and / or forecasts to consumer-side NFs such as PCF, AMF, NSSF, NEF, SMF, and / or AF.

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

[0240] like Figure 8 As shown, at 810, a consumer NF (e.g., PCF, AMF, NSSF, NEF, SMF, or AF) can 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 analysis requested can be one or more of the following, for example: network slice instance load level statistics and forecasts; network slice load level statistics and forecasts; network function load level statistics and forecasts; network load level statistics and forecasts; WTRU communication statistics and forecasts; and / or sixth WTRU anomalous behavior statistics and forecasts.

[0241] At 820, the NWDAF can (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 can invoke the AMF's Namf_EventExposure service operation. The type of service invocation can be a request or subscription operation. The event ID value that the NWDAF can provide to the AMF in the operation can be one or more of the following: Registration-Status-Report, Connection-Status-Report, Reachability-Report, Area-In-UE-Report, 5GS-User-Status-Report, Frequent-Mobility-Registration-Report, UE-Access-Behavior-Trend, UE-MM-Transaction-Report; and / or "WTRU Unavailable Information".

[0242] At 830, the AMF can receive NAS registration or deregistration requests, which may include the duration of the unavailability period. In the example, the operation at 830 may occur before 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 can respond to the NWDAF (e.g., immediately) with unavailability time information and / or an indication of the expected action if (e.g., when) the WTRU becomes available. This response can inform one or more WTRUs. For example, if the action at 820 is a subscription operation, a NAS message at 830 can 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 can inform one or more WTRUs.

[0244] At 850, NWDAF can export the analysis (e.g., statistical or predictive) requested at 810. When WTRU becomes available, the analysis can be exported based on unavailable time information and / or indications of expected actions.

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

[0246] Relay WTRUs can support unavailable period characteristics. Relay WTRUs can enter unavailable periods.

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

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

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

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

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

[0252] At 920, the trunk WTRU can enter an unavailable period, for example, by sending a REGISTRATION REQUEST message to the AMF. This message can 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 may no longer be available via the trunk WTRU.

[0253] At 930, a list of remote WTRU information can be passed from the AMF to the AF for connection loss events (e.g., assuming the AF has already registered the connection loss event for the corresponding remote WTRU).

[0254] At 940, the AMF can respond with REGISTRATION ACCEPT, which provides a list of remote WTRUs (e.g., the status of the receipt of the acknowledgment list).

[0255] At 950, the relay WTRU can notify the connected remote WTRU of the relay WTRU's unavailability, such as the duration of the unavailability period.

[0256] At 960, the remote WTRU can be notified of the unavailability of the relay WTRU. The remote WTRU can use the unavailability of the relay WTRU as a trigger to buffer UL activities, trigger the selection of different relay WTRUs, establish a direct connection to (e.g., 5G) networks, and / or provide the network with information about the unavailability period (e.g., via a registration procedure (deregistration procedure)).

[0257] Remote WTRUs can enter unavailable periods.

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

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

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

[0261] At 1020, a remote WTRU can trigger unavailability, for example, 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 the relay WTRU with information about unavailability (e.g., via an unavailability notification message), which may include, for example, the duration of the unavailability period and / or the remote WTRU ID.

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

[0264] At position 1050, the relay WTRU can notify other remote WTRUs of the remote WTRU's 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, a remote WTRU can provide an unavailability notification message to a relay WTRU, where unavailability is indicated as inapplicable. 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 a request is unavailable for a period of time, it can provide an explanation for the expected availability of the WTRU. As described in this article, the WTRU can use the MICO mode. When using the MICO mode, the WTRU can apply a strictly periodic registration timer feature.

[0267] The WTRU can send a registration request message to the network. The registration request message may include one or more of the following information elements: a request using the MICO mode; an indication of whether the WTRU supports a strictly periodic registration timer; a requested activity 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 can 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 activity 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, making the WTRU available at predictable times. This configuration can be achieved by the AMF selecting values ​​for the T3324 and T3512 times and / or by the AMF determining whether to enable strictly periodic registration durations (e.g., timers).

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

[0271] A registration accept message can indicate that a strictly periodic registration duration (e.g., a timer) feature is enabled, and that unavailable periods are not accepted. The WTRU can (e.g., in response to a registration accept 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 registration duration (e.g., the timer) expiry, and enter the CM-IDLE state when the activity duration (e.g., the timer) has not run. By waiting until these conditions are met, it can be ensured that the WTRU's expected availability time has ended (e.g., just passed). This approach can be useful when the strictly periodic registration time is nearing its expiry, for example, when the WTRU requests the unavailable period duration.

[0272] A registration accept message can indicate that the strictly periodic registration timer feature is not enabled and that the unavailable period has not been accepted. The WTRU can (e.g., in response to a registration accept message) wait to request the unavailable period duration again until the WTRU enters the CM-IDLE state and the activity duration (e.g., a timer) has not run. By waiting until these conditions are met, it can be ensured that the WTRU's expected availability 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 period.

[0274] The registration accept message can indicate that MICO mode is not enabled and unavailable periods are not accepted. WTRU can (e.g., in response to the registration accept message) track the duration of unavailable periods (e.g., by configuring a timer) and can prevent re-requesting of unavailable periods (e.g., by not requesting) until the waiting duration (e.g., the timer) expires and WTRU has entered the CM-IDLE state.

[0275] WTRU can (e.g., alternatively) determine (e.g., at any time) the duration of the unavailable period in the deregistration request (e.g., again). Figure 11 The image shows an example of the program.

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

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

[0278] like Figure 11 As shown, the WTRU can (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 can receive a registration acceptance message that indicates that MICO mode is enabled, the strictly periodic registration duration (e.g., timer) feature is not enabled, and the unavailable period duration is not permitted. For example, if the WTRU is already in CM-IDLE state and the activity duration (e.g., timer) is not running, the WTRU can determine to send a second registration request that includes a second unavailable period duration. The WTRU can send the second registration request, for example, that includes a second unavailable period duration.

[0279] like Figure 11As shown, the WTRU can (e.g., when MICO mode is not enabled) send a registration request that may include the duration of an unavailable period. The WTRU can receive a registration accept message that prevents (e.g., does not indicate) that MICO mode is enabled and that unavailable period durations are not allowed. The WTRU can configure and begin tracking durations with unavailable period durations (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 can determine to send a second registration request that includes a second unavailable period duration. The WTRU can send a second registration request that includes a second unavailable period duration.

[0280] Although the above features and elements are described in specific combinations, 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 scenario and can be applied to other wireless systems. For example, although 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 scenario and can also be applied to other wireless systems.

[0282] The processes described above can be implemented in computer programs, software, and / or firmware incorporated 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 compact disc (CD)-ROMs and / or digital versatile discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver used in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU) comprising: a processor configured to: send a registration request to a network entity, wherein the registration request indicates a first duration; receive a registration accept message, wherein the registration accept message includes an indication, the indication indicating whether the WTRU is to inform the network entity when the WTRU is available; determine that an unavailability event associated with the first duration has ended; determine whether the WTRU is to inform the network entity when the WTRU is available; and send a registration update request to the network based on the determination that the unavailability event has ended and the determination that the WTRU is to inform the network entity when the WTRU is available.

2. The WTRU of claim 1, wherein, the processor is further configured to: determine a second duration, wherein the second duration is a back-off duration associated with congestion, wherein the registration update request is sent during the second duration.

3. The WTRU of claim 1, wherein, the processor is further configured to: receive signaling from the network indicating congestion, and wherein the signaling indicates a second duration, wherein the second duration is a back-off duration associated with congestion, and wherein the registration update request is sent during the second duration.

4. The WTRU of any of claims 1-3, wherein, the first duration is an unavailability duration associated with the WTRU.

5. The WTRU of any one of claims 2-4, wherein, the first duration is greater than or equal to the second duration.

6. The WTRU of any one of claims 2-5, wherein, the processor is further configured to: determine that the second duration is active, wherein the registration request is sent to the network entity based on the determination that the second duration is active.

7. The WTRU of any one of claims 1-6, wherein, the registration request is sent via NAS signaling.

8. The WTRU of any one of claims 1-7, wherein, the registration update request includes an indication that the WTRU is available.

9. A method comprising: sending a registration request to a network entity, wherein, the registration request indicates a first duration; receiving a registration accept message, wherein the registration accept message includes an indication, the indication indicating whether the WTRU is to inform the network entity when the WTRU is available; determining that an unavailability event associated with the first duration has ended; determining whether the WTRU is to inform the network entity when the WTRU is available; and sending a registration update request to the network based on the determination that the unavailability event has ended and the determination that the WTRU is to inform the network entity when the WTRU is available.

10. The method of claim 9, wherein, the method further comprising: determining a second duration, wherein the second duration is a back-off duration associated with congestion, wherein the registration update request is sent during the second duration.

11. The method of claim 9, wherein, the method further comprising: receiving signaling from the network indicating congestion, and wherein the signaling indicates a second duration, wherein the second duration is a back-off duration associated with congestion, and wherein the registration update request is sent during the second duration.

12. The method of any one of claims 9-11, wherein, the first duration is an unavailability duration associated with the WTRU.

13. The method of any one of claims 10-12, wherein, The first duration is greater than or equal to the second duration.

14. The method of any one of claims 10 to 13, wherein, The method further comprises: determining that the second duration is active, wherein the registration request is sent to the network entity based on the determination that the second duration is active.

15. The method of any one of claims 9 to 14, wherein, The registration request is sent via NAS signaling.

16. The method of any one of claims 9 to 15, wherein, The registration update request includes an indication indicating that the WTRU is available.

Images