Unavailable Period Support for MUSIM Devices

Abstract

The device can be a multi-universal subscriber identification module (MUSIM) device. The device can send a first registration request to a first network, for example, to enable an inoperable period function with a second network. The registration request can indicate a first inoperable duration. The device can determine that an inoperable event is triggered. The device can determine that the device will be inoperable for a period of time. The device can receive a first registration response, for example, a first registration acceptance message. The first registration response can indicate a first registration duration. The device can determine a second inoperable duration. The device can send a second registration request to the second network, for example, indicating the second inoperable duration. The device can receive a second registration response. The second registration response can be a second registration acceptance message. The second registration response can indicate a second registration duration.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Application No. 63 / 457,515, filed on April 6, 2023, the content of which is incorporated herein by reference in its entirety.

Background Art

[0002] Mobile communications using wireless communication are continuously evolving. The fifth generation may be referred to as 5G. Previous (legacy) generations of mobile communications can be, for example, the fourth generation (4G) long term evolution (LTE).

Summary of the Invention

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

[0004] A device (e.g., a network device such as a WTRU, a device with access and mobility function (AMF)) may perform one or more of the following actions. The device may send a registration request (e.g., to a network entity) via non-access stratus (NAS) signaling. The registration request may include a first duration (e.g., an inavailability duration associated with the WTRU). The device may receive a registration acceptance message. The registration acceptance message may indicate whether the device should notify the network entity when the WTRU is available (e.g., after an inavailability event / duration has elapsed). The device may determine that the inavailability event has ended. The WTRU may determine whether to notify the network entity that the WTRU has become available (e.g., based on the registration acceptance message). The device may send a registration update request. The registration update request may be sent based on the determination that the inavailability event has ended and the determination that the WTRU should notify the network entity when the WTRU becomes available. The registration update request may indicate that the WTRU is available.

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

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

[0007] The device can be a multi-universal subscriber identity module (MUSIM) device. The device can send a first registration request to a first network. The first registration request can indicate enabling an inavailability period function with a second network. The registration request can indicate a first inavailability duration associated with the inavailability period. The device can determine that an inavailability event is triggered. The device can determine that the device (e.g., a WTRU) becomes unavailable for a period of time. The determination that the device becomes unavailable for a period of time can be based on the determination that the inavailability event is triggered. The first inavailability duration can be determined based on the determination that the device becomes unavailable for a period of time. The device can receive a first registration response (e.g., from the first network). The first registration response can be a first registration acceptance message. The first registration response can indicate a first registration duration. The first registration duration can be greater than or equal to the first inavailability duration. The device can determine a second inavailability duration, for example, based on the first inavailability duration. The device can send a second registration request to a second network. The second registration request can indicate enabling an inavailability period function with the second network. The second registration request can indicate the second inavailability duration. The device can receive a second registration response from the second network. The second registration response can be a second registration acceptance message. The second registration response can indicate a second registration duration. The second registration duration can be greater than or equal to the second inavailability duration. The second inavailability duration can be greater than or equal to the first registration duration.

[0008] The device may perform an action associated with double registration. The device may receive a registration request (e.g., from a WTRU). The registration request may indicate inactivity period information. The registration request may include an inactivity period information element that indicates inactivity period information. The inactivity period information may indicate, for example, an inactivity duration associated with the WTRU. The device may send a notification to an entity (e.g., a mobility management entity). The notification may indicate that the WTRU is unavailable for a period of time. The device may receive a notification response (e.g., from the entity). The notification response may indicate an indication that the entity has accepted the unavailability of the WTRU. The notification response may indicate a tracking area update duration. The notification response may indicate an indication that the entity has accepted the unavailability of the WTRU and the tracking area update duration. The device may send a registration acceptance message (e.g., to the WTRU) based on, for example, the notification response. The registration acceptance message may indicate a tracking area update duration. The registration acceptance message may indicate to the WTRU, for example, to perform a tracking area update with the entity based on the completion of the inactivity event.

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

Brief Description of the Drawings

[0010]

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

DETAILED DESCRIPTION OF THE INVENTION

[0011] FIG. 1A is a diagram illustrating an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. The communication system 100 may enable a plurality of wireless users to access such content through sharing of system resources including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC).

[0012] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a "station" and / or "STA", can be configured to transmit and / or receive wireless signals and can be user equipment (UE), a mobile station, a fixed subscriber unit or a mobile subscriber unit, a subscriber-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or a Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., for remote surgery), an industrial device and application (e.g., a robot and / or other wireless devices operating in an industrial and / or automated processing chain context), a home appliance device, a device operating in a commercial wireless network and / or an industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

[0013] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as CN106 / 115, Internet 110, and / or other network 112. By way of example, base stations 114a, 114b may be a base transceiver station (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, 114b are depicted as single elements, it will be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0014] Base station 114a may be part of RAN 104 / 113 and may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals at one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage to a specific geographic area that may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, 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 utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

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

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

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

[0019] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Accordingly, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by transmissions sent between multiple types of radio access technologies and / or multiple types of base stations (e.g., eNBs and gNBs).

[0020] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0021] The base station 114b in FIG. 1A can be, for example, a wireless router, a home node B, a home e-node B, or an access point, and can utilize any suitable RAT to facilitate wireless connection in a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (for use by drones, for example), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0022] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. The data can have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that employ the same or a different radio access technology (RAT) as RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113 which can utilize New Radio (NR) radio technology, CN 106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0023] CN106 / 115 can also function as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 can include a circuit-switched telephone network that provides a plain old telephone service (POTS). The Internet 110 can include a global system of interconnected computer networks and devices, and these networks and devices use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP internet protocol suite. The network 112 can include a wired communication network and / or a wireless communication network that is owned and / or operated by another service provider. For example, the network 112 can include another CN connected to one or more RANs that can use the same RAT as the RAN104 / 113 or a different RAT.

[0024] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 can include a multi-mode function (for example, the WTRU102a, 102b, 102c, 102d can include a plurality of transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in Figure 1A can be configured to communicate with a base station 114a that can employ a cellular-based wireless technology and a base station 114b that can employ IEEE802 wireless technology.

[0025] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU 102 may include any partial combination of the foregoing elements while remaining consistent with one embodiment.

[0026] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. Although Figure 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

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

[0029] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have a multimode functionality. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs such as, for example, NR and IEEE 802.11.

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

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

[0032] Processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU102. In addition to, or instead of, information from the GPS chipset 136, the WTRU102 may receive location information from a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or may determine its location based on the timing of signals received from two or more neighboring base stations. It will be understood that the WTRU102 may obtain location information by any suitable location determination method while remaining consistent with one embodiment.

[0033] Processor 118 may further be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral devices 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

[0035] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 may employ E-UTRA radio technology to communicate with WTRU102a, 102b, 102c via air interface 116. RAN104 may also communicate with CN106.

[0036] RAN104 may include eNodeBs 160a, 160b, 160c, but it will be understood that RAN104 may include any number of eNodeBs while remaining consistent with one embodiment. Each of eNodeBs 160a, 160b, 160c may include one or more transceivers for communicating with WTRU102a, 102b, 102c via air interface 116. In one embodiment, eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, eNodeB 160a, for example, may transmit a wireless signal to WTRU102a and / or receive a wireless signal from WTRU102a using multiple antennas.

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

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

[0039] The MME 162 can be connected to each of the eNodeBs 162a, 162b, and 162c in the RAN 104 via the S1 interface and can function as a control node. For example, the MME 162 can authenticate users of the WTRUs 102a, 102b, 102c, activate / deactivate bearers, select a specific serving gateway during the initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 can provide control plane functions for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

[0040] SGW 164 can be connected to each of the eNodeBs 160a, 160b, and 160c in RAN 104 via the S1 interface. SGW 164 can generally route and transfer user data packets between the WTRUs 102a, 102b, and 102c. SGW 164 can perform other functions such as the function of anchoring the user plane during handover between eNodeBs, the function of triggering paging when DL data is available to the WTRUs 102a, 102b, and 102c, and the function of managing and storing the contexts of the WTRUs 102a, 102b, and 102c.

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

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

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

[0044] In an exemplary embodiment, the other network 112 can be a WLAN.

[0045] A WLAN in infrastructure basic service set (BSS) mode can have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP can have access or an interface to another type of wired / wireless network that carries traffic entering and / or exiting the distribution system (DS) or BSS. Traffic destined for an STA that originates outside the BSS can reach and be sent to the STA through the AP. Traffic originating from an STA and destined for a destination outside the BSS can be sent to the AP to be sent to their respective destinations. Traffic between STAs within the BSS can be sent through the AP, for example, the source STA can send the traffic to the AP, and the AP can send the 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 sent using direct link setup (DLS) directly between the source STA and the destination STA (e.g., directly between them). In a particular exemplary embodiment, the DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) can communicate directly with each other. The IBSS mode of communication can be referred to herein as the "ad hoc" communication mode.

