Waveform indication using DCI

Abstract

Apparatuses, methods, and systems are disclosed for waveform indication using downlink control information ("DCI"). An apparatus (700) in a mobile communication network includes a processor (705) and a transceiver (725) that monitors (905) DCI outside of a discontinuous reception ("DRX") DRX active time, where the DCI contains a waveform indicator. The processor (705) determines (910) a waveform type for a next occurring DRX active time, and the transceiver (725) receives (915) a downlink transmission on a physical downlink channel during the next occurring DRX active time using the determined waveform.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 045,011, filed June 26, 2020, entitled “WAVEFORM INDICATIONUSING DCI BASED WUS SIGNALING”, by Karthikeyan Ganesan, Ankit Bhamri, Ali Ramadan Ali, VijayNangia, and Alexander Golitschek, which is incorporated herein by reference. Technical Field

[0003] The subject matter disclosed herein generally relates to wireless communication, and more specifically to apparatus, methods, and systems for waveform indication using wake-up signal (“WUS”) signaling based on downlink control information (“DCI”). Background Technology

[0004] In some wireless communication systems, radio access networks can support NR-based operation at frequencies between 52.6 GHz and 71 GHz. Due to anticipated performance degradation at higher frequencies, additional design requirements for 3GPP New Radio (“NR”) operation above 52.6 GHz have been considered. In addition to high path loss, the radio frequency (“RF”) components of the transmitter and receiver exhibit nonlinear transmission characteristics, leading to further system degradation. Summary of the Invention

[0005] A process for waveform indication using DCI is disclosed. This process can be implemented by an apparatus, system, method, or computer program product.

[0006] A method for a user equipment (“UE”) includes monitoring downlink control information (“DCI”) outside of a discontinuous reception (“DRX”) DRX activity period, wherein the DCI contains a waveform indicator. The method includes determining a waveform type for the next DRX activity period and receiving downlink transmissions on a physical downlink channel during the next DRX activity period using the determined waveform.

[0007] A method for a radio access network (“RAN”) node includes determining a waveform type for a next DRX activity period for a UE and transmitting a DCI outside of any DRX activity period for the UE, wherein the DCI contains a waveform indicator. The method includes transmitting downlink transmissions on a physical downlink channel during the next DRX activity period using the determined waveform. Attached Figure Description

[0008] A more specific description of the embodiments briefly described above will be presented with reference to specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings depict only a few embodiments and should therefore not be considered as limiting the scope; the embodiments will be described and explained with additional specificity and detail using the drawings, in which:

[0009] Figure 1 This is a schematic block diagram illustrating one embodiment of a wireless communication system using waveform indication with DCI.

[0010] Figure 2 This is a block diagram illustrating one embodiment of the 5G New Radio (“NR”) protocol stack;

[0011] Figure 3 A diagram illustrating one embodiment of a DCP monitoring scenario for DRX adaptation;

[0012] Figure 4 A diagram depicting one embodiment of PDCCH-WUS;

[0013] Figure 5 A diagram depicting an embodiment of DCI format 2_6;

[0014] Figure 6 A diagram depicting one embodiment of the illustrated waveform indication process;

[0015] Figure 7 This is a diagram illustrating one embodiment of a user equipment device that can be used for waveform indication using DCI;

[0016] Figure 8 This diagram illustrates one embodiment of a network device that can be used with DCI waveform indication;

[0017] Figure 9 This is a flowchart illustrating an embodiment of a first method for waveform indication using DCI; and

[0018] Figure 10 This is a flowchart illustrating an embodiment of a second method for waveform indication using DCI. Detailed Implementation

[0019] 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 aspects of both software and hardware.

[0020] For example, the disclosed embodiments can be implemented as hardware circuitry that includes custom-designed very large-scale integration (“VLSI”) circuitry or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments can also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may, for example, be organized as objects, procedures, or functions.

[0021] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage device may be tangible, non-transitory, and / or non-transferable. The storage device may not embody signals. In one embodiment, the storage device employs only signals for accessing the code.

[0022] Any combination of one or more computer-readable media may be used. A computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be a storage device for storing code. A storage device may 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.

[0023] More specific examples of storage devices (a non-exhaustive list) will include the following: electrical connections having one or more wires, portable computer floppy disks, hard disks, random access memory (“RAM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM” or flash memory), portable compact 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 a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0024] 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, and C++, and traditional 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, as a standalone software package, partially on the user's computer and 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"), a wireless LAN ("WLAN"), or a wide area network ("WAN"), or can be connected to an external computer (e.g., via the Internet through an Internet service provider ("ISP").

[0025] Furthermore, the features, structures, or characteristics described in the embodiments can be combined in any suitable manner. Numerous specific details, such as examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., are provided in the following description to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments can be practiced without one or more of these specific details or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of the embodiments.

[0026] Throughout this specification, references to "an embodiment," "embodiment," or similar language 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, the phrases "in an embodiment," "in an embodiment," and similar language throughout this specification may, but do not necessarily, 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 imply that any or all items are mutually exclusive. Unless expressly stated otherwise, the terms "a," "an," and "the" also mean "one or more".

[0027] As used herein, a list containing the conjunction “and / or” includes any single item in the list or a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one or more of…” includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one of…” includes one and only one of any single item in the list. For example, “one of A, B, and C” includes only A, only B, or only C and excludes combinations of A, B, and C. As used herein, “selected from the group consisting of A, B, and C” includes one and only one of A, B, or C and excludes combinations of A, B, and C. As used in this article, “selecting members of a group consisting of A, B, and C and their combinations” includes only A, only B, only C, combinations of A and B, combinations of B and C, combinations of A and C, or combinations of A, B, and C.

[0028] The following description of various 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 individual blocks in the schematic flowcharts and / or schematic block diagrams, as well as combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that instructions executable via the processor of the computer or other programmable data processing apparatus create means for implementing the functions / actions specified in the flowcharts and / or block diagrams.

[0029] The code can also be stored in a storage device that can instruct a computer, other programmable data processing device or other device to operate in a particular manner, such that the instructions stored in the storage device produce an article of art including instructions that implement the functions / actions specified in the flowchart and / or block diagram.

[0030] The code may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device, thereby producing a computer-implemented process, such that the code executing on the computer or other programmable apparatus provides a process for implementing the functions / actions specified in the flowchart and / or block diagram.

[0031] The flowcharts and / or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and program products according to various embodiments. In this regard, each block in the flowcharts and / or block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function.

[0032] It should also be noted that in some alternative implementations, the functions marked in the boxes may not appear in the order shown in the figures. For example, two boxes shown consecutively may actually be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order, depending on the functionality involved. Other steps and methods that are equivalent in function, logic, or effect to one or more boxes or portions thereof shown in the figures can be contemplated.

[0033] While various arrow and line types may be used in flowcharts and / or block diagrams, they are not intended to limit the scope of the corresponding embodiments. In practice, some arrows or other connectors may be used only to indicate the logical flow of the depicted embodiment. For example, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of a depicted embodiment. It will also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented by a system based on dedicated hardware or a combination of dedicated hardware and code that performs the specified function or action.

[0034] The description of the elements in each figure can be referenced to the elements in the preceding figures. In all figures, the same reference numerals refer to the same elements, including alternative embodiments of the same elements.

[0035] Generally, this disclosure describes systems, methods, and apparatuses for waveform indication. In some embodiments, the methods may be performed using computer code embedded in a computer-readable medium. In some embodiments, the apparatus or system may include a computer-readable medium containing computer-readable code that, when executed by a processor, causes the apparatus or system to perform at least a portion of the solution described below. In various embodiments, a wake-up signal (“WUS”) carried on a downlink control channel (“PDCCH”) is used to indicate the waveform.

[0036] Due to anticipated performance degradation at high frequencies, additional design requirements for new radios (“NR”) exceeding 52.6 GHz have been considered for further investigation. In addition to high path loss, the radio frequency (“RF”) components of both the transmitter and receiver exhibit nonlinear transmission characteristics, leading to further system degradation.

[0037] In NR Release 15 (“Rel-15”), multi-carrier-based waveforms (e.g., Orthogonal Frequency Division Multiplexing (“OFDM”)) have been adopted for both downlink (“DL”) and uplink (“UL”). For some cases, particularly at cell edges, single-carrier (e.g., Discrete Fourier Transform (“DFT”) Extended OFDM (“DFT-s-OFDM”)) is also used as an option for uplink (“UL”). However, due to its sensitivity to phase noise and its limiting peak-to-average power ratio (“PAPR”) or cubic metric (“CM”) for cell coverage, the performance of Cyclic Prefix OFDM (“CP-OFDM”) degrades at high frequencies (e.g., 52.6 GHz and above). The problems with CP-OFDM at high frequencies become more severe with increasing modulation order and / or channel bandwidth. Therefore, some physical layer channels will be more affected than others.

[0038] The aforementioned issues make single-carrier waveforms suitable candidates for high frequencies due to their inherent robustness to phase noise and their low PAPR or CM. In NR Rel-15 / 16, UL already supports single-carrier (DFT-s-OFDM and / or single-carrier frequency division multiple access (“SC-FDMA”)). However, power constraints of the UE, especially at cell edges, necessitate the use of other single-carrier waveforms to enhance UL, such as single-carrier quadrature amplitude modulation (“SC-QAM”) or single-carrier frequency domain equalization (“SC-FDE”) / cyclic prefix single-carrier (“CP-SC”) for cell edge scenarios.

[0039] One candidate waveform type for use at high frequencies (e.g., 52.6 GHz and above) is OFDM-based single-carrier waveforms, such as DFT-s-OFDM waveforms. Single-carrier waveforms can be used for downlink (“DL”) due to their lower PAPR compared to CP-OFDM and their better frequency flexibility compared to pure single-carrier candidates such as SC-QAM. On the other hand, while using DFT-s-OFDM or other single-carrier candidates for DL ​​enhances cell coverage, it limits the system’s multiple-input multiple-output (“MIMO”) capability and reduces the flexibility of demodulation reference signal (“DMRS”) mapping. Some FR4 intended use cases described in 3GPP TR38.807, such as enhanced mobile broadband with high data rates (“eMBB”), require high channel bandwidth for high throughput, where MIMO can also play an important role.

