Unavailability 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 hereby incorporated 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., only to non - 3GPP access) are described herein.

[0004] A device (e.g., a network device such as a WTRU or 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, for example, non-access stratus (NAS) signaling. The registration request may include a first duration (e.g., an unavailability duration associated with the WTRU). The device may receive a registration acceptance message, which may indicate whether the device should notify the network entity when the WTRU is available (e.g., after the unavailability event / duration has elapsed). The device may determine that the unavailability event has ended. The WTRU may decide (e.g., based on the registration acceptance message) whether to notify the network entity that the WTRU has become available. The device may send a registration renewal request, which may be sent based on the determination that the unavailability event has ended and the determination that the WTRU should notify the network entity when the WTRU becomes available. A registration renewal request may indicate that a WTRU is available.

[0005] The device may receive, for example, an instruction from the network indicating congestion. The device may receive an instruction indicating a second duration (e.g., a backoff duration associated with 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., the period of unavailability associated with the WTRU). The registration request may be associated with unavailability information. The device may decide 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 decision that the registration request is associated with unavailability 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 it will refrain from sending an update message (e.g., after the first duration) if the WTRU is associated with discontinuous coverage. The device may decide whether the WTRU is available after the first duration. The device may determine, for example, whether an update message was 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 a first duration. The WTRU may be determined to be available if the update message was 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 may be a multi-universal subscriber identity module (MUSIM) device. The device may send a first registration request to a first network. The first registration request may indicate enabling the unavailability feature with a second network. The registration request may indicate a first unavailability duration associated with the unavailability period. The device may determine that an unavailability event is triggered. The device may determine that the device (e.g., WTRU) will be unavailable for a certain period of time. The decision that the device will be unavailable for a certain period of time may be based on the decision that an unavailability event is triggered. The first unavailability duration may be determined based on the decision that the device will be unavailable for a certain period of time. The device may receive a first registration response (e.g., from the first network). The first registration response may be a first registration acceptance message. The first registration response may indicate a first registration duration. The first registration duration may be greater than or equal to the first unavailability duration. The device may determine a second unavailability period based, for example, on a first unavailability period. The device may send a second registration request to a second network. The second registration request may indicate enabling the unavailability period function with the second network. The second registration request may indicate a second unavailability period. The device may receive a second registration response from the second network. The second registration response may be a second registration acceptance message. The second registration response may indicate a second registration period. The second registration period may be greater than or equal to the second unavailability period. The second unavailability period may be greater than or equal to the first registration period.

[0008] The device may perform actions associated with duplicate enrollment. The device may receive enrollment requests (e.g., from a WTRU). Enrollment requests may indicate unavailability information. Enrollment requests may include an unavailability information element that may indicate unavailability information. Unavailability information may indicate, for example, the duration of unavailability associated with a WTRU. The device may send a notification to an entity (e.g., a mobility management entity). The notification may indicate that a WTRU will be unavailable for a certain period of time. The device may receive a notification response (e.g., from an entity). The notification response may indicate that the entity has accepted the unavailability of the WTRU. The notification response may indicate the tracking area update duration. The notification response may indicate that the entity has accepted the unavailability of the WTRU and the tracking area update duration. The device may, for example, send an enrollment acceptance message (e.g., to a WTRU) based on the notification response. The enrollment acceptance message may indicate the tracking area update duration. The registration acceptance message may, for example, instruct the WTRU to perform a tracking area update with the entity based on the completion of an unavailability 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 a period of unavailability. The registration request may include, for example, an information element indicating the first duration. The registration request may be sent over a non-3GPP access network. The device may send a registration response indicating, for example, that the first duration has been accepted. The instruction to accept the first duration may indicate the accepted duration of the unavailability period. The accepted duration of the unavailability period 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 over a 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 the determination that a second duration has elapsed. The second duration may be associated with, or equal to, the duration of the unavailability period associated with the registration request. The device may send a repost of the loss of connectivity. A loss of connectivity report may indicate a period of unavailability. A loss of connectivity report may indicate that the period of unavailability is sent to the network exposure function. The device may receive NAS messages from the WTRU. Based on the received NAS messages, the device may perform one or more actions, such as stopping tracking associated with a second duration, determining that the WTRU is reachable, or determining that the WTRU is connected. Based on the determination that the second duration has expired, the device may unregister the WTRU. [Brief explanation of the drawing]

[0010] [Figure 1A] This is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used in a communication system illustrated in Figure 1A, according to one embodiment. [Figure 1C]This is a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in a communication system illustrated in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used in the communication system illustrated in Figure 1A according to one embodiment. [Figure 2] This section illustrates an example of an unavailability event while NAS-level congestion control is active. [Figure 3] This example illustrates how the unavailability feature is used by a WTRU registered via non-3GPP access. [Figure 4] This example illustrates a network-wide unavailability adjustment. [Figure 5] This example illustrates a case of cross-network unavailability coordination when multiple networks (e.g., both 5G networks) support unavailable features. [Figure 6] This example illustrates a case of network-wide unavailability coordination when one of the networks does not support the unavailability feature of MUSIM WTRU. [Figure 7] This example illustrates a dual registration scenario where WTRU has both 5GMM and EMM contexts. [Figure 8] This example illustrates how unavailable information can be used to generate improved data analysis. [Figure 9] Let's illustrate an example of a relay WTRU entering an unavailable period. [Figure 10] This example illustrates a scenario where a remote WTRU becomes unavailable. [Figure 11] An example of logic for handling WTRU processing for unavailable period rejections is provided. [Modes for carrying out the invention]

[0011] Figure 1A illustrates an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, message transmission, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the 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 filtering OFDM, and filter bank multicarrier (FBMC).

[0012] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, 102d, any of which may be referred to as “station” and / or “STA”, may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed subscriber units or mobile subscriber units, subscriber-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other radio devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating on commercial radio networks and / or industrial radio networks, etc. WTRU102a, 102b, 102c, and 102d can all be referred to as UE for compatibility purposes.

[0013] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), node B, enode B, home node B, home enode B, gNB, NR node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0014] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), and relay nodes. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectra, unlicensed spectra, or combinations of licensed and unlicensed spectra. Cells may provide coverage of radio services to a particular geographic area that may be relatively fixed or change over time. Cells may be further divided into cell sectors. For example, a 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 per sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and utilize multiple transceivers per 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 and 114b may communicate with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, which may be any suitable radio communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The 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 RAN 104 / 113, and the WTRUs 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interfaces 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA 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 establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[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 establish the air interface 116 using New Radio (NR).

[0019] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interfaces utilized by 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, base station 114a and 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), IS-95, 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 Figure 1A may be, for example, a wireless router, home node B, home e-node B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as offices, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones, for example), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d may establish a wireless local area network (WLAN) by implementing wireless technologies such as IEEE 802.11. In one embodiment, the base station 114b and WTRU 102c, 102d may establish a wireless personal area network (WPAN) by implementing wireless technologies such as IEEE 802.15. In yet another embodiment, base stations 114b and WTRUs 102c, 102d may establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.

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

[0023] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, which 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. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN104 / 113 or a different RAT.

[0024] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode functionality (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which may employ cellular-based radio technology, and base station 114b, which may employ IEEE 802 radio 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, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the aforementioned elements while maintaining consistency with one embodiment.

[0026] The processor 118 could be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which can be coupled to a transmit / receive element 122. Figure 1B depicts the processor 118 and the transceiver 120 as separate components, but 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 and 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 radio signals.

[0028] Although the transmit / receive element 122 is depicted as a single element in Figure 1B, 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 sending and receiving radio signals via the air interface 116.

[0029] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capabilities. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0030] The processor 118 of the WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input from these. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in such memory. 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 memory not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data in that memory.

[0031] The processor 118 may be configured to receive power from the power supply 134 and 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 cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0032] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, the information from the GPS chipset 136, the WTRU 102 may determine its location based on receiving location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method while maintaining consistency with one embodiment.

[0033] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripherals 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, and the like. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0034] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference through signal processing either through hardware (e.g., chokes) or 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 any of the signals (e.g., associated with specific subframes 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 wireless technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN106.

[0036] RAN104 may include e-nodes B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of e-nodes B while maintaining consistency with one embodiment. Each of e-nodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, e-nodes B160a, 160b, and 160c may implement MIMO technology. Thus, e-node B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

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

[0038] The CN106 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 aforementioned elements is depicted as part of CN106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0039] The MME162 can be connected to each of the e-nodes B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0040] The SGW164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can also perform other functions, such as anchoring the user plane during e-node B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0041] SGW164 may be connected to PGW166, which may provide 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-enabled devices.

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

[0043] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface with a communication network (for example, temporarily or permanently).

[0044] In a typical embodiment, the other network 112 may be a WLAN.