[0046] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may transmit beacons on a fixed channel such as the primary channel. The primary channel can be of a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS, but can also be used by the STA to establish a connection with the AP. In certain representative embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented. In the case of CSMA / CA, STAs including the AP (e.g., all STAs) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. Only one STA (e.g., only one station) can transmit at any given time in a given BSS.

[0047] A High Throughput (HT) STA can use a 40 MHz wide channel for communication, and this 40 MHz wide channel can be formed, for example, via a combination of the primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel.

[0048] A Very High Throughput (VHT) STA may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. A 40 MHz and / or 80 MHz channel may be formed by combining a plurality of adjacent 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels, or by combining two non-adjacent 80 MHz channels, which may be referred to as an 80+80 configuration. In the case of an 80+80 configuration, after channel encoding, the data may pass through a segment parser that may divide the data into two streams. The Inverse Fast Fourier Transform (IFFT) process and time domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0049] The sub-1 GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier frequency are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine type communication, such as MTC devices within a macro communication range area. The MTC device may have limited capabilities, including support for certain capabilities, e.g., support for certain and / or limited bandwidths (e.g., supporting only these). The MTC device may include a battery having a battery life above a threshold (e.g., to maintain a very long battery life).

[0050] A WLAN system that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or restricted by an STA from among all STAs operating in a BSS that supports the minimum bandwidth operation mode. In an example of 802.11ah, the primary channel can be 1 MHz wide for an STA (e.g., an MTC type device) that supports the 1 MHz mode (e.g., supports only this) even when the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or Network Allocation Vector (NAV) setting can depend on the status of the primary channel. For example, due to an STA transmitting to an AP (supporting only the 1 MHz operation mode), when the primary channel is in operation, even if most of the frequency band remains in an operation pause and can be available, the entire available frequency band can be considered to be in operation.

[0051] In the United States, the available frequency band that can be used by 802.11ah is 902 MHz to 928 MHz. In South Korea, the available frequency band is 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is 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.

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

[0053] RAN113 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN113 may include any number of gNBs while remaining consistent with one embodiment. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 108b may use beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, gNB 180a may transmit and / or receive radio signals to / from WTRU 102a using, for example, multiple antennas. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of such component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0054] WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM sub-carrier interval may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using sub-frames or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or having absolute times of various lengths).

[0055] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in a stand-alone configuration and / or a non-stand-alone configuration. In a stand-alone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, and 160c, etc.). In a stand-alone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as a mobility anchor point. In a stand-alone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in an unlicensed band. In a non-stand-alone configuration, WTRUs 102a, 102b, and 102c can communicate with and connect to gNBs 180a, 180b, and 180c while also communicating with and connecting to another RAN such as eNodeBs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement a DC principle for communicating with one or more gNBs 180a, 180b, and 180c and one or more eNodeBs 160a, 160b, and 160c substantially simultaneously. In a non-stand-alone configuration, eNodeBs 160a, 160b, and 160c can function as a mobility anchor 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.

[0056] 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 decision-making, handover decision-making, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0057] As shown in FIG. 1D, CN 115 can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and optionally data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of CN 115, it will be understood that any of these elements can be owned and / or operated by entities other than the CN operator.

[0058] AMF 182a and 182b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can play roles such as authentication of users of WTRUs 102a, 102b, and 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selection of specific SMFs 183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slices can be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on the type of service being utilized by WTRUs 102a, 102b, and 102c. For example, different network slices can be established for different use cases such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and services for machine type communication (MTC) access. AMF 162 can provide control plane functions for exchange between RAN 113 and other RANs (not shown) that use other radio technologies such as non-3GPP access technologies like LTE, LTE-A, LTE-A Pro, and / or WiFi.

[0059] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b, and configure the routing of traffic passing through UPF184a and 184b. SMF183a 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. The PDU session type can be IP-based, non-IP-based, Ethernet-based, etc.

[0060] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N3 interface, thereby providing WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-corresponding devices. UPF184 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.

[0061] CN115 may facilitate communication with other networks. For example, CN115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and the PSTN 108. Additionally, CN115 may provide access to other network 112 for WTRU102a, 102b, 102c, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local data networks (DN) 185a, 185b through UPF184a, 184b via an N3 interface to UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0062] Referring to FIGS. 1A-1D and the corresponding descriptions of FIGS. 1A-1D, one or more of the functions described herein related to one or more of WTRU102a-d, base stations 114a and b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB180a-c, AMF182a and b, UPF184a and b, SMF183a and b, DN185a and b, and / or any other device described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functionality.

[0063] An emulation device can be designed to perform one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more emulation 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 emulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. An emulation device can be directly coupled to another device for testing purposes and / or can use terrestrial wireless communication to perform the test.

[0064] One or more emulation devices can perform one or more functions including all while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be utilized in a test scenario in a test laboratory and / or in a non-deployed (e.g., for testing) wired and / or wireless communication network to perform tests of one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit (which can include one or more antennas) can be used by the emulation device to transmit and / or receive data.

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

[0066] Systems, methods, and means related to support for an inavailability period while a wireless transmit / receive unit (WTRU) is registered to non-3GPP access (e.g., to non-3GPP access only) are described herein.

[0067] A device (e.g., a network device such as a WTRU, a device with access and mobility functions (AMF)) may perform one or more of the following actions. The device may send, e.g., via non-access stratum (NAS) signaling, a registration request (e.g., to a network entity). The registration request may include a first duration (e.g., an inactivity duration associated with the WTRU). The device may receive a registration acceptance message. The registration acceptance message may indicate whether the device should inform the network entity when the WTRU is available (e.g., after an inactivity event / duration has elapsed). The device may determine that the inactivity event has ended. The WTRU may determine whether to inform the network entity that the WTRU has become available (e.g., based on the registration acceptance message). The device may send a registration update request. The registration update request may be sent based on the determination that the inactivity event has ended and the determination that the WTRU should notify the network entity when the WTRU becomes available. The registration update request may indicate that the WTRU is available.

[0068] The device may receive, e.g., an indication from the network indicating congestion. The device may receive an indication indicating a second duration (e.g., a back-off duration associated with the congestion). The second duration may be determined. The first duration may be greater than or equal to the second duration.

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

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

[0071] The device may perform an action associated with double registration. The device may receive a registration request (e.g., from a WTRU). The registration request may indicate inactivity period information. The registration request may include an inactivity period information element that indicates inactivity period information. The inactivity period information may indicate, for example, an inactivity duration associated with the WTRU. The device may send a notification to an entity (e.g., a mobility management entity). The notification may indicate that the WTRU is unavailable for a period of time. The device may receive a notification response (e.g., from the entity). The notification response may indicate an indication that the entity has accepted the unavailability of the WTRU. The notification response may indicate a tracking area update duration. The notification response may indicate an indication that the entity has accepted the unavailability of the WTRU and the tracking area update duration. The device may send a registration acceptance message (e.g., to the WTRU) based on, for example, the notification response. The registration acceptance message may indicate a tracking area update duration. The registration acceptance message may indicate to the WTRU to perform a tracking area update with the entity, for example, based on the completion of the inactivity event.

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

[0073] Systems, methods, and means related to inavailability period support while a WTRU is registered to non-3GPP access (e.g., to non-3GPP access only) are described herein.

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

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

[0076] 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. The registration response can be sent based on the reception of a registration request via a non-3GPP access network and a registration request including an unavailable period duration information element. An indication of acceptance of the unavailable period duration request can indicate the accepted unavailable period duration. The accepted unavailable period duration can be greater than or equal to the requested unavailable period duration. The connectivity loss report can indicate the unavailable period. The connectivity loss report indicating the unavailable period can be sent to the network exposure function. The device (e.g., a processor) can be further configured to receive a NAS message from the WTRU and perform one or more of stopping the tracking of the duration (e.g., stopping a timer), determining that the WTRU is reachable, or determining that the WTRU is in a connected state (e.g., based on receiving the NAS message). The device (e.g., a processor) can be further configured to implicitly deregister the WTRU based on the expiration of a timer.