[0040] On the other hand, in factory automation / Industrial Internet of Things (“IIoT”) applications, latency, large-scale access, and reliability are the primary key performance indicators (“KPIs”). Other use cases, such as backhaul, integrated access, and backhaul (“IAB”), primarily operate under line-of-sight (“LOS”) conditions, where fading and power consumption are not major concerns. Mobile data offloading requires coexistence with other systems, such as 60GHz Wi-Fi (i.e., “WiGig”). For short-range, high-data-rate device-to-device (“D2D”) communication, coverage is limited, and PAPR issues are not the primary concern. Trade-offs in latency and throughput between cell coverage requirements and quality of service (“OoS”) requirements need to be considered to support diverse deployment and use case scenarios. Therefore, multi-waveform support for downlink (“DL”) and uplink (“UL”) is a practical solution to adapt to different deployment, coverage, and use case scenarios, thereby achieving high system flexibility and optimizing the performance of solutions for semi-static switching of DL waveforms for data transmission.

[0041] This disclosure addresses the issue of using DCI format monitored outside the UE's DRX activity time to indicate the DL waveform type that the UE will use for DL ​​physical channel reception from the non-sleep bandwidth portion ("BWP") of the primary cell ("PCell") and secondary cell ("SCell").

[0042] Figure 1 A wireless communication system 100 for waveform indication using DCI is depicted according to embodiments of the present disclosure. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a radio access network (“RAN”) 120, and a mobile core network 140. The RAN 120 and the mobile core network 140 form a mobile communication network. The RAN 120 may consist of a base unit 121, with the remote unit 105 communicating with the base unit 121 using a wireless communication link 123. Although in Figure 1 The document depicts a specific number of remote units 105, basic units 121, wireless communication links 123, RAN 120, and mobile core network 140, but those skilled in the art will recognize that any number of remote units 105, basic units 121, wireless communication links 123, RAN 120, and mobile core network 140 can be included in the wireless communication system 100.

[0043] In one implementation, RAN 120 conforms to the 5G system specifications outlined in the 3rd Generation Partnership Project (“3GPP”). For example, RAN 120 may be a next-generation radio access network (“NG-RAN”) implementing a new radio (“NR”) radio access technology (“RAT”) and / or a long-term evolution (“LTE”) RAT. In another example, RAN 120 may include non-3GPP RAT (e.g., Or an IEEE 802.11 series compliant WLAN. In another embodiment, RAN 120 conforms to the LTE system specified in the 3GPP specification. However, more generally, the wireless communication system 100 can implement some other open or proprietary communication networks, such as Global Microwave Access Interoperability (“WiMAX”) or the IEEE 802.16 series standards, as well as other networks. This disclosure is not intended to limit implementation to any particular wireless communication system architecture or protocol.

[0044] In one embodiment, remote unit 105 may include computing devices such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smartphones, smart TVs (e.g., internet-connected TVs), smart appliances (e.g., internet-connected appliances), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), etc. In some embodiments, remote unit 105 includes wearable devices such as smartwatches, fitness bands, optical head-mounted displays, etc. Furthermore, remote unit 105 may be referred to as UE, subscriber unit, mobile device, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, user terminal, wireless transmit / receive unit (“WTRU”), device, or other terms used in the art. In various embodiments, remote unit 105 includes a subscriber identity and / or identification module (“SIM”) and a mobile device (“ME”) that provides mobile terminal functions (e.g., radio transmission, conversion, voice encoding and decoding, error detection and correction, signaling and access to the SIM). In some embodiments, the remote unit 105 may include a terminal device (“TE”) and / or be embedded in an electrical appliance or device (e.g., a computing device as described above).

[0045] Remote unit 105 can communicate directly with one or more basic units 121 in RAN 120 via uplink (“UL”) and downlink (“DL”) communication signals. Additionally, UL and DL communication signals can be carried on wireless communication link 123. Here, RAN 120 is an intermediate network providing access to mobile core network 140 to remote unit 105. As described in more detail below, basic unit 121 can provide cells operating using a first carrier frequency and / or cells operating using a second carrier frequency. Cells using the first carrier frequency can form a first frequency layer, while cells using the second carrier frequency can form a second frequency layer.

[0046] In some embodiments, remote unit 105 communicates with application server 141 via a network connection to mobile core network 140. For example, application 107 in remote unit 105 (e.g., a web browser, media client, telephone, and / or Voice over Internet Protocol (“VoIP”) application) can trigger remote unit 105 to establish a Protocol Data Unit (“PDU”) session (or other data connection) with mobile core network 140 via RAN 120. Mobile core network 140 then uses the PDU session to relay services between remote unit 105 and application server 151 in packet data network 150. The PDU session represents a logical connection between remote unit 105 and user plane function (“UPF”) 141.

[0047] To establish a PDU session (or PDN connection), remote unit 105 must register with mobile core network 140 (also referred to as "attached to mobile core network" in the context of fourth-generation ("4G") systems). Note that remote unit 105 may establish one or more PDU sessions (or other data connections) with mobile core network 140. Therefore, remote unit 105 may have at least one PDU session for communicating with packet data network 150. Remote unit 105 may establish additional PDU sessions for communicating with other data networks and / or other communication peers.

[0048] In the context of a 5G system (“5GS”), the term “PDU session” refers to a data connection that provides end-to-end (“E2E”) user plane (“UP”) connectivity between remote unit 105 and a specific data network (“DN”) via UPF 141. A PDU session supports one or more Quality of Service (“QoS”) streams. In some embodiments, a one-to-one mapping may exist between QoS streams and QoS profiles, such that all packets belonging to a particular QoS stream have the same 5G QoS identifier (“5QI”).

[0049] In the context of 4G / LTE systems such as Evolved Packet System (“EPS”), a Packet Data Network (“PDN”) connection (also known as an EPS session) provides end-to-end (E2E) connectivity between the remote unit and the PDN. The PDN connectivity process establishes an EPS bearer, i.e., a tunnel between the remote unit 105 and the packet gateway (“PGW”, not shown) in the mobile core network 140. In some embodiments, a one-to-one mapping exists between the EPS bearer and the QoS profile, such that all packets belonging to a particular EPS bearer have the same QoS class identifier (“QCI”).

[0050] Basic unit 121 may be distributed across a geographical area. In some embodiments, basic unit 121 may also be referred to as an access terminal, access point, base station, base station, node B (“NB”), evolved node B (abbreviated as eNodeB or “eNB”, also known as evolved universal terrestrial radio access network (“E-UTRAN”) node B), 5G / NR node B (“gNB”), home node B, relay node, RAN node, or any other term used in the art. Basic unit 121 is typically part of a RAN such as RAN 120, which may include one or more controllers communicatively coupled to one or more corresponding basic units 121. These and other elements of the radio access network are not shown, but are generally well known to those skilled in the art. Basic unit 121 is connected to mobile core network 140 via RAN 120.

[0051] Basic unit 121 can serve multiple remote units 105 within a service area, such as a cell or cell sector, via wireless communication link 123. Basic unit 121 can communicate directly with one or more remote units 105 via communication signals. Typically, basic unit 121 transmits DL communication signals to serve remote units 105 in the time, frequency, and / or spatial domains. Furthermore, DL communication signals can be carried on wireless communication link 123. Wireless communication link 123 can be any suitable carrier in licensed or unlicensed radio spectrum. Wireless communication link 123 facilitates communication between one or more remote units 105 and / or one or more basic units 121. Note that during NR operation (referred to as "NR-U") on unlicensed spectrum, basic unit 121 and remote units 105 communicate via unlicensed (i.e., shared) radio spectrum.

[0052] In one embodiment, the mobile core network 140 is a 5GC or evolved packet core (“EPC”) that can be coupled to a packet data network 150, such as the Internet and private data networks, as well as other data networks. The remote unit 105 may have a subscription or other account with respect to the mobile core network 140. In various embodiments, each mobile core network 140 belongs to a single mobile network operator (“MNO”). This disclosure is not intended to limit implementation to any particular wireless communication system architecture or protocol.

[0053] Mobile core network 140 includes several network functions (“NFs”). As depicted, mobile core network 140 includes at least one UPF 141. Mobile core network 140 also includes multiple control plane (“CP”) functions, including but not limited to Access and Mobility Management Functions (“AMF”) 143, Session Management Functions (“SMF”) 145, Policy Control Functions (“PCF”) 147, Unified Data Management Functions (“UDM”), and User Data Repository (“UDR”) serving RAN 120. Figure 1 The document describes a specific number and type of network functions, but those skilled in the art will recognize that any number and type of network functions may be included in the mobile core network 140.

[0054] In the 5G architecture, UPF 141 is responsible for packet routing and forwarding, packet inspection, QoS processing, and external PDU sessions for interconnecting the data network (DN). AMF 143 is responsible for NAS signaling termination, NAS encryption and integrity protection, registration management, connection management, mobility management, access authentication and authorization, and security context management. SMF 145 is responsible for UPF 141's session management (i.e., session establishment, modification, and release), remote unit (i.e., UE) IP address allocation and management, DL data notification, and service orientation configuration for appropriate service routing.

[0055] PCF 147 is responsible for a unified policy framework, providing policy rules for CP functions and accessing subscription information for policy decisions in the UDR. UDM is responsible for generating authentication and key protocol (“AKA”) credentials, user identification processing, access authorization, and subscription management. The UDR is a repository of subscriber information and can be used to serve multiple network functions. For example, the UDR can store subscription data, policy-related data, subscriber-related data that can be exposed to third-party applications, and so on. In some embodiments, the UDM and UDR are co-located and depicted as a combined entity “UDM / UDR” 149.