[0045] A WLAN in Basic Service Set (BSS) mode may have access points (APs) of the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with other types of wired / wireless networks that carry traffic entering and / or leaving the Distribution System (DS) or BSS. Traffic originating outside the BSS and destined for an STA may reach and be sent to an AP. Traffic originating from an STA and destined for an outside BSS may be sent to an AP to reach its respective destination. Traffic between STAs within the BSS may be sent, for example, through an AP; a source STA may send traffic to an AP, and the AP may send traffic to a destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between a source STA and a destination STA (for example, directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with one another. The IBSS mode of communication may be referred to herein as “ad hoc” communication mode.

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

[0047] High-throughput (HT) STAs may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

[0048] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining multiple adjacent 20 MHz channels. 160 MHz channels can 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 80+80 configuration, after channel coding, the data can pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the operation described above for the 80+80 configuration may be reversed, and the combined data may be sent to Medium Access Control (MAC).

[0049] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier 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, while 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices within a macro communication range area. MTC devices may have limited performance, including support for certain performance, e.g., support for certain and / or limited bandwidths (e.g., supporting only these). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

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

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

[0052] Figure 1D is a system diagram illustrating RAN113 and CN115 according to one embodiment. As described above, RAN113 may employ NR radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN113 may also communicate with CN115.

[0053] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 108b may use beamforming to transmit signals to and / or receive signals from gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals to and from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation techniques. For example, gNB180a may transmit multiple elemental carriers to WTRU102a (not shown). A subset of these elemental carriers may be on the unlicensed spectrum, while the remaining elemental carriers may be on the licensed spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multi-point (CoMP) techniques. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0054] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable neurology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or having varying absolute time durations).

[0055] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., e-nodes B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unauthorized bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as enodes B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c and one or more enodes B160a, 160b, and 160c. In a non-standalone configuration, enodes B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0056] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, 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 and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, and so on. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

[0057] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. Although each of the aforementioned elements is depicted as part of the CN115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0058] AMF182a and 182b can be connected to one or more gNB180a, 180b, and 180c in RAN113 via the N2 interface and can function as control nodes. For example, AMF182a and 182b may perform roles such as user authentication for WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, and services for machine type communication (MTC) access. AMF162 may provide control plane functionality for exchange between RAN113 and other RANs (not shown) using other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as 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 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. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0060] UPF184a and 184b may be connected via the N3 interface to one or more gNB180a, 180b, and 180c in RAN113, 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-enabled devices. UPF184 and 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multiple home PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0061] CN115 can 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 PSTN108. In addition, CN115 may provide WTRU102a, 102b, 102c with access to another network 112, 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 the local data network (DN) 185a, 185b via UPF184a, 184b through an N3 interface to UPF184a, 184b, and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0062] As can be seen from Figures 1A to 1D and their corresponding descriptions, one or more of the functions described herein relating to one or more of the WTRU102a to d, base stations 114a and b, e-nodes B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a and b, UPF184a and b, SMF183a and b, DN185a and b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0063] Emulation devices may be designed to perform one or more tests on other devices in a laboratory and / or carrier network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless network. For testing purposes, emulation devices may be directly coupled to another device and / or perform tests using terrestrial radio communication.

[0064] One or more emulation devices may perform one or more functions, including all of the above, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory test scenario, and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing purposes), to perform testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may 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 period. References to timer expiration in this specification may refer to the determination that time has occurred or that a time period has expired. References to a timer in this specification may refer to time, time period, time tracking, time period tracking, etc. References to legacy technology or legacy handover may refer to legacy technology such as LTE compared to NR, or legacy versions of technology, for example, an earlier version / release of technology (e.g., an earlier NR release) compared to a newer version / release of technology (e.g., a later NR release). References to a specific timer in this specification may be provided as examples of timers.

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

[0067] A device (e.g., a network device such as a WTRU or a device with Access and Mobility Functions (AMF)) may perform one or more of the following actions: The device may send a registration request (e.g., to a network entity) via, for example, Non-Access Layer (NAS) signaling. The registration request may include a first duration (e.g., an unavailability 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 the unavailability event / duration has elapsed). The device may determine that the unavailability event has ended. The WTRU may decide (e.g., based on the registration acceptance message) whether to notify the network entity that the WTRU has become available. The device may send a registration renewal request. A registration renewal request may be sent based on the determination that the unavailability event has ended and the determination that the WTRU should notify the network entity when the WTRU becomes available. A registration renewal request may indicate that the WTRU is available.

[0068] The device may receive, for example, an instruction from the network indicating congestion. The device may receive an instruction indicating a second duration (e.g., a backoff duration associated with 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., the period of unavailability associated with the WTRU). The registration request may be associated with unavailability information. The device may decide 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 decision that the registration request is associated with unavailability 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 if the WTRU is associated with discontinuous coverage, it should refrain from sending an update message (e.g., after the first duration). The device may decide whether the WTRU is available after the first duration. The device may determine, for example, whether an update message was 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 a first duration. The WTRU may be determined to be available if the update message was 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 may be a Multi-Universal Subscriber Identification Module (MUSIM) device. The device may send a first registration request to a first network. The first registration request may indicate enabling the unavailability feature with a second network. The registration request may indicate a first unavailability duration associated with the unavailability period. The device may determine that an unavailability event is triggered. The device may determine that the device (e.g., WTRU) will be unavailable for a certain period of time. The decision that the device will be unavailable for a certain period of time may be based on the decision that an unavailability event is triggered. The first unavailability duration may be determined based on the decision that the device will be unavailable for a certain period of time. The device may receive a first registration response (e.g., from the first network). The first registration response may be a first registration acceptance message. The first registration response may indicate a first registration duration. The first registration duration may be greater than or equal to the first unavailability duration. The device may determine a second unavailability duration based on the first unavailability duration, for example. The device may send a second registration request to the second network. The second registration request may indicate enabling the unavailability feature with the second network. The second registration request may indicate a second unavailability duration. The device may receive a second registration response from the second network. The second registration response may be a second registration acceptance message. The second registration response may indicate a second registration duration. The second registration duration may be greater than or equal to the second unavailability duration. The second unavailability duration may be greater than or equal to the first registration duration.

[0071] The device may perform actions associated with duplicate enrollment. The device may receive enrollment requests (e.g., from a WTRU). Enrollment requests may indicate unavailability information. Enrollment requests may include an unavailability information element that may indicate unavailability information. Unavailability information may indicate, for example, the duration of unavailability associated with a WTRU. The device may send a notification to an entity (e.g., a mobility management entity). The notification may indicate that a WTRU will be unavailable for a certain period of time. The device may receive a notification response (e.g., from an entity). The notification response may indicate that the entity has accepted the unavailability of the WTRU. The notification response may indicate the tracking area update duration. The notification response may indicate that the entity has accepted the unavailability of the WTRU and the tracking area update duration. The device may, for example, send an enrollment acceptance message (e.g., to a WTRU) based on the notification response. The enrollment acceptance message may indicate the tracking area update duration. The registration acceptance message may, for example, instruct the WTRU to perform a tracking area update with the entity based on the completion of an unavailability 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 a period of unavailability. The registration request may include, for example, an information element indicating the first duration. The registration request may be sent over a non-3GPP access network. The device may send a registration response indicating, for example, that the first duration has been accepted. The instruction to accept the first duration may indicate the accepted duration of the unavailability period. The accepted duration of the unavailability period 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 over a 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 the determination that a second duration has elapsed. The second duration may be associated with, or equal to, the duration of the unavailability period associated with the registration request. The device may send a repost of the loss of connectivity. A loss of connectivity report may indicate a period of unavailability. A loss of connectivity report may indicate that the period of unavailability is sent to the network exposure function. The device may receive NAS messages from the WTRU. Based on the received NAS messages, the device may perform one or more actions, such as stopping tracking associated with a second duration, determining that the WTRU is reachable, or determining that the WTRU is connected. Based on the determination that the second duration has expired, the device may unregister the WTRU.