[0077] Systems, methods, and means for mechanisms for providing an unavailable period to a network are described herein. Some events, such as an operating system (OS) upgrade, a silent reset in a modem, or a modem software update (also referred to as a binary update), can be performed using more than two (e.g., three) parties involved, such as a device, an operator, and an application function.

[0078] A WTRU that executes a multi-party event may become unavailable (e.g., unable to communicate with a 5G system) for a period of time (e.g., several minutes) while the event operation is being executed. The unavailability of the WTRU without prior knowledge from the core network and / or application function may affect the operation of the application server (e.g., significantly) if, for example, the application server depends on the availability of the WTRU during the unavailable period (e.g., the time period when the WTRU is not available).

[0079] When the backoff duration is active (e.g., when the timer is running), if the WTRU is registered with the network (e.g., 5GS) via non-3GPP access (e.g., only), when the multi-universal subscriber identity module (MUSIM) device is registered with multiple networks with and without support for the unavailable function (e.g., when registered), when the WTRU is registered with multiple networks (e.g., both evolved packet system (EPS) and fifth generation system (5GS)), for the support of the analysis of the unavailable function (e.g., network data analytics function (NWDAF)), when the remote WTRU and / or relay WTRU enters the unavailable period (e.g., when entering), when the mobile initiated connection only (MICO) mode and / or the strict periodic registration timer function is enabled (e.g., when enabled), etc., systems, methods, and means related to handling the unavailable period for one or more scenarios are described herein.

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

[0081] Seamless WTRU context recovery can be performed. A particular event, e.g., an OS upgrade, a silent reset in the modem, or a modem software update (also referred to as a binary update), can be performed using multiple (e.g., three) parties involved, e.g., the device, the operator, and the application function.

[0082] The WTRU may download binaries. The time for the WTRU to perform an upgrade is left for implementation by the WTRU. Implementation by some WTRUs may use user input (e.g., may seek). The WTRU may delay the execution of an event, for example, if the WTRU is unable to execute the event (e.g., due to insufficient memory capacity or battery level). The WTRU may become unavailable (e.g., may not interact with a 5G system) for a period of time (e.g., on the order of several minutes) if such an operation is performed (e.g., when executed). The WTRU may become unavailable without prior knowledge from the core network and / or application functions. WTRU unavailability may, for example, affect critical operations of an application server if the application server depends on the availability of the WTRU during an unavailable period (e.g., the time period during which the WTRU is not available).

[0083] A network (e.g., a 5G system) may enable a WTRU to provide the network with an inactivity period (e.g., an inactivity duration) in, for example, a registration request or a deregistration request. The WTRU may store its mobility management (MM) context and session management (SM) context in a universal subscriber identity module (USIM) or non-volatile memory so that, after the WTRU's inactivity period, if an event that renders the WTRU inactive for, for example, a certain time period is triggered at the WTRU, the MM context and SM context can be reused. The WTRU may trigger a mobility registration update procedure or a deregistration procedure and provide the network with the inactivity period duration, for example, if the WTRU can store its context. The network (e.g., an access and mobility function (AMF)) may take the inactivity period duration into account when, for example, determining a periodic registration update duration (e.g., a periodic registration update timer value). The AMF may provide a periodic registration update time that is longer than the inactivity period duration, for example, to avoid interfering with a WTRU that is handling an event that causes inactivity. Later (e.g., when an event that renders the WTRU inactive is completed at the WTRU, or the event is delayed to a future time, or cancelled at the WTRU), the WTRU may trigger a registration procedure to resume normal services. The WTRU may refrain from (e.g., not) including the inactivity period in a registration request message. Depending on the WTRU state, the registration procedure may be an initial registration procedure or a mobility registration update procedure.

[0084] The AMF may provide the WTRU with a strict periodic registration duration indication (e.g., a strict periodic registration timer indication), along with, for example, a periodic registration timer value. The periodic registration timer function may be applicable, for example, when the WTRU uses the MICO mode (e.g., when it is used). The AMF may present an indication to the WTRU based on the expected WTRU behavior. For example, the AMF may configure (e.g., want to configure) the WTRU to be available for downlink data every hour (e.g., on the hour) for downlink data (e.g., in the CM connection mode). The periodic registration duration (e.g., timer) function may be useful, for example, when the WTRU uses the MICO mode (e.g., when it is used). The periodic registration duration (e.g., timer) function may be used to ensure that the WTRU is in the CM connection mode at (e.g., at a predictable time). For example, if the WTRU runs a 4-hour strict periodic registration timer and applies, for example, a 10-minute active timer at all times, it may be known that the WTRU is available for 10 minutes every 4 hours. By enabling the strict periodic registration duration (e.g., timer) function, the AMF may configure the available events (e.g., 10-minute available events) to occur at predictable times.

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

[0086] The AMF can be an example of a network function (NF) from which the NWDAF can collect data. The NWDAF can use the Namf_EventExposure service of the AMF to obtain data from the AMF. The NWDAF can provide the Nnwdaf_AnalyticsInfo service that can be used by network functions to obtain statistics and predictions from the NWDAF. The policy control function (PCF), access and mobility management function (AMF), network slicing selection function (NSSF), network exposure function (NEF), session management function (SMF), and application function (AF) are examples of network functions that can call or consume the Nnwdaf_AnalyticsInfo service.

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

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

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

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

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

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

[0093] The WTRU may trigger a registration procedure to resume normal services, for example, if an event that disables the WTRU is completed at the WTRU, or if the event is delayed or cancelled at the WTRU until a future time (e.g., due to insufficient memory capacity, insufficient battery level, or completion of an event that disables the WTRU). The WTRU may refrain from including the inactivity period in the registration request message (e.g., not include it). The registration procedure may be an initial registration procedure or a mobility registration update procedure, for example, depending on the state the WTRU will ultimately be in after the event.

[0094] Inactivity period support may be provided while the backoff duration is active (e.g., while the timer is running). While a non-access stratum (NAS) backoff duration (e.g., a timer, or other backoff timer) is running at the WTRU (e.g., T3346 / T3347 / T3396, other backoff timers), the NAS layer mobility management entity may refrain from triggering mobility registration procedures towards the core network (e.g., not trigger, or be prohibited from triggering), except for one or more exceptions such as downlink (DL) paging / notification, UL high priority signaling, or emergency services. The WTRU (e.g., in this case) may refrain from sending a registration request with an inactivity period duration to the network (e.g., not send).

[0095] For example, when the network is about to send (e.g., not send) the duration of the unavailable period to the network and the WTRU executes an action that can make the WTRU unavailable while the backoff duration (e.g., timer) is running, the network may attempt (e.g., fail) to contact the WTRU for mobile incoming services while the backoff duration (e.g., timer) is running. The attempt to contact the WTRU for mobile incoming services may fail.

[0096] One or more examples described herein may show how the WTRU processes MM signaling when the MM backoff duration (e.g., timer) is running and the WTRU can execute (e.g., needs to execute) an event that makes the WTRU unavailable.

[0097] Unavailable period support may be provided while the WTRU is registered to non-3GPP access and not registered to other accesses (e.g., registered only to non-3GPP access). For example, when the NAS layer of the WTRU receives a notification from the lower layer that non-3GPP access is available, the WTRU may send an initial NAS message to establish an N1 NAS signaling connection to the AMF. The NAS may consider (e.g., then) that the WTRU is in 5GMM connection mode via non-3GPP access. The WTRU may be reachable (e.g., then) for mobile incoming communications from the network. For example, the WTRU may receive a NAS notification message from the network indicating that downlink data is available to the WTRU. A WTRU in 5GMM connection mode via non-3GPP access may generally remain in 5GMM connection mode (e.g., until the WTRU is disconnected from the non-3GPP network).

[0098] Periodic registration update procedures may be withheld (e.g., not executed) when the WTRU is registered via non-3GPP access (e.g., when registered).

[0099] A WTRU registered via non-3GPP access may indicate to the network an unavailable period, for example, so that the network and the WTRU maintain the WTRU's registration state and / or so that the network understands that the WTRU may not be reachable for mobile incoming communications.

