Signaling design for OCC information indication

Abstract

An apparatus configured to process, based on signals received from a network, an indication that the network supports Orthogonal Cover Code (OCC) operation in a Physical Uplink Shared Channel (PUSCH), generate, for transmission to the network, a UE capability report comprising an indication o f an OCC operation supported by the apparatus, and process, based on signals received from the network, a Medium Access Control Control Element (MAC CE) activating the OCC operation for PUSCH, wherein the MAC CE comprises an indication of OCC parameters for the OCC operation for PUSCH.

Description

Signaling Design for OCC Information IndicationBackground

[0001] A user equipment (UE) may establish a connection to at least one of multiple different networks or types of networks, e.g., a public land mobile network (PLMN) operating a radio access network (RAN) . A non-terrestrial network (NTN) refers to a network utilizing non-terrestrial components, e.g., one or more satellites, to provide UE access to a PLMN.

[0002] A satellite or other component of an NTN network may have a large coverage area, e.g., hundreds, thousands or millions of square kilometers. This large coverage area may include a large number of UEs. Because there may be a large number of UEs, it may be beneficial to increase the data throughput of the network in the uplink (UL) (e.g., the Physical Uplink Shared Channel (PUSCH) ) to increase the capacity of the network. One manner of increasing capacity may be for the UEs to use Orthogonal Cover Codes (OCC) in the UL. OCC is a manner of multiple UEs sharing the same time and frequency resources in the UL. However, there is currently no manner of configuring UEs in an NTN network to OCCs.Summary

[0003] Some example embodiments are related to an apparatus having processing circuitry configured to process, based on signals received from a network, an indication that the network supports Orthogonal Cover Code (OCC) operation in a Physical Uplink Shared Channel (PUSCH) , generate, for transmission to the network, a UE capability report comprising an indication of an OCC operation supported by the apparatus, and process, based on  signals received from the network, a Medium Access Control Control Element (MAC CE) activating the OCC operation for PUSCH, wherein the MAC CE comprises an indication of OCC parameters for the OCC operation for PUSCH.

[0004] Other example embodiments are related to an apparatus having processing circuitry configured to generate, for transmission to a user equipment (UE) , an indication that a network supports Orthogonal Cover Code (OCC) operation in a Physical Uplink Shared Channel (PUSCH) , process, based on signals received from the UE, a UE capability report comprising OCC operation supported by the UE, and generate, for transmission to the UE, a Medium Access Control Control Element (MAC CE) activating the OCC operation for PUSCH, wherein the MAC CE comprises an indication of OCC parameters for the OCC operation for PUSCH.

[0005] Still further example embodiments are related to an apparatus having processing circuitry configured to process, based on signals received from a network, an indication that the network supports Orthogonal Cover Code (OCC) operation in a Physical Uplink Shared Channel (PUSCH) , generate, for transmission to the network, a UE capability report comprising an indication of an OCC operation supported by the apparatus, and process, based on signals received from the network, Downlink Control Information (DCI) having a cyclic redundancy check (CRC) scrambled with a Radio Network Temporary Identification (RNTI) related to the OCC operation for PUSCH, wherein one or more fields in the DCI comprise an indication of OCC parameters for the OCC operation for PUSCH.

[0006] Additional example embodiments are related to an apparatus having processing circuitry configured to generate, for transmission to a user equipment (UE) , an indication that the network supports Orthogonal Cover Code (OCC) operation in a Physical Uplink Shared Channel (PUSCH) , process, based on signals received from a UE, a UE capability report comprising OCC operation supported by the UE, and generate, for transmission to the UE, Downlink Control Information (DCI) having a cyclic redundancy check (CRC) scrambled with a Radio Network Temporary Identification (RNT I) related to the OCC operation for PUSCH, wherein one or more fields in the DCI comprise an indication of OCC parameters for the OCC operation for PUSCH.Brief Description of the Drawings

[0007] Fig. 1 shows an example network arrangement according to various example embodiments.

[0008] Fig. 2 shows an example user equipment (UE) according to various example embodiments.

[0009] Fig. 3 shows an example base station according to various example embodiments.

[0010] Fig. 4 shows an example non-terrestrial network (NTN) architecture according to various example embodiments.

[0011] Fig. 5 shows an example method for signaling OCC information for a dynamic grant (DG) and activating OCC operations using a Medium Access Control Control Element (MAC CE) according to various example embodiments.

[0012] Fig. 6 shows a timing diagram for activation of OCC operations based on a timing of receiving UL grant DCI according to various example embodiments.

[0013] Fig. 7 shows a timing diagram for activation of OCC operations based on a timing of PUSCH according to various example embodiments.

[0014] Fig. 8 shows an example MAC CE for OCC operations according to various example embodiments.

[0015] Fig. 9 shows an example MAC CE for OCC operations without a radio resource control (RRC) configuration according to various example embodiments.

[0016] Fig. 10 shows an example method for signaling OCC information for a dynamic grant (DG) and activating OCC operations using a new Radio Network Temporary Identifier (RNT I) according to various example embodiments.Detailed Description

[0017] The example embodiments may be further understood with reference to the following description and the related appended drawings, wherein like elements are provided with the same reference numerals. The example embodiments relate to a signaling design to indicate Orthogonal Cover Code (OCC) information to a user equipment (UE) for a dynamic grant (DG)

[0018] The example embodiments are described with regard to a user equipment (UE) . However, reference to a UE is merely provided for illustrative purposes. The example embodiments may be utilized with any electronic component that may establish a connection to a network and is configured with the hardware, software, and / or firmware to exchange information and data with the network. Therefore, the UE as described herein is used to represent any appropriate electronic component.

[0019] The example embodiments are also described with regard to a 5G New Radio (NR) network. However, reference to a 5G NR network is merely provided for illustrative purposes. The example embodiments may be utilized with any network that may establish a connection to a UE and exchange information and data with the UE (e.g., 5G-Advanced networks, 6G networks, etc. ) .

[0020] The example embodiments are further described with regard to a 5G NR network integrated with a non-terrestrial-network (NTN) utilizing one or more satellites to provide UE access to the 5G NR radio access network (RAN) . A satellite-based NTN may be deployed by a public land mobile network (PLMN) and may be further integrated with a terrestrial network (TN) of the PLMN. Throughout this description, the non-terrestrial component is generally described as a satellite. However, any reference to a satellite is only for illustrative purposes and the example embodiments may apply to other types of non-terrestrial components, e.g., airplanes, unmanned aerial vehicles (UAVs) , etc.