[0056] In various embodiments, the mobile core network 140 may also include a network repository function (“NRF”) (which provides network function (NF) service registration and discovery, enabling NFs to identify appropriate services among themselves and communicate with each other via an application programming interface (“API”), a network exposure function (“NEF”) (which is responsible for making network data and resources easily accessible to customers and network partners), an authentication server function (“AUSF”), or other NFs defined for the 5GC. When present, the AUSF can be used as an authentication server and / or authentication proxy, thereby allowing AMF 143 to authenticate remote unit 105. In some embodiments, the mobile core network 140 may include an authentication, authorization, and accounting (“AAA”) server.

[0057] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, where each mobile data connection utilizes a specific network slice. Here, a "network slice" refers to a portion of the mobile core network 140 optimized for a specific service type or communication service. For example, one or more network slices may be optimized for enhanced mobile broadband ("eMBB") service. As another example, one or more network slices may be optimized for ultra-reliable low-latency communication ("URLLC") service. In other examples, network slices may be optimized for machine-type communication ("MTC") service, massive MTC ("mMTC") service, and Internet of Things ("IoT") service. In still other examples, network slices may be deployed for specific application services, vertical services, specific use cases, etc.

[0058] Network slice instances can be identified by individual network slice selection aid information (“S-NSSAI”), while the set of network slices authorized for use by remote unit 105 is identified by network slice selection aid information (“NSSAI”). Here, “NSSAI” refers to a vector value including one or more S-NSSAI values. In some embodiments, various network slices may include separate instances of network functions, such as SMF 145 and UPF 141. In some embodiments, different network slices may share some common network functions, such as AMF 143. For illustration purposes, Figure 1Different network slices are not shown, but support for them is assumed. In various embodiments, a first set of network slices may be optimized for a first carrier frequency, while a second set of network slices may be optimized for a second carrier frequency. As discussed in more detail below, RAN 120 sends downlink control information (“DCI”) containing a wake-up signal (“WUS”) 125 to remote unit 105 (i.e., sent via base unit 121) to bring remote unit 105 into an active state (i.e., DRX active time). Moreover, the WUS includes a waveform indicator that indicates the waveform type that remote unit 105 will use for communication during the active time.

[0059] Although Figure 1 The components of the 5G RAN and 5G core network are described, but the embodiments described for performing enhanced DM-RS configurations are applicable to other types of communication networks and RATs, including IEEE 802.11 variants, Global System for Mobile Communications (“GSM”, i.e., 2G digital cellular networks), General Packet Radio Service (“GPRS”), General Mobile Telecommunications System (“UMTS”), LTE variants, CDMA 2000, Bluetooth, ZigBee, Sigfox, and others.

[0060] Furthermore, in the LTE variant of the mobile core network 140 where EPC is used, the described network functions can be replaced with appropriate EPC entities, such as the Mobility Management Entity (“MME”), Serving Gateway (“SGW”), PGW, Home Subscriber Server (“HSS”), etc. For example, AMF 143 can be mapped to the MME, SMF 145 can be mapped to the control plane portion of the PGW and / or the MME, UPF 141 can be mapped to the SGW and the user plane portion of the PGW, UDM / UDR 149 can be mapped to the HSS, and so on.

[0061] In the following description, the term "RAN node" is used for base station, but it can be replaced by any other radio access node such as gNB, eNB, base station ("BS"), access point ("AP"), etc. Furthermore, the operation is primarily described in the context of 5G NR. However, the proposed solution / method is equally applicable to other mobile communication systems supporting enhanced DM-RS configurations.

[0062] Figure 2 An NR protocol stack 200 according to an embodiment of this disclosure is depicted. Although Figure 2The diagram shows UE 205, RAN node 210, and AMF 215 in the 5G core network (“5GC”), but these represent a collection of remote units 105 that interact with basic unit 121 and mobile core network 140. As depicted, protocol stack 200 includes user plane protocol stack 201 and control plane protocol stack 203. User plane protocol stack 201 includes physical (“PHY”) layer 220, medium access control (“MAC”) sublayer 225, radio link control (“RLC”) sublayer 230, packet data convergence protocol (“PDCP”) sublayer 235, and service data adaptation protocol (“SDAP”) layer 240. Control plane protocol stack 203 includes physical layer 220, MAC sublayer 225, RLC sublayer 230, and PDCP sublayer 235. Control plane protocol stack 203 also includes radio resource control (“RRC”) layer 245 and non-access stratum (“NAS”) layer 250.

[0063] The AS layer (also referred to as the "AS protocol stack") for the user plane protocol stack 201 consists of at least SDAP, PDCP, RLC, and MAC sublayers, as well as a physical layer. The AS layer for the control plane protocol stack 203 consists of at least RRC, PDCP, RLC, and MAC sublayers, as well as a physical layer. Layer 2 ("L2") is divided into SDAP, PDCP, RLC, and MAC sublayers. Layer 3 ("L3") includes the RRC sublayer 245 and NAS layer 250 for the control plane and includes, for example, the Internet Protocol ("IP") layer and / or PDU layer (not depicted) for the user plane. L1 and L2 are referred to as "lower layers," while L3 and above (e.g., transport layer, application layer) are referred to as "higher layers" or "upper layers."

[0064] Physical layer 220 provides a transport channel to MAC sublayer 225. As described herein, physical layer 220 may perform clear channel assessment and / or listen-before-tell (“CCA / LBT”) procedures using energy detection thresholds. In some embodiments, physical layer 220 may send a notification of UL listen-before-tell (“LBT”) failure to the MAC entity at MAC sublayer 225. MAC sublayer 225 provides a logical channel to RLC sublayer 230. RLC sublayer 230 provides an RLC channel to PDCP sublayer 235. PDCP sublayer 235 provides radio bearers to SDAP sublayer 240 and / or RRC layer 245. SDAP sublayer 240 provides QoS flows to the core network (e.g., 5GC). RRC layer 245 provides carrier aggregation and / or dual connectivity addition, modification, and release. RRC layer 245 also manages the establishment, configuration, maintenance, and release of signaling radio bearers (“SRB”) and data radio bearers (“DRB”).

[0065] NAS layer 250 is located between UE 205 and 5GC 215. NAS messages are transparently transmitted through the RAN. NAS layer 250 is used to manage the establishment of communication sessions and to maintain continuous communication with UE 205 when UE 205 moves between different cells in the RAN. In contrast, AS layer is located between UE 205 and the RAN (i.e., RAN node 210) and carries information through the radio portion of the network.

[0066] In NR Release 15, multiple waveforms are supported. Specifically, the uplink (“UL”) supports both CP-OFDM and DFT-s-OFDM. However, the configuration is only semi-static, allowing selection of one of them, for example, by enabling (or alternatively disabling) the parameter “transformPrecoding”. For instance, RAN node 210 can switch between multi-carrier CP-OFDM and single-carrier DFT-s-OFDM via RRC configuration. The higher-layer parameter TransformPrecoding in Push-Config / configured Grunt Config or msg3-TransformPrecoding in RACH-ConfigCommon provides indications for enabling or disabling the TransformPrecoding (DFT-s-OFDM) for PUSCH. UE 205 considers TransformPrecoding as “enabled” or “disabled” based on reading these messages, and RAN node 210 applies simultaneous reception from multiple UE 205s with different waveforms.

[0067] Fundamentally, CP-OFDM suffers from high PAPR (phase noise response rate), and this problem becomes more pronounced at higher frequency ranges. In Rel-17, the NR frequency range has been extended from 52.6-71 GHz; however, the waveforms for DL ​​(deep subcarrier) and UL (ultra-low subcarrier) remain unchanged, employing only a high subcarrier spacing (“SCS”) to address phase noise issues. However, future versions may support new waveform types, or even further extensions to NR operation, such as 71-114.25 GHz.

[0068] Assuming support for new waveforms is added while also supporting current waveforms (i.e., Rel-15, Rel-16, and Rel-17), the issue of multiple waveform indication / switching / waveform becomes relevant. Depending on the modulation sequence of different channels, coverage requirements, and other potential factors, multiplexing / transmission / repetition of control and / or data using multiple waveforms may be meaningful.

[0069] If the secondary cell (“SCell”) is in a dormant state, UE 205 stops monitoring the PDCCH in the dormant SCell, but activities such as CSI measurement / reporting and radio resource management (“RRM”) measurements are unaffected. In Rel-16 NR, dormant behavior can be implemented at the BWP level. The BWP that supports dormant behavior for the SCell is called a dormant BWP, where PDCCH monitoring is not configured. The transition between dormant and non-dormant behavior is achieved based on BWP handover.

[0070] The SCell sleep indication can be communicated by DCI with different DCI formats for UE 205 to detect both outside and inside DRX activity time.

[0071] When in DRX active time, the SCell sleep indication field is carried by a DCI with the DCI format used by data scheduling (i.e., DCI format 0_1 ​​and DCI format 1_1). The information field indicating sleep behavior is in bitmap form, where each bit corresponds to a configured SCell group.

[0072] When outside of DRX activity time, UE 205 detects a DCI with DCI format 2_6 on the primary cell (“PCell”) or primary / secondary cell (“PSCell”) for use as an SCell sleep indicator. In addition to the wake-up indicator, the SCell sleep indicator can be carried by the same DL control signaling with WUS using DCI format 2_6. To reduce blocking rate and resource overhead, DCI format 2_6 can be used to convey information for one or more UEs 205 in a group. Each UE 205 in the group is configured with a wake-up indicator location, and the SCell sleep indicator for that UE 205 follows the wake-up indicator.

[0073] Single-carrier waveforms such as DFT-s-OFDM or SC-FDE (or single-carrier frequency division multiplexing (“SC-FDM”) or CP-SC) have lower PAPR compared to OFDM and thus improve network coverage, especially at cell edges and / or at high carrier frequencies. However, OFDM offers better support for MIMO and better spectral efficiency, as well as efficient reference signal (“RS”) placement in the time-frequency grid, compared to single-carrier (“SC”) waveforms. On the other hand, for simplicity, some UEs will only be equipped with one waveform. Therefore, multi-waveform support for DL ​​and UL is a practical solution to adapt to variant deployments, coverage areas, and use case scenarios.

[0074] For UL / DL with multiple waveforms, RAN node 210 (i.e., gNB) can select waveforms (possibly including subcarrier spacing) based on parameters such as the carrier frequency used, UE measurements (RS received power (“RSRP”), RS received quality (“RSRQ”), and / or signal-to-interference-plus-noise ratio (“SINR”)), UE location, UE 205 and RAN node 210 RF capabilities, UE power status (e.g., power margin (“PH”) reports), UE auxiliary information (e.g., DL transform precoding recommendations based on path loss (“PL”) estimates), UE battery power status indications, and so on. These factors can influence the dynamic requirements of the optimal waveform. For example, UE 205’s battery / power status can assist RAN node 210 in selecting the correct waveform because some waveforms require higher signal processing reception complexity than others, and thus save some UE power under critical battery power conditions.

[0075] Radio access network (“RAN”) node 210 (e.g., gNB) can configure / transmit different waveforms to multiple UEs in time division multiplexing (“TDM”) in different time slots or symbols, and also in frequency division multiplexing (“FDM”) in different BWPs. UE 205 can support any one or both of multi-carrier and single-carrier waveforms. In such a scenario, RAN node 210 can select one of a set of transmitted waveform types (e.g., single-carrier or multi-carrier waveforms), and the network node can either dynamically switch the waveform for UE 205 or semi-statically configure the waveform type for UE 205. UE 205 can also be configured to receive using multiple waveform types within a scheduling interval for one or more DL physical channels.

[0076] For a deep learning (DL) with multiple waveforms, RAN node 210 can select waveforms (possibly including subcarrier spacing) based on parameters such as the carrier frequency used, UE measurement (RSRP / RSRQ / SINR) location, UE 205 and RAN node 210 RF capabilities, UE power state (e.g., PH report), UE auxiliary information (e.g., DL transform precoding recommendations based on PL estimation), UE battery power state indication, and so on. These factors can influence the dynamic requirements for the optimal waveform. UE battery power can help RAN node 210 select the correct waveform because some waveforms require higher signal processing reception complexity than others, and thus save some UE power at critical battery power states.

[0077] One of the key benefits of the proposed solution is that it allows for increased reliability by providing an additional degree of diversity, thereby enabling waveform switching between different transmission scenarios across the same or different beams.

[0078] Figure 3 The DRX adaptation power-saving technology 300 is described to configure a PDCCH-based power-saving signal / channel (also known as "DRX active time") at the active BWP before the start of DRX Ontime 305, for monitoring UE wake-up indication depending on the presence of data to be received by UE 205. A new DCI format 2_6 with cyclic redundancy check ("CRC") scrambled by a power-saving radio network temporary identifier ("PS-RNTI") is introduced, which includes a wake-up indication and a secondary cell ("SCell") sleep indication (if configured).

[0079] Power saving offset (“PS-offset”) 310 in such Figure 3 The interval for DCI with CRC scrambled via PS-RNTI (“DCP”) monitoring occasion 1315, shown, is semi-statically configured before the start of the DRX ON time. During DCP monitoring occasion 315, UE 205 monitors the search space (i.e., search space (“SS”) set 1) for DCP. In some embodiments, more than one monitoring occasion 315 may be configured for DCP on the primary cell (“PCell”) for carrier aggregation (“CA”) and on a specific cell (“SpCell”) for dual connectivity (“DC”) based on the search space (i.e., search space (“SS”) set 1) and the control resource set (“CORESET”).

[0080] As used herein, a CORESET is a set of physical resources (i.e., a specific area on the NR downlink resource grid) and a set of parameters used to carry PDCCH / DCI. Unlike the LTE PDCCH area (the first 1, 2, 3, and 4 OFDM symbols in a subframe), where the control area is always distributed across the entire channel bandwidth, in NR, the CORESET area is distributed as a specific area in the frequency domain. The search space refers to the area within the CORESET that the UE 205 must monitor to detect a specific PDCCH / DCI. There are two main categories of search spaces called CSS (General Search Space) and USS (UE-Specific Search Space). Which search space the UE 205 must monitor is defined by the Radio Network Temporary Identifier (“RNTI”) type or RRC configuration.

[0081] The minimum time interval of 320 is specified as follows: Figure 3 The UE processing time is shown. UE 205 is not required to monitor DCP (i.e., DCI with CRC scrambled by PS-RNTI) at the minimum time interval and within DRX On time 305.

[0082] When DCP monitoring scenario 315 conflicts with other processes with higher priority in PDCCH monitoring, the monitoring scenario is considered invalid. UE 205 follows legacy behavior when all configured monitoring scenarios are invalid.

[0083] In one embodiment, UE 205 is configured to wake up via RRC signaling when no DCP is detected by valid monitoring scenario 315. In another embodiment, UE 205 is configured not to wake up via RRC signaling when no DCP is detected by valid monitoring scenario 1315.

[0084] Note that the same DCP can be configured to independently control PDCCH monitoring during the on-time for one or more UEs. UE 205 can also be configured via RRC signaling to report periodic L1-RSRP or periodic CSI / L1-SINR when the UE is not instructed to wake up at DRX On time 305.

[0085] Figure 4 An example of PDCCH-WUS signaling 400 is depicted. RAN node 210 (e.g., gNB) uses PDCCH-WUS (e.g., DCP) signaling to indicate the DL waveform for subsequent DL transmissions via UE 205 through RAN node 210 (i.e., via DL reception of UE 205) in the next occurrence of drx-ondurationTimer, such that UE 205 knows in advance which waveform type (e.g., whether it is a multi-carrier or single-carrier waveform and specific waveforms within these categories) will be used for reception of the Physical Downlink Control Channel (“PDCCH”) or Physical Downlink Shared Channel (“PDSCH”) (or both) during drx-ondurationtimer.

[0086] PDCCH-WUS can also indicate the waveform to be used for receiving PDCCH or PDSCH or both, for the non-sleep bandwidth portion (“BWP”) and / or radio resource management (“RRM”) measurements for the sleep BWP against the SCell during drx-onDurationTimer.

[0087] UE 205 monitors PDCCH-WUS during WUS occasion 405. Note that WUS occasion 405 may correspond to DCP monitoring occasion 305. As depicted, there is a WUS offset 410 between WUS occasion 405 and the next DRX activity time 415 (i.e., the DRX On period). In various embodiments, the WUS offset 410 is larger than the minimum time interval 320 described above.

[0088] During DRX active time 415 (i.e., DRX On period), waveforms can be indicated as part of a DCI (e.g., DCI format 1_1 or DCI format 0_1) for transitioning from a non-dormant BWP to a dormant BWP. In one embodiment, a separate waveform indicator is used for each SCell or SCell group (i.e., a group of configured SCells). In another embodiment, a combined waveform indicator is used for all SCells to be used for both non-dormant and / or dormant BWPs.

[0089] The network (e.g., RAN node 210) semi-statically configures the waveform type (e.g., single-carrier or multi-carrier DL waveform) to be used for PDCCH-based WUS reception for UE 205.

[0090] According to an embodiment of the first solution, a PDCCH-WUS indication (“PCell”) waveform for the primary cell is used. The DL waveform type for PCell—for example, the single-carrier or multi-carrier to be used for PDCCH and / or PDSCH (i.e., DL physical channel) reception in the next occurrence of drx-onDurationTimer (i.e., DRX active time)—can be indicated in the PDCCH-WUS, i.e., using DCI format 2_6 or another DCI format monitored for UE 205 outside of DRX active time.

[0091] Figure 5 An example structure of a DCI 500 having DCI format 2_6 according to an embodiment of the present disclosure is depicted. The depicted DCI 500 includes a set of indications for two UEs, namely, a first UE (“UE-1”) and a second UE (“UE-2”). Each set of indications includes a wake-up indicator 505, a SCell sleep indicator 510, a waveform (“WF”) indicator 515 for the PCell, and a WF indicator 520 for a non-sleep (and / or sleep) BWP.

[0092] In a first implementation of the first solution, the new size parameter (e.g., SizeDCI_2-6) is signaled to UE 205 via higher-layer signaling. Additionally, the position of the waveform indicator bits for DCI format 2_6 (or similar) is semi-statically configured for each UE via higher-layer parameters, e.g., WfIDPositionDCI2-6. In one embodiment, the positions of individual PCell and SCell waveform indicators for DCI format 2_6 are semi-statically configured. In another embodiment, the positions of combined PCell and SCell waveform indicators for DCI format 2_6 are semi-statically configured.

[0093] In a second implementation of the first solution, one or more code points added in DCI format 2_6 provide information about the type of DL waveform to be received for each of the DL physical channels in the next occurrence of drx-onDurationTimer (i.e., DRX activity time 415).

[0094] In the third implementation of the first solution, a bit code point added to DCI format 2_6 provides information about the DL waveform type to be used for reception of all DL physical channels in the next occurrence of drx-onDurationTimer (i.e., DRX activity time 415).

[0095] In the fourth implementation of the first solution, multiple bits are added to the DCI format 2_6, which provide information about different single-carrier waveforms or different multi-carrier waveforms used for the DL physical channel.

[0096] In the fifth embodiment of the first solution, one or more code points of DCI format 2_6 may indicate the CORESET ID or search space ID or DCI format and the corresponding waveform to be used for its reception in the next occurrence of drx-onDurationTimer (i.e., DRX activity time 415).

[0097] In the sixth embodiment of the first solution, DCI format 2_6 can indicate the monitoring occasion for the search space ID or DCI format and / or the corresponding waveform to be received in the next occurrence of drx-onDurationTimer (i.e., DRX activity time 415).

[0098] In the seventh implementation of the first solution, the waveform of the DCI-WUS indication for the DL physical channel is applicable to UE 205 during its DRX activity time 415 (i.e., when the DRX On timer is running) only if DCI-WUS is received at a slot / symbol equal to or less than the minimum time slot (in terms of slot or symbol) before the DRX activity time 415 configured for UE 205 by the higher layer (i.e., defined by the drx-onDurationTimer). Otherwise, the UE is expected to receive the default waveform used for receiving the DL physical channel during the next DRX activity time 415.

[0099] In the eighth implementation of the first solution, when it does not decode DCI-WUS or does not detect DCI-WUS before DRX activity time 415, UE 205 is expected to use the default waveform for receiving the DL physical channel during the next DRX activity time 415.

[0100] In the ninth embodiment of the first solution, the validity of the waveform indicated by DCI-WUS can be applied to the entire DRX activity time 415 of the DRX cycle, unless there is an explicit indication received by DCI or higher-level signaling during the activity period of the DRX cycle.

[0101] In the tenth embodiment of the first solution, the maximum allowed duration of time slots within the DRX activity time 415 of the DRX cycle for UE 205 can be configured via higher-layer signaling. Alternatively, the maximum allowed duration of time can be explicitly indicated in DCI-WUS.

[0102] In some embodiments of the first solution, in the absence of information about the DL waveform to be used for PDCCH in the next occurrence of drx-onDurationTimer (i.e., DRX activity time 415), UE 205 may use the same waveform it uses to receive PDCCH_WUS. Alternatively, UE 205 may use the default waveform configured as part of the RRC PDCCH configuration or may continue to use the waveform type used in previous onDuration (when the DRX onDuration timer is running, for example, when the PDCCH-WUS wake-up indicator bit is set to "1" or when the UE is configured to wake up when no PDCCH-WUS is detected).

[0103] In some embodiments of the first solution, in the absence of information about the DL waveform to be used for PDSCH, UE 205 may use the same waveform it uses to receive PDCCH. Alternatively, UE 205 may use the default waveform configured as part of the RRCPDSCH configuration or may continue to use the waveform type previously used in onDuration (when the DRX onDuration timer is running, for example, when the PDCCH-WUS wake-up indicator bit is set to "1" or when the UE is configured to wake up when no PDCCH-WUS is detected).

[0104] According to an embodiment of the second solution, considering the dormant and non-dormant bandwidth portions of the secondary cell, the default waveform is semi-statically configured. Here, RAN node 210 can be semi-statically configured to consider the default DL waveform type for dormant BWPs and non-dormant BWPs, as well as dormant SCell groups within and outside the DRX activity time 415.

[0105] Figure 6A process 600 for waveform indication for both PCell 605 and SCell 610 according to embodiments of the present disclosure is described. Note that SCell 610 includes both a non-sleeping BWP 615 and a sleeping BWP 620. During WUS scenarios, UE 205 receives WUS 625 (i.e., DCI format 2_6) on PCell. Here, the received WUS 625 includes both a waveform indicator 630 for PCell 605 and a waveform indicator 635 for the non-sleeping BWP 615.

[0106] UE 205 wakes up upon receiving the WUS signal and initiates a drx-onDuration timer. During DRX activity time 640, UE 205 receives PDCCH and / or PDSCH 645 on PCell 605 using the indicated waveform. Additionally, UE 205 monitors and / or communicates on non-sleeping BWP 615 during the first portion of DRX activity time 640 using the indicated waveform.

[0107] During DRX activity time 640 and before BWP handover, UE 205 receives a second DCI (i.e., DCI format 1_1) containing waveform indicator 650 for BWP sleep 615.

[0108] In one implementation of the second solution, RAN node 210 can be semi-statically configured in various ways for the default DL waveform used for the hibernation BWP:

[0109] One or more code points in the RRC dedicated signaling indicate the default waveform type used for the sleep BWP, where each of the sleep BWPs in the SCell can be configured individually for the default waveform type, or a single default waveform type can be configured for all sleep BWPs in the SCell.

[0110] Alternatively, the default DL waveform type for SCell's hibernation BWP can have a similar or separate configuration during and outside of DRX active time.

[0111] In another implementation of the second solution, RAN node 210 can be semi-statically configured in UE 205 (e.g., using one or more code points) with a similar / identical default DL waveform or a separate default DL waveform for sleep and non-sleep BWPs.

[0112] In another implementation of the second solution, RAN node 210 can be semi-statically configured in UE 205 (e.g., using one or more code points) for a similar / identical default DL waveform or a separate default DL waveform for each of the DL physical channels and a similar / identical or separate waveform type for each non-sleeping BWP.

[0113] If no default waveform is configured for receiving PDSCH in the case of a non-sleeping BWP in the SCell, UE205 is expected to receive PDSCH using the same waveform used for receiving the PDCCH of that non-sleeping BWP.

[0114] In an alternative embodiment of the second solution, RAN node 210 may semi-statically configure in UE 205 a similar / identical default waveform type or a separate default waveform type for each BWP configured in SCell and for each in the DL physical channel.

[0115] According to an embodiment of the third solution, PDCCH-WUS is used to indicate waveforms for SCells when moving from a dormant to a non-dormant BWP (considering both during and outside of DRX active time). Here, the DL waveform type for the SCell—i.e., single-carrier or multi-carrier—is indicated in the next occurrence of the drx-onDurationTimer to be used in the non-dormant BWP for PDCCH and / or PDSCH reception, in DCI format 2_6 or another DCI format to be monitored outside of the DRX active time of UE 205.

[0116] In the first implementation of the third solution, a new SizeDCI_2-6 is sent to the UE via a higher layer, and the position of the DCI format 2_6 or a similar waveform indicator bit is configured for each UE via the higher layer parameter WfIDPositionDCI2-6_nondormancy.

[0117] In another implementation of the third solution, each SCell in the group (for non-sleeping BWP) can be configured with a separate waveform indicator code point as part of DCI format 2_6 or another DCI format monitored outside the UE's DRX activity time, where each bit corresponds to one of the configured SCells and has MSB to LSB of the following fields concatenated in order corresponding to the SCells with the lowest to highest SCell indices.

[0118] In another implementation of the third solution, a common waveform indicator can be configured for all SCells in the group (for non-dormant BWPs).

[0119] In another implementation of the third solution, DCI format 2_6 can indicate the CORESETid or search space id or DCI format and / or corresponding waveform to be received in the next occurrence of drx-onDurationTimer for non-sleeping BWP.

[0120] In another implementation of the third solution, DCI format 2_6 can indicate the waveform to be used to receive the RRM measurement signal from the gNB in ​​the next occurrence of the drx-onDurationTimer for the sleeping BWP.

[0121] DL waveform type for SCell - The single-carrier or multi-carrier waveform type to be used for PDCCH and / or PDSCH reception for non-sleeping BWP and / or the single-carrier or multi-carrier waveform type to be used for RRM measurements during sleeping BWP can be indicated in DCI (e.g., DCI format 1_1 or DCI format 0_1) or another DCI format monitored during the DRX activity time of UE 205.

[0122] According to the fourth solution, the waveform is indicated via waveform signaling. Network nodes can semi-statically configure the waveform type (e.g., single-carrier or multi-carrier DL waveform) for PDCCH-based WUS reception for UE 205.

[0123] In one implementation of the fourth solution, the RRC signaling used for CORESET or search space configuration carries an indicator for the waveform type, which can indicate – single-carrier or multi-carrier waveform. In another implementation of the fourth solution, the DCP-config parameter carries an indicator for the waveform type used to receive WUS. The waveforms for PDCCH-based WUS can be configured differently for PCell and PSCell.

[0124] If the CORESET (or search space configuration) of DCI format 2_6 does not include a waveform type, then UE 205 is expected to receive PDCCH-based WUS with the same waveform as CORESET 0 or SSB (SS / PBCH block).

[0125] In another implementation of the fourth solution, if the UE 205 is not configured with a waveform type for PDCCH-based WUS, the same waveform as CORESET0 or SSB is used for PDCCH-WUS in PCell, while the same waveform for receiving PSCell in CORESET is used for receiving PDCCH-WUS.

[0126] According to the fifth solution, the technology described above can be used to indicate the UL waveform type and / or the default waveform type, for example, for both PCell and SCell.

[0127] In one implementation of the fifth solution, the DL and UL waveform types can be configured to be the same or similar. In another implementation of the fifth solution, the DL and UL waveform types are indicated separately. In yet another implementation of the fifth solution, a distinct position offset for each UE can be configured by a higher layer of each UE to indicate the start of the UL waveform field in the DCI.

[0128] In one implementation, the UL configuration's licensing configuration may also indicate the UL waveform type to be used. In another implementation, UE 205 may use the UL waveform type indicated in DCI-WUS to transmit UL configuration licensing and / or dynamic licensing during the DRX activity time of UE 205's DRX cycle. In yet another implementation, UE 205 may ignore the indicated waveform type for CG and continue using the same UL waveform type mentioned in the configuration's licensing configuration until UE 205 receives a configuration licensing reconfiguration message from a higher layer.

[0129] In another implementation, UE 205 follows the waveform type indicated in the DCI to perform DL and / or UL data transmission during the DRX active time of the DRX cycle, and when it receives the DCI outside the DRX active time, UE 205 follows the waveform type to perform DL and / or UL data transmission during the DRX active time of the DRX cycle, unless and until UE 205 receives a second DCI with a second waveform type during the DRX active time of the DRX cycle.

[0130] Figure 7 User equipment device 700, which can be used to perform enhanced DM-RS configuration according to embodiments of the present disclosure, is depicted. In various embodiments, user equipment device 700 is used to implement one or more of the solutions described above. User equipment device 700 may be an embodiment of remote unit 105 and / or UE 205 described above. Furthermore, user equipment device 700 may include processor 705, memory 710, input device 715, output device 720, and transceiver 725.

[0131] In some embodiments, input device 715 and output device 720 are combined into a single device, such as a touchscreen. In some embodiments, user equipment device 700 may not include any input device 715 and / or output device 720. In various embodiments, user equipment device 700 may include one or more of the following: processor 705, memory 710, and transceiver 725, and may not include input device 715 and / or output device 720.

[0132] As depicted, transceiver 725 includes at least one transmitter 730 and at least one receiver 735. In some embodiments, transceiver 725 communicates with one or more cells (or radio coverage areas) supported by one or more basic units 121. In various embodiments, transceiver 725 may operate on unlicensed spectrum. Furthermore, transceiver 725 may include multiple UE panels supporting one or more beams. Additionally, transceiver 725 may support at least one network interface 740 and / or application interface 745. Application interface 745 may support one or more APIs. Network interface 740 may support 3GPP reference points such as Uu, N1, PC5, etc. Other network interfaces 740 may be supported, as will be understood by those skilled in the art.

[0133] In one embodiment, processor 705 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 705 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 705 executes instructions stored in memory 710 to perform the methods and routines described herein. Processor 705 is communicatively coupled to memory 710, input device 715, output device 720, and transceiver 725.

[0134] In various embodiments, processor 705 controls user equipment device 700 to implement the UE behavior described above. In some embodiments, processor 705 may include an application processor (also referred to as a "main processor") that manages application domain and operating system ("OS") functions and a baseband processor (also referred to as a "baseband radio processor") that manages radio functions.

[0135] In various embodiments, via transceiver 725, processor 705 monitors the DCI outside of DRX activity periods, where the DCI contains waveform indicators. Processor 705 determines the waveform type for the next DRX activity period and controls transceiver 725 to receive downlink transmissions on physical downlink channels (e.g., PDSCH and / or PDCCH) during the next DRX activity period using the determined waveform.

[0136] In some embodiments, the DCI includes DCI-WUS. In some embodiments, the waveform indicator provides information about the use of a single-carrier waveform type or a multi-carrier waveform type for reception of the physical downlink channel. In some embodiments, the position of the waveform indicator within the DCI is configured semi-statically via higher-layer signaling.

[0137] In some embodiments, the DCI uses one or more code points to provide information about the waveform type to be received for the physical downlink channel. In some embodiments, the one or more code points indicate one of the following: a CORESET identifier, a search space identifier, and a DCI format, wherein the one or more code points further indicate the corresponding waveform type for receiving the identified CORESET, search space, and / or DCI format.

[0138] In some embodiments, determining the waveform type for the next DRX activity time includes using a default waveform type if no DCI containing a waveform indicator is received for at least a threshold amount of time prior to the start of the next DRX activity time. In one embodiment, the DCI contains a waveform indicator but is not received with the minimum time interval between the DCI-WUS and the next DRX activity time. In another embodiment, the waveform indicator is not present in the DCI-WUS.

[0139] In some embodiments, receiving downlink transmissions during the next DRX activity period includes receiving a second waveform indication during the DRX activity period, the second waveform indication indicating a first waveform for use with a dormant BWP and a second waveform type for use with a non-dormant BWP. In some embodiments, each BWP of the SCell is configured with a default waveform type, wherein the same default waveform type is configured for the physical downlink channel.

[0140] In some embodiments, the DCI including waveform indicators includes code points configured for each SCell in the group by a non-dormant BWP, wherein each bit in the code point corresponds to one of the SCells in the group. In some embodiments, determining the waveform type for the next DRX activity time includes determining the waveform type used by the dormant BWP to perform RRM measurements.

[0141] In some embodiments, the same waveform type used for receiving a CORESET for the same cell is used to receive a DCI containing a waveform indicator. In some embodiments, the waveform indicator further indicates the waveform type to be used for the physical uplink channel during the next DRX activity period. In some embodiments, receiving downlink transmissions during the next DRX activity period includes receiving an uplink CG, wherein the uplink CG contains a second waveform indicator indicating the waveform type to be used for uplink CG transmissions.

[0142] In one embodiment, memory 710 is a computer-readable storage medium. In some embodiments, memory 710 includes volatile computer storage media. For example, memory 710 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 710 includes non-volatile computer storage media. For example, memory 710 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 710 includes both volatile and non-volatile computer storage media.

[0143] In some embodiments, memory 710 stores data related to configuring control signaling and enhanced DM-RS. For example, memory 710 may store various parameters, panel / beam configurations, resource assignments, policies, etc., as described above. In some embodiments, memory 710 also stores program code and related data, such as an operating system or other controller algorithms operating on device 700.

[0144] In one embodiment, input device 715 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. In some embodiments, input device 715 may be integrated with output device 720, for example, as a touchscreen or similar touch-sensitive display. In some embodiments, input device 715 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 715 includes two or more different devices, such as a keyboard and a touch panel.

[0145] In one embodiment, output device 720 is designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 720 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 720 may include, but is not limited to, a liquid crystal display (“LCD”), a light-emitting diode (“LED”) display, an organic LED (“OLED”) display, a projector, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, output device 720 may include a wearable display, such as a smartwatch, smart glasses, a head-up display, etc., separate from but communicatively coupled to the rest of user equipment device 700. Furthermore, output device 720 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0146] In some embodiments, output device 720 includes one or more speakers for generating sound. For example, output device 720 may generate an auditory alarm or notification (e.g., a buzzer or ring). In some embodiments, output device 720 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of output device 720 may be integrated with input device 715. For example, input device 715 and output device 720 may form a touchscreen or similar touch-sensitive display. In other embodiments, output device 720 may be located near input device 715.