[0100] Unavailable period support may be provided for MUSIM devices. One or more examples described herein may show how the unavailable feature may be processed for a MUSIM device registered to two or more different networks.

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

[0102] A MUSIM WTRU may be registered to multiple networks. NAS signaling procedures may be performed sequentially (e.g., only). There may be elements of delay (e.g., that may be considered) while communicating with the network about the unavailable period. Reporting of unavailability to the network may be considered sequentially while coming out of unavailability, for example, to ensure that the network is informed within a defined time frame.

[0103] One or more examples described herein can show how a MUSIM WTRU having different configurations (e.g., all networks support unavailable functions or one or more of the networks do not support unavailable functions) can indicate an unavailable period to a network such that, for example, the network and the MUSIM WTRU can maintain the registration state of the MUSIM WTRU and / or the network can understand that the WTRU is not reachable for mobile incoming communications.

[0104] Unavailable 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 S1 and N1 modes) can be registered to both EPS and 5GS. A WTRU registered to EPS can be said to be in S1 mode. A WTRU registered to 5GS can be said to be in N1 mode. A dual-registered WTRU can be in both S1 and N1 modes (e.g., simultaneously).

[0105] One of the multiple networks (e.g., EPS) may not support negotiation of an unavailable period, for example, via the S1 NAS interface between the WTRU and the Mobility Management Entity (MME) of EPS. One or more examples described herein can show how EPS refrains from (e.g., does not) deleting the context of the WTRU and / or how EPS refrains from (e.g., does not) attempting to contact the WTRU for mobile incoming communications when the WTRU is performing an event that temporarily makes it unavailable (e.g., while performing).

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

[0107] There may be several scenarios to consider. First, the unavailable period provided by the WTRU to the AMF may not be a common event. For example, the unavailable period may occur (e.g., only) when the WTRU is installing a software upgrade (e.g., while installing). Second, multiple (e.g., many) WTRUs within an area may install software upgrades simultaneously or at similar times. The multiple WTRUs may become unavailable and may become available again almost simultaneously. Third, the unavailable period provided by the WTRU may be a strong indication of when the WTRU may attempt to execute a registration procedure to the network (e.g., it is expected that the WTRU may attempt to register to the network within the unavailable period duration).

[0108] The unavailable period duration requested by the WTRU may potentially have a strong impact on future events that may occur within the network. The unavailable period duration requested by the WTRU may affect the accuracy of the statistics and predictions provided to other network functions by the NWDAF. The NWDAF may obtain the unavailable period duration and / or may consider the unavailable period duration when generating statistics and predictions (e.g., using one or more of the functions described herein).

[0109] Unavailability period functionality support may be provided for a relay WTRU. One or more examples described herein may show how to handle scenarios for a relay WTRU, handle unavailability events for a relay WTRU and a remote WTRU, and / or how cooperation may be maintained between a connected relay WTRU and a remote WTRU.

[0110] A WTRU may be configured (e.g., by a network) to use a (e.g., strict periodic) registration duration (e.g., timer) function. As described above, the strict periodic registration timer function may be configured such that the WTRU is available to receive downlink data at predictable times when the WTRU is in the CM connection mode. This function may be useful, for example, for devices that use the MICO mode and / or enter a long sleep duration to conserve power. The opportunities for these devices (e.g., WTRUs) to be available for downlink data may be very rare (e.g., hours or even days apart). If the WTRU requests an unavailability period that overlaps with when the WTRU is expected to be available for downlink data, it may cause the WTRU to miss downlink data that could be sent from a server expecting the WTRU to be available at the expected time.

[0111] Multiple parties (e.g., three parties) may be involved in performing certain events (e.g., operations) such as an OS upgrade, a silent reset in a modem, or a modem software update (also called a binary update). The multiple parties involved may include, for example, a device (e.g., a WTRU), an operator, and an application function.

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

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

[0114] Unavailable period support may be provided while the backoff duration (e.g., a timer) is running. The AMF may perform (e.g., general) NAS-level congestion control, e.g., upon detection of mobility management (e.g., 5GMM) signaling congestion. The WTRU may refrain from sending (e.g., not send, not be permitted to send) a mobility registration update message, e.g., under 5GMM signaling congestion conditions, except for one or more scenarios such as emergency services and / or high-priority services.

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

[0116] The WTRU may inform the network of the start of an inactivity period, e.g., based on the detection of an event in the WTRU that may render the WTRU inactive (e.g., make it so) for a certain (e.g., certain) period of time. The WTRU may inform the network of the start of the inactivity period via a registration request message (e.g., including the inactivity period IE) if the WTRU is able to save the MM (e.g., 5GMM) context and the SM (e.g., 5GSM) context. However, the WTRU may refrain from (e.g., not be able to) informing the network (e.g., the AMF) of the inactivity of the WTRU in one or more scenarios. For example, the WTRU refrains from triggering UL NAS signaling for sending a mobility registration update when NAS-level congestion control is active (e.g., when it is active).

[0117] The WTRU may refrain from (e.g., not perform) an action that makes the WTRU unavailable without informing the network. The network may initiate signaling for the WTRU and may find, for example, that the WTRU does not respond if it is not aware of the network. The WTRU may not respond, for example, because it may be performing an action that makes it unavailable (e.g., a software upgrade).

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

[0119] While NAS level congestion control is active (e.g., while a duration or timer is in progress, e.g., while T3346 is in progress), the WTRU may be allowed to send (e.g., send) a registration request message (e.g., including an unavailable period IE). The WTRU may be configured (e.g., restricted) to prevent or avoid (e.g., limited to ensuring that the registration request message does not include) subsequent requests, uplink data status IEs, and / or permitted PDU session status IEs. The WTRU may be further configured (e.g., restricted) to request an unavailable period duration (e.g., only) that is greater than the amount of time remaining in the NAS backoff duration (e.g., a timer, e.g., T3346).

[0120] Based on receiving a registration request that includes an inactivity period request (e.g., while the back-off timer is running), the AMF may respond to the WTRU with information (e.g., a registration acceptance message) that includes one or more of the following: (i) an indication that the registration and inactivity period have been accepted; (ii) an indication that a previously provided back-off duration (e.g., a timer, e.g., T3346) may continue to run and need not be reset, e.g., the WTRU may still be considered to have active NAS-level congestion control; (iii) a new back-off duration (e.g., a timer) value (e.g., T3346) indicating that the WTRU may still be considered to have active NAS-level congestion control; (iv) an indication that the WTRU may notify the AMF when it becomes available again, even if the back-off duration (e.g., a timer) (e.g., T3346) is running; and / or (v) an indication that the WTRU need not notify the AMF when it becomes available again if the back-off duration (e.g., a timer) (e.g., T3346) is running.

[0121] The foregoing exemplary indications in the registration acceptance message may give the AMF control over whether the WTRU generates additional signaling when it becomes available again. Figure 2 shows an exemplary procedure for the WTRU to signal an inactivity period and the AMF to limit the amount of NAS signaling (e.g., still).

[0122] Figure 2 illustrates an example of an unavailable event while NAS level congestion control can be active. As shown in Figure 2, at 210, NAS level congestion control can be active for the WTRU, for example, because the WTRU has received a rejection response from the AMF. The rejection response may include a duration (e.g., a timer, e.g., the T3346 timer). NAS level congestion control can be active at the WTRU. The duration (e.g., or another duration) can be in progress (e.g., T3346 and / or another backoff timer can be in progress). The WTRU can refrain from triggering NAS level signaling (e.g., not trigger, be prohibited from triggering) except, for example, for high priority access, emergency services, and / or when it means that the WTRU responds to paging from the network side.

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

[0124] At 230 in Figure 2, the WTRU can trigger a registration request procedure towards the AMF. The WTRU can provide an unavailable period IE to inform the network about the unavailable duration of the WTRU. The WTRU (e.g., when a backoff timer is in progress at the WTRU) can set the unavailable period to the duration determined at 220 (e.g., decide to set) if, for example, the duration is greater than the amount of time remaining in the backoff duration (e.g., a timer such as T3346). Otherwise, the WTRU can request (e.g., decide to request) a time that is greater than or equal to the amount of time remaining in the backoff duration (e.g., the timer).