[0021] The example embodiments are related to a signaling design to indicate OCC information to a UE for a DG. In some  example embodiments, the OCC information is signaled to the UE using a MAC CE. In other example embodiments, the OCC information is signaled to the UE using DCI scrambled by a new RNTI. Each of these example embodiments are described in greater detail below.

[0022] Fig. 1 shows an example network arrangement 100 according to various example embodiments. The example network arrangement 100 includes a UE 110. The UE 110 may be any type of electronic component that is configured to communicate via a network, e.g., mobile phones, tablet computers, desktop computers, smartphones, phablets, embedded devices, wearables, Internet of Things (IoT) devices, etc. An actual network arrangement may include any number of UEs being used by any number of users. Thus, the example of a single UE 110 is merely provided for illustrative purposes.

[0023] The UE 110 may be configured to communicate with one or more networks. In the example of the network arrangement 100, the network with which the UE 110 may wirelessly communicate is a 5G NR radio access network (RAN) 120. However, the UE 110 may also communicate with other types of networks (e.g., 5G cloud RAN, a next generation RAN (NG-RAN) , a long term evolution RAN, a legacy cellular network, a WLAN, etc. ) and the UE 110 may also communicate with networks over a wired connection. With regard to the example embodiments, the UE 110 may establish a connection with the 5G NR RAN 120. Therefore, the UE 110 may have a 5G NR chipset to communicate with the NR RAN 120.

[0024] The 5G NR RAN 120 may be a portion of a public land mobile network (PLMN) that may be deployed by a network carrier (e.g., Verizon, AT&T, T-Mobile, etc. ) . The 5G NR RAN 120 may include, for example, cells or base stations (Node Bs, eNodeBs, HeNBs, eNBS, gNBs, gNodeBs, macrocells, microcells, small cells, femtocells, etc. ) that are configured to send and receive traffic from UEs that are equipped with the appropriate cellular chip set.

[0025] In the network arrangement 100, the 5G NR RAN 120 includes a base station (e.g., gNB 120A) that may be in a terrestrial network (TN) deployment or a non-terrestrial network (NTN) deployment. For example, a satellite-based system may be integrated with the 5G NR RAN 120 to provide network access to the UE 110 in the NTN deployment and the base station may, in some cases, be located on a non-terrestrial component, e.g., a satellite. An example NTN network architecture will be described in greater detail below with reference to Fig. 4.

[0026] Returning to the network arrangement 100 of Fig. 1, the gNB 120A may include one or more communication interfaces to exchange data and / or information with the UE 110, the corresponding 5G NR RAN 120, the cellular core network 130, the internet 140, etc.

[0027] The UE 110 may connect to the 5G NR-RAN 120 via the gNB 120A. Any association procedure may be performed for the UE 110 to connect to the 5G NR-RAN 120. For example, as discussed above, the 5G NR-RAN 120 may be associated with a particular cellular provider where the UE 110 and / or the user thereof has a contract and credential information (e.g., stored on a SIM card) . Upon detecting the presence of the 5G NR-RAN 120, the UE  110 may transmit the corresponding credential information to associate with the 5G NR-RAN 120. More specifically, the UE 110 may associate with a specific cell (e.g., the gNB 120A) . However, as mentioned above, reference to the 5G NR-RAN 120 is merely for illustrative purposes and any appropriate type of RAN may be used.

[0028] In addition to the 5G NR RAN 120, the network arrangement 100 also includes a cellular core network 130, the Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network services backbone 160. The cellular core network 130 may be considered to be the interconnected set of components that manages the operation and traffic of the cellular network. The cellular core network 130 also manages the traffic that flows between the cellular network and the Internet 140.

[0029] The IMS 150 may be generally described as an architecture for delivering multimedia services to the UE 110 using the IP protocol. The IMS 150 may communicate with the cellular core network 130 and the Internet 140 to provide the multimedia services to the UE 110. The network services backbone 160 is in communication either directly or indirectly with the Internet 140 and the cellular core network 130. The network services backbone 160 may be generally described as a set of components (e.g., servers, network storage arrangements, etc. ) that implement a suite of services that may be used to extend the functionalities of the UE 110 in communication with the various networks.

[0030] Fig. 2 shows an example UE 110 according to various example embodiments. The UE 110 will be described with regard to  the network arrangement 100 of Fig. 1. The UE 110 may include a processor 205, a memory arrangement 210, a display device 215, an input / output (I / O) device 220, a transceiver 225 and other components 230. The other components 230 may include, for example, an audio input device, an audio output device, a power supply, a data acquisition device, ports to electrically connect the UE 110 to other electronic devices, etc.

[0031] The processor 205 may be configured to execute a plurality of engines of the UE 110. For example, the engines may include an OCC engine 235. The OCC engine 235 may perform various operations related to applying OCC operations to PUSCH transmissions for the UE 110. To provide some general examples, the OCC engine 235 may perform operations such as, but not limited to, reporting OCC capabilities to a network, activating / deactivating OCC operations for PUSCH transmissions, and determining when to activate and deactivate the OCC operations. These and other operations are described in greater detail below.

[0032] The above referenced engine 235 being an application (e.g., a program) executed by the processor 205 is merely provided for illustrative purposes. The functionality associated with the engine 235 may also be represented as a separate incorporated component of the UE 110 or may be a modular component coupled to the UE 110, e.g., an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry to receive signals and processing circuitry to process the signals and other information. The engine may also be embodied as one application or separate applications. In addition, in some UEs, the functionality  described for the processor 205 is split among two or more processors such as a baseband processor and an applications processor. The example embodiments may be implemented in any of these or other configurations of a UE.

[0033] The memory arrangement 210 may be a hardware component configured to store data related to operations performed by the UE 110. The display device 215 may be a hardware component configured to show data to a user while the I / O device 220 may be a hardware component that enables the user to enter inputs. The display device 215 and the I / O device 220 may be separate components or integrated together such as a touchscreen.

[0034] The transceiver 225 may be a hardware component configured to establish a connection with the 5G NR-RAN 120, an LTE-RAN (not pictured) , a legacy RAN (not pictured) , a WLAN (not pictured) , etc. Accordingly, the transceiver 225 may operate on a variety of different frequencies or channels (e.g., set of consecutive frequencies) . The transceiver 225 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals) . Such signals may be encoded with information implementing any one of the methods described herein. The processor 205 may be operably coupled to the transceiver 225 and configured to receive from and / or transmit signals to the transceiver 225. The processor 205 may be configured to encode and / or decode signals (e.g., signaling from a base station of a network) for implementing any one of the methods described herein.

[0035] Fig. 3 shows an example base station 300 according to various example embodiments. The base station 300 may represent the gNB 120A or any other type of access node through which the UE 110 may establish a connection and manage network operations.

