Support for orthogonal cover code on nprach and npusch in IoT ntn

Abstract

In the NB-IoT NTN deployment, the coverage area can be as large as hundreds of thousand square kilometers. In such huge geography area, the number of IoT devices that need to access the satellite will be massive. In another hand, the UL capability of NB-IoT is severely suppressed by large repetition number due to the limited link budget. To enlarge the system capacity, multiplexing of UEs by usage of orthogonal cover codes (OCC) for NPUSCH format 1 and NPRACH is proposed in 3GPP as a Release 19 IoT NTN work item. The Invention incudes various methods of overlaying the OCC code to the NPUSCH and NPRACH; various procedures on support OCC for NPRACH and NPUSCH such as random access and connection establishment; other related 3GPP specification impact.

Description

SUPPORT FOR ORTHOGONAL COVER CODE ON NPRACH AND NPUSCH IN IOT NTNFIELD

[0001] This disclosure relates generally to wireless communications and, more particularly, to methods and apparatus for supporting for orthogonal cover code (OCC) on NPRACH and NPUSCH in IoT NTN.BACKGROUND

[0002] NB-IoT / eMTC was specified in 3GPP Rel-13 in the purpose of providing a new access system with low complexity and low throughput to address the requirements of cellular internet of things (IoT) . In 3GPP Rel-17, to enable IoT operation in remote areas with low / no cellular connectivity for many different industries, NB-IoT / eMTC support for Non-Terrestrial Networks (NTN) were studied and specified.

[0003] In the NB-IoT NTN deployment, the coverage area can be as large as hundreds of thousand square kilometers. In such huge geography area, the number of IoT devices that need to access the satellite will be massive. In another hand, the UL capability of NB-IoT is severely suppressed by large repetition number due to the limited link budget. To enlarge the system capacity, multiplexing of UEs by usage of orthogonal cover codes (OCC) for NPUSCH format 1 and NPRACH is proposed in 3GPP as a Release 19 IoT NTN work item.SUMMARY

[0004] The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

[0005] Various aspects of the present disclosure relate to supporting for orthogonal cover code (OCC) on NPRACH and NPUSCH in IoT NTN. The concepts and methods can also apply to NR (new radio access technology, or 5G technology) , 6G or other radio access technology.

[0006] In an aspect of the disclosure, a value in the orthogonal sequence overlays a data symbol in the NPUSCH slot. The same orthogonal sequence overlays to the data symbols in each NPUSCH slot. The orthogonal sequence length is the same as the number of NPUSCH symbols in the slot.

[0007] In an aspect of the disclosure, one value from the orthogonal sequence overlays to  each repetition unit in NPUSCH transmission. The repetition number should be an even multiple of the orthogonal sequence length.

[0008] In an aspect of the disclosure, one value from the orthogonal sequence overlays to each symbol groups. The same orthogonal sequence overlays to the symbol groups in each preamble. The orthogonal sequence length is the same as the number of symbol groups.

[0009] In an aspect of the disclosure, UE multiplexing number this value can be a fixed value or a cell specific value via SIB, or UE specific value. The UE multiplexing number be the same or different for NPUSCH and NPRACH.

[0010] In an aspect of the disclosure, UE can support OCC NPRACH and / or OCC NPUSCH.

[0011] In an aspect of the disclosure, OCC NPRACH can support contention based random access and contention free random access. Both PDCCH order CFRA and physical layer SR CFRA can support OCC. UE can support OCC for 3.75KHz NPUSCH and 15K NPUSCH. UE can support OCC for single-tone and multi-tone NPUSCH. UE can support OCC for EDT and PUR.

[0012] In an aspect of the disclosure, the legacy NPRACH and NPUSCH resources can be reused for OCC multiplexing UEs, or new OCC enabled NPACH and NPUSCH resource can be allocated only for OCC enabled Rel-19 UE.

[0013] In an aspect of the disclosure, OCC enabled Rel-19 UE randomly selects OCC code other that all 1 OCC sequence. Or OCC enabled Rel-19 UE is allowed to select all 1 OCC sequence.