[0125] In 240 of FIG. 2, the AMF may refrain from (e.g., without) rejecting the registration request taking into account the presence of the inactivity period IE, and / or may respond with a registration acceptance message. The AMF may use the registration acceptance message to indicate that the previously provided backoff duration (e.g., a timer, e.g., T3346) may continue to run and not be reset, and may indicate to the WTRU that it may be considered that NAS-level congestion control is still active for the WTRU, provide a new backoff duration (e.g., a timer) value (e.g., T3346), and / or may provide an indication as to whether the WTRU may notify the AMF when the WTRU becomes available again even if, for example, the backoff duration (e.g., a timer) is running.

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

[0127] In 260 of FIG. 2, for example, when the back-off duration (e.g., timer) is no longer running, or when the WTRU becomes available again and the AMF indicates in 240 that the WTRU may notify the AMF of the execution (e.g., successful execution) of the WTRU's unavailability event, the WTRU may notify the AMF of the execution (e.g., successful execution) of the WTRU's unavailability event. For example, the WTRU may refrain from (e.g., not) including the unavailability period IE, and may notify the AMF of the execution (e.g., successful execution) of the WTRU's unavailability event, for example, by sending a registration request message. The WTRU waits until the back-off duration (e.g., timer) expires, and then, for example, when the back-off duration (e.g., timer) is running, or when the back-off duration (e.g., timer) is running and the AMF indicates in 240 that the WTRU may refrain from (e.g., not) notifying the AMF when the WTRU becomes available again, the WTRU may notify the AMF of the execution (e.g., successful execution) of the WTRU's unavailability event. The WTRU waits until the back-off duration (e.g., timer) expires, and then, for example, refrains from (e.g., not) including the unavailability period IE, and may notify the AMF of the execution (e.g., successful execution) of the WTRU's unavailability event, for example, by sending a registration request message.

[0128] Referring to FIG. 2, further exemplary procedures are provided for the case when the back-off duration (e.g., timer) is running. The WTRU may perform one or more of the following.

[0129] As shown in FIG. 2, in 210, the WTRU may receive a NAS rejection message indicating that the WTRU is restricted due to congestion in the network. The NAS rejection message may include a duration (e.g., timer value) indicating how long the WTRU may consider the congestion situation applicable and / or how long the restriction may be applicable. The WTRU may start tracking the back-off duration (e.g., back-off timer), for example, based on receiving the duration (e.g., timer value).

[0130] As shown in Figure 2, at 220, the WTRU may detect a need to perform, at the WTRU, an event that may disable the WTRU for a certain (e.g., a particular) period of time. The WTRU may detect an amount of time that the WTRU is expected to become available.

[0131] As shown in Figure 2, at 230, the WTRU may send a registration request to the network. The registration request may include a WTRU inactivity duration. The WTRU inactivity duration may be set to a value greater than or equal to a backoff duration (e.g., a timer value) based on, for example, the ongoing backoff duration (e.g., a timer) and / or a backoff duration (e.g., a timer) value that is greater than the amount of time that the WTRU is expected to become available.

[0132] As shown in FIG. 2, at 240, the WTRU may 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, e.g., T3346) may continue to run and not be reset, which may cause or trigger the WTRU to continue to apply NAS level congestion control. The registration acceptance message may include a different (e.g., new) backoff duration (e.g., a timer) value (e.g., T3346) indicating to the WTRU that it is still active in NAS level congestion control, which may cause or trigger the WTRU to continue to apply NAS level congestion control and / or assign a different (e.g., new) value to the backoff duration (e.g., a timer). The registration acceptance message may include an indication that, for example, even if a backoff duration (e.g., a timer) (e.g., T3346) is running, the WTRU may notify the AMF when it becomes available again, which may cause or trigger the WTRU to send a registration update request to the network when an unavailable event ends. The registration update request may or may not include an unavailable period duration (e.g., not include it). The registration acceptance message may include an indication that, for example, when a backoff duration (e.g., a timer) (e.g., T3346) is running, the WTRU may or may not notify the AMF when it becomes available again, which may cause or trigger the WTRU not to send a registration update request to the network when an unavailable event ends while the backoff duration (e.g., a timer) is still running. The WTRU may send (e.g., decide to send) a registration update request to the network when the backoff duration (e.g., a timer) expires. The registration update request may or may not include an unavailable period duration (e.g., not include it).

[0133] During the period when the WTRU is registered to non-3GPP access only (for example), unavailable period support may be provided. The network (e.g., 5G system) may enable (e.g., indicate) the WTRU to send a registration request to the AMF via non-3GPP access. The registration request may include unavailable information (e.g., unavailable period duration information element (IE)).

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

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

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

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

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

[0139] The AMF may consider that the WTRU is deregistered (e.g., in the 5GMM deregistered state) if, for example, the duration (e.g., the standby timer) expires before the AMF receives an initial NAS message from the WTRU.

[0140] Figure 3 illustrates an example when the inactivity period function is used by a WTRU registered via non-3GPP access. For example, Figure 3 shows the support of the inactivity period function when a WTRU can be registered to a network (e.g., 5GCN) via non-3GPP access (e.g., only).

[0141] As shown in Figure 3, at 310, the WTRU can be registered to the 5GCN via non-3GPP access (e.g., only). The non-3GPP access may or may not be trusted.

[0142] At 320, an event that may render the WTRU inactive for a certain (e.g., a specific) period may occur at the WTRU.

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

[0144] At 340, the AMF may start tracking the duration (e.g., the standby timer). The AMF may first set the duration (e.g., the standby timer) value to be greater than or equal to the inactivity period duration.

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

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

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

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

[0149] Inactivity period support may be provided for MUSIM devices. Inactivity adjustment may be provided across the network.

[0150] A WTRU may be registered with multiple (e.g., two) networks. The WTRU may send a registration request to a first network (e.g., among the multiple networks). The registration request may include an inactivity duration. The first network may respond with a registration acceptance message and / or a periodic registration duration (e.g., a timer) that may be greater than or equal to the requested inactivity duration. The WTRU may then (e.g., next) send the registration request to a second network. The WTRU may include a second inactivity duration in the request to the second network. The WTRU may set (e.g., select) the second inactivity duration to a value that is greater than the periodic registration timer received from the first network. This technique may help ensure that the second network does not (e.g., refrains from) indicating to the WTRU that the WTRU may re-register well before (e.g., significantly before) the time associated with (e.g., requested by) the first network.

[0151] Figure 4 shows an example of how a WTRU may use the inactivity function in a scenario where the MUSIM function is also used.

[0152] Figure 4 illustrates an exemplary procedure for inactivity adjustment across networks.

[0153] As shown in Figure 4, at 410, a MUSIM WTRU may be registered with multiple (e.g., two) networks.

[0154] At 420, the WTRU may detect that it needs to execute an event that may be associated with (e.g., request that) the WTRU be inactive for a period of time. The WTRU may determine a first inactivity duration.

[0155] At 430, the WTRU may send a registration request to the first network. The registration request may include a first inactivity duration.

[0156] At 440, the AMF of the first network may send a registration response to the WTRU. The registration response may include a periodic registration duration (e.g., a timer) that may be greater than or equal to the first inactivity duration.

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

[0158] At 460, the WTRU may send a registration request to the second network. The registration request may include the second inactivity duration.

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

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

[0161] FIG. 5 illustrates an example of unavailability adjustment across multiple networks when multiple networks (e.g., both 5G networks) support an unavailability function.

[0162] As shown in FIG. 5, at 510, a MUSIM device having two active USIM cards may successfully register with two different (e.g., 5G) networks (e.g., AMF-1 and AMF-2) that support the unavailability function.

[0163] At 520, an event that may render the WTRU unavailable for a certain (e.g., a particular) period of time may occur at the WTRU. The WTRU (e.g., as a MUSIM device) may communicate sequentially with the network (e.g., 5GS). The MUSIM WTRU may take into account delays regarding the registration (deregistration) procedure.

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

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

[0166] At 550, the MUSIM WTRU may send a registration request to a second AMF, e.g., AMF-2, as the last instance to be informed about unavailability. The delay start may be set to 0, e.g., Δt = 0.

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

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

[0169] At 580, the MUSIM WTRU may send a registration request message to AMF-2 (e.g., refraining from including the unavailability duration IE (e.g., not including it)), informing the network that the MUSIM WTRU is available (e.g., here). There may be a sequence to come out of unavailability. For example, the network last notified about the unavailability period may be the first network to be notified about availability. In an exemplary scenario, higher priority may be given to AMF-2 than to AMF-1 to inform about the availability of the WTRU. The delay start provided to AMF-1 may take into account the delay related to informing other networks about unavailability, and the availability and / or corresponding procedure timing may follow later.