[0036] The base station 300 may include a processor 305, a memory arrangement 310, an input / output (I / O) device 315, a transceiver 320, and other components 325. The other components 325 may include, for example, an audio input device, an audio output device, a battery, a data acquisition device, ports to electrically connect the base station 300 to other electronic devices and / or power sources, TxRUs, transceiver chains, antenna elements, antenna panels, etc.

[0037] The processor 305 may be configured to execute a plurality of engines for the base station 300. For example, the engines may include an OCC configuration engine 330. The OCC configuration engine 330 may perform various operations related to configuring a UE to apply OCC operations to PUSCH transmissions. To provide some general examples, the OCC configuration engine 330 may perform operations such as, but not limited to, signaling network support for OCC operations, receiving OCC capabilities from a UE, configuring OCC parameters for UE OCC operations in PUSCH, and activating / deactivating OCC operations for PUSCH transmissions. These and other operations are described in greater detail below.

[0038] The above noted engine 330 being an application (e.g., a program) executed by the processor 305 is only an example. The functionality associated with the engine 330 may also be  represented as a separate incorporated component of the base station 300 or may be a modular component coupled to the base station 300, e.g., an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry to receive signals and processing circuitry to process the signals and other information. In addition, in some base stations, the functionality described for the processor 305 is split among a plurality of processors (e.g., a baseband processor, an applications processor, etc. ) . The example embodiments may be implemented in any of these or other configurations of a base station.

[0039] The memory arrangement 310 may be a hardware component configured to store data related to operations performed by the base station 300. The I / O device 315 may be a hardware component or ports that enable a user to interact with the base station 300.

[0040] The transceiver 320 may be a hardware component configured to exchange data with the UE 110 and any other UEs in the network arrangement 100. The transceiver 320 may operate on a variety of different frequencies or channels (e.g., set of consecutive frequencies) . Therefore, the transceiver 320 may include one or more components to enable the data exchange with the various networks and UEs. The transceiver 320 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals) . Such signals may be encoded with information implementing any one of the methods described herein. The processor 305 may be operably coupled to the transceiver 320 and configured to receive from and / or transmit signals to the transceiver 320. The processor 305 may be  configured to encode and / or decode signals (e.g., signaling from a UE) for implementing any one of the methods described herein.

[0041] Fig. 4 shows an example non-terrestrial network (NTN) architecture 400 according to various example embodiments. An NTN may relate to any network using non-terrestrial components, such as satellites, airplanes, unmanned aerial vehicles (UAVs) , etc., to provide network services to a user terminal.

[0042] The NTN architecture 400 represents a network arrangement including one or more satellites, which in this example shows two satellite 410 and 420 that are integrated with a radio access network (RAN) 440. The RAN 440 may be, for example, the 5G NR RAN 120 described above with respect to Fig. 1. The NTN architecture 400 includes a gateway 430 connecting the terrestrial network 440 with the NTN components. In the NTN architecture 400 of Fig. 4, the gateway 430 and the satellites 410 and 420 communicate via feeder links. In some NTN deployments, satellites may be served by several gateways simultaneously.

[0043] The satellites 410 and 420 provide network services to a UE 110 via a service link (not shown) . The satellites 410 and 420 may implement either a transparent payload or a regenerative payload. A transparent payload refers to an arrangement where the satellites 410 and 420 receive signals and transmit an amplified version of the signal, with a frequency conversion.

[0044] For example, the satellite 410 may receive uplink communications from the UE 110 on service link frequencies and transmit an amplified version of the signal to the gateway 430 on feeder link frequencies or may receive downlink communications via the  gateway 430 on feeder link frequencies and transmit an amplified version of the signal to the UE 110 on service link frequencies. A regenerative payload refers to an arrangement where the satellites 410 and 420 act as a distributed unit (DU) or a base station (e.g., a gNB) , wherein received signals are regenerated with signal-processing techniques (e.g., demodulation, decoding, switching, encoding, modulation, etc. ) before being re-transmitted.

[0045] With reference to Fig. 1, in a regenerative payload arrangement, the gNB 120A may be located on an aerial component, e.g., the satellites 410 and / or 420 of Fig. 4. In a transparent payload arrangement, the gNB 120A may be located on the ground and the satellites 410 and 420 are used to mirror the signals between the gNB 120A and the UE 110, as described above. In either case, in the example embodiments, the satellites 410 and 420 may transmit signals that include the same PCI as will be described in greater detail below.

[0046] The example NTN architecture 400 shown in Fig. 4 is not intended to limit the example embodiments in any way. NTNs may be integrated with the 5G NR RAN and / or other networks in any one of a variety of manners. For example, a typical satellite-based NTN may comprise a low earth orbit (LEO) constellation including an array of satellites and gateways with broad interconnectivity via ground-to-ground station (G2G) links, satellite-to-satellite (S2S) links, ground-to-satellite (G2S) links, and satellite-to-ground (S2G) links. Other types of satellite-based NTNs may include geostationary-orbiting (GEO) satellites or medium-earth-orbiting (MEO) satellites.

[0047] The different types of NTNs each have respective strengths and weaknesses and may be deployed in a variety of scenarios, depending on the goal to be achieved, e.g., broad coverage across a large region, concentrated coverage in an urban environment or along a highly trafficked route, etc. Thus, the NTN architecture 400 described in Fig. 4 is merely provided for illustrative purposes.

[0048] As described above, one manner of increasing throughput in the UL on the PDSCH in an NTN network may be for UEs to use OCCs when transmitting data. However, there is no current mechanism for the network to signal an OCC configuration to the UEs. The following provides some example embodiments of a signaling method for signaling OCC configuration information to UEs in a dynamic grant (DG) . In some aspects of the example embodiments, the activation of the OCC is performed using Medium Access Control (MAC) signaling. In other aspects of the example embodiments, the activation of the OCC is performed using a new Radio Network Temporary Identifier (RNTI) .

[0049] Fig. 5 shows an example method 500 for signaling OCC information for a dynamic grant (DG) and activating OCC operations using a Medium Access Control Control Element (MAC CE) according to various example embodiments. The method is performed between the network (e.g., 5G NR RAN 120) and a UE (e.g., UE 110) .

[0050] In 510, the UE 110 receives a network configuration of OCC based PUSCH transmissions. The configuration may be a cell specific configuration that is carried in a System Information Block (SIB) . The SIB used to carry the network configuration may  be, for example, SIB1 (e.g., the SIB that includes PUSCH information) , SIB19 (e.g., the SIB that includes NTN information) , a new SIB, etc.