[0073] Systems, methods, and means related to support during periods of unavailability while a WTRU is registered for non-3GPP access (e.g., 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., is configured to perform) one or more of the following actions: The device may receive a registration request. A registration request may include, for example, unavailability information (e.g., an information element, IE) that can be sent over a non-3GPP access network. The device may decide to start tracking a duration (e.g., start a standby timer) (e.g., based on receiving a registration request over a non-3GPP access network and / or based on a request including an information element). The device may assign an initial value to the duration (e.g., a standby timer), which may be equal to the unavailability duration provided in the registration request. The device may decide to send a registration response (e.g., based on receiving a registration request over a non-3GPP access network and / or based on a request including an information element), which may include, for example, that the unavailability duration request has been accepted and network instructions. A device may indicate acceptance of an unavailable period by, for example, sending an accepted unavailable period to a wireless transmit / receive unit (WTRU). A device may assign an accepted unavailable period that is greater than or equal to the requested unavailable period. A device may determine that a WTRU is unreachable and in an idle state (e.g., 5GMM idle state) (e.g., based on receiving a registration request over a non-3GPP access network and / or based on a request that includes an unavailable period information element). A device may send a directive to a session management function (SMF) that a WTRU is unreachable (e.g., based on the fact that the WTRU is unreachable and in an idle state (e.g., 5GMM idle state)). The directive may be sent in response to a downlink data notification from the SMF.A device may trigger a network exposure function (NEF) to report a loss of connectivity event (e.g., a period of unavailability), and / or, if there is a loss of connectivity event subscription to the WTRU by an application function (AF), the period of unavailability may be reported to the subscribed AF. A device may receive an initial non-access stratum (NAS) message from the WTRU. A device may decide to stop tracking the duration (e.g., stopping the standby timer) (based on, for example, receiving the NAS initial NAS message) and consider the WTRU to be reachable and in a connected state (e.g., 5GMM connected state). A device may decide to (e.g., implicitly) unregister the WTRU based on the expiration of the duration (e.g., the expiration of the standby timer).

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

[0076] The duration value (e.g., timer) may be associated with, or equal to, the unavailability duration associated with the registration request. A registration response may be sent based on the receipt of a registration request over a non-3GPP access network and a registration request containing an unavailability duration information element. An instruction to accept an unavailability duration request may indicate an accepted unavailability duration. The accepted unavailability duration may be greater than or equal to the requested unavailability duration. A loss of connectivity report may indicate an unavailability period. A loss of connectivity report indicating an unavailability period may be sent to a network exposure function. A device (e.g., a processor) may be further configured to receive a NAS message from a WTRU and perform one or more of the following actions (e.g., based on receiving a NAS message): stop tracking duration (e.g., stopping the timer), determine that the WTRU is reachable, or determine that the WTRU is in a connected state. A device (e.g., a processor) may be further configured to implicitly deregister a WTRU based on the expiration of a timer.

[0077] This specification describes systems, methods, and means relating to mechanisms for providing periods of network unavailability. Several events, such as operating system (OS) upgrades, silent resets in modems, or modem software updates (also known as binary updates), may be performed using two or more (e.g., three) parties involved, such as a device, an operator, and an application function.

[0078] A WTRU executing a multi-party event may become unavailable (e.g., unable to interact with the 5G system) for a period of time, such as while the event is running (e.g., for a few minutes). WTRU unavailability without prior knowledge from the core network and / or application functionality can affect the (e.g., critical) operation of an application server if the application server relies on the availability of the WTRU during the unavailability period (e.g., the time the WTRU is unavailable).

[0079] Systems, methods, and means relating to handling periods of unavailability for one or more scenarios are described herein, such as when the backoff duration is active (e.g., while the timer is running), when a WTRU registers with a network (e.g., 5GS) via non-3GPP access (e.g., only) (e.g., when registering), when a Multi-Universal Subscriber Identification Module (MUSIM) device registers with multiple networks with and without support for unavailability features (e.g., when registering), when a WTRU registers with multiple networks (e.g., both evolved packet system (EPS) and fifth generation system (5GS)) (e.g., when registering), when a remote WTRU and / or relay WTRU enter an unavailability period to support analysis for unavailability features (e.g., network data analytics function, NWDAF) (e.g., when entering), and when mobile initiated connection only (MICO) mode and / or strict periodic registration timer function are enabled (e.g., when enabled).

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

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

[0082] WTRUs can download binaries. Time is left for WTRU execution to perform upgrades. Some WTRU executions may use user input (e.g., they may seek). WTRUs may delay the execution of events if they are unable to perform them (e.g., due to insufficient memory or battery level). WTRUs may become unavailable (e.g., they may not interact with the 5G system) if such operations are being performed (e.g., when they are being performed). WTRUs may become unavailable without prior knowledge from the core network and / or application functions. WTRU unavailability may have a critical impact on the operation of an application server if the application server relies on the availability of the WTRU during the unavailability period (e.g., the period during which the WTRU is unavailable).

[0083] A network (e.g., a 5G system) may enable a WTRU to provide the network with an unavailability period (e.g., unavailability duration) in, for example, a registration request or a deregistration request. A 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 the MM and SM contexts can be reused after the WTRU's unavailability period if, for example, an event is triggered in the WTRU that renders the WTRU unavailable for a specific period of time. If the WTRU can store its context, it may, for example, trigger a mobility registration renewal procedure or a deregistration procedure and provide the network with the unavailability period duration. A network (e.g., an Access and Mobility Function (AMF)) may take the unavailability period duration into consideration when determining, for example, a periodic registration renewal duration (e.g., a periodic registration renewal timer value). AMF may provide periodic registration renewal times longer than the duration of the unavailability period to avoid interfering with WTRUs that address events causing unavailability. Later (for example, when the event that would make the WTRU unavailable is completed in the WTRU, or the event is delayed to a future time, or canceled in the WTRU), the WTRU may trigger a registration procedure to resume normal service. The WTRU may refrain from including the unavailability period in its registration request message (for example, by not including it). Depending on the WTRU state, the registration procedure may be an initial registration procedure or a mobility registration renewal procedure.

[0084] The AMF may provide the WTRU with, for example, a strict cyclic registration duration instruction (e.g., a strict cyclic registration timer instruction) along with a cyclic registration timer value. The cyclic registration timer function may be applied, for example, when the WTRU is using MICO mode (e.g., when it is in use). The AMF may present instructions to the WTRU based on expected WTRU behavior. For example, the AMF may configure the WTRU to be available for downlink data (e.g., in CM connection mode) every hour (e.g., on the hour) to receive downlink data. The cyclic registration duration (e.g., timer) function may be useful, for example, when the WTRU is using MICO mode (e.g., when it is in use). The cyclic registration duration (e.g., timer) function may be used to ensure that the WTRU is in CM connection mode (e.g., at predictable times). For example, if the WTRU runs a strict cyclic registration timer for 4 hours and applies a 10-minute active timer (e.g., always), it may be known that the WTRU is available for 10 minutes every 4 hours. By enabling the strictly periodic registration duration (e.g., timer) function, the AMF can be configured so that available events (e.g., 10-minute available events) occur at predictable times.

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

[0086] AMF may be an example of a network function (NF) from which NWDAF can collect data. NWDAF may use the AMF's Namf_EventExposure service to retrieve data from AMF. NWDAF may also use the Nnwdaf_AnalyticsInfo service, which can be used by network functions to retrieve statistics and forecasts from NWDAF. 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 may call or consume the Nnwdaf_AnalyticsInfo service.

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

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

[0089] The unavailability period may be determined in 5GS for a WTRU (e.g., a specific WTRU). WTRU and / or network actions may be based on the determined unavailability period. WTRU and the network (e.g., 5GC) may coordinate the architecture-level workflow for the unavailability period and / or unavailable functions.

[0090] WTRU may provide instructions for support during periods of unavailability, for example, in a registration request message (e.g., during the registration process). AMF may indicate support during periods of unavailability, for example, in a registration acceptance message.