[0147] Transceiver 725 communicates with one or more network functions of a mobile communication network via one or more access networks. Transceiver 725 operates under the control of processor 705 to transmit and receive messages, data, and other signals. For example, processor 705 may selectively activate transceiver 725 (or a portion thereof) at specific times to send and receive messages.

[0148] Transceiver 725 includes at least a transmitter 730 and at least one receiver 735. One or more transmitters 730 can be used to provide UL communication signals to base unit 121, such as UL transmissions described herein. Similarly, as described herein, one or more receivers 735 can be used to receive DL communication signals from base unit 121. Although only one transmitter 730 and one receiver 735 are illustrated, user equipment device 700 can have any suitable number of transmitters 730 and receivers 735. Furthermore, transmitters 730 and receivers 735 can be of any suitable type. In one embodiment, transceiver 725 includes a first transmitter / receiver pair for communicating with a mobile communication network on licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on unlicensed radio spectrum.

[0149] In some embodiments, a first transmitter / receiver pair for communicating with a mobile communication network on licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on unlicensed radio spectrum may be combined into a single transceiver unit, such as a single chip performing functions for both licensed and unlicensed radio spectrum. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair may share one or more hardware components. For example, certain transceivers 725, transmitters 730, and receivers 735 may be implemented as physically separate components that access shared hardware and / or software resources, such as, for example, a network interface 740.

