System information acquisition and update using ULP receiver

Abstract

The WTRU may receive an indication of a set of baseline configurations (e.g., a set of baseline configurations or a pointer / index to the set of baseline configurations). The set of baseline configurations may include at least a first baseline configuration and a second baseline configuration. The WTRU may receive first information (e.g., a first signature), where the first information indicates that the first baseline configuration is a selected baseline configuration (e.g., a current SI baseline). The first information may be received via a low power receiver. The WTRU may receive and / or determine scheduling information. The scheduling information may include at least an indication of a first schedule associated with the first update information. The WTRU may receive second information (e.g., a second signature) according to the first schedule. The second information may be indicative of the first update information (e.g., the first update information indicating an update to the selected baseline configuration).

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Application No. 63 / 279,536, filed November 15, 2021, the contents of which are incorporated herein by reference. [Background technology]

[0002] Mobile communications using wireless communications continue to evolve. The fifth generation of mobile communications radio access technology (RAT) may be referred to as 5G new radio (NR). A previous (conventional) generation of mobile communications RAT may be, for example, fourth-generation (4G) long-term evolution (LTE). Wireless communication devices may establish communications with other devices and data networks via an access network, such as, for example, a radio access network (RAN). Summary of the Invention

[0003] Disclosed herein are systems, methods, and means for a WTRU to receive system information and system information updates. The WTRU may comprise a processor, a main receiver, and a low-power receiver, where an ultra-low power (ULP) receiver may be used herein as an example of a low-power receiver. The processor may receive information via the main receiver and / or the low-power receiver, such as those described herein. The WTRU may receive a signature via the low-power receiver, where the received signature provides information that enables the WTRU to determine a selected baseline configuration and / or update a selected baseline configuration.

[0004] The WTRU may receive an indication of a set of baseline configurations (e.g., a set of baseline configurations or a pointer / index to a set of baseline configurations). The set of baseline configurations may be a baseline configuration of the system information. The set of baseline configurations may include at least a first baseline configuration and a second baseline configuration. The WTRU may receive first information (e.g., a first signature), where the first information indicates that the first baseline configuration is a selected baseline configuration (e.g., a current SI baseline). The first information may be received via a low power receiver. The WTRU may receive and / or determine scheduling information. The scheduling information may include at least an indication of a first schedule associated with the first update information. The WTRU may receive second information (e.g., a second signature) according to the first schedule. The second information may be indicative of the first update information (e.g., the first update information indicating an update to the selected baseline configuration). The first update information may be indicated by one or more of a time or a frequency associated with receipt of the second information.

[0005] The WTRU may determine a first update version of the selected baseline configuration based on the selected baseline configuration and the first update information (e.g., the first signature). The WTRU may use resources from the first update version of the selected baseline configuration, for example, until the first update version of the selected baseline configuration is updated. The scheduling information may further include an indication of a second schedule associated with the second update information, or the WTRU may separately receive an indication of the second schedule. The WTRU may receive third information (e.g., the third signature) according to the second schedule. The third information (e.g., the third signature) may be indicative of the second update information. The WTRU may determine a second update version of the selected baseline configuration based on the first update version of the selected baseline configuration and the second update information. The WTRU may use resources from the second update version of the selected baseline configuration, for example, until the second update version of the selected baseline configuration is updated. The described update features may enable system information to be changed (e.g., may enable system information to be changed without requiring an on-demand system information request).

[0006] In some examples, one or more of the following may apply: The selected baseline configuration may comprise a first set of resources and a second set of resources. The first set of resources may be a first plurality of information elements associated with a first system information block. The second set of resources may be a second plurality of information elements associated with a second system information block. The first update information may indicate an update to the first set of resources. For example, the first update information may indicate an update to the first set of resources by indicating that resources in the first set of resources should be replaced with resources from a first corresponding set of resources in the second baseline configuration. The WTRU may determine a first update version of the selected baseline configuration based on the selected baseline configuration and the first update information. The set of baseline configurations may include a third baseline configuration. The scheduling information may include an indication of a second schedule associated with the second update information. The WTRU may receive the third information according to the second schedule. The third information may be indicative of the second update information. The second update information may indicate an update to the second set of resources. The second update information may indicate an update to the second set of resources by indicating that a subset of resources in the second set of resources should be replaced with resources from a second corresponding set of resources in the third baseline configuration. The WTRU may determine a second update version of the selected baseline configuration based on the first update version of the selected baseline configuration and the second update information. The WTRU may use resources from the update version of the selected baseline configuration to perform measurements. [Brief description of the drawings]

[0007] [Figure 1A] FIG. 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B]FIG. 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] FIG. 1C is a system diagram illustrating an example Radio Access Network (RAN) and an example Core Network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1D is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 2A] FIG. 2A illustrates an example diagram of an energy detection (ED)-based mixer-first receiver. [Figure 2B] FIG. 2B illustrates an example diagram of an energy detection (ED)-based mixer-first receiver. [Diagram 3] FIG. 3 illustrates a diagram of an ultra-low power (ULP) receiver with an all-passive RF front-end. [Figure 4A] FIG. 4A illustrates a ULP network deployed with four exemplary ULP cell types. [Figure 4B] FIG. 4B illustrates a ULP network deployed with four exemplary ULP cell types. [Figure 4C] FIG. 4C illustrates a ULP network deployed with four exemplary ULP cell types. [Figure 4D] FIG. 4D illustrates a ULP network deployed with four exemplary ULP cell types. [Diagram 5] FIG. 5 illustrates an example division between the ULP RRC states and the Uu RRC states. [Figure 6] FIG. 6 illustrates time / frequency resource and SIB mapping. [Figure 7] FIG. 7 illustrates an example of continuous signaling for SI updates using a ULP receiver. [Figure 8] FIG. 8 illustrates an example of incremental signaling for SI updates using a ULP receiver. [Figure 9] FIG. 9 illustrates an example system information acquisition procedure performed by a WTRU in IDLE / INACTIVE state using a ULP receiver via signatures. [Figure 10] FIG. 10 illustrates an exemplary procedure for SI acquisition using a Uu-assisted configuration and continuous SI signaling over the ULP. [Figure 11] FIG. 11 illustrates an example of on-demand ULP SI acquisition assisted by Uu transmission. [Figure 12] FIG. 12 illustrates an example of on-demand ULP SI acquisition assisted by Uu transmission. [Figure 13] FIG. 13 illustrates an exemplary procedure for continuous and on-demand SI acquisition with Uu assistance. [Figure 14] FIG. 14 illustrates an exemplary ULP system information update procedure. [Figure 15] 15 illustrates an exemplary procedure for modifying the ULP SI signature. One or more of the following may be implemented: [Figure 16] FIG. 16 illustrates an exemplary SIB-ULP update procedure via the ULP. [Figure 17] FIG. 17 illustrates an exemplary network procedure for updating SIs, including incrementally updating the SI configuration baseline. [Figure 18] FIG. 18 illustrates an example signaling sequence for incremental SI updating using a delta SIB using a ULP receiver. [Figure 19] FIG. 19 illustrates an example of a ULP receiver enabled WTRU that implements ULP-based SI incremental updating. [Figure 20]FIG. 20 illustrates an example of a ULP receiver-enabled WTRU that performs incremental and on-demand ULP-based SI updates with the help of Uu transmission requests. [Figure 21] FIG. 21 illustrates an example of a ULP receiver enabled WTRU that performs incremental and on-demand ULP-based SI updates with the help of Uu transmission requests. [Figure 22] FIG. 22 illustrates a ULP receiver enabled WTRU that performs continuous and on-demand ULP SI updates. [Figure 23] FIG. 23 illustrates an example of a ULP receiver enabled WTRU that performs dual mode (ULP and main radio) reception of SI updates. [Figure 24] FIG. 24 illustrates a ULP receiver enabled WTRU that performs incremental / continuous SI updates using a limited set of signatures when an unsupported signature is received. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0009] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of 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), mobile stations, fixed or mobile subscriber units, subscription-based units, paging, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things devices, watches or other wearable, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0010] 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), Node B, Encode B, Home Node B, Home eNode B, gNB, NR Node B, Site Controller, Access Point (AP), wireless router, etc. Although the base stations 114a, 114b are each depicted as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0011] The base station 114a may be part of the 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. The base station 114a and / or the 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 a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell, for example, using beamforming to transmit and / or receive signals in a desired spatial direction.

[0012] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via 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).

[0013] More specifically, as noted above, the communications system 100 may be a multiple access system, but may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and the WTRUs 102a, 102b, 102c in the RAN 104 / 113 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 communications 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 ​​Uplink Packet Access (HSUPA).

[0014] 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-A Pro).

[0015] 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).

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

[0017] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless 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), or the like.

[0018] The base station 114b of FIG. 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, but may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a location of a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by a drone), a road, etc. 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 yet 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 picocell or femtocell. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0019] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as, for example, different throughput requirements, latency requirements, error 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 high-level security functions such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs employing 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 communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0020] The CN 106 / 115 may also act 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 providing 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), user datagram protocol (UDP), and / or the internet protocol (IP) of 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 RANs 104 / 113, or a different RAT.

[0021] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications 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 over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based wireless technology, and a base station 114b, which may employ an IEEE 802 wireless technology.

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

[0023] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, 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 FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0027] The processor 118 of the WTRU 102 may be coupled to, and may receive user-entered 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. In addition, the processor 118 may access information from and store data in any type of suitable 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, etc. 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).

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

[0029] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, 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 being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information by way of any suitable position determination method while remaining consistent with an embodiment.

[0030] The processor 118 may further be 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 videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

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

[0033] The RAN 104 may include eNode-Bs 160a, 160b, 160c, although it will be understood 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 an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a may transmit wireless signals to and / or receive wireless signals from the WTRU 102a using multiple antennas, for example.

[0034] 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, user scheduling, etc. in the UL and / or DL. As shown in FIG 1C, the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

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

[0036] 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 function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may 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.

[0037] The SGW 164 may be connected to each of the eNode-Bs 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 perform other functions, such as anchoring the user plane during inter-eNodeB handover, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0038] The SGW 164 may be connected to a 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.

[0039] 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 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.

[0040] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, in certain representative embodiments, it is contemplated that such a terminal may use a wired communications interface (e.g., temporarily or permanently) with the communications network.

[0041] In an exemplary embodiment, the other network 112 may be a WLAN.

[0042] A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a Distribution 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 to the STAs may arrive through the AP and be delivered to the STAs. Traffic originating from the STAs to destinations outside the BSS may be sent to the AP and transmitted to the respective destination. Traffic between STAs within the BSS may be sent, for example, through the AP, where the source STA may send traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) the source STA and the destination STA using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad-hoc" communication mode.

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

[0044] A High Throughput (HT) STA may use a 40 MHz wide channel for communication, for example, via a combination of a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

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

[0046] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including specific capabilities, such as support for (e.g., only support for) specific bandwidths and / or limited bandwidths. MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0047] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and / or limited by the STAs among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is busy due to STAs (that only support 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band may remain idle and available for use.

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

[0049] 1D is a system diagram illustrating the RAN 113 and the CN 115, according to one embodiment. As mentioned above, the RAN 113 may employ NR radio technology and communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also communicate with the CN 115.

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

[0051] 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 different or scalable lengths (e.g., including different numbers of OFDM symbols and / or lasting different lengths of absolute time).

[0052] 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 accessing another RAN (e.g., eNode-Bs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to 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-Bs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0053] Each of the gNBs 180a, 180b, 180c 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, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

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

[0055] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. The network slices may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 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, etc. 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.

[0056] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0057] The UPFs 184a, 184b may connect to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an 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 UPFs 184, 184b may perform other functions, such as, for example, routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0058] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or 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. In addition, 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 local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0059] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0060] The emulation device may be designed to perform one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and / or may perform the tests using terrestrial wireless communication.

[0061] The one or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0062] Disclosed herein are systems, methods, and means for a WTRU to receive system information and system information updates. The WTRU may comprise a processor, a main receiver, and a low-power receiver, where an ultra-low power (ULP) receiver may be used herein as an example of a low-power receiver. The processor may receive information via the main receiver and / or the low-power receiver, such as those described herein. The WTRU may receive a signature via the low-power receiver, where the received signature provides information that enables the WTRU to update a selected baseline configuration.

[0063] The WTRU may receive an indication of a set of baseline configurations (e.g., a set of baseline configurations or a pointer / index to a set of baseline configurations). The set of baseline configurations may be a baseline configuration of the system information. The set of baseline configurations may include at least a first baseline configuration and a second baseline configuration. The WTRU may receive first information (e.g., a first signature), where the first information indicates that the first baseline configuration is a selected baseline configuration (e.g., a current SI baseline). The first information may be received via a low power receiver. The WTRU may receive and / or determine scheduling information. The scheduling information may include at least an indication of a first schedule associated with the first update information. The WTRU may receive second information (e.g., a second signature) according to the first schedule. The second information may be indicative of the first update information (e.g., the first update information indicating an update to the selected baseline configuration). The first update information may be indicated by one or more of a time or a frequency associated with receipt of the second information.

[0064] The WTRU may determine a first update version of the selected baseline configuration based on the selected baseline configuration and the first update information (e.g., the first signature). The WTRU may use resources from the first update version of the selected baseline configuration, for example, until the first update version of the selected baseline configuration is updated. The scheduling information may further include an indication of a second schedule associated with the second update information, or the WTRU may separately receive an indication of the second schedule. The WTRU may receive third information (e.g., the third signature) according to the second schedule. The third information (e.g., the third signature) may be indicative of the second update information. The WTRU may determine a second update version of the selected baseline configuration based on the first update version of the selected baseline configuration and the second update information. The WTRU may use resources from the second update version of the selected baseline configuration, for example, until the second update version of the selected baseline configuration is updated. The described update features may enable system information to be changed (e.g., may enable system information to be changed without requiring an on-demand system information request).

[0065] In some examples, one or more of the following may apply: The selected baseline configuration may comprise a first set of resources and a second set of resources. The first set of resources may be a first plurality of information elements associated with a first system information block. The second set of resources may be a second plurality of information elements associated with a second system information block. The first update information may indicate an update to the first set of resources. For example, the first update information may indicate an update to the first set of resources by indicating that resources in the first set of resources should be replaced with resources from a first corresponding set of resources in the second baseline configuration. The WTRU may determine a first update version of the selected baseline configuration based on the selected baseline configuration and the first update information. The set of baseline configurations may include a third baseline configuration. The scheduling information may include an indication of a second schedule associated with the second update information. The WTRU may receive the third information according to the second schedule. The third information may be indicative of the second update information. The second update information may indicate an update to the second set of resources. The second update information may indicate an update to the second set of resources by indicating that a subset of resources in the second set of resources should be replaced with resources from a second corresponding set of resources in the third baseline configuration. The WTRU may determine a second update version of the selected baseline configuration based on the first update version of the selected baseline configuration and the second update information. The WTRU may use resources from the update version of the selected baseline configuration to perform measurements.

[0066] Systems, methods, and means for system information acquisition and updating using an ultra-low power (ULP) receiver are disclosed herein. A WTRU may use a ULP receiver to enable energy-efficient and / or latency-efficient system information acquisition and / or updating. Procedures may be implemented to support WTRU acquisition of system information (SI) via a ULP receiver using signature-based index signaling during IDLE / INACTIVE state mobility. Procedures may be implemented to support WTRU incremental SI updates over a configured signaled baseline SI set using index and low-throughput signaling to the ULP receiver. Procedures may be implemented to support WTRU requests for on-demand SI directed to a ULP receiver with assistance from a main transceiver. Procedures may be implemented to support WTRU detection of unsupported SI signatures and consideration of fallback to legacy SI acquisition and update procedures.