[0051] The network configuration may comprise, for example, a set of supported OCC lengths (e.g., {2, 4, 8} ) , a set of supported OCC codes (e.g., Walsh or Discrete Fourier Transform (DFT) sequences) , or any other information that may be used by the UE for the purposes of implementing the OCC. In addition, the network configuration may include, for each supported OCC length and supported OCC codes, the OCC sequence and index, e.g., for OCC length =2 and Walsh OCC codes, OCC sequence index 0 has [1 1] ; OCC sequence index 1 has [1 -1] , etc.

[0052] In 520, the UE 110 reports its capability of OCC spreading of PUSCH to the network in response to receiving the network configuration for OCC based PUSCH transmissions. The UE capability report may include an indication of the capability of the UE to apply OCC in PUSCH transmissions. A UE capability report may comprise an indication of an OCC operation supported by the UE. These capabilities may include an indication of sub-set (s) of OCC lengths the UE supports, an indication of sub-set (s) of OCC codes the UE supports, etc.

[0053] In 530, the UE receives radio resource configuration (RRC) configuration of OCC parameters to be used for PUSCH transmissions, e.g., the network may configure the specific configuration of OCC parameters based on the network supported parameters and the UE capability report. The contents of the RRC configuration may include the OCC length, OCC codes, and / or OCC sequence index under the OCC length / codes. Some UEs may support  multiple configurations. For example, a UE may receive an OCC Config #1 having an example OCC configuration of OCC length of 2, OCC codes of Walsh, and OCC sequence index 1= [1 -1] and an OCC Config #2 having an example OCC configuration of OCC length of 4, OCC codes of DFT sequence, and OCC sequence index 3 = [+1, +j, -1, -j ] .

[0054] As will be described in greater detail below, in some example embodiments, the UE 110 may not receive the RRC configuration.

[0055] In 540, the network may want to activate the OCC operations for the UE 110 by sending a MAC Control Element (MAC CE) based activation of the RRC configuration of the OCC-based PUSCH to the UE 110. The MAC CE may include, for example, the index of the RRC configuration to be activated. In the case of a UE being configured with multiple RRC configurations as described by way of example above, only one RRC configuration may be activated at a time.

[0056] When the UE 110 receives the activation command via the MAC CE, the UE 110 may determine the activation time as to when to activate OCC operations. The example embodiments provide various options for an activation time for OCC operations.

[0057] In some example embodiments, the activation time may be based on a timing of when UL grant Downlink Control Information (DCI) is received on the Physical Downlink Control Channel. In these example embodiments, if a UL grant DCI is received after a predetermined time (e.g., X ms) after the last symbol of the PDSCH carrying the MAC CE that activates OCC  operations, the UE 110 will use the OCC operations for the corresponding PUSCH. Otherwise, the UE 110 will not use the OCC operations for the corresponding PUSCH. The value of X for the predetermined time may be set to any value, for example, 1 ms, 3 ms, etc. These example embodiments will be described with reference to Fig. 6.

[0058] Fig. 6 shows a timing diagram 600 for activation of OCC operations based on a timing of receiving UL grant DCI according to various example embodiments.

[0059] At time t0, the UE 110 is not performing OCC operations as illustrated in Fig. 6. The UE 110 receives a UL grant 610 via DCI 1. At time t1, the UE 110 receives a MAC CE 620 activating the OCC operations as described above with reference to 540 of Fig. 5. At time t2, the UE 110 receives a UL grant 630 via DCI 2. In the example of Fig. 6, the UL grant 630 is received by the UE 110 X ms (e.g., the predetermined time) after the MAC CE 620 is received.

[0060] As described above, if a UL grant DCI is received after the predetermined time (e.g., X ms) after the last symbol of the PDSCH carrying the MAC CE that activates OCC operations, the UE 110 will use the OCC operations for the corresponding PUSCH. Otherwise, the UE 110 will not use the OCC operations for the corresponding PUSCH. In the example of Fig. 6, the UL grant 610 is received before the MAC CE 620 that activates OCC operations. Thus, for the PUSCH 640 corresponding to the UL grant 610, the UE does not use OCC operations. However, as shown in Fig. 6, the UL grant 630 is received after X ms after the MAC  CE 620 that activates OCC operations. Thus, for the PUSCH 650 corresponding to the UL grant 630, the UE uses OCC operations.

[0061] In other example embodiments, the activation time may be based on the timing of the PUSCH. In these example embodiments, if a PUSCH transmission is after a predetermined time (Y ms) after the last symbol of an acknowledgement (ACK) of the MAC CE that activates OCC operations, the PUSCH will use the OCC operations, no matter when the UL grant PDCCH is received. Otherwise, the PUSCH will not use the OCC operations. The predetermined time (e.g., Y ms) may be fixed (e.g., 3 ms as defined by standard) or may be configured in the MAC CE or other signaling related to the OCC operations. These example embodiments will be described with reference to Fig. 7.

[0062] Fig. 7 shows a timing diagram 700 for activation of OCC operations based on a timing of PUSCH according to various example embodiments.

[0063] At time t0, the UE 110 is not performing OCC operations as illustrated in Fig. 7. The UE 110 receives a UL grant 710 via DCI 1. At time t1, the UE 110 receives a MAC CE 720 activating the OCC operations as described above with reference to 540 of Fig. 5. At time t2, the UE 110 sends an ACK 730 acknowledging receipt of the MAC CE 720. At time t3, the UE 110 receives a UL grant 740 via DCI 2. In the example of Fig. 7, the PUSCH 750 corresponding to the UL grant 710 occurs at time t4 that is Y ms after the ACK 730. Thus, even though the UL grant 710 is received before the MAC CE 720, the corresponding PUSCH 750 is performed by the UE 110 using OCC operations. S imilarly, the  PUSCH 760 corresponding to the UL grant 740 that occurs at time t5 is also performed using OCC operations.

[0064] In still further example embodiments, the activation time may be based on both of the above example embodiments. For example, if any UL grant DCI is after X ms after the last symbol after the last symbol of the PDSCH carrying the MAC CE that activates OCC operation, and if the corresponding PUSCH transmission is after Y ms after the last symbol of the ACK of the MAC CE which activates OCC operations, the PUSCH will use the OCC operations. Otherwise, the PUSCH will not use the OCC operations. That is, in these example embodiments, both conditions of the above example embodiments need to be satis fied for OCC operations to be used for the PUSCH.