[0014] In an aspect of the disclosure, UEs with the same Random Access Preamble Identity (RAPID) but with different OCC sequences can use the same Random Access Response (RAR) . The UEs can include legacy UEs and OCC enabled Rel-19 UEs. Alternatively, the UEs with the same Random Access Preamble Identity (RAPID) but with different OCC sequences can use different RAR. RA-RNTI formulation needs to update to take OCC code into account.

[0015] In an aspect of the disclosure, network can send Msg4 contains multiple Contention Resolution MAC CEs for multiple UEs. The UEs can be legacy UE and OCC enabled Rel-19 UE. A new Rel-19 contention resolution ID MAC CE contains resolution ID and a C-RNTI.

[0016] In an aspect of the disclosure, the OCC sequence for NPUSCH can be configured in a RRC dedicated signaling, MAC CE, RAR, or DCI. For DCI indication, a new field can be expanded to indicate the OCC sequence index.BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure. 1 is a diagram illustrating random access procedure of supporting OCC NPRACH.

[0018] Figure. 2 is a diagram illustrating configuration flow of OCC NPUSCH.

[0019] Figure. 3 is a diagram illustrating Msg4 MAC PDU Structure alternative 1.

[0020] Figure. 4 is a diagram illustrating Msg4 MAC PDU Structure alternative 2.

[0021] Figure. 5 is a diagram illustrating Msg4 MAC PDU Structure alternative 3.DETAILED DESCRIPTION

[0022] The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

[0023] Several aspects of telecommunication systems will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0024] The described invention operates in the context of 3GPP IoT NTN. The IoT system was specified in 3GPP Rel-13 in the purpose of provide new access system towards low complexity and low throughput to address the requirement of cellular internet of things (IoT) . IoT system is mainly divided into NB-IoT and eMTC, based on different system bandwidth and coverage. In 3GPP Rel-17, to enable IoT operation in remote areas with low / no cellular connectivity for many different industries, NB-IoT / eMTC support for Non-Terrestrial Networks (NTN) was studied and specified.

[0025] In the NB-IoT NTN deployment, the coverage area can be as large as hundreds of thousand square kilometers. In such huge geography area, the number of IoT devices that need to access the satellite will be massive. In another hand, the UL capability of NB-IoT is severely suppressed by large repetition number due to the limited link budget. To meet the need of system capacity, multiplexing of UEs by usage of orthogonal cover codes (OCC) for NPUSCH format 1 and NPRACH is proposed in 3GPP as a Release 19 IoT NTN work item.

[0026] Alternative #1: OCC sequence for NPUSCH data symbol. The orthogonal sequence wi (m) is given by following tables as examples.

[0027] ● where corresponding to the symbols not used for transmission of reference signals,

[0028] ● where i is the index of the orthogonal sequence to use for different UEs,

[0029] ● where 0< i < = UE_MAX_OCC

[0030] A value in the OCC sequence overlays a data symbol in the NPUSCH slot. The same OCC sequence overlays to the data symbols in each NPUSCH slot. The OCC sequence length is the same as the number of NPUSCH symbols in the slot. For example, if the slot has 6 NPUSCH data symbols, the corresponding OCC sequence length is also 6. UE_MAX_OCC indicates the maximum UEs to enable multiplexing of multiple UEs, UE_MAX_OCC can be predefined value, like 2, 4, 6, 8, 16 or can be configured by DCI or higher layer with RRC or SIB.

[0031] Table 1 NPUSCH format 1, UE_MAX_OCC is 2

[0032] Table 2 NPUSCH format 1, UE_MAX_OCC is 4

[0033] Table 3 NPUSCH format 1, UE_MAX_OCC is 6

[0034] Table 4 NPUSCH format 2, UE_MAX_OCC is 2

[0035] Table 5 NPUSCH format 2, UE_MAX_OCC is 4

[0036] Alternative #2: OCC sequence for NPUSCH slot. The orthogonal sequence wi (m) is given by following tables as examples.

[0037] ● where is the slot number in the RU

[0038] ● where i is the index of the orthogonal sequence to use for different UEs,