[0170] At 590, the MUSIM WTRU may send a registration request message to AMF-1 (e.g., not including the unavailability duration IE), informing the network that the MUSIM WTRU is available (e.g., here).

[0171] Referring to FIG. 5, an example is provided where a plurality of (e.g., both or all) networks may support the inaccessibility period function. The MUSIM WTRU may perform one or more of the following.

[0172] As shown in FIG. 5, at 510 - 520, a MUSIM device (e.g., a WTRU) having two active USIM cards may register (e.g., successfully register) with two different (e.g., 5G) networks that support the inaccessibility function, e.g., AMF - 1 and AMF - 2. An event that may render the WTRU inaccessible for a certain (e.g., a particular) period may occur at the WTRU. The WTRU (e.g., as a MUSIM device) may communicate sequentially with the network (e.g., 5GS). The MUSIM WTRU may take into account the delay regarding the registration (deregistration) procedure.

[0173] As shown in FIG. 5, at 530 / 540, the MUSIM WTRU may select (choose) the first network (e.g., AMF - 1) and send a registration request message that may include an inaccessibility period duration IE) and / or a start delay Δt. The delay start (Δt) may inform the network AMF - 1 that the inaccessibility period may consider a delay having the provided delay start duration value. The actual duration for which the WTRU may be inaccessible may be the inaccessibility period duration + Δt. The delay start may be calculated, for example, by taking into account the number of pending registration (deregistration) procedures that the MUSIM WTRU may perform (e.g., needs to perform) to inform other networks that it is inaccessible.

[0174] In the example shown in FIG. 5, for example, Δt can be determined as Δt = (N = 1) × (time required (e.g., needed) for registration (deregistration) to notify unavailability to AMF-2 + registration to notify the network (AMF-2) about the end of the unavailable period), where N can be the number of registrations (deregistrations) that the MUSIM can perform (e.g., needs to perform). In the exemplary scenario shown in FIG. 5, there may be another registration event to notify AMF-2 about the unavailable period.

[0175] The time associated with registration (deregistration) (e.g., required for registration (deregistration)) can take into account best and / or worst possible cases, such as retransmission timers / counters, retry timers / counters, etc. Deregistration as power-down can take into account the duration for which the WTRU can wait for a response from the network (e.g., timer duration). The MUSIM WTRU can consider deregistration (e.g., implicit deregistration) if there is no response from the network, for example. AMF-1 can release the RRC signaling connection (e.g., thereafter) if AMF-1 responds with a registration acceptance message, for example.

[0176] As shown in FIG. 5, at 550 / 560, the MUSIM WTRU can send a registration request to a second AMF (e.g., AMF-2) as the last instance to be informed about unavailability. The delay start can be set to 0, e.g., Δt = 0. AMF-2 can respond with a registration acceptance message. AMF-2 can release the connection (e.g., RRC signaling connection) (e.g., thereafter).

[0177] As shown in Figure 5, at 570 / 580 / 590, the WTRU may execute (e.g., successfully execute) an event that makes the WTRU unavailable, such as a silent reset in the modem, a security patch update, an OS upgrade, a modem SW update, and / or a device reboot upon a modem configuration change via OMA-DM. The MUSIM WTRU may send a registration request message (e.g., not including an unavailable duration IE) to AMF-2, and may inform the network that the MUSIM WTRU is available (e.g., here). There may be a sequence to come out of the unavailable state. For example, the network that was last notified about the unavailable duration may be the first network to be notified about the availability. For example, as shown in Figure 5, higher priority than AMF-1 may be given to AMF-2 to inform about the availability of the WTRU. The delay start provided to AMF-1 takes into account the delay related to informing other networks about the unavailability, and for example, the availability and the corresponding procedure timing may follow later. The MUSIM WTRU may send a registration request message (e.g., not including an unavailable duration IE) to AMF-1, and may inform the network that the MUSIM WTRU is available (e.g., here).

[0178] In some examples, one of the networks may not support the unavailable duration function.

[0179] Figure 6 illustrates an example of unavailable adjustment across multiple networks when one of the networks does not support the unavailable function of the MUSIM WTRU.

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

[0181] At 620, an event that may render the WTRU inoperable over a certain (e.g., a particular) period of time may occur at the WTRU. The WTRU (as a MUSIM device) may communicate sequentially with the network (e.g., 5GS). The MUSIM WTRU may take into account the delay regarding the registration (deregistration) procedure.

[0182] At 630, the MUSIM WTRU may select / choose a first network (e.g., AMF-1) to which it should send a registration request message that includes, for example, an inoperable period duration IE and / or a start delay Δt. The delay start (Δt) may inform the network AMF-1 that the inoperable period may take into account a delay with the provided delay start duration value. The actual duration for which the WTRU may be inoperable may be the inoperable period duration + Δt. The delay start Δt may be calculated, for example, by taking into account the number of pending registration (deregistration) procedures that the MUSIM WTRU may execute (e.g., needs to execute) to inform other networks that it is inoperable. For example, as shown in Figure 6, other networks may not support the inoperability feature (e.g., EPS or 5GS where the feature is not supported). The delay start may take into account the duration associated with (e.g., for) deregistering the WTRU from other networks.

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

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

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

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

[0187] At 660, the WTRU may execute (e.g., successfully execute) a device reboot when an event that makes the WTRU unavailable occurs, such as a silent reset in the modem, a security patch update, an OS upgrade, a modem SW update, and / or a modem setting change via OMA-DM.

[0188] At 670, the MUSIM WTRU may send a registration request message (e.g., refraining from including, e.g., the inactivity duration IE) to AMF-2, and the MUSIM WTRU may inform the network that it is available (e.g., here). There may be a sequence to come out of inactivity. For example, the network that was last notified about the inactivity period may be the first network to be notified about availability. For example, as shown in FIG. 5, higher priority than AMF-1 may be given to AMF-2 / MME to inform about the availability of the WTRU. The delay start provided to AMF-1 takes into account the delay related to informing other networks about inactivity. For example, availability and the corresponding procedure timing may follow later.

[0189] At 680, the MUSIM WTRU may send a registration request message (e.g., not including the inactivity duration IE) to AMF-1, which may inform the network that the MUSIM WTRU is available (e.g., here).

[0190] Referring to FIG. 6, a further exemplary procedure is provided where one of the networks may not support the inactivity period function. The MUSIM WTRU may perform one or more of the following.

[0191] As shown in FIG. 6, at 610 - 620, the MUSIM device (e.g., WTRU) may have two active USIM cards. The MUSIM WTRU may successfully register with two different networks, e.g., AMF-1 and AMF-2 / MME. In an exemplary scenario, the second network may be an EPS that does not support the inactivity function, or a 5G network (e.g., AMF) that does not support the inactivity function. An event that may make the WTRU inactive over a certain period may occur at the WTRU. The WTRU (e.g., as a MUSIM device) may communicate with 5GS (e.g., sequentially). The MUSIM WTRU may take into account the delay regarding the registration (deregistration) procedure.

[0192] As shown in Figure 6, at 630 / 640, the MUSIM WTRU may select a first network, e.g., AMF-1, and send a registration request message including, e.g., an inavailability duration IE and / or a start delay Δt. The start delay (Δt) may inform the network AMF-1 that the inavailability period may consider a delay having the provided start delay duration value. The actual duration for which the WTRU may be unavailable may be calculated as the inavailability duration + Δt. The start delay Δt may be calculated, for example, by taking into account the number of pending registration (deregistration) procedures that the MUSIM WTRU may perform (e.g., needs to perform) to inform other networks of its unavailability. For example, as shown in Figure 6, other networks do not support the inavailability function (e.g., EPS or 5GS where the function is not supported). The start delay may take into account the duration it may take to deregister the MUSIM WTRU from other networks. AMF-1 may respond with a registration acceptance message. AMF-1 may release the connection (e.g., RRC signaling connection) (e.g., afterwards).

[0193] As shown in Figure 6, at 650, a second network (e.g., AMF-2 / MME) may not support the function. The WTRU may trigger deregistration towards the network, for example, by sending a deregistration request message having a cause code as power down.

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

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