[0150] In various embodiments, one or more transmitters 730 and / or one or more receivers 735 may be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an application-specific integrated circuit (“ASIC”), or other types of hardware components. In some embodiments, one or more transmitters 730 and / or one or more receivers 735 may be implemented and / or integrated into a multi-chip module. In some embodiments, other components such as network interface 740 or other hardware components / circuitets may be integrated with any number of transmitters 730 and / or receivers 735 into a single chip. In such embodiments, transmitters 730 and receivers 735 may be logically configured as transceivers 725 using a plurality of common control signals or as modular transmitters 730 and receivers 735 implemented in the same hardware chip or multi-chip module.

[0151] Figure 8A network device 800, which can be used to perform enhanced DM-RS configuration according to embodiments of the present disclosure, is depicted. In one embodiment, the network device 800 may be an implementation of a RAN node, such as the basic unit 121 or RAN node 210 as described above. Furthermore, the base station network device 800 may include a processor 805, a memory 810, an input device 815, an output device 820, and a transceiver 825.

[0152] In some embodiments, input device 815 and output device 820 are combined into a single device, such as a touchscreen. In some embodiments, network device 800 may not include any input device 815 and / or output device 820. In various embodiments, network device 800 may include one or more of the following: processor 805, memory 810, and transceiver 825, and may not include input device 815 and / or output device 820.

