Flexible registration of environmental internet of things (IoT) devices

Abstract

A wireless transmit / receive unit (WTRU) for flexible registration. The WTRU may send a first registration request message to a network node; receiving a first registration acceptance message from the network node, wherein the first registration acceptance message indicates a periodic registration timer value and a permitted periodic registration early time value; and determine a first time period based on the periodic registration timer value and a second time period based on the permitted periodic registration early time value. The WTRU may send a second registration request message to the network node under conditions that the first time period has elapsed, the second time period is pending, and the WTRU has sufficient available energy to perform a process with the network entity. The WTRU may receive a second registration accept message from the network node, wherein the second registration accept message indicates that the WTRU should enter the sleep mode.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 444,320, filed February 9, 2023, the contents of which are incorporated herein by reference. Background Art

[0002] Mobile communications using wireless communications continue to develop. The fifth generation of mobile communications radio access technology (RAT) may be referred to as 5G New Radio (NR). The previous generation (conventional) mobile communications RAT may be, for example, the fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] This disclosure describes systems, devices, and methods for providing availability coordination for ambient Internet of Things (IoT) devices. The ambient IoT devices may be wireless transmit / receive units (WTRUs). This disclosure also describes systems, devices, and methods for providing energy harvesting devices, which may include WTRUs.

[0004] An example wireless transmit / receive unit (WTRU) may include a processor configured to perform one or more actions. The WTRU may send a first registration request message to a network node. The network node may be associated with a network function. The WTRU may receive a first registration accept message from the network node. The first registration accept message may indicate a periodic registration timer value and an allowed periodic registration early time value. The WTRU may determine a first time period based on the allowed periodic registration early time value and a second time period based on the periodic registration timer value. The WTRU may send a second registration request message to the network node if the first time period has elapsed, a second time period is pending, and the WTRU has sufficient available energy to perform a procedure with the network entity. The WTRU may receive a second registration accept message from the network node, wherein the second registration accept message instructs the WTRU to enter a sleep mode.

[0005] The second registration request message may indicate that the second registration request message is an early periodic registration request.The WTRU may determine that the WTRU has been deregistered if the first time period and the second time period have elapsed without the WTRU sending a second registration request message.

[0006] At least one of the first Registration Request message or the second Registration Request message may indicate that the WTRU supports a periodic registration timer value and a permitted periodic registration early time value. The WTRU may be associated with a periodic registration time window value that is based on an expected period during which the WTRU will be powered off. The periodic registration timer value and the permitted periodic registration early time value may be based on the periodic registration time window value.

[0007] A WTRU may be an ambient Internet of Things (IoT) device. The WTRU may determine that the WTRU has sufficient available energy to perform a procedure with a network node. The WTRU may determine that the WTRU has sufficient available energy to perform a procedure with a network node by determining an energy criterion; determining an amount of energy used for tasks associated with the procedure; and determining that the amount of energy satisfies the energy criterion. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0009] Figure 1B is a diagram showing that according to one embodiment, Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use in a communication system is shown.

[0010] Figure 1C is a diagram showing that according to one embodiment, Figure 1A System diagram of an example radio access network (RAN) and an example core network (CN) used in the illustrated communication system.

[0011] Figure 1D is a diagram showing that according to one embodiment, Figure 1A System diagram of yet another example RAN and yet another example CN used in the communication system shown.

[0012] Figure 2 Example WTRU configuration techniques are shown (eg, making periodic registration timing flexible).

[0013] Figure 3 Example techniques are shown for obtaining expected downlink data without listening for pages. DETAILED DESCRIPTION

[0014] Example Network for Implementing Embodiments Figure 1Ais a diagram illustrating an example 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, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique word DFT spread OFDM (ZT UWDTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

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

[0016] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0017] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage to a specific geographic area, which may be relatively fixed or may change over time. A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, one for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0018] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless 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).

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

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

[0021] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using New Radio (NR).

[0022] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may jointly implement LTE radio access and NR radio access, e.g., using dual connectivity (DC) principles. Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions to / from multiple types of base stations (e.g., eNBs and gNBs).

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

[0024] For example, Figure 1A The base station 114b in the may be a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a microcell or a femtocell. As Figure 1A As shown, base station 114b may be directly connected to Internet 110. Therefore, base station 114b may not be required to access Internet 110 via CN 106 / 115.

[0025] The RAN 104 / 113 may be in communication with the CN 106 / 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 the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although in Figure 1AAlthough not shown, it will be appreciated that the RAN 104 / 113 and / or CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0028] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, 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 appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0029] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors 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 encoding and decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0033] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, 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). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information from and store data in any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0034] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 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.

[0035] The processor 118 may also be coupled to the 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 in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0036] 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, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (FM) radio unit, a digital music player, a media player, an electronic game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral device 138 may include one or more sensors, which may be a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a posture sensor, a biometric sensor, and / or a humidity sensor.

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

[0038] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0039] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

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

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

[0042] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0043] The SGW 164 may be connected to each eNode B 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may also perform other functions, such as anchoring the user plane during inter-eNode B handovers; triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c; managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0044] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0045] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0046] Even though the WTRU Figures 1A-1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may employ (eg, temporarily or permanently) a wired communication interface with a communication network.

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

[0048] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may access or be connected to a distributed system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS and destined for a STA may arrive through the AP and may be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. For example, traffic between STAs within a BSS may be sent through the AP, where the source STA may send traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between the source and destination STAs (e.g., directly between them) using direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad hoc" communication mode.

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

[0050] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0051] Very high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining 8 consecutive 20MHz channels, or by combining two discontinuous 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can separate the data into two streams. Each stream can be subjected to inverse fast Fourier transform (IFFT) processing and time domain processing respectively. These streams can be mapped onto two 80MHz channels, and the data can be sent by the transmitting STA. At the receiver of the receiving STA, the operation of the above-mentioned 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0052] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidths and carriers in 802.11af and 802.11ah are reduced relative to the channel operating bandwidths and carriers used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using non-TVWS. According to a representative embodiment, 802.11ah may support metered type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., in order to maintain very long battery life).