[0196] As shown in Figure 6, at 660 / 670 / 680, the WTRU may execute (e.g., successfully execute) an event that makes the WTRU unavailable, such as a silent reset in the modem, a security patch update, an OS upgrade, a modem SW update, and / or a device reboot during a modem configuration change via OMA-DM. The MUSIM WTRU may send a registration request message (e.g., without including an unavailable duration IE) to AMF-2, and may inform the network that the MUSIM WTRU is available (e.g., here). There may be a sequence to come out of the unavailable state. For example, the network that was last notified about the unavailable duration may be the first network to be notified about the availability. For example, as shown in Figure 6, higher priority than AMF-1 may be given to AMF-2 / MME to inform about the availability of the WTRU. The delay start provided to AMF-1 takes into account the delay related to informing other networks about the unavailability. For example, the availability and the corresponding procedure timing may follow later. The MUSIM WTRU may send a registration request message (e.g., without including an unavailable duration IE) to AMF-1, and may inform the network that the MUSIM WTRU is available (e.g., here).

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

[0198] A WTRU that can operate in S1 mode and N1 mode may detect that an event that may make the WTRU unavailable for a period of time needs to be executed. For example, the WTRU may be unreachable, and / or while the WTRU is executing an event and is unavailable, the WTRU may send (e.g., decide to send) the unavailable period duration to the AMF so that the AMF may know that the context of the WTRU should be maintained by the network (e.g., 5GS).

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

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

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

[0202] The AMF may send a registration response to the WTRU, for example, based on (e.g., at that time) sending a notification to the MME and receiving a response from the MME. The registration response may include, for example, one or more of the following indications, namely, an indication that the unavailable period is shared with the MME, and / or an indication that the WTRU can perform a tracking area update with the MME when the unavailable event can be completed, an indication that the unavailable period is rejected by the MME, and / or an indication that the WTRU can be considered to be deregistered from the EPS, e.g., transitioning from the EMM registered state to the EMM deregistered state, and / or a value (e.g., a new value) that the WTRU can assign to its EPS periodic tracking area update duration (e.g., timer) value.

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

[0204] Advantages provided by unavailable support for devices registered on multiple networks (e.g., EPC and 5GC) may include, for example, the following, namely, that EPS NAS signaling may be able to refrain from changes (e.g., there is no need to change), that the EPS context may be maintained while the WTRU is in an unavailable period, and / or that the WTRU may be able to determine (e.g., recognize) whether the MME is unable to maintain the EPS context or has no intention of maintaining the EPS context while the WTRU is in an unavailable period, among one or more of these.

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

[0206] As shown in Figure 7, at 710, the WTRU is 5GMM and EMM active. The WTRU may operate in a single registration mode. The WTRU may maintain a (e.g., one) common registration for 5GMM for 3GPP access and EMM. The WTRU may succeed in updating in both 5GMM and EMM (e.g., the S1 mode registration status is an EMM registration and the N1 mode registration status is a 5GMM registration). The WTRU may currently camp on a 5G cell in idle mode. 5GS or EPS may indicate support for interworking with N26 as part of a 5GS network function support IE or an EPS network function support IE with a WK N26 bit set to "interworking without an unsupported N26 interface" (e.g., in the last registration procedure).

[0207] At 720, an event that may render the WTRU unavailable for a certain (e.g., a particular) period of time may occur at the WTRU.

[0208] At 730, the WTRU may trigger a registration request procedure towards the AMF. The WTRU may provide an unavailable period IE to inform the network about the WTRU's unavailable duration.

[0209] At 740, the AMF can send a notification to the MME, for example, via the N26 interface. The notification can indicate to the MME that the WTRU is unavailable (e.g., likely to become unavailable) for a certain period of time. The notification can include the unavailable period duration or the periodic registration time that the AMF can send to the WTRU in the registration response. The MME can recognize, for example, the time when the WTRU is expected to be unavailable based on the unavailable period duration or the periodic registration time in the notification.

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

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

[0212] For example, the MME can respond to the AMF using an indication that the MME does not agree to maintain the WTRU context while the WTRU is unavailable, that the WTRU can consider itself to be deregistered from the EPS when the WTRU is deregistered, and / or that the WTRU can transition (e.g., may transition) from the EMM registration state to the EMM deregistration state. The response from the MME can further include a (e.g., new) periodic tracking area update duration (e.g., timer) value for the AMF to send to the WTRU.

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

[0214] At 770, the AMF may provide a registration acceptance to the WTRU. The registration response may include one or more of the following instructions, namely, an instruction that the non-availability period is shared with the MME, an instruction that the WTRU may perform a tracking area update with the MME when a non-availability event is completed, and / or an instruction that the EMM state may be an EMM registration, an instruction that the non-availability period has been rejected by the MME, an instruction that the WTRU may consider itself to be deregistered from the EPS, and / or an instruction that the WTRU may transition from an EMM registration state to an EMM deregistration state, and / or a new value that the WTRU may assign to its EPS periodic tracking area update timer value.

[0215] At 780, the WTRU may execute (e.g., successfully execute) an event that makes the WTRU unavailable, such as a silent reset in the modem, a security patch update, an OS upgrade, a modem SW update, and / or a device reboot when changing the modem settings via OMA-DM.

[0216] At 790, a WTRU emerging from a non-availability period may execute a registration procedure with the AMF, for example, without including a non-availability period IE.

[0217] At 795, the WTRU may trigger an EMM tracking area update procedure (e.g., when the EMM state is an EMM registration) or an EMM attach procedure (e.g., when the EMM state is an EMM deregistration) (e.g., according to the results and responses received by the WTRU from the MME via the AMF) to indicate to the MME that the non-availability period has ended and the WTRU is reachable again.

[0218] Analysis (e.g., NWDAF) can be supported for the Unavailability Period function. The Namf_EventExposure service of the AMF can support an NF invoker (e.g., NWDAF) subscribing to an event (e.g., WTRU Unavailability Event). The AMF can report WTRU unavailability information to the NF invoker when the event occurs. The WTRU unavailability information may include one or more of the following, namely, a WTRU identifier, unavailability time information for each (e.g., each) WTRU identifier, and / or an indication of an expected action such as when each WTRU becomes available.

[0219] The AMF can provide WTRU unavailability information when the invoker NF subscribes to or invokes the Namf_EventExposure subscribe service operation (e.g., when subscribing to or invoking the Namf_EventExposure subscribe service operation), for example, providing one or more of the following, namely, a registration status report, a connection status report, a reachability report, an in-area UE report, a 5GS user status report, a frequency mobility registration report, a UE access behavior trend, and / or a UE-MM transaction report (e.g., equivalent thereto) as an event ID. Additionally and / or alternatively, an event ID (e.g., a new event ID) can be defined (e.g., for WTRU unavailability information). The AMF can provide WTRU unavailability information when the invoker NF subscribes to or invokes the Namf_EventExposure subscribe service operation and provides an event ID (e.g., equivalent to "WTRU unavailability information") (e.g., when providing it).

[0220] The unavailable time information provided by the AMF to the invoking NF of the WTRU can be, for example, one or more of the following: equal to, for example, the unavailable period duration requested by the WTRU; set to an absolute time value based on the unavailable period duration requested by the WTRU; set to a value indicating how much time is expected or required to elapse until the unavailable time expires; and / or set equal to the periodic registration duration (e.g., a timer) value provided by the AMF to the WTRU.

[0221] The indication of the expected action when the WTRU becomes available can indicate that the WTRU performs (e.g., is expected to perform) a mobility registration when the unavailable period ends (e.g., at the end), or can indicate that the WTRU performs (e.g., is expected to perform) an initial registration when the unavailable period ends (e.g., at the end).

[0222] The AMF can indicate that the WTRU performs (e.g., is expected to perform) a mobility registration when the unavailable period ends (e.g., at the end), for example, if the WTRU provided the unavailable period duration in a mobility registration request.

[0223] The AMF can indicate that the WTRU performs (e.g., is expected to perform) an initial registration when the unavailable period ends (e.g., at the end), for example, if the WTRU provided the unavailable period duration in a deregistration request.

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

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

[0226] Figure 8 illustrates an example of using unavailability information to generate improved data analysis.