[0153] As depicted, transceiver 825 includes at least one transmitter 830 and at least one receiver 835. Here, transceiver 825 communicates with one or more remote units 85. Additionally, transceiver 825 may support at least one network interface 840 and / or application interface 845. Application interface 845 may support one or more APIs. Network interface 840 may support 3GPP reference points such as Uu, N1, N2, and N3. Other network interfaces 840 may be supported, as will be understood by those skilled in the art.

[0154] In one embodiment, processor 805 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 805 may be a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or similar programmable controller. In some embodiments, processor 805 executes instructions stored in memory 810 to perform the methods and routines described herein. Processor 805 is communicatively coupled to memory 810, input device 815, output device 820, and transceiver 825.

[0155] In various embodiments, network device 800 is a RAN node (e.g., gNB) communicating with one or more UEs, as described herein. In such embodiments, processor 805 controls network device 800 to perform the RAN behaviors described above. When operating as a RAN node, processor 805 may include an application processor (also referred to as a "main processor") that manages application domain and operating system ("OS") functions, and a baseband processor (also referred to as a "baseband radio processor") that manages radio functions.

[0156] In various embodiments, processor 805 determines for the UE the waveform type for the next DRX activity period. Processor 805 controls transceiver 825 to transmit a DCI outside of any DRX activity period of the UE, wherein the DCI contains a waveform indicator, and uses the determined waveform to transmit downlink transmissions on physical downlink channels (e.g., PDSCH and / or PDCCH) during the next DRX activity period.

[0157] In some embodiments, the DCI includes DCI-WUS. In some embodiments, waveform indicators provide information about the use of a single-carrier waveform type or a multi-carrier waveform type for reception of the physical downlink channel. In some embodiments, the location of the waveform indicators within the DCI is configured semi-statically via higher-layer signaling.