[0065] To provide an example of these example embodiments, the example of Fig. 7 may be considered again. As described above, the PUSCH 750 and PUSCH 760 satis fy the condition of the corresponding PUSCH transmission is after Y ms after the last symbol of the ACK of the MAC CE which activates OCC operations. However, the UL grant 710 does not satis fy the condition of being received after the predetermined time (e.g., X ms) after the last symbol of the PDSCH carrying the MAC CE that activates OCC operations, while the UL grant 740 satis fies this condition. Thus, in this example, the PUSCH 750 would not be performed using OCC operations but the PUSCVH 760 would be performed using OCC operations.

[0066] Returning to the method 500, in 550, the UE 110 may receive a dynamic grant of PUSCH, and applies the OCC-based  PUSCH using the activated OCC parameters based on, for example, the timing described above.

[0067] In 560, the UE 110 may receive a MAC CE based deactivation of the RRC configuration of OCC-based PUSCH and the UE 110 may then deactivate OCC operations for PUSCH. In some example embodiments, the MAC CE used for deactivation may be the same MAC CE that is used for activation. Some examples of this type of MAC CE are described below. In other example embodiments, the MAC CE may be a single bit indicating deactivation of the OCC operations because only a single OCC configuration may be active at a particular time.

[0068] The deactivation timeline may be similar to the examples of the activation timeline described above, e.g., based on the time of the received UL grants and / or based on the time of the scheduled PUSCH and the ACK associated with the deactivation MAC CE.

[0069] Fig. 8 shows an example Medium Access Control Control Element (MAC CE) 800 for OCC operations according to various example embodiments. The MAC CE 800 may be, for example, the MAC CE that is sent by the network to the UE 110 in 540 (activation) or 560 (deactivation) .

[0070] The MAC CE 800 may include a single bit 810 to activate an existing RRC configuration of the OCC or to deactivate the RRC configuration of the OCC. The following bits 820 may indicate the index of the RRC configuration to be activated or deactivated.

[0071] As stated above, in some example embodiments, the UE 110 may not receive the RRC configuration, e.g., 530 of Fig. 5 may not occur. In these example embodiments, the MAC CE that provides the activation / deactivation command may indicate the OCC length and OCC sequence index that is being activated / deactivated.

[0072] Fig. 9 shows an example MAC CE 900 for OCC operations without a radio resource control (RRC) configuration according to various example embodiments. Similar to the MAC CE 800, the MAC CE 900 may include a single bit 910 to activate or deactivate OCC operations. However, because the UE 110 may not have received the RRC configuration for OCC, the MAC CE 900 may also indicate the OCC length 920 and the OCC sequence index 930 (e.g., the information that may be provided in the RRC configuration) . For example, the OCC code may be predefined as either Walsh or DFT based and the MAC CE 900 may include an OCC length 920 of (2, 4, 8) and an OCC sequence index 930 of a value in [0 7] .

[0073] In the example MAC CE 800 and 900, example fields were shown with an example number of bits. These are only examples and the number of bits used for any field may be modified based on the type or quantity of OCC information to be indicated by the field.

[0074] As described above, in other aspects of the example embodiments, the activation of the OCC is performed using a new RNTI. The following will describe examples of using the new RNTI for the activation of the OCC operations.

[0075] Fig. 10 shows an example method 1000 for signaling OCC information for a dynamic grant (DG) and activating OCC operations using a new Radio Network Temporary Identifier (RNTI) according to various example embodiments. The method is performed between the network (e.g., 5G NR RAN 120) and a UE (e.g., UE 110) .

[0076] The operations 1010-1030 are similar to the operations 510-530 described above with reference to Fig. 5 and will not be described again.

[0077] In 1040, the UE 110 receives PDCCH with a dynamic grant of PUSCH, where the DCI cyclic redundancy check (CRC) is scrambled with a new RNTI. The new RNTI may be termed an OCC-RNTI but this is only an example and the new RNTI may be referred to by any name.

[0078] When the UE 110 receives the new RNTI, the UE 110 may reinterpret DCI fields. For example, certain fields in DCI Format 0_0 / 0_1 / 0_2 may be reinterpreted to indicate OCC related information. The following provides some examples of fields that may be reinterpreted in one or more of the DCI formats to indicate OCC related information.

[0079] In a first example, the most significant bit (s) (MSBs) or least significant bit (s) (LSBs) of a modulation and coding scheme (MCS) field may be repurposed to indicate OCC information. This is based on the MCS may be restricted in OCC based PUSCH transmissions because the OCC operations may be used when the UE is in bad channel conditions and therefore only a subset of the available MCS may be used by the UE. Therefore,  some bit (s) may be available for OCC information. To provide any example, in DCI Format 0_0, the MCS field may be 5 bits but only 3 bits are needed for the MCS. Thus, three LSB may be used for MCS and two MSB may be used for OCC related information.

[0080] In a second example, MSBs or LSBs of a Frequency Domain Resource Assignment (FDRA) field may be repurposed to indicate OCC information. This is based on only a certain range of the UL bandwidth part (BWP) may be used for OCC based PUSCH transmissions. Therefore, some bit (s) may be available for OCC information.

[0081] In a third example, MSBs or LSBs of a Time Domain Resource Assignment (TDRA) field may be repurposed to indicate OCC information.

[0082] In a fourth example, some or all bits in a redundancy version (RV) field may be repurposed to indicate OCC information. This is based on only RV=0 may be used for OCC based PUSCH transmissions. Therefore, some bit (s) may be available for OCC information.

[0083] In a fifth example, MSB (s) or LSB (s) of a Hybrid Automatic Repeat Request (HARQ) process number field may be repurposed to indicate OCC information. This is based on only a certain HARQ process number may be suitable for OCC based PUSCH transmissions. Therefore, some bit (s) may be available for OCC information.

[0084] In some example embodiments of the repurposed DCI fields described above, the bits may be used to indicate the  index of the RRC configuration for OCC information. This example uses the RRC configuration of OCC parameters as shown in 1030 of Fig. 10.

[0085] In other example embodiments of the repurposed DCI fields described above, the bits may be used to indicate the OCC length and OCC sequence index under the OCC length. In these example embodiments, the RRC configuration of the OCC parameters may not be used. Thus, similar to the examples described above, the RRC configuration of the OCC parameters may not be used, e.g., operation 1030 of Fig. 10 may not be performed.

[0086] Returning to the method 1000 of Fig. 10, the UE 110 may then apply the OCC-based PUSCH using the indicated OCC parameters that were decoded based on the new RNTI.

[0087] Examples

[0088] In a first example, a method comprising processing, based on signals received from a network, an indication that the network supports Orthogonal Cover Code (OCC) operation in a Physical Uplink Shared Channel (PUSCH) , generating, for transmission to the network, a UE capability report comprising an indication of an OCC operation supported by the apparatus, and processing, based on signals received from the network, a Medium Access Control Control Element (MAC CE) activating the OCC operation for PUSCH, wherein the MAC CE comprises an indication of OCC parameters for the OCC operation for PUSCH.

