Reporting transmissions for discontinuous reception
By optimizing DRX operation through symbol identification and report transmission during discontinuous reception, the problems of resource waste and power consumption in wireless communication are solved, thereby improving resource utilization and battery life.
Patent Information
- Application Number
- CN202080061910.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2019-09-12
- Filing Date
- 2020-07-15
- Publication Date
- 2025-11-18
- Estimated Expiration
- 2040-07-15
AI Technical Summary
In wireless communication, existing technologies have failed to effectively address the symbol reporting problem during discontinuous reception (DRX), leading to resource waste and increased power consumption.
By determining whether a symbol appears within a discontinuous reception duration and transmitting a report when necessary, DRX operation can be optimized to reduce unnecessary resource consumption.
This achieves improved resource utilization and power savings during discontinuous reception, extending the device's battery life.
Smart Images

Figure CN114342459B_ABST
Abstract
Description
[0001] Cross-references to related applications
[0002] This application claims priority to U.S. Patent Application Serial No. 62 / 899,370, filed September 12, 2019, by Joachim Loehr, entitled “APPARATUSES, METHODS, AND SYSTEMS FOR A DRX OPERATION CONSIDERING WAKE-UP SIGNALING,” which is incorporated herein by reference in its entirety. Technical Field
[0003] The topics disclosed in this article generally relate to wireless communication, and more specifically to reports on transmissions used for discontinuous reception. Background Technology
[0004] The following abbreviations are defined herein, and at least some of them are referenced in the following description: 3rd Generation Partnership Project (“3GPP”), 5th Generation (“5G”), QoS for NR V2X Communication (“5QI / PQI”), Authentication, Authorization and Accounting (“AAA”), Positive Acknowledgment (“ACK”), Application Function (“AF”), Authentication and Key Protocol (“AKA”), Aggregation Level (“AL”), Access and Mobility Management Function (“AMF”), Angle of Arrival (“AoA”), Angle of Departure (“AoD”), Access Point (“AP”), Application Server (“AS”), Application Service Provider (“ASP”), Autonomous Uplink (“AUL”), Authentication Server Function (“AUSF”), Authentication Token (“AUTN”), Background Data (“BD”), Background Data Delivery (“BDT”), Beam Fault Detection (“BFD”), Beam Fault Recovery (“BFR”), Binary Phase Shift Keying (“BPSK”), Base Station (“BS”), Buffer Status Report (“BSR”), Bandwidth (“BW”), Bandwidth Portion (“BWP”), Cell RNTI (“C-RNTI”), Carrier Aggregation (“CA”), Channel Access Priority Class (“CAPC”), Contention-Based Random Access (“CBRA”), Clear Channel Assessment (“CCA”), Common Control Channel (“CCCH”), Control Channel Element (“CCE”), Cyclic Delay Diversity (“CDD”), Code Division Multiple Access (“CDMA”), Control Element (“CE”), Contention-Free Random Access (“CFRA”), Configured License (“CG”), Closed Loop (“CL”), Coordinated Multipoint (“CoMP”), Channel Occupancy Time (“COT”), Cyclic Prefix (“CP”), Cyclic Redundancy Check (“CRC”), Configured Scheduling RNTI (“CS-RNTI”), Channel State Information (“CSI”), Channel State Information-Reference Signal (“CSI-RS”), Common Search Space (“CSS”), Control Resource Set (“CORESET”), Dual Connectivity (“DC”), Discrete Fourier Transform Extended (“DFTS”), Downlink Control Information (“DCI”), Downlink Feedback Information (“DFI”), Downlink Link (“DL”), Demodulation Reference Signal (“DMRS”), Data Network Name (“DNN”), Data Radio Bearer (“DRB”), Discontinuous Receive (“DRX”), Dedicated Short Range Communication (“DSRC”), Downlink Pilot Slots (“DwPTS”), Enhanced Clear Channel Assessment (“eCCA”), Enhanced Mobile Broadband (“eMBB”), Evolved Node B (“eNB”), Extensible Authentication Protocol (“EAP”), Effective Isotropic Radiated Power (“EIRP”), European Telecommunications Standards Institute (“ETSI”), Frame-Based Equipment (“FBE”), Frequency Division Duplex (“FDD”), Frequency Division Multiplexing (“FDM”)Frequency Division Multiple Access (“FDMA”), Frequency Division Orthogonal Coverage Code (“FD-OCC”), frequency range 1–6 GHz and / or 410 MHz to 7125 MHz (“FR1”), frequency range 2–24.25 GHz to 52.6 GHz (“FR2”), Common Geographic Area Description (“GAD”), Guaranteed Bit Rate (“GBR”), Group Leader (“GL”), 5G Node B or Next Generation Node B (“gNB”), Global Navigation Satellite System (“GNSS”), General Packet Radio Service (“GPRS”), Guard Period (“GP”), Global Positioning System (“GPS”), Common Public Subscription Identifier (“GPSI”), Global Mobile Communications System (“GSM”) The following are included: Globally Unique Temporary UE Identifier (“GUTI”), Home AMF (“hAMF”), Hybrid Automatic Repeat Request (“HARQ”), Home Location Register (“HLR”), Handover (“HO”), Home PLMN (“HPLMN”), Home Subscriber Server (“HSS”), Hash Expected Response (“HXRES”), Identifier or Identifier (“ID”), Information Element (“IE”), International Mobile Equipment Identity (“IMEI”), International Mobile Subscriber Identity (“IMSI”), International Mobile Telecommunications Equipment (“IMT”), Internet of Things (“IoT”), Interrupt RNTI (“INT-RNTI”), Key Management Function (“KMF”), and Layer 1 (“L1”). Layer 2 (“L2”), Layer 3 (“L3”), Licensed Auxiliary Access (“LAA”), Local Area Data Network (“LAND”), Local Area Network (“LAN”), Load-Based Equipment (“LBE”), Listen-After-Speak (“LBT”), Logical Channel (“LCH”), Logical Channel Group (“LCG”), Logical Channel Priority (“LCP”), Log-Likelihood Ratio (“LLR”), Long Term Evolution (“LTE”), Multiple Access (“MA”), Media Access Control (“MAC”), Multimedia Broadcast Multicast Service (“MBMS”), Maximum Bit Rate (“MBR”), Primary Cell Group (“MCG”), Minimum Communication Range (“MCR”), Modulation and Coding Scheme (“MCS”) Master Information Block (“MIB”), Multimedia Internet Keying (“MIKEY”), Multiple-Input Multiple-Output (“MIMO”), Mobility Management (“MM”), Mobility Management Entity (“MME”), Mobile Network Operator (“MNO”), Mobile Initiation (“MO”), Massive MTC (“mMTC”), Maximum Power Reduction (“MPR”), Machine Type Communication (“MTC”), Multi-User Shared Access (“MUSA”), Non-Access Stratum (“NAS”), Narrowband (“NB”), Negative Acknowledgment (“NACK”) or (“NAK”), New Data Indicator (“NDI”), Network Entity (“NE”), Network Exposure Function (“NEF”), Network Function (“NF”)Next Generation (“NG”), NG 5G S-TMSI (“NG-5G-S-TMSI”), Non-Orthogonal Multiple Access (“NOMA”), New Radio (“NR”), Unlicensed NR (“NR-U”), Network Repository Function (“NRF”), Network Scheduling Modes (“NS Modes”) (e.g., Network Scheduling Modes for V2X Communication Resource Allocation—Mode 1 in NR V2X and LTE) In V2X, the following are considered: Mode 3, Network Slice Instance (“NSI”), Network Slice Selection Assistance Information (“NSSAI”), Network Slice Selection Function (“NSSF”), Network Slice Selection Policy (“NSSP”), Operation, Management and Maintenance System or Operation and Maintenance Center (“OAM”), Orthogonal Frequency Division Multiplexing (“OFDM”), Open Loop (“OL”), Other System Information (“OSI”), Power Angle Spectrum (“PAS”), Physical Broadcast Channel (“PBCH”), Power Control (“PC”), UE-to-UE Interface (“PC5”), Policy and Charging Control (“PCC”), Primary Cell (“PCell”), Policy Control Function (“PCF”), Physical Cell Identifier (“PCI”), Physical Downlink Control Channel (“PDCCH”), Packet Data Convergence Protocol (“PDCP”), Packet Data Network Gateway (“PGW”), Physical Downlink Shared Channel (“PDSCH”), Mode Division Multiple Access (PDCCH) “PDMA”, Packet Data Unit (“PDU”), Physical Hybrid ARQ Indicator Channel (“PHICH”), Power Headroom (“PH”), Power Headroom Report (“PHR”), Physical Layer (“PHY”), Public Land Mobile Network (“PLMN”), PC5 QoS Class Identifier (“PQI”), Physical Random Access Channel (“PRACH”), Physical Resource Block (“PRB”), Proximity Service (“ProSe”), Location Reference Signal (“PRS”), Physical Sidelink Control Channel (“PSCCH”), Primary and Secondary Cell (“PSCell”), Physical Sidelink Feedback Control Channel (“PSFCH”), Physical Uplink Control Channel (“PUCCH”), Physical Uplink Shared Channel (“PUSCH”), QoS Class Identifier (“QCI”), Quasi-Co-location (“QCL”), Quality of Service (“QoS”), Quadrature Phase Shift Keying (“QPSK”), Registration Area (“RA”), RA RNTI (“RA-RNTI”), Radio Access Network (“RAN”), Random (“RAND”), Radio Access Technology (“RAT”), Serving RAT (“RAT-1”) (relative to Uu service), Other RAT (“RAT-2”) (not relative to Uu service), Random Access Procedure (“RACH”), Random Access Preamble Identifier (“RAPID”), Random Access Response (“RAR”), Resource Block Assignment (“RBA”), Resource Element Group (“REG”)Radio Link Control (“RLC”), RLC Acknowledgment Mode (“RLC-AM”), RLC Unacknowledgment Mode / Transparent Mode (“RLC-UM / TM”), Radio Link Failure (“RLF”), Radio Link Monitoring (“RLM”), Radio Network Temporary Identifier (“RNTI”), Reference Signal (“RS”), Residual Minimum System Information (“RMSI”), Radio Resource Control (“RRC”), Radio Resource Management (“RRM”), Resource Extended Multiple Access (“RSMA”), Reference Signal Received Power (“RSR”) Received Signal Strength Indicator (“RSSI”), Round Trip Time (“RTT”), Receive (“RX”), Sparse Code Multiple Access (“SCMA”), Scheduling Request (“SR”), Sounding Reference Signal (“SRS”), Single Carrier Frequency Division Multiple Access (“SC-FDMA”), Secondary Cell (“SCell”), Secondary Cell Group (“SCG”), Shared Channel (“SCH”), Sidechain Control Information (“SCI”), Subcarrier Spacing (“SCS”), Serving Data Unit (“SDU”), Security Anchor Function (“SEAF”), Sidechain Feedback Content Information (“SFCI”), Slot Format Indicator RNTI (“SFI-RNTI”), Serving Gateway (“SGW”), System Information Block (“SIB”), System Information Block Type 1 (“SIB1”), System Information Block Type 2 (“SIB2”), Subscriber Identifier / Identifier Module (“SIM”), Signal-to-Interference-plus-Noise Ratio (“SINR”), Sidelink (“SL”), Service Level Agreement (“SLA”), Sidelink Synchronization Signal (“SLSS”), Session Management (“SM”), Session Management Function (“SMF”), Semi-Persistent (“SP”), Special Cell (“SpCell”), Single Network Slice Selection Auxiliary Information (“S-NSSAI”), Scheduling Request (“SR”), Signaling Radio Bearer (“SRB”), Sounding Reference Signal (“SRS”), Shortened TMSI (“S-TMSI”), Shortened TTI (“sTTI”), Synchronization Signal (“SS”), Sidelink CSI RS (“S-CSI RS”), Sidechain PRS (“S-PRS”), Sidechain SSB (“S-SSB”), Synchronization Signal Block (“SSB”), Subscription Hidden Identifier (“SUCI”), Scheduled User Equipment (“SUE”), Supplemental Uplink (“SUL”), Subscriber Permanent Identifier (“SUPI”), Tracking Area (“TA”), TA Identifier (“TAI”), TA Update (“TAU”), Timing Calibration Timer (“TAT”), Transport Block (“TB”), Transport Block Size (“TBS”), Time Division Duplex (“TDD”), Time Division Multiplexing (“TDM”)Time Division Orthogonal Coverage Code (“TD-OCC”), Temporary Mobile Subscriber Identifier (“TMSI”), Time of Flight (“ToF”), Transmit Power Control (“TPC”), Transmit Receive Point (“TRP”), Transmission Time Interval (“TTI”), Transmit (“TX”), Uplink Control Information (“UCI”), Unified Data Management Function (“UDM”), Unified Data Repository (“UDR”), User Entity / Equipment (Mobile Terminal) (“UE”) (e.g., V2X UE), UE Autonomy Mode (UE autonomy selection of V2X communication resources – e.g., Mode 2 in NR V2X and Mode 4 in LTE V2X. UE autonomy selection may or may not be based on resource sensing operations), Uplink (“UL”), UL SCH (“UL-SCH”), Universal Mobile Telecommunications System (“UMTS”), User Plane (“UP”), UP Function (“UPF”), Uplink Pilot Time Slot (“UpPTS”), Ultra-Reliable and Low-Latency Communication (“URLLC”), UE Routing Policy (“URSP”), Vehicle-to-Vehicle (“V2V”), Vehicle-to-Everything (“V2X”), V2X UE (e.g., a UE capable of vehicular communication using 3GPP protocols), Access AMF (“vAMF”), V2X Encryption Key (“VEK”), V2X Group Key (“VGK”), V2X MIKEY Key (“VMK”), Access NSSF (“vNSSF”), Access PLMN (“VPLMN”), V2X Traffic Key (“VTK”), Wide Area Network (“WAN”), Global Microwave Access Interoperability (“WiMAX”), and Wake-up Signaling or Wake-up Sign (“WUS”).
[0005] In some wireless communication networks, discontinuous reception may occur. Summary of the Invention
[0006] Methods for reporting transmissions for discontinuous reception are disclosed. Apparatus and systems also perform the functions of these methods. One embodiment of a method includes determining whether a symbol appears within a discontinuous reception duration period. In some embodiments, the method includes determining whether to transmit a report in response to determining that a symbol appears within the discontinuous reception duration period. In some embodiments, the method includes transmitting a report regardless of whether a discontinuous reception duration timer is running.
[0007] An apparatus for reporting transmissions for discontinuous reception includes a processor that: determines whether a symbol appears within a discontinuous reception duration; and, in response to determining that a symbol appears within the discontinuous reception duration, determines whether to transmit a report. In various embodiments, the apparatus includes a transmitter that transmits a report regardless of whether a discontinuous reception duration timer is running. Attached Figure Description
[0008] A more specific description of the embodiments briefly described above will be presented by referring to the specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings depict only some embodiments and are not intended to be limiting of the scope; the embodiments will be described and explained with additional specificity and detail using the drawings, wherein:
[0009] Figure 1 This is a schematic block diagram illustrating one embodiment of a wireless communication system for reporting transmissions for discontinuous reception;
[0010] Figure 2 This is a schematic block diagram illustrating one embodiment of a device that can be used to report transmissions for discontinuous reception;
[0011] Figure 3 This is a schematic block diagram illustrating one embodiment of a device that can be used to report transmissions for discontinuous reception;
[0012] Figure 4 This is a timing diagram illustrating one embodiment of the DRX cycle; and
[0013] Figure 5 This is a flowchart illustrating one embodiment of a method for reporting transmissions used for discontinuous reception. Detailed Implementation
[0014] As those skilled in the art will understand, aspects of the embodiments can be embodied as a system, apparatus, method, or program product. Therefore, embodiments can take the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which may generally be referred to herein as "circuit," "module," or "system." Furthermore, embodiments can take the form of a program product embodied in one or more computer-readable storage devices stored in machine-readable code, computer-readable code, and / or program code, hereinafter referred to as "code." The storage device can be tangible, non-transitory, and / or non-transferable. The storage device may not embody signals. In one embodiment, the storage device only uses signals for accessing the code.
[0015] Certain functional units described in this specification may be designated as modules to more specifically emphasize their implementation independence. For example, modules may be implemented as hardware circuits comprising custom-designed very large-scale integration (“VLSI”) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Modules may also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc.
[0016] Modules can also be implemented in code and / or software for execution by various types of processors. The identified code module can, for example, comprise one or more physical or logical blocks of executable code, which can be organized, for example, as objects, procedures, or functions. However, the executable files of the identified modules do not need to be physically located together and can include unrelated instructions stored in different locations that, when logically combined, comprise the module and implement the stated purpose of the module.
[0017] In practice, a code module can be a single instruction or many instructions, and can even be distributed across several different code segments, different programs, and across several memory devices. Similarly, in this document, operational data can be identified and illustrated within a module, and can be represented in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single dataset or can be distributed across different locations, including different computer-readable storage devices. Where a module or part of a module is implemented in software, the software portion is stored on one or more computer-readable storage devices.
[0018] Any combination of one or more computer-readable media can be used. A computer-readable medium can be a computer-readable storage medium. A computer-readable storage medium can be a storage device for storing code. A storage device can be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof.
[0019] More specific examples of storage devices (a non-exhaustive list) will include the following: electrical connections with one or more cables, portable computer disks, hard disks, random access memory (“RAM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM” or flash memory), portable optical disc read-only memory (“CD-ROM”), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium capable of containing or storing programs for use by or in connection with an instruction execution system, apparatus, or device.
[0020] The code used to perform the operations of the embodiments can be any number of lines and can be written in any combination of one or more programming languages, including object-oriented programming languages such as Python, Ruby, Java, Smalltalk, C++, and common procedural programming languages such as the "C" programming language, and / or machine languages such as assembly language. The code can be executed entirely on the user's computer, partially on the user's computer, or as a standalone software package on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any type of network, including a local area network ("LAN") or a wide area network ("WAN"), or can be connected to an external computer (e.g., via the Internet provided by an Internet service provider).
[0021] References to "an embodiment," "embodiment," or similar language in this specification mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. Therefore, unless expressly stated otherwise, throughout this specification, the phrases "in an embodiment," "in an embodiment," and similar language may, but not necessarily all, refer to the same embodiment, but rather mean "one or more, but not all, embodiments." Unless expressly stated otherwise, the terms "comprising," "including," "having," and variations thereof mean "including, but not limited to,". Unless expressly stated otherwise, the list of enumerated items does not indicate that any or all items are mutually exclusive. Unless expressly stated otherwise, the terms "a," "an," and "the" also mean "one or more".
[0022] Furthermore, the features, structures, or characteristics of the described embodiments can be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that embodiments can be practiced without one or more specific details, or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the embodiments.
[0023] The following description of aspects of the embodiments is based on schematic flowcharts and / or schematic block diagrams of methods, apparatus, systems, and program products according to the embodiments. It will be understood that each block of the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. The code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to generate machinery, such that instructions executable via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / operations specified in the blocks or blocks of the schematic flowcharts and / or schematic block diagrams.
[0024] The code can also be stored in a storage device that can direct a computer, other programmable data processing apparatus or other device to operate in a particular manner, such that the instructions stored in the storage device produce an article of art that implements the function / operation specified in the schematic flowchart and / or schematic block diagram boxes or blocks.
[0025] The code can also be loaded onto a computer, other programmable data processing device, or other device to cause a series of operational steps to be executed on the computer, other programmable device, or other device to produce a computer-implemented process, such that the code executing on the computer or other programmable device provides for implementation in flowcharts and / or blocks. Figure 1 The processing of functions / operations specified in one or more boxes.
[0026] The schematic flowcharts and / or schematic block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, system, method, and program products according to different embodiments. In this regard, each block in the schematic flowcharts and / or schematic block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing one or more specified logical functions.
[0027] It should also be noted that in some alternative implementations, the functions annotated in the boxes may occur in a different order than those annotated in the figures. For example, depending on the functions involved, two boxes shown consecutively may actually be performed substantially simultaneously, or these boxes may sometimes be performed in reverse order. It is conceivable that other steps and methods are functionally, logically, or effectively equivalent to one or more boxes or portions thereof in the illustrated figures.
[0028] While various arrow and line types may be employed in flowcharts and / or block diagrams, understanding them does not limit the scope of the respective embodiments. In practice, some arrows or other connectors may be used solely to indicate the logical flow of the depicted embodiment. For example, an arrow may indicate a wait or monitoring period of unspecified duration between enumerated steps in a depicted embodiment. It will also be noted that each block in a block diagram and / or flowchart, as well as combinations of blocks in block diagrams and / or flowcharts, can be implemented by a dedicated hardware-based system performing a specific function or operation, or by a combination of dedicated hardware and code.
[0029] The description of the elements in each figure can be referenced to the elements in the preceding figures. Throughout all figures, the same reference numerals refer to the same elements, including alternative embodiments of the same elements.
[0030] Figure 1 An embodiment of a wireless communication system 100 for reporting transmissions for discontinuous access is described. In one embodiment, the wireless communication system 100 includes a remote unit 102 and a network unit 104. Although Figure 1 A specific number of remote units 102 and network units 104 are depicted, but those skilled in the art will recognize that any number of remote units 102 and network units 104 can be included in the wireless communication system 100.
[0031] In one embodiment, remote unit 102 may include computing devices such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smartphones, smart TVs (e.g., internet-connected televisions), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), aircraft, drones, etc. In some embodiments, remote unit 102 includes wearable devices such as smartwatches, fitness bands, optical head-mounted displays, etc. Furthermore, remote unit 102 may be referred to as a subscriber unit, mobile device, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, UE, user terminal, device, or other terms used in the art. Remote unit 102 may communicate directly with one or more network units 104 via UL communication signals. In some embodiments, remote unit 102 may communicate directly with other remote units 102 via sidelink communication.
[0032] Network unit 104 may be distributed across a geographical area. In some embodiments, network unit 104 may also be referred to as an access point, access terminal, base station, base station, node-B, eNB, gNB, home node-B, relay node, device, core network, air server, wireless access node, AP, NR, network entity, AMF, UDM, UDR, UDM / UDR, PCF, RAN, NSSF, AS, NEF, key management server, KMF, or any other term used in the art. Network unit 104 is typically part of a radio access network that includes one or more controllers communicatively coupled to one or more corresponding network units 104. The radio access network is typically communicatively coupled to one or more core networks, which may be coupled to other networks such as the Internet and the public switched telephone network, etc. These and other elements of the radio access and core networks are not illustrated but are generally well known to those skilled in the art.
[0033] In one implementation, the wireless communication system 100 conforms to the NR protocol standardized in 3GPP, wherein network unit 104 transmits on the DL using an OFDM modulation scheme, and remote unit 102 transmits on the UL using an SC-FDMA scheme or an OFDM scheme. However, more generally, the wireless communication system 100 can implement other open or proprietary communication protocols, such as WiMAX, IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA2000, etc. ZigBee, Sigfoxx, and other protocols. This disclosure is not intended to limit implementation to any particular wireless communication system architecture or protocol.
[0034] Network unit 104 can serve multiple remote units 102 within a service area, such as a cell or cell sector, via a wireless communication link. Network unit 104 transmits DL communication signals to serve remote units 102 in the time, frequency, and / or spatial domains.
[0035] In various embodiments, remote unit 102 can determine whether a symbol appears within a discontinuous reception duration period. In some embodiments, remote unit 102 can determine whether to transmit a report in response to determining that a symbol appears within a discontinuous reception duration period. In some embodiments, the method includes transmitting a report regardless of whether a discontinuous reception duration timer is running. Therefore, remote unit 102 can be used to report transmissions for discontinuous reception.
[0036] Figure 2An embodiment of a device 200 that can be used to report transmissions received discontinuously is depicted. Device 200 includes one embodiment of a remote unit 102. Furthermore, the remote unit 102 may include a processor 202, a memory 204, an input device 206, a display 208, a transmitter 210, and a receiver 212. In some embodiments, the input device 206 and the display 208 are combined into a single device, such as a touchscreen. In some embodiments, the remote unit 102 may not include any input device 206 and / or the display 208. In various embodiments, the remote unit 102 may include one or more of the processor 202, memory 204, transmitter 210, and receiver 212, and may not include the input device 206 and / or the display 208.
[0037] In one embodiment, processor 202 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 202 may be a microcontroller, microprocessor, central processing unit (“CPU”), graphics processing unit (“GPU”), auxiliary processing unit, field-programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, processor 202 executes instructions stored in memory 204 to perform the methods and routines described herein. Processor 202 is communicatively coupled to memory 204, input device 206, display 208, transmitter 210, and receiver 212.
[0038] In one embodiment, memory 204 is a computer-readable storage medium. In some embodiments, memory 204 includes volatile computer storage media. For example, memory 204 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 204 includes non-volatile computer storage media. For example, memory 204 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 204 includes both volatile and non-volatile computer storage media. In some embodiments, memory 204 also stores program code and associated data, such as an operating system or other controller algorithms operating on remote unit 102.
[0039] In one embodiment, input device 206 may include any known computer input device, including a touchpad, button, keyboard, stylus, microphone, etc. In some embodiments, input device 206 may be integrated with display 208, for example, as a touchscreen or similar touch-sensitive display. In some embodiments, input device 206 includes a touchscreen, allowing text to be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, input device 206 includes two or more different devices such as a keyboard and a touch panel.
[0040] In one embodiment, display 208 may include any known electronically controllable display or display device. Display 208 may be designed to output visual, auditory, and / or tactile signals. In some embodiments, display 208 includes an electronic display capable of outputting visual data to a user. For example, display 208 may include, but is not limited to, LCD displays, LED displays, OLED displays, projectors, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, display 208 may include wearable displays such as smartwatches, smart glasses, head-up displays, etc. Furthermore, display 208 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.
[0041] In some embodiments, display 208 includes one or more speakers for generating sound. For example, display 208 may generate an audible alarm or notification (e.g., a buzzer or ring). In some embodiments, display 208 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of display 208 may be integrated with input device 206. For example, input device 206 and display 208 may form a touchscreen or similar touch-sensitive display. In other embodiments, display 208 may be positioned near input device 206.
[0042] In some embodiments, processor 202 may: determine whether a symbol appears within a discontinuous reception duration period; and, in response to determining that a symbol appears within the discontinuous reception duration period, determine whether to transmit a report. In some embodiments, transmitter 210 may transmit a report regardless of whether a discontinuous reception duration timer is running.
[0043] Although only one transmitter 210 and one receiver 212 are illustrated, the remote unit 102 can have any suitable number of transmitters 210 and receivers 212. The transmitters 210 and receivers 212 can be of any suitable type. In one embodiment, the transmitters 210 and receivers 212 can be part of a transceiver.
[0044] Figure 3 An embodiment of a device 300 that can be used to report transmissions received discontinuously is depicted. Device 300 includes one embodiment of a network unit 104. Furthermore, network unit 104 may include a processor 302, a memory 304, an input device 306, a display 308, a transmitter 310, and a receiver 312. As will be understood, processor 302, memory 304, input device 306, display 308, transmitter 310, and receiver 312 may be substantially similar to processor 202, memory 204, input device 206, display 208, transmitter 210, and receiver 212 of remote unit 102, respectively.
[0045] In some embodiments, transmitter 310 may be used to transmit the information described herein and / or receiver 312 may be used to receive the information described herein.
[0046] In various embodiments, power-saving techniques may be present to enhance UE battery life. As can be understood, UE battery life can be an important aspect of user experience and can affect the adoption of 5G handsets and / or services. In some embodiments, DRX operation and / or BWP adaptation can provide UE power savings during NR operation.
[0047] In some embodiments, the power-saving technique used may be WUS, which adapts the UE's DRX activity time based on some wake-up signal and / or channel. In such an embodiment, the UE monitors for new signals and / or channels (e.g., PDCCH-WUS) at pre-configured times (e.g., WUS times), which indicate whether the UE should wake up to monitor the PDCCH during the next occurrence of a timer (e.g., DRX-onDurationTimer). If the new signal and / or channel (e.g., PDCCH-WUS) indicates to the UE to wake up to monitor the PDCCH during the next occurrence of a timer (e.g., DRX-onDurationTimer), the UE starts the timer at the next occurrence of its DRX-onDurationTimer duration; otherwise, the UE does not start the timer at its next occurrence.
[0048] In one embodiment, during the WUS timing in the DRX inactivity period, the UE can enter a first phase for monitoring wake-up PDCCH (e.g., PDCCH-WUS). In this phase, the UE's power-saving capabilities may be severely limited. For example, the UE may not expect to receive the same time-slot scheduling permission for PDSCH or be ready to transmit PUCCH in response to PDSCH reception. Furthermore, once the UE decodes the wake-up PDCCH during the WUS timing, there may be a time offset for the next onDuration. Therefore, in the first phase, a lower power implementation can be achieved by optimizing at least: (i) the PDCCH processing timeline; (ii) the amount of hardware required to be online; (iii) the hardware voltage and / or clock operating point; and / or (iv) the RX bandwidth and the number of antennas. If PDCCH-WUS is decoded to indicate wake-up to the UE in the next onDuration, the UE can transition to the second phase by waking up additional hardware and processing to prepare for DL and / or UL data scheduling.
[0049] In various embodiments: 1) PDCCH-WUS triggers a MAC entity to “wake up” from monitoring the PDCCH for the next occurrence of the drx-onDurationTimer duration upon receiving a PDCCH-based power-saving signal and / or channel; 2) PDCCH-WUS is considered in conjunction with DRX (e.g., it is configured only if DRX is configured); 3) PDCCH-WUS is monitored at an offset configured before the start of the drx-onDurationTimer—the offset is part of the physical layer design; 4) at the PDCCH-WUS timing that the UE is monitoring, if the UE is instructed to monitor the drx-onDurationTimer... 5) The UE does not monitor the WUS during the next occurrence of the duration; 6) If the UE is in the DRX active time during the PDCCH-WUS time period, the drx-onDurationTimer is started at its next Onduration time; 7) The WUS is configured on a PCell with CA and an SpCell with DC (e.g., PCell on MCG and PSCell on SCG); and / or 8) RLM and RRM measurements are not affected by the WUS design (i.e., the UE continues to measure the required reference signal according to RRM requirements).
[0050] In some embodiments, DRX may have enhancements to handle different sets of parameters in order to provide reasonable battery consumption for user devices.
[0051] In various embodiments, the MAC entity may be configured with DRX functionality by the RRC. This DRX functionality controls the UE's PDCCH surveillance activity via the MAC entity's C-RNTI, CS-RNTI, INT-RNTI, SFI-RNTI, SP-CSI-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, and / or TPC-SRS-RNTI. In some embodiments, a common DRX scheme may be used, where a common activity time exists applicable to all aggregated serving cells.
[0052] In some embodiments, RRC controls DRX operation by configuring the following parameters: 1) drx-onDurationTimer: the duration after which the DRX cycle begins; 2) drx-SlotOffset: the delay before starting drx-onDurationTimer; 3) drx-InactivityTimer: the duration after the PDCCH timing indicating a new UL or DL transmission for the MAC entity; 4) drx-RetransmissionTimerDL (for each DLHARQ process except for broadcast processes): the maximum duration until a DL retransmission is received; 5) drx-RetransmissionTimerUL (for each UL... 6) drx-LongCycleStartOffset: Long DRX cycle and drx-StartOffset, which define the subframes at which the long and short DRX cycles begin; 7) drx-ShortCycle (optional): Short DRX cycle; 8) drx-ShortCycleTimer (optional): The duration for which the UE should follow the short DRX cycle; 9) drx-HARQ-RTT-TimerDL (for each DL HARQ cycle except the broadcast cycle): Minimum duration before the DL assignment expected by the MAC entity for HARQ retransmission; and / or 10) drx-HARQ-RTT-TimerUL (for each UL HARQ cycle): Minimum duration before the UL HARQ retransmission permission expected by the MAC entity.
[0053] In various embodiments, if a DRX period is configured, the active time may include the time when: 1) the drx-onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, or ra-ContentionResolutionTimer is running; 2) a scheduling request is sent on the PUCCH and is pending; or 3) a PDCCH indicating a new transmission addressing to the MAC entity for a C-RNTI that has not yet been received after a successful reception of a random access response for a random access preamble not selected by the MAC entity in a contention-based random access preamble.
[0054] In some embodiments, DRX operation gives the UE an opportunity to activate radio circuits to conserve power. In such embodiments, whether the UE actually remains inactive during the DRX period can be determined by the UE. For example, the UE may perform inter-frequency measurements that cannot be performed during the active duration, and therefore may perform them at some other time.
[0055] In some embodiments, the parameterization of the DRX period can involve a trade-off between battery saving and latency. In various embodiments, a longer DRX period can benefit the UE's battery life. In some embodiments, it can be beneficial to monitor downlink control signaling in each time slot (or more frequently) to receive uplink and downlink grants and / or respond to changes in service characteristics.
[0056] In various embodiments, if DRX is configured, periodic SRS, semi-persistent SRS, CSI on PUCCH, and semi-persistent CSI on PUSCH can be transmitted by the UE only during the active period. In such embodiments, RRC can further restrict CSI on PUCCH so that they are transmitted only during the on-duration period (e.g., referred to as CSI masking).
[0057] In some embodiments, DRX-related timers (e.g., drx-InactivityTimer, drx-RetransmissionTimerDL, and drx-ShortCycleTimer) can be started and stopped by events such as receiving PDCCH grants or MAC control elements (e.g., DRX command MAC CE, long DRX command MAC CE)). In such embodiments, the UE's DRX state (e.g., active or inactive time) can change from one time slot and / or symbol to another, and therefore may not always be predictable by the UE or gNB. In some embodiments, because the UE may need some time to process received downlink control signaling or information about changing the DRX state, and may need some time to prepare CSI and / or SRS reports (e.g., this processing time may depend on the UE implementation), some relaxations to CSI and / or SRS reporting during DRX can be used, such as in NR.
[0058] In some embodiments, assuming the UE is currently in active time and the drx-InactivityTimer is running, if the UE receives a PDCCH indicating a new transmission (e.g., UL or DL) in the last time slot and / or symbol (e.g., time slot N) before the DRX inactivity timer expires, the UE may also be in active time in the next time slot and / or symbol (e.g., time slot N+1). Due to processing time within the UE, the UE may only know that time slot N+1 is still active at the end of time slot N or the beginning of time slot N+1. In this embodiment, assuming periodic CSI reports are configured to be transmitted in time slot N+1, the UE may not have time to prepare CSI reports for transmission because it may be assumed to be entering DRX (e.g., inactive time during time slot N+1). As can be understood, the UE may not be able to transmit periodic CSI reports in time slot N+1.
[0059] In various embodiments, to relax UE requirements for CSI and / or SRS reporting during DRX and introduce some predictable UE behavior that avoids the need for gNB dual decoding (e.g., decoding assuming CSI and / or SRS and no CSI and / or SRS transmission), the following can be performed: 1) In the current symbol n, if all DRX activity time conditions as specified in this clause are evaluated, taking into account grant, assignment, DRX command MAC CE, received long DRX command MAC CE, and scheduling requests sent up to 4ms before symbol n, if the MAC entity is not active: a) does not transmit periodic SRS and semi-persistent SRS; and b) does not report CSI on PUCCH and does not report semi-persistent CSI on PUSCH; and 2) If the CSI mask (e.g., csi-Mask) is set by the upper layer: a) In the current symbol n, if all DRX activity time conditions as specified in this clause are evaluated, taking into account grant, assignment, DRX command MAC CE, and scheduling requests sent up to 4ms before symbol n, if the MAC entity is not active: CE and long DRX commands received up to 4ms before symbol n, if drx-onDurationTimer does not run: CSI is not reported on PUCCH.
[0060] In various embodiments, the UE determines whether to report CSI and / or SRS in the current symbol n by considering downlink signaling (e.g., grant, assignment, DRX command MAC CE, long DRX command MAC CE) and / or the effects of SR transmissions transmitted up to 4 ms prior to the received DRX state. If all DRX activity time conditions are evaluated, and based on the downlink signaling corresponding to the transmitted SRs received up to 4 ms prior to symbol n, if symbol n will not be active, the UE does not transmit periodic SRS and / or CSI on the PUCCH and / or does not transmit semi-persistent CSI on the PUSCH.
[0061] In some embodiments, the initiation of the drx-onDurationTimer with the introduction of the WUS signal may not be a deterministic event. In various embodiments, the drx-onDurationTimer can be initiated based on the configured DRX cycle. In some embodiments, the initiation of the drx-onDurationTimer depends on whether the WUS signaling at the PDCCH-WUS timing instructs the UE to wake up during the next occurrence of the drx-onDuration to monitor the PDCCH (e.g., instructing the UE to initiate the drx-onDurationTimer at its next timing). In various embodiments, because the offset between the WUS timing and the next occurrence of the OnDuration (e.g., also referred to as WUS-Offset) can be less than 4 ms, but the conditions used to determine whether to report CSI and / or SRS in symbol n depend on control signaling received up to 4 ms before symbol n, it may be unclear how and whether the WUS-related signaling (e.g., PDCCH-WUS) affects CSI and / or SRS reporting during DRX.
[0062] As used herein, the terms eNB and / or gNB can be used to refer to a base station, but can be replaced by any other radio access node (e.g., BS, eNB, gNB, AP, NR, etc.). Furthermore, while the methods described herein may primarily apply to 5G NR scenarios, the various methods described herein are equally applicable to other mobile communication systems that support power-saving mechanisms. It should be further noted that, as used herein, the term "onDuration" can refer to the time period at the start of a DRX cycle, during which the drx-onDurationTimer is running, such as... Figure 4 One embodiment is shown.
[0063] Specifically, Figure 4This is a timing diagram illustrating one embodiment of a DRX cycle 400. The DRX cycle 400 includes a first WUS timing 402 and a first onDuration 404 at time 406. A first WUS offset 408 is the time between the first WUS timing 402 and the first onDuration 404. The first onDuration 404 has a duration 410. As understood, all onDurations in the DRX cycle 400 may have the same duration 410. Furthermore, the DRX cycle 400 also includes a second WUS timing 412 and a second onDuration 414 at time 406. A second WUS offset 416 is the time between the second WUS timing 412 and the second onDuration 414. Additionally, the DRX cycle 400 also includes a third WUS timing 418 and a third onDuration 420 at time 406. A third WUS offset 422 is the time between the third WUS timing 418 and the third onDuration 420.
[0064] In a first embodiment, the UE may disregard WUS (e.g., PDCCH-WUS, or wake-up PDCCH) used to determine whether to report CSI and / or SRS. In such an embodiment, the UE does not consider WUS-related signaling to determine whether symbol n will be in DRX active and / or inactive time and whether to transmit periodic SRS, transmit semi-persistent SRS, report CSI on PUCCH, and / or report semi-persistent CSI on PUSCH. In one implementation of the first embodiment, for the purpose of CSI and / or SRS reporting, the UE may assume that a timer (e.g., drx-onDurationTimer) is started according to the configured DRX period. In such an implementation, even if the timer (e.g., drx-onDurationTimer) is not running and the UE is not in active time (e.g., the WUS signal does not instruct the UE to start timer-drx-onDurationTimer), the UE may transmit periodic SRS, transmit semi-persistent SRS, transmit CSI on PUCCH, and / or transmit semi-persistent CSI on PUSCH. A first example of an implementation of the first embodiment is found herein. In the first example, WUS-PDCCH represents a WUS signal (e.g., a power-saving signal and / or channel based on PDCCH) that indicates whether the UE wants to start a timer (e.g., drx-onDurationTimer) at the start of the next DRX cycle (e.g., the next onDuration). A first example of an implementation of the first embodiment is as follows: 1) In the current symbol n, if all DRX activity time conditions as specified in this clause are evaluated, taking into account license, assignment, DRX command MAC CE, received long DRX command MAC CE (e.g., excluding PDCCH-WUS), and / or scheduling requests sent up to 4ms before symbol n, if the MAC entity is not active: a) does not transmit periodic SRS and semi-persistent SRS; 2) does not report CSI on PUCCH and does not report semi-persistent CSI on PUSCH; and 2) if the CSI mask (e.g., csi-Mask) is set by the upper layer: In the current symbol n, if all DRX activity time conditions as specified in this clause are evaluated, taking into account license, assignment, DRX command MAC CE, and / or long DRX command MAC CE received up to 4ms before symbol n (excluding PDCCH-WUS), if drx-onDurationTimer will not run: does not report CSI on PUCCH.
[0065] In another implementation of the first embodiment, the UE does not consider WUS-related signaling to determine whether symbol n will be in DRX active and / or inactive time, and whether it transmits periodic SRS, transmits semi-persistent SRS, reports CSI on PUCCH, and / or reports semi-persistent CSI on PUSCH for the first X ms of each onDuration. In such an embodiment, during the first X ms, the UE reports CSI and / or SRS regardless of the UE's DRX state (i.e., regardless of whether the drx-onDurationTimer is actually running—e.g., if PDCCH-WUS has indicated to the UE to start and / or not start the drx-onDurationTimer). In this embodiment, the UE may only consider WUS-related signaling (e.g., PDCCH-WUS) after the first X ms of onDuration. According to some implementations of the first embodiment, if the WUS-Offset (e.g., the WUS timing for monitoring PDCCH-WUS is configured with WUS-Offset before the start of onDuration) is less than 4 ms, then X may be equal to 4 ms minus the configured WUS-Offset. If WUS-Offset is greater than or equal to 4ms, then X equals 0.
[0066] In a second embodiment, the UE considers a "wake-up" signal (e.g., PDCCH-WUS) used to determine whether to report CSI and / or SRS. In such an embodiment, the UE considers WUS-related signaling to determine whether symbol n will be in DRX active and / or inactive time and whether to transmit periodic SRS, transmit semi-persistent SRS, report CSI on PUCCH, and / or report semi-persistent CSI on PUSCH. In such an embodiment, if WUS-Offset is less than 4ms, the UE may not transmit periodic SRS, not transmit semi-persistent SRS, not report CSI on PUCCH, and / or not report semi-persistent CSI on PUSCH during onDuration (e.g., start), even if drx-onDurationTimer is running and the UE is in active time (e.g., the WUS signal has instructed the UE to start drx-onDurationTimer). This may be because if the WUS timing is configured to be less than 4ms before the start of the next DRX cycle, the UE cannot consider the PDCCH-WUS signaling used to determine whether to send CSI and / or SRS before the OnDuration cycle (e.g., 4–WUS-Offset) ms before it arrives (e.g., the UE will act as if it did not receive the PDCCH-WUS instructing the UE to start drx-onDurationTimer).
[0067] This document illustrates a second example of the second embodiment. In the example of the second embodiment, WUS-PDCCH represents a WUS signal (e.g., a power-saving signal and / or channel based on PDCCH) that indicates whether the UE should initiate the drx-onDurationTimer at the start of the next DRX cycle (e.g., the next onDuration). A second example of the second embodiment is as follows: 1) In the current symbol n, if all DRX activity time conditions as specified in this clause are evaluated, taking into account the grant, assignment, DRX command MAC CE, long DRX command MAC CE, received PDCCH-WUS, and / or scheduling requests sent up to 4ms before symbol n, if the MAC entity will not be active: a) not transmit periodic SRS and semi-persistent SRS; and b) not report CSI on PUCCH and not report semi-persistent CSI on PUSCH; and 2) if a CSI mask (e.g., csi-Mask) is set by the upper layer: In the current symbol n, if all DRX activity time conditions as specified in this clause are evaluated, taking into account the grant, assignment, DRX command MAC CE, long DRX command MAC CE, and / or PDCCH-WUS received up to 4ms before symbol n, if drx-onDurationTimer does not run: not report CSI on PUCCH.
[0068] In the third embodiment, if the WUS timing is configured with an offset less than X ms before the start of onDuration, the UE can report CSI and / or SRS during the "onDuration period" at the start of the DRX cycle, even if the drx-onDurationTimer is not running (e.g., the UE is not active). If the WUS timing is configured with an offset equal to or greater than X ms before the start of onDuration, the UE considers the information used to determine whether to report CSI and / or SRSWUS-related signaling (e.g., WUS-PDCCH). In one specific implementation of the third embodiment, X equals 4 ms. According to another implementation of the third embodiment, if the offset in the current symbol n (e.g., the offset between WUS timing and OnDuration) is equal to or greater than 4 ms, and if all DRX activity timing conditions are evaluated, taking into account WUS signaling, grant, assignment, DRX command MAC CE, received long DRX command MAC CE (e.g., excluding WUS signaling), and / or scheduling requests sent up to 4 ms before symbol n, if the MAC entity will not be active, then the UE will not transmit periodic SRS, will not transmit semi-persistent SRS, will not report CSI on PUCCH, and / or will not report semi-persistent CSI on PUSCH. If the offset is less than 4 ms, in the current symbol n, and if all DRX activity timing conditions are evaluated, taking into account grant, assignment, DRX command MAC CE, received long DRX command MAC CE (e.g., excluding WUS signaling), and / or scheduling requests received up to 4 ms before symbol n, if the MAC entity will not be active, the UE will not transmit periodic SRS, will not transmit semi-persistent SRS, will not report CSI on PUCCH, and / or will not report semi-persistent CSI on PUSCH. By disregarding the WUS signaling used to determine whether the UE is active in symbol n, if the drx-onDurationTimer is not running (e.g., the WUS signaling indicates that the drx-onDurationTimer will not be started at the beginning of the next DRX cycle), the UE can report CSI and / or SRS.
[0069] This document illustrates a third example of the third embodiment. In this example of the third embodiment, WUS-PDCCH represents a WUS signal (e.g., a PDCCH-based power-saving signal and / or channel) indicating whether the UE should initiate a drx-onDurationTimer at the start of the next DRX cycle. The third example of the third embodiment is as follows: 1) If the WUS-offset is less than 4 ms, in the current symbol n, if all DRX activity time conditions as specified in this clause are evaluated, taking into account grant, assignment, DRX command MAC CE, receipt of a long DRX command MAC CE (e.g., excluding PDCCH-WUS), and / or scheduling requests sent up to 4 ms before symbol n, if the MAC entity is not active: a) does not transmit the defined periodic SRS and semi-persistent SRS; b) does not report CSI on PUCCH and does not report semi-persistent CSI on PUSCH; 2) otherwise, in the current symbol n, if all DRX activity time conditions as specified in this clause are evaluated, taking into account PDCCH-WUS, grant, assignment, DRX command MAC CE, receipt of a long DRX command MAC CE, and scheduling requests sent up to 4 ms before symbol n, the MAC entity is not active: a) does not transmit the defined periodic SRS and semi-persistent SRS; b) does not report CSI on PUCCH and does not report semi-persistent CSI on PUSCH; 2) otherwise, in the current symbol n, if all DRX activity time conditions as specified in this clause are evaluated, taking into account PDCCH-WUS, grant, assignment, DRX command MAC CE, receipt of a long DRX command MAC CE, and scheduling requests sent up to 4 ms before symbol n, the MAC entity is not active: If the CE and / or scheduling request sent up to 4ms before symbol n, and the MAC entity is not active, then: a) no periodic SRS and semi-persistent SRS are transmitted; b) no CSI is reported on the PUCCH and no semi-persistent CSI is reported on the PUSCH; 3) if a CSI mask is set by the upper layer (e.g., csi-mask) and if the WUS-offset in the current symbol n is less than 4ms, and if all DRX active time conditions as specified in this clause are evaluated, taking into account grant, assignment, DRX command MAC CE and / or long DRX command MAC CE received up to 4ms before symbol n (e.g., excluding PDCCH-WUS), if the drx-onDurationTimer does not run: a) no CSI is reported on the PUCCH; 4) otherwise, in the current symbol n, if all DRX active time conditions as specified in this clause are evaluated, taking into account PDCCH-WUS, grant, assignment, DRX command MAC CE and / or long DRX command MAC CE received up to 4ms before symbol n, CE, if drx-onDurationTimer will not run: CSI will not be reported on PUCCH.
[0070] In the fourth embodiment, the UE is configured to indicate whether, if the WUS-Offset is less than x ms, for example, 4 ms, reporting CSI and / or SRS (e.g., periodic SRS, semi-persistent SRS, and / or reporting CSI on PUCCH and semi-persistent CSI on PUSCH) reaches x ms before OnDuration, regardless of the UE's DRX state (e.g., regardless of whether the drx-onDurationTimer is actually running - PDCCH-WUS has indicated that the UE will start and / or not start the drx-onDurationTimer), or the configuration indicates that, if the WUS-Offset is less than x ms, not reporting CSI and / or SRS reaches X ms before OnDuration. The fourth embodiment can be combined with other WUS-related configurations (e.g., WUS-Offset). According to one implementation of the fourth embodiment, the UE can receive the configuration via RRC signaling.
[0071] According to one implementation of the fourth embodiment, if the WUS-Offset is less than 4 ms, the PDCCH-WUS (e.g., wake-up PDCCH) can indicate to the UE whether to transmit a periodic SRS, transmit a semi-persistent SRS, report a CSI on the PUCCH, and / or report a semi-persistent CSI on the PUSCH before the OnDuration reaches x ms. In such an embodiment, x can be equal to 4 ms WUS-Offset.
[0072] In a fifth embodiment, the UE may start or restart a timer (e.g., bwp-InactivityTimer) upon receiving a PDCCH-WUS instructing the UE to switch to the currently active BWP (e.g., wake-up PDCCH). The PDCCH-WUS may contain a BWP-ID field, which indicates to the UE which BWP is monitoring the PDCCH until the next onDuration, such that the UE has switched to a BWP suitable for the intended service by the time the onDuration begins. According to one implementation of the fifth embodiment, the UE may start and / or restart a timer upon receiving a PDCCH-WUS instructing the UE to switch to a different DLBWP (e.g., compared to the currently active (DL) BWP associated with the serving cell) until the next onDuration. According to another implementation of the fifth embodiment, if the timer is started, the UE starts and / or restarts a timer (e.g., bwp-InactivityTimer) associated with the active DL BWP when it has received a PDCCH-WUS instructing the UE to switch to a different DL BWP (e.g., compared to the currently active (DL) BWP associated with the serving cell) until the next onDuration.
[0073] In the sixth embodiment, if the UE monitors PDCCH-WUS during WUS, the UE stops the timer (e.g., bwp-InactivityTimer) associated with the active DL BWP of the serving cell. In such an embodiment, the UE can implicitly activate a "wake-up" specific BWP for monitoring the wake-up PDCCH during WUS. The UE can autonomously switch from the currently active DL BWP to the wake-up BWP for PDCCH-WUS monitoring. In some embodiments, the situation where the timer expires and the UE has to switch to the DefaultDownlinkBWP or initialDownlinkBWP can be avoided.
[0074] Figure 5 This is a flowchart illustrating one embodiment of a method 500 for reporting transmissions for discontinuous reception. In some embodiments, method 500 is performed by a device such as remote unit 102. In some embodiments, method 500 may be performed by a processor executing program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.
[0075] In various embodiments, method 500 includes determining whether a symbol 502 appears within a discontinuous reception duration period. In some embodiments, method 500 includes determining whether to transmit a report 504 in response to determining that a symbol appears within a discontinuous reception duration period. In some embodiments, method 500 includes transmitting a report 506 regardless of whether a discontinuous reception duration timer is running.
[0076] In some embodiments, method 500 further includes determining whether to initiate a discontinuous reception duration timer without considering wake-up signaling. In some embodiments, discontinuous reception over a duration includes the duration of the discontinuous reception duration timer. In various embodiments, the report is a channel state information report.
[0077] In one embodiment, the report is a periodic channel state information report. In some embodiments, the report is a semi-persistent channel state information report. In some embodiments, the report is a sounding reference signal report.
[0078] In various embodiments, the report is a periodic sounding reference signal report. In one embodiment, the report is a semi-persistent sounding reference signal report. In some embodiments, the report is transmitted on the physical uplink control channel.
[0079] In some embodiments, the report is transmitted on the physical uplink shared channel. In various embodiments, the report is transmitted during a predetermined period of discontinuous reception within a duration. In one embodiment, the predetermined period includes the number of milliseconds since the start of the discontinuous reception duration.
[0080] In one embodiment, a method includes: determining whether a symbol appears within a discontinuous reception duration period; determining whether to transmit a report in response to determining that a symbol appears within the discontinuous reception duration period; and transmitting a report regardless of whether a discontinuous reception duration timer is running.
[0081] In some embodiments, the method further includes determining whether to start a discontinuous reception duration timer without considering wake-up signaling.
[0082] In some embodiments, the discontinuous reception duration period includes the duration of the discontinuous reception duration timer.
[0083] In various embodiments, the report is a channel state information report.
[0084] In one embodiment, the report is a periodic channel state information report.
[0085] In some embodiments, the report is a semi-persistent channel state information report.
[0086] In some embodiments, the report is a probe reference signal report.
[0087] In various embodiments, the report is a periodic probe reference signal report.
[0088] In one embodiment, the report is a semi-persistent probe reference signal report.
[0089] In some embodiments, the report is transmitted on the physical uplink control channel.
[0090] In some embodiments, the report is transmitted on the physical uplink shared channel.
[0091] In various embodiments, the report is transmitted during a predetermined time period of a discontinuous reception duration.
[0092] In one embodiment, the predetermined time period includes the number of milliseconds at the beginning of a discontinuous reception duration period.
[0093] In one embodiment, an apparatus includes: a processor that: determines whether a symbol appears within a discontinuous reception duration period; and, in response to determining that the symbol appears within the discontinuous reception duration period, determines whether to transmit a report; and a transmitter that transmits a report regardless of whether a discontinuous reception duration timer is running.
[0094] In some embodiments, the processor does not consider wake-up signaling to determine whether to start a discontinuous receive duration timer.
[0095] In some embodiments, the discontinuous reception duration period includes the duration of the discontinuous reception duration timer.
[0096] In various embodiments, the report is a channel state information report.
[0097] In one embodiment, the report is a periodic channel state information report.
[0098] In some embodiments, the report is a semi-persistent channel state information report.
[0099] In some embodiments, the report is a probe reference signal report.
[0100] In various embodiments, the report is a periodic probe reference signal report.
[0101] In one embodiment, the report is a semi-persistent probe reference signal report.
[0102] In some embodiments, the report is transmitted on the physical uplink control channel.
[0103] In some embodiments, the report is transmitted on the physical uplink shared channel.
[0104] In various embodiments, the report is transmitted during a predetermined time period of a discontinuous reception duration.
[0105] In one embodiment, the predetermined time period includes the number of milliseconds at the beginning of a discontinuous reception duration period.
[0106] The embodiments may be practiced in other specific forms. The described embodiments are to be regarded in all respects as illustrative rather than restrictive. Therefore, the scope of the invention is indicated by the appended claims rather than the foregoing description. All variations within the meaning and equivalents of the claims are covered within their scope.
Claims
1. A method performed by a user equipment (UE), the method comprising: Determine whether the symbol appears during the duration of discontinuous DRX reception; In response to determining that the symbol appears during the DRX duration, determine whether to issue a report; Receive a wake-up signaling (WUS) indicating whether to start the DRX duration timer, wherein the WUS is received at an offset time period before the DRX duration; In response to the WUS not instructing the start of the DRX duration timer, the DRX duration timer is not started; as well as The report is emitted in the symbol even if the DRX duration timer is not running.
2. The method according to claim 1, wherein, The DRX duration is associated with the DRX duration timer.
3. The method according to claim 1, wherein, The report in question is a Channel State Information (CSI) report.
4. The method according to claim 3, wherein, The CSI report is either a periodic CSI report or a semi-persistent SPSCSI report.
5. The method according to claim 1, wherein, The report is a Sound Reference Signal (SRS) report.
6. The method according to claim 5, wherein, The SRS report is either a periodic SRS report or a semi-persistent SRS report.
7. The method according to claim 1, wherein, The report is transmitted on the Physical Uplink Control Channel (PUCCH) or the Physical Uplink Shared Channel (PUSCH).
8. A user equipment (UE), comprising: Processor, the processor being configured to cause the UE to: Determine whether the symbol appears during the duration of discontinuous DRX reception; In response to determining that the symbol appears during the DRX duration, determine whether to issue a report; In response to receiving a wake-up signal WUS that does not indicate the start of the DRX duration timer, the DRX duration timer is not started, wherein the WUS is received at an offset time period before the DRX duration. as well as Transmitter, the transmitter being configured to cause the UE to: The report is emitted in the symbol even if the DRX duration timer is not running.
9. The UE according to claim 8, wherein, The DRX duration is associated with the DRX duration timer.
10. The UE according to claim 8, wherein, The report in question is a Channel State Information (CSI) report.
11. The UE according to claim 10, wherein, The CSI report is either a periodic CSI report or a semi-persistent SPSCSI report.
12. The UE according to claim 8, wherein, The report is a Sound Reference Signal (SRS) report.
13. The UE according to claim 12, wherein, The SRS report is either a periodic SRS report or a semi-persistent SRS report.
14. The UE according to claim 8, wherein, The transmitter is configured to cause the UE to transmit the report on the Physical Uplink Control Channel (PUCCH) or the Physical Uplink Shared Channel (PUSCH).
Citation Information
Patent Citations
Deterministic UE behaviour for CSI / SRS reporting during DRX
CN105165085A
Method and device for performing handover in mobile communication system
EP2887741A1
Discontinuous Reception And CSI
US20190215897A1