Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
DYNAMIC TRANSFORM PRECODING INDICATION FOR PHYSICAL UPLINK SHARED CHANNEL AND/OR MSG3 TRANSMISSION
Document Type and Number:
WIPO Patent Application WO/2023/196812
Kind Code:
A1
Abstract:
Various embodiments herein provide techniques for dynamic transform precoding indication for a physical uplink shared channel (PUSCH) transmission and/or a msg3 transmission associated with a random access channel (RACH) procedure. For example, a downlink control information (DCI) that schedules a PUSCH may include a field to indicate whether transform precoding is enabled or disabled for the PUSCH. Additionally, or alternatively, the uplink grant received in the msg2 of the RACH procedure may include an indication of whether transform precoding is enabled or disabled for the msg3. Other embodiments may be described and claimed.

Inventors:
XIONG GANG (US)
WANG GUOTONG (CN)
RANE PRERANA (US)
Application Number:
PCT/US2023/065326
Publication Date:
October 12, 2023
Filing Date:
April 04, 2023
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
INTEL CORP (US)
International Classes:
H04W72/232; H04L1/00; H04L27/26; H04W72/04; H04W72/12; H04W74/08
Foreign References:
US20190327693A12019-10-24
Other References:
MODERATOR (ZTE): "Summary of email discussion for [104-e-NR-2Step-RACH-01]", 3GPP DRAFT; R1-2103924, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG1, no. e-Meeting; 20210412 - 20210420, 16 April 2021 (2021-04-16), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051995694
MODERATOR (ZTE CORPORATION): "Feature lead summary #3 on support of Type A PUSCH repetitions for Msg3", 3GPP DRAFT; R1-2202594, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG1, no. e-Meeting; 20220221 - 20220303, 4 March 2022 (2022-03-04), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP052122290
INTEL CORPORATION: "Discussion on potential techniques for PUSCH coverage enhancement", 3GPP DRAFT; R1-2005889, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG1, no. e-Meeting; 20200817 - 20200828, 8 August 2020 (2020-08-08), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051917791
HUAWEI, HISILICON: "Discussions on the configuration for transform preceding of PUSCH", 3GPP DRAFT; R2-1900984 DISCUSSIONS ON THE CONFIGURATION FOR TRANSFORM PRECEDING OF PUSCH, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Athens, Greece; 20190225 - 20190301, 15 February 2019 (2019-02-15), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051602350
Attorney, Agent or Firm:
PARKER, Wesley E. et al. (US)
Download PDF:
Claims:
CLAIMS

1. One or more non-transitory computer-readable media (NTCRM) having instructions, stored thereon, that when executed by one or more processors of a user equipment (UE) configure the UE to: decode a downlink control information (DCI) that schedules a physical uplink shared channel (PUSCH), wherein the DCI includes a field to indicate whether transform precoding is enabled or disabled for the PUSCH; and encode the PUSCH for transmission based on the field.

2. The one or more NTCRM of claim 1, wherein the DCI is a DCI format 0 0, a DCI format 0 1, or a DCI format 0 2.

3. The one or more NTCRM of claim 1, wherein the DCI has a cyclic redundancy check (CRC) scrambled by a cell (C) - radio network temporary identifier (RNTI), a configured scheduling (CS)-RNTI with a new data indicator having a value of 1, or a modulation and coding scheme (MCS)-C-RNTI.

4. The one or more NTCRM of claim 1, wherein the field is one bit.

5. The one or more NTCRM of any one of claims 1-4, wherein the instructions, when executed, are further to configure the UE to receive configuration information to indicate whether the field is to be present in the DCI.

6. The one or more NTCRM of claim 1, wherein the PUSCH is included in a Msg3 of a random access procedure.

7. The one or more NTCRM of claim 1, wherein the PUSCH is a first PUSCH, wherein the DCI schedules multiple PUSCHs in a cell including the first PUSCH, and wherein the field indicates whether transform precoding is enabled or disabled for all of the multiple PUSCHs.

8. The one or more NTCRM of claim 1, wherein the field is a first field, and wherein to decode the DCI includes to determine a size of a second field of the DCI as a larger of a first size that is used for a cyclic prefix (CP)-orthogonal frequency division multiplexing (OFDM) waveform and a second size that is used for a discrete Fourier transform (DFT)-spread (s)-OFDM waveform.

9. The one or more NTCRM of claim 1, wherein to decode the DCI includes to determine an overall size of the DCI as a larger of a first DCI size that is used for a cyclic prefix (CP)-orthogonal frequency division multiplexing (OFDM) waveform and a second DCI size that is used for a discrete Fourier transform (DFT)-spread (s)-OFDM waveform.

10. The one or more NTCRM of claim 9, wherein the field is at the beginning of the DCI to indicate whether the DCI corresponds to the CP-OFDM waveform or the DFT-s-OFDM waveform.

11. One or more non-transitory computer-readable media (NTCRM) having instructions, stored thereon, that when executed by one or more processors of a next generation Node B (gNB) configure the gNB to: encode, for transmission to a user equipment (UE), a downlink control information (DCI) that schedules a physical uplink shared channel (PUSCH), wherein the DCI includes a field to indicate whether transform precoding is enabled or disabled for the PUSCH; and decode the PUSCH based on the field.

12. The one or more NTCRM of claim 11, wherein the DCI is a DCI format 0 0, a DCI format 0 1, or a DCI format 0 2.

13. The one or more NTCRM of claim 11, wherein the DCI has a cyclic redundancy check (CRC) scrambled by a cell (C) - radio network temporary identifier (RNTI), a configured scheduling (CS)-RNTI with a new data indicator having a value of 1, or a modulation and coding scheme (MCS)-C-RNTI.

14. The one or more NTCRM of claim 11, wherein the field is one bit.

15. The one or more NTCRM of any one of claims 11-14, wherein the instructions, when executed, are further to configure the gNB to transmit configuration information to the UE to indicate whether the field is to be present in the DCI.

16. The one or more NTCRM of claim 11, wherein the PUSCH is included in a Msg3 of a random access procedure.

17. The one or more NTCRM of claim 11, wherein the PUSCH is a first PUSCH, wherein the DCI schedules multiple PUSCHs in a cell including the first PUSCH, and wherein the field indicates whether transform precoding is enabled or disabled for all of the multiple PUSCHs.

18. The one or more NTCRM of claim 11, wherein the field is a first field, and wherein to encode the DCI includes to determine a size of a second field of the DCI as a larger of a first size that is used for a cyclic prefix (CP)-orthogonal frequency division multiplexing (OFDM) waveform and a second size that is used for a discrete Fourier transform (DFT)-spread (s)-OFDM waveform.

19. The one or more NTCRM of claim 11, wherein to encode the DCI includes to determine an overall size of the DCI as a larger of a first DCI size that is used for a cyclic prefix (CP)-orthogonal frequency division multiplexing (OFDM) waveform and a second DCI size that is used for a discrete Fourier transform (DFT)-spread (s)-OFDM waveform.

20. The one or more NTCRM of claim 19, wherein the DCI includes a waveform indication field at the beginning of the DCI to indicate whether the DCI corresponds to the CP- OFDM waveform or the DFT-s-OFDM waveform.

21. One or more non-transitory computer-readable media (NTCRM) having instructions, stored thereon, that when executed by one or more processors of a user equipment (UE) configure the UE to: receive a random access response (RAR) message with an uplink (UL) grant for a Msg3 and an indication of whether transform precoding is enabled or disabled for the Msg3; and transmit the Msg3 in accordance with the indication.

22. The one or more NTCRM of claim 21, wherein the indication is provided by a bit of a designated field or a bit of a field that also encodes other information.

23. The one or more NTCRM of claim 22, wherein the field is a transmit power control (TPC) command field, a channel state information (CSI) request field, a physical uplink shared channel (PUSCH) frequency resource allocation field, or a PUSCH time resource allocation field.

24. The one or more NTCRM of claim 21, wherein the indication is based on a time domain resource allocation (TDRA) table, wherein individual rows of the TDRA table include the indication of whether transform precoding is enabled or disabled, a K2 value, a mapping type, and a starting and length indicator value (SLIV).

25. The one or more NTCRM of any one of claims 21-24, wherein the Msg3 is transmitted using a cyclic prefix (CP)-orthogonal frequency division multiplexing (OFDM) waveform or a discrete Fourier transform (DFT)-spread (s)-OFDM waveform based on the indication.

Description:
DYNAMIC TRANSFORM PRECODING INDICATION FOR PHYSICAL UPLINK SHARED CHANNEL AND/OR MSG3 TRANSMISSION

CROSS REFERENCE TO RELATED APPLICATION

The present application claims priority to U.S. Provisional Patent Application No. 63/327,681, which was filed April 5, 2022; U.S. Provisional Patent Application No. 63/410,996, which was filed September 28, 2022; U.S. Provisional Patent Application No. 63/421,023, which was filed October 31, 2022; and to U.S. Provisional Patent Application No. 63/483,684, which was filed February 7, 2023.

FIELD

Various embodiments generally may relate to the field of wireless communications. For example, some embodiments may relate to dynamic transform precoding indication for physical uplink shared channel (PUSCH) transmission and/or msg3 transmission associated with a random access channel (RACH) procedure.

BACKGROUND

Mobile communication has evolved significantly from early voice systems to today’s highly sophisticated integrated communication platform. The next generation wireless communication system, 5G, or new radio (NR) will provide access to information and sharing of data anywhere, anytime by various users and applications. NR is expected to be a unified network/system that target to meet vastly different and sometime conflicting performance dimensions and services. Such diverse multi-dimensional requirements are driven by different services and applications. In general, NR will evolve based on 3 GPP LTE -Advanced with additional potential new Radio Access Technologies (RATs) to enrich people lives with better, simple, and seamless wireless connectivity solutions. NR will enable everything connected by wireless and deliver fast, rich contents and services.

For cellular system, coverage is an important factor for successful operation. Compared to LTE, NR can be deployed at relatively higher carrier frequency in frequency range 1 (FR1), e.g., at 3.5GHz. In this case, coverage loss is expected due to larger path-loss, which makes it more challenging to maintain an adequate quality of service. Typically, uplink coverage is the bottleneck for system operation considering the low transmit power at UE side.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings. Figure 1 illustrates a 4-step random access channel (RACH) procedure.

Figure 2 illustrates a RACH procedure with dynamic transform precoding indication, in accordance with various embodiments.

Figure 3 schematically illustrates a wireless network in accordance with various embodiments.

Figure 4 schematically illustrates components of a wireless network in accordance with various embodiments.

Figure 5 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.

Figure 6 depicts an example procedure for practicing the various embodiments discussed herein.

Figure 7 depicts another example procedure for practicing the various embodiments discussed herein.

Figure 8 depicts another example procedure for practicing the various embodiments discussed herein.

DETAILED DESCRIPTION

The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of the present document, the phrases “A or B” and “A/B” mean (A), (B), or (A and B).

Various embodiments herein provide techniques for dynamic transform precoding indication for a physical uplink shared channel (PUSCH) transmission and/or a msg3 transmission associated with a random access channel (RACH) procedure. For example, a downlink control information (DCI) that schedules a PUSCH may include a field to indicate whether transform precoding is enabled or disabled for the PUSCH. In some embodiments, the DCI is a DCI format 0 0, a DCI format 0 1, or a DCI format 0 2. Additionally, or alternatively, in some embodiments, the DCI has a cyclic redundancy check (CRC) scrambled by a cell (C) - radio network temporary identifier (RNTI), a configured scheduling (CS)-RNTI, a semi-persistent - channel state information (SP-CSI)-RNTI, or a modulation and coding scheme (MCS)-C-RNTI.

Embodiments also provide techniques for dynamic transform precoding indication for transmission of msg3 (e.g., initial transmission or retransmission(s)) in a random access procedure. For example, the uplink grant received in the msg2 of the random access procedure may include an indication of whether transform precoding is enabled or disabled for the msg3. In some embodiments, the indication may be in a designated field and/or may use one or more bits of a field that also encodes other information (e.g., by repurposing an existing field).

In NR Rel-15, a 4-step random access channel (RACH) procedure was defined. Figure 1 illustrates the 4-step RACH procedure for initial access. In the first step, the user equipment (UE) transmits physical random access channel (PRACH) in the uplink (UL) by randomly selecting one preamble signature, which would allow gNB to estimate the delay between gNB and UE for subsequent UL timing adjustment. Subsequently, in the second step, gNB feedbacks the random access response (RAR) which carries timing advanced (TA) command information and uplink grant for the uplink transmission in the third step. The UE expects to receive the RAR within a time window, of which the start and end are configured by the gNB via system information block (SIB). Then, according to the UL grant in the RAR, UE can transmit a UL message (Msg3) which includes an identity of the UE. Finally, after successful reception of msg3, the gNB can transmit a downlink (DL) message (Msg4) which serves as contention resolution for the UE.

In NR, system design is based on waveform choice of cyclic prefix - orthogonal frequencydivision multiplexing (CP-OFDM) for DL and UL, and additionally, Discrete Fourier Transform- spread-OFDM (DFT-s-OFDM) for UL. Note that DFT-s-OFDM waveform is realized by enabling transform precoding at the transmitter side. When transform precoding is disabled, CP-OFDM waveform is employed for PUSCH transmission. Typically, DFT-s-OFDM waveform can achieve better uplink coverage performance due to its low Peak-to-Average Power Ratio (PAPR) compared to CP-OFDM waveform.

The waveform used for the Msg3 transmission is configured by NR remaining minimum system information (RMSI). For 4-step RACH, coverage enhancement is essential for proper system operation given the fact that initial access is the first step for UE to access the network. In order to further improve the coverage for Msg3 transmission, certain mechanisms may need to be defined to allow dynamic transform precoder indication for Msg3 transmission.

Various embodiments herein provide techniques for dynamic transform precoding indication for Msg3 transmission. For example, aspects of various embodiments may include:

• Dynamic transform precoding indication for Msg3 initial transmission • Dynamic transform precoding indication for Msg3 retransmission

• Dynamic transform precoding indication for PUSCH transmission

Dynamic transform precoding indication for Msg3 initial transmission

As mentioned above, in NR, system design is based on waveform choice of cyclic prefix - orthogonal frequency-division multiplexing (CP-OFDM) for DL and UL, and additionally, Discrete Fourier Transform-spread-OFDM (DFT-s-OFDM) for UL. Note that DFT-s-OFDM waveform is realized by enabling transform precoding at the transmitter side. When transform precoding is disabled, CP-OFDM waveform is employed for PUSCH transmission. Typically, DFT-s-OFDM waveform can achieve better uplink coverage performance due to its low Peak-to- Average Power Ratio (PAPR) compared to CP-OFDM waveform.

Note that waveform used for the Msg3 transmission is configured by NR remaining minimum system information (RMSI). For 4-step RACH, coverage enhancement is essential for proper system operation given the fact that initial access is the first step for UE to access the network. In order to further improve the coverage for Msg3 transmission, certain mechanisms may need to be defined to allow dynamic transform precoding indication for Msg3 transmission.

In the following embodiments, Msg3 initial transmission is the Msg3 transmission which is scheduled by RAR UL grant. Further, Msg3 retransmission is the Msg3 transmission which is scheduled by a DCI format 0 0 with Cyclic Redundancy Check (CRC) scrambled by a Temporary Cell - Radio Network Temporary Identifier (TC-RNTI).

Aspects of various embodiments for dynamic transform precoding indication for Msg3 initial transmission are described further below.