[0089] In a second example, the method of the first example, further comprising processing, based on signals received from  the network, a dynamic grant (DG) for PUSCH and applying the OCC parameters for the OCC operation in PUSCH for the PUSCH corresponding to the DG.

[0090] In a third example, the method of the second example, wherein the processing circuitry applies the OCC parameters when the DG is received after a predetermined time after a last symbol of the MAC CE activating the OCC operation.

[0091] In a fourth example, the method of the second example, further comprising generating, for transmission to the network, an acknowledgment (ACK) related to the MAC CE activating the OCC operation, wherein the processing circuitry applies the OCC parameters when the PUSCH corresponding to the DG is scheduled after a predetermined time after a last symbol of the ACK.

[0092] In a fifth example, the method of the second example, further comprising generating, for transmission to the network, an acknowledgment (ACK) related to the MAC CE activating the OCC operation, wherein the processing circuitry applies the OCC parameters when the PUSCH corresponding to the DG is scheduled after a predetermined time after a last symbol of the ACK and the DG is received after a predetermined time after a last symbol of the MAC CE activating the OCC operation.

[0093] In a sixth example, the method of the first example, further comprising processing, based on signals received from the network, a second MAC CE deactivating the OCC operation for PUSCH.

[0094] In a seventh example, the method of the sixth example, wherein the first and second MAC CE are a same type of MAC CE or a different type of MAC CE.

[0095] In an eighth example, the method of the sixth example, further comprising deactivating the OCC operation for DGs received after a predetermined time after a last symbol of the second MAC CE deactivating the OCC operation.

[0096] In a ninth example, the method of the sixth example, further comprising generating, for transmission to the network, an ACK for the second MAC CE deactivating the OCC operation, wherein the processing circuitry deactivates the OCC operation for PUSCH corresponding to DGs that are scheduled after a predetermined time after a last symbol of the ACK.

[0097] In a tenth example, the method of the sixth example, further comprising generating, for transmission to the network, an ACK related to the second MAC CE deactivating the OCC operation, wherein the processing circuitry deactivates the OCC operation for PUSCH corresponding to DGs that are scheduled after a predetermined time after a last symbol of the ACK and for DGs received after a predetermined time after a last symbol of the second MAC CE deactivating the OCC operation.

[0098] In an eleventh example, the method of the first example, further comprising processing, based on signals received from the network, a radio resource control (RRC) configuration comprising the OCC parameters for the OCC operation for PUSCH, wherein the MAC CE comprises an identification of the RRC configuration.

[0099] In a twelfth example, the method of the eleventh example, wherein the identification comprises an OCC configuration index.

[0100] In a thirteenth example, the method of the eleventh example, wherein the RRC configuration comprises a plurality of RRC configurations, wherein each of the plurality of RRC configurations comprises an index and wherein the identification in the MAC CE is an identification of one of the indexes.

[0101] In a fourteenth example, the method of the first example, wherein the indication that the network supports OCC operation in a PUSCH is received in a System Information Block (SIB) .

[0102] In a fifteenth example, the method of the fourteenth example, wherein the indication comprises one or more supported OCC lengths, one or more supported OCC codes and one or more OCC sequence corresponding to each of the supported OCC lengths and supported OCC codes.

[0103] In a sixteenth example, the method of the first example, wherein the UE capability report comprises one or more supported OCC lengths and one or more supported OCC codes.

[0104] In a seventeenth example, the method of the first example, wherein the OCC parameters comprise (i) an OCC length and OCC codes, or (ii) an OCC sequence index corresponding to OCC lengths and OCC codes.

[0105] In an eighteenth example, the method of the first example, wherein the MAC CE comprises the OCC parameters.

[0106] In a nineteenth example, a processor configured to perform any of the first through eighteenth examples.

[0107] In a twentieth example, a user equipment (UE) comprising a transceiver configured to communicate with a network and a processor communicatively coupled to the transceiver and configured to perform any of the first through eighteenth examples.

[0108] In a twenty first example, a method, comprising generating, for transmission to a user equipment (UE) , an indication that a network supports Orthogonal Cover Code (OCC) operation in a Physical Uplink Shared Channel (PUSCH) , processing, based on signals received from the UE, a UE capability report comprising OCC operation supported by the UE, and generating, for transmission to the UE, a Medium Access Control Control Element (MAC CE) activating the OCC operation for PUSCH, wherein the MAC CE comprises an indication of OCC parameters for the OCC operation for PUSCH.

[0109] In a twenty second example, the method of the twenty first example, further comprising generating, for transmission to the UE, a dynamic grant (DG) for PUSCH.

[0110] In a twenty third example, the method of the twenty first example, further comprising generating, for transmission to the UE, a second MAC CE deactivating the OCC operation for PUSCH.

[0111] In a twenty fourth example, the method of the twenty first example, wherein the first and second MAC CE are a same type of MAC CE or a different type of MAC CE.

[0112] In a twenty fifth example, the method of the twenty first example, further comprising generating, for transmission to the UE, a radio resource control (RRC) configuration comprising the OCC parameters for the OCC operation for PUSCH, wherein the MAC CE comprises an identification of the RRC configuration.

[0113] In a twenty sixth example, the method of the twenty fifth example, wherein the identification comprises an OCC configuration index.

[0114] In a twenty seventh example, the method of the twenty fifth example, wherein the RRC configuration comprises a plurality of RRC configurations, wherein each of the plurality of RRC configurations comprises an index and wherein the identification in the MAC CE is an identification of one of the indexes.

[0115] In a twenty eighth example, the method of the twenty first example, wherein the indication that the network supports OCC operation in a PUSCH is transmitted in a System Information Block (SIB) .

[0116] In a twenty ninth example, the method of the twenty eighth example, wherein the indication comprises one or more supported OCC lengths, one or more supported OCC codes and one  or more OCC sequence corresponding to each of the supported OCC lengths and supported OCC codes.

[0117] In a thirtieth example, the method of the twenty first example, wherein the UE capability report comprises one or more supported OCC lengths and one or more supported OCC codes.

[0118] In a thirty first example, the method of the twenty first example, wherein the OCC parameters comprise (i) an OCC length and OCC codes, or (ii) an OCC sequence index corresponding to OCC lengths and OCC codes.

[0119] In a thirty second example, the method of the twenty first example, wherein the MAC CE comprises the OCC parameters.

[0120] In a thirty third example, a processor configured to perform any of the twenty first through thirty second examples.