[0067] The WTRU, utilizing the ULP receiver, can determine the updated SI configuration using the signaled index of the baseline and / or incremental update message based on a pre-configured set of SI configurations, a list of eligible information elements (IEs) and SI blocks for incremental update, and / or a mapping between the signature-based index and the pre-configured SI configuration set.

[0068] The WTRU may receive an SI update message via the ULP receiver indicating SI blocks (SIBs) that are eligible for on-demand transmission to the ULP receiver or the main receiver. The WRU may determine interest in ULP-based SI updates based on energy budget and / or mobility. The WTRU may use the main transceiver to transmit a request for on-demand SIB transmission to the ULP receiver.

[0069] The WTRU may determine an updated SI configuration using successive signature-based index signaling for a pre-configured list of SIBs. The WTRU may determine an unsupported signature corresponding to one of the SIBs. The WTRU may fall back to an on-demand request for the missing SIB using the main transceiver.

[0070] The WTRU may determine an updated SI configuration using successive signature-based index signaling for a preconfigured ordered list of SIBs. The WTRU may use one of the determined SIBs to determine a list of SIBs that are eligible for on-demand transmission to the ULP receiver. The WTRU may transmit a request for on-demand SIB transmission to the ULP receiver using the main transceiver.

[0071] The WTRU may receive an SI update indication message via the ULP receiver indicating the SIBs eligible for ULP signaling and / or main transceiver signaling. The WTRU may determine the receiver type (ULP or main) to be utilized for the SIB configuration update based on one or more of the received update message, the energy budget, or the received signal strength. The WTRU may utilize the ULP receiver and the main receiver to receive and / or update the configuration of the corresponding SIB.

[0072] The terms normal radio, main radio, and conventional radio may be used interchangeably. The terms normal receiver, main receiver, legacy receiver, and conventional receiver may be used interchangeably, and normal radio, main radio, and conventional radio may be used interchangeably. The terms low power receiver and ultra-low power (ULP) receiver may be used interchangeably, where a ULP receiver may be an example of a low power receiver.

[0073] In wireless technologies such as cellular and WLAN, the radio frequency (RF) front end can typically be a mix of passive and active components. For example, passive components can include an Rx antenna, and / or a Tx / Rx path switch and / or a filter. Passive components may use (e.g., may not require) little or no power to function. Active components may require power to function. For example, an oscillator tuned to a carrier frequency, a low noise amplifier, and an A / D converter in the Rx path can be active components.

[0074] The RF component design may enable a type of RF circuitry that can process a received RF waveform (e.g., that may be collected by a receiving device through an antenna front end) with minimal or no use of an active power source (e.g., a receiver that receives using low power, e.g., a lower power than the main radio / receiver). A ULP receiver may be used herein as an example of a low power receiver. A type of RF circuitry (e.g., a low power receiver) may be capable of processing a received RF waveform (e.g., that may be collected by a receiving device through an antenna front end) in an ultra-low power (ULP) mode, e.g., with minimal or no use of an active power source. For example, such a device (e.g., a receiver) may be configured to use passive RF components (e.g., only passive RF components) and may harvest energy from a received RF waveform, e.g., to process a signal, e.g., a WTRU may use the energy harvested from the received waveform to operate the circuitry. In some examples, a mixer-first architecture may be used, the use of an RF low noise amplifier (LNA) may be eliminated, and / or development of passive RF components may be the focus. A passive (or nearly passive) ULP receiver may use RF components such as cascade capacitors, zero-bias Schottky diodes, MEMS, or others to implement the functions used (required) for voltage multipliers or rectifiers, charge pumps, and / or signal detectors. A ULP receiver may operate in the antenna far-field and can support a reasonable link budget.

[0075] The ULP receiver may perform (e.g., may be capable of performing) signal detection (e.g., basic signal detection), such as correlation for known signature waveforms and / or receiving low data rate signals. The ULP receiver may be configured to operate in an energy harvesting mode, e.g., the ULP receiver accumulates energy from an RF waveform entering the ULP receiver front end through the Rx antenna. Link budget characteristics of base stations (small or medium area cellular base stations) may be supported. For example, the ULP receiver may be used as a wake-up radio (e.g., to trigger a device internal wake-up and signal interrupt following detection of wake-up signaling) and prompt the main receiver (e.g., main modem) to wake up using active RF components.

[0076] A reduction in device power consumption may be realized when a ULP receiver is used. In an example, a cellular (e.g., 3G, 4G, 5G, etc.) modem transceiver may use up to hundreds of mW to demodulate and / or process received signals during reception (e.g., active reception) such as in an RRC_CONNECTED mode. Power consumption may scale depending on the number of RF front-end chains active on the device, the channel bandwidth used for reception, and / or the data rate received. In an example, a device may be in an RRC_IDLE mode, may determine that no data is being received or transmitted, and may enable a cellular wireless power saving protocol such as (e)DRX to ensure that the receiver can be configured to power on several times per second. In an example, a device may perform tasks such as measuring received signal strength of a serving cell and / or neighboring cells for purposes of a cell (re)selection procedure and / or reception of transmissions in a paging channel. In an example, a device may perform AFC and / or channel estimation, for example, to support coherent demodulation. For example, the device power consumption when the device is in RRC_IDLE may be on the order of a few mW. In examples involving enhanced MTC (eMTC) and / or narrowband (NB)-IoT, the sequence detection circuit for processing the wake-up signal (e.g., in RRC_IDLE mode) may also be implemented in the form of a wake-up receiver. In such examples, the device may power down a portion of the A / D converter and / or (e.g., digital baseband) processor. For example, if the power consumption associated with the LNA is (e.g., typically) in the milliwatt range, one or more active components in the RF front-end, such as a low noise amplifier and / or oscillator, may be used. In examples, the ULP receiver may be able (e.g., may reduce) the power consumption of the device (e.g., in RRC_IDLE mode) to about 1 mW or less, for example, by eliminating the RF LNA and the power consumption being dominated by the local oscillator.

[0077] Modulation schemes such as On-Off Keying (OOK) and Frequency-Shift Keying (FSK) may be used in a ULP receiver. OOK may be attractive (e.g., due to its simplicity) when designing a ULP radio. FIGS. 2A-2B illustrate example diagrams of an energy detection (ED)-based mixer-first receiver. FIG. 2A illustrates a simplified diagram of an ED-based mixer-first receiver for an OOK radio. FIG. 2B illustrates a simplified diagram of an ED-based mixer-first receiver for an FSK radio. FIG. 3 illustrates a simplified block diagram of a ULP receiver with a passive RF front-end (e.g., an all-passive RF front-end).

[0078] A WTRU may implement one or more of the RATs (e.g., 2G, 3G, 4G, 5G, etc.). Such a WTRU may perform PLMN selection, cell selection / reselection, and / or location registration procedures, e.g., in RRC_IDLE mode. The WTRU may support manual CSG selection or MBMS frequency prioritization, e.g., in RRC_IDLE mode, depending on capabilities. The WTRU may support RNA updates and / or operation in the RRC_INACTIVE state.

[0079] In response to the WTRU being switched on, a PLMN may be selected by the WTRU. A RAT associated with the selected PLMN may be configured. Cell selection may allow the WTRU to search for cells (e.g., preferred cells) of the selected PLMN, choose a cell for providing (e.g., to the WTRU) the cell's available services, and / or monitor a control channel of the selected cell. The WTRU may register its presence, for example, by a registration procedure (e.g., non-access stratum (NAS) registration) in the tracking area of ​​the selected cell.

[0080] In an example with a WTRU in RRC_IDLE state, the WTRU may perform received signal strength measurements on the serving cell and / or neighboring cells. If the WTRU finds a cell (e.g., a more suitable cell) according to cell reselection criteria, the WTRU may reselect the cell and camp on the cell. If the cell (e.g., a new cell) does not belong to at least one tracking area in which the WTRU may be registered, location registration may be performed. The WTRU may search for a PLMN (e.g., a higher priority PLMN), which may be performed at regular time intervals, e.g., searching for a cell (e.g., a preferred cell) if another PLMN (e.g., a higher priority PLMN) has been selected, e.g., by the WTRU's NAS (e.g., NAS layer).

[0081] A WTRU may lose coverage of a registered PLMN. A new PLMN may be selected automatically (e.g., by the WTRU). A new PLMN may be selected manually (e.g., an indication of available PLMNs may be presented to the user and the user may perform a manual selection). There may be one or more controls by which the network prioritizes cell selection for a RAT (e.g., a particular RAT) and controls the rate at which a WTRU (e.g., with low, medium, or high mobility) may perform cell reselection and / or prevent a selected tracking area from being reselected by the WTRU.

[0082] The WTRU may camp on a cell (e.g., in RRC_IDLE or RRC_INACTIVE state), may receive system information from the PLMN, may establish an RRC connection or resume a suspended RRC connection, and / or may receive ETWS or CMAS notifications. When the network needs to send a control message or deliver data to a registered WTRU, the network may know a set of tracking areas in which the WTRU may be camped. A paging message may be sent to the WTRU on the control channel of cells (e.g., all cells) in the corresponding set of areas. The WTRU may receive and respond to the paging message.

[0083] In some communication systems, before camping on a cell, a device may obtain system information of the cell and may obtain configuration parameters associated with the cell to be camped on. The system information (SI) may include parameters such as a default / common control resource set (CORESET), paging configuration information, and / or cell selection configuration information.

[0084] In an example (e.g., NR), the SI may be divided into Master Information Blocks (MIBs) and / or System Information Blocks (SIBs) and / or Positional SIBs (posSIBs). Description and retrieval of system information is described herein.

[0085] The MIB may be transmitted on the BCH with a periodicity (e.g., of 80 ms) and / or with SSB-based repetitions within a period (e.g., of 80 ms). The MIB may include parameters that may be used to obtain SIB1 from the cell. The first transmission of the MIB may be scheduled on a subframe-by-subframe basis, and the repetitions may be scheduled according to the period of the SSB.

[0086] SIB1 may be transmitted on the DL-SCH with a periodicity (e.g., 160 ms) and / or with a variable transmission repetition periodicity occurring within a period (e.g., 160 ms). The default transmission repetition period of SIB1 may be 20 ms, and the actual transmission repetition period may depend on the network implementation. In an example with SSB and CORESET multiplexing pattern 1, the SIB1 repetition transmission period may be 20 ms. In an example with SSB and CORESET multiplexing pattern 2 / 3, the SIB1 transmission repetition period may be the same as the SSB period. SIB1 may include information associated with or related to availability and scheduling of other SIBs (e.g., mapping of SIBs to SI messages, periodicity, and / or SI window size). Such availability and scheduling information may include an indication of whether one or more SIBs are provided on demand (e.g., provided only on demand) and, if a SIB is provided on demand (e.g., provided only on demand), may include configuration information used by the WTRU to implement SI requests. SIB1 may be a cell-specific SIB.

[0087] SIBs other than SIB1 and posSIB may be carried in SI messages that may be transmitted, for example, over DL-SCH. SIBs or posSIBs (e.g., SIBs or only posSIBs) with the same periodicity may be mapped to the same SI message. SIBs and posSIBs may be mapped to different SI messages. SI messages (e.g., each) may be transmitted within a periodically occurring time domain window (which may be referred to as an SI window and may have the same length for all SI messages). SI messages (e.g., each) may be associated with an SI window, and the SI windows of different SI messages may not overlap. Within an SI window, a corresponding SI message (e.g., only the corresponding SI message) may be transmitted. An SI message may be transmitted multiple times within an SI window. SIBs or posSIBs (e.g., except SIB1) may be configured to be cell-specific or area-specific, for example, using an indication in SIB1. A cell-specific SIB may be applicable within a cell that provides the SIB (e.g., only within a cell). An area-specific SIB may be applicable within an area, referred to as an SI area, which may include one or more cells and may be identified by a parameter (e.g., systemInformationAreaID).

[0088] Mapping of SIBs to SI messages may be configured in a first parameter (e.g., schedulingInfoList). Mapping of posSIB to SI messages may be configured in a second parameter (e.g., posSchedulingInfoList). SIBs (e.g., each SIB) may be included in a single SI message (e.g., only a single SI message), and each SIB and posSIB are included at most once in that SI message.

[0089] In an example involving a WTRU in RRC_CONNECTED state, the network may provide system information through dedicated signaling (e.g., using an RRCReconfiguration message), for example, if the WTRU has an active BWP that does not have a common search space configured to monitor system information or paging. The network may provide the system information in response to a request from the WTRU. The physical layer may impose a limit on the maximum size that a SIB may use. For example, the maximum SIB1 or SI message size may be 2976 bits.

[0090] SIB1 and other system information (OSI) may be sent over the DL-SCH in a PDSCH transmission and a DCI (e.g., a DCI that schedules the PDSCH transmission), which may be in DCI 1_0 format scrambled with the SI-RNTI. An indicator (e.g., in the DCI) may be set (e.g., via a system information indicator bit in the paging DCI) to identify whether the DCI includes SIB1 or OSI. Search spaces for OSI may be indicated in SIB1, for example, if they are different from the SIB1 search space.

[0091] When the network modifies the configuration of an SI, it may send a paging message (e.g., a specific paging message) to indicate the modification. The paging DCI (e.g., DCI 1_0 format scrambled with the P-RNTI) may include a short message that may include an indication, e.g., via the first two bits of the short message field, that some SI has been changed or notification has been received.

[0092] The WTRU may apply the SI acquisition procedure in response to one or more of the following: cell selection (e.g., in response to powering on), cell reselection, returning from out of coverage, entering the network from another RAT in response to reconfiguration with synchronization completion, receiving an indication that system information has changed, receiving a PWS notification, receiving a request from a higher layer (e.g., a positioning request), or determining that the WTRU does not have a valid version of a stored SIB or posSIB and / or a valid version of a requested SIB.

[0093] A ULP network may include one or more of the following cells: ULP cells or Uu cells. A ULP cell may provide a ULP interface that may enable energy-efficient data communication with limited bandwidth. In relation to a Uu cell, a ULP cell may be associated with a (e.g., normal) cell that serves a Uu air interface. A (e.g., normal) cell associated with a ULP cell may be referred to as a "Uu cell."

[0094] The ULP network may have exemplary types of ULP cells. Figures 4A-4D illustrate a ULP network deployed with four exemplary ULP cell types. Figure 4A illustrates a ULP network deployed with an exemplary ULP cell type 1. A Uu-ULP hybrid cell may serve Uu and ULP interfaces, for example, simultaneously. The Uu and ULP interfaces may have the same geographic coverage. For Uu / ULP coverage evaluation, reference signals such as UuRS (e.g., SSB) and / or ULPRS (e.g., where ULP may be used as an example of low power herein) may be used.

[0095] FIG. 4B illustrates a ULP network deployed with an exemplary ULP cell type 2. A Uu-ULP hybrid cell may serve Uu and ULP interfaces, e.g., simultaneously. The ULP interface may have a smaller geographic coverage than the Uu interface. For Uu coverage assessment, a reference signal such as UuRS (e.g., SSB) may be used. For ULP coverage assessment, a reference signal such as ULPRS may be used. A ULP cell type 2 may provide ULPRS and UuRS (e.g., SSB) (e.g., in such a manner).