In one embodiment, enabling/disabling transform precoding for CP-OFDM and DFT-s- OFDM waveform generation can be indicated in the RAR UL grant for Msg3 initial transmission. In particular, in order to maintain the same size for RAR UL grant and ensure backward compatibility, one field in the RAR UL grant may be repurposed to indicate the enabling/disabling transform precoding for Msg3 initial transmission. In this case, bit “1” may be used to indicate transform precoding is enabled, e.g., DFT-s-OFDM waveform is employed for the Msg3 initial transmission, while bit “0” may be used to indicate transform precoding is disabled, e.g., CP- OFDM waveform is employed for the Msg3 initial transmission.

Note that when Msg3 waveform is determined from dynamic enabling/disabling, transform precoding may override the waveform which is configured by msg3-transformPrecoder.

Figure 2 illustrates one example of the random access procedure with dynamic transform precoding indication for Msg3 initial transmission. In the example, dynamic transform precoding indication is indicated in the RAR UL grant. Further, UE transmits Msg3 initial transmission in accordance with the indicated transform precoding indication.

In one option, one most significant bit (MSB) of TPC command for PUSCH can be repurposed for transform precoding indication. Further, 2 LSB of TPC command may be used to indicate 4 values of TPC command as defined in Table 8.2-2 in TS38.213, V. 17.0.0 [1], Note that the 4 values of TPC command for PUSCH may be configured by higher layers via symbol information block (SIB) or NR remaining minimum system information (RMSI).

Table 1 illustrates one example of modified RAR UL grant to indicate enabling/disabling transform precoding. In the example, 1 MSB of TPC command for PUSCH is used to indicate transform precoding.

Table 1. Modified RAR UL grant to indicate enabling/disabling transform precoding:

Option 1

In another option, CSI request may be repurposed for transform precoding indication. Note that in NR, CSI request in RAR UL grant is reserved. In addition, whether to enable CSI request or transform precoding indication in the RAR UL grant may be configured by higher layers via RMSI.

Table 2 illustrates one example of modified RAR UL grant to indicate enabling/disabling transform precoding. In the example, CSI request field is disabled, and 1 bit transform precoding is included in the RAR UL grant.

Table 2. Modified RAR UL grant to indicate enabling/disabling transform precoding: Option 2

In another option, 1 MSB of PUSCH frequency resource allocation can be repurposed for transform precoding indication. Table 3 illustrates one example of modified RAR UL grant to indicate enabling/disabling transform precoding. In the example, 1 bit transform precoding is included in the RAR UL grant, and 13 bits are used for PUSCH frequency resource allocation for operation without shared spectrum channel access

Table 3. Modified RAR UL grant to indicate enabling/disabling transform precoding: Option 3

In another embodiment, enabling/disabling transform precoding may be indicated by PUSCH time resource allocation. In particular, a new TDRA table may be defined, where each row of the TDRA table may include enabling/disabling transform precoding, K2, mapping type, starting and length indicator value (SLIV). Note that K2, mapping type, and SLIV may be selected based on a row of TDRA table as defined in Section 6.1.2.1.1 in TS38.214, V17.0.0 [2],

For this option, based on the indicated PUSCH time resource allocation from RAR UL, UE can determine whether transform precoding is enabled/disabled or whether CP-OFDM or DFT-s-OFDM waveform is used for Msg3 transmission. In another embodiment, one or more states in one or more field or reserved state in the

RAR UL grant may be used to indicate enabling/disabling transform precoding for Msg3 initial transmission.

In another option, some state in one or more field or reserved state in the RAR UL grant may be used to indicate that the transform precoding which is configured by msg3- transformPrecoder is reverted. In one example, when lowest value for TPC command is indicated in the RAR UL grant, this would indicate that the transform precoding which is configured by msg3-transformPrecoder is reverted. Dynamic transform precoding indication for Msg3 retransmission

Aspects of various embodiments for dynamic transform precoding indication for Msg3 retransmission are described further below.

In one embodiment, enabling/disabling transform precoding for CP-OFDM and DFT-s- OFDM waveform generation of Msg3 retransmission can be explicitly indicated in the DCI format 0 0 with CRC scrambled by TC-RNTI.

As a further extension, whether this field is present in the DCI format 0 0 with CRC scrambled by TC-RNTI can be configured by higher layers via RMSI, OSI, or RRC signalling. In case when the field is not present, the UE shall, for this PUSCH transmission, consider the transform precoding either enabled or disabled according to the higher layer configured parameter msg3-transformPrecoder . Further, in case when the field is present, this transform precoding indication can override the msg3-transformPrecoder .

In another embodiment, the above embodiments for enabling/disabling transform precoding for Msg3 initial transmission can apply for that for Msg3 retransmission. For instance, a new TDRA table may be defined, where each row of the TDRA table may include enabling/disabling transform precoding, K2, mapping type and SLIV. Further, time domain resource assignment field in the DCI format 0 0 can be used to select one row of the new TDRA table. Further, UE can determine whether transform precoding is enabled/disabled or whether CP- OFDM or DFT-s-OFDM waveform is used for Msg3 retransmission.

In another option, “New data indicator” or “HARQ process number” fields which are reserved in the DCI format 0 0 with CRC scrambled by a TC-RNTI can be repurposed to indicate enabling/disabling transform precoding for Msg3 retransmission.

In another embodiment, in case of Msg3 PUSCH repetition for initial transmission and retransmission, e.g., the number of repetitions is greater than 1, a default transform precoding or waveform can be applied for Msg3 repetition. In particular, transform precoding may be enabled by default, e.g., waveform may be predefined in the specification as DFT-s-OFDM waveform.

Note that in this case, default waveform may override the dynamic waveform indication or waveform that is configured by msg3-transformPrecoder .

Dynamic transform precoding indication for PUSCH transmission

Aspects of various embodiments for dynamic transform precoding indication for PUSCH transmission are described further below.

In one embodiment, for DCI format 0 0 with CRC scrambled by C-RNTI or CS-RNTI or MCS-C-RNTI, one bit field can be explicitly included to indicate enabling/disabling transform precoding for PUSCH transmission. As a further extension, whether this field is present in the DCI format 0 0 with CRC scrambled by C-RNTI or CS-RNTI or MCS-C-RNTI can be configured by higher layers via RMSI, OSI, or RRC signalling. In case when the field is not present, the UE shall, for this PUSCH transmission, consider the transform precoding either enabled or disabled according to the higher layer configured parameter msg3-transformPrecoder . Further, in case when the field is present, this transform precoding indication can override the msg3-transformPrecoder .

Note that this option applies for PUSCH transmission scheduled by a PDCCH with CRC scrambled by CS-RNTI with NDI=1, C-RNTI, or MCS-CRNTI or SP-CSI-RNTI

In another embodiment, for DCI format 0 1 and 0 2 with CRC scrambled by C-RNTI or CS-RNTI or SP-CSI-RNTI or MCS-C-RNTI, one field can be explicitly included to indicate enabling/disabling transform precoding for PUSCH transmission.

As a further extension, whether this field is present in the DCI format 0 1 and 0 2 with CRC scrambled by C-RNTI or CS-RNTI or SP-CSI-RNTI or MCS-C-RNTI can be configured by higher layers via RMSI, OSI, or RRC signalling. In case when the field is not present, and if the UE is configured with the higher layer parameter transformPrecoder in pusch-Config, UE shall, for this PUSCH transmission, consider the transform precoding either enabled or disabled according to this parameter.

Further, in case when the field is not present, and if the UE is not configured with the higher layer parameter transformPrecoder in pusch-Config, the UE shall, for this PUSCH transmission, consider the transform precoding either enabled or disabled according to the higher layer configured parameter msg3-transformPrecoder .

When the field is present, this transform precoding indication can override the transformPrecoder in pusch-Config and/or msg3-transformPrecoder .

Note that this option applies for PUSCH transmission scheduled by a PDCCH with CRC scrambled by CS-RNTI with NDI=1, C-RNTI, or MCS-CRNTI or SP-CSI-RNTI.

In another embodiment, for the above embodiments, explicit indication in the RAR UL grant, DCI format 0 0, 0 1, or 0 2 may be used to indicate that the transform precoding which is configured by transformPrecoder in pusch-Config and/or msg3-transformPrecoder is reverted. For instance, when transformPrecoder = enabled, the explicit indication in the DCI may be used to indicate that transformPrecoder = disabled. The same mechanism can also apply for the case of Msg3 initial transmission and retransmission.

In another embodiment, a separate RNTI may be configured by higher layers via RRC signalling, and when DCI format 0 0, 0 1 and 0 2 with CRC scrambled with the separate RNTI, this may indicate that transform precoding which is configured by transformPrecoder in pusch- Config and/or msg3-transformPrecoder is reverted. In another embodiment, for PUSCH repetition type A or type B when the number of repetitions is greater than 1, or for TBoMS when the number of slots for TBS determination is great than 1 regardless of whether repetitions is employed, transform precoding may be enabled by default, e.g., default waveform may be employed as DFT-s-OFDM waveform.

In another option, when SUL is triggered for PUSCH transmission, e.g., UL/SUL indicator is indicated as “1” in the DCI format 0 0, 0 1 or 0 2, transform precoding may be enabled by default, e.g., default waveform may be employed as DFT-s-OFDM waveform.

This may be combined with other conditions to determine whether default waveform is applied for PUSCH transmission. In one option, when the indicated modulation and coding scheme (MCS) is lower than a threshold, and/or when the indicated number of layers for the scheduled PUSCH is 1 or rank is 1, then this can be combined with the above option with more than one repetitions to determine that default waveform or DFT-s-OFDM waveform is applied for the PUSCH transmission. In this case, this may override the transformPrecoder in pusch-Config and/or msg3-transformPrecoder .

In another embodiment, one bit field may be included in the Medium Access Control - Control Element (MAC-CE) to indicate enabling/disabling transform precoding for PUSCH transmission.

In another option, one bit field may be included in the MAC-CE to indicate enabling/disabling transform precoding for PUSCH transmission for a bandwidth part (BWP) and/or uplink carrier. The bit field may be indicated together with BWP index and/or uplink CC index in the MAC-CE to indicate the transform precoding for PUSCH transmission for the indicated BWP and/or uplink carrier.

In another option, a bitmap is included in the MAC CE where each bit in the bitmap is used to indicate enabling/disabling transform precoding for PUSCH transmission for all the BWPs and/or CCs for the UE or a configured set of BWPs and/or CCs, the bit index in the bitmap is determined in an increasing order of BWP and/or CC index.

In some aspects, if a UE receives a MAC CE for enabling/disabling transform precoding for PUSCH transmission, the UE applies the enabled or disabled transform precoding in the first slot that is after slot where k is the slot where the UE would transmit a PUCCH with HARQ-ACK information for the PDSCH providing the enabling/disabling transform precoding and p is the SCS configuration for the PUCCH.

In one option, when a UE receives the MAC CE, the UE applies the enabled or disabled transform precoding for the PUSCH transmissions, which includes the PUSCH transmission scheduled by DCI format 0 0, 0 1, or 0 2, or by a PDCCH with CRC scrambled by C-RNTI or CS-RNTI or SP-CSI-RNTI or MCS-C-RNTI, or with CRC scrambled by CS-RNTI with NDI=1, C-RNTI, or MCS-CRNTI or SP-CSI-RNTI, or Type 1 configured grant based PUSCH (CG- PUSCH) or Type 2 CG-PUSCH after the activation. For this option, UE may ignore the higher layer configured parameter msg3-transformPrecoder and/or transformPrecoder in pusch-Config.

In another option, when a UE receives the MAC CE, the UE applies the enabled or disabled transform precoding for the PUSCH transmissions, which includes the PUSCH transmission scheduled by DCI format 0 1, or 0 2, or by a PDCCH with CRC scrambled by C-RNTI or CS- RNTI or SP-CSI-RNTI or MCS-C-RNTI, or with CRC scrambled by CS-RNTI with NDI=1, C- RNTI, or MCS-CRNTI or SP-CSI-RNTI. For this option, UE may ignore the higher layer configured parameter msg3 -transformPrecoder and/or transformPrecoder in pusch-Config for the PUSCH scheduled by the above DCI format or PDCCH.

In another embodiment, when the UE would transmit a PUSCH corresponding to the DCI carrying indication for enabling/disabling transform precoding, the UE should apply enabled or disabled transform precoding for the PUSCH transmissions starting from the first slot that is at least N TP symbols or slots after the last symbol of the PUSCH transmission. The first slot and the symbols are both determined on the active BWP with the smallest SCS among the active BWP(s) of the carrier(s) applying the enabled or disabled transform precoding.

In some aspects, N TP can be configured by higher layers via RMSI, OSI, or RRC signalling or predefined in the specification.

In one option, when a UE receives the DCI carrying indication for enabling/disabling transform precoding, the UE applies the enabled or disabled transform precoding for the PUSCH transmissions, which includes the PUSCH transmission scheduled by DCI format 0 0, 0 1, or 0 2, or by a PDCCH with CRC scrambled by C-RNTI or CS-RNTI or SP-CSI-RNTI or MCS-C- RNTI, or with CRC scrambled by CS-RNTI with NDI=1, C-RNTI, or MCS-CRNTI or SP-CSI- RNTI, or Type 1 configured grant based PUSCH (CG-PUSCH) or Type 2 CG-PUSCH after the activation. For this option, UE may ignore the higher layer configured parameter msg3- transformPrecoder and/or transformPrecoder in pusch-Config.

In another option, when a UE receives the DCI carrying indication for enabling/disabling transform precoding, the UE applies the enabled or disabled transform precoding for the PUSCH transmissions, which includes the PUSCH transmission scheduled by DCI format 0 1, or 0 2, or by a PDCCH with CRC scrambled by C-RNTI or CS-RNTI or SP-CSI-RNTI or MCS-C-RNTI, or with CRC scrambled by CS-RNTI with NDI=1, C-RNTI, or MCS-CRNTI or SP-CSI-RNTI. For this option, UE may ignore the higher layer configured parameter msg3 -transformPrecoder and/or transformPrecoder in pusch-Config for the PUSCH scheduled by the above DCI format or PDCCH.

In another embodiment, for DCI format 0 0 or 0 1/0 2 carrying the indication for enabling/disabling transform precoding, enabled or disabled transform precoding could be applied for the PUSCH transmission scheduled by the same DCI. When determining the size of some DCI fields, and if the size is different for CP-OFDM and DFT-s-OFDM, the field size is determined by the larger size among the two waveforms. If the waveform with smaller DCI size is enabled for the PUSCH transmission, zero padding is applied, i.e., bits of value ‘0’ are inserted to the field to match with the larger size. In one option, the DCI size is matched with the size assuming CP- OFDM waveform is applied.

The DCI fields where the size could be different for CP-OFDM and DFT-s-OFDM at least include the following:

• Field of “Precoding information and number of layers”

• Field of “Antenna ports”

• Field of “PTRS-DMRS association”

• Field of “SRS resource indicator (SRI)”

• Field of “Second SRS resource indicator”

• Field of “Second Precoding information”

• Field of “Second PTRS-DMRS association”

• Field of “DMRS sequence initialization”

In some aspects, if multiple codewords (e.g., two codewords) are indicated and/or configured for uplink transmission, e.g., for CP-OFDM with rank larger than 4, then some DCI field(s) used for the second codeword should be always present in the DCI, and these fields should be ignored by the UE if DFT-s-OFDM waveform is indicated by the DCI. In one option, the DCI field(s) used for the second codeword could include: Modulation and coding scheme for the second codeword (or the second transport block), New data indicator for the second codeword (or the second transport block), Redundancy version for the second codeword (or the second transport block).