[0039] ● where 0< i < = UE_MAX_OCC.

[0040] A value in the OCC sequence overlays a NPUSCH slot in the RU. The same OCC sequence overlays to the NPUSCH slots in each RU. The OCC sequence length is the same as the number of slots in the RU. For example, if the RU has 4 slots, the corresponding OCC sequence length is also 4. UE_MAX_OCC indicates the maximum UEs to enable multiplexing of multiple  UEs, UE_MAX_OCC can be predefined value, like 2, 4, 6, 8, 16 or can be configured by DCI or higher layer with RRC or SIB.

[0041] Table 6 16 slots in RU, UE_MAX_OCC is 2

[0042] Table 7 16 slots in RU, UE_MAX_OCC is 4

[0043] Table 8 16 slots in RU, UE_MAX_OCC is 6

[0044] Table 9 16 slots in RU, UE_MAX_OCC is 8

[0045] Table 10 16 slots in RU, UE_MAX_OCC is 16

[0046] Table 11 8 slots in RU, UE_MAX_OCC is 8

[0047] Table 12 8 slots in RU, UE_MAX_OCC is 6

[0048] Table 13 8 slots in RU, UE_MAX_OCC is 4

[0049] Table 14 8 slots in RU, UE_MAX_OCC is 2

[0050] Table 15 4 slots in RU, UE_MAX_OCC is 6

[0051] Table 16 4 slots in RU, UE_MAX_OCC is 4

[0052] Table 17 4 slots in RU, UE_MAX_OCC is 2

[0053] Table 18 2 slots in RU, UE_MAX_OCC is 2

[0054] Alternative #3: OCC sequence for NPUSCH repetition. The orthogonal sequence wi (m) is given by following tables as examples.

[0055] ● where 0≤m<NREP, NREP is the repetition number

[0056] ● where i is the index of the orthogonal sequence to use for different UEs,

[0057] ● where 0< i < = UE_MAX_OCC

[0058] One value from the OCC sequence overlays to each repetition unit in NPUSCH transmission. The repetition number should be an even multiple of the OCC sequence length. For example, if the repetition number is 4, the OCC sequence length can be 2 or 4. If the repetition  number is 16, the OCC sequence length can be 2, 4, 8. When the repetition number is 4 and QCC sequence is [1, -1] , repetition 1 is overlaid with 1, repetition 2 is overlaid with -1, repetition 3 is overlaid with 1, repetition 4 is overlaid with -1. UE_MAX_OCC indicates the maximum UEs to enable multiplexing of multiple UEs, UE_MAX_OCC can be predefined value, like 2, 4, 6, 8, 16 or can be configured by DCI or higher layer with RRC or SIB.

[0059] Table 19 Nrep is 2, UE_MAX_OCC is 2

[0060] Table 20 NREP is 4, UE_MAX_OCC is 2

[0061] Table 21 NREP is 4, UE_MAX_OCC is 4

[0062] Table 22 NREP is 8, UE_MAX_OCC is 2

[0063] Table 23 NREP is 8, UE_MAX_OCC is 4

[0064] Table 24 NREP is 8, UE_MAX_OCC is 6

[0065] Table 25 NREP is 16, UE_MAX_OCC is 2

[0066] Table 26 NREP is 16, UE_MAX_OCC is 4

[0067] Table 27 NREP is 16, UE_MAX_OCC is 6

[0068] Table 28 NREP is 16, UE_MAX_OCC is 8

[0069] Table 29 NREP is 32, UE_MAX_OCC is 2

[0070] Table 30 NREP is 32, UE_MAX_OCC is 4

[0071] Table 31 NREP is 32, UE_MAX_OCC is 6

[0072] Table 32 NREP is 32, UE_MAX_OCC is 8

[0073] Alternative #4: OCC sequence for NPRACH. The orthogonal sequence wi (m) is given by following tables as examples.

[0074] ● where 0≤m<P, P is the number of symbol groups

[0075] ● where i is the index of the orthogonal sequence to use for different UEs,

[0076] ● where 0< i < = UE_MAX_OCC