[0091] A WTRU may store its MM context in USIM or non-volatile memory so that it can be reused (for example, after the WTRU's unavailability period) if an event is triggered in the WTRU that makes the WTRU unavailable for a certain period (for example, due to an OS upgrade or device reboot). A WTRU may trigger a mobility registration or unregistration procedure, including an unavailability period, when it is ready to perform an event (for example, when it is ready). An AMF may provide a periodic registration refresh duration (e.g., a timer) based on the unavailability period indicated by the WTRU; for example, an AMF may provide a periodic registration refresh duration that is longer than the unavailability period. An AMF may store information in the WTRU context that the WTRU is unavailable if the WTRU has not been unregistered. An AMF may consider the WTRU unreachable until the unavailability period has elapsed or the WTRU enters a CM connected state. While the WTRU is unreachable, high-latency communication solutions (e.g., all of them) may be applied (e.g., if supported), such as extended data buffering and downlink data buffering status reporting. If there is a loss of connectivity event subscription for the WTRU by the AF, the AMF may trigger a loss of connectivity event report to the NEF, which may include the period of unavailability. The period of unavailability may be reported to the respective subscribed AFs.

[0092] A WTRU may store (or choose to store) its context (e.g., MM and SM contexts) when it is ready to perform an event (e.g., for an OS upgrade or device reboot). How a WTRU stores the context may depend on its implementation. A WTRU may use USIM functionality to store some or all of its context in the USIM.

[0093] A WTRU may trigger a registration procedure to resume normal service if, for example, an event that renders the WTRU unavailable is completed in the WTRU, or if the event is delayed or canceled in the WTRU to a future time (e.g., due to insufficient memory capacity, insufficient battery level, or completion of an event that renders the WTRU unavailable). A WTRU may refrain from including the period of unavailability in the registration request message (e.g., not including it). The registration procedure may be, for example, an initial registration procedure or a mobility registration renewal procedure, depending on the final state the WTRU will be in after the event.

[0094] Unavailability support may be provided while a backoff duration is active (e.g., while a timer is running). While an Access Layer (NAS) backoff duration (e.g., a timer, or other backoff timer) is running in a WTRU (e.g., T3346 / T3347 / T3396, or other backoff timers), NAS layer mobility management entities may refrain from triggering mobility registration procedures toward the core network (e.g., not triggering or not permitted to trigger), with one or more exceptions such as downlink (DL) paging / notification, UL high-priority signaling, or emergency services. A WTRU (e.g., in this case) may refrain from sending registration requests with an unavailability duration to the network (e.g., not sending them).

[0095] If the WTRU takes action that could render the WTRU unavailable while the backoff duration (e.g., timer) is running, for example, by refraining from sending the duration of the unavailable period to the network (e.g., not sending it), the network may attempt to contact the WTRU for mobile incoming services (e.g., the attempt may fail) while the backoff duration (e.g., timer) is running. Attempts to contact the WTRU for mobile incoming services may fail.

[0096] One or more examples described herein may illustrate how a WTRU handles MM signaling when an MM backoff duration (e.g., a timer) is running and the WTRU may (e.g., must) perform an event that makes the WTRU unavailable.

[0097] Unavailability support may be provided while a WTRU is registered for non-3GPP access and not for other access (e.g., registered only for non-3GPP access). For example, if the NAS layer of a WTRU receives notification from a 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 then (e.g.) consider the WTRU to be in 5GMM connectivity mode via non-3GPP access. The WTRU may then (e.g.) be reachable 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 connectivity mode via non-3GPP access may (e.g., generally) remain in 5GMM connectivity mode until, for example, the WTRU is disconnected from the non-3GPP network.

[0098] Periodic registration renewal procedures may be avoided (or, for example, not performed) if, for example, a WTRU is registered via non-3GPP access (e.g., while registered).

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

[0100] Unavailability support may be provided for MUSIM devices. One or more examples described herein may illustrate how unavailability functionality may be handled for MUSIM devices registered to two or more different networks.

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

[0102] A MUSIM WTRU may be registered with multiple networks. NAS signaling procedures may be performed sequentially (for example, only). While communicating with the network about periods of unavailability, there may be delays (for example, these may be considered). Reporting of unavailability to the network may be considered sequentially while the system is out of the unavailability, for example, to ensure that the network is notified within a defined time frame.

[0103] One or more examples described herein may illustrate how MUSIM WTRUs with different configurations (e.g., all networks supporting the unavailable feature, or one or more networks not supporting the unavailable feature) can indicate periods of unavailableness to the network, for example, so that the network and the MUSIM WTRU can maintain the registration status of the MUSIM WTRU, and / or so that the network understands that the WTRU is unreachable for mobile incoming communications.

[0104] Unavailability support may be provided for devices registered with multiple networks (e.g., both EPC and 5GC). A WTRU (e.g., capable of operating in S1 and N1 modes) may be registered with both EPS and 5GS. A WTRU registered with EPS may be said to be in S1 mode. A WTRU registered with 5GS may be said to be in N1 mode. A dual-registered WTRU may be in both S1 and N1 modes (e.g., simultaneously).

[0105] One of several networks (e.g., EPS) may not support negotiation of unavailability periods, for example, via the S1 NAS interface between the WTRU and the EPS's Mobility Management Entity (MME). One or more examples described herein may illustrate how, when a WTRU is performing an event that would temporarily make it unavailable, the EPS knows (e.g., decides) to refrain (e.g., not to remove) the context of the WTRU, and / or how it knows (e.g., decides) to refrain (e.g., not to attempt to contact) the WTRU for incoming mobile communications.

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

[0107] Several scenarios may need to be considered. Firstly, the unavailability periods provided to the AMF by WTRUs may not be common events. For example, an unavailability period may occur only when a WTRU is installing a software upgrade (e.g., while it is installing). Secondly, multiple (e.g., many) WTRUs in an area may install software upgrades simultaneously or at similar times. Multiple WTRUs may become unavailable and then become available again at roughly the same time. Thirdly, the unavailability periods provided by WTRUs may be a strong indication of when a WTRU may attempt to perform the network registration procedure (e.g., it is expected that a WTRU may attempt to register with the network during the duration of the unavailability period).

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

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

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

[0111] Multiple parties (for example, three parties) may be involved in performing a specific event (e.g., an action), such as an OS upgrade, a silent reset of the modem, or a modem software update (also known as a binary update). These involved parties may include, for example, a device (e.g., a WTRU), an operator, and application functions.

[0112] A WTRU may become unavailable for a few minutes whenever such an operation is performed (e.g., it may not interact with the 5G system). A WTRU may become unavailable without prior knowledge from the core network and / or application functions. An unexpected WTRU unavailable state may affect the operation of an application server (e.g., critical operations) if the application server relies on the availability of the WTRU during the unavailable period (e.g., the time the WTRU is unavailable).

[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., timer) may be running (e.g., when it may be running), when a WTRU may register with a network (e.g., 5GS) via non-3GPP access (e.g., only) (e.g., when it may be registered), when a MUSIM device may register with multiple networks with and without support for the unavailable function (e.g., when it may be registered), when a WTRU may register with multiple networks (e.g., both EPS and 5GS) for support of analysis for the unavailable function (e.g., NWDAF) (e.g., when it is registered), when a remote WTRU and / or relay WTRU enters an unavailable period (e.g., when it enters), and when the MICO mode and / or exact periodic registration duration (e.g., timer) function is enabled (e.g., when it is enabled).

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

[0115] The AMF may reject NAS messages (e.g., when general NAS-level congestion control is active) and include the value of the Mobility Management (MM) backoff duration (e.g., timer, e.g., T3346) in the rejection message. The WTRU may use the value received in the MM (e.g., 5GMM) rejection message to begin tracking the duration (e.g., timer, e.g., T3346). The WTRU may refrain from sending one or more (e.g., certain) NAS messages (e.g., mobility registration updates) if the backoff duration (e.g., timer) is running (e.g., is currently running). The WTRU may respond to network initiation signaling (e.g., pages triggered by downlink data) if the backoff duration (e.g., timer) is running (e.g., is currently running).

[0116] A WTRU may notify the network of the start of an unavailability period based on the detection of an event in the WTRU that could make the WTRU unavailable for a certain period of time (e.g., when it is detected). A WTRU may also notify the network of the start of an unavailability period via a registration request message (e.g., including an unavailability period IE), if the WTRU can store MM (e.g., 5GMM) and SM (e.g., 5GSM) contexts. However, in one or more scenarios, a WTRU may refrain from notifying the network (e.g., AMF) of its unavailability (e.g., not notify, unable to notify). For example, a WTRU may refrain from triggering UL NAS signaling to send a mobility registration update when NAS level congestion control is active (e.g., when it is active) (e.g., it is not permitted to trigger it).

[0117] A WTRU may refrain from taking actions that would render it unavailable without informing the network (e.g., not taking any actions). The network may initiate signaling for the WTRU and, for example, find that the WTRU is unresponsive if the network is not informed. A WTRU may be unresponsive because, for example, it is taking actions that would render it unavailable (e.g., a software upgrade).

[0118] A WTRU may send a mobility registration update to the network (e.g., is permitted to send one) if, for example, a backoff duration (e.g., a timer) is running (e.g., even while it is running). A WTRU may generate NAS signaling to inform the network of a period of unavailability, and then again to inform the network that the WTRU is available again. Signaling may be generated while a backoff duration (e.g., a timer) is running. In some cases, multiple WTRUs in the same area may be performing the same software upgrade. Unavailability and availability signaling from multiple WTRUs may trigger a significant amount of NAS signaling that the network has to process, for example, even under congested conditions.

[0119] While NAS-level congestion control is active (e.g., while a duration or timer is running, e.g., while T3346 is running), the WTRU may (e.g., is permitted to) send registration request messages (e.g., including unavailability periods IE). The WTRU may (e.g., be limited to) (e.g., be configured to) prevent or avoid subsequent requests, uplink data status IE, and / or permitted PDU session status IE. (e.g., be limited to ensuring that registration request messages do not contain these). The WTRU may (e.g., further) be configured (e.g., limited to) requesting an unavailability period duration (e.g., only) that is greater than or equal to the amount of time remaining in the NAS backoff duration (e.g., a timer, e.g., T3346).

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

[0121] The aforementioned exemplary instructions within the registration acceptance message may give 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 the period of unavailability and for AMF to limit the amount of NAS signaling (for example, still).

[0122] Figure 2 illustrates an example of an unavailable event while NAS-level congestion control may be active. As shown in Figure 2, at 210, NAS-level congestion control may be active for a 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., a T3346 timer). NAS-level congestion control may be active at the WTRU. The duration (e.g., or other durations) may be running (e.g., T3346 and / or other backoff timers may be running). The WTRU may refrain from triggering NAS-level signaling (e.g., it may not trigger, or may not be permitted to trigger) except in cases such as high-priority access, emergency service, and / or meaning the WTRU is responding to paging from the network side.