In some aspects, if multiple codewords (e.g., two codewords) are indicated and/or configured for uplink transmission, default waveform is CP-OFDM waveform. In this case, the UE may ignore the bit field for dynamic waveform indication in the DCI.

In some aspects, for the DCI fields, PTRS-DMRS association and DMRS sequence initialization, when the UE determines DFT-s-OFDM waveform or transform precoding is enabled for the scheduled PUSCH(s), the UE ignores the above bit field.

In some aspects, in RRC configuration, two sets of RRC parameters could be configured to the UE, one for CP-OFDM and the other one for DFT-s-OFDM. For example, two sets of DMRS-UplinkConfig could be configured to the UE, one for the DMRS configuration with CP- OFDM, one for the DMRS configuration with DFT-s-OFDM. In another embodiment, overall DCI size is determined in accordance with the maximum DCI size which is determined for CP-OFDM waveform and DFT-s-OFDM waveform. Further, waveform indication field may be included at the beginning of DCI format. In this case, DCI field size for each DCI field is determined in accordance with the indicated waveform type. In addition, zero padding is appended after all the DCI fields to match the maximum size determined from CP-OFDM waveform and DFT-s-OFDM waveform.

For this option, UE can determine the waveform in accordance with the indicated waveform type in the DCI format. Further, the UE can determine the corresponding DCI field size for the aforementioned DCI field based on the indicated waveform type.

In one example, waveform indication field may be included right after the carrier indicator field or prior to UL/SUL indicator field. Assuming the overall DCI size for CP-OFDM waveform is 60 bits, while the overall DCI size for DFT-s-OFDM waveform is 50 bits, and if the indicated waveform is DFT-s-OFDM waveform, zero padding is appended after all 50 bits for the DCI fields.

In another embodiment, for DCI format 0 0, or 0 1/0 2 without scheduling UL-SCH, or for DCI format 0 0, 0 1/0 2 without scheduling PUSCH but with SRS triggered, one field can be explicitly included to indicate enabling/disabling transform precoding for PUSCH transmission. Alternatively, without introducing new DCI field, some un-used field could be repurposed to indicate enabling/disabling transform precoding for PUSCH transmission. In one option, some specific field(s) value could be used for the validation of the DCI.

After successful reception of the DCI carrying the indication for enabling/disabling transform precoding, the UE should report ACK.

The enabling/disabling transform precoding should be applied for the subsequent PUSCH transmission after receiving the DCI. In one option, the enabling/disabling transform precoding could be applied for the subsequent PUSCH transmission after receiving the DCI until the next indication of enabling/disabling transform precoding is received.

The application time of enabling/disabling transform precoding could be introduced, after which the indicated waveform is applied for the PUSCH transmission. In one option, the application time is defined from the DCI until the UE starts to apply the indicated waveform for PUSCH transmission. In another option, the application time is defined from the UE sends ACK until the UE starts to apply the indicated waveform for PUSCH transmission.

For enabling/disabling transform precoding indicated by DCI format 0 0 or 0 1/0 2 without scheduling UL-SCH, or by DCI format 0 0 or 0 1/0 2 without scheduling PUSCH but with SRS triggered, the field size of DCI scheduling PUSCH transmission is determined by the applied waveform. In another embodiment, for DCI format 1 0 or 1 1/1 2 without downlink assignment, one field can be explicitly included to indicate enabling/disabling transform precoding for PUSCH transmission. Alternatively, without introducing new DCI field, some un-used fields could be repurposed to indicate enabling/disabling transform precoding for PUSCH transmission. In one option, some specific field(s) value could be used for the validation of the DCI.

After successful reception of the DCI carrying the indication for enabling/disabling transform precoding, the UE should report ACK.

The enabling/disabling transform precoding should be applied for the subsequent PUSCH transmission after receiving the DCI. In one option, the enabling/disabling transform precoding could be applied for the subsequent PUSCH transmission after receiving the DCI until the next indication of enabling/disabling transform precoding is received.

The application time of enabling/disabling transform precoding could be introduced, after which the indicated waveform is applied for the PUSCH transmission. In one option, the application time is defined from the DCI until the UE starts to apply the indicated waveform for PUSCH transmission. In another option, the application time is defined from the UE sends ACK until the UE starts to apply the indicated waveform for PUSCH transmission.

For enabling/disabling transform precoding indicated by DCI format 1 0 or 1 1/1 2 without downlink assignment, the field size of DCI scheduling PUSCH transmission is determined by the applied waveform.

In another embodiment, when pusch-TimeDomainAllocationListForMultiPUSCH or pusch-TimeDomainAllocationListForMultiPUSCH-rl7 is configured in pusch-Config, in one option, a single bit field is included in the DCI format, which indicates whether transform precoding is applied for all the scheduled PUSCH transmissions. In one example, when indicated time domain resource allocation (TDRA) includes more than one SLIVs or PUSCHs, the indicated waveform or enabling/disabling transform precoding can be applied for the more than one PUSCHs.

In another option, a single bit may be included in each row of pusch- TimeDomainAllocationListForMultiPUSCH or pusch-

TimeDomainAllocationListForMultiPUSCH-rl7, which is used to indicate whether transform precoding is applied for all the scheduled PUSCH transmissions.

In another option, separate indication on whether transform precoding is applied is included in each row of pusch-TimeDomainAllocationListForMultiPUSCH or pusch- TimeDomainAllocationListForMultiPUSCH-rl7, together with separate starting and length indicator value (SLIV). In this case, this bit field is used to indicate whether transform precoding is applied in each scheduled PUSCH. In another embodiment, for single DCI scheduling multi-slot PUSCH for multi-TRP operation, when two SRS resource sets are configured in srs-ResourceSetToAddModList or srs- ResourceSetToAddModListDCI-0-2 with higher layer parameter usage in SRS-ResourceSet set to 'codebook' or 'noncodebook', two bit fields on enabling/disabling transform precoding can be included in the DCI format, where the first and second bit fields are used to indicate whether transform precoding is applied for the scheduled PUSCHs targeting for the first TRP and second TRP, respectively.

In another option, for single DCI scheduling multi-slot PUSCH for multi-TRP operation, when two SRS resource sets are configured in srs-ResourceSetToAddModList or srs- ResourceSetToAddModListDCI-0-2 with higher layer parameter usage in SRS-ResourceSet set to 'codebook' or 'noncodebook', a single bit field is included in the DCI, which is used to indicate whether transform precoding is applied for the scheduled PUSCHs targeting for both the first TRP and second TRP.

In another embodiment, in case of multi -cell scheduling, where a DCI is used to schedule PUSCH transmissions in more than one cells, a single bit field is included in the DCI for multicell scheduling, which is used to indicate whether transform precoding is applied for the scheduled PUSCHs for the more than one carriers.

In some aspects, the single bit field is only applied for the carrier where dynamic waveform indication is configured or presence of dynamic waveform indication field in the DCI format 0 1 or 0 2 is configured by RRC signalling. In case when dynamic waveform indication is not configured or presence of dynamic waveform indication field in the DCI format 0 1 or 0 2 is not configured by RRC signalling for a carrier, the single bit field is not applied.

In another option, separate bit fields can be included in the DCI for multi -cell scheduling, where each bit field is used to indicate whether transform precoding is applied for the scheduled PUSCH in each carrier, respectively.

In some aspects, the size of waveform indication field can be determined in accordance with the maximum number of carriers among all rows of carrier indication table that is configured with dynamic waveform indication. In case when dynamic waveform indication is not configured or presence of dynamic waveform indication field in the DCI format 0 1 or 0 2 is not configured by RRC signalling for a carrier, waveform indication for the carrier is not included in the waveform indication field.

In one example, assuming 2 rows are configured for the carrier indication table, where first row is configured with {cell #0, cell #1 } and second row is configured with {cell#0, cell#2}, for cell #0 and cell #1, dynamic waveform indication is configured while for cell#2, dynamic waveform indication is not configured, in this case, waveform indication field size is 2. SYSTEMS AND IMPLEMENTATIONS

Figures 3-5 illustrate various systems, devices, and components that may implement aspects of disclosed embodiments.

Figure 3 illustrates a network 300 in accordance with various embodiments. The network 300 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G/NR systems. However, the example embodiments are not limited in this regard and the described embodiments may apply to other networks that benefit from the principles described herein, such as future 3 GPP systems, or the like.

The network 300 may include a UE 302, which may include any mobile or non-mobile computing device designed to communicate with a RAN 304 via an over-the-air connection. The UE 302 may be communicatively coupled with the RAN 304 by a Uu interface. The UE 302 may be, but is not limited to, a smartphone, tablet computer, wearable computer device, desktop computer, laptop computer, in-vehicle infotainment, in-car entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, loT device, etc.

In some embodiments, the network 300 may include a plurality of UEs coupled directly with one another via a sidelink interface. The UEs may be M2M/D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.

In some embodiments, the UE 302 may additionally communicate with an AP 306 via an over-the-air connection. The AP 306 may manage a WLAN connection, which may serve to offload some/all network traffic from the RAN 304. The connection between the UE 302 and the AP 306 may be consistent with any IEEE 802.11 protocol, wherein the AP 306 could be a wireless fidelity (Wi-Fi®) router. In some embodiments, the UE 302, RAN 304, and AP 306 may utilize cellular-WLAN aggregation (for example, LWA/LWIP). Cellular-WLAN aggregation may involve the UE 302 being configured by the RAN 304 to utilize both cellular radio resources and WLAN resources.

The RAN 304 may include one or more access nodes, for example, AN 308. AN 308 may terminate air-interface protocols for the UE 302 by providing access stratum protocols including RRC, PDCP, RLC, MAC, and LI protocols. In this manner, the AN 308 may enable data/voice connectivity between CN 320 and the UE 302. In some embodiments, the AN 308 may be implemented in a discrete device or as one or more software entities running on server computers as part of, for example, a virtual network, which may be referred to as a CRAN or virtual baseband unit pool. The AN 308 be referred to as a BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. The AN 308 may be a macrocell base station or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

In embodiments in which the RAN 304 includes a plurality of ANs, they may be coupled with one another via an X2 interface (if the RAN 304 is an LTE RAN) or an Xn interface (if the RAN 304 is a 5G RAN). The X2/Xn interfaces, which may be separated into control/user plane interfaces in some embodiments, may allow the ANs to communicate information related to handovers, data/context transfers, mobility, load management, interference coordination, etc.

The ANs of the RAN 304 may each manage one or more cells, cell groups, component carriers, etc. to provide the UE 302 with an air interface for network access. The UE 302 may be simultaneously connected with a plurality of cells provided by the same or different ANs of the RAN 304. For example, the UE 302 and RAN 304 may use carrier aggregation to allow the UE 302 to connect with a plurality of component carriers, each corresponding to a Pcell or Scell. In dual connectivity scenarios, a first AN may be a master node that provides an MCG and a second AN may be secondary node that provides an SCG. The first/second ANs may be any combination of eNB, gNB, ng-eNB, etc.

The RAN 304 may provide the air interface over a licensed spectrum or an unlicensed spectrum. To operate in the unlicensed spectrum, the nodes may use LAA, eLAA, and/or feLAA mechanisms based on CA technology with PCells/Scells. Prior to accessing the unlicensed spectrum, the nodes may perform medium/carrier-sensing operations based on, for example, a listen-before-talk (LBT) protocol.

In V2X scenarios the UE 302 or AN 308 may be or act as a RSU, which may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable AN or a stationary (or relatively stationary) UE. An RSU implemented in or by: a UE may be referred to as a “UE-type RSU”; an eNB may be referred to as an “eNB-type RSU”; a gNB may be referred to as a “gNB-type RSU”; and the like. In one example, an RSU is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications/software to sense and control ongoing vehicular and pedestrian traffic. The RSU may provide very low latency communications required for high speed events, such as crash avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU may provide other cellular/WLAN communications services. The components of the RSU may be packaged in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network.

In some embodiments, the RAN 304 may be an LTE RAN 310 with eNBs, for example, eNB 312. The LTE RAN 310 may provide an LTE air interface with the following characteristics: SCS of 15 kHz; CP-OFDM waveform for DL and SC-FDMA waveform for UL; turbo codes for data and TBCC for control; etc. The LTE air interface may rely on CSLRS for CSI acquisition and beam management; PDSCH/PDCCH DMRS for PDSCH/PDCCH demodulation; and CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation/detection at the UE. The LTE air interface may operating on sub-6 GHz bands.

In some embodiments, the RAN 304 may be an NG-RAN 314 with gNBs, for example, gNB 316, or ng-eNBs, for example, ng-eNB 318. The gNB 316 may connect with 5G-enabled UEs using a 5G NR interface. The gNB 316 may connect with a 5G core through an NG interface, which may include an N2 interface or an N3 interface. The ng-eNB 318 may also connect with the 5G core through an NG interface, but may connect with a UE via an LTE air interface. The gNB 316 and the ng-eNB 318 may connect with each other over an Xn interface.

In some embodiments, the NG interface may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between the nodes of the NG-RAN 314 and a UPF 348 (e.g., N3 interface), and an NG control plane (NG-C) interface, which is a signaling interface between the nodes of the NG-RAN314 and an AMF 344 (e.g., N2 interface).

The NG-RAN 314 may provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar, repetition, simplex, and Reed-Muller codes for control and LDPC for data. The 5G-NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS similar to the LTE air interface. The 5G-NR air interface may not use a CRS, but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signal for time tracking. The 5G-NR air interface may operating on FR1 bands that include sub-6 GHz bands or FR2 bands that include bands from 24.25 GHz to 52.6 GHz. The 5G-NR air interface may include an SSB that is an area of a downlink resource grid that includes PSS/SSS/PBCH.

In some embodiments, the 5G-NR air interface may utilize BWPs for various purposes. For example, BWP can be used for dynamic adaptation of the SCS. For example, the UE 302 can be configured with multiple BWPs where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 302, the SCS of the transmission is changed as well. Another use case example of BWP is related to power saving. In particular, multiple BWPs can be configured for the UE 302 with different amount of frequency resources (for example, PRBs) to support data transmission under different traffic loading scenarios. A BWP containing a smaller number of PRBs can be used for data transmission with small traffic load while allowing power saving at the UE 302 and in some cases at the gNB 316. A BWP containing a larger number of PRBs can be used for scenarios with higher traffic load.

The RAN 304 is communicatively coupled to CN 320 that includes network elements to provide various functions to support data and telecommunications services to customers/subscribers (for example, users of UE 302). The components of the CN 320 may be implemented in one physical node or separate physical nodes. In some embodiments, NFV may be utilized to virtualize any or all of the functions provided by the network elements of the CN 320 onto physical compute/storage resources in servers, switches, etc. A logical instantiation of the CN 320 may be referred to as a network slice, and a logical instantiation of a portion of the CN 320 may be referred to as a network sub-slice.

In some embodiments, the CN 320 may be an LTE CN 322, which may also be referred to as an EPC. The LTE CN 322 may include MME 324, SGW 326, SGSN 328, HSS 330, PGW 332, and PCRF 334 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the LTE CN 322 may be briefly introduced as follows.

The MME 324 may implement mobility management functions to track a current location of the UE 302 to facilitate paging, bearer activation/deactivation, handovers, gateway selection, authentication, etc.

The SGW 326 may terminate an SI interface toward the RAN and route data packets between the RAN and the LTE CN 322. The SGW 326 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.

The SGSN 328 may track a location of the UE 302 and perform security functions and access control. In addition, the SGSN 328 may perform inter-EPC node signaling for mobility between different RAT networks; PDN and S-GW selection as specified by MME 324; MME selection for handovers; etc. The S3 reference point between the MME 324 and the SGSN 328 may enable user and bearer information exchange for inter-3 GPP access network mobility in idle/active states.

The HSS 330 may include a database for network users, including subscription-related information to support the network entities’ handling of communication sessions. The HSS 330 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc. An S6a reference point between the HSS 330 and the MME 324 may enable transfer of subscription and authentication data for authenticating/authorizing user access to the LTE CN 320.

The PGW 332 may terminate an SGi interface toward a data network (DN) 336 that may include an application/content server 338. The PGW 332 may route data packets between the LTE CN 322 and the data network 336. The PGW 332 may be coupled with the SGW 326 by an S5 reference point to facilitate user plane tunneling and tunnel management. The PGW 332 may further include a node for policy enforcement and charging data collection (for example, PCEF). Additionally, the SGi reference point between the PGW 332 and the data network 3 36 may be an operator external public, a private PDN, or an intra-operator packet data network, for example, for provision of IMS services. The PGW 332 may be coupled with a PCRF 334 via a Gx reference point.

The PCRF 334 is the policy and charging control element of the LTE CN 322. The PCRF 334 may be communicatively coupled to the app/content server 338 to determine appropriate QoS and charging parameters for service flows. The PCRF 332 may provision associated rules into a PCEF (via Gx reference point) with appropriate TFT and QCI.

In some embodiments, the CN 320 may be a 5GC 340. The 5GC 340 may include an AUSF 342, AMF 344, SMF 346, UPF 348, NSSF 350, NEF 352, NRF 354, PCF 356, UDM 358, and AF 360 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the 5GC 340 may be briefly introduced as follows.

The AUSF 342 may store data for authentication of UE 302 and handle authentication- related functionality. The AUSF 342 may facilitate a common authentication framework for various access types. In addition to communicating with other elements of the 5GC 340 over reference points as shown, the AUSF 342 may exhibit an Nausf service-based interface.

The AMF 344 may allow other functions of the 5GC 340 to communicate with the UE 302 and the RAN 304 and to subscribe to notifications about mobility events with respect to the UE 302. The AMF 344 may be responsible for registration management (for example, for registering UE 302), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 344 may provide transport for SM messages between the UE 302 and the SMF 346, and act as a transparent proxy for routing SM messages. AMF 344 may also provide transport for SMS messages between UE 302 and an SMSF. AMF 344 may interact with the AUSF 342 and the UE 302 to perform various security anchor and context management functions. Furthermore, AMF 344 may be a termination point of a RAN CP interface, which may include or be an N2 reference point between the RAN 304 and the AMF 344; and the AMF 344 may be a termination point of NAS (Nl) signaling, and perform NAS ciphering and integrity protection. AMF 344 may also support NAS signaling with the UE 302 over an N3 IWF interface. The SMF 346 may be responsible for SM (for example, session establishment, tunnel management between UPF 348 and AN 308); UE IP address allocation and management (including optional authorization); selection and control of UP function; configuring traffic steering at UPF 348 to route traffic to proper destination; termination of interfaces toward policy control functions; controlling part of policy enforcement, charging, and QoS; lawful intercept (for SM events and interface to LI system); termination of SM parts of NAS messages; downlink data notification; initiating AN specific SM information, sent via AMF 344 over N2 to AN 308; and determining SSC mode of a session. SM may refer to management of a PDU session, and a PDU session or “session” may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE 302 and the data network 336.

The UPF 348 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point of interconnect to data network 336, and a branching point to support multi-homed PDU session. The UPF 348 may also perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for a user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF- to-QoS flow mapping), transport level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. UPF 348 may include an uplink classifier to support routing traffic flows to a data network.