[0077] One value from the OCC sequence overlays to each NPRACH symbol groups. The same OCC sequence overlays to the NPRACH symbol groups in each preamble. The OCC sequence length is the same as the number of symbol groups. For example, if the preamble has 4 symbol groups, the corresponding OCC sequence length is also 4. UE_MAX_OCC indicates the maximum UEs to enable multiplexing of multiple UEs, UE_MAX_OCC can be predefined value, like 2, 4, 6, 8, 16 or can be configured by DCI or higher layer with RRC or SIB.

[0078] Table 33 UE_MAX_OCC for frame structure type 1

[0079] Table 34 UE_MAX_OCC for frame structure type 2

[0080] Table 35 Sequence for UE_MAC_OCC = 2, P=4

[0081] Table 36 Sequence for UE_MAC_OCC = 2, P=6

[0082] Table 37 Sequence for UE_MAC_OCC = 4, p=4

[0083] Table 38 Sequence for UE_MAC_OCC = 4, p=6

[0084] Table 39 Sequence for UE_MAC_OCC = 6, P=4

[0085] Table 40 Sequence for UE_MAC_OCC = 6, P =6

[0086] Table 41 Sequence for UE_MAC_OCC = 8, P=6

[0087] Table 42 Sequence for UE_MAC_OCC = 16, P=6

[0088] Alternative #5: UE_MAX_OCC, as the maximum UE multiplexing number, can be a fixed value. Alternatively, it can be a cell-specific value configured by system information or dedicated RRC signaling. Alternatively, it can be a UE-specific value configured by DCI, MAC CE or dedicated RRC signaling. The maximum UE multiplexing number for NPUSCH and NPRACH can be the same or different. Alternatively, it can be a dynamic value derived by NPUSCH and NPRACH configurations.

[0089] Alternative #6: For a UE supporting OCC NPUSCH and OCC NRACH, these are possible combinations:

[0090] ● UE support OCC NPRACH and OCC NPUSCH.

[0091] ● UE support OCC NPRACH but not OCC NPUSCH.

[0092] ● UE support OCC NPUSCH but not OCC NPRACH.

[0093] The supporting of OCC NPRACH and OCC NPUSCH in cell can be indicated by the system information, and dedicated RRC signaling.

[0094] Alternative #7: For OCC NPRACH, both contention-based random access and contention-free random access can be supported. For UE, the supporting of OCC contention-based  random access and OCC contention-free random access can be indicated in preamble partition. For example, if UE support OCC contention-free random access, UE can select a preamble index from the preamble set of supporting of OCC contention-free random access. Alternatively, for UE, the supporting of OCC contention-based random access and OCC contention-free random access can be indicated in RRC dedicated signaling. Network can indicate supporting of OCC contention-based random access and OCC contention-free random access by system information or RRC dedicated signaling. Both PDCCH order CFRA and physical layer SR CFRA can support OCC.

[0095] UE can support OCC for 3.75KHz NPUSCH and 15K NPUSCH. This UE capability can be indicated by the RRC dedicated signaling. Network can indicate supporting of OCC for 3.75KHz NPUSCH and 15K NPUSCH via system information and RRC dedicated signaling.

[0096] UE can support OCC for single-tone and multi-tone NPUSCH. This UE capability can be indicated by the RRC dedicated signaling or preamble partition. Network can indicate supporting of OCC for single-tone and multi-tone NPUSCH via system information and RRC dedicated signaling.

[0097] UE can support OCC for EDT and PUR. The UE capability can be indicated by the RRC dedicated signaling. Network can indicate cell supporting OCC for EDT and PUR via system information and RRC dedicated signaling.

[0098] The OCC sequence partition can also be used to indicate UE capability. For example, UE using OCC sequence #1 and OCC sequence #2 can be treated by network as supporting single-tone, UE using OCC sequence #3 and OCC sequence #4 can be treated by network as supporting multi-tone.