[0123] In Figure 2, at point 220, the WTRU may detect the need to perform an event in the WTRU that could render it unavailable for a specific period of time. The WTRU may also (for example) detect the amount of time it is expected to be available again. For example, the time value may be provided by an application or operating system.

[0124] In Figure 2, at 230, the WTRU may trigger a registration request procedure to the AMF. The WTRU may provide an unavailable period IE to inform the network about the duration of the WTRU's unavailability. The WTRU may set the unavailable period to the duration determined in 220 (e.g., decide to set it) 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 may request a period that is greater than or equal to the amount of time remaining in the backoff duration (e.g., a timer) (e.g., decide to request a period).

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

[0126] In Figure 2, at point 250, the WTRU may perform a device reboot (e.g., successfully) in response to an event that rendered the WTRU unavailable, such as a silent reset on the modem, a security patch update, an OS upgrade, a modem switch update, and / or a modem configuration change via OMA-DM.

[0127] In Figure 2, at 260, for example, if the backoff duration (e.g., timer) is no longer running, or if AMF indicates at 240 that the WTRU may notify AMF when it becomes available again, the WTRU may notify AMF of the execution of its unavailable event (e.g., successful execution). For example, the WTRU may notify AMF of the execution of its unavailable event (e.g., successful execution) by refraining from including the unavailable period IE (e.g., not including it), or by sending a registration request message. The WTRU may wait until the backoff duration (e.g., timer) expires, and then, for example, if the backoff duration (e.g., timer) is running, or if AMF indicates at 240 that the WTRU may refrain from notifying AMF when it becomes available again (e.g., not notify), the WTRU may notify AMF of the execution of its unavailable event (e.g., successful execution). The WTRU may wait until the backoff duration (e.g., timer) expires, and then notify the AMF of the execution of the WTRU's unavailability event (e.g., successful execution) by, for example, sending a registration request message, refraining from including (e.g., not including) the unavailability period IE.

[0128] Referring to Figure 2, further exemplary procedures are provided for the case where a backoff duration (e.g., a timer) is running. The WTRU may perform one or more of the following:

[0129] As shown in Figure 2, at 210, the WTRU may receive a NAS denial message indicating that the WTRU is being restricted due to network congestion. The NAS denial message may include a duration (e.g., a timer value) indicating how long the WTRU may be allowed to be subject to congestion and / or how long the restriction is applicable. Based on receiving the duration (e.g., a timer value), the WTRU may, for example, initiate tracking of a backoff duration (e.g., a backoff timer).

[0130] As shown in Figure 2, in 220, the WTRU may detect the need to perform an event in the WTRU that could render the WTRU unavailable for a certain period of time (e.g., a specific period). The WTRU may also detect the amount of time it is expected to be available again.

[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 unavailability duration. The WTRU unavailability duration may be set to a value greater than or equal to the backoff duration (e.g., timer value), for example, based on the running backoff duration (e.g., timer) and / or based on a backoff duration (e.g., timer) value that is greater than the amount of time the WTRU is expected to be available.

[0132] As shown in Figure 2, at 240, the WTRU may receive a registration acceptance message from the network. The registration acceptance message may include an instruction that a previously provided backoff duration (e.g., timer, e.g., T3346) may continue to run and not be reset, which may cause or trigger the WTRU to continue applying NAS-level congestion control. The registration acceptance message may include a different (e.g., new) backoff duration (e.g., timer) value (e.g., T3346) indicating to the WTRU that NAS-level congestion control is still active, which may cause or trigger the WTRU to continue applying NAS-level congestion control and / or assign a different (e.g., new) value to the backoff duration (e.g., timer). The registration acceptance message may include an instruction that the WTRU may notify the AMF when it becomes available again, even if a backoff duration (e.g., a timer) (e.g., T3346) is in progress, which may trigger the WTRU to send a registration renewal request to the network when the unavailable event ends. The registration renewal request may refrain from including the unavailable period duration (e.g., it does not include it). The registration acceptance message may also include an instruction that the WTRU may refrain from notifying the AMF when it becomes available again (e.g., it does not notify) if a backoff duration (e.g., a timer) (e.g., T3346) is in progress, which may cause or trigger the WTRU not to send a registration renewal request to the network when the unavailable event ends while the backoff duration (e.g., a timer) is still in progress. The WTRU may send a registration renewal request to the network (e.g., it decides to send one) when the backoff duration (e.g., a timer) expires. Registration renewal requests may refrain from including (for example, not including) the duration of the unavailability period.

[0133] Unavailability support may be provided while a WTRU is registered for non-3GPP access (e.g., only). A network (e.g., a 5G system) may enable a WTRU to send registration requests to the AMF via non-3GPP access (e.g., as shown). The registration request may include availability information (e.g., an availability duration information element (IE)).

[0134] The AMF may perform one or more actions based on (for example, upon receipt of) unavailability information (e.g., an unavailability duration information element) from a WTRU registered via non-3GPP access. For example, the AMF may be triggered to perform one or more of the following actions:

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

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

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

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

[0139] AMF may consider a WTRU to be unregistered (e.g., in the 5GMM unregistered state) if, for example, the duration (e.g., a waiting timer) expires before AMF receives an initial NAS message from the WTRU.

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

[0141] As shown in Figure 3, in 310, a WTRU may be registered with 5GCN via non-3GPP access (e.g., only). Non-3GPP access may or may not be trusted.

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

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

[0144] In 340, the AMF may begin tracking a duration (e.g., a standby timer). The AMF may initially set the duration (e.g., standby timer) value to be greater than or equal to the unavailability duration.

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

[0146] In 360, the WTRU may perform a device reboot (e.g., successfully) during events that render the WTRU unavailable, such as a silent reset on the modem, security patch update, OS upgrade, modem switch update, and / or a modem configuration change via OMA-DM.

[0147] In 370, the WTRU may send an initial NAS message to the network, for example, to indicate to the AMF that the WTRU is reachable at this location.

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

[0149] Unavailability support may be provided for MUSIM devices. Unavailability adjustments may be provided across the network.

[0150] A WTRU may register with multiple (e.g., two) networks. A WTRU may send a registration request to a first network (e.g., one of the multiple networks). The registration request may include an unavailability period. The first network may respond with a registration acceptance message and / or a periodic registration period (e.g., a timer) which may be greater than or equal to the requested unavailability period. The WTRU may then send a registration request to a second network. The WTRU may include a second unavailability period in its request to the second network. The WTRU may set (e.g., choose) the second unavailability period to a value greater than or equal to the periodic registration timer received from the first network. This technique may help ensure that the second network refrains from indicating to the WTRU that the WTRU can re-register before (e.g., well in advance of) the time associated with (e.g., requested by) the first network.

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

[0152] Figure 4 illustrates an exemplary procedure for network-wide unavailability coordination.

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

[0154] In 420, the WTRU may detect that it needs to perform an event that could be associated with the WTRU being unavailable for a certain period of time (e.g., an event that requests the WTRU to be unavailable). The WTRU may determine a first duration of unavailable time.

[0155] In 430, the WTRU may send a registration request to the first network. The registration request may include the duration of the first period of unavailability.

[0156] In 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) which may be longer than or equal to the first unavailability period duration.

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

[0158] In 460, the WTRU may send a registration request to a second network. The registration request may include a second unavailability period.

[0159] In 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) which may be longer than or equal to the second unavailability period duration.

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

[0161] Figure 5 illustrates an example of network-wide unavailability coordination when multiple networks (e.g., both 5G networks) support unavailable features.

[0162] As shown in Figure 5, in 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 unavailable function.

[0163] In 520, an event may occur in the WTRU that could render it unavailable for a certain period of time (e.g., a specific period). 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 related to registration (deregistration) procedures.