[0227] As shown in Figure 8, 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 the NWDAF). The type of service invocation can be a request or a subscribe operation. The type of analysis requested can be, for example, one or more of the following: network slice instance load level statistics and predictions, network slice load level statistics and predictions, network function load level statistics and predictions, network load level statistics and predictions, WTRU communication statistics and predictions, and / or sixth WTRU abnormal behavior statistics and predictions.

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

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

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

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

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

[0233] The inoperable period function may be supported for the relay WTRU. The relay WTRU may enter the inoperable period.

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

[0235] In some examples, the remote WTRU and the relay WTRU may be connected (e.g., via a PC5 connection). One or the other of the relay WTRU or the remote WTRU may become inoperable due to an inoperable event.

[0236] FIG. 9 illustrates an example of a relay WTRU entering the inoperable period.

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

[0238] At 910, an inoperable event may be triggered at the relay WTRU, which may render the relay WTRU inoperable for a certain (e.g., a specific) period.

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

[0240] At 930, a list of remote WTRU information can be passed by the AMF to the AF for a connection loss event (e.g., if the AF has registered for connection loss events for each remote WTRU).

[0241] At 940, the AMF may respond with a registration response providing a list of remote WTRUs, e.g., to confirm the status of receipt of the list.

[0242] At 950, the relay WTRU may inform the connected remote WTRU of its unavailability, e.g., along with an inactivity duration.

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

[0244] The remote WTRU may enter an inactivity period.

[0245] Figure 10 illustrates an example of a remote WTRU entering an inactivity period.

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

[0247] At 1010, an inactivity event that may render the remote WTRU unavailable for a certain (e.g., a particular) period may be triggered at the remote WTRU.

[0248] At 1020, the remote WTRU may trigger unavailability, for example, by informing the AMF / AF about unavailability events via, for example, a relay WTRU.

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

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

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

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

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

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

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

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

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

[0258] The registration acceptance message may indicate that the strict periodic registration duration (e.g., timer) function is enabled and that the inactivity duration was not accepted. The WTRU may wait to request the inactivity duration again until the registration duration (e.g., timer) expires (e.g., in response to the registration acceptance message), send a registration request based on the expiration of the registration duration (e.g., timer), and enter the CM idle state when the active duration (e.g., timer) is not running. By waiting until these conditions are met, it can be ensured that the expected available time of the WTRU has ended (e.g., just elapsed). This technique may be useful, for example, when the WTRU requests an inactivity duration when the strict periodic registration time is near expiration.

[0259] The registration acceptance message may indicate that the strict periodic registration timer function is not enabled and that an unavailable period has not been accepted. The WTRU may wait (e.g., in response to the registration acceptance message) for the WTRU to enter the CM idle state and for the active duration (e.g., timer) to expire before requesting the unavailable period duration again. By waiting until these conditions are met, it can be ensured that the expected available time of the WTRU has ended (e.g., just elapsed).

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

[0261] The registration acceptance message may indicate that the MICO mode is not enabled and that an unavailable period has not been accepted. The WTRU may track (e.g., configure a timer) the duration with an unavailable period (e.g., in response to the registration acceptance message) and refrain from (e.g., not) requesting the unavailable period again until the wait duration (e.g., timer) expires and the WTRU enters the CM idle state.

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

[0263] FIG. 11 illustrates an example of the logic for WTRU processing of unavailable period rejection. FIG. 11 shows an example of how to consider the expected WTRU availability when an unavailable period is requested.

[0264] As shown in FIG. 11, the WTRU may send a registration request that includes an inactivity duration (e.g., when the MICO mode and the strict periodic registration duration / timer function are enabled). The WTRU may receive a registration acceptance message, which may indicate that the MICO mode is enabled, that the strict periodic registration timer function is enabled, and that the inactivity duration is not permitted. The WTRU may determine to send a second registration request that includes a second inactivity duration, provided that the periodic registration duration (e.g., a timer) has expired, the WTRU has entered the CM idle state, and the active duration (e.g., a timer) is not running. The WTRU may send a second registration request that may include a second inactivity duration.

[0265] As shown in FIG. 11, the WTRU may send a registration request that includes an inactivity duration (e.g., when the MICO mode and the strict periodic registration timer function are not enabled). The WTRU may receive a registration acceptance message, which may indicate that the MICO mode is enabled, that the strict periodic registration duration (e.g., a timer) function is not enabled, and that the inactivity duration is not permitted. The WTRU may determine to send a second registration request that includes a second inactivity duration, provided that, for example, the WTRU has entered the CM idle state and the active duration (e.g., a timer) is not running. The WTRU may send a second registration request that, for example, includes a second inactivity duration.

[0266] As shown in FIG. 11, the WTRU may send a registration request that may include an inactivity period duration (e.g., when the MICO mode is not enabled). The WTRU may receive a registration acceptance message that refrains from indicating (e.g., does not indicate) that the MICO mode is enabled and that the inactivity period duration is not permitted. The WTRU may start tracking by configuring a duration with the inactivity period duration (e.g., starting a timer). The WTRU may determine to send a second registration request that includes a second inactivity period duration, on the condition that the duration (e.g., the timer) is not running and that the WTRU has entered the CM idle state. The WTRU may send a second registration request that includes a second inactivity period duration.

[0267] The features and elements described above have been described in a particular combination, but each feature or element may be used alone without the other features and elements of the preferred embodiments, or may be used in various combinations with or without other features and elements.

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

[0269] The processes described above may be implemented by a computer program, software, and / or firmware incorporated into a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via a wired connection and / or a wireless connection) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM disks and / or digital versatile disk (DVD), among others. A processor associated with the software may be used to implement a radio frequency transceiver for use in a WTRU, a terminal, a base station, an RNC, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: a processor, wherein the processor is configured to: send a first registration request indicating a first unavailable duration associated with an unavailable period to a first network; receive a first registration response indicating a first registration duration from the first network; determine a second unavailable duration based on the first unavailable duration; send a second registration request indicating the second unavailable duration to a second network; and receive a second registration response indicating a second registration duration from the second network,

2. The WTRU according to claim 1, wherein the WTRU is a multi-universal subscriber identity module (MUSIM) device.

3. The processor is configured to: determine that the WTRU will be unavailable for a period of time, and the first unavailable duration is determined based on the determination that the WTRU will be unavailable for a period of time,

4. The processor is further configured to: determine that an unavailable event is triggered, and the determination that the WTRU will be unavailable for a period of time is based on the determination that the unavailable event is triggered,

5. The WTRU according to any one of claims 1 to 4, wherein the first registration duration is greater than or equal to the first unavailable duration, and the second registration duration is greater than or equal to the second unavailable duration.

6. The WTRU according to claim 5, wherein the second unavailable duration is greater than or equal to the first registration duration.

7. The first registration request further indicates enabling an unavailable period function with the first network, and the second registration request further indicates enabling the unavailable period function with the second network,

8. The WTRU according to any one of claims 1 to 7, wherein the first registration response is a first registration acceptance message, and the second registration response is a second registration acceptance message.

9. A method, comprising: Sending a first registration request indicating a first unavailable duration associated with an unavailable period to a first network; Receiving a first registration response indicating a first registration duration from the first network; Determining a second unavailable duration based on the first unavailable duration; Sending a second registration request indicating the second unavailable duration to a second network; Receiving a second registration response indicating a second registration duration from the second network, the method comprising.

10. The method according to claim 9, wherein the method relates to a multi-universal subscriber identity module (MUSIM) device.

11. The method further includes Determining that the WTRU will be unavailable for a period of time, wherein the first unavailable duration is determined based on the determination that the WTRU will be unavailable for a period of time, the method according to claim 9 or 10.

12. The method further includes Determining that an unavailable event is triggered, wherein the determination that the WTRU will be unavailable for a period of time is based on the determination that the unavailable event is triggered, the method according to claim 11.

13. The method according to any one of claims 9 to 12, wherein the first registration duration is greater than or equal to the first unavailable duration, and the second registration duration is greater than or equal to the second unavailable duration.

14. The method according to claim 13, wherein the second unavailable duration is greater than or equal to the first registration duration.

15. The method according to any one of claims 9 to 14, wherein the first registration request further indicates enabling an unavailable period function with the first network, and the second registration request further indicates enabling the unavailable period function with the second network.

16. The method according to any one of claims 9 to 15, wherein the first registration response is a first registration acceptance message, and the second registration response is a second registration acceptance message.

Images