[0053] WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as a primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a STA among all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, for a STA that supports (e.g., only supports) 1 MHz mode (e.g., an MTC-type device), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (supporting only 1 MHz operating mode) transmitting to the AP, the entire available frequency band can be considered busy, even if most of the frequency band remains idle and potentially usable.

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

[0055] Figure 1D1 is a system diagram illustrating the RAN 113 and the CN 115 according to one embodiment. As described above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0056] The RAN 113 may include gNBs 180a, 180b, and 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit and / or receive signals to and from the gNBs 180a, 180b, and 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit and / or receive wireless signals to and / or from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers (not shown) to the WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, the gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and gNB 180b (and / or gNB 180c).

[0057] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing a varying number of OFDM symbols and / or varying absolute time durations).

[0058] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without simultaneously accessing other RANs (e.g., such as the eNode-Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with a gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as an eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may serve as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for the serving WTRUs 102a, 102b, 102c.

[0059] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to a user plane function (UPF) 184a, 184b, routing of control plane information to an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

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

[0061] The AMF 182a, 182b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, and the like. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of service being used by the WTRU 102a, 102b, 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, services for machine-type communication (MTC) access, and the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies, such as WiFi.

[0062] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b and configure the routing of traffic through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, and so on.

[0063] The UPF 184a, 184b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

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

[0065] Given that Figures 1A-1D as well as Figures 1A-1D

[0066] As described herein, one or more or all of the functionality described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functionality described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functionality.

[0066] Emulated devices can be designed to implement one or more tests of other devices in a laboratory environment and / or in a carrier network environment. For example, one or more emulated devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more emulated devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. For testing purposes, the emulated device can be directly coupled to another device and / or can use over-the-air wireless communication to perform the tests.

[0067] One or more emulated devices can perform one or more functions, including all functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulated device can be used in a test scenario in a non-deployed (e.g., testing) wired and / or wireless communication network and / or test lab to enable testing of one or more components. The one or more emulated devices can be test devices. The emulated device can use direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) to send and / or receive data.

[0068] Detailed description This disclosure describes systems, devices, and methods for providing availability coordination for ambient Internet of Things (IoT) devices. The ambient IoT devices may be wireless transmit / receive units (WTRUs). This disclosure also describes systems, devices, and methods for providing energy harvesting devices, which may be WTRUs.

[0069] In one embodiment, the WTRU may be configured by the network so that the WTRU may detect when it is allowed to perform a periodic registration (e.g., an early periodic registration). The WTRU may be configured with information regarding periodic registrations (e.g., an early periodic registration) and may be allowed to perform a periodic registration update (e.g., an early periodic registration update). This may, for example, reduce the chance that the WTRU may not have enough energy to perform a periodic registration update. As another example, this may avoid unwanted implicit registrations.

[0070] In one embodiment, the network may configure the WTRU with information about expected downlink data so that the WTRU may enter a low state power (e.g., sleep or mobile initiated connection only (MICO) mode, where the WTRU may not need to listen for paging) until after the expected arrival time of the downlink data. The WTRU may initiate a service request procedure without listening for paging and use the service request procedure to indicate to the network that the WTRU is ready and able to download downlink data. By configuring the WTRU with information about expected downlink data, the WTRU may be able to sleep longer and may reduce the chance that the WTRU may miss downlink data (e.g., because it sleeps too long and the data is flushed from the network buffer).

[0071] A timer as mentioned herein may refer to a determination of a time or a time period. The expiration of a timer as mentioned herein may refer to a determination that a time has arrived or a time period has expired. A timer as mentioned herein may refer to a time, a time period, a tracking time, a tracking time period, etc.

[0072] This article uses the following abbreviations and acronyms: AF application function AMF access and mobility function CM connection management IoT MICO only initiates connections on mobile MM Mobility Management NAS non-access layer NEF network exposure function RM Registration Management RRC Radio Resource Control SDM Subscriber Data Management SMF Session Management UDM user data management UDR User Data Repository UE (User Equipment) UPF user plane function WTRU wireless transmit / receive unit.

[0073]

[0014] Feature(s) associated with wireless transmit / receive unit (WTRU) registration flexibility are provided herein.

[0074]

[0014] Feature(s) associated with an ambient IoT device (e.g., a WTRU) are provided herein. An example ambient IoT device may send a registration request to a network. The example ambient IoT device may receive a registration accept message from the network. The registration accept message may include an allowed periodic registration early time value (e.g., allowed periodic registration early time value) and a periodic registration timer value (e.g., a T3512 timer).

[0075] The example environment IoT device may enter a CM-IDLE state. The example environment IoT device may start one or more timers (e.g., two timers). The example timer (e.g., a first timer) may be configured based on an allowed periodic registration early time value (e.g., an allowed periodic registration EARLY TIME value). The example timer (e.g., a second timer) may be configured based on a periodic registration timer value (e.g., a T3512 timer).

[0076] The example environment IoT device may determine to send a second registration request to the network. This determination may be made based on one or more conditions being met. For example, the example environment IoT device may determine to send the second registration request if the following three conditions are met: the first timer has expired, the second timer has not expired (e.g., is in progress or pending), and there is sufficient available energy to perform the process with the network.

[0077] In an example environment, the IoT device may send a second registration request to the network. The second registration request may indicate that the registration request is an early periodic registration request.

[0078] Example Environment The IoT device may receive a second Registration Accept message from the network. The second Registration Accept message may trigger the WTRU to enter the CM-IDLE state.

[0079] The registration request message(s) (eg, the first and / or second registration request messages) may indicate to the network that the ambient IoT device supports the periodic registration window feature.

[0080] The registration request message(s) (eg, first and / or second registration request messages) may include a requested periodic registration time value and / or a requested periodic registration early time value (eg, a requested periodic registration EARLYTIME value).