[0121] In a thirty fourth example, a base station comprising a transceiver configured to communicate with a user equipment (UE) and a processor communicatively coupled to the transceiver and configured to perform any of the first through eighteenth examples.

[0122] In a thirty fifth example, a method, comprising processing, based on signals received from a network, an indication that the network supports Orthogonal Cover Code (OCC) operation in a Physical Uplink Shared Channel (PUSCH) , generating, for transmission to the network, a UE capability report comprising an indication of an OCC operation supported by the apparatus, and processing, based on signals received from  the network, Downlink Control Information (DCI) having a cyclic redundancy check (CRC) scrambled with a Radio Network Temporary Identification (RNTI) related to the OCC operation for PUSCH, wherein one or more fields in the DCI comprise an indication of OCC parameters for the OCC operation for PUSCH.

[0123] In a thirty sixth example, the method of the thirty fifth example, further comprising processing, based on signals received from the network, a dynamic grant (DG) for PUSCH and applying the OCC parameters for the OCC operation in PUSCH for the PUSCH corresponding to the DG.

[0124] In a thirty seventh example, the method of the thirty fifth example, wherein the DCI comprises DCI format 0_0, DCI format 0_1 or DCI format 0_2.

[0125] In a thirty eighth example, the method of the thirty seventh example, wherein the one or fields in the DCI format 0_0, DCI format 0_1 or DCI format 0_2 includes the OCC parameters for the OCC operation in PUSCH.

[0126] In a thirty ninth example, the method of the thirty eighth example, wherein the one or more fields comprise a Modulation and Coding Scheme (MCS) field, a Frequency Domain Resource Assignment (FDRA) field, a Time Domain Resource Assignment (TDRA) field, a redundancy version (RV) field or a Hybrid Automatic Repeat Request (HARQ) process number field.

[0127] In a fortieth example, the method of the thirty fifth example, further comprising processing, based on signals received from the network, a radio resource control (RRC)  configuration comprising the OCC parameters for the OCC operation for PUSCH, wherein the one or more fields in the DCI comprises an identification of the RRC configuration.

[0128] In a forty first example, the method of the fortieth example, wherein the identification comprises an OCC configuration index.

[0129] In a forty second example, the method of the fortieth example, wherein the RRC configuration comprises a plurality of RRC configurations, wherein each of the plurality of RRC configurations comprises an index and wherein the identification in the DCI is an identification of one of the indexes.

[0130] In a forty third example, the method of the thirty fifth example, wherein the indication that the network supports OCC operation in a PUSCH is received in a System Information Block (SIB) .

[0131] In a forty fourth example, the method of the forty third example, wherein the indication comprises one or more supported OCC lengths, one or more supported OCC codes and one or more OCC sequence corresponding to each of the supported OCC lengths and supported OCC codes.

[0132] In a forty fifth example, the method of the thirty fifth example, wherein the UE capability report comprises one or more supported OCC lengths and one or more supported OCC codes.

[0133] In a forty sixth example, the method of the thirty fifth example, wherein the OCC parameters comprise (i) an OCC  length and OCC codes, or (ii) an OCC sequence index corresponding to OCC lengths and OCC codes.

[0134] In a forty seventh example, the method of the forty sixth example, wherein the one or more fields of the DCI comprise the OCC parameters.

[0135] In a forty eighth example, a processor configured to perform any of the thirty fifth through forty seventh examples.

[0136] In a forty ninth example, a user equipment (UE) comprising a transceiver configured to communicate with a network and a processor communicatively coupled to the transceiver and configured to perform any of the thirty fifth through forty seventh examples.

[0137] In a fiftieth example, a method, comprising generating, for transmission to a user equipment (UE) , an indication that the network supports Orthogonal Cover Code (OCC) operation in a Physical Uplink Shared Channel (PUSCH) , processing, based on signals received from a UE, a UE capability report comprising OCC operation supported by the UE, and generating, for transmission to the UE, Downlink Control Information (DCI) having a cyclic redundancy check (CRC) scrambled with a Radio Network Temporary Identification (RNTI) related to the OCC operation for PUSCH, wherein one or more fields in the DCI comprise an indication of OCC parameters for the OCC operation for PUSCH.

[0138] In a fifty first example, the method of the fiftieth example, further comprising generating, for transmission to the UE, a dynamic grant (DG) for PUSCH

[0139] In a fifty second example, the method of the fiftieth example, wherein the DCI comprises DCI format 0_0, DCI format 0_1 or DCI format 0_2.

[0140] In a fifty third example, the method of the fifty second example, wherein the one or fields in the DCI format 0_0, DCI format 0_1 or DCI format 0_2 includes the OCC parameters for the OCC operation in PUSCH.

[0141] In a fifty fourth example, the method of the fifty third example, wherein the one or more fields comprise a Modulation and Coding Scheme (MCS) field, a Frequency Domain Resource Assignment (FDRA) field, a Time Domain Resource Assignment (TDRA) field, a redundancy version (RV) field or a Hybrid Automatic Repeat Request (HARQ) process number field.

[0142] In a fifty fifth example, the method of the fiftieth example, further comprising generating, for transmission to the UE, a radio resource control (RRC) configuration comprising the OCC parameters for the OCC operation for PUSCH, wherein the one or more fields in the DCI comprises an identification of the RRC configuration.

[0143] In a fifty sixth example, the method of the fifty fourth example, wherein the identification comprises an OCC configuration index.

[0144] In a fifty seventh example, the method of the fifty fourth example, wherein the RRC configuration comprises a plurality of RRC configurations, wherein each of the plurality of RRC configurations comprises an index and wherein the identification in the DCI is an identification of one of the indexes.

[0145] In a fifty eighth example, the method of the fiftieth example, wherein the indication that the network supports OCC operation in a PUSCH is transmitted in a System Information Block (SIB) .

[0146] In a fifty ninth example, the method of the fifty eighth example, wherein the indication comprises one or more supported OCC lengths, one or more supported OCC codes and one or more OCC sequence corresponding to each of the supported OCC lengths and supported OCC codes.

[0147] In a sixtieth example, the method of the fiftieth example, wherein the UE capability report comprises one or more supported OCC lengths and one or more supported OCC codes.

[0148] In a sixty first example, the method of the fiftieth example, wherein the OCC parameters comprise (i) an OCC length and OCC codes, or (ii) an OCC sequence index corresponding to OCC lengths and OCC codes.

[0149] In a sixty second example, the method of the sixty first example, wherein the one or more fields of the DCI comprise the OCC parameters.

[0150] In a sixty third example, a processor configured to perform any of the fiftieth through sixty second examples.

