Power saving operation
By implementing beam fault detection and recovery methods in the wireless transmitting/receiving unit, the problem of low beam fault detection and recovery efficiency in the prior art is solved, and more efficient wireless communication signal operation is achieved.
Patent Information
- Application Number
- CN202411549234.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2019-10-01
- Filing Date
- 2020-08-12
- Publication Date
- 2025-03-04
AI Technical Summary
The prior art is difficult to efficiently detect and recover beam faults in wireless communication, resulting in low signal operation efficiency.
By implementing a beam fault detection and recovery method in a wireless transmit/receive unit (WTRU), it includes determining the beam quality, selecting the preferred beam for failure recovery, and sending an indication message to the base station.
Improves the efficiency of beam fault detection and recovery, reduces signal operation time in wireless communication, and improves the overall performance of the system.
Smart Images

Figure CN119561591A_ABST
Abstract
Description
[0001] This divisional application is a divisional application with a filing date of August 12, 2020, application number 202080062529.X, and invention name “Power saving signal operation”.
[0002] CROSS-REFERENCE TO RELATED APPLICATIONS
[0003] This application claims the benefit of U.S. Provisional Application No. 62 / 886,175, filed on August 13, 2019, and U.S. Provisional Application No. 62 / 909,143, filed on October 1, 2019, the contents of which are incorporated herein by reference. Background Art
[0004] Mobile communications using wireless communications continue to evolve. The fifth generation of mobile communications may be referred to as 5G. Previous (eg, legacy) mobile communications may be, for example, fourth generation (4G) long term evolution (LTE). Summary of the invention
[0005] Systems, methods, and tools for power save signaling operations are described herein. The power save signaling operations may include beam failure detection (e.g., beam failure wakeup signal (BF-WUS) detection) and beam failure recovery (BFR) operations (e.g., WUS-BFR operations). In an example, a wireless transmit / receive unit (WTRU) may include a processor configured (e.g., programmed with executable instructions to implement the method) to determine a first set of beams and a second set of beams; determine that a corresponding quality of each beam in the first set of beams is less than a predetermined quality value, determine that a beam in the second set of beams but not in the first set of beams has a quality equal to or greater than the predetermined quality value; select a beam in the second set of beams but not in the first set of beams and whose quality is equal to or greater than the predetermined quality value for BFR; send a message to a gNB indicating the selected beam for BFR; and receive a message from the gNB including the selected beam.
[0006] The first set of beams and the second set of beams may not overlap.The first set of beams may be a subset of the second set of beams.
[0007] The respective quality of (e.g., each) beam in the first set of beams may be determined, for example, during a first time period. The quality of beams in the second set of beams but not in the first set of beams may be determined, for example, during a second time period. In an example, the second time period may be after the first time period. In an example, the first time period and the second time period may overlap in time.
[0008] The message received from the gNB may include, for example, a reconfiguration message indicating that the selected beam is to be included in the first set of beams.
[0009] The WTRU processor may be further configured with executable instructions to further implement the method: monitoring the first set of beams for a signal type. The beam failure recovery may be for a beam failure associated with the monitoring of the signal type. The beam failure may be different from a radio link failure associated with using the first set of beams.
[0010] The WTRU processor may be further configured with executable instructions to further implement the method: before discontinuous reception (DRX)-on, monitoring the WUS using a first set of beams; and during DRX-on, monitoring physical downlink control channel transmission using a second set of beams. The first set of beams may be a subset of the second set of beams.
[0011] The BFR may include a WUS-BFR. The WTRU processor may be further configured with executable instructions to further implement the method of skipping decoding of the WUS in the WUS-BFR, and monitoring the WUS using the selected beam based on a message received from the gNB.
[0012] One or more examples herein may be implemented (e.g., in whole or in part), for example, by one or more devices, apparatuses, and / or systems (e.g., WTRUs, network nodes such as gNodeBs (gNBs), etc.) that may include one or more processors configured to perform methods (e.g., in whole or in part) in accordance with computer-executable instructions that may be stored on a computer-readable medium or a computer program product that, when executed by the one or more processors, perform the methods. The computer-readable medium or computer program product may include instructions that cause the one or more processors to perform the methods by executing the instructions.
[0013] A wireless transmit / receive unit (WTRU) may be configured (e.g., dynamically) to detect a control resource set (CORESET) and / or a transmission configuration indicator (TCI) state for a wake-up signal. The wake-up signal (WUS) may also be referred to as a power save signal (PSS). For example, the WTRU may dynamically detect a CORESET and / or TCI state for a WUS, for example, based on the CORESET configuration of an associated on-duration. The CORESET (e.g., CORESET_PSS) in which the PSS is transmitted may be determined, for example, based on a CORESET with a configured on-duration and / or one or more configured parameters of a search space configured in the associated on-duration. The WTRU may determine the TCI state of the CORESET_PSS, for example, based on CORESET_ON and / or one or more configured parameters of a search space configured in the associated on-duration.
[0014] For example, during certain periods, the WTRU may be allowed not to monitor for WUS. For example, the WTRU may be configured not to monitor for WUS in a particular state to avoid misinterpreting / misdetecting a signal as a WUS. The WTRU may enter an awake state and may not monitor for WUS when it is not in the awake state. The WTRU may be configured to remain in the awake state regardless of whether a WUS has been received. The WTRU may be configured to ignore WUS under various conditions (e.g., when the WTRU is not in the awake state).
[0015] A specific type of signal (e.g., aWUS) may be used and may be associated with beam failure detection and / or recovery. The WTRU may measure the beam quality of one or more beam reference signals associated with a configured CORESET. For example, if the beam measurement quality is below a threshold, the WTRU may determine that the beam may have failed. If the beam measurement quality of the preferred beam is above a threshold, the WTRU may determine the preferred beam. For example, the WTRU may perform WUS monitoring using a subset of beams in a set of beams for monitoring a physical downlink control channel (PDCCH). The WTRU may detect a beam failure for WUS monitoring (BF-WUS) based on failure of all beams in the beam subset. The WTRU may identify (e.g., based on a quality threshold) at least one beam in the set of beams but not in the beam subset (e.g., not configured for WUS) as at least one preferred beam for WUS beam failure recovery (BFR). The WTRU may request WUS-BFR by notifying network nodes around the BF-WUS and by indicating the at least one preferred beam for WUS-BFR. The WTRU may receive a reconfigured WUS beam (eg, including the at least one preferred beam) from the network node for WUSBFR.
[0016] The WTRU may be configured to resolve inconsistent signaling between information derived from a wake-up signal and cross-slot scheduling information and / or scheduling downlink control information (DCI). In an example, the PSS may include additional information for the WTRU. For example, the PSS may indicate to the WTRU whether the WTRU implements cross-slot scheduling. The PSS may indicate to the WTRU, for example, whether the WTRU is switching from one bandwidth part (BWP) to another BWP.
[0017] The WTRU may be configured to operate in a cross-slot scheduling mode. The WTRU may be configured to operate according to a power saving state. In an example, the WTRU may be configured to operate according to one or more (e.g., a set of) power saving states. The power saving state may indicate that a particular entry of a time division relay access (TDRA) table is excluded. For example, a WTRU in a given power saving state may determine that a particular TDRA table may not be used for data scheduling.
[0018] Multiple-input multiple-output (MIMO) adaptation may be performed, for example, per BWP and / or based on the BWP being used. For example, a number of antenna ports may be determined per BWP for transmission and / or reception. For example, if the number of antenna ports is determined per BWP, the number of bits used in the antenna port field of the DCI may be different, for example, depending on the BWP to which the DCI is applied. The WTRU may be configured to interpret the antenna port field of the DCI, for example, based on the BWP to which the DCI is applied.
[0019] The WTRU may be configured with one or more power saving signal / wake-up signal offsets for short discontinuous reception (DRX). The offset indication may be implicit, for example, associated with the search space configuration. The offset configuration may be explicit. BRIEF DESCRIPTION OF THE DRAWINGS
[0020] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;
[0021] Figure 1B It is shown that according to one embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within the communication system shown;
[0022] Figure 1C It is shown that according to one embodiment, Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the illustrated communication system;
[0023] Figure 1D It is shown that according to one embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in the communication system shown;
[0024] Figure 2 An example of discontinuous reception (DRX) is shown.
[0025] Figure 3 An example of a CORESET for a Physical Downlink Control Channel (PDCCH) in active time and / or WUS is shown.
[0026] Figure 4 An example of a CORESET monitored in a time slot of active time is shown.
[0027] Figure 5 An example of a method for beam failure detection and recovery is shown.
[0028] Figure 6 An example of a method of beam failure detection and restoration for WUS monitoring is shown. DETAILED DESCRIPTION
[0029] Figure 1A 1 is a schematic diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.
[0030] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.
[0031] 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 that is configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.
[0032] 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), a relay node, 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 cells (not shown)). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrums. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, 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, beamforming may be used to transmit and / or receive signals in a desired spatial direction.
[0033] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).
[0034] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed Downlink (DL) Packet Access (HSDPA) and / or High Speed UL Packet Access (HSUPA).
[0035] 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 Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).
[0036] 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).
[0037] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).
[0038] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rates for Evolution (EDGE), GSM EDGE (GERAN), etc.
[0039] Figure 1A The base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In 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 a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.
[0040] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay 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 described in detail in the specification, the CN 106 / 115 may be configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Figure 1AAlthough not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.
[0041] 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 that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.
[0042] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
[0043] Figure 1B is a system diagram illustrating an exemplary WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.
[0044] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
[0045] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via an air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive RF and light signals. It should be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.
[0046] Although the transmit / receive element 122 is Figure 1B 1 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.
[0047] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As noted 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 NR and IEEE 802.11.
[0048] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit) and may receive user input data therefrom. 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 a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
[0049] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.
[0050] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.
[0051] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral device 138 may include one or more sensors, which may be one or more of the following: 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.
[0052] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous.
[0053] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.
[0054] The RAN 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the evolved Node-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.
[0055] Each of the evolved Node Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.
[0056] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.
[0057] The MME 162 may be connected to each of the evolved Node-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach 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.
[0058] The SGW 164 may be connected to each of the evolved Node-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-evolved Node-B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.
[0059] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
[0060] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication 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.
[0061] Although the WTRU Figures 1A to 1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may (eg, temporarily or permanently) use a wired communications interface with a communications network.
[0062] In a representative embodiment, the other network 112 may be a WLAN.
[0063] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and leading to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be sent to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be sent by the AP, for example, wherein the source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be sent between the source and destination STAs (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.
[0064] When using the 802.11ac infrastructure operating mode or a similar operating mode, the 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 dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (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.
[0065] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.
[0066] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. For example, each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be transmitted by transmitting STA. At the receiver of the receiving STA, the above-mentioned operations for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).
[0067] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).
[0068] WLAN systems that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only the 1MHz operating mode) is transmitting to the AP, the entire available frequency band may be considered busy even if most of the frequency bands remain idle and may be available.
[0069] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.
[0070] Figure 1D 1 is a system diagram showing the RAN 113 and the CN 115 according to one embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.
[0071] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation techniques. 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 unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).
[0072] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).
[0073] 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 while also not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use 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 an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate or connect with the gNBs 180a, 180b, 180c while also communicating or connecting with other RANs, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the evolved Node-Bs 160a, 160b, 160c may serve 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.
[0074] 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 UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.
[0075] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.
[0076] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c via the N2 interface in the RAN 113 and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRU 102a, 102b, 102c based on the type of services used by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced 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.
[0077] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating 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.
[0078] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.
[0079] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. 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 via the UPF 184a, 184b via an N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.
[0080] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b and / or any other device described herein. The simulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.
[0081] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices may perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communications to perform testing.
[0082] The one or more simulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device may be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which may include one or more antennas) may be used by the simulation device to transmit and / or receive data.
[0083] Discontinuous reception (DRX) may be used to reduce or save energy usage (e.g., to save battery). A WTRU may use DRX to stop monitoring DL control channels (e.g., physical downlink control channel (PDCCH)) during certain sleep periods. A WTRU (e.g., in radio resource control (RRC) connected mode) may use connected mode DRX (C-DRX). Figure 2 An example of discontinuous reception (DRX) is shown. Figure 2 The on-duration and off-duration within the DRX cycle are shown. The WTRU may monitor the configured PDCCH during the on-duration. During the off-duration, the WTRU may sleep (e.g., not monitor the PDCCH). PDCCH may be used as a non-limiting example of a DL control channel in this document.
[0084] During the OFF Duration of the DRX cycle, the WTRU may not measure or report channel state information (CSI) in the time units (e.g., subframes) configured to measure and / or report periodic CSI reports. The WTRU may monitor the PDCCH and / or PDCCH opportunities during the Active Time of the DRX cycle. The Active Time may occur during the ON Duration. The Active Time may occur during the OFF Duration. The Active Time may start during the ON Duration and / or continue during the OFF Duration and / or vice versa.
[0085] Active time may include time when at least one of the following is true: a DRX timer is running (e.g., including one or more of an on-duration timer, an inactivity timer, a retransmission timer in the DL and / or UL, a random access contention resolution timer, etc.); a scheduling request may be sent and / or waited for; after successfully receiving a random access response to a random access preamble that was not selected by the MAC entity among contention-based random access preambles, a PDCCH indicating a different transmission of a cell radio network temporary identifier (C-RNTI) addressed to the MAC entity of the WTRU has not been received.
[0086] The signal type (wake-up signal (WUS) and / or go-to-sleep signal (GOS) (WUS / GOS)) may be used, for example, with DRX operation. The WUS / GOS may be associated with one or more DRX cycles. For example, the WUS / GOS may be transmitted and / or received (transmit / receive) before an associated time. For example, the WUS / GOS may be transmitted and / or received (transmit / receive) before a portion of an associated DRX cycle.
[0087] A WTRU (e.g., having received a WUS) may monitor the PDCCH, for example, during the on-duration of one or more DRX cycles. A WTRU (e.g., having received a GOS) may skip monitoring the PDCCH, for example, during the on-duration of one or more DRX cycles, and / or may remain in a sleep mode. In an example, the sleep mode may include deep sleep.
[0088] A system or network (e.g., New Radio (NR) for a 5G wireless system) may use WUS and / or GOS. A signal / channel may be used to transmit a wake-up or sleep indication. For example, a bit field in a signal (e.g., a PDCCH-based signal) may indicate whether the WTRU should perform a wake-up or sleep. The signal (e.g., indicating wake-up or sleep) may include a power saving signal or may be referred to as a power saving signal. For example, a power saving signal may be transmitted before the start of the on-duration of a DRX cycle. The time interval between the power saving signal and the start of the on-duration may include an offset or may be referred to as an offset (e.g., a WUS offset). The offset may be measured in one or more units such as ms, time slots, OFDM symbols, etc. The offset may be measured from the beginning or end of the power saving signal.
[0089] The PDCCH and / or search space may be used (e.g., in NR for 5G systems) to provide the WTRU with an opportunity to receive downlink control information (DCI). Different structures may be used for the PDCCH and / or physical downlink shared channel (PDSCH) in different systems (e.g., 4G and 5G systems). Slot-based transmissions, non-slot-based transmissions, and / or different monitoring rates may be used for the PDCCH.
[0090] In an example, a resource element group (REG) may be the smallest building block of a PDCCH. (Eg, each) REG may include multiple (e.g., 12) resource elements (REs) in time on (e.g., one) OFDM symbol and in frequency on (e.g., one) resource block (RB). In an example, (e.g., each) REG may include nine (9) REs for control information and three (3) REs for demodulation reference signals (DM-RS). Multiple (e.g., 2, 3, or 6) REGs that may be adjacent in time or frequency may form a REG bundle that may be used with the same precoder. DM-RSs for multiple REGs may be used together for channel estimation. Multiple (e.g., six (6)) REGs (e.g., in the format of 1, 2, or 3 REG bundles) may form (e.g., one) control channel element (CCE), which may be the smallest possible PDCCH. (Eg, each) PDCCH may include one or more (e.g., multiple) CCEs (e.g., 1, 2, 4, 8, or 16 CCEs). The number of CCEs used for a PDCCH may be referred to as an aggregation level (AL) of the PDCCH.
[0091] The mapping of REG bundles can use interleaving or non-interleaving. Non-interleaved mapping can form CCEs from consecutive REG bundles (e.g., adjacent in frequency). CCEs adjacent in frequency can form a PDCCH. REGs (e.g., in interleaved mapping) can be interleaved (or arranged) before mapping to CCEs, which can result in non-adjacent REG bundles in (e.g., one) CCE and non-adjacent CCEs in (e.g., one) PDCCH.
[0092] A control resource set (CORESET) may be configured by and / or may include at least one of: frequency allocation (e.g., six (6) RBs as a data block), time length (e.g., one to three (1-3) OFDM symbols), REG bundle type, mapping type from REG bundle to CCE (e.g., whether interleaved or non-interleaved), etc. In (e.g., each) bandwidth part (BWP), there may be, for example, up to N (e.g., 3) CORESETs. In an example, there may be 12 CORESETs in four (4) possible bandwidth parts.
[0093] The WTRU may monitor a set of PDCCH candidates or may be assigned a set of PDCCH candidates (e.g., for monitoring). A set of PDCCH candidates may be monitored during blind detection of the PDCCH. A search space or a set of search spaces (e.g., for multiple aggregation levels) may be or may include a set of PDCCH candidates (e.g., for monitoring (such as monitoring using blind detection)). (Each) search space or a set of search spaces may be configured by at least one of: an associated CORESET, a number of candidates for or within (e.g., each) aggregation level, a set of monitoring opportunities, etc. The monitoring opportunities may be determined, for example, by one or more of: monitoring periodicity (e.g., based on time slots), monitoring offsets, monitoring modes (e.g., 14 bits corresponding to possible symbol patterns within time slots), etc.
[0094] For example, the WTRU may (e.g., in NR) use a PDSCH slot offset to determine the timing relationship between a PDCCH transmission and a PDSCH transmission. The WTRU may (e.g., in NR) be configured with a set of slot offsets for scheduling PDSCH from the slot in which the WTRU receives the scheduling DCI. The WTRU may be configured with a PDSCH-TimeDomainResourceAllocationList (PDSCH-TDRA list), which may include, for example, up to 16 PDSCH-TimeDomainResourceAllocation (PDSCH-TDRA) configurations. (Each) PDSCH-TDRA configuration may include, for example, one or more of the following: a k0 value, which may be one of {0, 1, ..., 32}; a mapping type, which may be one of {typeA, typeB}; a starting symbol and length (SLIV), which may be one of {0, 1, ..., 127}; and the like. The k0 value may determine the slot offset for receiving the PDSCH from the slot in which the scheduling DCI is received. For example, the WTRU may receive DCI for PDSCH in slot #n. The WTRU may receive PDSCH in slot #n+k0. The mapping type may determine the slot length, where type A may be used for normal slot length and type B may be used for sub-slot length. The SLIV may determine the starting symbol and / or the length of the PDSCH within a slot.
[0095] The WTRU may not wake up when it is considered to be in the DRX on-duration. False detection of wake-up signals (e.g., power saving signals) may occur. For example, at higher frequencies, inaccurate beam pairing between the transmitter and receiver may increase the probability of false detection.
[0096] The WUS may carry additional information, including an indication of switching between cross-slots and / or regular scheduling.In an example, a conflict may occur between information in the wake-up signal (eg, if the wake-up signal carries additional information) and the scheduling DCI.
[0097] A power saving signal (PSS) (e.g., WUS) may be associated with a time interval. The terms PSS and WUS may be used interchangeably herein. The WTRU may be configured to perform one or more (e.g., specific) tasks during a time interval. The WTRU may be configured to perform specific tasks during a time interval based on, for example, the presence of a power saving signal and / or the content of the PSS. For example, a PSS may be defined within a time interval such that the WTRU may (e.g., be expected to) perform specific tasks during the time interval, for example based on the presence and / or content of the PSS.
[0098] In an example, the WTRU may monitor the PDCCH (e.g., as shown in FIG. 1 ), for example, during the on-duration of a DRX cycle. Figure 6 As shown in 602 of , the WTRU may monitor a set of beams of the PDCCH during the on-duration of the DRX cycle and, for example, perform WUS monitoring using a subset of beams before the on-duration of the DRX cycle. The WTRU may perform specified actions during the on-duration. For example, the WTRU may start a related timer (e.g., as specified by the MAC layer). The WTRU may skip the DRX on-duration. The WTRU may not monitor the PDCCH during the skipped on-duration. In the example, for example, if a wake-up signal is not detected, or if a wake-up signal is detected but the content of the wake-up signal indicates to skip the DRX on-duration, the WTRU may skip the DRX on-duration and not monitor the PDCCH during the skipped on-duration. The PSS may be associated with the DRX on-duration. In the example, the PSS may be associated with a specific DRX on-duration.
[0099] The PSS may be associated with non-contiguous time intervals (e.g., multiple DRX On Durations). In one or more examples, it may be assumed that the PSS is associated with a time interval (e.g., a one-to-one mapping of the PSS and the DRX On Duration). For example, due to the WTRU's activity exceeding the On Duration, the duration of the Active Time may be longer than the On Duration. (Eg., each) Active Time may include one or more time slots.
[0100] Figure 3 An example of a CORESET for PDCCH in active time and / or WUS is shown. Figure 3The example shown in may illustrate the CORESETs that a WTRU monitors in (e.g., each) active time. The WTRU may monitor (e.g., and / or perform measurements on) CORESETs #1, #2, and #3 (e.g., as shown in FIG. 1 ) in a first active time. Figure 3 ). The WTRU may monitor (e.g., and / or perform measurements) CORESET #1 during the second activity time. The active CORESET may be different during different activity times, e.g., due to one or more of the following: RRC configuration and / or reconfiguration, periodicity of the search space associated with the CORESET and / or slot offset parameters, etc.
[0101] Figure 4 An example of monitoring a CORESET in a time slot of an activity time interval is shown. Figure 4 The example shown in may illustrate the CORESETs that the WTRU may monitor during (e.g., one) active time in (e.g., each) time slot. One or more (e.g., specific or selected) search spaces and / or associated CORESETs may be monitored during the active time interval, for example, based on a search space parameter. The periodicity of (e.g., each) search space may be different. The active CORESET may be different from one time slot to another. In the example (e.g., as Figure 4 As shown in FIG. 1 , CORESET 1 can be detected to have a periodicity of 1 time slot, CORESET 3 can be detected to have a periodicity of 4 time slots, and CORESET 2 can be detected to have a periodicity of 7 time slots.
[0102] The PSS may be a WUS and / or may be transmitted before the associated DRX On Duration. A CORESET in which a PSS is transmitted may be referred to as a CORESET_PSS. A CORESET configured during an On Duration associated with a PSS may be referred to as a CORESET_ON. PSS and WUS may be used interchangeably (e.g., and they may also be referred to as WUS PSS). For example, Figure 6 As shown in 602, the WTRU may monitor a set of beams of the PDCCH during the on-duration and perform WUS monitoring using a subset of beams, for example, before the on-duration of the DRX cycle.
[0103] The CORESET_PSS may be determined, for example, dynamically. In an example, the CORESET_PSS associated with an on-duration may be CORESET_ON in the associated on-duration. A CORESET identification (CORESET-id) may be shared, determined, selected and / or used by the CORESET_PSS and CORESET_ON.
[0104] The search space for PSS monitoring may be associated with (e.g., any) CORESET-id. In one or more examples, CORESET identification, CORESET-id, CORESET_PSS identification, CORESET_ON identification, CORESET_PSS-id, and CORESET_ON-id may be used interchangeably. The determined CORESET_PSS may be used to monitor the search space for PSS during the associated on-duration. The search space for PSS monitoring may be referred to as SS_PSS. The monitoring timing of SS_PSS may be determined based on, for example, one or more of the following: N time slots earlier than the first PDCCH monitoring timing of the associated on-duration; N time slots earlier than the first time slot of the associated on-duration; N may be determined based on various parameters and / or factors; and the like.
[0105] The monitoring opportunity of the SS_PSS may be determined, for example, N slots earlier than the first PDCCH monitoring opportunity of the associated on-duration. The first PDCCH monitoring opportunity may start from the beginning (e.g., from the on-duration) or may start after K slots (e.g., after the on-duration starts).
[0106] The monitoring timing of the SS_PSS may be determined, for example, N time slots earlier than the first time slot of the associated on-Duration.
[0107] The monitoring occasions for the SS_PSS may be determined, for example, based on N, which may be determined based on various parameters and / or factors. N may be determined based on, for example, one or more of the following: the number of beams used, the number of CORESETs associated with the on-duration, the subcarrier spacing, the cyclic prefix (CP) length, the WTRU capabilities, higher layer configuration (e.g., as part of the PSS configuration), etc.
[0108] For example, N may be determined based on the number of beams used. For example, N may be determined based on the number of beams used for PDCCH monitoring. The number of beams used for PDCCH monitoring may be associated with multiple CORESETs. For example, the number of beams used for PDCCH monitoring may be the number of CORESETs with different quasi-co-location (QCL)-typeD associated with the search space within the associated on-duration. QCL-typeD may indicate a beam reference signal that may have the same spatial-Rx characteristics. Beams with the same QCL-typeD parameters may be considered to be the same beam. The QCL-typeD indication may be based on a transmission configuration indicator (TCI) indication.
[0109] For example, N may be determined based on the subcarrier spacing. For example, N may be larger if and / or when the subcarrier spacing becomes wider.
[0110] The examples described herein may be applicable to a variety of signal types or states. For example, although some examples may be described in terms of beams, Rx beams, Tx beams, Tx-Rx beam pairs, QCL-typeD, associated beam reference signals, TCI states, associated Rx beam reference signals, associated synchronization signal blocks (SSBs), spatial Rx characteristics, and / or QCL, the examples may (e.g., also) be applicable to other signals or parameters (e.g., as described herein). Therefore, the terms in the examples may be used interchangeably, depending on the applicability of the examples and other descriptions herein. Examples described in terms of one transmission configuration (e.g., beams) may (e.g., also) be applicable to other transmission configurations (e.g., TCI states). The techniques described herein may be applicable to any of the following: beams, Tx beams, Tx-Rx beam pairs, QCL-typeD, associated beam reference signals, TCI states, associated Rx beam reference signals, associated SSBs, spatial Rx characteristics, and / or QCL, even if the examples are described with respect to other terms.
[0111] The WTRU may be configured with and / or use beam information to monitor PSS signals. The WTRU may determine the CORESET_PSS during an associated on-duration. The WTRU may determine the CORESET_PSS during an associated on-duration, for example, based on the CORESET_ON and / or a search space configured during the associated on-duration. One or more of the following techniques (e.g., a combination) may be used to determine the CORESET_PSS: one or more configured parameters of the CORESET_ON and / or a search space configured during the associated on-duration; at least one measurement of an attribute of the CORESET_ON; a TCI state of the CORESET_ON; and the like.
[0112] For example, the CORESET_PSS may be determined based on one or more configured parameters of the CORESET_ON and / or a search space that may be configured in an associated on-duration.
[0113] The one or more configured parameters for determining the CORESET_ON of the CORESET_PSS and / or the search space configured in the associated on-duration may include a resource element group (REG) mapping type and / or a frequency resource. In an example, the CORESET_ON parameters that may be used to determine the CORESET_PSS may be the REG mapping type and / or the frequency resource. For example, the CORESET_PSS may be determined based on a CORESET_ON with a non-interleaved REG mapping. For example, the CORESET_PSS may be determined based on a CORESET_ON with a frequency allocation bandwidth below a threshold. For example, the CORESET_PSS may be the same as the CORESET_ON with the minimum bandwidth.
[0114] The one or more configured parameters for determining the CORESET_ON and / or search space of the CORESET_PSS may include a CORESET_ON ID. In an example, the CORESET_PSS may be determined based on the CORESET_ON ID. For example, the CORESET_PSS may be the same CORESET as the CORESET_ON with a specific (e.g., minimum) ID.
[0115] The one or more configured parameters for determining the CORESET_ON and / or the search space of the CORESET_PSS may include an ID of the search space configured in the associated on-duration. In an example, the CORESET_PSS may be determined based on the ID of the search space configured in the associated on-duration. For example, the CORESET_PSS may be the same CORESET as the CORESET_ON that may be configured as part of the search space with the smallest ID. The CORESET_PSS may be the same CORESET as the CORESET_ON that may be configured as part of the WTRU-specific search space with the smallest ID, or the CORESET_PSS may be the same CORESET as the CORESET ON that may be configured as part of the group common search space with the smallest ID.
[0116] The one or more configured parameters for determining the CORESET_ON and / or the search space of the CORESET_PSS may include an aggregation level of the search space configured in the associated on-duration. In an example, the CORESET_PSS may be determined based on the aggregation level of the search space configured in the associated on-duration. For example, the CORESET_PSS may be the same CORESET as the CORESET_ON that may be configured as part of the search space with a specific (e.g., maximum) aggregation level.
[0117] The one or more configured parameters for determining CORESET_ON and / or the search space of the CORESET_PSS may include a DCI format of the search space configured in the associated on-duration. In an example, the CORESET_PSS may be determined based on the DCI format of the search space configured in the associated on-duration. For example, the CORESET_PSS may be the same CORESET as the CORESET_ON that may be configured as part of a search space as described below, the search space having a specific (e.g., selected) DCI format among the configured DCI formats and / or a DCI format having a specific (e.g., minimum) size.
[0118] The one or more configured parameters for determining CORESET_ON and / or the search space of the CORESET_PSS may include a search space type of the search space configured in the associated on-duration. In an example, the CORESET_PSS may be determined based on the search space type of the search space configured in the associated on-duration. For example, if the PSS is WTRU-specific, then, for example, the CORESET_PSS may be the same CORESET as the CORESET ON that may be configured as part of the WTRU-specific search space. For example, if the PSS is common, then the CORESET_PSS may be the same CORESET as the CORESET ON that may be configured as part of the group common search space.
[0119] The one or more configured parameters of CORESET_ON and / or the search space for determining the CORESET_PSS may include a periodicity of the search space configured in the associated on-duration. In an example, the CORESET_PSS may be determined based on the periodicity of the search space configured in the associated on-duration. For example, the CORESET_PSS may be the same CORESET as the CORESET_ON that may be configured as part of the search space with the minimum periodicity.
[0120] The one or more configured parameters for determining the CORESET_ON and / or search space of the CORESET_PSS may include the CORESET-id of the CORESET_ON. In an example, the CORESET_PSS may be determined based on a specific (e.g., lowest) CORESET-id of the CORESET_ON. For example, one or more search spaces may be located or monitored in the on-duration. (E.g., each) search space may be associated with a CORESET. The CORESET with an associated search space in the on-duration may be the CORESET_ON. The CORESET_PSS may be the CORESET_ON with a specific (e.g., lowest) CORESET-id within the CORESET_ON. The CORESET_PSS may change at different on-durations. For example, the CORESET_PSS may change in some (e.g., each) on-durations, for example, based on a set of search spaces that may be monitored during the associated on-duration.
[0121] The one or more configured parameters for determining CORESET_ON and / or search space of CORESET_PSS may include a default CORESET (or initial CORESET) in which broadcast channels may be received. In an example, CORESET_PSS may be predetermined as a default CORESET (e.g., or initial CORESET) in which broadcast channels may be received.
[0122] For example, the CORESET_PSS may be determined based on at least one measurement result of the properties of CORESET_ON. The CORESET_PSS may be the same CORESET as the CORESET_ON, which is associated with a specific reference signal received power (RSRP). For example, the CORESET_PSS may be the same CORESET as the CORESET_ON with the maximum RSRP. The RSRP may be measured using at least one RS indicated in the TCI state of the CORESET_ON. The RS may be a specific QCL type (e.g., QCL_D). In an example, the CORESET_PSS may be the same CORESET as the CORESET_ON with the maximum RSRP. The RSRP may be measured using at least one RS indicated in the TCI state of the CORESET_ON. For example, measurements of one or more beams configured to monitor the PSS may be performed at a specific time (e.g., before and / or during DRX-ON). The measurements may be performed at specific time intervals (e.g., within N slots before the PSS slot).
[0123] For example, the CORESET_PSS may be determined based on the TCI state of CORESET_ON. The CORESET_PSS may be the same CORESET as the CORESET_ON with the activated TCI state. For example, the CORESET_PSS may be the same CORESET as the CORESET_ON with the most recently activated TCI state.
[0124] The WTRU may determine the CORESET_PSS, for example, using one or more criteria (e.g., a combination of at least two criteria), such as described herein. For example, the CORESET_PSS may be the same CORESET as the CORESET_ON that may be configured as part of a WTRU-specific search space with a specific (e.g., minimum) periodicity. For example, the CORESET_PSS may be the same CORESET as the CORESET_ON with a specific (e.g., most recently activated) TCI state among the CORESETs that are configured as part of the WTRU-specific search space. The one or more configured parameters of the CORESET_ON and / or the search space that may be used to determine the CORESET_PSS may correspond to multiple parameters of the CORESET_ON and / or the search space in various combinations.
[0125] In an example (eg, as described herein), the CORESET_PSS and CORESET_ON may use at least one common configuration parameter (eg, TCI state, bandwidth, etc.), eg, after determining the at least one common configuration parameter based on at least one of the CORESET_ONs.
[0126] In an example, the search space for the PSS may be configured without a CORESET_PSS and / or the CORESET_PSS may be determined dynamically (e.g., using one or more of the methods and / or techniques described herein) by the WTRU (e.g., during each associated on-duration). In an example, the search space for the PSS may be configured with an initial CORESET_PSS and / or the CORESET_PSS may be determined dynamically (e.g., using one or more of the methods and / or techniques described herein) (e.g., during each associated on-duration).
[0127] In some examples, certain CORESET_ONs (eg, beam recovery CORESETs) may be excluded and / or not used.
[0128] The TCI state of the CORESET_PSS may be determined, for example, dynamically. The TCI state of the CORESET_PSS may be associated with a beam used to receive the PSS. For example, the TCI state of the CORESET_PSS may determine the beam used to receive the PSS. The active TCI state of the CORESET_PSS may include a reference signal (RS). In an example, the active TCI state of the CORESET_PSS may include at least one RS with QCL_typeD. The WTRU may use the same receive beam for the RS and the CORESET_PSS.
[0129] The receive beam for the PSS (e.g., WUS) may be determined, for example, based on an active time receive beam. In an example, the receive beam for the PSS may be determined based on an active time receive beam, which may be configured to receive the CORESET in an associated active time. In a similar or equivalent implementation, the TCI state of the CORESET_PSS may be determined, for example, based on an active time TCI state of the CORESET in an associated active time.
[0130] In an example, the TCI state of CORESET_PSS may be the same as the TCI state of CORESET_ON associated with the on-duration.
[0131] The WTRU may determine the TCI state of the CORESET_PSS, for example, based on the CORESET_ON and / or the search space configured in the associated on-duration. The WTRU may determine the TCI state of the CORESET_PSS, for example, based on one or more of the following (e.g., a combination thereof): one or more configured parameters of the CORESET_ON and / or the search space configured in the associated on-duration; at least one measurement result of a property of the CORESET_ON; the TCI state of the CORESET_ON; etc.
[0132] The CORESET_PSS TCI state may be determined based on one or more configured parameters of CORESET_ON and / or a search space configured in an associated on-duration.
[0133] The one or more configured parameters of the CORESET_ON and / or the search space configured in the associated on-duration may include a CORESET_ON ID. In an example, a CORESET_PSS TCI state may be determined based on the CORESET_ON ID. For example, a CORESET_PSS may have the same TCI state as a CORESET_ON as described below, which is associated with a specific (e.g., minimum) ID.
[0134] .The one or more configured parameters of the CORESET_ON and / or the search space configured in the associated on-duration may include an ID of the search space. In an example, the CORESET_PSS TCI state may be determined based on the ID of the search space in the associated on-duration. For example, the CORESET_PSS may have the same TCI state as a CORESET_ON described below, which is linked to a search space associated with a specific (e.g., minimum) ID. For example, the CORESET_PSS may have the same TCI state as a CORESET_ON described below, which is configured as part of a WTRU-specific search space with a specific (e.g., minimum) ID or as part of a group-common search space with a specific (e.g., minimum) ID.
[0135] The one or more configured parameters of the CORESET_ON and / or the search space configured in the associated on-duration may include a REG mapping type and / or a frequency resource. In an example, the CORESET_ON parameter may be a REG mapping type and / or a frequency resource. For example, the CORESET_PSS may have the same TCI state as the CORESET_ON described below, which has a specific (e.g., non-interleaved) REG mapping. For example, the CORESET_PSS may have the same TCI state as the CORESET_ON described below, which has a specific frequency allocation bandwidth (e.g., below a threshold), such as a minimum bandwidth.
[0136] The one or more configured parameters of the CORESET_ON and / or the search space configured in the associated on-duration may include an aggregation level of the search space configured in the associated on-duration. In an example, the CORESET_ON parameter may be an aggregation level of the search space configured in the associated on-duration. For example, a CORESET_PSS may have the same TCI state as a CORESET_ON that may be configured as a portion of a search space with a specific (e.g., maximum) aggregation level.
[0137] The one or more configured parameters of the CORESET_ON and / or the search space configured in the associated on-duration may include a DCI format of the search space configured in the associated on-duration. In an example, the CORESET_PSS TCI state may be determined based on the DCI format of the search space configured in the associated on-duration. For example, the CORESET_PSS may have the same TCI state as the CORESET_ON described below, which may be configured as a portion of the search space having a specific DCI format among the configured DCI formats and / or a DCI format associated with a specific (e.g., minimum) size.
[0138] The one or more configured parameters of the CORESET_ON and / or the search space configured in the associated on-duration may include a search space type of the search space configured in the associated on-duration. In an example, the CORESET_PSS TCI state may be determined based on the search space type of the search space configured in the associated on-duration. For example, if the PSS is WTRU-specific, the CORESET_PSS may have the same TCI state as, for example, a CORESET_ON that may be configured as part of a WTRU-specific search space. For example, if the PSS is group-common, the CORESET_PSS may have the same TCI state as a CORESET ON that may be configured as part of a group-common search space.
[0139] The one or more configured parameters of CORESET_ON and / or the search space configured in the associated on duration may include the periodicity of the search space configured in the associated on duration. In an example, the CORESET_PSS TCI state may be determined based on the periodicity of the search space configured in the associated on duration. For example, the CORESET_PSS may have the same TCI state as a CORESET_ON that may be configured as a portion of a search space with a specific periodicity (e.g., corresponding to a DRX cycle). For example, the CORESET_PSS may have the same TCI state as a CORESET_ON that may be configured as a portion of a search space associated with a specific (e.g., minimum) periodicity. In an example, multiple search spaces may be configured with a specific (e.g., minimum) periodicity. A search space with a specific (e.g., minimum) ID may be selected among the multiple search spaces.
[0140] For example, the CORESET_PSS TCI state may be determined based on at least one measurement result of the attributes of CORESET_ON. The attributes of CORESET_ON may include, for example, RSRP. For example, the CORESET_PSS TCI state may be determined based on the TCI state of CORESET_ON having (e.g., a specific) RSRP. For example, the CORESET_PSS TCI state may be the same TCI state as the CORESET_ON having the maximum RSRP. For example, the RSRP may be measured using at least one RS indicated in the TCI state of the CORESET_ON. The RS may be a (e.g., a specific) QCL type (e.g., QCL_D). In an example, the CORESET_PSS TCI state may be the same TCI state as the CORESET_ON described below, which is associated with a specific (e.g., maximum) RSRP. For example, the RSRP may be measured using at least one RS indicated in the TCI state of the CORESET_ON. The measurement may be performed at (e.g., a specific) time interval (e.g., within N time slots of the PSS).
[0141] For example, the CORESET_PSS TCI state may be determined based on the TCI state of CORESET_ON. The CORESET_PSS may have the same TCI state as a CORESET_ON with an activated TCI state. For example, the CORESET_PSS may have the same TCI state as a CORESET_ON with a specific (e.g., most recently activated) TCI state. For example, if the time gap between the most recent activation of the CORESET_ON TCI state and the reception of the PSS is above a threshold, the WTRU may use the default TCI state of the CORESET_PSS.
[0142] The WTRU may determine the CORESET_PSS TCI state, for example, using one or more criteria (e.g., a combination of at least two criteria), e.g., as described herein. For example, the CORESET_PSS may have the same TCI state as CORESET_ON, which may be configured as part of a WTRU-specific search space associated with a specific (e.g., minimum) periodicity.
[0143] In an example, the CORESET_PSS may be configured with no TCI state. The WTRU may be configured to determine the TCI state (e.g., dynamically) during (e.g., each) associated on-duration. The WTRU may determine the TCI state (e.g., dynamically), for example, using one or more methods or techniques (e.g., a combination thereof) described herein. In an example, the TCI state of the CORESET_PSS may be configured with an initial TCI state. The WTRU may determine the TCI state (e.g., dynamically), for example, using one or more methods or techniques described herein.
[0144] A power saving signal may be transmitted from a network node to a WTRU. The power saving signal may be transmitted before the on-duration begins. In an example, the power saving signal may be transmitted during an inactive time. For example, the power saving signal may be transmitted at predefined or configured time intervals before the on-duration begins. The power saving signal may be transmitted in a PDCCH. The power saving signal may be subject to beamforming and / or precoding.
[0145] The WTRU may determine, for example, based on at least one attribute of the wake-up signal, at least one attribute of a procedure for receiving the PDCCH and / or PDSCH. In an example, the WTRU may use at least one attribute of the wake-up signal to (e.g., implicitly) determine at least one attribute of a procedure that may be used to receive the PDCCH and / or PDSCH during an on-duration associated with the wake-up signal. The on-duration associated with the wake-up signal may include, for example, an on-duration indicated by a power save signal when the WTRU is configured to monitor or is monitoring the PDCCH.
[0146] The attributes of the power saving signal may include, for example, one or more of the following: DM-RS (e.g., including a reference signal sequence and / or a scrambling ID); the ID of the transmit beam and / or the precoding vector applied to the power saving signal; the ID of the CORESET in which the power saving signal is transmitted; the aggregation level of the power saving signal; and the like.
[0147] The attributes of the on-duration may be determined (e.g., implicitly) by the power saving signal. The attributes of the on-duration may include, for example, one or more of: a set of monitored search spaces (e.g., selected from a set of configured search spaces); a set of monitored CORESETs (e.g., selected from a set of configured CORESETs); a power saving state; etc. In an example, the WTRU may or may not implement a power saving scheme, which may be indicated in the attributes of the on-duration (e.g., in the power saving state).
[0148] The WTRU may determine a receive beam applicable to an OFDM symbol, for example, based on a TCI state associated with the OFDM symbol. The search space may include, for example, a set of periodic time slots for monitoring the PDCCH and OFDM symbols within the time slot, etc. (e.g., as a set of parameters). In an example, an OFDM symbol or a set of OFDM symbols in a time slot associated with the search space may be associated with a corresponding TCI state. For example, when the WTRU is monitoring the PDCCH according to the search space configuration, the WTRU may apply a receive beam to the OFDM symbol in the time slot. For example, a beam may be determined using a TCI state associated with the OFDM symbol. The TCI state may include, for example, a CSI-reference signal (CSI-RS) index and / or an SSB index with QCL type information (e.g., as a set of parameters). In an example, the WTRU may apply a receive beam to an OFDM symbol. The receive beam may be determined, for example, from a CSI-RS or an SSB with QCL type D.
[0149] The receive beam may be determined, for example, based on a TCI state associated with a time interval. In an example, the WTRU may apply multiple receive beams to an input signal within multiple time intervals. The receive beam may be determined from a TCI state associated with a time interval (e.g., among multiple time intervals). The beam that results in successful decoding of the channel may be used to (e.g., implicitly) determine the properties of a program used in the on-duration. The TCI state that results in successful decoding of the channel may be used to (e.g., implicitly) determine the properties of one or more programs that may be used in the on-duration. The time interval may be one or more OFDM symbols and / or one or more time slots. In an example, a power saving signal may be transmitted at multiple time instances, for example, using the same CORESET. A time instance may be associated with a TCI state (e.g., a corresponding TCI state). The TCI state that results in successful decoding of the PDCCH may be used to indicate the properties of the program used when receiving the PDCCH and / or PDSCH (e.g., in the on-duration associated with the wake-up signal).
[0150] The receive beam may be determined from the TCI states of different CORESETs. In an example, a power save signal may be transmitted at multiple time instances and / or different CORESETs may be used at some (e.g., each) time instances. The WTRU may apply a receive beam to a CORESET. The receive beam may be determined from the TCI states of the CORESET. For example, the receive beam and / or TCI state that resulted in a successful decoding of the PDCCH may be used to determine the properties of the PDCCH and / or PDSCH, for example, in an on-duration associated with the WUS.
[0151] False detection may be prevented. For example, the WTRU may be configured to remain in an awake state regardless of whether a WUS has been received. The WTRU may be configured to ignore the WUS. In an example, the WTRU may ignore the WUS, for example, by assuming that a PSS indication for wake-up has been received and waking up (e.g., starting the PDCCH in the associated on-duration), regardless of whether a wake-up signal has actually been received, which may be referred to as ignoring the WUS. The WTRU may remain in a WUS ignoring state for a period of time and then resume normal operation (e.g., wake up when the WTRU receives a WUS). For example, when the WTRU receives a WUS, the WTRU may remain in a WUS ignoring state for a period of time until (e.g., only until) the WTRU is instructed to resume normal operation.
[0152] Under various conditions, the WTRU may ignore (e.g., skip decoding) the PSS / WUS. For example, the WTRU may be triggered to ignore the WUS based on one or more of the following conditions: whether the measurement of the RS indicated by the active TCI state of the CORESET_PSS (e.g., RSRP) may be below a threshold; the quality of the RS indicated in the TCI state of the CORESET_PSS (e.g., whether the quality is below the threshold multiple times); the PDCCH link quality measurement result (e.g., below the threshold multiple times); whether the time from the activation of the TCI state of the CORESET_PSS to the time when the WTRU is configured to monitor the PSS may exceed a threshold; whether the WTRU speed may be below a threshold; whether the activity time extends and whether the time in which the WTRU is configured to monitor the WUS may be within the activity time; whether a specific DRX timer may be running at the time in which the WTRU is configured to monitor the WUS; the type of WUS; etc. As described herein, measurements of one or more beams configured to monitor the PSS may be performed at specific times (e.g., before DRX-ON and / or during DRX-ON).
[0153] For example, if the measurement (e.g., RSRP) of the RS indicated by the active TCI state of the CORESET_PSS is below a threshold, the WTRU may be triggered to ignore the WUS. In an example, the indicated RS may be an SSB and / or a CSI-RS. It may be assumed that at least one RS is indicated by a TCI state. For example, if the measurement of at least one RS is below a threshold, the WTRU may ignore the PSS. In an example, if the measurement of multiple (e.g., all) RSs is below a threshold, the WTRU may ignore the PSS. In an example, different RSs may have different thresholds. For example, if the measurement of the RS used to determine the receive beam is below a threshold, the WTRU may ignore the PSS. For example, the RS of the receive beam used to determine the CORESET_PSS may be an RS with QCL type D. More than one CORESET may be used to transmit the WUS. For example, if the RS indicated in the TCI state of at least one CORESET (e.g., in more than one CORESET) meets the wake-up condition, the WTRU may ignore the WUS. For example, if the RS indicated in the TCI states of some or all individual CORESETs meet the wake-up condition, the WTRU may ignore the WUS. In an example (e.g., in beam scanning), the individual CORESETs may transmit on different OFDM symbols within a slot and / or on different slots. For example, if the RS indicated in the TCI state of at least one CORESET meets the wake-up condition (e.g., using the criteria / standards described herein), the WTRU may ignore the WUS. For example, if the RS indicated in the TCI states of multiple (e.g., all) individual CORESETs meet the wake-up condition, the WTRU may ignore the WUS.
[0154] For example, if the measurement exceeds a threshold and / or remains above the threshold for a specified period of time, the WTRU may resume normal operation. In an example, the WTRU may (e.g., only) begin monitoring the WUS and wake up when instructed, for example, if the measurement exceeds a threshold and / or remains above the threshold for a specified period of time. As described herein, measurements of one or more beams configured to monitor the WUS may be performed at a specific time (e.g., before DRX-on). Different TCI states of the CORESET_PSS may be indicated, for example, explicitly or implicitly. The WTRU may send information to the base station to indicate a failure.
[0155] For example, if the quality of the RS indicated in the TCI state of the CORESET_PSS is below a threshold multiple times (e.g., a certain number of times), the WTRU may be triggered to ignore the WUS. The WTRU may monitor the quality of the RS indicated in the TCI state of the CORESET_PSS and may count the number of times the measurement is below the threshold. In an example, if the measurement of (e.g., one) CORESET is below a specified threshold, the counter may be incremented (e.g., one (1)). In an example, if the measurement of multiple (e.g., all) CORESETs is below a specified threshold, the WTRU may increment the counter (e.g., 1). The WTRU may determine whether to ignore the PSS and / or reset the counter. For example, if and / or when the counter reaches a target value, the WTRU may (e.g., decide) to ignore the PSS and reset the counter. For example, the WTRU may send information to the base station to indicate a failure. For example, if different TCI states are activated for one or more (e.g., all) CORESET_PSSs, the WTRU may resume normal operation. For example, if a different TCI state is activated (eg, explicitly or implicitly) for one or more (eg, all) CORESET_PSSs, the WTRU may start monitoring the WUS and wake up (eg, only) based on the indication.
[0156] The WTRU may (e.g., in the examples described herein and / or in other specific implementations) use a set of RSs other than those RSs indicated in the TCI state (e.g., in the examples described herein) or a set of RSs including those RSs indicated in the TCI state.
[0157] The WTRU may use the PDCCH link quality measurement results to determine whether to ignore the PSS. The WTRU may monitor the PDCCH link quality. For example, if the PDCCH link quality is relatively low (e.g., below a threshold metric), the WTRU may ignore the PSS. For example, if a counter for a beam failure instance indication reaches (e.g., equals or exceeds) a specified target value, the WTRU may ignore the PSS. For example, if the RS indicated in the TCI state of the PDCCH CORESET is below (e.g., a specific) threshold, the counter may be increased (e.g., one (1)). For example, if the RS indicated in (e.g., only one) TCI state of the PDCCH CORESET is below (e.g., a specific) threshold, the counter may be increased (e.g., 1). For example, if different TCI states are activated for one or more (e.g., all) PDCCH CORESETs, the WTRU may send an indication to the base station and / or resume normal operation. For example, the WTRU may ignore the PSS if and / or when the PDCCH beam failure condition is met and / or until beam recovery is completed.
[0158] For example, if a specific (e.g., selected, configured, fixed and / or variable) duration exceeds a threshold, the WTRU may be triggered to ignore the WUS. For example, if the time (e.g., from the activation of the TCI state of the CORESET_PSS to the time when the WTRU is configured to monitor the PSS) exceeds a threshold, the WTRU may ignore the PSS. The TCI state of the CORESET_PSS may be activated explicitly (e.g., by a MAC CE) or implicitly (e.g., as described herein).
[0159] For example, if the WTRU speed changes, the WTRU may be triggered to ignore the WUS. For example, the WTRU speed may exceed a threshold. The WTRU may ignore the WUS until the speed is below the threshold. For example, if the WTRU is about to start a handover or a procedure triggered by mobility, the WTRU may ignore the WUS.
[0160] For example, if the activity time is extended, the WTRU may be triggered to ignore the WUS. For example, if the activity time is extended and the time during which the WTRU is configured to monitor for WUS is within the activity time, the WTRU may ignore the WUS and remain awake (e.g., for the next on-duration).
[0161] For example, if a specific DRX timer is running, the WTRU may be triggered to ignore the WUS. For example, if a specific DRX timer is running at a time where the WTRU is configured to monitor for WUS, the WTRU may ignore the WUS and remain awake (e.g., for the next on-duration). The DRX timers may include, for example, one or more of the following: drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, drx-HARQ-RTT-TimerDL, and / or drx-HARQ-RTT-TimerUL.
[0162] The WTRU behavior may be determined by the type of WUS. For example, the WTRU may behave differently depending on whether the WUS is WTRU-specific or group-common. For example, if the WUS is WTRU-specific (e.g., includes information only for a single WTRU), the WTRU may wake up if the WTRU detects the WUS, and may not wake up if the WTRU does not detect the WUS. For example, if the WUS is group-common (e.g., includes information for a group of WTRUs), the WTRU may wake up if the WTRU detects the WUS and the code points within the WUS content indicate to the WTRU to wake up, and may not wake up if the code points indicate to the WTRU not to wake up.
[0163] The WUS may be associated with beam failure detection and / or recovery. For example, for an operating frequency range, one or more beams may be associated with a WUS. An example of an operating frequency range may be FR2. Beams may be mismatched between Tx and Rx. For example, if a WUS is associated with one or more beams and these beams are mismatched between Tx and Rx, the WTRU may misdetect the WUS.
[0164] For example, if the WTRU is configured to monitor the WUS and one or more beams are associated with the WUS (e.g., Figure 5 As shown in 502 of , the WTRU may be configured to monitor a first set of beams associated with the WUS), the beam quality of the WUS may be measured by the WTRU. As described herein, the measurement of one or more beams configured to monitor the PSS (e.g., CORSET_PSS) may be performed at a specific time (e.g., before DRX-ON). In an example, the WTRU may measure the beam quality of one or more beams RS associated with the configured CORESET (e.g., Figure 5 As shown in 502 of FIG. 5 , the WTRU may determine a second set of beams associated with the configured CORESET); if the beam measurement quality is below a predetermined quality value, such as a threshold (e.g., Figure 5 504 and Figure 6 ), the WTRU may determine that the beam may have failed; and so on.
[0165] The WTRU may measure beam quality (e.g., L1-RSRP, RSRP, signal-to-noise ratio and signal-to-interference-plus-noise ratio (SINR), L1-SINR) of one or more beam reference signals associated with a configured CORESET (e.g., CORESET, CORESET_PSS, and / or CORESET_ON). Measurements of one or more beams configured for monitoring PDCCH (e.g., CORSET_ON) may be performed at specific times (e.g., during DRX-ON). The beam reference signals may include one or more of the following: SSB, CSI-RS, non-zero power (NZP)-CSI-RS, DM-RS of PDCCH, and / or DM-RS of PDSCH. As described herein, the respective quality of each beam in a first set of beams (e.g., a set of beams configured for WUS monitoring) may be determined during a first time period, and the quality of beams in a second set of beams (e.g., a set of beams configured for monitoring PDCCH) that are not in the first set of beams may be determined during a second time period. The second time period (e.g., DRX-ON) may be after the first time period (e.g., DRX-OFF). In some examples as described herein, the second time period may overlap with the first time period, such as when determining the respective quality of each beam in the first set of beams (e.g., a set of beams configured for WUS monitoring) during the DRX-ON period.
[0166] For example, if one or more beam measurement qualities are below an associated threshold (e.g., Figure 5 504 of ), the WTRU may determine that the beam may have failed. For example, if all beams associated with the WUS have failed (e.g., Figure 6), the WTRU may determine a beam failure of the WUS. The beam associated with the WUS may be a subset of the beams associated with the configured CORESET. The beam associated with the WUS may be a first beam subset associated with the configured CORESET, and the beam not associated with the WUS may be a second beam subset associated with the configured CORESET. The first beam subset and the second beam subset may not overlap. The beam failure of the WUS may be different from the beam failure of the link between the gNB and the WTRU. In an example, a WUS beam failure may be declared when the beam quality of the link between the gNB and the WTRU may maintain normal functionality (e.g., no beam failure). The beam failure of the WUS may be referred to as BF-WUS. The beam failure of the gNB and WTRU radio link may be referred to as BF-RL. Different thresholds may be used to determine the BF-WUS and the BF-Radio Link (RL). In an example, a first threshold may be used to determine the BF-WUS, and a second threshold may be used to determine the BF-RL. The first threshold and the second threshold may be different. In an example, the first threshold may be lower than the second threshold, or vice versa.
[0167] In an example, the WTRU may skip decoding the WUS and monitor the search space configured in the on-Duration, for example, based on one or more of the following: BF-WUS and / or BF-RL declared / announced by the WTRU; the beam used for the WUS is different from the beam used for the search space monitored in the associated on-Duration; the WTRU monitors for an indication (e.g., SearchSpaceBFR); no WUS is detected M times in a row; etc. The indication SearchSpaceBFR may indicate the search space used when the WTRU declares BF-RL and reports a different candidate beam for beam failure recovery.
[0168] For example, if the WTRU asserts BF-WUS and / or BF-RL, the WTRU may skip decoding the WUS and monitor the search space configured in the OnDuration.
[0169] For example, if the beam used for the WUS is different from the beam used for the search space monitored in the associated on-Duration, the WTRU may skip decoding the WUS and monitor the search space configured in the on-Duration.
[0170] For example, if the WTRU monitors an indication (e.g., SearchSpaceBFR), which may instruct the WTRU to monitor whether the WTRU declares BF-RL based on detecting a beam failure and reports the search spaces of different candidate beams, the WTRU may skip decoding the WUS and monitor the search space configured in the on-duration.
[0171] For example, if a WUS is not detected M times in a row, the WTRU may skip decoding the WUS and monitor the search space configured in the on-duration. M may be determined, for example, based on one or more of: a predetermined value (e.g., M=4); a configured value (e.g., via higher layer signaling); a value determined based on one or more of the number of beams used, a DRX cycle, etc.; etc.
[0172] The WTRU may send a message (e.g., a reconfiguration message to reconfigure a set of beams) that indicates to the gNB the selected (e.g., preferred) beams for BFR (e.g., such as Figure 5 In an example, for example, if the WTRU detects a BF-WUS, the WTRU may send (e.g., to the network) a request for beam restoration of the WUS (e.g., as shown in 510 of FIG. 1 ). Figure 6 For example, the WTRU may send a request to the gNB for a preferred beam for the WUS (e.g., as shown in 608 of FIG. 1 ). Figure 6 608 of ). The preferred beam for the WUS may be different from the beam for CORESET_ON. The preferred beam for the WUS may be indicated, for example, via a scheduling request (SR) and / or a buffer status report (BSR). The WTRU may select and / or indicate to the gNB (e.g., via an SR and / or a BSR) the preferred beam for the WUS (e.g., as shown in 608 of ). Figure 5 508 or as shown in Figure 6 The preferred beam may be identified, for example, by determining a beam having a beam quality greater than a predetermined quality value (eg, as shown in 606 of FIG. 1 ). Figure 5506 of ). The preferred beam may be in a different set of beams from the beam in which the failure has occurred. For example, the preferred beam may be in a first set of beams, and the beam in which the failure has occurred may be in a second set of beams. The first set of beams and the second set of beams may be different. The first set of beams and the second set of beams may or may not overlap. One or more SR resources (e.g., or PUCCH resources) may be reserved for the WTRU. (E.g., each) SR resource and / or PUCCH resource may be associated with a beam (e.g., TCI state and / or QCL-typeD). The WTRU may send an SR resource, which may be associated with a preferred beam determined by the WTRU. The preferred beam indication may be performed using one or more types of physical uplink channels. For example, the first uplink channel may be a physical uplink control channel (PUCCH), and the second uplink channel may be a physical random access channel (PRACH). In the example, the type of physical uplink channel may be determined based on the beam failure type. For example, if the WTRU declares BF-RL, the PRACH may be used to indicate the preferred beam, and if the WTRU declares BF-WUS, the PUCCH may be used to indicate the preferred beam. The preferred beam may be used interchangeably with a different or updated candidate beam. The gNB may acknowledge receipt of the beam change request for the WUS and / or the WTRU may begin monitoring the WUS with the reported preferred beam (e.g., by receiving a PUCCH message such as Figure 5 For example, if the WTRU is in a beam recovery procedure, the WTRU may ignore (or skip decoding) the WUS.
[0173] The WUS may be used to indicate cross-slot scheduling. In an example, the PSS may include additional information for the WTRU. For example, the PSS may indicate to the WTRU whether the WTRU implements (e.g., whether the WTRU must implement) cross-slot scheduling. For example, the PSS may indicate to the WTRU whether the WTRU implements cross-slot scheduling in an upcoming associated activity time. The PSS may indicate to the WTRU whether the WTRU switches (e.g., whether the WTRU must switch) to another bandwidth part. For example, the PSS may indicate to the WTRU whether the WTRU switches to another bandwidth part other than the BWP in which the PSS is transmitted.
[0174] The PSS may be transmitted as a wake-up signal. The PSS may be transmitted during active time (referred to as active time PSS). The PSS transmitted during active time may indicate specific information to the WTRU. For example, the PSS transmitted during active time may (e.g., dynamically) instruct the WTRU to switch between cross-slot scheduling and same-slot scheduling. For example, same-slot and cross-slot scheduling may be used in same-slot scheduling. The PSS transmitted during active time may use different DCI formats. The PSS transmitted during active time may use the currently used DCI format, for example, by adding different bits to the DCI. The PSS transmitted during active time may use one or more (e.g., different) DCI formats, for example, by adding bits in a first DCI format or re-planning one or more bits (e.g., by configuring bits to indicate power saving techniques). In an example, a DCI with a PSS bit may be monitored by a WTRU with a specified periodicity.
[0175] The power saving scheme may be configured using the WUS PSS and the active time PSS. For example, the same power saving scheme may be configured using the WUS PSS and the active time PSS. In an example, the WUS PSS may indicate to the WTRU that cross-slot scheduling is performed during the associated active time. The active time PSS may be used to enable the WTRU to dynamically switch between same-slot and cross-slot scheduling (e.g., during the active time). For example, configuring same-slot or cross-slot scheduling may be achieved by setting a minimum value of the k0 and / or k2 parameters (e.g., to 0 slots or at least 1 slot, respectively).
[0176] In an example, the WUS PSS may indicate to the WTRU that cross-slot scheduling is used (e.g., by setting k0min(k2min) to at least 1 slot). For example, the WTRU may receive (e.g., in a data scheduling DCI) a resource allocation with k0 equal to zero slots. For example, the resource allocation may be indicated by a DCI code point that indicates an entry in a time division relay access (TDRA) table. The WTRU may, for example, revert to the same slot scheduling (e.g., setting k0min and k2min to 0 slots). For example, if a scheduling DCI with k0=0 indication is received in slot n, the WTRU may set k0min and k2min to 0 slots in slot n.
[0177] In an example, the WUS PSS may indicate to the WTRU that cross-slot scheduling is used (e.g., by setting k0min(k2min) to at least 1 slot). For example, the WTRU may receive (e.g., in a data scheduling DCI) a resource allocation with k2 equal to zero slots. For example, the resource allocation may be indicated by a DCI code point that indicates an entry in a time division relay access (TDRA) table. The WTRU may, for example, revert to the same slot scheduling (e.g., setting k0min and k2min to 0 slots). For example, if a scheduling DCI with a k2=0 indication is received in slot n, the WTRU may set k0min and k2min to 0 slots in slot n.
[0178] In an example, the WUS PSS may indicate to the WTRU that cross-slot scheduling is used (e.g., by setting k0min(k2min) to at least 1 slot). For example, the WTRU may receive (e.g., in a data scheduling DCI) an aperiodic CSI-RS triggering indication with a trigger offset indicated as 0 slots. The WTRU may, for example, revert to the same slot scheduling (e.g., setting k0min and k2min to 0 slots). For example, if a scheduling DCI with an aperiodic CSI-RS triggering offset = 0 indication is received in slot n, the WTRU may set k0min and k2min to 0 slots in slot n.
[0179] In one or more examples, for example, if the WTRU is in the same time slot scheduling mode, the minimum aperiodic CSI-RS triggering offset may be set to 0 time slots. For example, if the WTRU is in the cross-time slot scheduling mode, the minimum aperiodic CSI-RS triggering offset may be set equal to k0min.
[0180] In an example, the WUS PSS may be transmitted (e.g., always) before (e.g., every) active time associated with the WUS PSS. The WUS PSS may include a bit field to indicate to the WTRU whether to wake up. The WTRU may wake up (e.g., if the WTRU does not detect the WUS PSS). The WTRU may determine that the same timeslot scheduling may be used in an upcoming associated active time. For example, if the WTRU does not detect the WUS PSS, the WTRU may wake up, determine that the same timeslot scheduling may be used in an upcoming associated active time, and / or may set one or more of k0min, k2min, and / or the minimum aperiodic CSI-RS triggering offset to 0 timeslots.
[0181] The configuration of the WUS PSS may indicate the configuration of the active time PSS (e.g., DCI format). For example, the WUS PSS may be configured with a bit field for activating / deactivating cross-slot scheduling. The active time PSS may be configured to have a bit field for activating / deactivating cross-slot scheduling. The WUS PSS may be configured to not have a bit field for activating / deactivating cross-slot scheduling. The active time PSS may be configured to not have a bit field for activating / deactivating cross-slot scheduling.
[0182] The WTRU may indicate to the gNB (e.g., explicitly) that the WTRU cannot monitor the WUS. For example, if the WUS contains additional information, the WTRU may indicate to the gNB (e.g., explicitly) that the WTRU cannot monitor the WUS. The WTRU may indicate to the gNB (e.g., explicitly) that the WTRU cannot monitor the WUS, for example, via RACH or SR. The additional information may include, for example, k0 / k2 values for cross-slot scheduling and / or BWP switching.
[0183] The network may, for example, indicate a missing value to the WTRU in the corresponding on-duration. For example, if the network can expect that the WTRU cannot monitor the WUS, the network may indicate a missing value to the WTRU in the corresponding on-duration (e.g., via the DCI). For example, if the network knows that no current search space configuration is mapped to the WTRU in a given on-duration, the network may expect that the WTRU cannot monitor the WUS. The WTRU may not be able to detect the WUS. The WTRU may (e.g., if the WTRU cannot detect the WUS) wake up in the corresponding on-duration and monitor the PDCCH for the corresponding on-duration (e.g., using one or more of the PS-RNTI, the group power save RNTI, or the dedicated C-RNTI).
[0184] For example, if a PSS WUS is not configured for the WTRU, the WTRU may monitor one or more (eg, some or all) short DRX cycles. The WTRU may receive relevant PSS information, for example, via a MAC CE (eg, a short DRX MAC CE).
[0185] The TCI state of the WUS may be indicated (e.g., dynamically). In an example, the WUS may be configured by RRC. For example, during the active time, the WUS may be activated and / or deactivated using MAC CE signaling. Deactivation may be based on expiration of a timer. The MAC CE that may be used to activate the WUS may provide other information (e.g., the active TCI state of the CORESET for the WUS).
[0186] The MAC CE may be used to activate the TCI state of the CORESET for the WUS. For example, if a TCI state activation command is received, the WTRU may determine that the WUS is activated. For example, the WUS may be deactivated by the expiration of a timer. For example, if a different MAC CE is received, the timer may be reset.
[0187] In an example, the presence and / or configuration of the WUS may be determined, for example, by the DRX cycle (e.g., indicating WTRU specific or group common, DCI format and content, etc.). For example, the WUS may be activated due to a short DRX cycle but not for a long DRX cycle, or vice versa.
[0188] The WTRU may be configured to operate in a cross-slot scheduling mode. The WTRU may be configured to operate according to a power saving state. In an example, the WTRU may be configured to operate according to one of a plurality of (e.g., a set of) power saving states. In an example, the WTRU may operate in a cross-scheduling mode, for example, where the minimum values of the k0 and k2 parameters may be set so that a specific entry of the PDSCH and / or PUSCH TDRA table configured by the RRC may not be used for data scheduling. A specific entry may include an entry associated with a k0 or k2 parameter that may be less than a minimum value. An entry of the TDRA table may indicate that the table or entry may not be used for data scheduling. The WTRU (e.g., based on an entry) may not expect to receive a grant or allocation in the DCI indicating an entry of the TDRA table that has a k0 or k2 that is less than the configured minimum value.
[0189] The power saving state may indicate that certain entries of the TDRA table are excluded. In an example, the power saving state may indicate that certain entries of the TDRA table are excluded (e.g., by setting a minimum k0 / k2 value). The normal power state may indicate that some or all entries of the TDRA table are available. In an example, the normal power state may indicate that one or more (e.g., all) entries of the TDRA table are available without restriction.
[0190] The power saving state may be set according to the attribute of at least one of long DRX and short DRX. For example, the minimum value of the k0 and / or k2 parameters may be set according to the attribute of at least one of long DRX and short DRX.
[0191] For example, the WTRU may monitor the PDCCH while in the active time. The WTRU's active time may include the time when one or more timers (e.g., drx-onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, or ra-ContentionResolutionTimer) are running.
[0192] The minimum values of multiple parameters (e.g., k0 and k2) may be signaled together (e.g., jointly). In an example, there may be two minimum values, e.g., k0min and k2min. The two values may be signaled jointly, e.g., using a 1-bit indication in the DCI (e.g., DCI1_1 or DCI 0_1). For example, as shown in Table 1, bit 0 in the DCI may indicate that the minimum k0 and k2 values are set to k01, k21, respectively, and bit 1 in the DCI may indicate that the minimum k0 and k2 values are set to k02, k22, respectively.
[0193] Table 1 - Example of signaling k0min / k2min values
[0194] DCI bit Indicates the minimum values of k0 and k2 Bit 0 <![CDATA[k01、k21]]> Bit 1 <![CDATA[k02、k22]]>
[0195] The minimum values of parameters k0 and k2 may be configured by RRC and / or determined by the WTRU. In an example, the values of k01, k21, k02, k22 may be configured by RRC and / or determined by the WTRU.
[0196] The RRC may configure one or both of k01, k02. In an example, the WTRU (eg, if only one value is configured) may assume that the other (eg, unconfigured) value indicates that there is no restriction in the TDRA table.
[0197] The RRC may configure one or both of k21, k22. In an example, the WTRU (eg, if only one value is configured) may assume that the other (eg, unconfigured) value indicates that there is no restriction in the TDRA table.
[0198] The WTRU may set the minimum value of k0 and k2 to a specific pair. In an example, the WTRU may set the minimum value of k0 and k2 to a pair in the pair (k01, k21) or (k02, k22). The pair may be configured or based on a rule. The rule may be configured or defined.
[0199] The WTRU may set the minimum values of k0 and k2 to a specific pair, for example, based on one or more conditions. In an example (e.g., based on one or more conditions described herein), the WTRU may set the minimum values of k0 and k2 to a pair in (k01, k21) or (k02, k22), where the pair may be configured or based on a rule. For example, the pair may be a pair that results in a restriction on the TDRA table. For example, the pair may be a pair indexed using a specific index, such as the lowest index (e.g., bit 0). For example, the pair may be a pair indexed using the maximum index (e.g., bit 1). For example, the pair may be a pair that enables the WTRU to perform power saving (e.g., by entering a power saving state).
[0200] The condition (e.g., setting the minimum values of K0 and k2 as a pair) may include, for example, if one or more of the following timers (e.g., a combination or subset thereof, such as some or all) are not running or have expired: drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, ra-ContentionResolutionTimer, drx-HARQ-RTT-TimerDL, drx-HARQ-RTT-TimerUL, and drx-onDurationTimer is not running.
[0201] The condition (e.g., setting the minimum value of K0 and k2 to a pair) may include, for example, if one or more of the following timers (e.g., a combination or subset thereof, such as some or all) are not running or have expired: drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, ra-ContentionResolutionTimer, drx-HARQ-RTT-TimerDL, drx-HARQ-RTT-TimerUL,
[0202] The condition (eg, setting the minimum values of K0 and k2 as a pair) may include, for example, if the WTRU is not in active time.
[0203] The conditions (e.g., setting the minimum values of K0 and k2 as a pair) may include, for example, if the WTRU is not in active time and the timers (drx-HARQ-RTT-TimerDL and drx-HARQ-RTT-TimerUL) are not running or have expired.
[0204] One or more examples (eg, based on one or more conditions) may apply to long and / or short DRX cycles (eg, long and short DRX cycles, long DRX cycle only, etc.).
[0205] For example, if the WTRU switches to a different BWP, the WTRU may set the minimum value of k0 and k2 to a specific pair. For example, if the WTRU switches to a different BWP, the WTRU may set the minimum value of k0 and k2 to a pair in the pair (k01, k21) or (k02, k22). The pair may be configured or rule-based. The rule may be configured or defined. For example, the pair may be a pair that results in a restriction on the TDRA table. The pair may be a pair indexed with a specific index, such as the lowest index (e.g., bit 0). The pair may be a pair indexed with the maximum index (e.g., bit 1). The pair may be a pair that will enable the WTRU to perform power saving (e.g., by entering a power saving state).
[0206] MIMO adaptation may be performed based on BWP (e.g., per BWP). The antenna port used for data transmission (e.g., in NR DL) may be signaled, for example, in DCI format 1_1 with a bit field having a length of 4, 5, or 6 bits. The length of the bit field (bitwidth) may be configured, for example, by RRC (e.g., via an RRC configuration message). For example, the length of the bit field (bitwidth) may be configured, for example, by RRC through DM-RS configuration parameters (e.g., dmrs-Type and maxLength), as shown in Table 2. Separate tables may be used for PDSCH mapping types A and B. In an example, a table may be specified for (e.g., each) DM-RS parameter pair. The DCI bit may indicate a row in the corresponding table. The row may include an index of the antenna port and / or other related parameters.
[0207] Table 2 - Example of antenna port bitwidth determination
[0208] dmrs-Type maxLength DCI bit field length 1 1 4 1 2 5 2 1 5 2 2 6
[0209] In some examples, the number of antenna ports may be the same for some or all BWPs. The number of antenna ports may be different for some or all BWPs. For example, the number of antenna ports may be determined per BWP. For example, if the number of antenna ports is determined per BWP, the number of bits used in the antenna port field of the DCI may be different (e.g., 4 bits, 5 bits, or 6 bits).
[0210] For example, the size of the "antenna port" bit field may be determined, for example, as a maximum value of the DCI bit field length. In an example, the size of the "antenna port" bit field may be determined, for example, as a maximum value of the DCI bit field length over all configured BWPs, for example, as shown in Equation 1:
[0211]
[0212] As shown in Formula 1, i may be a BWP index. It can be the antenna port bitwidth, which can be derived for BWP i according to dmrs-DownlinkForPDSCH-MappingTypeA. B It can be the antenna port bitwidth, which can be derived for BWP i according to dmrs-DownlinkForPDSCH-MappingTypeB. For example, if the WTRU is not configured with dmrs-DownlinkForPDSCH-MappingTypeA, then for a given BWP i, can be used as zero in Equation 1. For example, if the WTRU is not configured with dmrs-DownlinkForPDSCH-MappingTypeB, then for a given BWP i, can be used as zero in Equation 1.
[0213] For example, if the number of antenna ports in a BWP is less than bitwidth, zero padding may be performed. In the example, for example, if the number of antenna ports k in BWP i is less than bitwidth, zero padding may be performed. i If it is less than bitwidth, then (bitwidth-k) zeros may be padded to the MSB of bitwidth.
[0214] The number of active RF chains for (e.g., one) BWP may be different from the number of RF chains for another BWP. BWP switching may require a certain amount of time to complete. In an example (e.g., if the number of antenna ports is determined per BWP), the number of active RF chains for a BWP may be different from the number of RF chains for another BWP. In an example, more RF chains may be used to support more antenna ports. For example, four (4) or more RF chains may be used to support four (4) antenna ports, while two (2) or more RF chains may be used to support (2) antenna ports.
[0215] In an example, the time for switching the BWP may be determined based on one or more of the following. For example, if the target and current BWP are configured with the same number of antenna ports, t may represent the time (e.g., in ms, time slots, or OFDM symbols) for switching from the current BWP to the target BWP. For example, t may have the same value as defined in NR.
[0216] For example, if the target BWP is configured with more antenna ports than the current BWP, the time for switching the BWP may be t+offset1. The value of offset1 (e.g., the additional time) may depend on, for example, the absolute value of the antenna ports on the target and / or current BWP. The value of offset1 (e.g., the additional time) may depend on the difference between the number of antenna ports configured for the target and current BWP. The value of offset1 (e.g., the additional time) may be a fixed value that may depend on parameters other than the number of antenna ports of the target and current BWP. For example, the offset1 value may be based on (e.g., at least) the subcarrier spacing of the target BWP.
[0217] For example, if the target BWP is configured with fewer antenna ports than the current BWP, the time for switching may be t. Additional time may not be required to shut down some of the RF chains. The time for switching may be t+offset2. The offset2 (e.g., additional time) value may be fixed and / or may depend on, for example, (e.g., at least) the subcarrier spacing of the target BWP. In an example, the additional time for switching from BWP i to BWP j may be the same as the additional time for switching from BWP j to BWP i.
[0218] One or more power saving signal / wake-up signal offsets may be configured (eg, for short DRX). An (eg, implicit) offset indication may be associated with a search space configuration.
[0219] In an example, the WTRU may monitor the PSS WUS for a short DRX cycle in a configured search space. For example, when a short DRX cycle starts a DRX short cycle duration, the search space may be selected (eg, implicitly), for example, based on parameters of the short DRX cycle.
[0220] In an example, the network may indicate a range of opportunities (eg, in time and / or frequency) in which monitoring opportunities may occur. For example, if the retrieval space monitoring opportunity falls within the range, the WTRU may observe the current search space configuration and / or may monitor the PSS WUS.
[0221] The mapping between the DRX offset range and / or PSS WUS search space monitoring and DRX parameters may be configured (e.g., semi-statically) and / or dynamically updated. The mapping between the DRX offset range and / or PSS WUS search space monitoring and DRX parameters may be configured, for example, via one or more of: DRX configuration, DCI, and / or RRC signaling.
[0222] The WTRU may be configured with multiple possible search spaces. The WTRU may be configured with a mapping between a PSS WUS search space monitoring opportunity and the start of short DRX. The WTRU may (e.g., after entering short DRX) select between search spaces based on, for example, the timeslot in which short DRX starts. The WTRU may monitor the PSS WUS in the subspace for the corresponding on-duration.
[0223] The WTRU may be provided with a range of possible time-frequency resources in which to monitor the PSS WUS (e.g., during DRX configuration). The WTRU may select its current search space configuration or a search space that satisfies the range. For example, if multiple search spaces are valid (e.g., fall within the indicated range), the WTRU may monitor in more than one search space. For example, if more than one search space is valid, the WTRU may select among the multiple search spaces (e.g., based on predefined criteria).
[0224] An offset and / or range of possible time-frequency resources may be provided to the WTRU to monitor the PSS WUS. In an example, for example, if the search space does not satisfy the indicated range, the WTRU may switch between several search spaces on subsequent monitoring occasions to satisfy the range. For example, if the periodicity of the search space is not aligned with the DRX cycle, the search space may not satisfy the indicated range. For example, the offset between the search space and the on-duration may not be fixed. The WTRU may switch between several search spaces on subsequent monitoring occasions to satisfy the range.
[0225] A separate search space may be associated with a short DRX cycle. The WTRU may monitor a separate search space for WUS. The parameters of the search space may be used to indicate when the WTRU monitors the WUS. The parameters of the search space may include, for example, monitoring periodicity and slot offset, monitoring symbols within a slot, etc. In an example, the DRX on duration of the short cycle may start every 23 milliseconds (e.g., drx-ShortCycle=20ms, drx-StartOffset=3ms). The monitoringSlotPeriodicityAndOffset parameter of the search space may be configured, for example, so that the WTRU may start monitoring the WUS every 23 milliseconds-WUS-Offset. The parameters of the search space may be configured, for example, as shown in Equation 1 and Equation 2:
[0226] WUSmonitoringSlotPeriodicity = drx-ShortCycle Formula 1
[0227] WUSmonitoringSlotOffset = drx-StartOffset - WUS-offset Equation 2
[0228] For example, if drx-ShortCyleTimer is running, the WTRU may monitor the search space associated with the short DRX cycle. For example, if drx-ShortCyleTimer is not running, the WTRU may not (e.g., intend to) monitor the search space associated with the short DRX cycle.
[0229] The search space may be associated with both long DRX and short DRX. The search space may include parameters defining monitoring opportunities associated with long and / or short DRX. For example, the parameter WUSmonitoringSlotPeriodicity for long DRX may be a multiple of the parameter for short DRX. For example, if drx-ShortCyleTimer is running, the WTRU may monitor the search space associated with short DRX. For example, if drx-ShortCyleTimer is not running, the WTRU may not expect to monitor the search space associated with the short DRX cycle.
[0230] For example, if the drxShortCyleTimer is running, the WTRU may not monitor the WUS search space associated with a long DRX cycle.
[0231] The offset configuration may be explicit. The indicated offset may be the same for both the short DRX cycle and the long DRX cycle. For example, if (e.g., only) one offset value is indicated to the WTRU, the WTRU may assume that the offset is a default value that applies to both the short DRX cycle and the long DRX cycle.
[0232] The PSS WUS offset value may be configured for the short DRX cycle and the long DRX cycle, respectively. The offset value may be configured semi-statically, for example. The offset value may be configured dynamically, for example.
[0233] Multiple offsets may be indicated to the WTRU. The WTRU may monitor in valid offset opportunities. In an example, for example, based on one or more short DRX cycle conditions, the WTRU may (e.g., only) monitor in valid offset opportunities. For example, if the WTRU starts a short DRX cycle, the short DRX cycle conditions may include, among other things, the length of the short cycle. Valid offset opportunities may include, for example, an offset that falls within a short DRX cycle, an offset that satisfies a minimum time before the start of the on-duration, and / or an offset that falls within a configured search space. The selection of the monitoring opportunity may be performed autonomously (e.g., by the WTRU). The selection of the monitoring opportunity may be based on a criterion (e.g., defined by the network).
[0234] The DRX offset may be configured (eg, semi-statically) and / or dynamically updated. The DRX offset may be configured, for example, via one or more of: DRX configuration, DCI, and / or RRC signaling.
[0235] The WTRU may (e.g., autonomously) select which short DRX offset to monitor. In an example, the WTRU may be configured with a PSS WUS monitoring offset for long DRX (e.g., during initial DRX configuration), and several possible monitoring offsets for short DRX. For example, depending on the time when the WTRU enters short DRX, the WTRU may (e.g., autonomously) select which short DRX offset to monitor. The selection of the short DRX monitoring opportunity may follow a rule (e.g., defined by the network).
[0236] During initial DRX configuration, the WTRU may be set with a default offset value. The default offset value may be applied to long DRX and short DRX. The network may send a modified offset for short DRX or long DRX. For example, the network may (e.g., at a certain point) send a modified offset for short DRX or long DRX (e.g., via DCI or dedicated RRC signaling). The WTRU may apply the offset, for example, after a predefined time (e.g., the next DRX monitoring opportunity).
[0237] The WTRU may be configured to ignore WUS, for example, within a short DRX cycle. The WTRU may ignore the PSS WUS and wake up during the corresponding on-duration, or the WTRU may remain asleep. In some examples, the WTRU may not (e.g., be able to) meet one or more monitoring criteria. In various examples, the short DRX cycle may be shorter than the monitoring offset, and / or the cycle duration may not be sufficient for the WTRU to complete WUS monitoring; the mapping between the short cycle start and the current search space configuration may not be available; the current search space configuration may not fall within the indicated range; and the like. The WTRU may ignore (e.g., if the WTRU cannot meet the monitoring criteria) the PSS WUS and wake up during the corresponding on-duration, or the WTRU may remain asleep.
[0238] For example, if a threshold for a DRX cycle is met, the WTRU may (e.g., expected) monitor the search space. In an example, for example, if (e.g., only if) a parameter drx-ShortCycle is greater than a first threshold and / or if a parameter drx-LongCycle is greater than a second threshold, the WTRU may (e.g., expected) monitor the search space. For example, if the cycle is less than a corresponding threshold, the WTRU may not (e.g., expected) monitor the associated search space for the WUS. The WTRU may (e.g., if the cycle is less than a corresponding threshold) wake up or sleep during a corresponding on-duration. Whether to wake up or sleep may be configured or defined as a rule, for example. The thresholds may be configurable (e.g., including a first threshold and a second threshold).
[0239] The WTRU may skip the long DRX On Duration. For example, if the short DRX cycle timer is running when the long DRX On Duration arrives, the WTRU may skip the long DRX On Duration and / or may continue monitoring according to the corresponding short cycle monitoring configuration.
[0240] For example, depending on whether certain criteria are met, the WTRU may monitor or ignore PSS WUS within a short DRX cycle. In an example, the WTRU may be set with independent PSS WUS monitoring opportunities for short DRX values and long DRX values. For example, if (and only if) it meets certain criteria, the WTRU may monitor the short DRX PSS WUS opportunity that undergoes a shift (e.g., after entering short DRX). The criteria may be predetermined. The predetermined criteria may include one or more of a minimum processing time, a DRX cycle duration, etc. For example, if the criteria are met, the WTRU may monitor PSS WUS within a short DRX cycle. For example, if the criteria are not met, the WTRU may ignore PSS WUS. For example, if the WTRU ignores the WUS, the WTRU may wake up and monitor the corresponding on-duration, or ignore the on-duration and remain asleep.
[0241] For example, if no preconfigured search space satisfies the indicated offset or range of the time-frequency resources, the WTRU may apply the offset for the long DRX indication.The WTRU may not monitor the WUS and may wake up and monitor the corresponding on-duration, or remain asleep.
[0242] Figure 5 An example for performing beam failure detection and recovery is shown. The examples disclosed herein and other examples may be based on Figure 5 The example 500 operation is shown. Performing beam failure detection and recovery may include 502 to 512. In 502, a first group of beams and a second group of beams may be determined. In 504, a corresponding quality of each beam in the first group of beams may be determined to have a quality less than a predetermined quality value. In 506, a beam in the second group of beams but not in the first group of beams may be determined to have a quality equal to or greater than a predetermined quality value. In 508, a beam in the second group of beams but not in the first group of beams and whose quality is equal to or greater than the predetermined quality value may be selected for beam failure recovery (BFR). In 510, a message indicating the selected beam for BFR may be sent to a gNodeB (gNB). In 512, a message including the selected beam may be received from the gNB.
[0243] Figure 6 An example for performing beam failure detection and recovery for WUS monitoring is shown. The examples disclosed herein and other examples may be based on Figure 6The example 600 operation is shown. Performing beam failure detection and recovery for WUS monitoring may include 602 to 608. In 602, a wake-up signal (WUS) monitoring may be performed using a subset of beams in a group of beams for monitoring a physical downlink control channel (PDCCH). In 604, a beam failure for WUS monitoring (BF-WUS) may be detected based on a failure of all beams in the beam subset. In 606, at least one beam in the group of beams but not in the beam subset may be identified as at least one preferred beam for WUS beam failure recovery (BFR). In 608, WUS BFR may be requested by notifying network nodes around the BF-WUS and by indicating the at least one preferred beam for WUS BFR.
[0244] Although features and elements are described above in specific combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and 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 built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.
Claims
1. A method implemented in a wireless transmit / receive unit WTRU, comprising: receiving a first message, the first message including configuration information, the configuration information indicating one or more reference signals and indicating wake-up signal monitoring; receiving one or more reference signals; performing one or more measurements on the received one or more reference signals, respectively; receiving at least one wake-up signal; as well as Whether to ignore the at least one wake-up signal or to monitor the at least one wake-up signal is determined based on one or more measurement values of the one or more measurements, respectively.
2. The method according to claim 1, wherein: The configuration information further indicates an association between the one or more reference signals and one or more thresholds, and the method comprises: The at least one wake-up signal is ignored on the condition that the one or more measured values are respectively lower than one or more thresholds respectively associated with the received one or more reference signals.
3. The method according to claim 1, wherein: The configuration information further indicates an association between the one or more reference signals and one or more thresholds, and the method comprises: The at least one wake-up signal is monitored under the condition that the one or more measured values respectively exceed one or more thresholds respectively associated with the received one or more reference signals.
4. The method according to claim 3, comprising: The at least one wake-up signal is monitored under the condition that the one or more measured values exceed the one or more threshold values respectively for a specified period of time.
5. The method according to claim 1, wherein: The one or more measurements performed are performed on one or more reference signals used to determine a receive beam for the WTRU.
6. The method according to claim 1, wherein: The configuration information includes a transmission configuration indicator (TCI) state for the wake-up signal indicating the one or more reference signals.
7. A wireless transmit / receive unit WTRU, comprising a processor, a transceiver unit and a storage unit, and configured to: receiving a first message, the first message including configuration information, the configuration information indicating one or more reference signals and indicating wake-up signal monitoring; receiving one or more reference signals; performing one or more measurements on the received one or more reference signals, respectively; receiving at least one wake-up signal; as well as Whether to ignore the at least one wake-up signal or to monitor the at least one wake-up signal is determined based on one or more measurement values of the one or more measurements, respectively.
8. The WTRU of claim 7 wherein: The configuration information further indicates an association between the one or more reference signals and one or more thresholds, and is configured as: The at least one wake-up signal is ignored on the condition that the one or more measured values are respectively lower than one or more thresholds respectively associated with the received one or more reference signals.
9. The WTRU of claim 7 wherein: The configuration information further indicates an association between the one or more reference signals and one or more thresholds, and is configured as: The at least one wake-up signal is monitored under the condition that the one or more measured values respectively exceed one or more thresholds respectively associated with the received one or more reference signals.
10. The WTRU of claim 9, configured to: The at least one wake-up signal is monitored under the condition that the one or more measured values exceed the one or more threshold values respectively for a specified period of time.
11. The WTRU of claim 7 wherein: The one or more measurements performed are performed on one or more reference signals used to determine a receive beam for the WTRU.
12. The WTRU of claim 7 wherein: The configuration information includes a transmission configuration indicator (TCI) state for the wake-up signal indicating the one or more reference signals.