[0081] When the first timer expires, the WTRU may be in CM-IDLE state.

[0082]

[0066] Feature(s) associated with a WTRU expecting downlink data are provided herein.

[0083] Example Environment An IoT device (eg, a WTRU) may send a registration request to a network.

[0084] The ambient IoT device may receive a registration acceptance message from the network. The registration acceptance message may include an expected downlink data time and a periodic registration timer (e.g., a T3512 timer).

[0085] Ambient IoT devices can enter the CM-IDLE state.

[0086] The ambient IoT device may determine to send a service request to the network. This determination may be based on satisfying one or more conditions. For example, the ambient IoT device may determine to send a service request if the current time is equal to or exceeds the expected downlink data time and / or if there is sufficient available energy to perform the process with the network.

[0087] The ambient IoT device may send a service request to the network. The service request may be sent to the network to retrieve the expected buffered data.

[0088] The ambient IoT device may receive a service acceptance message from the network. The service acceptance message may indicate the status of the buffered data.

[0089] The registration request may indicate (eg, to the network) that the ambient IoT device supports sending service requests to the network that are triggered by an expected downlink data timer.

[0090] The registration accept message may include a buffer expiration time. The WTRU may use the buffer expiration time to determine whether to send a service request message. The WTRU may determine to send a service request message if (e.g., only if) the current time is less than the buffer expiration time.

[0091] The Registration Accept message may include a reference identifier (ID) that represents or identifies a location in the network where the buffered data will be stored. The WTRU may include the reference ID in the service request to indicate to the network the buffer to which the service request relates.

[0092] The service accept message may indicate to the ambient IoT device (eg, WTRU) that buffered data is available. The service accept message may indicate to the ambient IoT device that a user plane connection may be established.

[0093] The service accept message may indicate to the ambient IoT device (eg, WTRU) that the buffered data is no longer available in the buffer.

[0094] The service accept message may indicate to the ambient IoT device (eg, WTRU) that the buffered data was never received by the network.

[0095] The service acceptance message may include information about the priority of the buffered data. For example, the network may prioritize the buffered data based on the identity of the data source, how much time remains before the data in the buffer is discarded (e.g., if the data is about to be discarded, it may be considered to have a higher priority), or a combination thereof. The ambient IoT device may use the priority information to help determine how and whether to use stored energy to receive the data.

[0096] The service acceptance message may include information about the buffered data. For example, the network may indicate whether the buffered data is to be delivered via the user plane or the control plane, the amount of buffered data, etc. The ambient IoT device may use this information about the buffered data to determine how and / or whether to use stored energy to receive the data.

[0097] The service acceptance message may include information about the quality of service (QoS) requirements of (e.g., any) response sent by the ambient IoT device for the buffered data. The ambient IoT device may use this information to help determine when, how, and / or whether to use stored energy to send a response (e.g., an acknowledgment) after receiving the buffered data.

[0098]

[0014] Feature(s) associated with registering timers are provided herein.

[0099] The WTRU may initiate a registration procedure by sending a registration request (eg, upon expiration of a periodic registration timer). The purpose of the registration procedure may be to let the network know that the WTRU is still active.

[0100] The Access and Mobility Function (AMF) may send a periodic registration timer value to the WTRU based on local policy, subscription information, and / or information provided by the WTRU. The periodic registration timer value may be sent by the AMF to the WTRU in a Registration Accept message.

[0101] If a WTRU in the RM-REGISTERED state enters the CM-IDLE state, the WTRU may start a periodic registration timer (e.g., based on the periodic registration timer value received from the AMF). If the periodic registration timer expires, the WTRU may send a Registration Request to the AMF to notify the network that the WTRU is still active.

[0102] If a WTRU in the RM-REGISTERED state enters the CM-IDLE state, the AMF may start a Mobile Reachable Timer (e.g., based on the periodic registration timer value sent to the WTRU). If the AMF receives a Registration Request from the WTRU before the Mobile Reachable Timer expires, the AMF may stop the timer. If the timer expires before the WTRU sends a Registration Request to the AMF, the AMF may start a second timer. The second timer may be referred to as an Implicit Deregistration Timer. If the Implicit Deregistration Timer expires before the WTRU contacts the network, the AMF may (e.g., implicitly) deregister the WTRU. The Implicit Deregistration Timer may give (e.g., may effectively give) the WTRU additional time to contact the network before the network implicitly deregisters the WTRU.

[0103] If (e.g., each time) the WTRU enters the CM-CONNECTED state, the WTRU may stop the periodic registration timer. If (e.g., each time) the WTRU re-enters the CM-IDLE state, the WTRU may restart the timer. If the WTRU is not in the CM-IDLE state for a long time, the WTRU may not perform or may rarely perform the registration update procedure. Systems such as fifth generation (5G) systems may support a feature called "strict periodic registration timer indication". If the strict periodic registration timer indication feature is activated, the AMF may send a strict periodic registration timer indication to the WTRU in the registration accept message. When the WTRU enters the CM-CONNECTED state, the strict periodic registration timer indication may cause the WTRU to suppress stopping and / or restarting the periodic registration timer. For example, the WTRU may keep the periodic registration timer running while in the CM-CONNECTED state and after returning to the CM-IDLE state. If the WTRU is in the CM-IDLE state when the timer expires, the WTRU may initiate a registration procedure. If the WTRU is in the CM-CONNECTED state when the timer expires, the WTRU may restart the periodic registration timer and may not initiate the registration procedure.The Strict Periodic Registration Timer Indication feature may allow the network to configure the WTRU to be reachable for downlink data at known times and in known time intervals.

[0104] The registration procedure may be a type of non-access stratum mobility management (NAS-MM) procedure.

[0105] The WTRU configuration update procedure may be used to send a periodic registration timer value and / or a strict periodic registration timer indication to the WTRU.

[0106] The WTRU configuration update procedure may be a type of NAS-MM procedure.

[0107] Feature(s) associated with extending connection time are provided herein.