[0096] FIG. 4C illustrates a ULP network deployed with an exemplary ULP cell type 3. A first ULP cell (e.g., a small ULP cell used as an example) may serve a ULP interface for paging and / or for SI (ULP-SI) for the ULP cell. A second ULP cell (e.g., a second small ULP cell used as an example) may serve a ULP interface for paging and / or for SI (ULP-SI) for the ULP cell. The first small ULP cell and the second small ULP cell may be associated with a Uu cell. The first small ULP cell and the second small ULP cell may be co-located within the coverage of a (e.g., single) Uu cell. For ULP coverage evaluation, a reference signal such as a ULPRS may be used.

[0097] 4D illustrates a ULP network deployed with an exemplary ULP cell type 4. A ULP cell (e.g., a small ULP cell used as an example) may serve a ULP interface for paging and may serve SI for the ULP cell (ULP-SI). The small ULP cell may be associated with two Uu cells, Uu cell 1 and Uu cell 2. The small ULP cell may be located at the edge of coverage of the two Uu cells.

[0098] A ULP network may be deployed using one or a combination of the ULP cell types described herein. Figure 5 illustrates an example division between ULP and Uu RRC states. The ULP RRC IDLE / INACTIVE state may be an RRC state that manages the WTRU's behavior in the IDLE / INACTIVE state using a first receiver (e.g., a ULP receiver). The Uu RRC IDLE / INACTIVE state may be an (e.g., legacy / conventional) RRC state that manages the WTRU's behavior in the IDLE / INACTIVE state using a second receiver (e.g., a conventional / legacy receiver).

[0099] A WTRU may remain in the RRC IDLE state for a large amount of time, and power consumption associated with IDLE mode operation may impact the battery life of the WTRU. The WTRU may, for example, acquire system information to determine system parameters used for the WTRU's operation in IDLE / INACTIVE mode, and / or monitor (e.g., require) an indication of an update (e.g., any update). Such operations may include one or more of monitoring a Paging Occasion (PO) to determine the presence of a network event, initiating an RRC connection establishment / resumption procedure, or transitioning to an RRC connected state. A WTRU (e.g., a WTRU implementing an ultra-low power (ULP) (e.g., passive or semi-passive) receiver) may benefit from near-zero power consumption when it is not (e.g., actively) transmitting or performing high data rate reception. To benefit from the ULP receiver and / or to extend the battery life of the WTRU, features that overcome the limited capacity of the ULP receiver for system information delivery may be implemented, and features for ULP receiver-specific system information abstraction and / or signaling may be implemented. In some examples, a Zero-Energy (ZE) receiver may consider energy harvesting to compensate for its power consumption, for example, during IDLE mode operation. In some examples herein, a ULP receiver may be integrated into a system to support energy-efficient system information acquisition and / or updates.

[0100] In some examples, signaling system information using signatures may be implemented and may use machine-type communication (MTC) system information (SI) acquisition. In some examples, SI acquisition and / or updates may be implemented when a ULP receiver is utilized to enable deep sleep (e.g., longer duration) of the (e.g., conventional / main) Uu radio. Features may be implemented to enable and / or improve system design flexibility, which may include on-demand SI signaling, several signaling formats to improve design flexibility, e.g., support for continuous, incremental, implicit, or explicit signaling, and / or handling issues related to the (e.g., potentially changing) ability of a WTRU to use indication / detection of unsupported signatures by the ULP radio.

[0101] One or more features described herein may enable system information acquisition and / or system information updates, for example, using a ULP receiver. One or more features may include indexing of system information blocks and / or information elements for signaling to a ULP receiver, which may have limited capacity and / or low data rates, for example. Features described herein may include definition of ULP-specific system information related parameters, for example, information elements. Features described herein may include enabling, signaling, and / or configuring an SI configuration set to a conventional radio of the WTRU and / or indicating an SI configuration set to a ULP radio of the WTRU (e.g., via a signature). Features described herein may include enabling, signaling, and / or configuring incremental updates of system information blocks and / or information elements, for example, using a ULP receiver. Features described herein may include, for example, enabling, signaling, and / or configuring on-demand updates of system information blocks and / or information elements using a ULP receiver and a conventional radio (e.g., a transmitter) of the WTRU. For example, the conventional radio may be used as an update configuration and / or as a fallback solution. Features described herein may include, for example, enabling, signaling, and / or configuring unsupported signatures in case of reception capability and / or detection failure.

[0102] Dual-mode SI update / acquisition may refer to an implementation in which SI update / acquisition is accomplished by a low-power receiver and / or a normal receiver. The determination of which receiver to use may depend on the configured settings for the SIB (e.g., each SIB).

[0103] The low power physical downlink control channel may be referred to as LP-PDCCH or ULP-PDCCH (e.g., where a ULP physical downlink control channel may be used as an example). The LP-PDCCH may be a physical channel (e.g., a PDCCH, a PDCCH-like channel, a newly defined physical channel, etc.) that may carry (e.g., may be capable of carrying) control signals, such as wake-up signals, and / or downlink control information (DCI) (e.g., paging DCI), having characteristics that may be specific to a ULP receiver.

[0104] The low power physical downlink shared channel may be referred to as LP-PDSCH or ULP-PDSCH (e.g., where a ULP physical downlink shared channel may be used as an example). The LP-PDSCH may be a physical channel (e.g., a PDSCH, a PDSCH-like channel, a newly defined physical channel, etc.) that may carry (e.g., may be capable of carrying) an information signal, such as a paging message, having characteristics that may be specific to a ULP receiver.

[0105] A serving Uu cell may refer to a Uu cell associated with a (e.g., current) serving ULP cell. The Uu cell may provide the configuration of the serving ULP cell and / or may provide a data communication link, e.g., for user data traffic and / or for RRC signaling to a WTRU camped on the serving ULP cell. More than one Uu cell may be associated with a single Uu cell.

[0106] A serving ULP cell may refer to a cell that serves the ULP interface for a WTRU.

[0107] A set of SI configurations may refer to a set of SI configurations that is an ensemble of system parameters for (e.g., all) SIBs.

[0108] A list of sets of SI configurations may refer to a list of sets of SI configurations, which is a collection of multiple sets of SI configurations that may be indexed.

[0109] ULP-SIB may refer to a system information block that may include ULP-related configurations.

[0110] Uu / ULP cell may refer to an implementation in which a Uu or ULP cell may represent separate physical or logical entities that may lead to different operational states, for example, a legacy Uu RRC IDLE state and a ULP RRC IDLE state.

[0111] System information elements and / or system information indexing for ULP receivers may be implemented.

[0112] Indexing of ULP-related system information elements and / or ULP-related system information elements may be implemented.

[0113] The ULP receiver may be used, for example, to determine a set of system information parameters for radio operation in an IDLE / INACTIVE mode.

[0114] The network may transmit, for example, by a conventional radio, as part of system information acquisition, a SIB, for example, an additional SIB, a new SIB, etc. (e.g., a ULP-SIB, which may be used as an exemplary SIB herein). The ULP-SIB may include information for the ULP receiver to use (e.g., can use) for decoding configured on the air channel. The SIB for the ULP may be transmitted, for example, to the Uu receiver of the conventional radio. The SIB for the ULP may be scheduled / configured within the parameters of SIB1 (e.g., SI-SchedulingInfo).

[0115] SIB1 may include information related to availability and / or scheduling of other SIBs (e.g., mapping of SIBs to SI messages, periodicity, and / or SI window size). This information may include an indication of whether one or more SIBs are provided on demand (e.g., only on demand) and, if a SIB is provided on demand (e.g., only on demand), may include configuration information used by the WTRU to implement the SI request. SIB1 may be a cell-specific SIB.

[0116] The system information parameters may be inherited from a system information block / element intended for and / or acquired by the conventional radio, which may correspond to a single cell serving the conventional radio and the ULP radio, or cells serving the conventional radio (e.g., independent and associated cells). The parameter set (which may be inherited, for example) may include one or more of a PLMN identity, a tracking area identity, or a system frame number (e.g., partial or complete).

[0117] By inheriting parameters (e.g., parameter sets), a configuration obtained for one of the interfaces may be valid for the other interfaces and may not need to be specifically updated or configured more than once.

[0118] In some examples, there may be a system information parameter set (e.g., another system information parameter set) that may be specific to a ULP receiver and may be signaled (e.g., dedicatedly signaled) to the ULP-capable WTRU. This parameter set may include one or more of the following:

[0119] The parameter set may include, for example, a PLMN identity of the ULP cell if the PLMN is dedicated for ULP operation. The PLMN information in the PLMN information list (e.g., each PLMN information) may signal whether the associated ULP cell may be used by subscribers of the PLMN.

[0120] The parameter set may include a System Frame Number (SFN), which may be included if (e.g., only if) a duty cycle is applied for ULP paging (e.g., SFN may not be included if a duty cycle is not applied for ULP paging).

[0121] The parameter set may include information of the associated Uu cell. If the ULP cell has more than one associated Uu cell, the ULP cell may be configured (e.g., may need to) signal the cell identity of the associated Uu cell. This association information may be used when the WTRU determines a serving Uu cell for accessing the Uu interface (e.g., when the WTRU receives / transmits a certain amount of data).

[0122] The parameter set may include a signature set for ULP-indexed system information signaling and / or updates. The signature may be used, for example, to identify a system information configuration set of a serving cell (e.g., a current serving cell) from two or more system information configuration sets that may be signaled to a legacy radio (e.g., via system information or (e.g., dedicated) RRC signaling (e.g., RRCReconfiguration or RRCRelease messages)) before switching to ULP radio operation. The parameter set (e.g., signature set) may include one or more of signature periodicity, scheduling information, or search space information (e.g., time and / or frequency resources), for example, based on periodic and duty-cycled operation or opportunistic reception operation.

[0123] The parameter set may include a configuration for the LP-PDCCH and (e.g., in some examples) a configuration for the LP-PDSCH. These control and data channels may be used as an alternative to signatures / sequences, for example, to carry a ULP data payload that may include a data transmission (e.g., an explicit data transmission). The configuration may be or include LP-PDCCH search space configuration information and / or LP-PDSCH scheduling information configuration. The configuration may be or include LP-DCI configuration information, e.g., modulation, repetition, etc.

[0124] The parameter set may include an indication of the presence of one or more of an LP-PSS, an LP-SSS, or a mapping to a Physical Cell Identity (PCI), which may be used by the WTRU to identify and / or measure the signal strength of the ULP cell.

[0125] The parameter set may include (e.g., in some examples) paging configuration information, which may include one or more of a ULP-specific paging search space, a ULP-specific initial paging indication configuration (e.g., presence indication, DCI format and / or search space, and / or sequence information), or a ULP-specific WTRU grouping information.

[0126] The parameter set may include an association of a Uu cell with a ULP cell. For example, the Uu cell may signal a ULP cell PCI associated with the Uu cell. The Uu cell may provide ULP cell-related configuration parameters for the associated ULP cell, and the WTRU may apply the ULP cell configuration parameters for the serving ULP cell (e.g., when the WTRU is camped on one of the associated ULP cells). The WTRU may use the Uu interface served by the Uu cell associated with the serving ULP cell (e.g., the current serving ULP cell), for example, if it is determined that the Uu interface is to be used (e.g., needs to be used).

[0127] The parameter set may include information (e.g., configurations) for SI acquisition, such as enabled features for SI acquisition, such as incremental SI update, continuous SI update, on-demand SI update, split between Uu and ULP SI, etc.

[0128] The parameter set may include a power profile for the user to use the ULP or Uu interface (eg, the percentage of remaining battery life at which the WTRU is configured to trigger the use of the ULP).

[0129] System information indexing may be implemented.

[0130] System information may be signaled, for example, using a limited number of information bits and / or (e.g., relatively) short sequences, which may help, for example, a ULP receiver (which may have limited throughput) to acquire and / or update system information parameters, regardless of the assistance of the Uu transceiver. This may involve the use and / or definition of system information signatures / sequences (e.g., signatures or sequences may be interchangeable herein) as an indexing scheme and / or mapping to (e.g., existing and / or newly) defined system information blocks and / or elements. System information signaling may include the definition of incremental system information update messages.

[0131] The SI index may be signaled via a signature (eg, a ULP signature, which may be used as an example herein).

[0132] To overcome capacity limitations and the limited number of sequences that a ULP receiver can support, SI acquisition may be compressed. The network may, for example, transmit a sequence that may act as a signature to identify which configuration set the WTRU may use when the network may decide (e.g., desire) to update or change the SI configuration. The mapping between the signature and its corresponding configuration set may be used by the WTRU and may be received (e.g., initially received) by the main radio (e.g., using a dedicated SIB configuration and / or RRC signaling) using a conventional Uu interface, under which condition the WTRU may camp on a ULP cell and / or switch to ULP receiver operation. For example, ULP-SIB list configuration information may be sent over the conventional Uu interface, for example, via system information sent from the (e.g., current) serving cell or via a (e.g., dedicated) RRC message. The configuration information may include a list of possible configuration sets (e.g., a set of baseline configurations) that may be used by ULP-capable cells in the area. The signature of a configuration set (eg, each configuration set) may be related to the configuration contents (eg, hashing the contents) or may be based on the index of the row in a list.

[0133] The signature may be network-specific or may be specific to a group of cells in a particular area. The signature (e.g., a specific signature) may be broadcast within a cell (e.g., each cell may have a specific signature). The signature may be broadcast to served ULP-enabled devices to indicate a corresponding (e.g., desired or indicated) system information configuration set (e.g., a selected baseline configuration). The signature and sequence may be received by a ULP-enabled device such as a WTRU (e.g., using a low-power correlator or receiver). For example, the signature or sequence may be received at any time (e.g., whether or not there is a predefined scheduling or timing associated with the configuration or signature). The signature may be received by a ULP receiver, for example, according to a predefined scheduling sequence. The signature may be sent following a reference signal (e.g., LP-PSS and / or LP-SSS), and the receiver may be able to identify the source of the signature (e.g., based on the received reference signal). The timing between the reference signal and the signature may be part of a scheduled / configured sequence. The timing between the RS and the signature may be part of the configuration (e.g., SIB-ULP) or may be part of the scheduling information received via the signature / sequence.

[0134] The ULP receiver may perform duty cycled monitoring of the signature, e.g., SI acquisition and / or update. If the ULP receiver uses a duty cycle, the ULP device may check the SFN of the system and check for periodicity of the SI monitoring. For example, if the periodicity of the duty cycle is N, the ULP device may monitor the signature if SFN mod N=x, x∈{0,1,...,N-1}. The network may transmit a signal in a corresponding frame, e.g., in response to, based on the duty cycle configuration, for example.

[0135] A broadcast signature (e.g., each broadcast signature) may be mapped to one or more of a complete SI configuration set including the active SIBs of the system (e.g., all active SIBs of the system), a partial / subset SI configuration set, e.g., one or more SIB configurations from the active SIBs of the system, or a partial SIB configuration or information element or set of information elements.

[0136] The network may transmit a set of configurations (e.g., a set of baseline configurations) to the WTRU, e.g., a WTRU having a ULP receiver. This transmission may be through Uu SIB or RRC signaling. The network may (e.g., subsequently) transmit a sequence, which may act as a signature to the WTRU. The WTRU may determine a configuration (e.g., a selected baseline, or a baseline to use to update a selected baseline configuration) based on the received signature, e.g., by deriving a configuration to apply based on the signature received from the network. The signature may be received by the WTRU via a low power receiver.

[0137] For example, the network and ULP devices may support multiple signatures, and eight example supported signatures may be used. The network may configure the device to have corresponding sets of four different complete SI configurations, two configuration sets specific to ULP-SIBs, and two configuration sets for specific IEs that change frequently.