[0164] In 530, the MUSIM WTRU may select 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 unavailability duration IE with a start delay (e.g., Δt). The start delay (Δt) may inform network AMF-1 that the unavailability may take into account a delay having a provided start delay duration value and / or the actual duration for which the WTRU will be unavailable, e.g., unavailability duration + Δt. The start delay may be calculated taking into account the number of pending registration (deregistration) procedures that the MUSIM WTRU may perform (e.g., need to perform) to notify other networks of its unavailability. For example, Δt can be calculated as Δt = (N=1) × (the time required (e.g., needed) for registration (deregistration) to notify AMF-2 of the unavailability + registration to notify the network (AMF-2) of the end of the unavailability period), where N can be the number of registrations (deregistrations) that MUSIM can (e.g., need to) perform. In the exemplary scenario shown in Figure 5, there may be another registration event to notify AMF-2 of the unavailability period. The time associated with registration (deregistration) (e.g., the time required (e.g., needed) for registration (deregistration) may take into account the best and / or worst-case scenarios, e.g., retransmission timers / counters, retry timers / counters, etc. Deregistration as a power-down may take into account the duration (e.g., timer) for which the WTRU may wait for a response from the network. A MUSIM WTRU may be considered (e.g., implicitly) deregistered if, for example, there is no response from the network.

[0165] In 440, AMF-1 may respond with a registration acceptance message. AMF-1 may then (for example) release the RRC signaling connection.

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

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

[0168] In 570, the MUSIM WTRU may perform (e.g., successfully perform) a device reboot during events that render the MUSIM WTRU unavailable, such as a silent reset on the modem, a security patch update, an OS upgrade, a modem switch update, and / or a modem configuration change via OMA-DM.

[0169] In 580, the MUSIM WTRU may send a registration request message to AMF-2 (e.g., refraining from including the duration of the unavailability period IE) to inform the network that the MUSIM WTRU is available (e.g., here). There may be a sequence for exiting unavailability. For example, the last network notified about the unavailability period may be the first network notified about availability. In an exemplary scenario, AMF-2 may be given higher priority than AMF-1 for informing other networks of the availability of the WTRU. The delay in initiation provided to AMF-1 may take into account the delay in informing other networks of the unavailability, which may be followed by availability and / or corresponding procedural timing.

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

[0171] Referring to Figure 5, an example is provided in which multiple (e.g., both or all) networks may support the unavailability feature. The MUSIM WTRU may perform one or more of the following:

[0172] As shown in Figure 5, in 510-520, a MUSIM device (e.g., WTRU) having two active USIM cards can register (e.g., successfully register) with two different (e.g., 5G) networks that support the unavailable function, e.g., AMF-1 and AMF-2. An event may occur in the WTRU that may render the WTRU unavailable for a certain period of time. The WTRU (e.g., as a MUSIM device) can sequentially communicate with the network (e.g., 5GS). The MUSIM WTRU may take into account delays in the registration (unregistration) procedure.

[0173] As shown in Figure 5, in 530 / 540, the MUSIM WTRU may select a first network (e.g., AMF-1) and send a registration request message that may include an unavailability duration (IE) and / or a start delay Δt. The start delay (Δt) may inform network AMF-1 that the unavailability period may take into account a delay with the provided start delay duration value. The actual duration for which the WTRU may be unavailable may be the unavailability duration + Δt. The start delay may be calculated, for example, by taking into account the number of pending registration (deregistration) procedures that the MUSIM WTRU may perform (e.g., need to perform) to inform other networks of its unavailability.

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

[0175] The time associated with registration (or deregistration) (e.g., the time required for registration (or deregistration)) may take into account the best and / or worst-case scenarios, e.g., retransmission timers / counters, retry timers / counters, etc. Deregistration as a power-down may take into account the duration for which the WTRU can wait for a response from the network (e.g., timer duration). A MUSIM WTRU may be considered deregistered (e.g., implicitly deregistered) if, for example, there is no response from the network. An AMF-1 may release the RRC signaling connection (e.g., subsequently) if, for example, AMF-1 responds with a registration acceptance message.

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

[0177] As shown in Figure 5, in 570 / 580 / 590, the WTRU may perform (e.g., successfully perform) a device reboot in response to an event that made the WTRU unavailable, such as a silent reset on the modem, security patch update, OS upgrade, modem SW update, and / or a modem configuration change via OMA-DM. The MUSIM WTRU may send a registration request message to AMF-2 (e.g., without including the duration of the unavailable period IE) to inform the network that the MUSIM WTRU is available (e.g., here). There may be a sequence for exiting the unavailable period. For example, the last network notified about the unavailable period may be the first network notified about availability. For example, as shown in Figure 5, AMF-2 may be given higher priority than AMF-1 to inform others about the availability of the WTRU. The delay in initiation provided to AMF-1 may take into account the delay in informing other networks about the unavailable period, and may be followed by availability and corresponding procedure timings. The MUSIM WTRU can send a registration request message to AMF-1 (e.g., without an unavailability period duration IE) to inform the network that the MUSIM WTRU is available (e.g., here).

[0178] In some cases, one of the networks may not support the unavailability feature.

[0179] Figure 6 illustrates an example of network-wide unavailability coordination when one of the networks does not support the MUSIM WTRU unavailability feature.

[0180] As shown in Figure 6, in 610, the MUSIM device (e.g., WTRU) may have multiple (e.g., two) active USIM cards. The MUSIM WTRU may register (e.g., successfully register) 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 unavailable features, or a 5G network (e.g., AMF) that does not support unavailable features.

[0181] In 620, an event may occur in the WTRU that could render it unavailable for a certain period of time (e.g., a specific period). The WTRU (as a MUSIM device) may communicate sequentially with the network (e.g., 5GS). The MUSIM WTRU may take into account delays related to registration (deregistration) procedures.

[0182] In 630, the MUSIM WTRU may select / choose a first network (e.g., AMF-1) to which it should send a registration request message, including, for example, an unavailability duration IE and / or a start delay Δt. The start delay (Δt) may inform network AMF-1 that the unavailability period may take into account a delay with the provided start delay duration value. The actual duration for which the WTRU may be unavailable may be the unavailability 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., need to perform) to inform other networks of its unavailability. For example, as shown in Figure 6, other networks may not support the unavailability feature (e.g., EPS or 5GS, where the feature is not supported). The start delay may take into account the duration associated with (e.g., the time required for) deregistering the WTRU from other networks.

[0183] In 640, AMF-1 may respond with a registration acceptance message. AMF-1 may then (for example) release the RRC signaling connection.

[0184] In the 650, the second network (AMF-2 / MME) may not support the function. The WTRU may trigger unregistration to the network by sending an unregistration request message (for example, with a cause code such as power down).

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

[0186] In some cases, deregistration may be performed first. The MUSIM WTRU may deregister itself from a network that does not support the unavailable feature. The MUSIM WTRU may then (for example) perform an unavailable procedure with a second network that does support it.

[0187] In 660, the WTRU may perform a device reboot (e.g., successfully) in the event that rendered the WTRU unavailable, such as a silent reset on the modem, security patch update, OS upgrade, modem switch update, and / or a modem configuration change via OMA-DM.

[0188] In 670, the MUSIM WTRU may send a registration request message to AMF-2 (e.g., refraining from including the duration of the unavailability period IE) to inform the network that the MUSIM WTRU is available (e.g., here). There may be a sequence for exiting unavailability. For example, the last network notified about the unavailability period may be the first network notified about availability. For example, as shown in Figure 5, AMF-2 / MME may be given higher priority than AMF-1 to inform other networks about the availability of the WTRU. The delayed initiation provided to AMF-1 takes into account the delay in informing other networks about the unavailability, and may be followed by, for example, availability and corresponding procedure timings.

[0189] In 680, the MUSIM WTRU may send a registration request message to AMF-1 (which does not include, for example, the duration of the period of unavailability IE) to inform the network that the MUSIM WTRU is available (for example, here).

[0190] Referring to Figure 6, further illustrative procedures are provided in which one of the networks may not support the unavailability feature. The MUSIM WTRU may perform one or more of the following:

[0191] As shown in Figure 6, in 610-620, a MUSIM device (e.g., WTRU) may have two active USIM cards. A 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 unavailable function, or a 5G network (e.g., AMF) that does not support the unavailable function. An event may occur in the WTRU that may render it unavailable for a certain period of time. The WTRU (e.g., as a MUSIM device) may communicate with the 5GS (e.g., sequentially). A MUSIM WTRU may take into account delays in the registration (deregistration) procedure.

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

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

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

[0195] In some cases, the deregistration step may be the first step. For example, a MUSIM WTRU may deregister itself from a network that does not support the unavailable feature. The WTRU may then (for example) perform an unavailable procedure with a second network that does support it.

[0196] As shown in Figure 6, in the 660 / 670 / 680, the WTRU may perform (e.g., successfully perform) a device reboot in response to an event that made the WTRU unavailable, such as a silent reset on the modem, security patch update, OS upgrade, modem SW update, and / or a modem configuration change via OMA-DM. The MUSIM WTRU may send a registration request message to AMF-2 (e.g., without including the duration of the unavailable period IE) to inform the network that the MUSIM WTRU is available (e.g., here). There may be a sequence for exiting the unavailable period. For example, the last network notified about the unavailable period may be the first network notified about availability. For example, as shown in Figure 6, AMF-2 / MME may be given higher priority than AMF-1 to inform others about the availability of the WTRU. The delay in initiation provided to AMF-1 may take into account the delay in informing other networks about the unavailable period, and may be followed by availability and corresponding procedure timings. The MUSIM WTRU can send a registration request message to AMF-1 (e.g., without an unavailability period duration IE) to inform the network that the MUSIM WTRU is available (e.g., here).

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