[0108] If the network (e.g., AMF) anticipates that downlink data will be sent to the WTRU (e.g., will be needed soon), the AMF may keep the WTRU in the CM-CONNECTED state, and the RAN may keep the WTRU in the RRC-CONNECTED state for an extended connected time period (e.g., to ensure that the downlink data is delivered to the WTRU). The extended connected time value may indicate the minimum time that the RAN keeps the WTRU in the RRC-CONNECTED state (e.g., despite inactivity).

[0109] The AMF may send the extended connection time value to the RAN. For example, when the AMF sends a Registration Accept message or a Service Accept message to the WTRU, the AMF may send the extended connection time value to the RAN.

[0110] Providing the extended connection time to the RAN may keep the WTRU in the RRC-CONNECTED state. If the WTRU were to enter the RRC-IDLE state, the WTRU may have to be paged before sending downlink data, or the network may have to wait for the WTRU to leave the Mobile Initiated Connection Only (MICO) mode before sending data.

[0111] The extended connection time may be determined by the AMF (e.g., based on local configuration or information sent by the Unified Data Manager (UDM) to the AMF). The UDM may obtain information about expected downlink data from the Application Function (AF).

[0112] Feature(s) associated with a service request are provided herein.

[0113] If the WTRU is in the CM-IDLE and RM-REGISTERED states, the WTRU may send a Service Request message to the network to transition to the CM-REGISTERED state and establish user plane resources. The WTRU may determine to send a Service Request message if the WTRU has uplink data to send. The WTRU may determine to send a Service Request message if the WTRU detects that the WTRU is being paged by the network.

[0114] The service request procedure may be a type of NAS-MM procedure.

[0115]

[0066] Feature(s) associated with an ambient IoT device (which may be a WTRU) are provided herein.

[0116] An example ambient IoT device may be a WTRU and may have one or more of the following characteristics (e.g., capabilities): harvests energy from the environment; has no battery or long-term energy storage capability; has intermittent (e.g., only intermittent) available power; has (e.g., only has) sufficient energy to communicate with the network at unpredictable times (e.g., because the times at which the device can harvest energy from the environment are unpredictable); may not be able to listen to the network for network-initiated indications (e.g., paging); and / or may (e.g., may only be) active for short periods of time.

[0117] If the WTRU remains in the CM-IDLE state for too long (e.g., without entering the CM-CONNECTED state to perform the registration procedure), the WTRU may be (e.g., implicitly) deregistered from the network. When the periodic registration timer expires, the ambient IoT device may not have enough power to perform the registration procedure. The ambient IoT device may be (e.g., implicitly) deregistered from the network. Deregistration (e.g., implicit deregistration) events may be expensive for the ambient IoT device and the network because the ambient IoT device may require initial registration and establishment of the ambient IoT device context (e.g., a new initial registration and establishment) to use the network again.

[0118] The network (e.g., AMF) may be configured with information so that the network may be aware of the time period(s) during which the WTRU's downlink data is expected to arrive at the network. The Strict Periodic Registration Timer indication may be used (e.g., by the 5G system) to configure the WTRU so that the WTRU will leave the CM-IDLE state at a predictable time and perform a registration procedure with the network. The network may be able to trigger the delivery of downlink data (e.g., once the registration procedure is complete). When the periodic registration timer expires, the ambient IoT device may not have enough power to perform the registration procedure. The ambient IoT device may not wake up to receive downlink data.

[0119] If the network (e.g., AMF) anticipates that downlink data will be sent to the WTRU (e.g., will be needed soon), the AMF may maintain the WTRU in the CM-CONNECTED state until the downlink data is available for transmission to the WTRU. The ambient IoT device may not have sufficient power available to remain in the RRC-CONNECTED state for an extended period of time. The ambient IoT device may run out of power while waiting for downlink data to be delivered.

[0120] This document provides an example registration technique. The registration technique can be optimized to reduce the risk that ambient IoT devices will miss periodic registration updates and be (e.g., implicitly) deregistered. The registration technique can allow the network to maintain control over when ambient IoT devices perform periodic registration updates.

[0121] Registration techniques may allow the network to notify an ambient IoT device (e.g., a WTRU) of expected downlink data (e.g., so that the WTRU can perform a service request without listening for paging from the network). The ambient IoT device may indicate to the network that the service request was triggered based on the notification of expected downlink data (e.g., as opposed to an explicit paging).

[0122]

[0014] Feature(s) associated with downlink data optimization are provided herein.

[0123] Provided herein are (one or more) features associated with registration flexibility for ambient IoT devices. The ambient IoT device may be a wireless transmit / receive unit (WTRU). An example wireless transmit / receive unit (WTRU) may include a processor configured to perform one or more actions. The WTRU may send a first registration request message to a network node. The network node may be associated with a network function. The WTRU may receive a first registration accept message from the network node. The first registration accept message may indicate a periodic registration timer value and an allowed periodic registration early time value. The WTRU may determine a first time period based on the allowed periodic registration early time value and determine a second time period based on the periodic registration timer value. Conditional on the first time period having passed, the second time period being pending, and the WTRU having sufficient available energy to perform a procedure with a network entity, the WTRU may send a second registration request message to the network node. The WTRU may receive a second registration accept message from the network node, wherein the second registration accept message instructs the WTRU to enter a sleep mode.

[0124] The second registration request message may indicate that the second registration request message is an early periodic registration request.The WTRU may determine that the WTRU has been deregistered if the first time period and the second time period have elapsed without the WTRU sending a second registration request message.

[0125] At least one of the first Registration Request message or the second Registration Request message may indicate that the WTRU supports a periodic registration timer value and a permitted periodic registration early time value. The WTRU may be associated with a periodic registration time window value that is based on an expected period during which the WTRU will be powered off. The periodic registration timer value and the permitted periodic registration early time value may be based on the periodic registration time window value.