[0099] Alternative #8: The legacy NPRACH and NPUSCH resources can be reused for OCC multiplexing UEs. The legacy UE transmission on NPRACH and NPUSCH is equivalent to overlaying all 1 OCC sequence (e.g., [1 1] ) . There is no change for the legacy UE, and it is still orthogonal to other OCC sequences. Hence, the legacy NPRACH and NPUSCH resource can be reused together with OCC enabled Rel-19 UE. Legacy UEs and OCC enabled Rel-19 UEs can send same preamble on the same legacy NPRACH resources overlaying different OCC sequence. Legacy UEs and OCC enabled Rel-19 UEs can send different NPUSCH data on the same legacy NPRACH resources overlaying different OCC sequence. Cell can indicate that the legacy NPRACH and NPUSCH resource support OCC in SIB, RRC dedicated signaling and DCI. Take Figure 1 as an example.

[0100] Alternatively, new OCC enabled NPACH and NPUSCH resource can be allocated only for OCC enabled Rel-19 UE. For NPRACH, there can be new time domain resource, frequency domain resource and new NPRACH preamble partition. For NPUSCH, there can be new time domain resource and frequency domain resource. The new NPRACH and NPUSH  resource can be indicated via system information, RRC dedicated signaling and DCI.

[0101] Alternative #9: For contention-based random access, OCC enabled Rel-19 UE can randomly selects OCC sequence other that all 1 OCC sequence (e.g., [1 1] ) . All 1 OCC code is reserved for legacy UE. Alternatively, OCC enabled Rel-19 UE is allowed to select all 1 OCC sequence (e.g., [1 1] ) . To be more specific, the cell can indicate whether OCC enabled Rel-19 UE is allowed to select all 1 OCC sequence via SIB or dedicated signaling. Alternatively, the OCC sequence can be derived by UE information, such as UE identity (e.g., IMSI, TMSI) . For example, i = UE_IDENTITY mod UE_MAX_OCC where i is the index of the OCC sequence, UE_MAX_OCC is the maximum number of the OCC sequences. The network can also indicate the OCC sequence for NPRACH in the dedicated signaling, MAC CE or DCI in case of contention-free random access.

[0102] Alternative #10: UEs with the same Random Access Preamble Identity (RAPID) but with different OCC sequences can use the same Random Access Response (RAR) . The UEs can include legacy UEs and OCC enabled Rel-19 UEs. UEs using same RAR can send their own Msg3 on the same time and frequency NPUSCH resource as designated by RAR. It requires UE support OCC NPUSCH. The OCC sequence for Msg3 can be the same as the one used in Msg1 transmission. Alternatively, the OCC sequence for Msg3 can be different from the OCC sequence used in Msg1 transmission. Take Figure 1 as an example.

[0103] Alternatively, the UEs with the same Random Access Preamble Identity (RAPID) but with different OCC sequences can use different RAR. In this case, RA-RNTI formulation needs to update to take OCC code into account. For example, the RA-RNTI=1 + floor (SFN_id / 4) + 256*carrier_id + 12*256*OCC_SEQ_id, where SFN_id is the index of the first radio frame of the specified PRACH, carrier_id is the index of the UL carrier associated with the specified PRACH and the OCC_SEQ_id is the index of the used OCC sequence. In this case, network send different RARs to UEs with same RAPID but different OCC code. In the same time, UEs with same RAPID but different OCC code monitor the different RAR addressed by different RA-RNTI. Only UEs with only same OCC code (i.e., using same RAR) can send Msg3 on the same time and frequency OCC NPUSCH resource as designated by RAR.

[0104] The RAR can be expanded to indicate the OCC sequence index used for OCC NPUSCH Msg3 transmission.