[0198] A WTRU that can operate in S1 and N1 modes may detect that an event needs to be performed that could render the WTRU unavailable for a certain period of time. For example, the WTRU may send (e.g., decide to send) an unavailable period duration to the AMF so that the AMF knows that the WTRU may be unreachable and / or that the WTRU's context should be maintained by the network (e.g., 5GS) while the WTRU is performing an event and is unavailable.

[0199] The AMF may, for example, detect (based on a registration request) that a WTRU is capable of operating in S1 and N1 modes, has a common registration for 5G and EPS access, or is dual-registered, and for example, if the AMF receives a registration request from the WTRU that includes an unavailability period duration, it may send a notification to the MME (e.g., via the N26 interface). The notification may indicate to the MME that the WTRU is likely to be unavailable for a certain period of time. The notification may include an unavailability period duration or periodic registration time that the AMF may send to the WTRU in its registration response. The MME may, for example, determine (e.g., recognize) how long the WTRU is expected to be unavailable, based on the unavailability period duration or periodic registration time in the notification. Based on receiving the notification, the MME may take one or more of the following actions (e.g., any combination):

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

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

[0202] The AMF may, for example, send a notification to the MME and, based on receiving a response from the MME (for example, at that time), send a registration response to the WTRU. The registration response may include, for example, one or more of the following instructions: an instruction that the unavailability period has been shared with the MME, and / or an instruction that the WTRU may perform a tracking area update with the MME when the unavailability event can be completed, an instruction that the unavailability period has been rejected by the MME, and / or an instruction that the WTRU may be considered to have been unregistered from the EPS and transitioned, for example, from an EMM registered state to an EMM unregistered state, and / or one or more of the values ​​(e.g., a new value) that the WTRU may assign to its EPS periodic tracking area update duration (e.g., timer) value.

[0203] A WTRU may complete its unavailability period. A WTRU may perform registration area update procedures with 5GS and tracking area update procedures with EPS (for example, upon completion of the unavailability period). The tracking area update procedure may be performed, for example, only if the WTRU has not transitioned to an EMM deregistered state. A WTRU may perform an attachment procedure with EPS if, for example, the WTRU has transitioned to an EMM deregistered state.

[0204] The benefits provided by unavailable support for devices registered to multiple networks (e.g., EPC and 5GC) may include, for example, one or more of the following: EPS NAS signaling may be kept unchanged (e.g., does not need to be changed); the EPS context may be maintained while the WTRU is unavailable; and / or the WTRU may determine (e.g., recognize) whether the MME is unable or unwilling to maintain the EPS context while the WTRU is unavailable.

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

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

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

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

[0209] In 740, the AMF may send a notification to the MME, for example, via the N26 interface. The notification may indicate to the MME that the WTRU will be unavailable (e.g., likely to become unavailable) for a period of time. The notification may include an unavailable period duration or periodic registration time that the AMF may send to the WTRU in its registration response. The MME may, for example, determine the expected duration of the WTRU's unavailability based on the unavailable period duration or periodic registration time in the notification.

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

[0211] For example, an MME may consider a WTRU to be unreachable (e.g., begin to consider it unreachable). An MME may reject any (e.g., any) downlink data notifications that may be associated with a WTRU until at least the time period indicated in the notification has elapsed. An MME may (e.g., further) adjust the duration associated with a WTRU (e.g., a timer, e.g., an implicit detach timer) by assigning a value that is at least the period indicated in the notification to the duration (e.g., assigning it to a timer).

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

[0213] In the 760, the MME may respond to notifications from the AMF (e.g., via the N26 interface). The MME response may include, for example, information indicating whether an unavailable request from the WTRU was accepted / rejected by the MME, and / or a periodic registration timer duration that can be relayed back to the WTRU via the AMF.

[0214] In 770, the AMF may provide the WTRU with registration acceptance. The registration response may include one or more of the following instructions: an instruction that the unavailability period has been shared with the MME; an instruction that the WTRU may perform a tracking area update with the MME when the unavailability event is complete; and / or an instruction that the EMM status may be EMM registered; an instruction that the unavailability period has been rejected by the MME; an instruction that the WTRU may be considered to be deregistered from the EPS; and / or an instruction that the WTRU may transition from an EMM registered state to an EMM deregistered state; and / or a new value that the WTRU may assign to the WTRU's EPS periodic tracking area update timer value.

[0215] In the 780, the WTRU may perform a device reboot (e.g., successfully) during events that render the WTRU unavailable, such as a silent reset on the modem, security patch update, OS upgrade, modem switch update, and / or a modem configuration change via OMA-DM.

[0216] In 790, the WTRU resulting from the unavailability period can, for example, be used to perform the registration procedure with the AMF without including the unavailability period IE.

[0217] In 795, the WTRU may trigger an EMM tracking area update procedure (e.g., if the EMM status is EMM registered) or an EMM attach procedure (e.g., if the EMM status is EMM unregistered) (in response to the results and response received by the WTRU from the MME via the AMF) to indicate to the MME that the unavailability period has ended and the WTRU is reachable again.

[0218] Analysis (e.g., NWDAF) may be supported for the unavailability feature. The AMF's Namf_EventExposure service may support NF invokers (e.g., NWDAF) that subscribe to events (e.g., WTRU unavailability events). AMF may report WTRU unavailability information to NF invokers when an event occurs. WTRU unavailability information may include, namely, a WTRU identifier, unavailability time information for (e.g., each) WTRU identifier, and / or one or more instructions for expected action, such as when each WTRU becomes available.

[0219] AMF may provide WTRU Unavailability Information when 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), providing event IDs such as one or more of the following (e.g., equivalent to them): registration status reports, connectivity status reports, reachability reports, in-area UE reports, 5GS user status reports, frequency mobility registration reports, UE access behavior trends, and / or UE-MM transaction reports. Additionally and / or alternatively, event IDs (e.g., new event IDs) may be defined (e.g., WTRU Unavailability Information). AMF may provide WTRU Unavailability Information when Invoker NF subscribes to or invokes the Namf_EventExposure Subscribe Service operation and provides (e.g., when providing) event IDs (e.g., equivalent to "WTRU Unavailability Information").

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

[0221] Instructions for expected actions when a WTRU becomes available may indicate that the WTRU will perform mobility registration (e.g., is expected to do so) when the unavailability period ends (e.g., when it ends), or that the WTRU will perform initial registration (e.g., is expected to do so) when the unavailability period ends (e.g., when it ends).

[0222] AMF may indicate that when the unavailability period ends (for example, when it ends), for example, if the WTRU has provided the duration of the unavailability period in the mobility registration request, the WTRU will perform (for example, is expected to perform) mobility registration.

[0223] The AMF may indicate that when the unavailability period ends (for example, when it ends), for example, if the WTRU provides the duration of the unavailability period in the deregistration request, the WTRU will perform (for example, is expected to perform) initial registration.

[0224] Providing consumer NFs (e.g., NWDAFs) with instructions for expected actions when a WTRU becomes available (e.g., when it becomes available) can be useful (e.g., important) because the expected actions may influence the amount of network activity (e.g., which may be required) when a WTRU becomes available (e.g., when it becomes available). For example, an initial registration procedure may result in more signaling than a mobility registration procedure. Consumer NFs can generate (e.g., can generate) more accurate statistics and / or predictions if they are informed of which actions are expected.

[0225] Figure 8 illustrates an exemplary procedure for AMF to provide unavailable information to NWDAF. NWDAF can use the unavailable information to generate more accurate statistics and / or forecasts. NWDAF can provide statistics and / or forecasts to consumer NFs such as PCF, AMF, NSSF, NEF, SMF, and / or AF.

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

[0227] As shown in Figure 8, in 810, a consumer NF (e.g., PCF, AMF, NSSF, NEF, SMF, or AF) may invoke a service (e.g., the Nnwdaf_AnalytcisInfo service of NWDAF). The type of service invoke may be a request or a join operation. The type of analysis requested may be, for example, one or more of the following: network slice instance load level statistics and forecasts, network slice load level statistics and forecasts, network function load level statistics and forecasts, network load level statistics and forecasts, WTRU communication statistics and forecasts, and / or a sixth WTRU abnormal behavior statistics and forecasts.

[0228] In 820, the NWDAF may collect (e.g., begin collecting) data that may be necessary to determine the information requested in 810. As part of the process of collecting the necessary data, the NWDAF may call the AMF's Namf_EventExposure service operation. The type of service call may be a request or join operation. The event ID values ​​that the NWDAF may provide to the AMF in the operation may be one or more of the following: registration status reports, connectivity status reports, reachability reports, in-area UE reports, 5GS user status reports, frequent mobility registration reports, UE access behavior trends, UE-MM transaction reports, and / or "WTRU unavailable information".

[0229] In 830, the AMF may receive a NAS registration request or a NAS deregistration request, which may include an unavailability period. In the example, the action in 830 may occur before the action in 820.

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