[0126] A WTRU may be an ambient Internet of Things (IoT) device. The WTRU may determine that the WTRU has sufficient available energy to perform a procedure with a network node. The WTRU may determine that the WTRU has sufficient available energy to perform a procedure with a network node by determining an energy criterion; determining an amount of energy used for tasks associated with the procedure; and determining that the amount of energy satisfies the energy criterion.

[0127] A WTRU (e.g., sometimes also referred to herein as an ambient IoT device) may determine (e.g., select) to perform a periodic registration update (e.g., before the periodic registration time expires). Performing the periodic registration early may result in more registration messages over time (e.g., in terms of overall signaling). Performing the registration procedure early may reduce the chance that the ambient IoT device will miss the registration procedure (e.g., because the ambient IoT device does not have enough energy to perform the procedure when the timer expires).

[0128] Allowing ambient IoT devices to perform registration procedures arbitrarily early without parameters (e.g., allowing the WTRU to take any amount of time) may be suboptimal (e.g., from a system design perspective). For example, an ambient IoT device may determine (e.g., by design) to perform periodic registration procedures at an unnecessarily large amount of time (e.g., to avoid undesirable implicit deregistrations).

[0129] Figure 2 Example techniques are shown for enabling ambient IoT devices to perform early registration (e.g., while preventing ambient IoT devices from performing unnecessarily early registration). The network may provide a timer value to the WTRU that indicates how early the WTRU is allowed to initiate a periodic registration procedure. The network may indicate how much time is allowed for the ambient IoT device to perform a periodic registration update procedure before the periodic registration timer expires.

[0130] At 201, the AF may send information about the type of ambient IoT device to the network. The information may be a time value indicating how long the ambient IoT device can be expected to operate without power. The device may be associated with a periodic registration time window value based on the expected period that the WTRU will be powered off. For example, if the ambient IoT device harvests energy from vibrations on the road and the road is unlikely to operate for more than four hours without accommodating traffic, the value provided by the AF may be four hours. In this example, the AF may indicate that the ambient IoT device is unlikely to operate for more than four hours without power. This value may be referred to as a "recommended periodic registration TIME WINDOW value." The periodic registration timer value and the permitted periodic registration early time value may be based on the periodic registration time window value. The recommended periodic registration time window value (e.g., the recommended periodic registration TIME WINDOW value) may be sent from the AF to the NEF, from the NEF to the UDM, and stored by the UDM in the subscription data of the ambient IoT device in the unified data repository (UDR). The NEF may choose to send the recommended periodic registration time window value (e.g., the recommended periodic registration TIME WINDOW value) to the UDR via the UDM (e.g., rather than directly to the UDR), so that the UDM can verify that the recommended periodic registration TIME WINDOW value is within the allowed range. For example, the Nnef_ParameterProvision procedure may be enhanced to allow the AF to provide the recommended periodic registration time window value (e.g., the recommended periodic registration TIME WINDOW value) to the network.

[0131] At 202, the ambient IoT device may send a registration request to the network (e.g., to a network node associated with a network function, such as an AMF). For example, the ambient IoT device may indicate that the registration request type is "initial registration" or "mobility registration." The ambient IoT device may indicate to the AMF (e.g., in the registration request) that the ambient IoT device supports the "periodic registration window" feature, the "requested periodic registration time value," and / or the "requested periodic registration early time value" (e.g., the "requested periodic registration EARLYTIME value").

[0132] In 203 (e.g., as part of the registration process), the AMF may use the Nudm_SDM_Get application programming interface (API) of the UDM to obtain the subscription information of the ambient IoT device. The subscription information may include a "recommended periodic registration time value" and / or a "recommended periodic registration time window value" (e.g., a "recommended periodic registration time window value").

[0133] At 204, the AMF may determine a periodic registration timer (e.g., T3512 timer) and a "permitted periodic registration early time value" (e.g., "permitted periodic registration EARLY TIME value") using the recommended periodic registration time value and the recommended periodic registration time window value (e.g., recommended periodic registration TIME WINDOW value) from the UDM, and / or the requested periodic registration time value and the requested periodic registration early time value (e.g., requested periodic registration EARLY TIME value) from the WTRU. The AMF may send (e.g., to the ambient IoT device / WTRU) a registration accept message, and the WTRU may receive the registration accept message. The registration accept message may include the periodic registration timer value (e.g., T3512 timer) and / or the permitted periodic registration early timer value (e.g., permitted periodic registration EARLY TIME value).

[0134] At 205, the ambient IoT device may enter a CM-IDLE state and start one or more timers (e.g., two timers). The device may determine a first time period based on the allowed periodic registration early time value and a second time period based on the periodic registration timer value. For example, the first time period may be based on the allowed periodic registration early time value, and the second time period may be based on the periodic registration timer value (e.g., a T3512 timer). At 205, the ambient IoT device may determine to perform another procedure. For example, at 205, if (e.g., under the following conditions) the first timer / time period (e.g., based on the allowed periodic registration early time value) has expired, the second timer / time period (e.g., based on the periodic registration timer value) is in progress / pending, and the WTRU determines that the WTRU has sufficient (e.g., sufficient) energy to perform a procedure with the network node (e.g., to perform a periodic registration procedure), the ambient IoT device may determine to send (e.g., another) registration request message to the network node (e.g., may proceed to 206). The WTRU may determine that the WTRU has sufficient available energy to perform a procedure with a network node by determining an energy criterion; determining an amount of energy used for tasks associated with the procedure; and determining that the amount of energy meets the energy criterion.

[0135] At 206, the ambient IoT device may send a registration request to the network (e.g., if the first time period has passed, the second time period is ongoing, and the WTRU has sufficient available energy to perform the procedure with the network node). If the second timer / time period (e.g., T3512 timer) (and the first timer / time period) has expired / passed (e.g., and the WTRU has not sent a second registration request message), the ambient IoT device / WTRU may determine that the ambient IoT device / WTRU has (e.g., implicitly or explicitly) deregistered and set the registration type of the registration request to "initial". If the first timer (e.g., T3512 timer) has not expired, the ambient IoT device may determine that the ambient IoT device has not (e.g., implicitly or explicitly) deregistered. The registration request message may indicate that the registration request message is an early periodic registration request (e.g., the WTRU may set the registration type of the registration request to "periodic early"). The registration request may include an indication that the ambient IoT device (e.g., WTRU) supports periodic registration timer values ​​and permitted periodic registration early time values ​​(e.g., supports periodic registration window feature, requested periodic registration time value, and / or requested periodic registration early time value).