[0151] In a sixty fourth example, a base station comprising a transceiver configured to communicate with a user equipment (UE) and a processor communicatively coupled to the transceiver and configured to perform any of the fiftieth through sixty second examples.

[0152] Those skilled in the art will understand that the above-described example embodiments may be implemented in any suitable software or hardware configuration or combination thereof. An example hardware platform for implementing the example embodiments may include, for example, an Intel x86 based platform with compatible operating system, a Windows OS, a Mac platform and MAC OS, a mobile device having an operating system such as iOS, Android, etc. The example embodiments of the above described method may be embodied as a program containing lines of code stored on a non-transitory computer readable storage medium that, when compiled, may be executed on a processor or microprocessor.

[0153] Although this application described various embodiments each having different features in various combinations, those skilled in the art will understand that any of the features of one embodiment may be combined with the features of the other embodiments in any manner not specifically disclaimed or which is not functionally or logically inconsistent with the operation of the device or the stated functions of the disclosed embodiments.

[0154] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

[0155] It will be apparent to those skilled in the art that various modifications may be made in the present disclosure, without departing from the spirit or the scope of the disclosure. Thus, it is intended that the present disclosure cover modifications and variations of this disclosure provided they come within the scope of the appended claims and their equivalent.

Claims

1.An apparatus comprising processing circuitry configured to:process, based on signals received from a network, an indication that the network supports Orthogonal Cover Code (OCC) operation in a Physical Uplink Shared Channel (PUSCH) ;generate, for transmission to the network, a UE capability report comprising an indication of an OCC operation supported by the apparatus;process, based on signals received from the network, a Medium Access Control Control Element (MAC CE) activating the OCC operation for PUSCH, wherein the MAC CE comprises an indication of OCC parameters for the OCC operation for PUSCH.2.The apparatus of claim 1, wherein the processing circuitry is further configured to:process, based on signals received from the network, a dynamic grant (DG) for PUSCH; andapply the OCC parameters for the OCC operation in PUSCH for the PUSCH corresponding to the DG.3.The apparatus of claim 2, wherein the processing circuitry applies the OCC parameters when the DG is received after a predetermined time after a last symbol of the MAC CE activating the OCC operation.4.The apparatus of claim 2, wherein the processing circuitry is further configured to:generate, for transmission to the network, an acknowledgment (ACK) related to the MAC CE activating the OCC operation,wherein the processing circuitry applies the OCC parameters when the PUSCH corresponding to the DG is scheduled after a predetermined time after a last symbol of the ACK.5.The apparatus of claim 2, wherein the processing circuitry is further configured to:generate, for transmission to the network, an acknowledgment (ACK) related to the MAC CE activating the OCC operation,wherein the processing circuitry applies the OCC parameters when the PUSCH corresponding to the DG is scheduled after a predetermined time after a last symbol of the ACK and the DG is received after a predetermined time after a last symbol of the MAC CE activating the OCC operation.6.The apparatus of claim 1, wherein the processing circuitry is further configured to:process, based on signals received from the network, a second MAC CE deactivating the OCC operation for PUSCH.7.The apparatus of claim 6, wherein the processing circuitry is further configured to:deactivate the OCC operation for DGs received after a predetermined time after a last symbol of the second MAC CE deactivating the OCC operation.8.The apparatus of claim 6, wherein the processing circuitry is further configured to:generate, for transmission to the network, an ACK for the second MAC CE deactivating the OCC operation,wherein the processing circuitry deactivates the OCC operation for PUSCH corresponding to DGs that are scheduled after a predetermined time after a last symbol of the ACK.9.The apparatus of claim 6, wherein the processing circuitry is further configured to:generate, for transmission to the network, an ACK related to the second MAC CE deactivating the OCC operation, wherein the processing circuitry deactivates the OCC operation for PUSCH corresponding to DGs that are scheduled after a predetermined time after a last symbol of the ACK and for DGs received after a predetermined time after a last symbol of the second MAC CE deactivating the OCC operation.10.The apparatus of claim 1, wherein the processing circuitry is further configured to:process, based on signals received from the network, a radio resource control (RRC) configuration comprising the OCC parameters for the OCC operation for PUSCH, wherein the MAC CE comprises an identification of the RRC configuration.11.The apparatus of claim 10, wherein the identification comprises an OCC configuration index.12.The apparatus of claim 10, wherein the RRC configuration comprises a plurality of RRC configurations, wherein each of the plurality of RRC configurations comprises an index and wherein the identification in the MAC CE is an identification of one of the indexes.13.The apparatus of claim 1, wherein the OCC parameters comprise (i) an OCC length and OCC codes, or (ii) an OCC sequence index corresponding to OCC lengths and OCC codes.14.An apparatus comprising processing circuitry configured to:process, based on signals received from a network, an indication that the network supports Orthogonal Cover Code (OCC) operation in a Physical Uplink Shared Channel (PUSCH) ;generate, for transmission to the network, a UE capability report comprising an indication of an OCC operation supported by the apparatus;process, based on signals received from the network, Downlink Control Information (DCI) having a cyclic redundancy check (CRC) scrambled with a Radio Network Temporary Identification (RNTI) related to the OCC operation for PUSCH, wherein one or more fields in the DCI comprise an indication of OCC parameters for the OCC operation for PUSCH.15.The apparatus of claim 14, wherein the processing circuitry is further configured to:process, based on signals received from the network, a dynamic grant (DG) for PUSCH; andapply the OCC parameters for the OCC operation in PUSCH for the PUSCH corresponding to the DG.16.The apparatus of claim 1, wherein the DCI comprises DCI format 0_0, DCI format 0_1 or DCI format 0_2, and wherein the one or fields in the DCI format 0_0, DCI format 0_1 or DCI format 0_2 includes the OCC parameters for the OCC operation in PUSCH.17.The apparatus of claim 16, wherein the one or more fields comprise a Modulation and Coding Scheme (MCS) field, a Frequency Domain Resource Assignment (FDRA) field, a Time Domain Resource Assignment (TDRA) field, a redundancy version (RV) field or a Hybrid Automatic Repeat Request (HARQ) process number field.18.The apparatus of claim 14, wherein the processing circuitry is further configured to:process, based on signals received from the network, a radio resource control (RRC) configuration comprising the OCC parameters for the OCC operation for PUSCH, wherein the one or more fields in the DCI comprises an identi fication of the RRC configuration.19.The apparatus of claim 18, wherein the identification comprises an OCC configuration index.20.The apparatus of claim 18, wherein the RRC configuration comprises a plurality of RRC configurations, wherein each of the plurality of RRC configurations comprises an index and wherein the identification in the DCI is an identi fication of one of the indexes.

Images