[0138] The set of SI configurations may be represented as a list of sets of SI configurations, and an index (e.g., each index) of the list may map to a set of SI configurations that may be a full set of SIB parameters. This may be viewed as a big table of parameters, where an index / column combination (e.g., each index / column combination) may be / indicate a parameter. Other suitable variations of storage and representation of SI parameters are not excluded and may be implemented as well.

[0139] Continuous SI signaling may be implemented via reusable signatures.

[0140] Signaling via signatures and / or sequences may carry (e.g., extra) bits of information, e.g., that a ULP receiver may be able to search and / or decode without increasing the maximum number of signatures. The ULP interface may be able to (e.g., in such a manner) increase the number of configurations and / or configuration updates (e.g., in its limited capacity) and reduce the complexity of the received signatures.

[0141] In an example, the first indication may inform the WRTU that an SI update may be arriving and that several time slots and / or windows may be expected to include different portions of the SI configuration. A timing (e.g., each timing) may refer to a configuration sub-part, or a set of possible configurations to choose from, e.g., where the timing may be a time slot and / or a time window. For example, successive time windows (e.g., each successive time window) may correspond to an SIB update and an associated mapping configuration.

[0142] By having separate scheduling for different SIB and / or IE updates, in these (e.g., each of these) scheduled windows, the supported and available possible signatures (e.g., all supported and available possible signatures) can be reused. A mapping between the signature and associated configuration for (e.g., each) scheduled update can be sent over Uu, e.g., via a SIB or RRC reconfiguration.

[0143] If the continuous SI signaling procedure is associated with a start signal as a reference, one of the signatures received by the WTRU (e.g., at any time) may be configured to refer to the start of this procedure. In response to receiving this signature, the WTRU may start the continuous update procedure and may expect the network to send further signals for the scheduled configurations (e.g., each scheduled configuration).

[0144] In an example, the WTRU, for example, in response to receiving an identifiable signature, may determine an associated configuration change or update to implement, for example, based on the signature and the scheduling of the signature.

[0145] In a ULP physical layer configuration, timing and / or frequency specific areas in the spectrum may be defined, and the receiver may, for example, based on this configuration, identify a correspondence between a received signature and what it represents, e.g., a first signature at a particular time instance, and a frequency resource may correspond to a first SIB.

[0146] For example, time separations may be configured to update different SIBs and / or SI IEs. The timing of these time separations (e.g., windows) may be configured with respect to previous signaling indicating a frame index, a synchronization signal, and / or a subsequent signature.

[0147] The timing of each successive transmission window may be (pre)configured and shared with the ULP device. For example, the starting point of the procedure may be configured to be a given signature index, and the start time of the window (e.g., each window) (e.g., offset between the start of the window and the previous signature or window) and the duration of the window (e.g., each window) may be (e.g., jointly) configured with the corresponding meaning (e.g., SIB index). The timing configuration may relate to the OFDM symbol, slot, subframe, or absolute time and duration (e.g., ms) used by the main radio (e.g., in NR). The frequency domain configuration may relate to resource blocks, subbands, bandwidth portions, etc.

[0148] Consecutive signaling windows (e.g., two windows) may have the same duration (e.g., 5 symbols) or different durations (e.g., 5 symbols and 7 symbols, respectively). The WTRU may be able to monitor (e.g., simultaneously) two or more signatures that may be multiplexed in the frequency domain, and may interpret the frequency and time resources used to map the signatures to configured content, for example. In one example, FIG. 6 illustrates time / frequency resources and SIB mapping. In FIG. 6, four signaling resource pools are shown across two time resources (t_1 and t_2) and two frequency resources (f_1 and f_2). As shown, (t_1,f_1) maps to SIB1, (t_2,f_1) maps to SIB3, (t_1,f_2) maps to SIB5, and (t_2,f_2) maps to ULP-SIB.

[0149] The received signatures may be mapped differently.

[0150] In case of SI signaling (e.g., periodic SI indication), the indices received on the physical layer (e.g., all indices) and their respective time and frequency windows may be mapped (e.g., jointly mapped) to a logical index, which may refer to a table (e.g., a larger table) having entries for the possible SI configurations.

[0151] For SI updates, a time / frequency window (e.g., each time / frequency window) may be configured for updates (e.g., a particular update), e.g., a group of SIBs, a group of SIBs, an IE, etc. The indication (e.g., index) received in that window may refer to a table of SI configurations. The SI configuration to use (e.g., the SI configuration to use in the current instance) may be the ongoing SI configuration baseline (e.g., the selected baseline configuration) with the update if received, and the updated IE / SIB may use the value from the received index. That is, at least two indexes may be used, one for the baseline (e.g., the selected baseline configuration) and the other for the particular update that overrides the baseline value. In some examples, instead of referencing the same configuration table as the baseline, the signature in the window may refer to an index in another (e.g., additionally configured) table of SIB / IE configurations that may (e.g., also) override the baseline value.