The NSSF 350 may select a set of network slice instances serving the UE 302. The NSSF 350 may also determine allowed NSSAI and the mapping to the subscribed S-NSSAIs, if needed. The NSSF 350 may also determine the AMF set to be used to serve the UE 302, or a list of candidate AMFs based on a suitable configuration and possibly by querying the NRF 354. The selection of a set of network slice instances for the UE 302 may be triggered by the AMF 344 with which the UE 302 is registered by interacting with the NSSF 350, which may lead to a change of AMF. The NSSF 350 may interact with the AMF 344 via an N22 reference point; and may communicate with another NSSF in a visited network via an N31 reference point (not shown). Additionally, the NSSF 350 may exhibit an Nnssf service-based interface.

The NEF 352 may securely expose services and capabilities provided by 3 GPP network functions for third party, internal exposure/re-exposure, AFs (e.g., AF 360), edge computing or fog computing systems, etc. In such embodiments, the NEF 352 may authenticate, authorize, or throttle the AFs. NEF 352 may also translate information exchanged with the AF 360 and information exchanged with internal network functions. For example, the NEF 352 may translate between an AF-Service-Identifier and an internal 5GC information. NEF 352 may also receive information from other NFs based on exposed capabilities of other NFs. This information may be stored at the NEF 352 as structured data, or at a data storage NF using standardized interfaces. The stored information can then be re-exposed by the NEF 352 to other NFs and AFs, or used for other purposes such as analytics. Additionally, the NEF 352 may exhibit an Nnef service-based interface.

The NRF 354 may support service discovery functions, receive NF discovery requests from NF instances, and provide the information of the discovered NF instances to the NF instances. NRF 354 also maintains information of available NF instances and their supported services. As used herein, the terms “instantiate,” “instantiation,” and the like may refer to the creation of an instance, and an “instance” may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code. Additionally, the NRF 354 may exhibit the Nnrf service-based interface.

The PCF 356 may provide policy rules to control plane functions to enforce them, and may also support unified policy framework to govern network behavior. The PCF 356 may also implement a front end to access subscription information relevant for policy decisions in a UDR of the UDM 358. In addition to communicating with functions over reference points as shown, the PCF 356 exhibit an Npcf service-based interface.

The UDM 358 may handle subscription-related information to support the network entities’ handling of communication sessions, and may store subscription data of UE 302. For example, subscription data may be communicated via an N8 reference point between the UDM 358 and the AMF 344. The UDM 358 may include two parts, an application front end and a UDR. The UDR may store subscription data and policy data for the UDM 358 and the PCF 356, and/or structured data for exposure and application data (including PFDs for application detection, application request information for multiple UEs 302) for the NEF 352. The Nudr service-based interface may be exhibited by the UDR 221 to allow the UDM 358, PCF 356, and NEF 352 to access a particular set of the stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notification of relevant data changes in the UDR. The UDM may include a UDM- FE, which is in charge of processing credentials, location management, subscription management and so on. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification handling, access authorization, regi strati on/mobility management, and subscription management. In addition to communicating with other NFs over reference points as shown, the UDM 358 may exhibit the Nudm service-based interface.

The AF 360 may provide application influence on traffic routing, provide access to NEF, and interact with the policy framework for policy control.

In some embodiments, the 5GC 340 may enable edge computing by selecting operator/3 rd party services to be geographically close to a point that the UE 302 is attached to the network. This may reduce latency and load on the network. To provide edge-computing implementations, the 5GC 340 may select a UPF 348 close to the UE 302 and execute traffic steering from the UPF 348 to data network 336 via the N6 interface. This may be based on the UE subscription data, UE location, and information provided by the AF 360. In this way, the AF 360 may influence UPF (re)selection and traffic routing. Based on operator deployment, when AF 360 is considered to be a trusted entity, the network operator may permit AF 360 to interact directly with relevant NFs. Additionally, the AF 360 may exhibit an Naf service-based interface.

The data network 336 may represent various network operator services, Internet access, or third party services that may be provided by one or more servers including, for example, application/content server 338.

Figure 4 schematically illustrates a wireless network 400 in accordance with various embodiments. The wireless network 400 may include a UE 402 in wireless communication with an AN 404. The UE 402 and AN 404 may be similar to, and substantially interchangeable with, like-named components described elsewhere herein.

The UE 402 may be communicatively coupled with the AN 404 via connection 406. The connection 406 is illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols such as an LTE protocol or a 5G NR. protocol operating at mmWave or sub-6GHz frequencies.

The UE 402 may include a host platform 408 coupled with a modem platform 410. The host platform 408 may include application processing circuitry 412, which may be coupled with protocol processing circuitry 414 of the modem platform 410. The application processing circuitry 412 may run various applications for the UE 402 that source/sink application data. The application processing circuitry 412 may further implement one or more layer operations to transmit/receive application data to/from a data network. These layer operations may include transport (for example UDP) and Internet (for example, IP) operations

The protocol processing circuitry 414 may implement one or more of layer operations to facilitate transmission or reception of data over the connection 406. The layer operations implemented by the protocol processing circuitry 414 may include, for example, MAC, RLC, PDCP, RRC and NAS operations.

The modem platform 410 may further include digital baseband circuitry 416 that may implement one or more layer operations that are “below” layer operations performed by the protocol processing circuitry 414 in a network protocol stack. These operations may include, for example, PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/de-mapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, which may include one or more of space-time, space-frequency or spatial coding, reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.

The modem platform 410 may further include transmit circuitry 418, receive circuitry 420, RF circuitry 422, and RF front end (RFFE) 424, which may include or connect to one or more antenna panels 426. Briefly, the transmit circuitry 418 may include a digital -to-analog converter, mixer, intermediate frequency (IF) components, etc.; the receive circuitry 420 may include an analog-to-digital converter, mixer, IF components, etc.; the RF circuitry 422 may include a low-noise amplifier, a power amplifier, power tracking components, etc.; RFFE 424 may include filters (for example, surface/bulk acoustic wave filters), switches, antenna tuners, beamforming components (for example, phase-array antenna components), etc. The selection and arrangement of the components of the transmit circuitry 418, receive circuitry 420, RF circuitry 422, RFFE 424, and antenna panels 426 (referred generically as “transmit/receive components”) may be specific to details of a specific implementation such as, for example, whether communication is TDM or FDM, in mmWave or sub-6 gHz frequencies, etc. In some embodiments, the transmit/receive components may be arranged in multiple parallel transmit/receive chains, may be disposed in the same or different chips/modules, etc.

In some embodiments, the protocol processing circuitry 414 may include one or more instances of control circuitry (not shown) to provide control functions for the transmit/receive components.

A UE reception may be established by and via the antenna panels 426, RFFE 424, RF circuitry 422, receive circuitry 420, digital baseband circuitry 416, and protocol processing circuitry 414. In some embodiments, the antenna panels 426 may receive a transmission from the AN 404 by receive-beamforming signals received by a plurality of antennas/antenna elements of the one or more antenna panels 426.

A UE transmission may be established by and via the protocol processing circuitry 414, digital baseband circuitry 416, transmit circuitry 418, RF circuitry 422, RFFE 424, and antenna panels 426. In some embodiments, the transmit components of the UE 404 may apply a spatial filter to the data to be transmitted to form a transmit beam emitted by the antenna elements of the antenna panels 426.

Similar to the UE 402, the AN 404 may include a host platform 428 coupled with a modem platform 430. The host platform 428 may include application processing circuitry 432 coupled with protocol processing circuitry 434 of the modem platform 430. The modem platform may further include digital baseband circuitry 436, transmit circuitry 438, receive circuitry 440, RF circuitry 442, RFFE circuitry 444, and antenna panels 446. The components of the AN 404 may be similar to and substantially interchangeable with like-named components of the UE 402. In addition to performing data transmission/reception as described above, the components of the AN 408 may perform various logical functions that include, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

Figure 5 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, Figure 5 shows a diagrammatic representation of hardware resources 500 including one or more processors (or processor cores) 510, one or more memory/storage devices 520, and one or more communication resources 530, each of which may be communicatively coupled via a bus 540 or other interface circuitry. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 502 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 500.

The processors 510 may include, for example, a processor 512 and a processor 514. The processors 510 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio-frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

The memory/storage devices 520 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices 520 may include, but are not limited to, any type of volatile, non-volatile, or semi-volatile memory such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.

The communication resources 530 may include interconnection or network interface controllers, components, or other suitable devices to communicate with one or more peripheral devices 504 or one or more databases 506 or other network elements via a network 508. For example, the communication resources 530 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, Bluetooth® (or Bluetooth® Low Energy) components, Wi-Fi® components, and other communication components.

Instructions 550 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 510 to perform any one or more of the methodologies discussed herein. The instructions 550 may reside, completely or partially, within at least one of the processors 510 (e.g., within the processor’s cache memory), the memory/storage devices 520, or any suitable combination thereof. Furthermore, any portion of the instructions 550 may be transferred to the hardware resources 500 from any combination of the peripheral devices 504 or the databases 506. Accordingly, the memory of processors 510, the memory/storage devices 520, the peripheral devices 504, and the databases 506 are examples of computer-readable and machine-readable media.

EXAMPLE PROCEDURES

In some embodiments, the electronic device(s), network(s), system(s), chip(s) or component(s), or portions or implementations thereof, of Figures 3-5, or some other figure herein, may be configured to perform one or more processes, techniques, or methods as described herein, or portions thereof. One such process 600 is depicted in Figure 6. In some embodiments, the process 600 may be performed by a UE or a portion thereof. At 602, the process 600 may include decoding a downlink control information (DCI) that schedules a physical uplink shared channel (PUSCH), wherein the DCI includes a field to indicate whether transform precoding is enabled or disabled for the PUSCH. At 604, the process 600 may further include encoding the PUSCH for transmission based on the field.

In some embodiments, the DCI is a DCI format 0 0, a DCI format 0 1, or a DCI format 0 2. Furthermore, in some embodiments, the DCI has a cyclic redundancy check (CRC) scrambled by a cell (C) - radio network temporary identifier (RNTI), a configured scheduling (CS)-RNTI, a semi-persistent - channel state information (SP-CSI)-RNTI, or a modulation and coding scheme (MCS)-C-RNTI.

Figure 7 illustrates another example process 700 in accordance with various embodiments. In some embodiments, the process 700 may be performed by a gNB or a portion thereof. At 702, the process 700 may include encoding, for transmission to a user equipment (UE), a downlink control information (DCI) that schedules a physical uplink shared channel (PUSCH), wherein the DCI includes a field to indicate whether transform precoding is enabled or disabled for the PUSCH. At 704, the process 700 may further include decoding the PUSCH based on the field.

In some embodiments, the DCI is a DCI format 0 0, a DCI format 0 1, or a DCI format 0 2. Furthermore, in some embodiments, the DCI has a cyclic redundancy check (CRC) scrambled by a cell (C) - radio network temporary identifier (RNTI), a configured scheduling (CS)-RNTI, a semi -persistent - channel state information (SP-CSI)-RNTI, or a modulation and coding scheme (MCS)-C-RNTI.

Figure 8 illustrates another example process 800 in accordance with various embodiments. In some embodiments, the process 800 may be performed by a UE or a portion thereof. At 802, the process 800 may include receiving a random access response (RAR) message with an uplink (UL) grant for a Msg3 and an indication of whether transform precoding is enabled or disabled for the Msg3. In some embodiments, the indication may be in a designated field and/or may use one or more bits of a field that also encodes other information (e.g., by repurposing an existing field). At 804, the process 800 may further include transmitting the Msg3 in accordance with the indication.