[0231] In 850, the NWDAF may derive the information requested in 810 (e.g., statistics or forecasts). The analysis may be derived based on the unavailability time information and / or instructions for the actions to be taken when the WTRU becomes available.

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

[0233] Unavailability features may be supported for relay WTRUs. Relay WTRUs may enter an unavailability period.

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

[0235] In some cases, the remote WTRU and relay WTRU may be connected (for example, via a PC5 connection). Either the relay WTRU or the remote WTRU, or the other, may become unavailable due to an unavailable event.

[0236] Figure 9 illustrates an example of a relay WTRU entering an unavailable period.

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

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

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

[0240] In 930, a list of remote WTRU information may be passed to the AF by the AMF for a loss of connectivity event (for example, if the AF has registered a loss of connectivity event for each remote WTRU).

[0241] In 940, the AMF may respond with a registration response that provides a list of remote WTRUs, for example, by confirming the status of receipt of the list.

[0242] In 950, the relay WTRU may inform the connected remote WTRU of the relay WTRU's unavailability, for example, along with the duration of the unavailability period.

[0243] In 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 network (e.g., 5G), and / or provide information to the network (e.g., via a registration (deregistration) procedure) regarding the duration of the unavailability.

[0244] Remote WTRUs may enter a period of unavailability.

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

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

[0247] In 1010, an unavailable event may be triggered in the remote WTRU that could render the remote WTRU unavailable for a certain period of time (e.g., a specific period of time).

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

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

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

[0251] In 1050, a relay WTRU may notify other remote WTRUs of the unavailability of a remote WTRU. The relay WTRU may provide the remote WTRU ID and / or the duration of the unavailability period.

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

[0253] When an unavailability period is requested, a charge may be applied for the expected WTRU availability. As described herein, WTRU may use MICO mode. When WTRU uses MICO mode, the strictly periodic registration timer function may be applied.

[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: a request to use MICO mode, an indication of whether a strictly 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., 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: an instruction to use MICO mode, an instruction to see if the strictly 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 using MICO mode so that the WTRU is available in a predictable time. Configuration may be carried out by the AMF selecting T3324 and T3512 time values ​​and / or by the AMF deciding whether to enable a strictly periodic registration duration (e.g., a timer).

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

[0258] A registration acceptance message may indicate that the strict periodic registration duration (e.g., timer) feature is enabled and that the unavailability period was not accepted. The WTRU may wait (e.g., in response to the registration acceptance message) until the registration duration (e.g., timer) expires before requesting the unavailability period duration again, send a registration request based on the expiration of the registration duration (e.g., timer), and enter a 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 WTRU's expected availability period has ended (e.g., just elapsed). This technique may be useful, for example, when the WTRU requests the unavailability period duration when the strict periodic registration time is nearing its expiration.

[0259] The registration acceptance message may indicate that the strictly periodic registration timer function is not enabled and that the unavailability period was not accepted. The WTRU may wait to request the unavailability period duration again until it enters a CM idle state (e.g., in response to the registration acceptance message) and its active duration (e.g., timer) is no longer running. By waiting until these conditions are met, it may be ensured that the WTRU's expected availability period has ended (e.g., just elapsed).

[0260] If a WTRU receives a WTRU configuration update message or another registration acceptance message that disables the MICO mode or the exact periodic registration duration (e.g., timer) function, it may decide to request an unavailability period duration (e.g., again) (e.g., alternatively).

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

[0262] The WTRU may decide to send the unavailability period duration (for example, again) (for example, at any time) (for example, alternatively) in response to the deregistration request. An example of this procedure is illustrated in Figure 11.

[0263] Figure 11 illustrates an example of logic for WTRU processing of unavailability period rejections. Figure 11 shows an example of how to consider expected WTRU availability when an unavailability period is requested.

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

[0265] As shown in Figure 11, the WTRU may send a registration request including an unavailable period duration (for example, when MICO mode and the strictly periodic registration timer function are not enabled). The WTRU may receive a registration acceptance message, which may indicate that MICO mode is enabled, the strictly periodic registration duration (e.g., timer) function is not enabled, and an unavailable period duration is not permitted. The WTRU may decide to send a second registration request including a second unavailable period duration, for example, under the condition that the WTRU enters a CM idle state and the active duration (e.g., timer) is not running. The WTRU may send a second registration request including a second unavailable period duration.

[0266] As shown in Figure 11, the WTRU may send a registration request that may include an unavailability period duration (for example, when MICO mode is not enabled). The WTRU may receive a registration acceptance message that refrains from indicating (e.g., does not indicate) that MICO mode is enabled and that an unavailability period duration is not permitted. The WTRU may configure a duration with the unavailability period duration and start tracking (e.g., start a timer). The WTRU may decide to send a second registration request that includes a second unavailability period duration, provided that the duration (e.g., timer) is not running and the WTRU has entered a CM idle state. The WTRU may send a second registration request that includes a second unavailability period duration.

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

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

[0269] The processes described above may be carried out by computer programs, software, and / or firmware embedded in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, as well as magnetic media, magneto-optical media, and / or optical media such as Compact Disc (CD)-ROM discs and / or Digital Versatile Disks (DVDs). A processor associated with software may be used to implement radio frequency transceivers for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A Multi-USIM (MUSIM) Wireless Transmitter / Receiver Unit (MUSIM WTRU), Start registering with the first network and the second network. It was determined that an event was triggered that would render the aforementioned MUSIM WTRU unavailable. Initiating a first mobility registration renewal procedure with the first network, the first mobility registration renewal procedure includes sending a first registration request to the first network indicating a first unavailability duration associated with a period of unavailability during which the MUSIM WTRU is unable to interact with the first network. A first registration response is received from the first network, the first registration response indicates a first periodic registration timer value, and the first network does not support unavailable functions. A first deregistration procedure with the first network is initiated, the first deregistration procedure includes sending a first deregistration request to the first network. Initiate a second mobility registration renewal procedure with the second network, the second mobility registration renewal procedure including sending a second registration request to the second network indicating a second unavailability duration during which the MUSIM WTRU is unable to interact with the second network. A second registration response is received from the second network, the second registration response indicates a second periodic registration timer value, and the second network does not support the unavailable function. Initiating a second deregistration procedure with the second network, the second deregistration procedure includes sending a second deregistration request to the second network. A processor configured in such a way MUSIM WTRU equipped with [this feature].

2. The MUSIM WTRU according to claim 1, wherein the second unavailability duration is different from the first unavailability duration.

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

4. The MUSIM WTRU according to claim 1, wherein the first periodic registration timer value is based on the unavailability period.

5. The MUSIM WTRU according to claim 1, wherein the second periodic registration timer value is based on the second unavailability duration.

6. The MUSIM WTRU according to claim 1, further configured to execute the event that renders the WTRU unavailable, wherein the processor is configured to perform the event that renders the WTRU unavailable.

7. The MUSIM WTRU according to claim 1, wherein the second periodic registration timer value is greater than or equal to the first unavailability duration.

8. The MUSIM WTRU according to claim 1, wherein the first registration request further indicates a request to activate the unavailability period function with the first network.

9. It is a method, Steps to initiate registration with the first network and the second network, A step to determine that an event has been triggered that would disable the Multi USIM (MUSIM) Wireless Transmitter / Receiver Unit (MUSIM WTRU), Steps include initiating a first mobility registration renewal procedure with the first network, the first mobility registration renewal procedure comprising sending a first registration request to the first network indicating a first unavailability duration associated with a period of unavailability during which the MUSIM WTRU is unable to interact with the first network; The steps include receiving a first registration response from the first network, wherein the first registration response indicates a first periodic registration timer value, and the first network does not support unavailable functions, A step of initiating a first deregistration procedure with the first network, the first deregistration procedure including sending a first deregistration request to the first network, Steps include initiating a second mobility registration renewal procedure with the second network, the second mobility registration renewal procedure including sending a second registration request to the second network indicating a second unavailability duration during which the MUSIM WTRU is unable to interact with the second network; A step of receiving a second registration response from the second network, wherein the second registration response indicates a second periodic registration timer value, and the second network does not support the unavailable function. A step of initiating a second deregistration procedure with the second network, the second deregistration procedure including sending a second deregistration request to the second network. A method for providing this.

10. The method according to claim 9, wherein the second unavailability duration is different from the first unavailability duration.

11. The method according to claim 9, wherein the second unavailability duration is the same as the first unavailability duration.

12. The method according to claim 9, wherein the first periodic registration timer value is based on the unavailable period.

13. The method according to claim 9, wherein the second periodic registration timer value is based on the second unavailability duration.

14. The method according to claim 9, further configured to perform the event that renders the WTRU unavailable.

15. The method according to claim 9, wherein the second periodic registration timer value is greater than or equal to the first unavailability duration.

16. The method according to claim 9, wherein the first registration request further indicates a request to activate the unavailability period function with the first network.

Images