[0136] At 207, the AMF may send (e.g., to the WTRU) and the WTRU may receive (e.g., another) Registration Accept message to the WTRU. The Registration Accept message may include a periodic registration timer (e.g., T3512 timer) and / or a permitted periodic registration early value. The Registration Accept message may instruct the WTRU to enter sleep mode (e.g., may trigger the WTRU to enter CM-IDLE state). The ambient IoT device may restart the periodic registration timer (e.g., T3512 timer) and the periodic registration early time value timer. On the network side, both timers may be restarted.

[0137]

[0014] Feature(s) associated with wireless transmit / receive unit (WTRU) registration flexibility are provided herein.

[0138]

[0014] Feature(s) associated with an ambient IoT device (e.g., a WTRU) are provided herein. An example ambient IoT device may send a registration request to a network. The example ambient IoT device may receive a registration accept message from the network. The registration accept message may include an allowed periodic registration early time value and a periodic registration timer (e.g., a T3512 timer).

[0139] The example environment IoT device may enter a CM-IDLE state. The example environment IoT device may start one or more timers (e.g., two timers). The example timer (e.g., a first timer) may be configured based on the permitted periodic registration early time value. The example timer (e.g., a second timer) may be configured based on a periodic registration timer (e.g., a T3512 timer).

[0140] The example ambient IoT device may determine to send a second registration request to the network. This determination may be made based on satisfying one or more conditions. For example, the ambient IoT device may determine to send the second registration request if the following three conditions are satisfied: the first timer has expired, the second timer has not expired, and sufficient (e.g., enough) energy is available to perform the process with the network.

[0141] The ambient IoT device may send a second registration request to the network. The second registration request may indicate that the registration request is an early periodic registration request.

[0142] The ambient IoT device may receive a second registration accept message from the network. The second registration accept message may instruct the WTRU to enter sleep mode (eg, may trigger the WTRU to enter CM-IDLE state).

[0143] The registration request message(s) (eg, the first and / or second registration request messages) may indicate to the network that the ambient IoT device supports the periodic registration window feature.

[0144] The registration request message(s) (eg, the first and / or second registration request messages) may include a requested periodic registration time value and / or a requested periodic registration early time value.

[0145] When the first timer expires, the WTRU may be in CM-IDLE state.

[0146] Provided herein are (one or more) features associated with expected downlink data for an ambient IoT device. An example wireless transmit / receive unit (WTRU) may include a processor configured to perform one or more actions. The WTRU may send a registration request to a network node. The network node may be associated with a network function. The WTRU may receive a registration accept message from the network node. The registration accept message may include / indicate an expected downlink data time value. Under the condition that the time value is equal to or later than the expected downlink data time value and the WTRU has sufficient available energy to perform a procedure with the network node, the WTRU may send a service request message to the network node. The service request message may indicate that the WTRU is attempting to retrieve buffered data stored in a buffer. The WTRU may receive a service accept message from the network node. The service accept message may indicate the status of the buffered data.

[0147] The registration accept message may include a buffer expiration time value. The WTRU may send a service request message based on the time value and the buffer expiration time value. At least one of the registration accept message or the service request message may include a reference identifier that identifies a storage location of the buffered data.

[0148] The service accept message may indicate that: buffered data is available and the WTRU may establish a user plane connection; that buffered data is no longer available in the buffer; or that the network node has not received the buffered data. The service accept message may indicate information regarding the priority of the buffered data. The service accept message may indicate at least one of the following: the size of the buffered data; or whether the buffered data is to be delivered via the user plane or the control plane.

[0149] The WTRU may receive the buffered data. The WTRU may determine whether to send an acknowledgment message based on quality of service (QoS) information associated with sending the acknowledgment message. The service acceptance message may indicate the QoS information.

[0150] If a WTRU (e.g., sometimes also referred to herein as an ambient IoT device) performs a periodic registration procedure with the network, the AMF may keep the WTRU in RRC-CONNECTED mode in anticipation of pending downlink data.

[0151] Figure 3 An example method is shown for handling situations where ambient IoT devices expect downlink data. Figure 3is an example of the network providing the expected downlink time to the WTRU in the registration accept message (e.g., without providing an extended wait time value to the RAN). The WTRU may be able to (e.g., immediately) enter the CM-IDLE state or the dormant state and start saving power. The ambient IoT device may wait until after the expected downlink time to contact the network and receive downlink data. In the case where the ambient IoT device waits (e.g., needs to wait) until after (e.g., much later) the expected downlink time to contact the network (e.g., to ensure that the ambient IoT device has stored enough energy to contact the network), the downlink data may be buffered in the network. If the expected downlink time has passed and the ambient IoT device has stored enough energy to contact the network, the ambient IoT device may send a service request message to the network. The service request message may indicate to the network that the purpose of the service request message is to download the expected downlink data.

[0152] like Figure 3 As shown, at 301, the AF may send information about the type of ambient IoT device to the network. This information may include an expected communication time. The expected communication time value may be sent from the AF to the NEF, from the NEF to the UDM, and stored by the UDM in the subscription data of the ambient IoT device in the UDR. The NEF may choose to send the expected communication time value to the UDR via the UDM (e.g., rather than directly to the UDR) so that the UDM can verify that the expected communication time value is within an allowed range. For example, the Nnef_ParameterProvision procedure may be used to send expected WTRU behavior parameters to the network.