[0105] Alternative #11: To support OCC NPUSCH Msg3 in random access, network can send Msg4 contains multiple Contention Resolution MAC CEs for multiple UEs. The UEs can be legacy UE and OCC enabled Rel-19 UE. The contention resolution information for legacy UE and OCC enabled rel-19 UE can be in a same Msg4. For example, a Msg4 contains legacy contention resolution ID MAC CE, legacy CCCH data, Rel-19 contention resolution ID MAC CE and Rel- 19 CCCH data. Msg4 is addressed to Temporary C-RNTI (TC-RNTI) from RAR. The new Rel-19 contention resolution ID MAC CE contains resolution ID and a C-RNTI. The C-RNTI can be an offset to the TC-RNTI to reduce the overhead. Alternatively, the C-RNTI can be conveyed by a separate DL C-RNTI MAC CE. A new LCID is needed for Rel-19 CCCH data, so that the legacy UE would not consider it as its own. This Rel-19 CCCH data belongs to the UE identified by the previous Rel-19 UE Contention Resolution ID MAC CE. Take Figure 1 and Figure 3 as an example.

[0106] The Rel-19 UE Contention Resolution ID MAC CE and Rel-19 CCCH data for a UE may be sent by another Msg4 addressed by TC-RNTI. Unlike the legacy UE, Rel-19 UE will continue to wait for another Msg4 if received Rel-19 Contention Resolution ID MAC CE does not match. Take Figure 4 as an example.

[0107] A separate CCCH data for Rel-19 UE can be sent in a subsequent DL MAC PDU addressed by the previously indicated C-RNTI. Take Figure 5 as an example.

[0108] Alternative #12: The OCC sequence for NPUSCH can be configured in a RRC dedicated signaling, MAC CE, RAR, or DCI. For DCI indication, a new field can be expanded to indicate the OCC sequence index. For RRC dedicated signaling, network can enable OCC NPUSCH in RRCConnectionSetup-NB, RRCConnectionResume-NB, RRCConnectionReestablishment-NB, RRCConnectionReconfiguration-NB for OCC enabled Rel-19 UE. Network can configure OCC NPUSCH based on the OCC code used in Msg1 or Msg3, or OCC NPUSCH supporting UE capability indication in Msg3, or a UE capability parameter in UECapabilityInformation message.

[0109] Various functions in accordance with one or more embodiments or examples described herein can be performed by an exemplary apparatus. For example, the apparatus can be used to implement functions of UEs or BSs in various embodiments and examples described herein. The apparatus can include a general purpose processor or specially designed circuits to implement various functions, components, or processes described herein in various embodiments. The apparatus can include a processing circuitry, a memory, and a radio frequency (RF) module. In various examples, the processing circuitry can include circuitry configured to perform the functions and processes described herein in combination with software or without software. In some other examples, the processing circuitry can be a central processing unit (CPU) configured to execute program instructions to perform various functions and processes described herein. Accordingly, the memory can be configured to store program instructions. The processing circuitry, when executing the program instructions, can perform the functions and processes. The memory can further store other programs or data, such as operating systems, application programs, and the like.

[0110] While aspects of the present disclosure have been described in conjunction with the  specific embodiments thereof that are proposed as examples, alternatives, modifications, and variations to the examples may be made. Accordingly, embodiments as set forth herein are intended to be illustrative and not limiting. There are changes that may be made without departing from the scope of the claims set forth below.

Claims