[0158] In some embodiments, the DCI uses one or more code points to provide information about the waveform type to be received for the physical downlink channel. In some embodiments, the one or more code points indicate one of the following: a CORESET identifier, a search space identifier, and a DCI format, wherein the one or more code points further indicate the corresponding waveform type for receiving the identified CORESET, search space, and / or DCI format.

[0159] In some embodiments, transmitting downlink transmissions during the next DRX activity period includes transmitting a second waveform indication during the DRX activity period, the second waveform indication indicating a first waveform type for use with a dormant BWP and a second waveform type for use with a non-dormant BWP. In some embodiments, each BWP of the SCell is configured with a default waveform type, wherein the same default waveform type is configured for the physical downlink channel.

[0160] In some embodiments, the DCI including waveform indicators includes code points configured for each SCell in the group by a non-dormant BWP, wherein each bit in the code point corresponds to one of the SCells in the group. In some embodiments, determining the waveform type for the next DRX activity time includes determining the waveform type used by the dormant BWP to perform RRM measurements.

[0161] In some embodiments, a DCI containing a waveform indicator is transmitted using the same waveform type as that used to transmit a CORESET for the same cell. In some embodiments, the waveform indicator further indicates the waveform type to be used for the physical uplink channel during the next DRX activity period. In some embodiments, transmitting downlink transmissions during the next DRX activity period includes transmitting an uplink CG for the UE, wherein the uplink CG contains a waveform type indicating the type to be used for uplink CG transmission.

[0162] In one embodiment, memory 810 is a computer-readable storage medium. In some embodiments, memory 810 includes volatile computer storage media. For example, memory 810 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 810 includes non-volatile computer storage media. For example, memory 810 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 810 includes both volatile and non-volatile computer storage media.

[0163] In some embodiments, memory 810 stores data related to the enhanced DM-RS configuration. For example, memory 810 may store parameters, configurations, resource assignments, policies, etc., as described above. In some embodiments, memory 810 also stores program code and related data, such as an operating system or other controller algorithms operating on device 800.

[0164] In one embodiment, input device 815 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. In some embodiments, input device 815 may be integrated with output device 820, for example, as a touchscreen or similar touch-sensitive display. In some embodiments, input device 815 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 815 includes two or more different devices, such as a keyboard and a touch panel.

[0165] In one embodiment, output device 820 is designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 820 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 820 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, output device 820 may include a wearable display, such as a smartwatch, smart glasses, head-up display, etc., separate from but communicatively coupled to the rest of network device 800. Furthermore, output device 820 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0166] In some embodiments, output device 820 includes one or more speakers for generating sound. For example, output device 820 may generate an auditory alarm or notification (e.g., a buzzer or ring). In some embodiments, output device 820 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of output device 820 may be integrated with input device 815. For example, input device 815 and output device 820 may form a touchscreen or similar touch-sensitive display. In other embodiments, output device 820 may be located near input device 815.

[0167] Transceiver 825 includes at least a transmitter 830 and at least one receiver 835. As described herein, one or more transmitters 830 can be used to communicate with a UE. Similarly, as described herein, one or more receivers 835 can be used to communicate with network functions in a PLMN and / or RAN. Although only one transmitter 830 and one receiver 835 are illustrated, network device 800 can have any suitable number of transmitters 830 and receivers 835. Furthermore, transmitters 830 and receivers 835 can be of any suitable type.

[0168] Figure 9 An embodiment of a method 900 for waveform indication using DCI according to embodiments of the present disclosure is depicted. In various embodiments, method 900 is performed by a user equipment device in a mobile communication network, such as remote unit 105, UE 205, and / or user equipment device 700 as described above. In some embodiments, method 900 is performed by a processor such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0169] Method 900 begins and includes monitoring a 905 DCI outside of a DRX activity period, wherein the DCI contains a waveform indicator. Method 900 includes determining a waveform type 910 for the next DRX activity period. Method 900 includes receiving a 915 downlink transmission on a physical downlink channel (e.g., PDSCH and / or PDCCH) during the next DRX activity period using the determined waveform. Method 900 ends.

[0170] Figure 10An embodiment of a method 1000 for waveform indication using DCI according to embodiments of the present disclosure is described. In various embodiments, method 1000 is performed by a RAN device in a mobile communication network, such as the basic unit 121 described above, RAN node 210, and / or network device device 800. In some embodiments, method 1000 is performed by a processor such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0171] Method 1000 begins and includes determining, for the UE, the waveform type 1005 for the next DRX activity time. Method 1000 includes transmitting a 1010 DCI outside of any DRX activity time for the UE, wherein the DCI contains a waveform indicator. Method 100 includes transmitting a downlink transmission 1015 on a physical downlink channel (e.g., PDSCH and / or PDCCH) during the next DRX activity time using the determined waveform. Method 1000 ends.

[0172] This document discloses a first apparatus for waveform indication using DCI according to embodiments of the present disclosure. The first apparatus may be implemented by a user equipment apparatus in a mobile communication network, such as remote unit 105, UE 205, and / or user equipment apparatus 800 described above. The first apparatus includes a transceiver and a processor that monitors the DCI outside of DRX activity periods, wherein the DCI contains waveform indicators. The processor determines the waveform type for the next DRX activity period, and the transceiver uses the determined waveform to receive downlink transmissions on physical downlink channels (e.g., PDSCH and / or PDCCH) during the next DRX activity period.

[0173] In some embodiments, the DCI includes DCI-WUS. In some embodiments, the waveform indicator provides information about the use of a single-carrier waveform type or a multi-carrier waveform type for reception of the physical downlink channel. In some embodiments, the position of the waveform indicator within the DCI is configured semi-statically via higher-layer signaling.

[0174] In some embodiments, the DCI uses one or more code points to provide information about the waveform type to be received for the physical downlink channel. In some embodiments, the one or more code points indicate one of the following: a CORESET identifier, a search space identifier, and a DCI format, wherein the one or more code points further indicate the corresponding waveform type for receiving the identified CORESET, search space, and / or DCI format.

[0175] In some embodiments, determining the waveform type for the next DRX activity time includes using a default waveform type if no DCI containing a waveform indicator is received for at least a threshold amount of time prior to the start of the next DRX activity time. In one embodiment, the DCI contains a waveform indicator but is not received with the minimum time interval between the DCI-WUS and the next DRX activity time. In another embodiment, the waveform indicator is not present in the DCI-WUS.

[0176] In some embodiments, receiving downlink transmissions during the next DRX activity period includes receiving a second waveform indication during the DRX activity period, the second waveform indication indicating a first waveform type for use with a dormant BWP and a second waveform type for use with a non-dormant BWP. In some embodiments, each BWP of the SCell is configured with a default waveform type, wherein the same default waveform type is configured for the physical downlink channel.

[0177] In some embodiments, the DCI including waveform indicators includes code points configured for each SCell in the group by a non-dormant BWP, wherein each bit in the code point corresponds to one of the SCells in the group. In some embodiments, determining the waveform type for the next DRX activity time includes determining the waveform type used by the dormant BWP to perform RRM measurements.

[0178] In some embodiments, the DCI containing a waveform indicator is received using the same waveform type as that used to receive the CORESET for the same cell. In some embodiments, the waveform indicator further indicates the waveform type to be used for the physical uplink channel during the next DRX activity period. In some embodiments, receiving downlink transmissions during the next DRX activity period includes receiving uplink CGs, wherein the uplink CGs contain a second waveform indicator indicating the waveform type to be used for uplink CG transmissions.

[0179] According to embodiments of this disclosure, a first method for waveform indication using a DCI is disclosed herein. The first method can be performed by a user equipment device in a mobile communication network, such as remote unit 105, UE 205, and / or user equipment device 800 as described above. The first method includes monitoring a DCI outside of a DRX activity period, wherein the DCI contains a waveform indicator. The first method includes determining a waveform type for the next occurring DRX activity period and receiving downlink transmissions on physical downlink channels (e.g., PDSCH and / or PDCCH) during the next occurring DRX activity period using the determined waveform.

[0180] In some embodiments, the DCI includes DCI-WUS. In some embodiments, the waveform indicator provides information about the use of a single-carrier waveform type or a multi-carrier waveform type for reception of the physical downlink channel. In some embodiments, the position of the waveform indicator within the DCI is configured semi-statically via higher-layer signaling.

[0181] In some embodiments, the DCI uses one or more code points to provide information about the waveform type to be received for the physical downlink channel. In some embodiments, the one or more code points indicate one of the following: a CORESET identifier, a search space identifier, and a DCI format, wherein the one or more code points further indicate the corresponding waveform type for receiving the identified CORESET, search space, and / or DCI format.

[0182] In some embodiments, determining the waveform type for the next DRX activity time includes using a default waveform type if no DCI containing a waveform indicator is received for at least a threshold amount of time prior to the start of the next DRX activity time. In one embodiment, the DCI contains a waveform indicator but is not received with the minimum time interval between the DCI-WUS and the next DRX activity time. In another embodiment, the waveform indicator is not present in the DCI-WUS.

[0183] In some embodiments, receiving downlink transmissions during the next DRX activity period includes receiving a second waveform indication during the DRX activity period, the second waveform indication indicating a first waveform type for use with a dormant BWP and a second waveform type for use with a non-dormant BWP. In some embodiments, each BWP of the SCell is configured with a default waveform type, wherein the same default waveform type is configured for the physical downlink channel.

[0184] In some embodiments, the DCI including waveform indicators includes code points configured for each SCell in the group by a non-dormant BWP, wherein each bit in the code point corresponds to one of the SCells in the group. In some embodiments, determining the waveform type for the next DRX activity time includes determining the waveform type used by the dormant BWP to perform RRM measurements.