[0153] At 302, the ambient IoT device may send a registration request message to the network (e.g., to a network node associated with a network function). For example, the ambient IoT device may determine to send a registration request because a periodic registration timer has expired. The registration request may include an indication to the network that the ambient IoT device supports sending service request messages to the network triggered by expected downlink data.

[0154] At 303 (e.g., as part of registration), the AMF may use the Nudm_SDM_Get API of the UDM to obtain the subscription information of the ambient IoT device. The subscription information may include the expected downlink data time.

[0155] The AMF may send (eg, and the WTRU may receive) a Registration Accept message to the WTRU at 304. The Registration Accept message may include one or more of the following information.

[0156] The registration accept message may include an expected downlink data time value. By providing the expected downlink data time, the ambient IoT device may be able to return to a sleep (e.g., CM-IDLE) state (e.g., faster), reconnect to the network, and download data from the network buffer at a later time (e.g., after the expected downlink data time).

[0157] The Registration Accept message may include an indication that the WTRU may perform the service request at any time after the expected downlink data time. The presence of the expected downlink data time in the Registration Accept message may serve as this indication.

[0158] The Registration Accept message may include a buffer expiration time value, which indicates how long or until what time the network is willing to buffer data. Ambient IoT devices can use this buffer expiration information to determine whether they can attempt to retrieve buffered data. For example, if the ambient IoT device has sufficient energy to communicate with the network, but the network has discarded the buffered data, the ambient IoT device may not initiate a service request.

[0159] The registration accept message may include a reference identifier (ID) that identifies (e.g., represents) a storage location for the buffered data (e.g., where the network will store the buffered data). The reference ID may be a value that the network can resolve to an SMF ID, UPF ID, UDSF ID, or PDU session ID.

[0160] The registration acceptance message may include data of the ambient IoT device. For example, the network may send some (or all) of the data buffered for the ambient IoT device in the registration acceptance message.

[0161] If data is included in the registration accept message, the registration accept message may include an indication of whether there is more data in the buffer to be received by the WTRU. If the network indicates that there is no more data to be received, the ambient IoT device may be able to return to a sleep state (e.g., more quickly).

[0162] Downlink data from the ambient IoT device may arrive at the network at 305. The data may be buffered in the network (eg, in the SMF or UPF).

[0163] At 306, the ambient IoT device may be in a CM-IDLE state (e.g., may have been in a CM-IDLE state since receiving the registration accept message). The ambient IoT device may wait until the expected downlink data time. Under the condition that the time value (e.g., the current time value) is equal to or later than the expected downlink data time value, and the WTRU has sufficient available energy to perform the process with the network node, the WTRU may send a service request message to the network node. For example, if the expected downlink data time is detected (e.g., the expected downlink data time has passed), the ambient IoT device may wait until the ambient IoT device determines that sufficient (e.g., enough) energy is available to perform the process with the network. If the ambient IoT device has sufficient (e.g., enough) energy to perform the process with the network, and the buffer expiration time has not elapsed (e.g., has not passed), the ambient IoT device may take further action (e.g., proceed to 307 and send a service request message to the network).

[0164] At 307, the ambient IoT device may send a service request message to the network. The service type information element in the service request message may indicate (e.g., to the network) that the WTRU is attempting to retrieve buffered data stored in a buffer (e.g., the purpose of the service request is to retrieve the desired buffered data). The service request message may include one or more reference IDs (e.g., received at 304).

[0165] At 308, the ambient IoT device may receive a service accept message from the network node. The service accept message may indicate (e.g., to the ambient IoT device) the status of the buffered data. For example, the service accept message may indicate that the buffered data is available and / or that the ambient IoT device can establish a user plane connection or that an existing user plane connection has been activated. The service accept message may indicate to the ambient IoT device that the buffered data is no longer available in the buffer or has not (e.g., never) been received by the network (e.g., triggering the ambient IoT device to return to the CM-IDLE (or dormant) state).

[0166] The AMF may use the reference ID to determine where to buffer the data at 309. The AMF may trigger the delivery of the data from the buffer to the ambient IoT device.

[0167] At 310, the WTRU may receive buffered data (eg, buffered downlink data).

[0168] The network may send the WTRU an expected downlink data time, an indication that the WTRU may perform the service request at any time after the expected downlink data time, a buffer expiration time, and / or a reference ID in a Registration Accept message. This information may be sent to the ambient IoT device in a WTRU Configuration Update Command. If the ambient IoT device receives the information in the WTRU Configuration Update Command, the actions described at 306 to 310 may be triggered. If the network knows the expected downlink data and the WTRU is in the CM-CONNECTED state, the network may determine to send a WTRU Configuration Update Command to the ambient IoT device.

[0169]

[0066] Feature(s) associated with a WTRU expecting downlink data are provided herein.

[0170] Example Environment An IoT device (eg, a WTRU) may send a registration request to a network.

[0171] The ambient IoT device may receive a registration acceptance message from the network. The registration acceptance message may include an expected downlink data time and a periodic registration timer (e.g., a T3512 timer).

[0172] Ambient IoT devices can enter the CM-IDLE state.

[0173] The ambient IoT device may determine to send a service request to the network. This determination may be based on satisfying one or more conditions. For example, the ambient IoT device may determine to send a service request if the current time is equal to or exceeds the expected downlink data time and / or if there is sufficient available energy to perform the process with the network.

[0174] The ambient IoT device may send a service request to the network. The service request may be sent to the network to retrieve the expected buffered data.

[0175] The ambient IoT device may receive a service acceptance message from the network. The service acceptance message may indicate the status of the buffered data.

[0176] The registration request may indicate (eg, to the network) that the ambient IoT device supports sending service requests to the network that are triggered by an expected downlink data timer.

[0177] The registration accept message may include a buffer expiration time. Sending a service request message may be based on the buffer expiration time value and / or a time value (e.g., the current time). For example, the WTRU may use the buffer expiration time to determine whether to send a service request message. The WTRU may determine to send a service request message if (e.g., only if) the time value (e.g., the current time) is less than the buffer expiration time.