For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and/or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.

EXAMPLES

Some non-limiting examples of various embodiments are described further below.

Example Al may include one or more non-transitory computer-readable media (NTCRM) having instructions, stored thereon, that when executed by one or more processors of a user equipment (UE) configure the UE to: decode a downlink control information (DCI) that schedules a physical uplink shared channel (PUSCH), wherein the DCI includes a field to indicate whether transform precoding is enabled or disabled for the PUSCH; and encode the PUSCH for transmission based on the field.

Example A2 may include the one or more NTCRM of example Al, wherein the DCI is a DCI format 0 0, a DCI format 0 1, or a DCI format 0 2.

Example A3 may include the one or more NTCRM of example Al, wherein the DCI has a cyclic redundancy check (CRC) scrambled by a cell (C) - radio network temporary identifier (RNTI), a configured scheduling (CS)-RNTI with a new data indicator having a value of 1, or a modulation and coding scheme (MCS)-C-RNTI.

Example A4 may include the one or more NTCRM of example Al, wherein the field is one bit.

Example A5 may include the one or more NTCRM of any one of examples A1-A4, wherein the instructions, when executed, are further to configure the UE to receive configuration information to indicate whether the field is to be present in the DCI.

Example A6 may include the one or more NTCRM of example Al, wherein the PUSCH is included in a Msg3 of a random access procedure.

Example A7 may include the one or more NTCRM of example Al, wherein the PUSCH is a first PUSCH, wherein the DCI schedules multiple PUSCHs in a cell including the first PUSCH, and wherein the field indicates whether transform precoding is enabled or disabled for all of the multiple PUSCHs.

Example A8 may include the one or more NTCRM of example Al, wherein the field is a first field, and wherein to decode the DCI includes to determine a size of a second field of the DCI as a larger of a first size that is used for a cyclic prefix (CP)-orthogonal frequency division multiplexing (OFDM) waveform and a second size that is used for a discrete Fourier transform (DFT)-spread (s)-OFDM waveform.

Example A9 may include the one or more NTCRM of example Al, wherein to decode the DCI includes to determine an overall size of the DCI as a larger of a first DCI size that is used for a cyclic prefix (CP)-orthogonal frequency division multiplexing (OFDM) waveform and a second DCI size that is used for a discrete Fourier transform (DFT)-spread (s)-OFDM waveform.

Example A10 may include the one or more NTCRM of example A9, wherein the field is at the beginning of the DCI to indicate whether the DCI corresponds to the CP-OFDM waveform or the DFT-s-OFDM waveform.

Example Al 1 may include one or more non-transitory computer-readable media (NTCRM) having instructions, stored thereon, that when executed by one or more processors of a next generation Node B (gNB) configure the gNB to: encode, for transmission to a user equipment (UE), a downlink control information (DCI) that schedules a physical uplink shared channel (PUSCH), wherein the DCI includes a field to indicate whether transform precoding is enabled or disabled for the PUSCH; and decode the PUSCH based on the field.

Example A12 may include the one or more NTCRM of example Al l, wherein the DCI is a DCI format 0 0, a DCI format 0 1, or a DCI format 0 2.

Example A13 may include the one or more NTCRM of example Al l, wherein the DCI has a cyclic redundancy check (CRC) scrambled by a cell (C) - radio network temporary identifier (RNTI), a configured scheduling (CS)-RNTI with a new data indicator having a value of 1, or a modulation and coding scheme (MCS)-C-RNTI. Example A14 may include the one or more NTCRM of example Al l, wherein the field is one bit.

Example Al 5 may include the one or more NTCRM of any one of examples Al 1-A14, wherein the instructions, when executed, are further to configure the gNB to transmit configuration information to the UE to indicate whether the field is to be present in the DCI.

Example Al 6 may include the one or more NTCRM of example Al l, wherein the PUSCH is included in a Msg3 of a random access procedure.

Example Al 7 may include the one or more NTCRM of example Al l, wherein the PUSCH is a first PUSCH, wherein the DCI schedules multiple PUSCHs in a cell including the first PUSCH, and wherein the field indicates whether transform precoding is enabled or disabled for all of the multiple PUSCHs.

Example Al 8 may include the one or more NTCRM of example Al l, wherein the field is a first field, and wherein to encode the DCI includes to determine a size of a second field of the DCI as a larger of a first size that is used for a cyclic prefix (CP)-orthogonal frequency division multiplexing (OFDM) waveform and a second size that is used for a discrete Fourier transform (DFT)-spread (s)-OFDM waveform.

Example Al 9 may include the one or more NTCRM of example Al l, wherein to encode the DCI includes to determine an overall size of the DCI as a larger of a first DCI size that is used for a cyclic prefix (CP)-orthogonal frequency division multiplexing (OFDM) waveform and a second DCI size that is used for a discrete Fourier transform (DFT)-spread (s)-OFDM waveform.

Example A20 may include the one or more NTCRM of example A 19, wherein the DCI includes a waveform indication field at the beginning of the DCI to indicate whether the DCI corresponds to the CP-OFDM waveform or the DFT-s-OFDM waveform.

Example A21 may include one or more non-transitory computer-readable media (NTCRM) having instructions, stored thereon, that when executed by one or more processors of a user equipment (UE) configure the UE to: receive a random access response (RAR) message with an uplink (UL) grant for a Msg3 and an indication of whether transform precoding is enabled or disabled for the Msg3; and transmit the Msg3 in accordance with the indication.

Example A22 may include the one or more NTCRM of example A21, wherein the indication is provided by a bit of a designated field or a bit of a field that also encodes other information.

Example A23 may include the one or more NTCRM of example A22, wherein the field is a transmit power control (TPC) command field, a channel state information (CSI) request field, a physical uplink shared channel (PUSCH) frequency resource allocation field, or a PUSCH time resource allocation field.

Example A24 may include the one or more NTCRM of example A21, wherein the indication is based on a time domain resource allocation (TDRA) table, wherein individual rows of the TDRA table include the indication of whether transform precoding is enabled or disabled, a K2 value, a mapping type, and a starting and length indicator value (SLIV).

Example A25 may include the one or more NTCRM of any one of examples A21-A24, wherein the Msg3 is transmitted using a cyclic prefix (CP)-orthogonal frequency division multiplexing (OFDM) waveform or a discrete Fourier transform (DFT)-spread (s)-OFDM waveform based on the indication.

Example B 1 may include a method of wireless communication for a fifth generation (5G) or new radio (NR) system, the method including: receiving, by a UE from a gNB, a transform precoding indication in a random access response (RAR) uplink grant for Msg3 initial transmission; and transmitting, by the UE, Msg3 initial transmission in accordance with the indicated transform precoding indication.

Example B2 may include the method of Example Bl or some other example herein, wherein enabling/disabling transform precoding for CP-OFDM and DFT-s-OFDM waveform generation can be indicated in the RAR UL grant for Msg3 initial transmission.

Example B3 may include the method of Example Bl or some other example herein, wherein one most significant bit (MSB) of transmit power control (TPC) command for PUSCH can be repurposed for transform precoding indication.

Example B4 may include the method of Example Bl or some other example herein, wherein CSI request may be repurposed for transform precoding indication, wherein whether to enable CSI request or transform precoding indication in the RAR UL grant may be configured by higher layers via RMSI.

Example B5 may include the method of Example Bl or some other example herein, wherein 1 MSB of PUSCH frequency resource allocation can be repurposed for transform precoding indication.

Example B6 may include the method of Example Bl or some other example herein, wherein enabling/disabling transform precoding may be indicated by PUSCH time resource allocation.

Example B7 may include the method of Example B6 or some other example herein, wherein a new TDRA table may be defined, where each row of the TDRA table may include enabling/disabling transform precoding, K2, mapping type, starting and length indicator value (SLIV). Example B8 may include the method of Example Bl or some other example herein, wherein one or more states in one or more field or reserved state in the RAR UL grant may be used to indicate enabling/disabling transform precoding for Msg3 initial transmission.

Example B9 may include the method of Example Bl or some other example herein, wherein enabling/disabling transform precoding for CP-OFDM and DFT-s-OFDM waveform generation of Msg3 retransmission can be explicitly indicated in the DCI format 0 0 with CRC scrambled by TC-RNTI.

Example BIO may include the method of Example Bl or some other example herein, wherein the above embodiments for enabling/disabling transform precoding for Msg3 initial transmission can apply for that for Msg3 retransmission.

Example Bl 1 may include the method of Example Bl or some other example herein, wherein “New data indicator” or “HARQ process number” fields which are reserved in the DCI format 0 0 with CRC scrambled by a TC-RNTI can be repurposed to indicate enabling/disabling transform precoding for Msg3 retransmission.

Example B 12 may include the method of Example Bl or some other example herein, wherein in case of Msg3 PUSCH repetition for initial transmission and retransmission, e.g., the number of repetitions is greater than 1, a default transform precoding or waveform can be applied for Msg3 repetition.

Example B 13 may include the method of Example Bl or some other example herein, wherein for DCI format 0 0 with CRC scrambled by C-RNTI or CS-RNTI or MCS-C-RNTI, one bit field can be explicitly included to indicate enabling/disabling transform precoding for PUSCH transmission.

Example B 14 may include the method of Example B13 or some other example herein, wherein whether this field is present in the DCI format 0 0 with CRC scrambled by C-RNTI or CS-RNTI or MCS-C-RNTI can be configured by higher layers via RMSI, OSI, or RRC signalling.

Example B 15 may include the method of Example Bl or some other example herein, wherein for DCI format 0 1 and 0 2 with CRC scrambled by C-RNTI or CS-RNTI or SP-CSI- RNTI or MCS-C-RNTI, one field can be explicitly included to indicate enabling/disabling transform precoding for PUSCH transmission.

Example B 16 may include the method of Example B15 or some other example herein, wherein whether this field is present in the DCI format 0 1 and 0 2 with CRC scrambled by C- RNTI or CS-RNTI or SP-CSI-RNTI or MCS-C-RNTI can be configured by higher layers via RMSI, OSI, or RRC signalling.

Example B 17 may include the method of Example Bl or some other example herein, wherein explicit indication in the RAR UL grant, DCI format 0 0, 0 1, or 0 2 may be used to indicate that the transform precoding which is configured by transformPrecoder in pusch-Config and/or msg3 -transformPrecoder is reverted.

Example B 18 may include the method of Example Bl or some other example herein, wherein a separate RNTI may be configured by higher layers via RRC signalling, and when DCI format 0 0, 0 1 and 0 2 with CRC scrambled with the separate RNTI, this may indicate that transform precoding which is configured by transformPrecoder in pusch-Config and/or msg3- transformPrecoder is reverted.

Example B 19 may include the method of Example Bl or some other example herein, wherein for PUSCH repetition type A or type B when the number of repetitions is greater than 1, or for TBoMS when the number of slots for TBS determination is great than 1 regardless of whether repetitions is employed, transform precoding may be enabled by default, e.g., default waveform may be employed as DFT-s-OFDM waveform.

Example B20 may include the method of Example Bl or some other example herein, wherein when SUL is triggered for PUSCH transmission, e.g., UL/SUL indicator is indicated as “1” in the DCI format 0 0, 0 1 or 0 2, transform precoding may be enabled by default, e.g., default waveform may be employed as DFT-s-OFDM waveform.

Example B21 may include the method of Example Bl or some other example herein, wherein one bit field may be included in the MAC-CE to indicate enabling/disabling transform precoding for PUSCH transmission for a bandwidth part (BWP) and/or uplink carrier, wherein the bit field may be indicated together with BWP index and/or uplink CC index in the MAC-CE to indicate the transform precoding for PUSCH transmission for the indicated BWP and/or uplink carrier.

Example B22 may include the method of Example Bl or some other example herein, wherein if a UE receives a MAC CE for enabling/disabling transform precoding for PUSCH transmission, the UE applies the enabled or disabled transform precoding in the first slot that is after slot k + w here the UE would transmit a PUCCH with HARQ-ACK information for the PDSCH providing the enabling/disabling transform precoding and is the SCS configuration for the PUCCH.

Example B23 may include the method of Example Bl or some other example herein, wherein a UE receives the MAC CE, the UE applies the enabled or disabled transform precoding for the PUSCH transmissions, which includes the PUSCH transmission scheduled by DCI format 0 0, 0 1, or 0 2, or by a PDCCH with CRC scrambled by C-RNTI or CS-RNTI or SP- CSI-RNTI or MCS-C-RNTI, or with CRC scrambled by CS-RNTI with NDI=1, C-RNTI, or MCS-CRNTI or SP-CSI-RNTI, or Type 1 configured grant based PUSCH (CG-PUSCH) or Type 2 CG-PUSCH after the activation.

Example B24 may include the method of Example Bl or some other example herein, wherein when a UE receives the MAC CE, the UE applies the enabled or disabled transform precoding for the PUSCH transmissions, which includes the PUSCH transmission scheduled by DCI format 0 1, or 0 2, or by a PDCCH with CRC scrambled by C-RNTI or CS-RNTI or SP- CSI-RNTI or MCS-C-RNTI, or with CRC scrambled by CS-RNTI with NDI=1, C-RNTI, or MCS-CRNTI or SP-CSI-RNTI.

Example B25 may include the method of Example Bl or some other example herein, wherein when the UE would transmit a PUSCH corresponding to the DCI carrying indication for enabling/disabling transform precoding, the UE should apply enabled or disabled transform precoding for the PUSCH transmissions starting from the first slot that is at least N_TP symbols or slots after the last symbol of the PUSCH transmission. The first slot and the symbols are both determined on the active BWP with the smallest SCS among the active BWP(s) of the carrier(s) applying the enabled or disabled transform precoding.

Example B26 may include the method of Example Bl or some other example herein, wherein when determining the size of some DCI fields, and if the size is different for CP-OFDM and DFT-s-OFDM, the field size is determined by the larger size among the two waveforms.

Example B27 may include the method of Example Bl or some other example herein, wherein for DCI format 0 0, or 0 1/0 2 without scheduling UL-SCH, or for DCI format 0 0, 0 1/0 2 without scheduling PUSCH but with SRS triggered, one field can be explicitly included to indicate enabling/disabling transform precoding for PUSCH transmission

Example B28 may include the method of Example Bl or some other example herein, wherein for DCI format 1 0 or 1 1/1 2 without downlink assignment, one field can be explicitly included to indicate enabling/disabling transform precoding for PUSCH transmission

Example B29 may include the method of Example Bl or some other example herein, wherein the DCI size is matched with the size assuming CP-OFDM waveform is applied.

Example B30 may include the method of Example Bl or some other example herein, wherein when pusch-TimeDomainAllocationListForMultiPUSCH or pusch- TimeDomainAllocationListForMultiPUSCH-rl7 is configured in pusch-Config, in one option, a single bit field is included in the DCI format, which indicates whether transform precoding is applied for all the scheduled PUSCH transmissions.

Example B31 may include the method of Example Bl or some other example heren, wherein for single DCI scheduling multi-slot PUSCH for multi-TRP operation, when two SRS resource sets are configured in srs-ResourceSetToAddModList or srs- ResourceSetToAddModListDCI-0-2 with higher layer parameter usage in SRS-ResourceSet set to 'codebook' or 'noncodebook', two bit fields on enabling/disabling transform precoding can be included in the DCI format, where the first and second bit fields are used to indicate whether transform precoding is applied for the scheduled PUSCHs targeting for the first TRP and second TRP, respectively.