[0185] In some embodiments, the DCI containing a waveform indicator is received using the same waveform type as that used to receive the CORESET for the same cell. In some embodiments, the waveform indicator further indicates the waveform type to be used for the physical uplink channel during the next DRX activity period. In some embodiments, receiving downlink transmissions during the next DRX activity period includes receiving uplink CGs, wherein the uplink CGs contain a second waveform indicator indicating the waveform type to be used for uplink CG transmissions.

[0186] This document discloses a second apparatus for waveform indication using DCI according to embodiments of the present disclosure. The second apparatus may be implemented by RAN equipment in a mobile communication network, such as the basic unit 121, RAN node 210, and / or network equipment apparatus 900 described above. The second apparatus includes a transceiver and a processor that determines the waveform type for the UE for the next DRX activity time. The processor controls the transceiver to transmit DCI outside of any DRX activity time of the UE, wherein the DCI contains a waveform indicator and uses the determined waveform to transmit downlink transmissions on physical downlink channels (e.g., PDSCH and / or PDCCH) during the next DRX activity time.

[0187] In some embodiments, the DCI includes DCI-WUS. In some embodiments, the waveform indicator provides information about the use of a single-carrier waveform type or a multi-carrier waveform type for reception of the physical downlink channel. In some embodiments, the position of the waveform indicator within the DCI is configured semi-statically via higher-layer signaling.

[0188] In some embodiments, the DCI uses one or more code points to provide information about the waveform type to be received for the physical downlink channel. In some embodiments, the one or more code points indicate one of the following: a CORESET identifier, a search space identifier, and a DCI format, wherein the one or more code points further indicate the corresponding waveform type for receiving the identified CORESET, search space, and / or DCI format.

[0189] In some embodiments, transmitting downlink transmissions during the next DRX activity period includes transmitting a second waveform indication during the DRX activity period, the second waveform indication indicating a first waveform type for use with a dormant BWP and a second waveform type for use with a non-dormant BWP. In some embodiments, each BWP of the SCell is configured with a default waveform type, wherein the same default waveform type is configured for the physical downlink channel.

[0190] In some embodiments, the DCI including waveform indicators includes code points configured for each SCell in the group by a non-dormant BWP, wherein each bit in the code point corresponds to one of the SCells in the group. In some embodiments, determining the waveform type for the next DRX activity time includes determining the waveform type used by the dormant BWP to perform RRM measurements.

[0191] In some embodiments, a DCI containing a waveform indicator is transmitted using the same waveform type as that used for receiving a CORESET for the same cell. In some embodiments, the waveform indicator further indicates the waveform type to be used for the physical uplink channel during the next DRX activity period. In some embodiments, transmitting downlink transmissions during the next DRX activity period includes transmitting an uplink CG for the UE, wherein the uplink CG contains a second waveform indicator indicating the waveform type to be used for uplink CG transmission.

[0192] This document discloses a second method for waveform indication using a DCI according to embodiments of the present disclosure. The second method can be performed by a RAN device in a mobile communication network, such as the basic unit 121, RAN node 210, and / or network device apparatus 900 described above. The second method includes determining a waveform type for the UE for the next DRX activity time and transmitting a DCI outside of any DRX activity time of the UE, wherein the DCI contains a waveform indicator. The second method includes transmitting downlink transmissions on physical downlink channels (e.g., PDSCH and / or PDCCH) during the next DRX activity time using the determined waveform.

[0193] In some embodiments, the DCI includes DCI-WUS. In some embodiments, the waveform indicator provides information about the use of a single-carrier waveform type or a multi-carrier waveform type for reception of the physical downlink channel. In some embodiments, the position of the waveform indicator within the DCI is configured semi-statically via higher-layer signaling.

[0194] In some embodiments, the DCI uses one or more code points to provide information about the waveform type to be received for the physical downlink channel. In some embodiments, the one or more code points indicate one of the following: a CORESET identifier, a search space identifier, and a DCI format, wherein the one or more code points further indicate the corresponding waveform type for receiving the identified CORESET, search space, and / or DCI format.

[0195] In some embodiments, transmitting downlink transmissions during the next DRX activity period includes transmitting a second waveform indication during the DRX activity period, the second waveform indication indicating a first waveform type for use with a dormant BWP and a second waveform type for use with a non-dormant BWP. In some embodiments, each BWP of the SCell is configured with a default waveform type, wherein the same default waveform type is configured for the physical downlink channel.

[0196] In some embodiments, the DCI including waveform indicators includes code points configured for each SCell in the group by a non-dormant BWP, wherein each bit in the code point corresponds to one of the SCells in the group. In some embodiments, determining the waveform type for the next DRX activity time includes determining the waveform type used by the dormant BWP to perform RRM measurements.

[0197] In some embodiments, a DCI containing a waveform indicator is transmitted using the same waveform type as that used for receiving a CORESET for the same cell. In some embodiments, the waveform indicator further indicates the waveform type to be used for the physical uplink channel during the next DRX activity period. In some embodiments, transmitting downlink transmissions during the next DRX activity period includes transmitting an uplink CG for the UE, wherein the uplink CG contains a second waveform indicator indicating the waveform type to be used for uplink CG transmission.

[0198] The embodiments can be practiced in other specific forms. The described embodiments are to be considered in all respects as illustrative rather than restrictive. Therefore, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All variations within the equivalent meaning and scope of the claims should be covered within their scope.

Claims

1. A method for a user equipment apparatus ("UE"), the method comprising: Monitoring downlink control information ("DCI") outside of the discontinuous reception ("DRX") DRX activity period, wherein the DCI includes waveform indicators; Determine the waveform type to be used for the next DRX activity; and Receive downlink transmissions on the physical downlink channel using the determined waveform during the next DRX activity period. The DCI uses one or more code points to provide information about the waveform type to be received for the physical downlink channel, wherein the one or more code points indicate one of the following: a control resource set ("CORESET") identifier, a search space identifier, and a DCI format, wherein the one or more code points further indicate the corresponding waveform type for receiving the identified CORESET, search space, and / or DCI format.

2. The method according to claim 1, wherein, The DCI includes the DCI wake-up signal ("DCI-WUS").

3. The method according to claim 1, wherein, The waveform indicator provides information about the use of a single-carrier waveform type or a multi-carrier waveform type for reception of the physical downlink channel.

4. The method according to claim 1, wherein, The position of the waveform indicator within the DCI is configured semi-statically via higher-layer signaling.

5. The method according to claim 1, wherein, Determining the waveform type for the next DRX activity time includes using the default waveform type when no DCI including a waveform indicator is received at least a threshold time amount prior to the start of the next DRX activity time.

6. The method according to claim 1, wherein, Receiving the downlink transmission during the next DRX activity period includes receiving a second waveform indication during the DRX activity period, the second waveform indication indicating a first waveform type for use with the dormant bandwidth portion ("BWP") and a second waveform type for use with the non-dormant BWP.

7. The method according to claim 6, wherein, Each BWP of the secondary cell ("SCell") is configured with a default waveform type, wherein the same default waveform type is configured for the physical downlink channel.

8. The method according to claim 1, wherein, The DCI including the waveform indicator includes code points configured for the non-dormant BWP of each secondary cell ("SCell") in the group, wherein each bit in the code points corresponds to one of the SCells in the group.

9. The method according to claim 1, wherein, Determining the waveform type for the next DRX activity time includes determining the waveform type used by the dormant BWP to perform radio resource management ("RRM") measurements.

10. The method according to claim 1, wherein, The DCI, including the waveform indicator, is received using the same waveform type as that used to receive the control resource set ("CORESET") for the same cell.

11. The method according to claim 1, wherein, The waveform indicator further indicates the waveform type that will be used for the physical uplink channel during the next DRX activity period.

12. The method according to claim 1, wherein, Receiving the downlink transmission during the next DRX activity period includes receiving an uplink configuration permission ("CG"), wherein the uplink CG includes a second waveform indicator indicating the waveform type to be used for the uplink CG transmission.

13. A user equipment ("UE") apparatus, comprising: Processor, the processor: Monitoring downlink control information ("DCI") outside of discontinuous reception ("DRX") activity periods, wherein the DCI includes waveform indicators; and Determine the waveform type to be used for the next DRX activity; and A transceiver that receives downlink transmissions on the physical downlink channel during the next DRX activity period using a determined waveform. The DCI uses one or more code points to provide information about the waveform type to be received for the physical downlink channel, wherein the one or more code points indicate one of the following: a control resource set ("CORESET") identifier, a search space identifier, and a DCI format, wherein the one or more code points further indicate the corresponding waveform type for receiving the identified CORESET, search space, and / or DCI format.

14. A radio access network ("RAN") apparatus, comprising: The processor determines for the user equipment ("UE") the waveform type for the next occurrence of discontinuous reception ("DRX") DRX activity time; as well as Transceiver, the transceiver: Outside of any DRX activity time of the UE, downlink control information ("DCI") is transmitted, wherein the DCI includes waveform indicators; and Using the determined waveform, transmit downlink transmissions on the physical downlink channel during the next DRX activity period. The DCI uses one or more code points to provide information about the waveform type to be received for the physical downlink channel, wherein the one or more code points indicate one of the following: a control resource set ("CORESET") identifier, a search space identifier, and a DCI format, wherein the one or more code points further indicate the corresponding waveform type for receiving the identified CORESET, search space, and / or DCI format.

15. The apparatus according to claim 14, wherein, The DCI includes the DCI wake-up signal ("DCI-WUS").

16. The apparatus according to claim 14, wherein, The waveform indicator provides information about the use of a single-carrier waveform type or a multi-carrier waveform type for reception of the physical downlink channel.

17. The apparatus according to claim 14, wherein, Transmitting the downlink transmission during the next DRX activity period includes transmitting a second waveform indication during the DRX activity period, the second waveform indication indicating a first waveform type for use with the dormant bandwidth portion ("BWP") and a second waveform type for use with the non-dormant BWP.

18. The apparatus according to claim 17, wherein, Each BWP of the secondary cell ("SCell") is configured with a default waveform type, wherein the same default waveform type is configured for the physical downlink channel.

Images