[0178] The registration accept message may include a reference identifier (ID) that represents or identifies a location in the network where the buffered data is stored. The WTRU may include the reference ID in the service request to indicate to the network the buffer to which the service request relates.

[0179] The service accept message may indicate to the ambient IoT device (e.g., WTRU) that buffered data is available. The service accept message may indicate to the ambient IoT device (e.g., WTRU) that a user plane connection can be established. The service accept message may indicate to the ambient IoT device (e.g., WTRU) that buffered data is no longer available in the buffer. The service accept message may indicate to the ambient IoT device (e.g., WTRU) that the network has never received the buffered data.

[0180] The service acceptance message may include information about the priority of the buffered data. For example, the network may prioritize the buffered data based on the identity of the data source, how much time remains before the data in the buffer is discarded (e.g., if the data is about to be discarded, it may be considered to have a higher priority), or a combination thereof. The ambient IoT device may use the priority information to help determine how and whether to use stored energy to receive the data.

[0181] The service acceptance message may include information about the buffered data. For example, the network may indicate whether the buffered data is to be delivered via the user plane or the control plane, the size (e.g., amount) of the buffered data, etc. The ambient IoT device may use this information about the buffered data to help determine how and whether to use stored energy to receive the data.

[0182] The service acceptance message may indicate quality of service (QoS) information (e.g., information about QoS requirements) for (e.g., any) responses that the ambient IoT device may send for the buffered data. The ambient IoT device may determine whether to send an acknowledgment message based on the QoS information associated with sending the acknowledgment message. For example, the ambient IoT device may use this information to help determine when, how, and whether to use stored energy to send a response (e.g., an acknowledgment) after receiving the buffered data.

[0183] Although the features and elements described herein are described in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiment, or in various combinations with or without the other features and elements.

[0184] Although the implementation described herein may consider 3GPP specific protocols, it should be understood that the implementation described herein is not limited to such scenarios and may be applicable to other wireless systems. For example, although the solution described herein considers LTE, LTE-A, New Radio (NR), or 5G specific protocols, it should be understood that the solution described herein is not limited to such scenarios and may be applicable to other wireless systems.

[0185] The processes described herein may be implemented in a computer program, software, and / or firmware contained in a computer-readable medium for execution by a computer and / or a 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 storage devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as compact disc (CD)-ROM disks and / or digital versatile discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver used in a WTRU, terminal, base station, RNC, and / or any host.

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: The processor is configured to: sending a first registration request message to a network node, wherein the network node is associated with a network function; receiving a first registration accept message from the network node, wherein the first registration accept message indicates a periodic registration timer value and a granted periodic registration early time value; determining a first time period based on a granted periodic registration early time value, and determining a second time period based on a periodic registration timer value; sending a second registration request message to the network node on the condition that the first time period has elapsed, the second time period is ongoing, and the WTRU has sufficient available energy to perform the procedure with the network node; and A second registration accept message is received from the network node, wherein the second registration accept message instructs the WTRU to enter sleep mode.

2. The WTRU of claim 1 , wherein: The second registration request message indicates that the second registration request message is an early periodic registration request.

3. The WTRU of claim 1 , wherein: The processor is further configured to determine that the WTRU has been deregistered if the first time period and the second time period have elapsed and the WTRU has not sent a second registration request message.

4. The WTRU of claim 1 , wherein: At least one of the first Registration Request message or the second Registration Request message indicates that the WTRU supports a periodic registration timer value and a granted periodic registration early time value.

5. The WTRU of claim 1 , wherein: The WTRU is associated with a periodic registration time window value that is based on an expected period that the WTRU will be powered off, and wherein the periodic registration timer value and the granted periodic registration early time value are based on the periodic registration time window value.

6. The WTRU of claim 1 , wherein: A WTRU is an ambient Internet of Things (IoT) device.

7. The WTRU of claim 1 , wherein: The processor is further configured to determine that the WTRU has sufficient available energy to perform a procedure with the network node.

8. The WTRU of claim 7, wherein: The processor being configured to determine that the WTRU has sufficient available energy to perform a procedure with a network node includes the processor being configured to: Determine energy standards; determining an amount of energy to be used for tasks associated with the process; and The amount of energy is determined to meet the energy criteria.

9. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: sending a first registration request message to a network node, wherein the network node is associated with a network function; receiving a first registration accept message from the network node, wherein the first registration accept message indicates a periodic registration timer value and a granted periodic registration early time value; determining a first time period based on a granted periodic registration early time value and determining a second time period based on a periodic registration timer value; sending a second registration request message to the network node on the condition that the first time period has elapsed, the second time period is ongoing, and the WTRU has sufficient available energy to perform the procedure with the network node; and A second registration accept message is received from the network node, wherein the second registration accept message instructs the WTRU to enter sleep mode.

10. The method according to claim 9, wherein: The second registration request message indicates that the second registration request message is an early periodic registration request.

11. The method according to claim 9, wherein: The method further includes determining that the WTRU has been deregistered on the condition that the first time period and the second time period have elapsed and the WTRU has not sent a second registration request message.

12. The method according to claim 9, wherein At least one of the first Registration Request message or the second Registration Request message indicates that the WTRU supports a periodic registration timer value and a granted periodic registration early time value.

13. The method according to claim 9, wherein: The WTRU is associated with a periodic registration time window value that is based on an expected period that the WTRU will be powered off, and wherein the periodic registration timer value and the granted periodic registration early time value are based on the periodic registration time window value.

14. The method according to claim 9, wherein A WTRU is an ambient Internet of Things (IoT) device.

15. The method according to claim 9, wherein The method also includes determining that the WTRU has sufficient available energy to perform a procedure with the network node.

16. The method according to claim 15, wherein The process of determining whether the WTRU has sufficient available energy to perform communication with a network node includes: Determine energy standards; determining an amount of energy to be used for tasks associated with the process; and The amount of energy is determined to meet the energy criteria.

Images