Example B32 may include in some aspects, the size of waveform indication field can be determined in accordance with the maximum number of carriers among all rows of carrier indication table that is configured with dynamic waveform indication. In case when dynamic waveform indication is not configured or presence of dynamic waveform indication field in the DCI format 0 1 or 0 2 is not configured by RRC signalling for a carrier, waveform indication for the carrier is not included in the waveform indication field.

Example B33 may include one example, assuming 2 rows are configured for the carrier indication table, where first row is configured with {cell #0, cell #1 } and second row is configured with {cell#0, cell#2}, for cell #0 and cell #1, dynamic waveform indication is configured while for cell#2, dynamic waveform indication is not configured, in this case, waveform indication field size is 2.

Example B34 may include a method of a user equipment (UE), the method comprising: receiving a random access response (RAR) message with an uplink (UL) grant and an indication of transform precoding; and transmitting a Msg3 in accordance with the indicated transform precoding.

Example B35 may include the method of Example B34 or some other example herein, wherein the indication enables or disables transform precoding for waveform generation for the Msg3.

Example B36 may include the method of Example B35 or some other example herein, wherein the Msg3 is transmitted using a CP-OFDM or DFT-s-OFDM waveform.

Example B37 may include the method of Example B34-36 or some other example herein, wherein the indication corresponds to a bit (e.g., a most significant bit (MSB)) of a transmit power control (TPC) command for a physical uplink shared channel (PUSCH).

Example B38 may include the method of Example B34-36 or some other example herein, wherein the indication corresponds to a C SI request field of the RAR message.

Example B39 may include the method of Example B38 or some other example herein, further comprising receiving configuration information to indicate whether the CSI request field is to be used for transform precoding indication.

Example B40 may include the method of Example B33-36 or some other example herein, wherein the indication corresponds to a bit (e.g., a MSB) of a PUSCH frequency resource allocation. Example B41 may include the method of Example B34-36 or some other example herein, wherein the indication corresponds to a PUSCH time resource allocation.

Example B42 may include the method of Example B41 or some other example herein, wherein the indication is based on a time domain resource allocation (TDRA) table, wherein individual rows of the TDRA table include the indication of whether transform precoding is enabled or disabled, K2, mapping type, and starting and length indicator value (SLIV).

Example B43 may include the method of Example B34-42 or some other example herein, wherein the indication is included in a DCI format 0 0 with CRC scrambled by a temporary cell radio network temporary identifier (TC-RNTI).

Example B44 may include the method of Example B34-43 or some other example herein, wherein the Msg3 transmission is an initial transmission.

Example B45 may include the method of Example B34-43 or some other example herein, wherein the Msg3 transmission is a re-transmission.

Example B46 may include the method of Example B34-45 or some other example herein, further comprising receiving a DCI that enables or disables transform precoding for a PUSCH; and transmitting the PUSCH based on the DCI.

Example B47 may include the method of Example B46 or some other example herein, wherein the DCI is a DCI format 0 0, a DCI format 0 1, or a DCI format 0 2.

Example B48 may include the method of Example B46 or some other example herein, wherein the DCI has a CRC scrambled by C-RNTI, CS-RNTI, SP-CSI-RNTI, or MCS-C-RNTI.

Example B49 may include the method of Example B47-48 or some other example herein, wherein the DCI includes a one bit field to enable or disable transform precoding.

Example B50a may include the method of Example B49 or some other example herein, further comprising receiving configuration information to indicate whether the one bit field is to be present in the DCI.

Example B50b may include the method of Example B34-50a or some other example herein, wherein the DCI is included in a Msg4 of a random access procedure.

Example B50c may include the method of Example B34-50a or some other example herein, wherein the PUSCH is included in the Msg3.

Example B50d may include the method of Example B46-50c or some other example herein, wherein the DCI size is matched assuming CP-OFDM waveform is applied.

Example B50e may include the method of Example B46-50d or some other example herein, wherein when pusch-TimeDomainAllocationListForMultiPUSCH or pusch- TimeDomainAllocationListForMultiPUSCH-rl7 is configured in pusch-Config, the DCI includes a single bit field to indicate whether transform precoding is applied for all scheduled PUSCH transmissions.

Example B50f may include the method of Example B34-50e or some other example herein, wherein two SRS resource sets are configured with a usage of 'codebook' or 'noncodebook', and wherein the method further comprises receiving a single DCI to schedule a multi-slot PUSCH for multi-TRP operation, wherein the DCI includes two or more bit fields to indicate whether transform precoding is applied for scheduled PUSCHs targeting respective TRPs.

Example B50g may include the method of Example B34-50f, in some aspects, the size of waveform indication field can be determined in accordance with the maximum number of carriers among all rows of carrier indication table that is configured with dynamic waveform indication. In case when dynamic waveform indication is not configured or presence of dynamic waveform indication field in the DCI format 0 1 or 0 2 is not configured by RRC signalling for a carrier, waveform indication for the carrier is not included in the waveform indication field.

Example B50h may include the method of Example B34-50g, wherein, assuming 2 rows are configured for the carrier indication table, where first row is configured with {cell #0, cell #1 } and second row is configured with {cell#0, cell#2}, for cell #0 and cell #1, dynamic waveform indication is configured while for cell#2, dynamic waveform indication is not configured, in this case, waveform indication field size is 2.

Example B51 may include a method of a next generation Node B (gNB), the method comprising: transmitting, to a user equipment, a random access response (RAR) message with an uplink (UL) grant and an indication of transform precoding; and receiving a Msg3 from the UE in accordance with the indicated transform precoding.

Example B52 may include the method of Example B51 or some other example herein, wherein the indication enables or disables transform precoding for waveform generation for the Msg3.

Example B53 may include the method of Example B52 or some other example herein, wherein the Msg3 is transmitted using a CP-OFDM or DFT-s-OFDM waveform.

Example B54 may include the method of Example B51-53 or some other example herein, wherein the indication corresponds to a bit (e.g., a most significant bit (MSB)) of a transmit power control (TPC) command for a physical uplink shared channel (PUSCH).

Example B55 may include the method of Example B51-53 or some other example herein, wherein the indication corresponds to a C SI request field of the RAR message.

Example B56 may include the method of Example B55 or some other example herein, further comprising transmitting, to the UE, configuration information to indicate whether the CSI request field is to be used for transform precoding indication.

Example B57 may include the method of Example B51-56 or some other example herein, wherein the indication corresponds to a bit (e.g., a MSB) of a PUSCH frequency resource allocation.

Example B58 may include the method of Example B51-57 or some other example herein, wherein the indication corresponds to a PUSCH time resource allocation.

Example B59 may include the method of Example B58 or some other example herein, wherein the indication is based on a time domain resource allocation (TDRA) table, wherein individual rows of the TDRA table include the indication of whether transform precoding is enabled or disabled, K2, mapping type, and starting and length indicator value (SLIV).

Example B60 may include the method of Example B51-59 or some other example herein, wherein the indication is included in a DCI format 0 0 with CRC scrambled by a temporary cell radio network temporary identifier (TC-RNTI).

Example B61 may include the method of Example B51-60 or some other example herein, wherein the Msg3 transmission is an initial transmission.

Example B62 may include the method of Example B51-60 or some other example herein, wherein the Msg3 transmission is a re-transmission.

Example B63 may include the method of Example B51-62 or some other example herein, further comprising transmitting a DCI that enables or disables transform precoding for a PUSCH; and receiving the PUSCH according to the DCI.

Example B64 may include the method of Example B63 or some other example herein, wherein the DCI is a DCI format 0 0, a DCI format 0 1, or a DCI format 0 2.

Example B65 may include the method of Example B64 or some other example herein, wherein the DCI has a CRC scrambled by C-RNTI, CS-RNTI, SP-CSI-RNTI, or MCS-C-RNTI.

Example B66 may include the method of Example B63-64 or some other example herein, wherein the DCI includes a one bit field to enable or disable transform precoding.

Example B67 may include the method of Example B66 or some other example herein, further comprising receiving configuration information to indicate whether the one bit field is to be present in the DCI.

Example B68 may include the method of Example B62-67 or some other example herein, wherein the DCI is included in a Msg4 of a random access procedure.

Example B69 may include the method of Example B62-67 or some other example herein, wherein the PUSCH is included in the Msg3.

Example B70 may include a method of a UE, the method comprising: receiving a DCI that includes an indication of supplementary uplink (SUL) for PUSCH transmission; and transmitting the PUSCH using transform precoding based on the indication.

Example B71 may include the method of Example B68, wherein the DCI has a DCI format 0_0, 0_l or 0_2.

Example B72 may include a method of a UE, the method comprising: receiving a MAC-CE that indicates whether transform precoding is enabled or disabled for a PUSCH; and transmitting the PUSCH based on the indication.

Example B73 may include the method of Example B72 or some other example herein, wherein the indication corresponds to a bandwidth part (BWP) and/or an uplink carrier.

Example B74 may include the method of Example B73 or some other example herein, wherein the indication includes a BWP index and/or an uplink CC index for the corresponding BWP and/or uplink carrier.

Example B75 may include the method of Example B72-74 or some other example herein, wherein the transmitting further comprises applying the enabled or disabled transform precoding in the first slot that is after slot k + g^ubframe,// j s t h e sjot w h ere the pjp would transmit a PUCCH with HARQ-ACK information for the PDSCH providing the enabling/disabling transform precoding and /J. is the SCS configuration for the PUCCH.

Example B76 may include the method of Example B72-74 or some other example herein, wherein the PUSCH is scheduled by DCI format 0 0, 0 1, or 0 2, or by a PDCCH with CRC scrambled by C-RNTI or CS-RNTI or SP-CSI-RNTI or MCS-C-RNTI, or with CRC scrambled by CS-RNTI with NDI=1, C-RNTI, or MCS-CRNTI or SP-CSI-RNTI, or Type 1 configured grant based PUSCH (CG-PUSCH) or Type 2 CG-PUSCH after the activation.

Example B77 may include the method of Example B72-74 or some other example herein, wherein the PUSCH is scheduled by DCI format 0 1, or 0 2, or by a PDCCH with CRC scrambled by C-RNTI or CS-RNTI or SP-CSI-RNTI or MCS-C-RNTI, or with CRC scrambled by CS-RNTI with NDI=1, C-RNTI, or MCS-CRNTI or SP-CSI-RNTI.

Example B78 may include the method of Example B72-77 or some other example herein, further comprising applying the enabled or disabled transform precoding for the PUSCH transmission starting from a first slot that is at least N_TP symbols or slots after the last symbol of the PUSCH transmission.

Example B79 may include the method of Example B78 or some other example herein, wherein the first slot and the symbols are determined on the active BWP with the smallest SCS among the active BWP(s) of the carrier(s) applying the enabled or disabled transform precoding. Example B80 may include a method of a UE, the method comprising: receiving a DCI to schedule multiple PUSCHs, wherein the DCI indicates whether transform precoding is to be applied for the PUSCHs; and encoding the PUSCHs for transmission based on the DCI.

Example B81 may include the method of Example B80 or some other example herein, wherein the PUSCHs are scheduled in multiple cells.

Example B82 may include the method of Example B81 or some other example herein, wherein the DCI includes a single bit to indicate whether transform precoding is to be applied for all of the PUSCHs.

Example B83 may include the method of Example B81 or some other example herein, wherein the DCI includes separate bit fields to indicate whether transform precoding is to be applied for the PUSCHs in respective cells.

Example B84 may include the method of Example B80 or some other example herein, wherein the PUSCHs are targeted to multiple TRPs and multiple SRS resource sets are configured with a usage of codebook or non-codebook.

Example B85 may include the method of Example B84 or some other example herein, wherein the DCI includes a single bit to indicate whether transform precoding is to be applied for all of the PUSCHs.

Example B86 may include the method of Example B84 or some other example herein, wherein the DCI includes separate bit fields to indicate whether transform precoding is to be applied for the PUSCHs targeted to the respective TRPs.

Example B87 may include the method of Example B80 or some other example herein, wherein the DCI includes a single bit to indicate whether transform precoding is to be applied for all of the PUSCHs.

Example B88 may include the method of Example B80 or some other example herein, wherein the DCI includes multiple bit fields to indicate whether transform precoding is to be applied for respective subsets of one or more of the PUSCHs.

Example B89 may include the method of Example B88 or some other example herein, wherein the subsets correspond to PUSCHs that are transmitted in respective cells or targeted to respective TRPs.

Example B90 may include the method of Example B80-89 or some other example herein, wherein the DCI includes a waveform indication field, and wherein a size of the waveform indication field is determined in accordance with a maximum number of carriers among all rows of a carrier indication table that is configured with dynamic waveform indication. Example B91 may include the method of Example B90 or some other example herein, wherein 2 rows (a first row and a second row) are configured for the carrier indication table, wherein the first row is configured with {cell #0, cell #1 } and the second row is configured with {cell#0, cell#2}, wherein dynamic waveform indication is configured for cell #0 and cell #1, wherein dynamic waveform indication is not configured for cell#2, and wherein the size of the waveform indication is 2.

Example Z01 may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples A1-A25, B1-B91, or any other method or process described herein.

Example Z02 may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples A1-A25, B1-B91, or any other method or process described herein.

Example Z03 may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples A1-A25, B1-B91, or any other method or process described herein.

Example Z04 may include a method, technique, or process as described in or related to any of examples A1-A25, B1-B91, or portions or parts thereof.

Example Z05 may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples A1-A25, B1-B91, or portions thereof.

Example Z06 may include a signal as described in or related to any of examples A1-A25, B1-B91, or portions or parts thereof.

Example Z07 may include a datagram, packet, frame, segment, protocol data unit (PDU), or message as described in or related to any of examples A1-A25, B1-B91, or portions or parts thereof, or otherwise described in the present disclosure.

Example Z08 may include a signal encoded with data as described in or related to any of examples A1-A25, B1-B91, or portions or parts thereof, or otherwise described in the present disclosure.

Example Z09 may include a signal encoded with a datagram, packet, frame, segment, protocol data unit (PDU), or message as described in or related to any of examples A1-A25, Bl- B91, or portions or parts thereof, or otherwise described in the present disclosure.

Example Z10 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is to cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples A1-A25, B1-B91, or portions thereof.

Example Z11 may include a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out the method, techniques, or process as described in or related to any of examples A1-A25, Bl- B91, or portions thereof.

Example Z12 may include a signal in a wireless network as shown and described herein.

Example Z13 may include a method of communicating in a wireless network as shown and described herein.

Example Z14 may include a system for providing wireless communication as shown and described herein.

Example Z15 may include a device for providing wireless communication as shown and described herein.

Any of the above-described examples may be combined with any other example (or combination of examples), unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

Abbreviations

Unless used differently herein, terms, definitions, and abbreviations may be consistent with terms, definitions, and abbreviations defined in 3GPP TR 21.905 vl6.0.0 (2019-06). For the purposes of the present document, the following abbreviations may apply to the examples and embodiments discussed herein.

3 GPP Third AO A Angle of Shift Keying Generation Arrival BRAS Broadband

Partnership AP Application Remote Access Project Protocol, Antenna Server 4G Fourth 40 Port, Access Point 75 BSS Business Generation API Application Support System 5G Fifth Programming Interface BS Base Station Generation APN Access Point BSR Buffer Status 5GC 5G Core Name Report network 45 ARP Allocation and 80 BW Bandwidth AC Retention Priority BWP Bandwidth Part

Application ARQ Automatic C-RNTI Cell Client Repeat Request Radio Network

ACR Application AS Access Stratum Temporary Context Relocation 50 ASP 85 Identity ACK Application Service CA Carrier

Acknowledgem Provider Aggregation, ent Certification ACID ASN.l Abstract Syntax Authority

Application 55 Notation One 90 CAPEX CAPital Client Identification AUSF Authentication Expenditure AF Application Server Function CBD Candidate Function AWGN Additive Beam Detection

AM Acknowledged White Gaussian CBRA Contention Mode 60 Noise 95 Based Random

AMBRAggregate BAP Backhaul Access Maximum Bit Rate Adaptation Protocol CC Component AMF Access and BCH Broadcast Carrier, Country

Mobility Channel Code, Cryptographic

Management 65 BER Bit Error Ratio 100 Checksum Function BFD Beam CCA Clear Channel AN Access Failure Detection Assessment Network BLER Block Error CCE Control ANR Automatic Rate Channel Element

Neighbour Relation 70 BPSK Binary Phase 105 CCCH Common Control Channel Management System Redundancy Check CE Coverage CO Conditional CRI Channel-State Enhancement Optional Information CDM Content CoMP Coordinated Resource Delivery Network 40 Multi-Point 75 Indicator, CSI-RS CDMA Code- CORESET Control Resource Division Multiple Resource Set Indicator Access COTS Commercial C-RNTI Cell

CDR Charging Data Off-The-Shelf RNTI Request 45 CP Control Plane, 80 CS Circuit

CDR Charging Data Cyclic Prefix, Switched Response Connection CSCF call

CFRA Contention Free Point session control function Random Access CPD Connection CSAR Cloud Service CG Cell Group 50 Point Descriptor 85 Archive CGF Charging CPE Customer CSI Channel-State

Gateway Function Premise Information CHF Charging Equipment CSI-IM CSI

Function CPICHCommon Pilot Interference

CI Cell Identity 55 Channel 90 Measurement CID Cell-ID (e g., CQI Channel CSI-RS CSI positioning method) Quality Indicator Reference Signal CIM Common CPU CSI processing CSI-RSRP CSI Information Model unit, Central reference signal CIR Carrier to 60 Processing Unit 95 received power Interference Ratio C/R CSI-RSRQ CSI CK Cipher Key Command/Resp reference signal CM Connection onse field bit received quality Management, CRAN Cloud Radio CSI-SINR CSI

Conditional 65 Access 100 signal -to-noise and Mandatory Network, Cloud interference CMAS Commercial RAN ratio Mobile Alert Service CRB Common CSMA Carrier Sense CMD Command Resource Block Multiple Access CMS Cloud 70 CRC Cyclic 105 CSMA/CA CSMA with collision Access Identifier (GSM Evolution) avoidance EAS Edge

CSS Common DRB Data Radio Application Server

Search Space, CellBearer EASID Edge specific Search 40 DRS Discovery 75 Application Server

Space Reference Signal Identification

CTF Charging DRX Discontinuous ECS Edge

Trigger Function Reception Configuration Server

CTS Clear-to-Send DSL Domain ECSP Edge

CW Codeword 45 Specific Language. 80 Computing Service

CWS Contention Digital Provider

Window Size Subscriber Line EDN Edge

D2D Device-to- DSLAM DSL Data Network

Device Access Multiplexer EEC Edge

DC Dual 50 DwPTS 85 Enabler Client

Connectivity, Direct Downlink Pilot EECID Edge

Current Time Slot Enabler Client

DCI Downlink E-LAN Ethernet Identification

Control Local Area Network EES Edge

Information 55 E2E End-to-End 90 Enabler Server

DF Deployment EAS Edge EESID Edge

Flavour Application Server Enabler Server

DL Downlink ECCA extended clear Identification

DMTF Distributed channel EHE Edge

Management Task 60 assessment, 95 Hosting Environment

Force extended CCA EGMF Exposure

DPDK Data Plane ECCE Enhanced Governance

Development Kit Control Channel Management

DM-RS, DMRS Element, Function

Demodulation 65 Enhanced CCE 100 EGPRS

Reference Signal ED Energy Enhanced

DN Data network Detection GPRS

DNN Data Network EDGE Enhanced EIR Equipment

Name Datarates for GSM Identity Register

DNAI Data Network 70 Evolution 105 eLAA enhanced Licensed Assisted Tsunami Warning Block

Access, System FBI Feedback enhanced LAA eUICC embedded Information EM Element UICC, embedded FCC Federal Manager 40 Universal 75 Communications eMBB Enhanced Integrated Circuit Commission Mobile Card FCCH Frequency

Broadband E-UTRA Evolved Correction CHannel

EMS Element UTRA FDD Frequency Management System 45 E-UTRAN Evolved 80 Division Duplex eNB evolved NodeB, UTRAN FDM Frequency E-UTRAN Node B EV2X Enhanced V2X Division EN-DC E- F1AP Fl Application Multiplex UTRA-NR Dual Protocol FDMA F requency Connectivity 50 Fl-C Fl Control 85 Division Multiple

EPC Evolved Packet plane interface Access Core Fl-U Fl User plane FE Front End EPDCCH interface FEC Forward Error enhanced FACCH Fast Correction PDCCH, enhanced 55 Associated Control 90 FFS For Further Physical CHannel Study

Downlink Control FACCH/F Fast FFT Fast Fourier

Cannel Associated Control Transformation

EPRE Energy per Channel/Full feLAA further resource element 60 rate 95 enhanced Licensed EPS Evolved Packet FACCH/H Fast Assisted System Associated Control Access, further

EREG enhanced REG, Channel/Half enhanced LAA enhanced resource rate FN Frame Number element groups 65 FACH Forward Access 100 FPGA Field- ETSI European Channel Programmable Gate

Telecommunica FAUSCH Fast Array tions Standards Uplink Signalling FR Frequency Institute Channel Range

ETW S Earthquake and 70 FB Functional 105 FQDN Fully Qualified Domain System HN Home Network Name GPRS General Packet HO Handover

G-RNTI GERAN Radio Service HPLMN Home

Radio Network GPSI Generic Public Land Mobile

Temporary 40 Public Subscription 75 Network Identity Identifier HSDPA High GERAN GSM Global System Speed Downlink

GSM EDGE for Mobile Packet Access RAN, GSM EDGE Communication HSN Hopping

Radio Access 45 s, Groupe Special 80 Sequence Number

Network Mobile HSPA High Speed

GGSN Gateway GPRS GTP GPRS Packet Access Support Node Tunneling Protocol HSS Home GLONASS GTP-UGPRS Subscriber Server

GLObal'naya 50 Tunnelling Protocol 85 HSUPA High

NAvigatsionnay for User Plane Speed Uplink Packet a Sputnikovaya GTS Go To Sleep Access Si sterna (Engl.: Signal (related HTTP Hyper Text Global Navigation to WUS) Transfer Protocol

Satellite 55 GUMMEI Globally 90 HTTPS Hyper

System) Unique MME Text Transfer Protocol gNB Next Identifier Secure (https is Generation NodeB GUTI Globally http/ 1.1 over gNB-CU gNB- Unique Temporary SSL, i.e. port 443) centralized unit, Next 60 UE Identity 95 I-Block

Generation HARQ Hybrid ARQ, Information

NodeB Hybrid Block centralized unit Automatic ICCID Integrated gNB-DU gNB- Repeat Request Circuit Card distributed unit, Next 65 HANDO Handover 100 Identification

Generation HFN HyperFrame IAB Integrated

NodeB Number Access and distributed unit HHO Hard Handover Backhaul

GNSS Global HLR Home Location ICIC Inter-Cell Navigation Satellite 70 Register 105 Interference Coordination Equipment Network ID Identity, Identity ISIM IM Services identifier IMGI International Identity Module IDFT Inverse Discrete mobile group identity ISO International Fourier 40 IMPI IP Multimedia 75 Organisation for

Transform Private Identity Standardisation IE Information IMPU IP Multimedia ISP Internet Service element PUblic identity Provider IBE In-Band IMS IP Multimedia IWF Interworking- Emission 45 Subsystem 80 Function IEEE Institute of IMSI International I-WLAN Electrical and Mobile Interworking

Electronics Subscriber WLAN Engineers Identity Constraint IEI Information 50 loT Internet of 85 length of the Element Things convolutional

Identifier IP Internet code, USIM IEIDL Information Protocol Individual key Element Ipsec IP Security, kB Kilobyte (1000

Identifier Data 55 Internet Protocol 90 bytes) Length Security kbps kilo-bits per IETF Internet IP-CAN IP- second Engineering Task Connectivity Access Kc Ciphering key Force Network Ki Individual

IF Infrastructure 60 IP-M IP Multicast 95 subscriber IIOT Industrial IPv4 Internet authentication Internet of Things Protocol Version 4 key IM Interference IPv6 Internet KPI Key Measurement, Protocol Version 6 Performance Indicator

Intermodulation 65 IR Infrared 100 KQI Key Quality , IP Multimedia IS In Sync Indicator IMC IMS IRP Integration KSI Key Set Credentials Reference Point Identifier IMEI International ISDN Integrated ksps kilo-symbols Mobile 70 Services Digital 105 per second KVM Kernel Virtual PLMN MANO Machine LPP LTE Management LI Layer 1 Positioning Protocol and Orchestration (physical layer) LSB Least MBMS Ll-RSRP Layer 1 40 Significant Bit 75 Multimedia reference signal LTE Long Term Broadcast and received power Evolution Multicast L2 Layer 2 (data LWA LTE-WLAN Service link layer) aggregation MBSFN L3 Layer 3 45 LWIP LTE/WLAN 80 Multimedia (network layer) Radio Level Broadcast LAA Licensed Integration with multicast Assisted Access IPsec Tunnel service Single LAN Local Area LTE Long Term Frequency Network 50 Evolution 85 Network LADN Local M2M Machine-to- MCC Mobile Country Area Data Network Machine Code LBT Listen Before MAC Medium Access MCG Master Cell Talk Control Group LCM LifeCycle 55 (protocol 90 MCOT Maximum Management layering context) Channel LCR Low Chip Rate MAC Message Occupancy LCS Location authentication code Time Services (security/ encrypti on MCS Modulation and LCID Logical 60 context) 95 coding scheme Channel ID MAC-A MAC MD AF Management LI Layer Indicator used for Data Analytics LLC Logical Link authentication Function Control, Low Layer and key MD AS Management Compatibility 65 agreement 100 Data Analytics LMF Location (TSG T WG3 context) Service

Management Function MAC-IMAC used for MDT Minimization of LOS Line of data integrity of Drive Tests

Sight signalling messages ME Mobile LPLMN Local 70 (TSG T WG3 context) 105 Equipment MeNB master eNB Shared mMTCmassive MTC, MER Message Error CHannel massive Ratio MPRACH MTC Machine-Type MGL Measurement Physical Random Communication Gap Length 40 Access 75 s MGRP Measurement CHannel MU-MIMO Multi Gap Repetition MPUSCH MTC User MIMO Period Physical Uplink Shared MWUS MTC MIB Master Channel wake-up signal, MTC Information Block, 45 MPLS MultiProtocol 80 WUS Management Label Switching NACK Negative

Information Base MS Mobile Station Acknowledgement MIMO Multiple Input MSB Most NAI Network Multiple Output Significant Bit Access Identifier MLC Mobile 50 MSC Mobile 85 NAS Non-Access Location Centre Switching Centre Stratum, Non- Access MM Mobility MSI Minimum Stratum layer Management System NCT Network MME Mobility Information, Connectivity Management Entity 55 MCH Scheduling 90 Topology MN Master Node Information NC-JT NonMNO Mobile MSID Mobile Station coherent Joint Network Operator Identifier Transmission MO Measurement MSIN Mobile Station NEC Network

Object, Mobile 60 Identification 95 Capability

Originated Number Exposure MPBCH MTC MSISDN Mobile NE-DC NR-E-

Physical Broadcast Subscriber ISDN UTRA Dual CHannel Number Connectivity

MPDCCH MTC 65 MT Mobile 100 NEF Network Physical Downlink Terminated, Mobile Exposure Function Control Termination NF Network

CHannel MTC Machine-Type Function

MPDSCH MTC Communication NFP Network Physical Downlink 70 s 105 Forwarding Path NFPD Network Physical Assistance

Forwarding Path Downlink Information

Descriptor Shared CHannel S-NNSAI Single-

NFV Network NPRACH NSSAI

Functions 40 Narrowband 75 NSSF Network Slice

Virtualization Physical Random Selection Function

NFVI NFV Access CHannel NW Network

Infrastructure NPUSCH NWU SNarrowband

NF VO NFV Narrowband wake-up signal,

Orchestrator 45 Physical Uplink 80 N arrowb and WU S

NG Next Shared CHannel NZP Non-Zero

Generation, Next Gen NPSS Narrowband Power

NGEN-DC NG- Primary O&M Operation and

RAN E-UTRA-NR Synchronization Maintenance

Dual Connectivity 50 Signal 85 ODU2 Optical channel

NM Network NSSS Narrowband Data Unit - type 2

Manager Secondary OFDM Orthogonal

NMS Network Synchronization Frequency Division

Management System Signal Multiplexing

N-PoP Network Point 55 NR New Radio, 90 OFDMA of Presence Neighbour Relation Orthogonal

NMIB, N-MIB NRF NF Repository Frequency Division

Narrowband MIB Function Multiple Access

NPBCH NRS Narrowband OOB Out-of-band

Narrowband 60 Reference Signal 95 OOS Out of

Physical NS Network Sync

Broadcast Service OPEX OPerating

CHannel NS A Non- Standalone EXpense

NPDCCH operation mode OSI Other System

Narrowband 65 NSD Network 100 Information

Physical Service Descriptor OSS Operations

Downlink NSR Network Support System

Control CHannel Service Record OTA over-the-air

NPDSCH NSSAINetwork Slice PAPR Peak-to-

Narrowband 70 Selection 105 Average Power Ratio Convergence Protocol POC PTT over

PAR Peak to PDN Packet Data Cellular

Average Ratio Network, Public PP, PTP Point-to-

PBCH Physical Data Network Point Broadcast Channel 40 PDSCH Physical 75 PPP Point-to-Point

PC Power Control, Downlink Shared Protocol

Personal Channel PRACH Physical

Computer PDU Protocol Data RACH

PCC Primary Unit PRB Physical Component Carrier, 45 PEI Permanent 80 resource block Primary CC Equipment PRG Physical

P-CSCF Proxy Identifiers resource block

CSCF PFD Packet Flow group

PCell Primary Cell Description ProSe Proximity

PCI Physical Cell 50 P-GW PDN Gateway 85 Services,

ID, Physical Cell PHICH Physical Proximity- Identity hybrid-ARQ indicator Based Service

PCEF Policy and channel PRS Positioning

Charging PHY Physical layer Reference Signal

Enforcement 55 PLMN Public Land 90 PRR Packet

Function Mobile Network Reception Radio

PCF Policy Control PIN Personal PS Packet Services Function Identification Number PSBCH Physical

PCRF Policy Control PM Performance Sidelink Broadcast and Charging Rules 60 Measurement 95 Channel Function PMI Precoding PSDCH Physical

PDCP Packet Data Matrix Indicator Sidelink Downlink

Convergence PNF Physical Channel

Protocol, Packet Network Function PSCCH Physical

Data Convergence 65 PNFD Physical 100 Sidelink Control Protocol layer Network Function Channel

PDCCH Physical Descriptor PSSCH Physical

Downlink Control PNFR Physical Sidelink Shared

Channel Network Function Channel

PDCP Packet Data 70 Record 105 PSFCH physical sidelink feedback Access RNTI Control, Radio channel RAB Radio Access Link Control

PSCell Primary SCell Bearer, Random layer

PSS Primary Access Burst RLC AM RLC

Synchronization 40 RACH Random Access 75 Acknowledged Mode

Signal Channel RLC UM RLC

PSTN Public Switched RADIUS Remote Unacknowledged

Telephone Network Authentication Dial Mode

PT-RS Phase-tracking In User Service RLF Radio Link reference signal 45 RAN Radio Access 80 Failure

PTT Push-to-Talk Network RLM Radio Link

PUCCH Physical RAND RANDom Monitoring

Uplink Control number (used for RLM-RS

Channel authentication) Reference

PUSCH Physical 50 RAR Random Access 85 Signal for RLM

Uplink Shared Response RM Registration

Channel RAT Radio Access Management

QAM Quadrature Technology RMC Reference

Amplitude RAU Routing Area Measurement Channel

Modulation 55 Update 90 RMSI Remaining

QCI QoS class of RB Resource block, MSI, Remaining identifier Radio Bearer Minimum

QCL Quasi coRBG Resource block System location group Information

QFI QoS Flow ID, 60 REG Resource 95 RN Relay Node

QoS Flow Element Group RNC Radio Network

Identifier Rel Release Controller

QoS Quality of REQ REQuest RNL Radio Network

Service RF Radio Layer

QPSK Quadrature 65 Frequency 100 RNTI Radio Network

(Quaternary) Phase RI Rank Indicator Temporary

Shift Keying RIV Resource Identifier

QZSS Quasi-Zenith indicator value ROHC RObust Header

Satellite System RL Radio Link Compression

RA-RNTI Random 70 RLC Radio Link 105 RRC Radio Resource Control, Radio S-GW Serving Context

Resource Control Gateway Management layer S-RNTI SRNC SCS Subcarrier

RRM Radio Resource Radio Network Spacing

Management 40 Temporary 75 SC TP Stream Control

RS Reference Identity Transmission

Signal S-TMSI SAE Protocol

RSRP Reference Temporary Mobile SDAP Service Data

Signal Received Station Adaptation

Power 45 Identifier 80 Protocol,

RSRQ Reference SA Standalone Service Data

Signal Received operation mode Adaptation

Quality SAE System Protocol layer

RS SI Received Signal Architecture SDL Supplementary Strength 50 Evolution 85 Downlink

Indicator SAP Service Access SDNF Structured Data

RSU Road Side Unit Point Storage Network RSTD Reference SAPD Service Access Function Signal Time Point Descriptor SDP Session difference 55 SAPI Service Access 90 Description Protocol

RTP Real Time Point Identifier SDSF Structured Data Protocol SCC Secondary Storage Function

RTS Ready-To-Send Component Carrier, SDT Small Data RTT Round Trip Secondary CC Transmission Time 60 SCell Secondary Cell 95 SDU Service Data

Rx Reception, SCEF Service Unit Receiving, Receiver Capability Exposure SEAF Security S1AP SI Application Function Anchor Function Protocol SC-FDMA Single SeNB secondary eNB

Sl-MME SI for 65 Carrier Frequency 100 SEPP Security Edge the control plane Division Protection Proxy Sl-U SI for the user Multiple Access SFI Slot format plane SCG Secondary Cell indication

S-CSCF serving Group SFTD Space- CSCF 70 SCM Security 105 Frequency Time Diversity, SFN SN Secondary Continuity and frame timing Node, Sequence SS-RSRP difference Number Synchronization

SFN System Frame SoC System on Chip Signal based Number 40 SON Self-Organizing 75 Reference

SgNB Secondary gNB Network Signal Received SGSN Serving GPRS SpCell Special Cell Power Support Node SP-CSI-RNTISemi- SS-RSRQ

S-GW Serving Persistent CSI RNTI Synchronization Gateway 45 SPS Semi-Persistent 80 Signal based

SI System Scheduling Reference Information SQN Sequence Signal Received

SI-RNTI System number Quality

Information RNTI SR Scheduling SS-SINR

SIB System 50 Request 85 Synchronization Information Block SRB Signalling Signal based Signal

SIM Subscriber Radio Bearer to Noise and Identity Module SRS Sounding Interference Ratio SIP Session Reference Signal SSS Secondary

Initiated Protocol 55 SS Synchronization 90 Synchronization

SiP System in Signal Signal Package SSB Synchronization SSSG Search Space

SL Sidelink Signal Block Set Group

SLA Service Level SSID Service Set SSSIF Search Space

Agreement 60 Identifier 95 Set Indicator SM Session SS/PBCH Block SST Slice/Service Management SSBRI SS/PBCH Types SMF Session Block Resource SU-MIMO Single

Management Function Indicator, User MIMO SMS Short Message 65 Synchronization 100 SUL Supplementary Service Signal Block Uplink

SMSF SMS Function Resource TA Timing SMTC S SB-based Indicator Advance, Tracking Measurement Timing SSC Session and Area

Configuration 70 Service 105 TAC Tracking Area Code Network Layer Management

TAG Timing TPC Transmit Power UDP User Datagram Advance Group Control Protocol TAI TPMI Transmitted UDSF Unstructured

Tracking Area 40 Precoding Matrix 75 Data Storage Network Identity Indicator Function

TAU Tracking Area TR Technical UICC Universal Update Report Integrated Circuit

TB Transport Block TRP, TRxP Card TBS Transport Block 45 Transmission 80 UL Uplink Size Reception Point UM

TBD To Be Defined TRS Tracking Unacknowledge

TCI Transmission Reference Signal d Mode

Configuration TRx Transceiver UML Unified

Indicator 50 TS Technical 85 Modelling Language

TCP Transmission Specifications, UMTS Universal

Communication Technical Mobile

Protocol Standard Tel ecommuni ca

TDD Time Division TTI Transmission tions System

Duplex 55 Time Interval 90 UP User Plane

TDM Time Division Tx Transmission, UPF User Plane Multiplexing Transmitting, Function

TDMATime Division Transmitter URI Uniform

Multiple Access U-RNTI UTRAN Resource Identifier

TE Terminal 60 Radio Network 95 URL Uniform

Equipment Temporary Resource Locator

TEID Tunnel End Identity URLLC Ultra¬

Point Identifier UART Universal Reliable and Low

TFT Traffic Flow Asynchronous Latency

Template 65 Receiver and 100 USB Universal Serial

TMSI Temporary Transmitter Bus

Mobile UCI Uplink Control USIM Universal

Subscriber Information Subscriber Identity

Identity UE User Equipment Module

TNL Transport 70 UDM Unified Data 105 USS UE-specific search space VoIP Voice-over-IP, UTRA UMTS Voice-over- Internet Terrestrial Radio Protocol

Access VPLMN Visited

UTRAN 40 Public Land Mobile

Universal Network Terrestrial Radio VPN Virtual Private

Access Network

Network VRB Virtual

UwPTS Uplink 45 Resource Block Pilot Time Slot WiMAX V2I Vehicle-to- Worldwide Infrastruction Interoperability V2P Vehicle-to- for Microwave Pedestrian 50 Access

V2V Vehicle-to- WLANWireless Local Vehicle Area Network

V2X Vehicle-to- WMAN Wireless everything Metropolitan Area

VIM Virtualized 55 Network Infrastructure Manager WPANWireless VL Virtual Link, Personal Area Network VLAN Virtual LAN, X2-C X2-Control Virtual Local Area plane Network 60 X2-U X2-User plane VM Virtual XML extensible Machine Markup

VNF Virtualized Language Network Function XRES EXpected user

VNFFG VNF 65 RESponse

Forwarding Graph XOR exclusive OR VNFFGD VNF ZC Zadoff-Chu

Forwarding Graph ZP Zero Power

Descriptor VNFMVNF Manager Terminology

For the purposes of the present document, the following terms and definitions are applicable to the examples and embodiments discussed herein.

The term “application” may refer to a complete and deployable package, environment to achieve a certain function in an operational environment. The term “AI/ML application” or the like may be an application that contains some AI/ML models and application-level descriptions.

The term “circuitry” as used herein refers to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable SoC), digital signal processors (DSPs), etc., that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

The term “processor circuitry” as used herein refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, and/or transferring digital data. Processing circuitry may include one or more processing cores to execute instructions and one or more memory structures to store program and data information. The term “processor circuitry” may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computerexecutable instructions, such as program code, software modules, and/or functional processes. Processing circuitry may include more hardware accelerators, which may be microprocessors, programmable processing devices, or the like. The one or more hardware accelerators may include, for example, computer vision (CV) and/or deep learning (DL) accelerators. The terms “application circuitry” and/or “baseband circuitry” may be considered synonymous to, and may be referred to as, “processor circuitry.”

The term “interface circuitry” as used herein refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces, for example, buses, I/O interfaces, peripheral component interfaces, network interface cards, and/or the like.

The term “user equipment” or “UE” as used herein refers to a device with radio communication capabilities and may describe a remote user of network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Furthermore, the term “user equipment” or “UE” may include any type of wireless/wired device or any computing device including a wireless communications interface.

The term “network element” as used herein refers to physical or virtualized equipment and/or infrastructure used to provide wired or wireless communication network services. The term “network element” may be considered synonymous to and/or referred to as a networked computer, networking hardware, network equipment, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, and/or the like.

The term “computer system” as used herein refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” and/or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” and/or “system” may refer to multiple computer devices and/or multiple computing systems that are communicatively coupled with one another and configured to share computing and/or networking resources.

The term “appliance,” “computer appliance,” or the like, as used herein refers to a computer device or computer system with program code (e.g., software or firmware) that is specifically designed to provide a specific computing resource. A “virtual appliance” is a virtual machine image to be implemented by a hypervisor-equipped device that virtualizes or emulates a computer appliance or otherwise is dedicated to provide a specific computing resource.

The term “resource” as used herein refers to a physical or virtual device, a physical or virtual component within a computing environment, and/or a physical or virtual component within a particular device, such as computer devices, mechanical devices, memory space, processor/CPU time, processor/CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input/output operations, ports or network sockets, channel/link allocation, throughput, memory usage, storage, network, database and applications, workload units, and/or the like. A “hardware resource” may refer to compute, storage, and/or network resources provided by physical hardware element(s). A “virtualized resource” may refer to compute, storage, and/or network resources provided by virtualization infrastructure to an application, device, system, etc. The term “network resource” or “communication resource” may refer to resources that are accessible by computer devices/systems via a communications network. The term “system resources” may refer to any kind of shared entities to provide services, and may include computing and/or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.

The term “channel” as used herein refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term “channel” may be synonymous with and/or equivalent to “communications channel,” “data communications channel,” “transmission channel,” “data transmission channel,” “access channel,” “data access channel,” “link,” “data link,” “carrier,” “radiofrequency carrier,” and/or any other like term denoting a pathway or medium through which data is communicated. Additionally, the term “link” as used herein refers to a connection between two devices through a RAT for the purpose of transmitting and receiving information.

The terms “instantiate,” “instantiation,” and the like as used herein refers to the creation of an instance. An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code.

The terms “coupled,” “communicatively coupled,” along with derivatives thereof are used herein. The term “coupled” may mean two or more elements are in direct physical or electrical contact with one another, may mean that two or more elements indirectly contact each other but still cooperate or interact with each other, and/or may mean that one or more other elements are coupled or connected between the elements that are said to be coupled with each other. The term “directly coupled” may mean that two or more elements are in direct contact with one another. The term “communicatively coupled” may mean that two or more elements may be in contact with one another by a means of communication including through a wire or other interconnect connection, through a wireless communication channel or link, and/or the like.

The term “information element” refers to a structural element containing one or more fields. The term “field” refers to individual contents of an information element, or a data element that contains content.

The term “SMTC” refers to an SSB-based measurement timing configuration configured by SSB-MeasurementTimingConfiguration .

The term “SSB” refers to an SS/PBCH block. The term “a “Primary Cell” refers to the MCG cell, operating on the primary frequency, in which the UE either performs the initial connection establishment procedure or initiates the connection re-establishment procedure.

The term “Primary SCG Cell” refers to the SCG cell in which the UE performs random access when performing the Reconfiguration with Sync procedure for DC operation.

The term “Secondary Cell” refers to a cell providing additional radio resources on top of a Special Cell for a UE configured with CA.

The term “Secondary Cell Group” refers to the subset of serving cells comprising the PSCell and zero or more secondary cells for a UE configured with DC.

The term “Serving Cell” refers to the primary cell for a UE in RRC CONNECTED not configured with CA/DC there is only one serving cell comprising of the primary cell.

The term “serving cell” or “serving cells” refers to the set of cells comprising the Special Cell(s) and all secondary cells for a UE in RRC CONNECTED configured with CA/.

The term “Special Cell” refers to the PCell of the MCG or the PSCell of the SCG for DC operation; otherwise, the term “Special Cell” refers to the Pcell.

The term “machine learning” or “ML” refers to the use of computer systems implementing algorithms and/or statistical models to perform specific task(s) without using explicit instructions, but instead relying on patterns and inferences. ML algorithms build or estimate mathematical model(s) (referred to as “ML models” or the like) based on sample data (referred to as “training data,” “model training information,” or the like) in order to make predictions or decisions without being explicitly programmed to perform such tasks. Generally, an ML algorithm is a computer program that learns from experience with respect to some task and some performance measure, and an ML model may be any object or data structure created after an ML algorithm is trained with one or more training datasets. After training, an ML model may be used to make predictions on new datasets. Although the term “ML algorithm” refers to different concepts than the term “ML model,” these terms as discussed herein may be used interchangeably for the purposes of the present disclosure.

The term “machine learning model,” “ML model,” or the like may also refer to ML methods and concepts used by an ML-assisted solution. An “ML-assisted solution” is a solution that addresses a specific use case using ML algorithms during operation. ML models include supervised learning (e.g., linear regression, k-nearest neighbor (KNN), descision tree algorithms, support machine vectors, Bayesian algorithm, ensemble algorithms, etc.) unsupervised learning (e.g., K-means clustering, principle component analysis (PCA), etc.), reinforcement learning (e.g., Q-leaming, multi-armed bandit learning, deep RL, etc.), neural networks, and the like. Depending on the implementation a specific ML model could have many sub-models as components and the ML model may train all sub-models together. Separately trained ML models can also be chained together in an ML pipeline during inference. An “ML pipeline” is a set of functionalities, functions, or functional entities specific for an ML-assisted solution; an ML pipeline may include one or several data sources in a data pipeline, a model training pipeline, a model evaluation pipeline, and an actor. The “actor” is an entity that hosts an ML assisted solution using the output of the ML model inference). The term “ML training host” refers to an entity, such as a network function, that hosts the training of the model. The term “ML inference host” refers to an entity, such as a network function, that hosts model during inference mode (which includes both the model execution as well as any online learning if applicable). The ML-host informs the actor about the output of the ML algorithm, and the actor takes a decision for an action (an “action” is performed by an actor as a result of the output of an ML assisted solution). The term “model inference information” refers to information used as an input to the ML model for determining inference(s); the data used to train an ML model and the data used to determine inferences may overlap, however, “training data” and “inference data” refer to different concepts.