1.A method of wireless communication comprising: A method to overlay an OCC sequence on a certain radio resource unit to enable multiplying UE.2.The method of Claim 1, wherein a method of overlaying OCC sequence includes: A value in the OCC sequence overlays a data symbol in the NPUSCH slot, the same OCC sequence overlays to the data symbols in each NPUSCH slot, the OCC sequence length is the same as the number of NPUSCH symbols in the slot.3.The method of Claim 1, wherein a method of overlaying OCC sequence includes: A value in the OCC sequence overlays a NPUSCH slot in the RU, the same OCC sequence overlays to the NPUSCH slots in each RU, the OCC sequence length is the same as the number of slots in the RU.4.The method of Claim 1, wherein a method of overlaying OCC sequence includes: One value from the OCC sequence overlays to each repetition unit in NPUSCH transmission, the repetition number should be an even multiple of the OCC sequence length.5.The method of Claim 1, wherein a method of overlaying OCC sequence includes: One value from the OCC sequence overlays to each NPRACH symbol groups, the same OCC sequence overlays to the NPRACH symbol groups in each preamble, the OCC sequence length is the same as the number of symbol groups.6.A method of wireless communication comprising: A method of configuration and usage of OCC.7.The method of Claim 6, wherein a method of configuration and usage of OCC includes: The maximum UE multiplexing number can be a fixed value, cell-specific value, UE specific value or dynamic derived value, it can be configured by DCI, MAC CE or RRC dedicated signaling.8.The method of Claim 6, wherein a method of configuration and usage of OCC includes: UE support OCC NPRACH and / or OCC NPUSCH.9.The method of Claim 6, wherein a method of configuration and usage of OCC includes: For OCC NPRACH, both contention-based random access and contention-free random access can be supported, both PDCCH order CFRA and physical layer SR CFRA can support OCC, UE can support OCC for 3.75KHz NPUSCH and 15K NPUSCH, UE can support OCC for single-tone and multi-tone NPUSCH, UE can support OCC for EDT and PUR, the OCC sequence partition can also be used to indicate UE capability.10.The method of Claim 6, wherein a method of configuration and usage of OCC includes: The legacy NPRACH and NPUSCH resources can be reused for OCC multiplexing UEs, legacy UEs and OCC enabled Rel-19 UEs can send same preamble on the same legacy NPRACH resources overlaying different OCC sequence.11.The method of Claim 10, wherein a method of OCC resource configuration includes: New OCC enabled NPACH and NPUSCH resource can be allocated only for OCC enabled Rel-19 UE.12.The method of Claim 6, wherein a method of configuration and usage of OCC includes: For contention-based random access, OCC enabled Rel-19 UE can randomly selects OCC sequence other that all 1 OCC sequence (e.g., [1 1] ) , all 1 OCC code is reserved for legacy UE.13.The method of Claim 12, wherein a method of UE selection of OCC sequence for contention-based random access includes: Alternatively, OCC enabled Rel-19 UE is allowed to select all 1 OCC sequence, alternatively, the OCC sequence can be derived by UE information.14.The method of Claim 6, wherein a method of configuration and usage of OCC includes: UEs with the same Random Access Preamble Identity (RAPID) but with different OCC sequences can use the same Random Access Response (RAR) , the UEs can include legacy UEs and OCC enabled Rel-19 UEs, UEs using same RAR can send their own Msg3 on the same time and frequency NPUSCH resource as designated by RAR, the OCC sequence for Msg3 can be the same as the one used in Msg1 transmission, alternatively, the OCC sequence for Msg3 can be different from the OCC sequence used in Msg1 transmission.15.The method of Claim 14, wherein a method of UE using RAR includes: Alternatively, the UEs with the same Random Access Preamble Identity (RAPID) but with different OCC sequences can use different RAR, RA-RNTI formulation needs to update to take OCC code into account, UEs with same RAPID but different OCC code monitor the different RAR addressed by different RA-RNTI.16.The method of Claim 6, wherein a method of configuration and usage of OCC includes: To support OCC NPUSCH Msg3 in random access, network can send Msg4 contains multiple Contention Resolution MAC CEs for multiple UEs, the UEs can be legacy UE and OCC enabled Rel-19 UE.17.The method of Claim 16, wherein a method of structure of Msg4 includes: A new Rel-19 contention resolution ID MAC CE contains resolution ID and a C-RNTI, the C-RNTI can be an offset to the TC-RNTI to reduce the overhead, a new LCID is needed for Rel-19 CCCH data.18.The method of Claim 16, wherein a method of structure of Msg4 includes: The Rel-19 UE Contention Resolution ID MAC CE and Rel-19 CCCH data for a UE may be sent by another Msg4 addressed by TC-RNTI.19.The method of Claim 16, wherein a method of structure of Msg4 includes: A separate CCCH data for Rel-19 UE can be sent in a subsequent DL MAC PDU addressed by the previously indicated C-RNTI.20.The method of Claim 6, wherein a method of configuration and usage of OCC includes: The OCC sequence for NPUSCH can be configured in a RRC dedicated signaling, MAC CE, RAR,  or DCI, for DCI indication, a new field can be expanded to indicate the OCC sequence index.

Images