[0152] As described herein, the WTRU may receive a set of baseline configurations (e.g., an indication of a set of baseline configurations). FIG. 7 illustrates an example of continuous signaling for SI updates to a WTRU, e.g., using a ULP receiver. FIG. 7 illustrates an example of a received set of baseline configurations in a table of SI baselines (e.g., Config#0 through #N). As shown, a sequential / sequential update indication may be received by the WTRU (e.g., via a ULP receiver), where the WTRU is using (e.g., currently using) the SI baseline configured as index 2 (e.g., current SI baseline #2 is Config#2). For example, the WTRU may be using Config#2 as a selected baseline configuration, and the selected baseline configuration may have been indicated to the WTRU as the selected baseline configuration (e.g., as described herein). Config#2 (e.g., the selected baseline The following first sequence / signature may be signaled to the WTRU (e.g., may be received by the WTRU via, e.g., a low power receiver) to indicate that SIB2 of Config#2 (e.g., the selected baseline configuration) should be modified according to the value of SI baseline configuration index 0 (e.g., Config#0). For example, as shown in FIG. 7, based on receipt of the first sequence / signature, the WTRU may replace IEs in SIB2 of Config#2 (e.g., the selected baseline configuration) with corresponding SIB2 IEs from Config#0 (e.g., resulting in a first updated version of the selected baseline configuration). Following the signaling of the first sequence / signature, a second sequence / signature may be signaled to the WTRU (e.g., may be received by the WTRU via a low power receiver) to indicate that some IEs of SIB3 (e.g., IE indexes 1 and 2) should be modified to use IE values ​​found in baseline configuration index 1 (e.g., Config#1).For example, as shown in Figure 7, based on receiving the second sequence / signature, the WTRU may replace IE#1 and IE#2 of SIB3 of the first version of the selected baseline configuration with IE#1 and IE#2 of the corresponding SIB3 from Config#1 (e.g., resulting in a second updated version of the selected baseline configuration). The second update (e.g., the second updated version of the selected baseline configuration) may be a merge of the indicated baselines for the selected IE / SIB. The first and second sequence / signatures may be the same sequence / signature or may be different sequences / signatures.

[0153] Incremental / structured partial SI update messages may be implemented.

[0154] SI may be signaled incrementally, for example, using partial SI updates that may be structured and / or completed one after the other. Having a comprehensive list of configurations for all SIBs may not be feasible in practice. The number of potential combinations for IEs in each SIB may be large, which may result in large overhead in the initial configuration (e.g., even over a conventional interface), and the index itself may have many bits to carry. An incremental approach may be used, where SI updates may be done using an SI configuration baseline and additional IE updates. To initially establish a baseline, a series of signaling may be performed. For example, the WTRU may have received a set of baseline configurations. The network may send a signature of a known SI configuration (e.g., of the set of baseline configurations) to the WTRU (e.g., received via a ULP receiver), e.g., the known SI configuration indicated by the signature may be the selected baseline configuration. The network may send one or several signals (e.g., thereafter) to indicate which IEs (e.g., if any) in the selected baseline configuration should be modified. The incremental update signal may indicate which IEs are updated and / or an indication of the update value (e.g., a value or a pointer to a value). The value indication in the incremental update may be an absolute value (e.g., a configuration value) or a relative value compared to a baseline (e.g., the configuration value intended (e.g., desired) to be used is the incremental update value plus the baseline configuration value).

[0155] If an incremental SI signaling / update procedure is configured to be supported, one of the signatures that may be received by the WTRU (e.g., at any time) may be configured to indicate the start of this procedure. In response to receiving this signature, the WTRU may initiate the incremental signaling / update procedure and may expect the network to send further signals for incremental updating of the SI configuration.

[0156] To be able to perform incremental updates, the network may send configuration information (e.g., to the WTRU) that may indicate support for ULP-based incremental updates. The configuration information may include an indication of which SIBs are covered by this feature and which are not. For example, the configuration may include a list of SIBs in a ULP-SIB IE (e.g., a dedicated IE) that indicates which SIBs may support incremental updates. The list may be expressed as a Boolean list of SIBs that should be received by the WTRU (e.g., existing or configured).

[0157] Configuration information may (e.g., also) be sent to the WTRU indicating which IEs can support incremental updates within a SIB that supports incremental updates. For example, the configuration may include a list of IEs for (e.g., related) SIBs, e.g., among IEs of a ULP-SIB, indicating which IEs support incremental updates. The list may be represented, for example, as a Boolean list of IEs (e.g., existing or configured) to be received by the WTRU in a SIB (e.g., each SIB).

[0158] For IEs for which incremental updating may be used (e.g., for each IE for which incremental updating may be possible), information regarding how the update is performed may be received (e.g., the WTRU may receive configuration information indicating how the IEs are incrementally updated), and for example, one or more of the following examples may apply.

[0159] For example, a value obtained using a hierarchical update signal may replace the value of the baseline configuration. In this case, the value obtained via the hierarchical update signal may be configured to be any possible value, and (e.g., therefore) the number of bits for this IE may be the same as the number of bits in the original SIB. In some examples, the value may be configured to be a subset of the possible values, e.g., to reduce the number of bits used (e.g., required) for this IE.

[0160] For example, a value obtained using an incremental update signal may be used, which is added to the value of the baseline configuration. The number of bits of this incremental update may be configured to be smaller than the number of bits of the (e.g., actual) IE. For consecutive integer values, if the update is coded over 3 bits, the update may generate a gain of 0 to 7 relative to the second value of the baseline. The update may be configured to have positive and negative values, e.g., -3 to +4. If the IE value is taken from a discontinuous set of values, the update value may refer to an increment of an index within that set.

[0161] For example, a partial update of a value may be sent via an SI update signal, e.g., a subset (e.g., only the subset) of bits of an IE may be configured to be sent. The subset of bits of an IE may replace bits of an IE in a baseline configuration. The partial bit update may be configured to replace three least significant bits (LSBs) of an original value. The baseline configuration may be configured (e.g., in such a manner) to have a configuration (e.g., a broad configuration), and the partial update may provide an improvement to the configuration. The subset of bits of an IE that may be configured to be replaced in a partial update may be flexible (e.g., fully flexible) and may be sent in the configuration, e.g., as a binary mask of bits for (e.g., relevant) IEs.

[0162] When configuring baselines and updates, the network may select the baseline and update the configuration to minimize overhead. For example, the network may know and / or obtain (e.g., using inter-cell coordination) potential configurations that the WTRU may receive in neighboring cells (e.g., some (e.g., a small number of) neighboring cells). The network may configure (e.g., in response) some baselines (e.g., through signatures) to be received and corresponding updates that may minimize overhead (e.g., total overhead). The network may (e.g., also) select the baseline and update the configuration, for example, based on the network's own SI configuration history.

[0163] The incremental update (e.g., sometimes referred to as a delta SIB) may include the same IEs as the originally defined SIB, and the IEs in the delta Uu SIB may be defined as optional IEs. The network may omit one or more of the IEs, and the omitted IEs may not be updated as part of the (e.g., current) SI update procedure. If not all IEs are eligible for incremental update, the eligible ones (e.g., only the eligible ones) may be listed.

[0164] Shown below are two example tables illustrating possible SIBs (eg, RRC defined SIBs) and corresponding delta SIBs / delta Uu SIBs.

[0165] [Table 1]

[0166] These examples show that the IEs in the delta SIB / delta Uu SIB are defined as optional IEs, e.g., one (e.g., only one) of the IEs (IE1, IE2, IE3, or IE4) in the delta SIBX may be present in the delta SIB / delta Uu SIB. The SIBX may include (e.g., may be required to include) mandatory IEs (e.g., all IEs (IE1-IE4) may be present).

[0167] A rough estimate of the overhead reduction that the incremental update feature may bring may be considered as the difference between the fields that do not need to be updated and the IE field indicators that are in log2 of the total number of optional IE fields. 10 bits for the indicators may be able to cover 1024 IEs, and (e.g.) the delta SIB may have very few IEs that should not be updated because the overhead cost is reduced. For 5-8 bits per IE field, there may be a net gain in overhead when two IEs are not updated. For example, for a SIB with a total load of 512 bits (e.g., maximum allowed SIB size is 2976 bits), the network would have to signal 512 bits if the desired configuration is not within the configured signature. When using the incremental approach, the network may (e.g., initially) signal a baseline configuration (e.g., 5 bits for 32 possible signatures) and incremental updates, which may depend on the number of IEs to be updated. The increment SIB may carry the log2 (e.g., 8 bits) of the number of optional IEs in the SIB, which may be used to indicate the updated fields and the values ​​of the updated IEs (e.g., 8 bits for each). If it is determined that 5 IEs get (e.g., need) an update, then 5 (signature) + 80 (5 * delta SIB) bits may be sent (e.g., instead of 512).

[0168] Incremental updates may be signaled, for example, using signatures or using (e.g., explicit) data. In the case of signatures, their corresponding content may be listed, indexed, and / or configured using IE configurations. Such methods of using signatures may limit the number and / or flexibility of potential updates.

[0169] When using explicit data, the data may be decoded (e.g., may need to be decoded) by the WRTU and sent over a ULP data channel, e.g., LP-SCH. In preparation for using the data (e.g., in front of the data) to signal incremental updates, an indication of the incoming data may be sent from the network along with a signature signal that may enable the WRTU to monitor (e.g., anticipate) the arrival of subsequent data. The WRTU may (e.g., also) resynchronize with the ULP cell so that it can accurately decode the incoming data packets.

[0170] The explicit data content may be (e.g., more easily) updatable and may include any SI configurations and / or (e.g., specific) IE elements and values. This data may (e.g., also) include, for example, an index or reference to a preset list of configurations similar to the signature configuration.

[0171] To avoid (e.g., large) overhead on the capacity-limited ULP interface, the explicit data transfer may be limited to an element (e.g., a specific element) or a group of elements. The explicit data may (e.g., also) be limited to the difference between the desired SI configuration and the SI configurations present in the list of configurations at the WTRU side.

[0172] FIG. 8 illustrates an example of incremental signaling for SI updates, e.g., signaling to a WTRU using a ULP receiver. As shown, an incremental SI update (e.g., indication of baseline+indication of use of procedure in incremental update indication) may be indicated by a signature (e.g., a dedicated signature) followed by a first signature indicating a baseline SI configuration set, e.g., a selected baseline configuration, which may be configuration set #2 (e.g., Config#2) in the example of FIG. 8. The first signature may be received, e.g., at a time offset from the SI update indication or within a first timeslot at a time offset from the received SI update indication. The WTRU may receive (e.g., after receiving the first signature) an incremental update message, e.g., a delta SIB, indicating updating two IEs in SIB2 and two IEs in SIB3 of SI configuration set #2 (e.g., the selected baseline configuration). The delta SIB may include (e.g., also include) incremental updates of the indicated IEs, e.g., IE#1 in SIB2 is increased by a value of 1. The WTRU may use the received incremental updates in the delta SIB to update the indicated selected baseline configuration, e.g., Config#2, and may apply the updated SI configuration. For example, the result may be an updated version of the selected baseline configuration. In the examples herein, resources from the updated version of the selected baseline configuration may be used by the WTRU (e.g., to perform measurements, etc.).

[0173] A specific SI update message indication may be implemented. A sequence of signatures (e.g., a particular sequence) may be used to implement (e.g., indicate) an ongoing SI update / acquisition. The sequence may indicate which SI blocks and / or elements should be updated, and the subsequent sequence may refer to the (e.g., actual) configuration to be applied to the SI blocks and / or elements (e.g., referencing an index of a corresponding configuration list). A list of configurations may be prepared for each SI block or group of SI elements, e.g., that may be configured in the SI block (e.g., in the WTRU). The list of configurations may allow a wider range of configurations and flexibility, as compared to, e.g., a list including all SI elements.

[0174] In response to the WTRU receiving the first signaling (e.g., a first signature), the WTRU may map the first signaling to an SI block or element to be updated and (e.g., then) may use the corresponding list to map subsequent signatures.

[0175] One advantage of this may be that if one block or group of elements is updated in the system (e.g., only one block or group of elements is updated in the system), the SI update may be achieved using two signature transmissions (e.g., only two signature transmissions).

[0176] The WTRU may be configured to receive multiple signatures, e.g., a first signature indicating one or more particular SIBs to be updated and a second signature indicating an index into a pre-configured set of SI configurations to be used for signaled SIB retrieval.

[0177] The WTRU may be configured to receive multiple signatures, e.g., a first signature indicating a pre-configured set of SI configurations to be used for a second signature, and the second signature indicating an index into the pre-configured set of SI configurations to be used for signaled SIB retrieval.

[0178] Identification of ULP support by Uu may be implemented.

[0179] As a condition for activating the ULP idle mode, the WTRU device may determine whether the serving cell supports ULP. One or more ways may be used to identify whether a cell supports ULP. One or more of the following may apply:

[0180] To determine if ULP is supported, the WTRU may check whether Uu SIB1 (e.g., configured according to the description herein) includes a configuration for ULP-SIB scheduling. For example, the WTRU device may determine ULP support based on the presence of a scheduled ULP-SIB in the schedulingInfoList and / or si-SchedulingInfo in SIB1. If not present, the WTRU may determine that the Uu cell does not support ULP. If present, the WTRU may determine the ULP cell ID of the ULP cell configured in the ULP-SIB for the cell that supports ULP.

[0181] The WTRU device may determine ULP support based on the correspondence between the ULP cell ID (e.g., obtained through sensing the LP-SS) and the ULP cell ID in the list of configured ULP cells (e.g., obtained through the Uu ULP-SIB).

[0182] To determine if ULP is supported, the WTRU may determine if a dedicated indicator is present in the MIB and / or SIB1.

[0183] Including a dedicated indicator in the MIB may be a costly operation (e.g., because the MIB may contain a small number of bits (e.g., only a small number of bits) and may need to be as reliable and backward / forward compatible as possible). Including a dedicated indicator in the MIB may allow a system to have a dedicated SIB1 format for including ULP-specific information (e.g., without blindly decoding several possibilities for the ULP information). Including a dedicated indicator in the MIB may allow faster identification of ULP support.

[0184] The WTRU device can determine support for ULP operation with Uu, for example, by reading the MIB content. A dedicated bit flag indicating ULP support can be added to the (e.g., existing) MIB format, for example, using spare bits in the MIB.

[0185] The inclusion of a dedicated indicator for ULP support may be implemented, for example, in SIB1 (e.g., as a bit flag) when the ULP SI is transmitted as a ULP-SIB over Uu, in which case SIB1 may indicate support (e.g., may only indicate support) and the WTRU may obtain the remaining configuration over the ULP link and / or via an RRCReconfiguration message.

[0186] The WTRU device may determine support for ULP operation with Uu, for example, by reading the SIB1 content. A dedicated bit flag indicating ULP support may be added to the (e.g., existing) SIB1 format. In response to decoding SIB1 and / or reading this bit information, ULP support may be identified.

[0187] Support for features (e.g., further specific features) may be determined, for example, from reading the contents of the ULP SIB configuration and / or the WTRU capabilities. For example, such features may include incremental updates, on-demand ULP updates with Uu assistance, and / or continuous updates or specific indication features.

[0188] During the identification of supported features, the WTRU may determine ULP-related features supported by the network, e.g., via reading a configuration received via SIB or RRC. Such features may include the manner in which the SIB should be updated, e.g., using direct signatures, incremental updates, on-demand updates, etc.

[0189] SI updates may be split between the ULP and a traditional interface (eg, a Uu interface).

[0190] The network may configure in SIB1 how other SIBs may be received, including their scheduling and / or periodicity or on-demand aspects. The scheduling / on-demand aspects of different SIBs may be different. Different SIBs may have different sizes. The importance that different SIBs may have in the system may be different.

[0191] The configuration may indicate which SIBs are configured to be obtained and / or updated over which interfaces. For example, the SIBs may be obtained or updated over the Uu or ULP interfaces, as indicated by the configuration.

[0192] The configuration may be included in SIB1. An indication may be added (e.g., specifically) for the scheduled SIBs (e.g., each of the scheduled SIBs) in SIB1. In some examples, some (e.g., a set) of the SIBs may be obtained / updated via a conventional receiver and other SIBs may be obtained / updated via a ULP receiver.

[0193] The splitting of SIB processing may be configured in the ULP-SIB. In response to the ULP-SIB being signaled to the WTRU, the WTRU may be able to determine which SIBs should be processed by which interface / receiver. The splitting of SIB processing may have the advantage of not changing the legacy SIB1 (e.g., better backward compatibility). For example, the WTRU may be configured to initially acquire the SIBs (e.g., initially) using a default or conventional interface / receiver, and the WTRU's operation via the ULP receiver may apply to updates (e.g., only updates such as signatures described herein that are used to update a selected baseline configuration).

[0194] The configurations described herein may operate in conjunction with (e.g., in addition to) configurations indicating whether a SIB is periodic or on-demand. For example, a network may configure some SIBs to be ULP and on-demand. Additional procedures related to SIBs that are configured to be ULP and on-demand are described herein.

[0195] When configured to receive Uu SIBs, the ULP receiver may be configured with several IEs (e.g., similar to those of Uu SIB1 such that the ULP receiver may receive the SIBs (e.g., correctly). For example, the ULP receiver may be configured with information associated with (e.g., regarding) availability and / or scheduling of other SIBs (e.g., mapping of SIBs to SI messages in schedulingInfoList, periodicity, SI window size), which may include an indication of whether one or more SIBs are provided on demand (e.g., provided only on demand).

[0196] The determination of which interface / receiver to use may be based on one or more of the following: The determination may be based on the overhead that the interface / receiver can represent, e.g., the size of the SIB, the size of the potential list of preset configurations to handle (e.g., sufficient) configuration alternatives, etc. The determination may be based on whether the SIB is configured to be on-demand or periodic. For example, if some of the networks or devices do not support Uu assisted on-demand ULP SIB updates, then on-demand ULP SIB updates may be carried over the Uu interface (e.g., only over the Uu interface).

[0197] In an example, the ULP receiver may be configured to receive all SIBs over the ULP interface (e.g., configured to receive may include receiving, as used herein). In an example, the ULP receiver may be configured to receive the ULP-SIB (e.g., only the ULP-SIB) over that interface. In an example, the ULP receiver may be configured to receive a portion (e.g., only a portion) of the Uu SIB over the ULP interface, and the Uu receiver may be configured to receive the remaining portion (e.g., over the Uu interface). For example, the ULP receiver may be configured to process reception of SIB1-SIB5, and the Uu receiver may be configured to process SIB6-SIB14. A WTRU that obtains SI update signaling in response to obtaining this configuration may identify which interface / receiver to use based on (e.g., using) this configuration (e.g., instead of explicit signaling).

[0198] Indexed system information acquisition and update procedures may be implemented. Procedures may be implemented to support periodic and / or on-demand system information acquisition and updates using ULP receivers. Pre-configured system information baselining and incremental update procedures may be implemented.

[0199] An indexed system information acquisition procedure may be implemented. The system information may be used by (e.g., required by) the WTRU to determine eligibility to camp on a particular cell and / or to be able to perform initial access to the network. The WTRU may utilize a conventional receiver to acquire system information of a (e.g., current) Uu serving cell used (e.g., required) for initial access to the network, may acquire a valid system information set within a defined area covered by multiple cells, and / or may utilize a ULP receiver to determine a valid system information set for a (e.g., current) Uu / ULP serving cell. In some examples, the WTRU may utilize a ULP receiver to determine a valid system information set for a (e.g., current) serving Uu / ULP cell using a default pre-configured system information set and / or a system information signature detectable by the ULP receiver.

[0200] A procedure for initial acquisition of SI may be implemented.

[0201] 9 illustrates an example system information acquisition procedure performed by a WTRU in IDLE / INACTIVE state using a ULP receiver via signature. The example system information acquisition procedure may be a procedure how a WTRU (e.g., using a conventional receiver) can acquire a system information set to assist the ULP receiver in determining system information of a serving cell (e.g., during IDLE / INACTIVE state mobility) and / or to camp on a ULP receiver serving cell utilizing SI signature signaling.

[0202] The WTRU may perform one or more of the following actions: At 100, the WTRU may perform a cell search and may attempt to synchronize with a discovered Uu cell that may satisfy the cell selection criteria. At 101, the WTRU may acquire system information about the Uu cell, e.g., after synchronization. At 102, the WTRU may store the received system information and may camp on the Uu cell, e.g., by using configuration parameters provided by the stored system information. At 103, the WTRU may determine interest / criteria for transitioning to a ULP idle mode state. At 104, the WTRU may attempt to synchronize with a ULP cell associated with the Uu cell. The associated ULP cell information may be provided by system information received from the Uu cell or by a (e.g., dedicated) RRC message (e.g., an RRCReconfiguration message). At 105, the WTRU may receive a SIB-ULP, which may be sent from the ULP cell. At 106, the WTRU may identify ULP system information for the ULP cell (e.g., system information sent from the Uu cell or a dedicated RRC message), which may be sent from the ULP-SIB list over the Uu interface. At 107, the WTRU may camp on the ULP cell, for example, by using configuration parameters in the identified ULP system information (e.g., at 106).

[0203] Different WTRUs may have different capabilities, e.g., with respect to the number of supported signatures. For example, a first WTRU may support monitoring (e.g., consistent monitoring) of six signatures, and a second WTRU may support monitoring (e.g., consistent monitoring) of ten signatures. To accommodate different WTRU capabilities, e.g., based on desired behavior / requirements for power consumption, the network may indicate unsupported signature signaling using an allocation of one of the signatures supported by the first WTRU. In some examples, the first WTRU may be (e.g., requested to) detect an unsupported signature without the help of the network, e.g., detect the absence of a supported signature during a configured window. An example of this scenario is illustrated in FIG. 10.

[0204] FIG. 10 illustrates an example procedure for SI acquisition with Uu-assisted configuration and continuous SI signaling over a ULP. The example procedure for SI acquisition may be how a WTRU (e.g., using a conventional receiver) can acquire a system information set to assist the ULP receiver in determining system information of the serving cell (e.g., during IDLE / INACTIVE state mobility) as described herein and / or to camp on the ULP receiver serving cell utilizing timed / hierarchical SI signature signaling. The WTRU may perform one or more of the following actions. The WTRU may, for example, use a conventional receiver to receive system information of the (e.g., current) serving cell and determine initial access parameters and / or support of timed / hierarchical SI acquisition of the ULP receiver (e.g., for a group of cells in a defined area). The WTRU may report ULP receiver capabilities utilizing the initial access parameters. The WTRU may request a mapping of the indexed system information set to the scheduling / signaling and / or supported signatures of the ULP receiver. The WTRU may receive the indexed system information set, the system information signaling hierarchy, and / or the mapping information. The WTRU may utilize the ULP receiver for IDLE / INACTIVE state mobility and / or indexed system information acquisition. The ULP receiver may detect the start of a hierarchical system information interval, for example, using a configured signature. The WTRU may utilize the timing / hierarchical information and / or the mapping between the supported signatures and the system information set, for example, to retrieve / update the system information of the (e.g., current) serving cell (e.g., using the ULP receiver). For example, the WTRU may utilize a first signature that may be detected within a first duration T from the detection of the configured signature to retrieve a first block of system information elements from the fifth pre-configured system information set.The WTRU utilizes a second signature (e.g., the same or different from the first detected signature) that may be detected within a second duration T following the first duration from detection of the configured signature to retrieve a second block of system information elements from the seventh preconfigured system information set. Selection of the fifth and seventh system information sets may be based on a mapping between supported signatures and system information sets. The retrieved block of system information elements from the selected system information set may depend on when the signature is detected based on the signaled hierarchical information. In some examples, the first duration may be used to indicate an update for SIB3 and the second duration may be used to indicate an update for SIB5.

[0205]

number

[0206]

number

[0207] The WTRU may detect an unsupported signature, for example, within the Nth duration of a hierarchical interval corresponding to the Nth block of a system information element (e.g., if the WTRU does not detect the start of a hierarchical system information interval using a configured signature). Determining detection of an unsupported signature may be an alternative decision to determining whether a signature is supported, as illustrated in FIG. 10. Detection of an unsupported signature may be based, for example, on failure to detect a supported signature within the Nth duration assigned to the Nth block of a system information element. If an unsupported signature is sent to a ULP receiver due to the physical characteristics of the signature, the receiver may not be able to detect the unsupported signature. An unsupported signature may be recognized as the absence of the signature within a predefined time window, which may be interpreted as an unsupported signature. In some examples, the detection of an unsupported signature may be based on the detection of a WTRU / group / globally assigned signature to detect the unsupported signature and / or failure to detect any other supported signature within the Nth duration of the hierarchical interval. In response to the detection of an unrecognized or unsupported signature, a fallback procedure may be triggered to acquire SI. For example, the WTRU may wake up its conventional radio, synchronize it (e.g., if necessary), and perform full or partial SI acquisition. One way to perform partial SI acquisition may be to use information obtained from the ULP SI procedure (e.g., timing of when an unsupported event occurred) to determine which SI or SI block has been updated, and the conventional radio may send a specific SI request if supported by the network.

[0208] The network may repeat the transmission, for example, if the network transmits a signature to the WTRU within a particular time window. Based on the repeated transmission, the ULP receiver may increase the chances of correct reception of the signature. The ULP receiver may use reception of several signatures to verify expected SI updates and / or accumulate received signals to increase signal quality.

[0209] If the network transmits a signature to the WTRU within a configured time window, and if the network recognizes that at least one WTRU does not support the signal it transmits, the network may continuously / repeatedly send the unsupported signal signature and signatures for SI acquisition / update.

[0210] In some examples, the WTRU may acquire an initial system information set (e.g., using a ULP receiver) for a (e.g., current) serving cell utilizing a default pre-configured system information set and mapping to ULP receiver detectable signatures. The WTRU may use a pre-configured (e.g., specification default) configuration and may determine initial access parameters and / or support of ULP receiver timed / hierarchical SI acquisition for a group of cells in a defined area. The WTRU may utilize the ULP receiver for IDLE / INACTIVE state mobility and / or indexed system information acquisition. The ULP receiver may detect timing-free signatures, which may be signatures that may be transmitted (e.g., at any time) without using (e.g., requiring) a time reference, e.g., a synchronization signal, a slot number, a frame number, etc. The WTRU may map the received signatures (e.g., according to a pre-configured / default mapping configuration) to SI blocks or elements and may apply the corresponding configuration. For example, the pre-configured configuration may indicate that several signatures are assigned to elements (e.g., each element) of a list of ULP SI configurations. The network may transmit a signature corresponding to a third ULP SI configuration. The WTRU device may use the third configuration in the configuration list and apply it to the ULP receiver.

[0211] The described examples may refer to time domain windows for receiving different signatures. As one skilled in the art will appreciate, these examples may apply to frequency domain and / or time domain reception of signatures (e.g., SIB indexes) that are used to indicate and map to corresponding content.

[0212] Procedures may be implemented to support on-demand SI acquisition (eg, via a ULP receiver).

[0213] In a RAT (e.g., NR), SIBs may be configured to be periodic or on-demand. On-demand SIBs may not be transmitted to a user unless requested by the user. This may be intended to minimize radio overhead and / or on-time in the system.

[0214] The MIB and SIB1 may be periodic (e.g., always periodic) as they may be required for the Uu user to operate and / or initiate a connection. Other SIBs may be configured, and the configuration of whether a SIB is periodic or on-demand may be indicated in SIB1. SIB1 may include information associated with (e.g., indicative of) the availability and / or scheduling of other SIBs (e.g., mapping of SIBs to SI messages, periodicity, SI window size), e.g., the information may include an indication of whether one or more SIBs are provided on-demand (e.g., provided only on-demand), and if a SIB is provided on-demand (e.g., provided only on-demand), the information may include a configuration used by the WTRU to implement the SI request.

[0215] The ULP receiver may not be able to transmit. To perform on-demand SIB acquisition, the WTRU may wake up its Uu transmitter and send a SIB request via the Uu transmitter.

[0216] 11-12 illustrate an example of on-demand ULP SI acquisition assisted by Uu transmission. The WTRU may perform one or more of the following actions: The WTRU may be configured to receive an on-demand SIB using a ULP receiver. In response to determining to receive an on-demand SIB, the WTRU may wake up the Uu transmitter, establish synchronization (e.g., if necessary), and prepare to transmit a SIB request, e.g., based on a request configuration. In response to receiving the request, the network may transmit a corresponding SIB over a ULP link. The WTRU may monitor and / or receive the SIB via the ULP receiver, e.g., over a configured search space.

[0217] If the WTRU detects that a desired SIB update and / or acquisition is missing from a (e.g., ongoing) procedure, it may trigger an on-demand SI acquisition. For example, if the SI change notification indicates which subsequent SIB should be updated, and the WTRU fails to detect / decode the desired SIB in the ongoing procedure, the WTRU may perform an on-demand request so that it can receive (e.g., further) SIBs.

[0218] FIG. 13 illustrates an example procedure for continuous and on-demand SI acquisition with Uu assistance. An example procedure may be, for example, how a WTRU can acquire an on-demand block of a system information element (e.g., using a ULP receiver) while implementing IDLE / INACTIVE state mobility and utilizing timed / continuous SI signature signaling. The WTRU may perform one or more of the following actions: The WTRU can receive system information of a serving cell (e.g., of a current serving cell), for example, using a conventional receiver, and can determine initial access parameters and / or support of on-demand and continuous SI acquisition of a ULP receiver, for a group of cells, for example, in a defined area. The WTRU can utilize the initial access parameters to report ULP receiver capabilities and / or request scheduling / signaling of indexed system information sets and / or mapping to supported signatures of ULP receivers. The WTRU can receive indexed system information sets, system information signaling hierarchy configuration, and / or mapping information. The WTRU may utilize a ULP receiver for IDLE / INACTIVE state mobility and / or indexed system information acquisition. The ULP receiver may detect the start of successive system information intervals and may determine a mapping between interval durations / slots and blocks of system information elements, e.g., based on a detected configured signature. The WTRU may utilize timing and / or continuity information and / or a mapping between supported signatures and system information sets, e.g., using the ULP receiver, to retrieve and / or update a determined block of system information elements for a serving cell (e.g., a current serving cell). The WTRU may determine (e.g., the need) to acquire a different block of system information elements, e.g., based on its capabilities or detection of a system information change notification.The WTRU can request a block of system information elements (e.g., a desired block) using the initial access parameters. The WTRU can receive the scheduling information and can receive the desired block of system information elements using a conventional receiver and / or a ULP receiver.

[0219] The WTRU may detect an unsupported signature, e.g., within the Nth duration of a hierarchical interval corresponding to the Mth block of a system information element (e.g., when the WTRU does not detect the start of a consecutive system information interval and / or determines a mapping between interval durations / slots and blocks of system information elements, e.g., based on a detected configured signature). Detection of an unsupported signature may be based, for example, on failure to detect a supported signature within the Nth duration assigned to the Mth block of a system information element. In some examples, detection of an unsupported signature may be based on detection of a WTRU / group / globally assigned signature to detect the unsupported signature and / or failure to detect any other supported signature within the Nth duration of a hierarchical interval.

[0220] Procedures for system information reconfiguration and / or system information updates may be implemented.

[0221] Due to the limited number of signatures that may be supported by a ULP receiver, the number of pre-configured or initially signaled system information sets may be limited and may not cover all possible combinations of system information parameters. The network may use (e.g., be planned or prepared to use) configurations that are not currently listed in the user's (pre-)configuration. Methods may be used that may allow the configuration to be modified and / or updated, and the network may have (e.g., more) flexibility in selecting SI configurations that are not already stored in the user's (pre-)configuration set.

[0222] For example, to enable system flexibility, two types of updates can be implemented.

[0223] Using the first type of update implementation, in response to a user obtaining some set of configurations, for example through (pre-)configuration, the network may be able to modify and / or update the pre-set or originally signaled system information. The set of configurations stored at the user side may be updated to reflect and / or support dynamic configuration changes from the network.

[0224] Using an implementation of the second type of update, in response to a user being assigned (e.g., initially) some SI configuration set, the network may be able to update the configuration used by the user, for example, by modifying specific IEs in addition to the baseline configuration set. This may provide a finer granularity of configuration, and the network may send specific and / or detailed updates regarding IEs or SI parameters that have not yet been configured.

[0225] The selection of which type of update to perform may be based on whether the configuration update is permanent (e.g., expected to be permanent) or long-lived (e.g., may indicate that it is better to update the list of configurations in the user's (pre-)configuration), or whether the modification is temporary. In some examples, to determine the type of update, the WTRU may identify the expected (e.g., required) overhead to obtain the desired configuration. If modification of the baseline configuration by a particular element is expected to use (e.g., require) too much overhead, e.g., especially on the ULP interface, it may be preferable to perform a change in the configured set of configurations, e.g., to indicate a baseline (e.g., a new baseline) that may require less overhead to update (e.g., this time and thereafter).

[0226] A reconfiguration of the (pre-)configured set of SI configurations may be implemented. If the network decides against performing a reconfiguration of the set of SI configurations available for selection, the network may indicate the change to the device, e.g., through signaling that initiates a procedure. For example, a dedicated signature indicating such an SI set reconfiguration may be sent over the ULP interface. Upon detecting this indication, the WTRU may follow the procedures described herein to perform an SI update, e.g., over the Uu and / or ULP interfaces.

[0227] 14 illustrates an example ULP system information update procedure. The example procedure may be how a WTRU updates its system information set using a conventional receiver to help the ULP receiver acquire a set of configurations (e.g., a baseline configuration) when the WTRU is camped on a ULP cell.

[0228] The WTRU may perform one or more of the following actions: At 200, the WTRU may receive an indication signaling a system information update (e.g., over a Uu interface) and may determine to obtain an SI update from a Uu cell associated with a (e.g., current) serving ULP cell, e.g., via a wake-up signal or a paging indication.

[0229] At 201, the WTRU may synchronize with a Uu cell associated with a ULP cell. At 202, the WTRU may obtain an updated system information block (SIB), e.g., via a network, as part of a system information update procedure (e.g., a current system information update procedure).

[0230] At 203, the WTRU may update its stored system information with the received and / or updated SIBs.

[0231] At 204, the WTRU may synchronize with a ULP cell associated with the serving Uu cell (eg, the Uu cell-ULP cell association information may come from system information or a dedicated RRC message sent from the Uu cell).

[0232] At 205, the WTRU may obtain a SIB-ULP sent from a synchronized ULP cell. The SIB-ULP may include a signature that may be used to identify ULP system information corresponding to the ULP cell.

[0233] At 206, the WTRU may use the signature provided by the SIB-ULP sent from the ULP cell to identify ULP system information corresponding to the ULP cell sent from the ULP-SIB-List over the Uu interface (e.g., system information sent from the Uu cell or a dedicated RRC message).

[0234] At 207, the WTRU may camp on the ULP cell, for example, using configuration parameters in the identified ULP system information.

[0235] When the WTRU receives an indication of an SI change (e.g., as described herein), the received indication of the SI change (e.g., a sent signal) may indicate a simple change of SI, and the WTRU may determine that it will use (e.g., require) a conventional receiver to obtain SIBs (e.g., all SIBs) from the network as part of an ongoing SI update procedure, e.g., without knowing in advance which SIBs should be updated. The WTRU may obtain (e.g., via a conventional receiver) the SIBs that the network sends to the device. If some SIBs are determined for an on-demand request (e.g., require an on-demand request), the conventional transceiver may implement the request (e.g., as described herein).

[0236] In some examples, a ULP SI change indication used to indicate an incoming SI update procedure may include an indication of which SIB or group of SIBs is being updated. In examples, this indication may be limited to a binary option, such as specifying whether the update pertains to a particular SIB and / or, in certain examples, whether this is for a ULP-SIB (e.g., the signal may indicate whether the update is for a ULP-SIB or for some other SIB). In examples, the indication may signal two or more specific SIBs to be updated, such as SIB1, a ULP-SIB, and a list of other SIBs. In examples, the indication may signal one or more IEs or groups of IEs to be updated. A combination of two or more groupings may be implemented.

[0237] The WTRU device, e.g., in response to receiving such an indication, may determine which SIBs should be updated, e.g., according to the received SI change indication and / or its device capabilities (e.g., not all devices receive SIBs for sidelink or positioning). The WTRU may proceed with the SI update procedure, e.g., using a conventional receiver as detailed below. If some SIBs are determined for on-demand request (e.g., require on-demand request), a conventional transceiver may implement the request.

[0238] The WTRU may perform one or more of the following actions: At 200′, the WTRU may receive an indication signaling an update of system information, e.g., via a Uu interface, and may determine that it obtains (e.g., requires) an SI update from a Uu cell associated with a (e.g., current) serving ULP cell, e.g., via a wake-up signal or a paging indication. The indication may (e.g., further) include a selection of which SIBs should be updated.

[0239] At 201', the WTRU may synchronize with a Uu cell associated with a ULP cell.

[0240] At 202′, the WTRU may obtain, eg, over a network, an updated system information block (SIB) as part of a system information update procedure (eg, a current system information update procedure).

[0241] At 203', the WTRU may update its stored system information with the received and / or updated SIBs.

[0242] At 204', the WTRU may synchronize with a ULP cell associated with the serving Uu cell (eg, the Uu cell-ULP cell association information may come from system information or a dedicated RRC message sent from the Uu cell).

[0243] At 205′, the WTRU may obtain a SIB-ULP sent from a synchronized ULP cell. The SIB-ULP may include a signature that may be used to identify ULP system information corresponding to the ULP cell.

[0244] At 206′, the WTRU can use the signature provided by the SIB-ULP sent from the ULP cell to identify ULP system information corresponding to the ULP cell from the ULP-SIB-list sent over the Uu interface (e.g., via system information sent from the Uu cell or a dedicated RRC message).

[0245] At 207', the WTRU may camp on the ULP cell, for example, using configuration parameters in the identified ULP system information.

[0246] The signature may indicate a ULP SI corresponding to a serving ULP cell and / or a ULP SI and SI corresponding to an associated Uu cell, in some implementations, the ULP cell and the associated Uu cell may be the same physical cell.

[0247] Scheduling information for a particular SIB may be included in the indication signal and / or a separate message following the indication. This scheduling method may represent a cross-cell scheduling mechanism. This cross-cell scheduling method may be applied not only to SI updates but also to normal DL data reception in Uu cells.

[0248] The ULP interface may be used (e.g., in the form of an SI update) to transmit a signature (e.g., in the form of an SI update) corresponding to a selection of a set of configurations for a given SIB (e.g., a new set of configurations for a given SIB), for example, specifically for a ULP-SIB. For example, a WTRU device receiving a list of possible configurations for different SIBs may detect the signature and may determine a corresponding configuration. The WTRU may (e.g., in response thereto) apply the corresponding configuration to the device. In an example of a ULP-SIB update, for example, as illustrated in FIG. 15, the ULP receiver may apply a configuration (e.g., a new configuration) and the WTRU may camp on the ULP cell. If the SIB update corresponds to a conventional SIB, the WTRU may apply the configuration to the camped Uu receiver.

[0249] FIG. 15 illustrates an example procedure of ULP SI signature modification. The WTRU may perform one or more of the following actions: At 500, the ULP cell may signal a signature (e.g., a new signature) corresponding to a ULP-SIB list provided by the serving Uu cell, for example, via a ULP SI signature modification indication. The ULP SI signature modification indication may be sent via a wake-up signal (WUS), via a paging indication, or via an LP-DCI. At 501, the WTRU may reselect a ULP SI from the ULP-SIB list provided by the serving Uu cell, for example, according to the signature, and may apply the configuration provided by the selected ULP SI.

[0250] FIG. 16 illustrates an example SIB-ULP update procedure over the ULP interface. An example procedure may be, for example, how a WTRU updates a system information set using a ULP receiver to obtain a set of configurations (e.g., a modified or new set of configurations) when the WTRU is camped on a ULP cell. The SI change indication may provide an option to use the ULP interface to update the SI. The SI change indication may indicate that the ULP-SIB is the SI (e.g., SIB) that has been determined to be updated (e.g., requires updating). In a subsequent signal, which may be a signature, the network may use the ULP interface to indicate which ULP-SIB configuration should be used. The network may have previously indicated a list of possible ULP-SIBs to be chosen, and the WTRU may have stored the list (e.g., a mapping between signatures and possible ULP-SIB configurations). The mapping may result from a received signal that may include or may be information that the ULP-SIB should be updated and a list of possible ULP-SIB configurations previously acquired by the WTRU. This method may allow for a switch or change in the (pre-)configured set of possible configurations.

[0251] The WTRU may perform one or more of the following actions: At 300, the WTRU may receive an indication (e.g., over a ULP interface) signaling an update of system information, e.g., via a wake-up signal or a paging indication.

[0252] At 301, the WTRU may receive a SIB-ULP (e.g., a new SIB-ULP), for example, via a ULP receiver, may check SI scheduling information, and / or may obtain updated SI.

[0253] At 302, the WTRU may store the configuration in the received SIB-ULP and may apply the configuration.

[0254] In some examples, the ULP cell may transmit (e.g., initially transmit) a signal to indicate a SI change that may be incoming, which may indicate that subsequent updates may use explicit data. The ULP receiver may, for example, synchronize with the ULP cell using the ULP-RS (e.g., if necessary). The network may (e.g., then) forward the corresponding update (e.g., over the ULP interface) along with the explicit data, which may be decoded by the ULP receiver device. The explicit data may include a set of IEs or SIBs to be updated. The capacity of the ULP may be smaller than the capacity of the Uu interface. The SI maximum packet size may be smaller than the maximum SI packet of Uu. Several packets may be required. If a single ULP data packet cannot carry sufficient payload, it may be possible to transmit several explicit SI update packets.

[0255] In some examples, reconfiguration of the stored SI set at the WTRU may be triggered by mobility and / or change of cell / location. For example, reconfiguration may be triggered if a radio notification area update (RNAU) or tracking area update (TAU) procedure is triggered. The SI configuration may be cell specific or may be related to a particular group of cells, e.g., a tracking area, a registration area, etc. If a WTRU located within or changing a tracking area or registration area is changing cells, the SI shall be updated (e.g., accordingly). If the WTRU knows the SI configuration for a location (e.g., a new location), e.g., through a pre-configured or acquired SI configuration, the WTRU may apply the SI configuration of the location corresponding to, e.g., the received signature. If the WTRU does not know the SI configuration, the WTRU may trigger SI acquisition from that location.

[0256] In some examples, the ULP-SIB may contain configurations to be applied across multiple ULP cells within the range or support of a given Uu cell. The configurations of the ULP cells may be identical. To reduce the size of the ULP-SIB, one configuration may be sent with a list of ULP cell IDs where the configuration may be applicable and the cell ID identification may be sufficient to determine the corresponding SI configuration. If the WTRU detects that it is within the coverage of a ULP cell that matches the ULP cell ID in the corresponding configured / signaled ULP-SIB, the WTRU may apply the obtained configuration to the ULP operation.

[0257] It is possible to use different configurations for different ULP cells, although it is expected that within a given Uu cell or several nearby cells the configurations should be similar.

[0258] In some examples, the ULP-SIB may include configurations to be applied across multiple ULP cells (e.g., from a given or multiple Uu cells). The configurations of different ULP cells may differ from each other. One way to send the configurations may be to send a list of individual configurations with the ULP cell ID as a reference for each one. One way may be to send a list of primary and / or distinct configurations for each ULP cell with their respective IDs. To know and transmit the configurations of nearby cells, the network may use cell coordination to share information of ULP configurations in its neighboring cells.

[0259] Incremental updates to the SI configuration baseline may be implemented.

[0260] 17 illustrates an example network procedure for updating an SI, including incremental updating of an SI configuration baseline. As illustrated, when the network is preparing to send an SI update, the network may determine whether the desired updated configuration is stored at the WTRU, e.g., whether the latest version of the SI configuration set sent to the WTRU includes the desired configuration. If the desired configuration is included in the latest version, then the SI change or update may be implemented, e.g., a signature indicating the SI configuration (e.g., a new SI configuration) may be sent to replace the (e.g., currently) used configuration.

[0261] If the latest version of the SI configuration set sent to the user / WTRU does not contain the desired configuration, the network can identify the difference between the desired configuration and the stored configuration available at the WTRU side. The network can select the stored configuration that is closest to the desired configuration. This configuration can act as a baseline for the incoming update. In one example, the closest configuration can mean that the network selects the configuration for which the least overhead of a particular IE / SIB update can be expected (e.g., required). One method can be, for example, to determine the number of IEs to update regardless of the value difference between the desired configuration and the selected configuration.

[0262] If the baseline configuration is not the one used by the system (e.g., currently used by the system), the network may send (e.g., initially send) a signal indicating such a baseline configuration. The network may send (e.g., further send) specific updates (e.g., additional specific updates). The IEs / SIBs included in these specific updates may replace the IEs / SIBs of the baseline configuration.

[0263] FIG. 18 illustrates an example signaling sequence for incremental SI update using delta SIB using a ULP receiver. As illustrated, SI may be updated using a ULP receiver following receipt of an SI change indication. The ULP receiver may be limited in throughput. A hierarchical approach may be implemented, e.g., the serving cell may deliver SIB information using complete SI information (e.g., first using) via a preconfigured signature mapping approach, and the ULP cell may transmit (e.g., later) the difference between the signaled SI content and the desired configuration (e.g., delta SIB). The SI sent first may be chosen by the network, e.g., to minimize the overhead cost for delta transmission. An indication of incremental update may be sent via an SI change indication signal or in a first / baseline SI indication. The delta configuration may use signature mapping if configured, or may use a data indication (e.g., explicit). Being limited to minimal changes to the (e.g., existing) SIB configuration, it may be expected that a small number of IEs (e.g., only a small number of IEs) may be determined by the WTRU to be changed (e.g., requiring change).

[0264] The WTRU may perform one or more of the following actions: At 400, the WTRU may receive an indication, e.g., via a signature / wake-up signal or a paging indication, to signal an update of the system information using a baseline configuration and incremental update signaling via a ULP receiver.

[0265] At 401, a WTRU may receive a signature that may indicate an SI configuration set baseline (e.g., a new SI configuration set baseline) from a set of SI configurations in a pre-configured or signaled (e.g., received via a conventional receiver) ULP-SIB. The WTRU may determine SI scheduling information and / or one or more parameters in the SI configuration to be updated. The SI scheduling information may be determined based on a pre-configuration, e.g., a time offset relative to when the baseline signature was received, a pre-configured set of frequency resources, a received message following reception of the baseline signature, and / or one of the SIBs included in the signaled baseline SI configuration.

[0266] At 402, the WTRU may receive a scheduled delta SIB, which may include updated parameters corresponding to the IEs / SIBs in the baseline SI configuration set. The delta SIB may indicate which IEs / SIBs are included in the current delta SIB and / or the values ​​of the IEs (e.g., new values ​​of the IEs).

[0267] At 403, the WTRU may update the stored SI configuration set received from the Uu cell (e.g., apply the configuration using the (e.g., newly) received information provided by the delta SIB).

[0268] Incremental ULP SI updates may be implemented. FIG. 19 illustrates an example of a ULP receiver-capable WTRU that performs ULP-based SI incremental updates. The WTRU may perform one or more of the following actions: The WTRU reports its ULP capabilities (e.g., to the network). The WTRU may receive SI acquisition and / or SI update configuration information. The WTRU may receive and detect an indication for an incremental system information update (e.g., as described herein). The WTRU may receive a signature, which may indicate a baseline SI configuration (e.g., a selected baseline configuration, e.g., a selected baseline configuration from a set of baseline configurations) based on the received SI acquisition configuration. The WTRU may determine scheduling information for the incremental SI update signal (e.g., based on the received incremental SI update indication (e.g., as a reference point) and the received SI update configuration) (e.g., to determine an offset from a reference point (e.g., and frequency resource). The WTRU may receive an incremental SI update signal (e.g., signature, delta SIB, etc.) as described herein, e.g., in accordance with the determined scheduling configuration, which in some examples may include an intra-frequency offset and / or an inter-frequency offset for a cell ranking criterion. The WTRU may update SI configuration parameters, e.g., based on the determined SI configuration baseline, the received incremental SI update, and / or the received SI update configuration. The WTRU may perform a cell (re)selection evaluation, e.g., based on the updated SI configuration (e.g., cell ranking criterion offset), and may camp on a cell (e.g., a new cell).

[0269] The SI acquisition configuration and / or SI updating configuration may be received using system information (e.g., system information acquired in response to powering up the WTRU (e.g., via a main radio)) and / or RRC signaling. The SI acquisition configuration and / or SI updating configuration may be valid in a serving cell (e.g., a current serving cell) and / or a set of cells in a defined area.

[0270] The SI acquisition configuration and / or SI update configuration may include one or more of a baseline SI configuration, support for incremental ULP-based SI updates, a list of IEs and corresponding SIBs that are eligible for incremental updates, or an incremental update signaling format (e.g., a subset of bits in the baseline IE value that should be replaced by an incremental update).

[0271] The detection of an indication for an incremental SI update may be performed while the WTRU is operating in IDLE or INACTIVE, eg, a ULP RRC_IDLE and / or a ULP RRC_INACTIVE state.

[0272] A configuration for an incremental update may replace a configured value with a received value, or may add a received value to a (eg, already) configured value.

[0273] On-demand incremental ULP SI acquisition and / or SI update may be implemented. FIG. 20 illustrates an example of a ULP receiver-enabled WTRU that performs incremental and on-demand ULP-based SI updates, e.g., using a ULP receiver and / or with the aid of a Uu transmission request. The WTRU may perform one or more of the following actions: The WTRU may report ULP capability information and / or receive SI acquisition configuration and / or SI update configuration information. The WTRU may detect (e.g., receive) an indication of incremental and / or on-demand SI updates. The WTRU may receive a signature, which may indicate, e.g., a baseline SI configuration (e.g., a selected baseline configuration, e.g., a selected baseline configuration from a set of baseline configurations) based on, e.g., the received SI acquisition configuration. The WTRU may transmit an on-demand request, e.g., via a main / legacy radio. The WTRU may receive and / or determine scheduling information for the ULP incremental SI update signal, e.g., based on DCI received via the main / legacy radio. The WTRU may, for example, receive an incremental SI update signal (e.g., signature, delta SIB, etc.) in accordance with the determined scheduling configuration. The WTRU may, for example, update SI configuration parameters based on the determined SI configuration baseline, the received incremental SI updates, and / or the determined SI update configuration (e.g., as described herein, for example, with reference to FIG. 7 and / or FIG. 8).

[0274] The SI acquisition configuration and / or the SI updating configuration may be received using system information and / or RRC signaling. The SI acquisition configuration and / or the SI updating configuration may be valid in a serving cell (e.g., a current serving cell) and / or a set of cells in a defined area.

[0275] The SI acquisition configuration and / or SI update configuration may include one or more of a baseline SI configuration, support for incremental ULP-based and / or Tx-assisted on-demand SI updates, a list of IEs and corresponding SIBs that are eligible for incremental updates, or an incremental update signaling format (e.g., a subset of bits in the baseline IE value that should be replaced by an incremental update).

[0276] Detection of the indications for incremental and on-demand SI updates may be performed while the WTRU is operating in the ULP RRC_IDLE and / or ULP RRC_INACTIVE states.

[0277] Detection of an indication of incremental and on-demand SI update may be determined, for example, based on detection of a signature indicating the availability of on-demand incremental SI update signaling.

[0278] Detection of an indication of incremental and on-demand SI updates may be determined, for example, based on detection of a signature indicating the availability of incremental SI update signaling and failure to decode a ULP incremental SI update (e.g., within a period of time).

[0279] The transmission of an on-demand request via the main / conventional radio may be preceded by the ULP receiver device sending a wake-up signal to the main / conventional radio and transmitting (e.g., via the main / conventional radio) a request for an initial or repeat transmission of an on-demand ULP incremental update.

[0280] The determination of the scheduling information for the ULP incremental SI update signal may be based on the received SI update configuration and / or the determined SI configuration baseline.

[0281] The updated SI configuration may include a value (e.g., a new value) of the cell ranking criteria offset. The WTRU may, for example, perform a cell (re)selection evaluation based on the updated SI configuration and may camp on a cell (e.g., a new cell).

[0282] The WTRU may send a wake-up signal to the main / conventional radio to transmit a request for an on-demand ULP incremental SI update (e.g., via the main / conventional radio) or to fall back to a conventional SI acquisition / update procedure, e.g., based on the measured received signal strength from the serving base station (BS) and / or the energy (e.g., required energy) determined to be used to complete the on-demand request transmission.

[0283] FIG. 21 illustrates an example of a ULP receiver-enabled WTRU that performs incremental updates and on-demand ULP-based SI updates, e.g., using a ULP receiver and / or with the help of a Uu transmission request. The WTRU may perform one or more of the following actions: The ULP receiver may have latency and / or energy budget constraints. The WTRU may report ULP capability information and / or receive SI acquisition configuration and / or SI update configuration information. The WTRU may detect an indication signature of an incremental SI signaling format. The WTRU may receive a signature, which may indicate a baseline SI configuration (e.g., a selected baseline configuration, e.g., a selected baseline configuration from a set of baseline configurations) based on the received SI acquisition configuration. In a first condition that the baseline signature is correctly detected and an incremental update message is missing, the WTRU may evaluate a latency tolerance. In a second condition, that the latency is determined to be unacceptable, the WTRU may transmit a request (e.g., via the main / legacy radio) for an on-demand retransmission of the ULP incremental update message. The WTRU may receive and / or determine scheduling information. The WTRU may receive an incremental SI update message (e.g., signature, delta SIB, etc.), for example, based on the received DCI and / or scheduling information. The WTRU may receive the incremental SI update message via the ULP receiver. The WTRU may update SI configuration parameters (e.g., as described herein, for example, with reference to FIG. 7 and / or FIG. 8), for example, based on the determined SI configuration baseline, the received incremental SI update, and / or the determined SI update configuration.

[0284] The SI acquisition configuration and / or the SI updating configuration may be received, for example, using system information and / or RRC signaling. The SI acquisition configuration and / or the SI updating configuration may be valid in a serving cell (e.g., a current serving cell) and / or a set of cells in a defined area.

[0285] The SI acquisition configuration and / or SI update configuration may include one or more of a baseline SI configuration, support for incremental ULP-based and / or Tx-assisted on-demand SI updates, a list of IEs and corresponding SIBs that are eligible for incremental updates, or an incremental update signaling format (e.g., a subset of bits in the baseline IE value that should be replaced by an incremental update).

[0286] Detection of incremental and on-demand SI update indications may be performed while the WTRU is operating in the ULP RRC_IDLE and ULP RRC_INACTIVE states.

[0287] The latency tolerance is determined based on a configured validity duration (e.g., a configured validity timer) and / or a ULP-based SI signaling periodicity. For example, the latency is determined to be acceptable if the SI validity time duration (e.g., the SI validity timer) is longer than at least one period of the ULP-based SI signaling. The latency is determined to be unacceptable if the SI validity time duration (e.g., the SI validity timer) is not longer than at least one period of the ULP-based SI signaling.

[0288] The latency tolerance condition may depend on the received signal strength and / or the energy budget.

[0289] The SI validity duration (e.g., an SI validity timer) may be initialized or reset upon receipt / detection of a signal / signature indicating an SI configuration that corresponds to (e.g., is identical to) an SI configuration (e.g., the SI configuration currently being used).

[0290] The transmission of an on-demand request via the main / conventional radio may be preceded by the ULP receiver sending a wake-up signal to the main / conventional radio to transmit a request for an initial or repeat transmission of an on-demand ULP incremental update.

[0291] The determination of the scheduling information for the ULP incremental SI update signal may be based on one or more of the received SI update configuration or the determined SI configuration baseline.

[0292] The WTRU may fall back to conventional SI acquisition / update procedures, e.g., if the WTRU fails to detect / decode the baseline SI configuration signature and / or the incremental SI update message, the WTRU determines that the latency is unacceptable and / or that the ULP on-demand request is below an energy budget threshold (e.g., is inefficient from an energy efficiency perspective).

[0293] The WTRU may decide to wait for another period of ULP SI signaling, for example, provided that the WTRU fails to detect / decode the baseline SI configuration signature and / or the incremental SI update message and the WTRU determines that the latency is acceptable.

[0294] The WTRU may send a wake-up signal to the main / conventional radio to transmit a request for an on-demand ULP incremental SI update (e.g., via the main / conventional radio) or to fall back to a conventional SI acquisition / update procedure, e.g., based on the measured received signal strength from the serving BS and / or the energy determined to be used (e.g., required energy) to complete the on-demand request transmission.

[0295] The baseline SI configuration may be determined, for example, by an index in the incremental update message (eg, instead of a dedicated signature indicating the baseline SI configuration).

[0296] In some examples, on-demand continuous ULP SI acquisition and / or SI update may be implemented. FIG. 22 illustrates a ULP receiver-enabled WTRU that performs continuous and on-demand ULP SI updates, e.g., using a ULP receiver. The WTRU may perform one or more of the following actions: The WTRU may report ULP capability information and / or receive SI acquisition configuration and / or SI update configuration information (e.g., which may include a continuous update signaling format and / or an SI update format). The WTRU may detect an indication of continuous and / or on-demand SI updates. The WTRU may receive a signature, which may indicate, e.g., a baseline SI configuration (e.g., a selected baseline configuration, e.g., a selected baseline configuration from a set of baseline configurations) based on the received SI acquisition configuration. The WTRU may transmit an on-demand request, e.g., via a main / legacy radio. The WTRU may receive and / or determine scheduling information for the ULP continuous and / or on-demand SI update signals, e.g., based on the received DCI. The WTRU may receive (e.g., via a ULP receiver) at least, e.g., continuously on at least one frequency resource, a first SI configuration update (e.g., according to a first detected signature) and a second SI configuration update (e.g., according to a second detected signature), e.g., based on the determined scheduling information and / or the received continuous update signaling format. The WTRU may update SI configuration parameters (e.g., as described herein with reference to FIG. 7 and / or FIG. 8), e.g., based on the determined SI configuration baseline, the received continuous and / or on-demand SI updates, and / or the determined SI update format.

[0297] The SI acquisition and / or updating configuration may be received, for example, using system information and / or RRC signaling. The SI acquisition and / or updating configuration may be valid in a serving cell (e.g., a current serving cell) and / or a set of cells in a defined area.

[0298] The SI acquisition and / or update configuration may include one or more of a baseline SI configuration, support for ULP-based continuous and / or Tx-assisted on-demand SI updates, a list of IEs and corresponding SIBs eligible for continuous and on-demand updates, and / or scheduling / format of continuous update signaling.

[0299] The continuous update signaling format may include one or more of periodicity, eligible SIB order / number, mapping between updates and indications or signatures, or on-demand eligibility of updates for (e.g., each) SIB.

[0300] Detection of indications for continuous and on-demand SI updates may be performed while the WTRU is operating in a ULP RRC IDLE state or a ULP RRC INACTIVE state.

[0301] The transmission of an on-demand request via the main / conventional radio may be preceded by the ULP receiver sending a wake-up signal to the main / conventional radio and transmitting (e.g., via the main / conventional radio) a request for an initial or repeat transmission of an on-demand ULP continuous update.

[0302] The determination of the scheduling information for the ULP continuous SI update signal may be based on the received SI update configuration and / or the determined SI configuration baseline.

[0303] The first SI configuration and / or the second SI configuration may be a (e.g., at least) subset of IEs of a SIB (e.g., at least one SIB).

[0304] The first detected signature and the second detected signature may be the same signature, which may be reused across one or more time and / or frequency resources.

[0305] The continuous SI update configuration may include a validity duration (e.g., validity time) that may be used by the WTRU to determine whether to repeat (e.g., whether it needs to repeat) the continuous update procedure, e.g., upon expiration of a duration (e.g., a timer) initialized by the configured validity duration (e.g., validity time).

[0306] Detection of an on-demand SI update indication (e.g., a determination of (e.g., the need for) a subsequent on-demand request from the WTRU) may be based on information (e.g., in the received SI update indication) indicating a determination (e.g., the need for) that one or more SIBs in the signaled baseline SI should be updated. Updates to the one or more SIBs may be sent on-demand (e.g., only on-demand).

[0307] Detection of an on-demand SI update indication (e.g., a subsequent determination of an on-demand request from the WTRU) may be based on failure to detect one or more of the signatures (e.g., within successive SI update signaling windows), where one or more of the signatures may correspond to one or more SIBs that are eligible for an on-demand request.

[0308] The WTRU may implement the features described herein in a different order than described, e.g., based on the trigger criteria for an on-demand SI update request. In an example, the baseline SI configuration and / or receipt of subsequent SI update signaling may precede the determination of (e.g., the need for) an on-demand transmission request.

[0309] In some examples, dual mode reception of SI updates may be implemented.

[0310] 23 illustrates an example of a ULP receiver enabled WTRU performing dual mode (ULP and main radio) reception of SI updates. The WTRU may perform one or more of the following actions:

[0311] The WTRU may report ULP capability information and may receive SI acquisition configuration and / or SI update configuration information. The WTRU may receive a signature indicative of a baseline SI configuration set (e.g., a selected baseline configuration, e.g., a baseline configuration selected from a set of baseline configurations) and / or may receive an indication of a system information update. The WTRU may, for example, determine ULP receiver scheduling information for a first SI configuration and / or main radio scheduling information for a second SI configuration based on the received indication (e.g., of an SI update) and / or the receive mode scheduling configuration. The WTRU may, for example, utilize the ULP and main radio receivers (e.g., simultaneously or sequentially) to receive the first and second SI configuration updates. The WTRU may update SI configuration parameters based, for example, on the determined SI configuration baseline, the received SI updates, and / or the determined SI update configuration.

[0312] The SI acquisition configuration and / or the SI updating configuration may be received, for example, using system information and / or RRC signaling. The SI acquisition configuration and / or the SI updating configuration may be valid in a (e.g., current) serving cell) and / or a set of cells in a defined area.

[0313] The SI acquisition configuration and / or SI update configuration may include an indication of support for dual mode (e.g., use of a ULP receiver and / or a main receiver) updates and / or a list of SIBs eligible for update in a certain mode (e.g., each mode), e.g., ULP Rx mode or normal Rx mode.

[0314] Detection of an indication for SI acquisition and / or update may be performed while the WTRU is operating in a ULP RRC IDLE state or a ULP RRC INACTIVE state.

[0315] The first SI configuration and / or the second SI configuration may be a (e.g., at least) subset of IEs of a SIB (e.g., at least one SIB).

[0316] The first SI configuration and / or the second SI configuration may be received, for example, using one or more of a continuous, incremental, or full update signaling format.

[0317] Handling of unsupported signatures may be implemented. Figure 24 illustrates a ULP receiver-enabled WTRU that performs incremental / continuous SI updates using a limited set of signatures when receiving an unsupported signature. The WTRU may perform one or more of the following actions:

[0318] The WTRU may report ULP capability information and / or receive SI acquisition configuration and / or SI update configuration information (e.g., which may include an SI continuous update signaling format). The WTRU may receive an SI update indication, e.g., within a configured registration, such as a tracking or notification area. The WTRU may receive, e.g., a signature indicating a baseline SI configuration (e.g., a selected baseline configuration, e.g., a selected baseline configuration from a set of baseline configurations) based on the received SI acquisition configuration. The WTRU may determine ULP scheduling information of the continuous SI update signal, e.g., based on the received SI update indication and / or configuration information. The WTRU may receive the continuous SI update signal, e.g., according to the determined scheduling information and / or the received SI continuous update signaling format. On the condition that an unsupported signature is detected, the WTRU may utilize the main radio to receive a full SIB update or a partial SIB update, e.g., based on the detected consecutive ULP-based SI updates and the correspondence between the unsupported signature and the updated SIB. The WTRU may update the SI configuration (eg, current SI configuration) based on, for example, the determined SI configuration baseline and the determined SIB updates received in the ULP and / or normal reception mode.

[0319] The SI acquisition configuration and / or the SI updating configuration may be received, for example, using system information and / or RRC signaling. The SI acquisition configuration and / or the SI updating configuration may be valid in a serving cell (e.g., a current serving cell) and / or a set of cells in a defined area.

[0320] The SI acquisition configuration and / or SI update configuration information may include one or more of a baseline SI configuration, support for ULP-based continuous or incremental SI updates, a list of IEs and corresponding SIBs eligible for continuous and / or incremental updates, or continuous and / or incremental update signaling formats.

[0321] Detection of indications for continuous and / or incremental SI updates may be performed while the WTRU is operating in a ULP RRC IDLE state or a ULP RRC INACTIVE state.

[0322] The ULP scheduling information may include one or more of a configured time offset, a time window, a time slot, a number of slots, or a frequency resource, and the configured time offset may be relative to a received SI update indication and / or a received signature indicating a baseline SI configuration set.

[0323] The main radio reception and / or request transmission (eg, of a full SIB update or a partial SIB update) may be preceded by the ULP receiver sending a wake-up signal to the main / legacy radio.

[0324] The main radio reception of a complete or partial SIB update may be preceded by the transmission of a request to receive the update, which may be via the main radio and may be based on the received SI acquisition and update configurations.

[0325] The wake-up of the main radio may be to request SI update signaling (eg, explicit SI update signaling) directed to the ULP receiver.

[0326] Use of the main radio receiver from the WTRU may be based, for example, on detection of an unsupported signature and / or a detected failure of a signature in receiving ULP signatures for incremental or continuous SI updates.

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

[0328] It will be appreciated that while the implementations described herein may consider 3GPP specific protocols, the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, while the solutions described herein consider LTE, LTE-A, new radio (NR), or 5G specific protocols, it will be appreciated that the solutions described herein are not limited to this scenario and may be applicable to other wireless systems. For example, while the systems have been described with reference to 3GPP, 5G, and / or NR network layers, contemplated embodiments extend beyond implementations using specific network layer technologies. Similarly, potential implementations extend to all types of service layer architectures, systems, and embodiments. The techniques described herein may be applied independently and / or used in combination with other resource configuration techniques.

[0329] The processes described herein may be implemented in computer programs, software, and / or firmware embodied 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 over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as Compact Disc (CD)-ROM disks, and / or Digital Versatile Disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, a terminal, a base station, a Radio Network Controller (RNC), and / or any host computer.

[0330] It is understood that the entities performing the processes described herein may be logical entities that may be implemented in the form of software (e.g., computer-executable instructions) stored in the memory of a mobile device, network node, or computer system and executed on a processor thereof. That is, the processes may be implemented in the form of software (e.g., computer-executable instructions) stored in the memory of a mobile device and / or a network node, such as a node or computer system, which computer-executable instructions, when executed by a processor of the node, perform the discussed process. It is also understood that any transmission and reception processes illustrated in the figures may be performed by the communication circuitry of the node under the control of the node's processor and the computer-executable instructions (e.g., software) that it executes.

[0331] The various techniques described herein may be implemented in connection with hardware or software, or a combination of both, as appropriate. Thus, implementations and apparatus of the subject matter described herein, or certain aspects or portions thereof, may take the form of program code (e.g., instructions) embodied in a tangible medium, including any other machine-readable storage medium, which when loaded and executed on a machine, such as a computer, causes the machine to become an apparatus for performing the subject matter described herein. When the program code is stored on a medium, the program code may be stored on one or more media that collectively perform an action, i.e., one or more media together include code for performing an action, although if there are two or more single media, any particular portion of the code need not be stored on any particular medium. In the case of program code execution on a programmable device, the computing device generally includes a processor, a storage medium (including volatile and non-volatile memory and / or storage elements) readable by the processor, at least one input device, and at least one output device. One or more programs may implement or utilize the processes described in connection with the subject matter described herein, for example, through the use of APIs, reusable controls, etc. Such programs are preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system, although the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

[0332] Although example embodiments may refer to utilizing aspects of the subject matter described herein in the environment of one or more stand-alone computing systems, the subject matter described herein is not so limited, but rather may be implemented in connection with any computing environment, such as a network or distributed computing environment. Still further, aspects of the subject matter described herein may be implemented within or across multiple processing chips or devices, and storage may be affected across multiple devices as well. Such devices may include personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems, such as automobiles and airplanes.

[0333] In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the Figures, specific terminology is used for clarity, however, the claimed subject matter is not intended to be limited to the specific terminology so selected, with the understanding that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: a processor, the processor comprising: receiving an indication of a set of baseline configurations, the set of baseline configurations including at least a first baseline configuration and a second baseline configuration; receiving first information, the first information indicating that the first baseline configuration is a selected baseline configuration; determining scheduling information, the scheduling information including at least an indication of a first schedule associated with the first update information; and receiving, in accordance with the first schedule, second information indicating the first update information, the first update information indicating a change to the selected baseline configuration.

2. The WTRU of claim 1 , further comprising a main receiver and a low power receiver, the first information being received via the low power receiver.

3. The WTRU of claim 1 , wherein the processor is further configured to determine a first update version of the selected baseline configuration based on the selected baseline configuration and the first update information.

4. 4. The WTRU of claim 3, wherein the scheduling information includes an indication of a second schedule associated with second update information, and the processor is further configured to receive third information in accordance with the second schedule, the third information indicating the second update information.

5. 5. The WTRU of claim 4, wherein the processor is further configured to determine a second update version of the selected baseline configuration based on the first update version of the selected baseline configuration and the second update information.

6. The WTRU of claim 4 , wherein the first information comprises a first signature, the second information comprises a second signature, and the third information comprises a third signature.

7. The WTRU of claim 1 , wherein the first update information is indicated by one or more of a time or a frequency associated with receipt of the second information.

8. 2. The WTRU of claim 1 , wherein the selected baseline configuration includes a first set of resources and a second set of resources, the first set of resources being a first plurality of information elements associated with a first system information block, the second set of resources being a second plurality of information elements associated with a second system information block, the first update information indicating an update to the first set of resources, the first update information indicating the update to the first set of resources by indicating that resources in the first set of resources are replaced with resources from a first corresponding set of resources in the second baseline configuration, and the processor is further configured to determine a first update version of the selected baseline configuration based on the selected baseline configuration and the first update information.

9. 9. The WTRU of claim 8, wherein the set of baseline configurations includes a third baseline configuration, the scheduling information includes an indication of a second schedule associated with second update information, and the processor is further configured to receive third information in accordance with the second schedule, the third information indicating the second update information.

10. 10. The WTRU of claim 9, wherein the second update information indicates an update to the second set of resources, the second update information indicating the update to the second set of resources by indicating that a subset of resources in the second set of resources are to be replaced with a subset of resources from a second corresponding set of resources in the third baseline configuration, and the processor is further configured to determine a second update version of the selected baseline configuration based on the first update version of the selected baseline configuration and the second update information.

11. The WTRU of claim 10 , wherein the processor is further configured to use resources from an updated version of the selected baseline configuration to perform measurements.

12. The WTRU of claim 1 , wherein the set of baseline configurations is a set of system information baseline configurations.

13. 1. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: receiving an indication of a set of baseline configurations, the set of baseline configurations including at least a first baseline configuration and a second baseline configuration; receiving first information, the first information indicating that the first baseline configuration is a selected baseline configuration; determining scheduling information, the scheduling information including at least an indication of a first schedule associated with the first update information; receiving second information in accordance with the first schedule, the second information indicating the first update information.

14. 14. The method of claim 13, wherein the WTRU comprises a main receiver and a low power receiver, the first information is received via the low power receiver, the first information includes a first signature, the second information includes a second signature, and the third information includes a third signature.

15. determining a first update version of the selected baseline configuration based on the selected baseline configuration and the first update information, wherein the scheduling information includes an indication of a second schedule associated with second update information; receiving third information in accordance with the second schedule, the third information indicating the second update information; and 2. The WTRU of claim 1, further comprising: determining a second update version of the selected baseline configuration based on the first update version of the selected baseline configuration and the second update information.

Images