Techniques for PDSCH / PUSCH processing for multi-TRP

Abstract

Techniques for physical downlink shared channel (PDSCH) and physical uplink shared channel (PUSCH) processing for multiple transmit / receive points (multiple TRPs) are disclosed. In some embodiments, determining PDSCH hybrid automatic repeat request-acknowledgement (HARQ-ACK) processing timing includes determining that a user equipment (UE) is configured for single downlink control information (single DCI) multi-TRP PDSCH operation; determining a first PDSCH and a second PDSCH in a slot, the first PDSCH and the second PDSCH being used in the single DCI multi-TRP PDSCH operation; and and determining a minimum HARQ-ACK processing timing for the first PDSCH and the second PDSCH using one or more symbols of the first PDSCH or one or more symbols of both the first PDSCH and the second PDSCH.

Description

[Technical Field]

[0001] TECHNICAL FIELD This application relates generally to wireless communication systems. [Background technology]

[0002] Wireless mobile communication technologies use various standards and protocols to transmit data between base stations and wireless mobile devices. Standards and protocols for wireless communication systems can include the 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) (e.g., 4G) or New Radio (NR) (e.g., 5G), the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard, commonly known to industry groups as worldwide interoperability for microwave access (WiMAX), and the IEEE 802.11 standard for wireless local area networks (WLANs), commonly known to industry groups as Wi-Fi. In a 3GPP radio access network (RAN) of an LTE system, a base station may include a RAN node, such as an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as an evolved Node B, enhanced Node B, eNodeB, or eNB) and / or an E-UTRAN Radio Network Controller (RNC), which communicates with wireless communication devices known as user equipment (UE). In a fifth-generation (5G) wireless RAN, a RAN node may include a 5G node, an NR node (also referred to as a next-generation Node B, or gNode B (gNB)).

[0003] The RAN communicates between RAN nodes and UEs using radio access technologies (RATs). RANs may include global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), and / or E-UTRAN, which provide access to communication services via a core network. Each RAN operates according to a particular 3GPP RAT. For example, GERAN implements GSM and / or EDGE RATs, UTRAN implements universal mobile telecommunication system (UMTS) RAT or other 3GPP RATs, E-UTRAN implements LTE RATs, and NG-RAN implements 5G RATs. In certain deployments, E-UTRAN may also implement a 5G RAT.

[0004] The 5G NR frequency band can be divided into two different frequency ranges. Frequency Range 1 (FR1) includes sub-6 GHz frequency bands, some of which may be used by previous standards but may be expanded to cover potential new frequency bands offering 410 MHz to 7125 MHz. Frequency Range 2 (FR2) includes frequency bands from 24.25 GHz to 52.6 GHz. FR2's millimeter wave (mmWave) range bands have shorter ranges than FR1's bands, but offer higher available bandwidth. Those skilled in the art will understand that these frequency ranges, provided as examples, may vary over time or by region.

[0005] To easily identify the discussion of any particular element or act, the most significant digit(s) of a reference number refers to the number of the figure in which that element is first introduced. [Brief explanation of the drawings]

[0006] [Figure 1] 1 illustrates a capability reporting process according to some embodiments. [Figure 2] 1 shows a diagram illustrating a physical downlink shared channel (PDSCH) according to TDM scheme A, in accordance with some embodiments. [Figure 3] 1 illustrates a process for PDSCH processing according to some embodiments. [Figure 4] 1 shows another diagram illustrating PDSCH according to TDM scheme A, according to some embodiments. [Figure 5] 1 illustrates a process for determining the overall minimum HARQ-ACK processing time according to some embodiments. [Figure 6] 1 illustrates a system architecture according to some embodiments. [Figure 7] 1 illustrates infrastructure equipment according to some embodiments. [Figure 8] 1 illustrates a platform according to some embodiments. [Figure 9] 1 illustrates system components according to some embodiments. [Figure 10] 1 illustrates an exemplary system for multi-transmit / receive point (multi-TRP) operation according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0007] Multi-transmit / receive point (multi-TRP) is one of the five agendas in Rel-16 eMIMO. Two operation modes have been agreed upon for multi-TRP in NR Rel-16: multiple downlink control information (multi-DCI) operation (e.g., multiple DCIs may be used to schedule and / or control transmissions between a UE and a gNB) and single-DCI operation (e.g., a single DCI may be used to schedule and / or control transmissions between a UE and a gNB). For example, in multi-DCI multi-TRP, multiple physical downlink control channels (PDCCHs) may be received by a UE from multiple TRPs (e.g., multiple gNBs). Each PDCCH may correspond to a different TRP and may schedule physical downlink shared channel (PDSCH) transmissions from a separate TRP to the UE. For example, in the case of single-DCI multi-TRP, a single PDCCH may be received by a UE from one TRP (e.g., one gNB) among the multiple TRPs (e.g., multiple gNBs). A single PDCCH from one TRP may schedule PDSCH transmissions from each of the multiple TRPs to the UE.

[0008] In a multi-DCI solution for multi-TRP, each TRP may be scheduled by a control resource set (CORESET) with a corresponding CORESETPoolIndex from {0, 1}. If CORESETPoolIndex is not set, it may be considered to be 0. Up to three CORESETs per bandwidth portion (BWP) may be configured for each CORESETPoolIndex. Up to five total CORESETs may be configured per BWP. In a multi-DCI solution for multi-TRP, the physical downlink shared channel (PDSCH) may be allowed to be full, partial, or non-overlapping. Furthermore, hybrid automatic repeat request (HARQ)-acknowledgement (ACK) feedback may support both "separate" and "joint" feedback modes. Up to two codewords (CWs) and 16 HARQ processes may be supported, which is the same as Rel-15.

[0009] 10 illustrates an exemplary system 1000 for multi-TRP operation according to some embodiments. In the illustrated embodiment, system 1000 includes gNB 1002, gNB 1004, and UE 1006. UE 1006 and one or both of gNB 1002 and gNB 1004 may communicate with each other using signals 1008, 1012, 1016, and 1020. For example, gNB 1002 and / or gNB 1004 are transmit / receive points (TRPs) in system 1000, and UE 1006 supports multi-TRP operation. For example, gNB 1002 transmits signal 1010 of signal 1008 to UE 1006, and UE 1006 transmits signal 1014 of signal 1012 to gNB 1002. For example, gNB 1004 transmits signal 1022 of signal 1020 to UE 1006, and UE 1006 transmits signal 1018 of signal 1016 to gNB 1004.

[0010] Multi-DCI mode-based multi-TRP operation is shown in Figure 10. For example, UE 1006 simultaneously receives signals (e.g., signals 1010 and 1022) from multiple TRPs (e.g., gNB 1002 and gNB 1004), and signals 1010 and 1022 are scheduled by multiple physical downlink control channels (PDCCHs). PDCCHs from different TRPs (e.g., gNB 1002, gNB 1004) may be transmitted from different control resource sets (CORESETs) for each of the TRPs with different CORESET-poolIndex values. For example, signal 1010 and / or signal 1014 for communication between UE 1006 and gNB 1002 use PDCCHs from CORESET 1, which has a CORESET-poolIndex value of 0. For example, signal 1018 and / or signal 1022 for communication between UE 1006 and gNB 1004 use a PDCCH from CORESET 2, which has a CORESET-poolIndex value of 1. In some embodiments, networks of system 1000 having a multi-DCI mode (e.g., gNB 1002 and gNB 1004) may be deployed with ideal or non-ideal backhaul. For example, a system with ideal backhaul may have latency of approximately 2.5 microseconds or less and throughput of 10 Gbps or less. A system with non-ideal backhaul may have latency entirely outside the range provided for ideal backhaul.

[0011] In Rel-15, 3GPP Technical Specification (TS) 38.214 defines two processing capabilities for the PDSCH and the Physical Uplink Shared Channel (PUSCH). For the PDSCH, PDSCH Processing Capability 1 has normal HARQ-ACK feedback with respect to the timing offset between the PDSCH and HARQ-ACK. PDSCH Processing Capability 2 has low-latency HARQ-ACK feedback. For the PUSCH, PUSCH Processing Capability 1 has normal PUSCH processing with respect to the timing offset between the PDCCH and PUSCH. PUSCH Processing Capability 2 has low-latency PUSCH processing.

[0012] Some embodiments of the present disclosure may address PDSCH / PUSCH processing capabilities for multi-TRP. Some embodiments may provide capability reports regarding PDSCH / PUSCH processing capabilities. Some embodiments may provide PDSCH processing capabilities for TDM scheme A single DCI multi-TRP scheme. Some embodiments may provide PDSCH processing capabilities for other single DCI multi-TRP schemes. Some embodiments of the present disclosure implement one or more of the following solutions.

[0013] Solutions 1.1 to 1.9 relate to capability reporting for PDSCH / PUSCH processing. Solution 1.1

[0014] In some embodiments, PDSCH processing capability 2 does not apply to multi-DCI multi-TRP. For example, when a UE is configured with multi-DCI multi-TRP operation, the UE may not operate with PDSCH processing capability 2. In another example, when all UEs are configured with multi-DCI multi-TRP operation, none of the UEs may operate with PDSCH processing capability 2. Solution 1.2

[0015] In some embodiments, PDSCH processing capability 2 does not apply to single DCI multi-TRP. For example, when a UE is configured with single DCI multi-TRP operation, the UE may not operate with PDSCH processing capability 2. In another example, when all UEs are configured with single DCI multi-TRP operation, none of the UEs may operate with PDSCH processing capability 2. Solution 1.3

[0016] In some embodiments, PUSCH processing capability 2 does not apply to multi-DCI multi-TRP. For example, when a UE is configured with multi-DCI multi-TRP operation, the UE may not operate with PUSCH processing capability 2. In another example, when all UEs are configured with multi-DCI multi-TRP operation, none of the UEs may operate with PUSCH processing capability 2. Solution 1.4

[0017] In some embodiments, the UE can indicate support for PDSCH Capability 2 for multi-DCI multi-TRP. For example, the UE may issue a report to indicate support. The report can be issued by the UE per Feature Set per Component Carrier (FSPC) (per Component Carrier (CC) per band per band combination), per Feature Set (FS), or per band. Solution 1.5

[0018] In some embodiments, the UE may indicate support for PUSCH capability 2 for multi-DCI multi-TRP. For example, the UE may issue a report to indicate support. The report may be issued by the UE per FSPC (per CC per band per band combination), per FS (per band per band combination), or per band. Solution 1.6

[0019] In some embodiments, the UE can indicate support for PDSCH Capability 2 for single DCI multi-TRP. For example, the UE may issue a report to indicate support. The report can be in a bitmap format to cover all five different single DCI multi-TRP schemes (e.g., SDM, FDM Scheme A, FDM Scheme B, TDM Scheme A, Scheme 4). The report can be issued by the UE per FSPC (per CC per band per band per band combination), per FS (per band per band combination), or per band.

[0020] For example, in SDM (Spatial Domain Multiplexing), a single PDSCH is spatially multiplexed. Each TRP may be mapped to one TCI (Transmission Configuration Indicator) and one DMRS (Demodulation Reference Signal) Code Division Multiplexing (CDM) group.

[0021] For example, in FDM scheme A (frequency domain multiplexing scheme A), each TRP that is frequency domain multiplexed with a single PDSCH may be mapped to one TCI and half a resource element (RE).

[0022] For example, in FDM scheme B (frequency domain multiplexing scheme B), two PDSCHs in the same transport block (TB) are frequency domain multiplexed, and each TRP may be mapped to one TCI and half an RE.

[0023] For example, in TDM scheme A (time domain multiplexing scheme A), time domain multiplexing is performed for two PDSCHs of the same TB. Each TRP may be mapped to one TCI using intra-slot TDM.

[0024] For example, in Scheme 4, time domain multiplexing for multiple PDSCHs of the same TB is performed. Each TRP may be mapped to one TCI or the same TCI using inter-slot TDM. Solution 1.7

[0025] In some embodiments, the UE may support PUSCH capability 2 for multi-DCI multi-TRP under certain conditions, for example, the UE may support PUSCH capability 2 for multi-DCI multi-TRP without out-of-order (OOO) scheduling from PUSCH to PDCCH. Solution 1.8

[0026] In some embodiments, a UE may only support PDSCH Capability 2 for Multi-DCI Multi-TRP under certain conditions. For example, a UE may support PDSCH Capability 2 for Multi-DCI Multi-TRP when there is one, a subset, or all of the following: no out-of-order (OOO) scheduling from PDCCH to PDSCH, no out-of-order (OOO) scheduling from PDSCH to HARQ-ACK, no joint HARQ-ACK feedback, no overlap in time domain scheduling, no overlap in frequency domain scheduling, or no cross-carrier scheduling. Solution 1.9

[0027] In some embodiments, the UE may only support PDSCH / PUSCH Capability 2 with processing timeline relaxation. For example, the processing time relaxation may be either based on UE reporting or hard-coded in the specification. For example, processing time relaxation may be used independently or jointly for multi-DCI multi-TRP PDSCH, multi-DCI multi-TRP PUSCH, and single-DCI multi-TRP PDSCH in each of the five schemes (e.g., SDM, FDM Scheme A, FDM Scheme B, TDM Scheme A, Scheme 4).

[0028] Solutions 2.1 to 2.4 relate to PDSCH processing capabilities for TDM scheme A. For example, for TDM scheme A, two PDSCHs may be present in a slot, the same duration and frequency resource allocation may be provided for each PDSCH, the same transport block (TB) may be transmitted twice, and the offset between the first and second PDSCHs may be configured via radio resource configuration (RRC) signaling.

[0029] The current processing timeline for PDSCH in TDM scheme A is described in 3GPP TS 38.214. As described in 3GPP TS 38.314, if the first uplink symbol of the PUCCH carrying HARQ-ACK information, defined by the allocated HARQ-ACK timing K1 and the PUCCH resources used, including the effect of timing advance, does not start earlier than symbol L1, L1 is considered to be the time T proc,1 =(N1+d 1,1 +d2)(2048+144)·k2 -μ T c +T ext After, CP is defined as the next uplink symbol in which the CP starts after the end of the last symbol of the PDSCH carrying the TB has been acknowledged, and the UE shall provide a valid HARQ-ACK message.

[0030] For UE processing capability 1: If the PDSCH is of mapping type B as given in clause 7.4.1.1 of [4, 3GPP TS 38.211], If the number of allocated PDSCH symbols is L ≥ 7, then d 1,1 =0, If the number of allocated PDSCH symbols is L ≥ 4 and L ≤ 6, then d 1,1 = 7-L, If the number of allocated PDSCH symbols is L=3, then d 1,1 = 3 + min(d,1), where d is the number of overlapping symbols of the scheduled PDCCH and the scheduled PDSCH; If the number of allocated PDSCH symbols is 2, then d 1,1 = 3 + d, where d is the number of overlapping symbols of the scheduled PDCCH and the scheduled PDSCH.

[0031] For UE processing capability 2: If the PDSCH is mapping type B as given in clause 7.4.1.1 of [4, TS 38.211], If the number of allocated PDSCH symbols is L ≥ 7, then d 1,1 =0, If the number of allocated PDSCH symbols is L ≥ 3 and L ≤ 6, then d 1,1 is the number of overlapping symbols of the scheduled PDCCH and the scheduled PDSCH, If the number of allocated PDSCH symbols is 2, If the scheduling PDCCH is within the 3-symbol CORESET and the CORESET and the PDSCH have the same starting symbol, 1,1 = 3, - if not, d 1,1 is the number of overlapping symbols between the scheduling PDCCH and the scheduled PDSCH.

[0032] Embodiments of the present disclosure may determine how to determine a HARQ-ACK processing timing (also referred to as a timeline or time) K1, such as a minimum HARQ-ACK timeline K1. For example, for a first PDSCH (e.g., PDSCH 1) and a second PDSCH (e.g., PDSCH 2) in a slot, a minimum HARQ-ACK processing timeline or timing K1 until the end of PDSCH 2 may define the timing or duration between PDSCH 2 and the corresponding HARQ-ACK in the PUCCH. The timing or duration may be defined by the last symbol of PDSCH 2 (e.g., the last PDSCH repetition) and the first symbol of the PUCCH carrying the corresponding HARQ-ACK. This timing or duration may provide a UE with time to process the PDSCH. Embodiments of the present disclosure may provide a solution for determining a minimum HARQ-ACK processing timeline or timing K1 until the end of PDSCH 2. Solution 2.1

[0033] In some embodiments, the minimum HARQ-ACK processing timeline until the end of PDSCH 2 may be based only on PDSCH 1. For example, only symbols from PDSCH 1 may be considered. Solution 2.2

[0034] In some embodiments, the minimum HARQ-ACK processing timeline to the end of PDSCH 2 may consider all symbols from the beginning of PDSCH 1 to the end of PDSCH 2, with blank symbols between PDSCH 1 and PDSCH 2 being counted. For example, all symbols from the first symbol of PDSCH 1 to the last symbol of PDSCH 2 may be considered as a PDSCH transmission. The duration L may correspond to the number of symbols overlapping with the CORESET / scheduling PDCCH. For example, if PDSCH 1 has four symbols, followed by a two-symbol gap (e.g., two blank symbols), followed by PDSCH 2, which has four symbols, all symbols are considered for PDSCH 1, PDSCH 2, and the gap. Therefore, the duration L = 4 symbols of PDSCH 1 + 2 symbols of the gap + 4 symbols of PDSCH 2 = 10. Solution 2.3

[0035] In some embodiments, the minimum HARQ-ACK processing timeline to the end of PDSCH 2 may consider all symbols in both PDSCH 1 and PDSCH 2. For example, all symbols in PDSCH 1 and PDSCH 2, the union, may be considered, but blank symbols between PDSCH 1 and PDSCH 2 may not be counted. Duration L may correspond to the number of symbols overlapping with the CORESET / scheduling PDCCH. For example, if PDSCH 1 has four symbols, followed by a two-symbol gap (e.g., two blank symbols), followed by PDSCH 2, which has four symbols, only the symbols for PDSCH 1 and PDSCH 2 are considered. The symbols in the gap are not considered. Therefore, duration L = 4 symbols of PDSCH 1 + 4 symbols of PDSCH 2 = 8. Solution 2.4

[0036] In some embodiments, the minimum HARQ-ACK processing timeline K1 until the end of PDSCH 2 may be jointly based on PDSCH 1 and PDSCH 2. For example, a minimum HARQ-ACK processing time k1_1 may be calculated for PDSCH 1, and a minimum HARQ-ACK processing time k1_2 may be calculated for PDSCH 2.

[0037] For example, the actual minimum HARQ-ACK processing time K1 may be equal to one of the following options: option 1) max(k1_1-Offset,0)+k1_2+C, option 2) max(k1_1,k1_2)+C, or option 3) k1_1+k1_2+C. For example, C may be 0 or may be used to provide additional timeline mitigation.

[0038] In some embodiments, PDSCH processing capability for multiple DCIs and multiple TRPs may be provided. Solution 3.1

[0039] In some embodiments, for multi-DCI based multi-TRP, the minimum HARQ-ACK timeline by the end of PDSCH 2 is based on the same design as TDM scheme A. For example, it may be based on solutions 2.1, 2.2, 2.3, and / or 2.4 described above.

[0040] In some embodiments, PDSCH processing capability for other single DCI multi-TRPs may be provided. Solution 4.1

[0041] In some embodiments, for the SDM SDCI MTRP scheme, the same scheme as in Rel-15 (3GPP TS 38.214 mentioned above) may be used to determine the minimum HARQ-ACK timeline until the end of PDSCH 2, since the two PDSCHs overlap each other. Additional mitigations may be included to account for the UE interference handling timeline. Solution 4.2

[0042] In some embodiments, for the FDM Scheme A SDCI MTRP scheme, the same scheme as in Rel-15 (3GPP TS 38.214 mentioned above) may be used to determine the minimum HARQ-ACK timeline until the end of PDSCH 2. Solution 4.3

[0043] In some embodiments, for the FDM Scheme B SDCI MTRP scheme, the same scheme as in Rel-15 (3GPP TS 38.214 mentioned above) may be used to determine the minimum HARQ-ACK timeline until the end of PDSCH 2, and mitigations may be included, for example, when the UE supports CW soft-combining. Solution 4.4

[0044] In some embodiments, for the Scheme 4 SDCI MTRP scheme, the same scheme as Rel-15 (3GPP TS 38.214 mentioned above) may be used to determine the minimum HARQ-ACK timeline until the end of PDSCH 2, based on the first PDSCH transmission opportunity.

[0045] FIG. 1 illustrates a capability reporting process 100 according to some embodiments.

[0046] In block 102, a UE configuration for multi-DCI multi-TRP operation and single DCI multi-TRP operation is determined. In some embodiments, a UE configuration for only multi-DCI multi-TRP operation is determined. In some embodiments, a UE configuration for only single DCI multi-TRP operation is determined. In some embodiments, a UE configuration for both multi-DCI multi-TRP operation and single DCI multi-TRP operation is determined.

[0047] In block 104, for the determined multi-DCI multi-TRP operation and / or single-DCI multi-TRP operation, a PDSCH processing capability for a timing offset between the PDSCH and HARQ-ACK is determined. In some embodiments, for a timing offset between the PDSCH and HARQ-ACK, PDSCH processing capability 1 uses normal HARQ-ACK feedback. In some embodiments, for a timing offset between the PDSCH and HARQ-ACK, PDSCH processing capability 2 uses low-latency HARQ-ACK feedback.

[0048] In some embodiments, the PDSCH processing capability is determined as PDSCH processing capability 1. In some embodiments, the PDSCH processing capability is determined as PDSCH processing capability 2.

[0049] In some embodiments, PDSCH processing capability 2 does not apply to multi-DCI multi-TRP operation. For example, when a UE is configured with multi-DCI multi-TRP operation, the UE may not operate with PDSCH processing capability 2. In another example, when all UEs are configured with multi-DCI multi-TRP operation, none of the UEs may operate with PDSCH processing capability 2.

[0050] In some embodiments, PDSCH processing capability 2 applies to multi-DCI multi-TRP operation. For example, when a UE is configured with multi-DCI multi-TRP operation, the UE may operate with PDSCH processing capability 2. In another example, when all UEs are configured with multi-DCI multi-TRP operation, all UEs may operate with PDSCH processing capability 2.

[0051] In some embodiments, a UE may only support PDSCH Capability 2 for Multi-DCI Multi-TRP under certain conditions. For example, a UE may support PDSCH Capability 2 for Multi-DCI Multi-TRP when there is one, a subset, or all of the following: no out-of-order (OOO) scheduling from PDCCH to PDSCH, no out-of-order (OOO) scheduling from PDSCH to HARQ-ACK, no joint HARQ-ACK feedback, no overlap in time domain scheduling, no overlap in frequency domain scheduling, or no cross-carrier scheduling.

[0052] In some embodiments, PDSCH processing capability 2 does not apply to single DCI multi-TRP. For example, when a UE is configured with single DCI multi-TRP operation, the UE may not operate with PDSCH processing capability 2. In another example, when all UEs are configured with single DCI multi-TRP operation, none of the UEs may operate with PDSCH processing capability 2.

[0053] In some embodiments, PDSCH processing capability 2 applies to single DCI multi-TRP. For example, when a UE is configured with single DCI multi-TRP operation, the UE may operate with PDSCH processing capability 2. In another example, when all UEs are configured with single DCI multi-TRP operation, all UEs may operate with PDSCH processing capability 2.

[0054] In block 106, support of the determined PDSCH processing capability is indicated. In some embodiments, the UE may indicate support for PDSCH Capability 2 for multiple DCIs and multiple TRPs. For example, the UE may generate and issue or transmit a report to indicate support. The report may be issued by the UE per feature set per component carrier (FSPC) (per CC per band per band combination), per feature set (FS), or per band. In some embodiments, the UE may indicate support for PDSCH Capability 2 for single DCI and multiple TRPs. For example, the UE may issue a report to indicate support. The report may be in a bitmap format to cover all five different single DCI and multiple TRP schemes (e.g., SDM, FDM Scheme A, FDM Scheme B, TDM Scheme A, Scheme 4). The report may be issued by the UE per FSPC (per CC per band per band combination), per FS (per band per band combination), or per band.

[0055] In block 108, a PUSCH processing capability for a timing offset between the PDCCH and the PUSCH is determined for the determined multi-DCI multi-TRP operation and / or single-DCI multi-TRP operation. In some embodiments, for a timing offset between the PDCCH and the PUSCH, PUSCH processing capability 1 uses normal PUSCH processing. In some embodiments, for a timing offset between the PDCCH and the PUSCH, PUSCH processing capability 2 uses low-latency PUSCH processing.

[0056] In some embodiments, the PUSCH processing capability is determined as PUSCH processing capability 1. In some embodiments, the PUSCH processing capability is determined as PUSCH processing capability 2.

[0057] In some embodiments, PUSCH processing capability 2 does not apply to multi-DCI multi-TRP. For example, when a UE is configured with multi-DCI multi-TRP operation, the UE may not operate with PUSCH processing capability 2. In another example, when all UEs are configured with multi-DCI multi-TRP operation, none of the UEs may operate with PUSCH processing capability 2.

[0058] In some embodiments, the UE may support PUSCH capability 2 for multi-DCI multi-TRP under certain conditions, for example, the UE may support PUSCH capability 2 for multi-DCI multi-TRP without out-of-order (OOO) scheduling from PUSCH to PDCCH.

[0059] In block 110, support of the determined PUSCH processing capability is indicated. In some embodiments, the UE may indicate support for PUSCH capability 2 for multiple DCIs and multiple TRPs. For example, the UE may generate a report to indicate the support and issue or transmit the report. The report may be issued by the UE per FSPC (per CC per band per band combination), per FS (per band per band combination), or per band.

[0060] In some embodiments, the reports of blocks 106 and 110 may be combined such that a combined report including the reports of blocks 106 and 110 is generated and then published or transmitted.

[0061] With respect to blocks 104 and 108, in some embodiments, a UE may only support PDSCH and / or PUSCH Capability 2 with processing timeline relaxation. For example, the processing time relaxation may be based on UE reporting or hard-coded herein, e.g., processing time relaxation may be used independently or jointly for multi-DCI multi-TRP PDSCH, multi-DCI multi-TRP PUSCH, and single-DCI multi-TRP PDSCH in each of the five schemes (e.g., SDM, FDM Scheme A, FDM Scheme B, TDM Scheme A, Scheme 4).

[0062] 2 shows a diagram 200 illustrating PDSCHs according to TDM scheme A, according to some embodiments. Here, two PDSCHs, PDSCH 1 (202) and PDSCH 2 (204), are located within a slot 208. PDSCH 1 (202) and PDSCH 2 (204) are separated by an offset 206 within the slot 208. For example, the offset 206 is between the last symbol of PDSCH 1 and the first symbol of PDSCH 2. In some embodiments, PDSCH 1 and PDSCH 2 have the same duration and frequency resource allocation. In some embodiments, PDSCH 1 and PDSCH 2 have different durations and / or frequency resource allocations. In some embodiments, a transport block (TB) is transmitted twice by a UE per slot. In some embodiments, the offset 206 between PDSCH 1 (202) and PDSCH 2 (204) is configured via RRC.

[0063] In some embodiments, PDSCH 1 (202) and PDSCH 2 (204) each include a set of symbols that describe their payloads. In some embodiments, the area between the end of PDSCH 1 (202) (e.g., the last symbol of PDSCH 1) and the beginning of PDSCH 2 (204) (e.g., the first symbol of PDSCH 2), as indicated by offset 206, includes one or more blank symbols corresponding to the duration of offset 206.

[0064] As mentioned above, the processing timeline for the PDSCH in TDM scheme A is described in 3GPP TS 38.214. As described in 3GPP TS 38.314, if the first uplink symbol of the PUCCH carrying the HARQ-ACK information, defined by the allocated HARQ-ACK timing K1 and the PUCCH resources used, including the effect of timing advance, does not start earlier than symbol L1, L1 is set to T proc,1 =(N1+d 1,1 +d2)(2048+144)·k2 -μ T c +T ext is defined as the next uplink symbol in which the CP starts after the end of the last symbol of the PDSCH carrying the TB has been acknowledged, and the UE shall provide a valid HARQ-ACK message. The following defines the parameters of this equation:

[0065] For UE processing capability 1: If the PDSCH is mapping type B as given in clause 7.4.1.1 of [4, TS 38.211], If the number of allocated PDSCH symbols is L ≥ 7, then d 1,1 =0, If the number of allocated PDSCH symbols is L ≥ 4 and L ≤ 6, then d 1,1 = 7-L, If the number of allocated PDSCH symbols is L=3, then d 1,1 = 3 + min(d,1), where d is the number of overlapping symbols of the scheduled PDCCH and the scheduled PDSCH; If the number of allocated PDSCH symbols is 2, then d 1,1 = 3 + d, where d is the number of overlapping symbols of the scheduled PDCCH and the scheduled PDSCH.

[0066] For UE processing capability 2: If the PDSCH is mapping type B as given in clause 7.4.1.1 of [4, TS 38.211], If the number of allocated PDSCH symbols is L ≥ 7, then d 1,1 =0, If the number of allocated PDSCH symbols is L ≥ 3 and L ≤ 6, then d 1,1 is the number of overlapping symbols of the scheduled PDCCH and the scheduled PDSCH, If the number of allocated PDSCH symbols is 2, If the scheduling PDCCH is within the 3-symbol CORESET and the CORESET and the PDSCH have the same starting symbol, 1,1 = 3, - if not, d 1,1 is the number of overlapping symbols between the scheduling PDCCH and the scheduled PDSCH.

[0067] In some embodiments, the HARQ-ACK processing timing K1 is determined as described with reference to Figures 3 to 5. In some embodiments, a minimum HARQ-ACK timing K1 is determined.

[0068] FIG. 3 illustrates a process 300 for PDSCH processing according to some embodiments.

[0069] In block 302, single DCI multi-TRP PDSCH operation is determined. In some embodiments, the single DCI multi-TRP PDSCH operation is TDM-A operation. In some embodiments, this determination includes determining that the UE is configured for single DCI multi-TRP PDSCH operation. In some embodiments, this determination includes determining that the UE is configured for TDM-A operation.

[0070] In block 304, a first PDSCH and a second PDSCH (e.g., PDSCH 1 (202) and PDSCH 2 (204)) within a slot (e.g., slot 208) are determined according to the determined single DCI multi-TRP PDSCH operation. For example, the first PDSCH and the second PDSCH may be used in the determined single DCI multi-TRP PDSCH operation. In some embodiments, a duration and / or frequency resource allocation for each PDSCH is determined. In some embodiments, for example, when the single DCI multi-TRP PDSCH operation is TDM Scheme A, the duration and / or frequency resource allocation for the first PDSCH and the second PDSCH are the same.

[0071] At block 306, HARQ-ACK timing for the first PDSCH and the second PDSCH is determined. In some embodiments, the determined HARQ-ACK timing is a minimum HARQ-ACK timing. In some embodiments, one or more symbols of the first PDSCH are used to determine the minimum HARQ-ACK timing. In some embodiments, one or more symbols of the first PDSCH and the second PDSCH are used to determine the minimum HARQ-ACK timing.

[0072] In some embodiments, the minimum HARQ-ACK timing is until the end of the second PDSCH. Here, for example, for a first PDSCH and a second PDSCH in a slot, the minimum HARQ-ACK processing timeline or timing K1 until the end of the second PDSCH may define the timing or duration between the second PDSCH and the corresponding HARQ-ACK in the PUCCH. The timing or duration may be defined by the last symbol of the second PDSCH (e.g., the last PDSCH repetition) and the first symbol of the PUCCH carrying the corresponding HARQ-ACK. This timing or duration may provide the UE with time to process the PDSCH.

[0073] In some embodiments, determining the minimum HARQ-ACK timing until the end of the second PDSCH may be based only on the first PDSCH, e.g., only symbols from the first symbol of the first PDSCH (e.g., PDSCH 1 (202)) to the last symbol of the first PDSCH are considered for PDSCH transmission and for determining the minimum HARQ-ACK timing.

[0074] In some embodiments, the minimum HARQ-ACK processing timing until the end of the second PDSCH may consider all symbols from the beginning of the first PDSCH to the end of the second PDSCH, with blank symbols between the first and second PDSCHs being counted. For example, all symbols from the first symbol of the first PDSCH to the last symbol of the second PDSCH may be considered for PDSCH transmission and to determine the minimum HARQ-ACK timing. For example, the duration L may correspond to the number of symbols overlapping with the CORESET / scheduling PDCCH. For example, if the first PDSCH has four symbols, followed by a two-symbol gap (e.g., two blank symbols), followed by a second PDSCH having four symbols, all symbols are considered for the first PDSCH, the second PDSCH, and the gap. Therefore, the duration L = 4 symbols of the first PDSCH + 2 symbols of the gap + 4 symbols of the second PDSCH = 10.

[0075] In some embodiments, the minimum HARQ-ACK processing timeline up to the end of the second PDSCH may consider all symbols in both the first PDSCH and the second PDSCH. For example, all symbols in the first PDSCH and the second PDSCH, the union, may be considered, but blank symbols between the first PDSCH and the second PDSCH (e.g., in the offset region between the two) may not be counted for PDSCH transmission and to determine the minimum HARQ-ACK timing. For example, duration L may correspond to the number of symbols overlapping with the CORESET / scheduling PDCCH. For example, if the first PDSCH has four symbols, followed by a two-symbol gap (e.g., two blank symbols), followed by a second PDSCH having four symbols, only the symbols for the first PDSCH and the second PDSCH are considered. The symbols in the gap are not considered. Therefore, duration L = 4 symbols of the first PDSCH + 4 symbols of the second PDSCH = 8.

[0076] 4 shows a diagram 400 illustrating PDSCHs according to TDM scheme A, according to some embodiments. Here, two PDSCHs, a first PDSCH (PDSCH 1 (402)) and a second PDSCH (PDSCH 2 (404)), are separated by an offset 406. In some embodiments, the first PDSCH and the second PDSCH have the same duration and frequency resource allocation. In some embodiments, the first PDSCH and the second PDSCH have different durations and / or frequency resource allocations. In some embodiments, a transport block (TB) is transmitted twice by a UE per slot. In some embodiments, the offset 406 between the first PDSCH 402 and the second PDSCH 404 is configured via RRC.

[0077] As shown in diagram 400, an initial minimum HARQ-ACK processing timing k1_1 is indicated by item 408, and an initial minimum HARQ-ACK processing timing k1_2 is indicated by item 410. k1_1 and k1_2 are used to determine an overall minimum HARQ-ACK processing time K1, as described below in connection with FIG.

[0078] 5 illustrates a process 500 for determining an overall minimum HARQ-ACK processing time K1 using values ​​k1_1 and k1_2. Thus, the minimum HARQ-ACK processing timeline until the end of the second PDSCH is now jointly based on the first PDSCH (PDSCH 1 (402)) and the second PDSCH (PDSCH 2 (404)). In some embodiments, process 500 mirrors the processing of example blocks 304 and 306 of process 300 shown in FIG. 3.

[0079] In block 502, a minimum HARQ-ACK processing timing k1_1 is determined for the first PDSCH.

[0080] In block 504, a minimum HARQ-ACK processing timing k1_2 is determined for the second PDSCH.

[0081] In block 506, an overall minimum HARQ-ACK processing timing (also referred to as time) K1 for the first PDSCH and the second PDSCH is determined using k1_1 and k1_2. In some embodiments, the overall minimum HARQ-ACK processing time K1 = max(k1_1 - Offset, 0) + k1_2 + C. In some embodiments, the overall minimum HARQ-ACK processing time K1 = max(k1_1, k1_2) + C. In some embodiments, the overall minimum HARQ-ACK processing time K1 = k1_1 + k1_2 + C. For example, the offset may be the offset between the first PDSCH and the second PDSCH (e.g., offset 406). For example, the offset may be the offset between the last symbol of the first PDSCH and the first symbol of the second PDSCH. For example, C may be a constant, may be 0, or may be set to a value that provides additional timeline mitigation. For example, "max(X,Y)" means that the maximum value of the sequence of values ​​X, Y inside the brackets is selected. Thus, if X is greater than Y, then max(X,Y)=X.

[0082] Note that in some embodiments, for multi-DCI based multi-TRP, the minimum HARQ-ACK timeline by the end of the second PDSCH (PDSCH 2 (404)) uses the same process as described above for TDM scheme A. For example, determining the minimum HARQ-ACK for multi-DCI based multi-TRP may be performed using one or more of the techniques described in Figures 2-5.

[0083] In some embodiments, PDSCH processing capabilities for other single DCI MTRPs may also be provided.

[0084] The processing timeline for the PDSCH in TDM scheme A is described in 3GPP TS 38.214 and may also be used in the following embodiments. As described in 38.314, if the first uplink symbol of the PUCCH carrying the HARQ-ACK information, defined by the allocated HARQ-ACK timing K1 and the PUCCH resources used, including the effect of timing advance, does not start earlier than symbol L1, L1 is is defined as the next uplink symbol in which the CP starts after the end of the last symbol of the PDSCH carrying the TB has been acknowledged, and the UE shall provide a valid HARQ-ACK message. The following defines the parameters of this equation:

[0085] For UE processing capability 1: If the PDSCH is mapping type B as given in clause 7.4.1.1 of [4, TS 38.211], If the number of allocated PDSCH symbols is L ≥ 7, then d 1,1 =0, If the number of allocated PDSCH symbols is L ≥ 4 and L ≤ 6, then d 1,1 = 7-L, If the number of allocated PDSCH symbols is L=3, then d 1,1 = 3 + min(d,1), where d is the number of overlapping symbols of the scheduled PDCCH and the scheduled PDSCH; If the number of allocated PDSCH symbols is 2, then d 1,1 = 3 + d, where d is the number of overlapping symbols of the scheduled PDCCH and the scheduled PDSCH.

[0086] For UE processing capability 2: If the PDSCH is mapping type B as given in clause 7.4.1.1 of [4, TS 38.211], If the number of allocated PDSCH symbols is L ≥ 7, then d 1,1 =0, If the number of allocated PDSCH symbols is L ≥ 3 and L ≤ 6, then d 1,1 is the number of overlapping symbols of the scheduled PDCCH and the scheduled PDSCH, If the number of allocated PDSCH symbols is 2, If the scheduling PDCCH is within the 3-symbol CORESET and the CORESET and the PDSCH have the same starting symbol, 1,1 = 3, - if not, d 1,1 is the number of overlapping symbols between the scheduling PDCCH and the scheduled PDSCH.

[0087] In some embodiments, for the SDM SDCI MTRP scheme, the same scheme as in Rel-15 (3GPP TS 38.214 mentioned above) may be used to determine the minimum HARQ-ACK timeline until the end of PDSCH 2, since the two PDSCHs overlap each other. Additional mitigations may be included to account for the UE interference handling timeline.

[0088] In some embodiments, for the FDM Scheme A SDCI MTRP scheme, the same scheme as in Rel-15 (3GPP TS 38.214 mentioned above) may be used to determine the minimum HARQ-ACK timeline until the end of PDSCH 2.

[0089] In some embodiments, for the FDM Scheme B SDCI MTRP scheme, the same scheme as in Rel-15 (3GPP TS 38.214 mentioned above) may be used to determine the minimum HARQ-ACK timeline until the end of PDSCH 2, and mitigations may be included, for example, when the UE supports CW soft-combining 2.

[0090] In some embodiments, for the Scheme 4 SDCI MTRP scheme, the same scheme as Rel-15 (3GPP TS 38.214 mentioned above) may be used to determine the minimum HARQ-ACK timeline until the end of PDSCH 2, based on the first PDSCH transmission opportunity.

[0091] 6 illustrates an exemplary architecture of a system 600 of networks in accordance with various embodiments. The following description is provided for the exemplary system 600 operating in conjunction with LTE system standards and 5G or NR system standards as provided by 3GPP technical specifications. However, the exemplary embodiments are not limited in this respect, and the described embodiments may be applied to other networks that would benefit from the principles described herein, such as future 3GPP systems (e.g., sixth generation (6G) systems), IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), etc.

[0092] As shown in FIG. 6, the system 600 includes a UE 622 and a UE 620 . In this example, UE 622 and UE 620 are shown as smartphones (e.g., handheld touchscreen mobile computing devices capable of connecting to one or more cellular networks), but may include any mobile or non-mobile computing device, such as a consumer electronics device, a mobile phone, a smartphone, a feature phone, a tablet computer, a wearable computing device, a personal digital assistant (PDA), a pager, a wireless handset, a desktop computer, a laptop computer, an in-vehicle infotainment (IVI), an in-vehicle entertainment (ICE) device, an instrument cluster (IC), a head-up display (HUD) device, an on-board diagnostics (OBD) device, a dash-top mobile equipment (DME), a mobile data terminal (MDT), an electronic engine management system (EEMS), an electronic / engine control unit (ECU), an electronic engine / engine control module (ECM), an embedded system, a microcontroller, a control module, an engine management system (EMS), a network or "smart" appliance, an MTC device, an M2M, an IoT device, or the like.

[0093] In some embodiments, UE 622 and / or UE 620 may be IoT UEs, which may have a network access layer designed for low-power IoT applications utilizing short-lived UE connections. IoT UEs may utilize technologies such as M2M or MTC to exchange data with MTC servers or devices via PLMN, ProSe, or D2D communications, sensor networks, or IoT networks. M2M or MTC data exchanges may be machine-initiated data exchanges. An IoT network refers to IoT UEs connecting with each other, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) via short-lived connections. IoT UEs may run background applications (e.g., keep-alive messages, status updates, etc.) to facilitate IoT network connectivity.

[0094] The UE 622 and the UE 620 may be configured to connect to, communicatively couple with, for example, an access node or radio access node (denoted as (R)AN 608). In an embodiment, the (R)AN 608 may be an NG RAN or SG RAN, an E-UTRAN, or a legacy RAN such as a UTRAN or GERAN. As used herein, terms such as "NG RAN" may refer to an (R)AN 608 operating in an NR or SG system, and terms such as "E-UTRAN" may refer to an (R)AN 608 operating in an LTE or 4G system. The UE 622 and the UE 620 utilize connections (or channels) (denoted as connection 604 and connection 602, respectively), each of which comprises a physical communication interface or layer (described in further detail below).

[0095] In this example, connection 604 and connection 602 are shown as air interfaces for enabling a communicative coupling and may correspond to a cellular communication protocol such as a GSM protocol, a CDMA network protocol, a PTT protocol, a POC protocol, a UMTS protocol, a 3GPP LTE protocol, a 5G protocol, an NR protocol, and / or any of the other communication protocols described herein. In an embodiment, UE 622 and UE 620 may exchange communication data directly via ProSe interface 610. ProSe interface 610 may alternatively be referred to as sidelink (SL) interface 110 and may comprise one or more logical channels, including, but not limited to, a PSCCH, a PSSCH, a PSDCH, and a PSBCH.

[0096] The UE 620 is shown configured to access the AP 612 (also referred to as a “WLAN node,” “WLAN,” “WLAN terminal,” “WT,” etc.) via a connection 624. The connection 624 may comprise a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, and the AP 612 would comprise a Wireless Fidelity (Wi-Fi®) router. In this example, the AP 612 may be connected to the Internet without connecting to a wireless system's core network (described in further detail below). In various embodiments, the UE 620, the (R)AN 608, and the AP 612 may be configured to utilize LWA operation and / or LWIP operation. LWA operation may include the UE 620 in RRC_CONNECTED being configured by the RAN node 614 or RAN node 616 to utilize LTE and WLAN radio resources. LWIP operations may include the UE 620 using WLAN radio resources (e.g., connection 624) via IPsec protocol tunneling to authenticate and encrypt packets (e.g., IP packets) sent over the connection 624. The IPsec tunneling may include encapsulating the entire original IP packet and adding a new packet header, thereby protecting the IP packet's original header.

[0097] The (R)AN 608 may include one or more AN nodes, such as RAN node 614 and RAN node 616, that enable connection 604 and connection 602. As used herein, the terms “access node,” “access point,” etc. may refer to equipment that provides wireless baseband functionality for data and / or voice connectivity between a network and one or more users. These access nodes may be referred to as BSs, gNBs, RAN nodes, eNBs, NodeBs, RSUs TRxPs, TRPs, etc., and may include earth stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the terms “NG RAN node” etc. may refer to a RAN node operating in an NR or SG system (e.g., gNB), and the terms “E-UTRAN node” etc. may refer to a RAN node operating in an LTE or 4G system 600 (e.g., eNB). According to various embodiments, the RAN node 614 or the RAN node 616 may be implemented as one or more of a macrocell base station and / or a dedicated physical device such as a femtocell, picocell, or other similar cell having a smaller coverage area, lower user capacity, or higher bandwidth compared to a macrocell.

[0098] In some embodiments, all or part of the RAN node 614 or RAN node 616 may be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as a CRAN and / or virtual baseband unit pool (vBBUP). In these embodiments, the CRAN or vBBUP may implement a RAN function split such as a PDCP split, where the RRC and PDCP layers are operated by the CRAN / vBBUP and other L2 protocol entities are operated by individual RAN nodes (e.g., the RAN node 614 or RAN node 616), a MAC / PHY split, where the RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBUP and the PHY layer is operated by individual RAN nodes (e.g., the RAN node 614 or RAN node 616), or a "lower PHY" split, where the RRC, PDCP, RLC, MAC, and upper portions of the PHY layer are operated by the CRAN / vBBUP and the lower portions of the PHY layer are operated by individual RAN nodes. This virtualized framework allows freed processor cores of the RAN node 614 or RAN node 616 to run other virtualized applications. In some implementations, each RAN node may represent an individual gNB-DU connected to a gNB-CU via an individual F1 interface (not shown in FIG. 6). In these implementations, the gNB-DUs may include one or more remote radio heads or RFEMs, and the gNB-CU may be operated by a server located within the RAN 608 (not shown) or by a server pool in a manner similar to CRAN / vBBUP. Additionally or alternatively, one or more of the RAN node 614 or RAN node 616 may be a next-generation eNB (ng-eNB), which is a RAN node that provides E-UTRA user plane and control plane protocol termination for the UE 622 and UE 620 and connects to 5GC via an NG interface (described below). In a V2X scenario, one or more of the RAN node 614 or RAN node 616 may be or function as an RSU.

[0099] The term “roadside unit” or “RSU” may refer to any transport infrastructure entity used for V2X communications. The RSU may be implemented in or by an appropriate RAN node 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 RSU implemented in or by an eNB may be referred to as an “eNB-type RSU,” an RSU implemented in or by a gNB may be referred to as a “gNB-type RSU,” etc. In one embodiment, the RSU is a computing device coupled to radio frequency circuits located at the roadside that provides connectivity support to passing vehicular UEs (vUEs). The RSU may also include internal data storage circuitry for storing applications / software for detecting and controlling intersection map geometry, traffic statistics, media, and ongoing vehicular and pedestrian traffic. The RSU may operate in the 5.9 GHz Direct Short Range Communication (DSRC) band to provide very low-latency communications necessary for high-speed events such as collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU may operate in the cellular V2X band to provide the aforementioned low-latency communications and other cellular communication services. Additionally or alternatively, the RSU may operate as a Wi-Fi hotspot (2.4 GHz band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communications. Some or all of the radio frequency circuitry of the computing device(s) and 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 and / or a backhaul network.

[0100] The RAN node 614 and / or the RAN node 616 may terminate air interface protocols and may be the first point of contact for the UE 622 and the UE 620. In some embodiments, the RAN node 614 and / or the RAN node 616 may perform various logical functions for the (R)AN 608, including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0101] In an embodiment, the UEs 622 and 620 may be configured to communicate with each other and / or the RAN node 614 and / or the RAN node 616 using OFDM communication signals over multi-carrier communication channels in accordance with various communication techniques, such as, but not limited to, OFDMA communication techniques (e.g., for downlink communication) or SC-FDMA communication techniques (e.g., for uplink and ProSe or sidelink communication), although the scope of the embodiments is not limited in this respect. The OFDM signals may include multiple orthogonal subcarriers.

[0102] In some embodiments, a downlink resource grid can be used for downlink transmissions from either the RAN node 614 and / or the RAN node 616 to the UEs 622 and 620, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, also called a resource grid or time-frequency resource grid, which represents the downlink physical resources within each slot. Such a time-frequency plane representation is common in OFDM systems, making radio resource allocation intuitive. Each column and row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit of the resource grid is referred to as a resource element. Each resource grid contains a number of resource blocks, which represent the mapping of a particular physical channel to resource elements. Each resource block contains a set of resource elements, which in the frequency domain can represent the smallest amount of resources that can currently be allocated. There are several different physical downlink channels conveyed using such resource blocks.

[0103] According to various embodiments, UE 622, UE 620, and RAN node 614 and / or RAN node 616 communicate data (e.g., transmit and receive) over licensed media (also referred to as "licensed spectrum" and / or "licensed band") and unlicensed shared media (also referred to as "unlicensed spectrum" and / or "unlicensed band"). The licensed spectrum may include channels operating in a frequency range from about 400 MHz to about 3.8 GHz, and the unlicensed spectrum may include the 5 GHz band.

[0104] To operate in the unlicensed spectrum, the UEs 622, 620 and the RAN nodes 614, 616 may operate using LAA, eLAA, and / or feLAA mechanisms. In these implementations, the UEs 622, 620 and the RAN nodes 614 or 616 may perform one or more known medium sensing and / or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied before transmitting in the unlicensed spectrum. The medium / carrier sensing operations may be performed in accordance with a listen-before-talk (LBT) protocol.

[0105] LBT is a mechanism by which devices (e.g., UE 622, UE 620, and RAN node 614 or RAN node 616) sense the medium (e.g., a channel or carrier frequency) and transmit when the medium is sensed to be idle (or when a particular channel within the medium is sensed to be unoccupied). The medium sensing operation may include CCA, which utilizes at least ED to determine the presence or absence of other signals on the channel to determine whether the channel is occupied or free. This LBT mechanism enables cellular / LAA networks to coexist with current occupied systems and with other LAA networks in unlicensed spectrum. ED may include sensing RF energy over the intended transmission band for a period of time and comparing the sensed RF energy to a predetermined or configured threshold.

[0106] Typically, the currently occupying system in the 5 GHz band is a WLAN based on IEEE 802.11 technology. WLAN employs a contention-based channel access mechanism called CSMA / CA. Here, when a WLAN node (e.g., a mobile station (MS), such as UE 622 or AP 612) attempts to transmit, the WLAN node may first perform CCA before transmitting. Furthermore, a backoff mechanism is used to avoid collisions in situations where two or more WLAN nodes simultaneously sense the channel as idle and transmit. The backoff mechanism may be a randomly sampled counter within the CWS, which is exponentially incremented upon collision occurrence and reset to its minimum value upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to CSMA / CA for WLAN. In some implementations, the LBT procedure for a DL or UL transmission burst containing a PDSCH or PUSCH transmission, respectively, can have an LAA contention window with a variable length between X and Y ECCA slots, where X and Y are the minimum and maximum values ​​of the CWS for LAA. In one embodiment, the minimum CWS for an LAA transmission may be 9 microseconds (μs), although the size of the CWS and MCOT (e.g., transmission burst) may be based on government regulatory requirements.

[0107] The LAA mechanism is based on the CA technology of the LTE-Advanced system. In CA, each aggregated carrier is called a CC. A CC can have a bandwidth of 1.4, 3, 5, 10, 15, or 20 MHz, and up to five CCs can be aggregated, resulting in a maximum aggregated bandwidth of 100 MHz. In FDD systems, the number of aggregated carriers can differ between DL and UL, and the number of UL CCs is equal to or less than the number of DL component carriers. In some cases, individual CCs can have a different bandwidth from other CCs. In TDD systems, the number of CCs and the bandwidth of each CC are typically the same for DL ​​and UL.

[0108] CA also includes individual serving cells providing individual CCs. For example, CCs in different frequency bands experience different path losses, so the coverage of the serving cells may differ. The primary serving cell or PCell can provide the PCC for both the UL and DL and handle RRC and NAS-related activities. Other serving cells are called SCells, and each SCell can provide a separate SCC for both the UL and DL. SCCs may be added and removed as needed, while changing the PCC may require the UE 622 to undergo a handover. In LAA, eLAA, and feLAA, some or all of the SCells may operate in the unlicensed spectrum (called "LAA SCells"), and the LAA SCells are supported by a PCell operating in the licensed spectrum. When a UE is configured with two or more LAA SCells, the UE can receive UL grants on the configured LAA SCells indicating different PUSCH starting positions within the same subframe.

[0109] The PDSCH carries user data and higher layer signaling to the UEs 622 and 620. The PDCCH carries, among other things, information regarding the transport format and resource allocation associated with the PDSCH channel. The PDCCH may also inform the UEs 622 and 620 of the transport format, resource allocation, and HARQ information associated with the uplink shared channel. Typically, downlink scheduling (allocation of control channel resource blocks and shared channel resource blocks to the UEs 620 in a cell) may be performed by either the RAN node 614 or the RAN node 616 based on channel quality information fed back from either the UEs 622 and 620. Downlink resource allocation information may be transmitted on the PDCCH used for each of the (e.g., assigned) UEs 622 and 620.

[0110] The PDCCH conveys control information using CCEs. Before being mapped to resource elements, PDCCH complex-valued symbols may first be organized into quadruplets and then shuffled using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, and each CCE may correspond to nine sets of four physical resource elements known as REGs. Four quadrature phase-shift keying (QPSK) symbols may be mapped to each REG. The PDCCH may be transmitted using one or more CCEs, depending on the size of the DCI and the channel conditions. There may be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation levels, L=1, 2, 4, or 8).

[0111] Some embodiments may use a concept for resource allocation for control channel information that is an extension of the concept described above. For example, some embodiments may utilize an EPDCCH that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more ECCEs. As above, each ECCE may correspond to nine sets of four physical resource elements known as EREGs. An ECCE may have other numbers of EREGs in some situations.

[0112] The RAN node 614 or the RAN node 616 may be configured to communicate with each other via an interface 630. In embodiments where the system 600 is an LTE system (e.g., where the CN 606 is the EPC), the interface 630 may be an X2 interface. The X2 interface may be defined between two or more RAN nodes (e.g., two or more eNBs) that connect to the EPC and / or between two eNBs that connect to the EPC. In some implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide a flow control mechanism for user data packets transferred over the X2 interface and may be used to communicate information regarding the distribution of user data between eNBs. For example, the X2-U may provide specific sequence number information for user data transferred from the MeNB to the SeNB, information regarding successful sequence delivery of PDCP PDUs from the SeNB to the UE 622 for user data, information regarding PDCP PDUs that were not delivered to the UE 622, information regarding the current minimum desired buffer size at the SeNB for transmitting UE user data, etc. The X2-C may provide intra-LTE access mobility functions, load management functions, and inter-cell interference coordination functions, including context transfer from the source eNB to the target eNB, user plane transport control, etc.

[0113] In embodiments where the system 600 is an SG or NR system (e.g., where the CN 606 is an SGC), the interface 630 may be an Xn interface. An Xn interface is defined between two or more RAN nodes (e.g., two or more gNBs) that connect to an SGC, between a RAN node 614 (e.g., a gNB) and an eNB that connect to an SGC, and / or between two eNBs (e.g., the CN 606) that connect to a 5GC. In some implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U provides non-guaranteed delivery of user plane PDUs and may support / provide data forwarding and flow control functions. The Xn-C may provide mobility support for a connected mode UE 622 (e.g., CM-connected), including management and error handling functions, functions for managing the Xn-C interface, and functions for managing UE mobility for connected mode between one or more RAN nodes 614 or 616. Mobility support may include context transfer from the old (source) serving RAN node 614 to the new (target) serving RAN node 616 and control of user plane tunnels between the old (source) serving RAN node 614 and the new (target) serving RAN node 616. To carry user plane PDUs, the protocol stack of the Xn-U may include a transport network layer built on an Internet Protocol (IP) transport layer and a GTP-U layer on top of the UDP and / or IP layer(s). The Xn-C protocol stack may include an application layer signaling protocol (referred to as the Xn Application Protocol (Xn-AP)) and a transport network layer built on SCTP. SCTP may sit above the IP layer and provide guaranteed delivery of application layer messages. At the transport IP layer, point-to-point transmission is used to deliver signaling PDUs.In other implementations, the Xn-U protocol stack and / or the Xn-C protocol stack may be the same as or similar to the user plane and / or control plane protocol stack(s) shown and described herein.

[0114] The (R)AN 608 is shown in this embodiment as communicatively coupled to the core network of the CN 606. The CN 606 may comprise one or more network elements 632 configured to provide various data and communication services to customers / subscribers (e.g., users of UEs 622 and 620) connected to the CN 606 via the (R)AN 608. The components of the CN 606 may be implemented in a single physical node or separate physical nodes, including components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some embodiments, NFV may be utilized to virtualize any or all of the above-described network node functions via executable instructions stored on one or more computer-readable storage media (described in further detail below). A logical instantiation of the CN 606 may be referred to as a network slice, and a logical instantiation of a portion of the CN 606 may be referred to as a network sub-slice. The NFV architecture and infrastructure may be used to virtualize one or more network functions on physical resources, including a combination of industry-standard server hardware, storage hardware, or switches, or may be performed by dedicated hardware. In other words, an NFV system can be used to run a virtual or reconfigurable implementation of one or more EPC components / functions.

[0115] In general, the application server 618 may be an element that provides applications that use IP bearer resources with the core network (e.g., UMTS PS domain, LTE PS data services, etc.). The application server 618 may also be configured to support one or more communication services (e.g., VoIP sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs 622 and 620 via the EPC. The application server 618 may communicate with the CN 606 via the IP communication interface 636.

[0116] In an embodiment, the CN 606 may be an SGC, and the (R)AN 116 may be connected to the CN 606 via an NG interface 634. In an embodiment, the NG interface 634 may be divided into two parts: an NG-User Plane (NG-U) interface 626 that carries traffic data between the RAN node 614 or RAN node 616 and the UPF, and an S1-Control Plane (NG-C) interface 628 that is a signaling interface between the RAN node 614 or RAN node 616 and the AMF.

[0117] In an embodiment, the CN 606 may be an SG CN, while in other embodiments, the CN 606 may be an EPC. When the CN 606 is an EPC, the (R)AN 116 may be connected to the CN 606 via an S1 interface 634. In an embodiment, the S1 interface 634 may be divided into two parts: an S1 user plane (S1-U) interface 626 that carries traffic data between the RAN node 614 or RAN node 616 and the S-GW, and an S1-MME interface 628 that is a signaling interface between the RAN node 614 or RAN node 616 and the MME.

[0118] 7 illustrates an example of infrastructure equipment 700 in accordance with various embodiments. Infrastructure equipment 700 may be implemented as a base station, a radio head, a RAN node, an AN, an application server, and / or any other element / device described herein. In other examples, infrastructure equipment 700 may be implemented in or by a UE.

[0119] The infrastructure equipment 700 includes application circuitry 702, baseband circuitry 704, one or more radio front-end modules (RFEMs) 706, memory circuitry 708, a power management integrated circuit (denoted PMIC 710), power T circuitry 712, network controller circuitry 714, network interface connector 720, satellite positioning circuitry 716, and user interface circuitry 718. In some embodiments, the device infrastructure equipment 700 may include additional elements, such as memory / storage, a display, a camera, sensors, or input / output (I / O) interfaces. In other embodiments, the components described below may be included in two or more devices. For example, the circuits may be included separately in two or more devices for a CRAN, vBBU, or other similar implementation. The application circuitry 702 may include, but is not limited to, one or more processors (or processor cores), cache memory, low dropout regulators (LDOs), an interrupt controller, SPI, I / O, etc. 2The application circuitry 702 may include circuits such as a serial interface such as a Universal Programmable Serial Interface Module (UPLC), a real-time clock (RTC), timer counters including interval and watchdog timers, general-purpose input / output (I / O or IO), a memory card controller such as a Secure Digital (SD) Multimedia Card (MMC), a Universal Serial Bus (USB) interface, a Mobile Industry Processor Interface (MIPI) interface, and a Joint Test Access Group (JTAG) test access port. The processor (or core) of the application circuitry 702 may be coupled to or may include memory / storage elements and may be configured to execute instructions stored in the memory / storage elements to enable various applications or operating systems to run on the infrastructure equipment 700. In some implementations, the memory / storage elements may be on-chip memory circuits, which may include any suitable volatile and / or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, and / or any other type of memory device technology as described herein.

[0120] The processor(s) of application circuitry 702 may include, for example, one or more processor cores (CPUs), one or more application processors, one or more graphics processing units (GPUs), one or more reduced instruction set computing (RISC) processors, one or more Acorn RISC Machine (ARM) processors, one or more complex instruction set computing (CISC) processors, one or more digital signal processors (DSPs), one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors, controllers, or any suitable combination thereof. In some embodiments, application circuitry 702 may comprise or be a dedicated processor / controller operating in accordance with various embodiments herein. As an example, the processor(s) of application circuit 702 may include one or more Intel Pentium®, Core®, or Xeon® processor(s), Advanced Micro Devices (AMD) Ryzen® processor(s), Accelerated Processing Unit (APU), or Epyc® processor, ARM-based processor(s) licensed from ARM Holdings Ltd., such as the ARM Cortex-A family processors, and processors of MIPS-based designs offered by MIPS Technologies, Inc., such as the ThunderX2® offered by Cavium™, Inc., MIPS Warrior P-class processors, etc. In some embodiments, infrastructure equipment 700 may not utilize application circuit 702 and instead may include a dedicated processor / controller for processing IP data received from, for example, an EPC or 5GC.

[0121] In some implementations, the application circuitry 702 may include one or more hardware accelerators, which may be a microprocessor, a programmable processing device, or the like. The one or more hardware accelerators may include, for example, a computer vision (CV) and / or a deep learning (DL) accelerator. By way of example, the programmable processing device may be one or more of a field programmable device (FPD) such as a field programmable gate array (FPGA), a programmable logic device (PLD) such as a complex PLD (CPLD), a high capacity PLD (HCPLD), an ASIC such as a structured ASIC, a programmable system on a chip (PSoC), or the like. In such implementations, the circuitry of the application circuitry 702 may comprise logic blocks or logic fabric and other interconnected resources that may be programmed to perform various functions, such as the procedures, methods, and functions of various embodiments described herein. In such an embodiment, the circuitry of the application circuit 702 may include memory cells (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), antifuses, etc.)) used to store logic blocks, logic fabric, data, etc., in look-up tables (LUTs), etc. The baseband circuit 704 may be implemented, for example, as a soldered substrate containing one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits.

[0122] User interface circuitry 718 may include one or more user interfaces designed to enable user interaction with infrastructure equipment 700 or peripheral component interfaces designed to enable peripheral component interaction with infrastructure equipment 700. User interfaces may include, but are not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., light-emitting diodes (LEDs)), a physical keyboard or keypad, a mouse, a touchpad, a touchscreen, a speaker or other audio-light emitting device, a microphone, a printer, a scanner, a headset, a display screen or device, etc. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power interface, etc.

[0123] The wireless front-end module 706 may comprise a millimeter-wave radio front-end module (RFEM) and one or more submillimeter-wave radio frequency integrated circuits (RFICs). In some implementations, the one or more submillimeter-wave RFICs may be physically separate from the millimeter-wave RFEM. The RFIC may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In alternative implementations, both millimeter-wave and submillimeter-wave wireless functionality may be implemented within the same physical wireless front-end module 706 that incorporates both millimeter-wave and submillimeter-wave antennas.

[0124] The memory circuitry 708 may include one or more of volatile memory, including dynamic random access memory (DRAM) and / or synchronous dynamic random access memory (SDRAM), and non-volatile memory (NVM), including high-speed electrically erasable memory (commonly referred to as flash memory), phase change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc., and may incorporate Intel® and Micron® three-dimensional (3D) cross point (XPOINT) memory. The memory circuitry 708 may be implemented as one or more of a solder-packaged integrated circuit, a socketed memory module, and a plug-in memory card.

[0125] The PMIC 710 may include a voltage regulator, a surge protector, a power alarm detection circuit, and one or more backup power sources, such as a battery or capacitor. The power alarm detection circuit may detect one or more of brownout (undervoltage) and surge (overvoltage) conditions. The power T-circuit 712 may supply power drawn from a network cable that provides both power and data connectivity to the infrastructure equipment 700 using a single cable.

[0126] The network controller circuitry 714 may provide connectivity to a network using a standard network interface protocol, such as Ethernet, Ethernet over a GRE tunnel, Ethernet over Multiprotocol Label Switching (MPLS), or some other suitable protocol. Network connectivity may be provided to and from the infrastructure equipment 700 via network interface connectors 720 using physical connections that may be electrical (commonly referred to as "copper wiring"), optical, or wireless. The network controller circuitry 714 may include one or more dedicated processors and / or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the network controller circuitry 714 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0127] The positioning circuitry 716 includes circuitry for receiving and decoding signals transmitted / broadcast by a Global Navigation Satellite System (GNSS) positioning network. Examples of navigation satellite constellations (or GNSS) include the United States' Global Positioning System (GPS), the Russian Global Navigation System (GLONASS), the European Union's Galileo system, the Chinese BeiDou navigation satellite system, regional navigation systems or GNSS augmentation systems (e.g., the Indian Regional Navigation System (NAVIC), the Japanese Quasi-Zenith Satellite System (QZSS), the French Radio Beacon Orbit and Radio Beacon Positioning (DORIS), etc. The positioning circuitry 716 includes various hardware elements for communicating with components of the positioning network, such as navigation satellite constellation nodes (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, etc. to facilitate OTA communications). In some embodiments, the positioning circuitry 716 may include a Micro-Technology for Positioning, Navigation, and Timing (Micro-PNT) IC for performing position tracking / estimation without GNSS assistance using a master timing clock. The positioning circuitry 716 may also be part of or interact with the baseband circuitry 704 and / or the radio front-end module 706 to communicate with nodes and components of a positioning network. The positioning circuitry 716 may also provide position and / or time data to the application circuitry 702, which may use the data to synchronize operations with various infrastructures, etc. The components shown in FIG. 7 may communicate with each other using interface circuitry, which may include any number of bus and / or interconnect (IX) technologies, such as Industry Standard Architecture (ISA), Enhanced ISA (EISA), Peripheral Component Interconnect (PCI), Enhanced Peripheral Component Interconnect (PCIx), PCI Express (PCIe), or any number of other technologies. The bus / IX may be, for example, a proprietary bus used in SoC-based systems. Other bus / IX systems, among others, may include I / O, SPI, and other bus / IX technologies. 2C interface, SPI interface, point-to-point interface, power bus, etc. may be included.

[0128] FIG. 8 illustrates an example of a platform 800 according to various embodiments. In an embodiment, the computer platform 800 may be suitable for use as a UE, an application server, and / or any other element / device described herein. The platform 800 may include any combination of components illustrated in the example. The components of the platform 800 may be implemented as an integrated circuit (IC) adapted to the computer platform 800, as part thereof, as a separate electronic device, or as other modules, logic, hardware, software, firmware, or a combination thereof, or as components otherwise incorporated within the chassis of a larger system. The block diagram of FIG. 8 is intended to provide a schematic view of the components of the computer platform 800. However, some of the illustrated components may be omitted, additional components may be present, and different arrangements of the illustrated components may occur in other implementations.

[0129] The application circuit 802 may include, but is not limited to, one or more processors (or processor cores), cache memory, one or more LDOs, an interrupt controller, an SPI, an I 2The application circuitry 802 may include circuits such as a serial interface such as a SPI, SPI-C, or universal programmable serial interface module, timer counters including RTC, interval and watchdog timers, general-purpose I / O, memory card controllers such as SD MMC, USB interface, MIPI interface, and JTAG test access port. The processor (or core) of the application circuitry 802 may be coupled to or may include memory / storage elements and may be configured to execute instructions stored in the memory / storage elements to enable various applications or operating systems to run on the platform 800. In some implementations, the memory / storage elements may be on-chip memory circuits, which may include any suitable volatile and / or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, and / or any other type of memory device technology as described herein.

[0130] The processor(s) of application circuit 802 may include, for example, one or more processor cores, one or more application processors, one or more GPUs, one or more RISC processors, one or more ARM processors, one or more CISC processors, one or more DSPs, one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, multi-threaded processors, very low voltage processors, embedded processors, some other known processing elements, or any suitable combination thereof. In some embodiments, application circuit 802 may include or be a special-purpose processor / controller that operates in accordance with various embodiments herein.

[0131] By way of example, the processor(s) of application circuit 802 may include an Intel® Architecture Core™-based processor such as a Quark™, ​​Atom™, i3, i5, i7, or MCU class processor, or another such processor available from Intel® Corporation. The processor of application circuit 802 may also be one or more of: Advanced Micro Devices (AMD) Ryzen® processor(s) or accelerated processing unit (APU), AS-A9 processor(s) from Apple® Inc., Snapdragon™ processor(s) from Qualcomm® Technologies, Inc., Texas Instruments, Inc.® Open Multimedia Applications Platform (OMAP)™ processor(s), MIPS-based designs from MIPS Technologies, Inc. such as the MIPS Warrior M-class, Warrior I-class, and Warrior P-class processors, ARM-based designs licensed from ARM Holdings Ltd. such as the ARM Cortex-A, Cortex-R, and Cortex-M family of processors, and the like. In some implementations, the application circuit 802 may be part of a system-on-chip (SoC) in which the application circuit 802 and other components are formed on a single integrated circuit or package, such as an Edison™ or Galileo™ SoC substrate from Intel® Corporation.

[0132] Additionally or alternatively, application circuitry 802 may include, but is not limited to, one or more field programmable devices (FPDs) such as FPGAs, programmable logic devices (PLDs) such as composite PLDs (CPLDs) or high-capacity PLDs (HCPLDs), ASICs such as structured ASICs, programmable system-on-chips (PSoCs), etc. In such embodiments, the circuitry of application circuitry 802 may comprise logic blocks or logic fabric and other interconnected resources that may be programmed to perform various functions, such as the procedures, methods, and functions of various embodiments described herein. In such embodiments, the circuitry of application circuitry 802 may include memory cells (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), antifuses, etc.) used to store logic blocks, logic fabric, data, etc., such as in look-up tables (LUTs).

[0133] The baseband circuitry 804 may be implemented, for example, as a soldered board containing one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits.

[0134] The radio front-end module (RFEM) 806 may include a millimeter-wave RFEM and one or more submillimeter-wave radio frequency integrated circuits (RFICs). In some implementations, the one or more submillimeter-wave RFICs may be physically separate from the millimeter-wave RFEM. The RFIC may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In alternative implementations, both millimeter-wave and submillimeter-wave radio functionality may be implemented within the same physical radio front-end module 806 that incorporates both millimeter-wave and submillimeter-wave antennas.

[0135] The memory circuit 808 may include any number and type of memory devices used to provide a given amount of system memory. By way of example, the memory circuit 808 may include one or more of: volatile memory, including random access memory (RAM), dynamic RAM (DRAM) and / or synchronous dynamic RAM (SDRAM), and non-volatile memory (NVM), including high-speed electrically erasable memory (commonly referred to as flash memory), phase-change random access memory (PRAM), magnetoresistive random access memory (MRAM), etc. The memory circuit 808 may be developed according to a Joint Electron Devices Engineering Council (JEDEC) low-power double data rate (LPDDR)-based design, such as LPDDR2, LPDDR3, LPDDR4, etc. The memory circuit 808 may be implemented as one or more of a solder package integrated circuit, a single die package (SDP), a dual die package (DDP), or a quad die package (Q17P), a socketed memory module, a dual in-line memory module (DIMM) including a micro DIMM or a mini DIMM, and / or soldered onto a motherboard via a ball grid array (BGA). In low-power implementations, the memory circuit 808 may be on-die memory or registers associated with the application circuit 802. To provide persistent storage of information such as data, applications, and operating systems, the memory circuit 808 may include one or more mass storage devices, which may include, among others, a solid-state disk drive (SSDD), a hard disk drive (HDD), a micro HDD, a resistive memory, a phase-change memory, a holographic memory, or a chemical memory. For example, the computer platform 800 may incorporate three-dimensional (3D) cross-point (XPOINT) memory from Intel® and Micron®.

[0136] Removable memory circuitry 826 may include devices, circuits, enclosures / housings, ports or receptacles, etc. used to couple portable data storage devices with platform 800. These portable data storage devices may be used for mass storage purposes and may include, for example, flash memory cards (e.g., Secure Digital (SD) cards, microSD cards, xD image cards, etc.), USB flash drives, optical disks, external HDDs, etc.

[0137] Platform 800 may also include interface circuitry (not shown) used to connect external devices with platform 800. External devices connected to platform 800 via the interface circuitry include sensor circuitry 822 and electromechanical components (shown as EMC 824), and a removable memory device coupled to removable memory circuit 826.

[0138] The sensor circuitry 822 includes devices, modules, or subsystems intended to detect events or changes in the environment and transmit information about the detected events (sensor data) to some other device, module, subsystem, etc. Examples of such sensors include, among others, inertial measurement units (IMUs) including accelerometers, gyroscopes, and / or magnetometers, microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS) including 3-axis accelerometers, 3-axis gyroscopes, and / or magnetometers, level sensors, flow sensors, temperature sensors (e.g., thermistors), pressure sensors, barometric pressure sensors, gravimeters, altimeters, image capture devices (e.g., cameras or lensless apertures), light detection and ranging (LiDAR) sensors, proximity sensors (e.g., infrared detectors, etc.), depth sensors, ambient light sensors, ultrasonic transceivers, microphones or other similar audio capture devices, etc.

[0139] EMC 824 includes devices, modules, or subsystems intended to enable platform 800 to change its state, position, and / or orientation, or to move or control mechanisms or (sub)systems. Additionally, EMC 824 may be configured to generate and send messages / signaling to other components of platform 800 to indicate the current state of EMC 824. Examples of EMC 824 include one or more power switches, relays including electromechanical relays (EMRs) and / or solid-state relays (SSRs), actuators (e.g., valve actuators, etc.), audible sound generators, visual alarm devices, motors (e.g., DC motors, stepper motors, etc.), wheels, thrusters, propellers, claws, clamps, hooks, and / or other similar electromechanical components. In an embodiment, platform 800 is configured to operate one or more EMCs 824 based on one or more captured events and / or commands or control signals received from service providers and / or various clients. In some implementations, the interface circuitry may connect the platform 800 with positioning circuitry 816. The positioning circuitry 816 includes circuitry for receiving and decoding signals transmitted / broadcast by a GNSS positioning network. Examples of navigation satellite constellations (or GNSS) include the United States' GPS, Russia's GLONASS, the European Union's Galileo system, China's Beidou navigation satellite system, regional navigation systems or GNSS augmentation systems (e.g., NAVIC, Japan's QZSS, France's DORIS, etc.), etc. The positioning circuitry 816 includes various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, etc. to facilitate over-the-air (OTA) communications) for communicating with components of the positioning network, such as navigation satellite constellation nodes. In some embodiments, the positioning circuitry 816 may include a Micro-PNT IC for performing position tracking / estimation without GNSS assistance using a master timing clock.The positioning circuitry 816 may also be part of or interact with the baseband circuitry 804 and / or the wireless front-end module 806 to communicate with nodes and components of a positioning network. The positioning circuitry 816 may also provide position and / or time data to the application circuitry 802, which may use the data to synchronize operation with various infrastructures (e.g., wireless base stations), such as for turn-by-turn navigation applications.

[0140] In some implementations, the interface circuit may connect the platform 800 with near-field communication circuitry (denoted NFC circuitry 812). The NFC circuitry 812 is configured to provide contactless, short-range communication based on radio frequency identification (RFID) standards, and magnetic field induction is used to enable communication between the NFC circuitry 812 and an NFC-enabled device (e.g., an “NFC touchpoint”) external to the platform 800. The NFC circuitry 812 includes an NFC controller coupled to an antenna element and a processor coupled to the NFC controller. The NFC controller may be a chip / IC that provides NFC functionality to the NFC circuitry 812 by executing NFC controller firmware and an NFC stack, where the NFC stack may be executed by the processor to control the NFC controller, and the NFC controller firmware may be executed by the NFC controller to control the antenna element to emit short-range RF signals. The RF signal may power a passive NFC tag (e.g., a microchip embedded in a sticker or wristband) to transmit stored data to NFC circuitry 812, or may initiate a data transfer between NFC circuitry 812 in proximity to platform 800 and another active NFC device (e.g., a smartphone or NFC-enabled POS terminal).

[0141] Driver circuitry 818 may include software and hardware elements that operate to control particular devices embedded in, attached to, or otherwise communicatively coupled to platform 800. Driver circuitry 818 may include individual drivers that enable other components of platform 800 to interact with or control various input / output (I / O) devices that may be present in or connected to platform 800. For example, driver circuitry 818 may include a display driver for controlling and enabling access to a display device, a touchscreen driver for controlling and enabling access to a touchscreen interface of platform 800, a sensor driver for obtaining sensor readings of and controlling and enabling access to sensor circuitry 822, an EMC driver for obtaining actuator positions of and / or controlling and enabling access to EMC 824, a camera driver for controlling and enabling access to an embedded image capture device, and an audio driver for controlling and enabling access to one or more audio devices.

[0142] A power management integrated circuit (shown as PMIC 810) (referred to as a "power management circuit") may manage the power supplied to various components of platform 800. In particular, with respect to baseband circuitry 804, PMIC 810 may control power source selection, voltage scaling, battery charging, or DC-DC conversion. PMIC 810 is often included when platform 800 can be powered by a battery 814, for example, when the device is included in a UE.

[0143] In some embodiments, the PMIC 810 may control or otherwise be a part of various power saving mechanisms of the platform 800. For example, if the platform 800 is in an RRC connected state and still connected to a RAN node such that it is expected to receive traffic soon, after a period of inactivity the platform may enter a state known as discontinuous reception mode (DRX). While in this state, the platform 800 may power down for short intervals, thereby conserving power. If there is no data traffic activity for an extended period of time, the platform 800 may transition to an RRC idle state, in which the platform disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The platform 800 enters a very low power state, performs paging, and then periodically wakes up again, listens to the network, and powers down again. The platform 800 may not receive data in this state; to receive data, it must transition to the RRC connected state. In further power saving modes, the device may be allowed to be unavailable from the network for longer periods than the paging interval (which can range from a few seconds to several hours). During this time, the device may not be able to reach the network at all and may be completely powered down. Any data sent during this time will be significantly delayed, but the delay is deemed acceptable.

[0144] Battery 814 may power platform 800, although in some examples platform 800 may be deployed and mounted in a fixed location or may have a power source coupled to an electrical grid. Battery 814 may be a lithium-ion battery, a metal-air battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some implementations, such as for V2X applications, battery 814 may be a typical lead-acid automotive battery.

[0145] In some implementations, the battery 814 may be a "smart battery" that includes or is coupled to a battery management system (BMS) or battery monitoring integrated circuit. The BMS may be included in the platform 800 to track the state of charge (SoCh) of the battery 814. The BMS may also be used to monitor other parameters of the battery 814 to provide fault predictions, such as the state of health (SoH) and state of function (SoF) of the battery 814. The BMS may communicate information about the battery 814 to the application circuit 802 or other components of the platform 800. The BMS may also include an analog-to-digital (ADC) converter that allows the application circuit 802 to directly monitor the voltage of or current from the battery 814. Battery parameters may be used to determine operations that the platform 800 may perform, such as transmit frequency, network operation, and sensing frequency.

[0146] A power block, or other power source coupled to the electric grid, may be coupled to the BMS to charge the battery 814. In some embodiments, the power block may be replaced with a wireless power receiver to obtain power wirelessly, for example, via a loop antenna within the computer platform 800. In these examples, wireless battery charging circuitry may be included in the BMS. The particular charging circuitry selected may depend on the size of the battery 814 and therefore the current required. Charging may be performed using the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, or the Rezence charging standard promulgated by the Alliance for Wireless Power, among others.

[0147] User interface circuitry 820 includes various input / output (I / O) devices present within or connected to platform 800, including one or more user interfaces designed to enable user interaction with platform 800 and / or peripheral component interfaces designed to enable peripheral component interaction with platform 800. User interface circuitry 820 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting input, including, among others, one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, a headset, etc. Output device circuitry includes any physical or virtual means for displaying or otherwise communicating information, such as sensor readings, actuator position(s), or other similar information. The output device circuitry may include any number and / or combination of audio or visual displays, among others, one or more simple visual outputs / indicators, such as binary status indicators (e.g., light-emitting diodes (LEDs)), and multi-character visual outputs or more complex outputs, such as a display device or touch screen (e.g., a liquid crystal display (LCD), an LED display, a quantum dot display, a projector, etc.), where output, such as text, graphics, multimedia objects, etc., is generated or created from operation of platform 800. The output device circuitry may also include a speaker or other audio emitting device, printer(s), and / or the like. In some embodiments, the sensor circuitry 822 may be used as an input device circuit (e.g., an image capture device, a motion capture device, etc.), and one or more EMCs may be used as output device circuitry (e.g., an actuator for providing haptic feedback, etc.). In another example, an NFC circuit comprising an NFC controller coupled to an antenna element and a processing device may be included for reading an electronic tag and / or connecting with another NFC-enabled device.Peripheral component interfaces include, but are not limited to, a non-volatile memory port, a USB port, an audio jack, a power interface, and the like.

[0148] Although not shown, the components of platform 800 may communicate with each other using any suitable bus or interconnect (IX) technology, which may include any number of technologies, including ISA, EISA, PCI, PCIx, PCIe, a time-triggered protocol (TTP) system, a FlexRay system, or any number of other technologies. The bus / IX may be, for example, a proprietary bus / IX used in an SoC-based system. In particular, 2 Other bus / IX systems may be included such as a C interface, an SPI interface, a point-to-point interface, and a power bus.

[0149] 9 is a block diagram illustrating a component 900 that can 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 described herein, according to some demonstrative embodiments. Specifically, FIG. 9 shows a diagrammatic representation of hardware resources 902, including one or more processors 906 (or processor cores), one or more memory / storage devices 914, and one or more communication resources 924, each of which may be communicatively coupled via a bus 916. In embodiments in which node virtualization (e.g., NFV) is utilized, a hypervisor 922 may execute to provide an execution environment for one or more network slices / sub-slices that utilize the hardware resources 902.

[0150] Processor 906 (e.g., 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 digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 908 and processor 910.

[0151] The memory / storage 914 may include main memory, disk storage, or any suitable combination thereof. The memory / storage 914 may include any type of volatile or non-volatile memory, such as, but not limited to, 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.

[0152] Communications resources 924 may include interconnect or network interface components or other suitable devices for communicating with one or more peripheral devices 904 or one or more databases 920 over network 918. For example, communications resources 924 may include wired communications components (e.g., for coupling via a Universal Serial Bus (USB)), cellular communications components, NFC components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communications components.

[0153] The instructions 912 may include software, programs, applications, applets, apps, or other executable code for causing at least one of the processors 906 to perform any one or more of the methods described herein. The instructions 912 may reside, completely or partially, within at least one of the processors 906, the memory / storage 914, or any suitable combination thereof (e.g., within a processor's cache memory). Furthermore, any portion of the instructions 912 may be transferred to the hardware resources 902 from any combination of the peripheral devices 904 or the database 920. Accordingly, the memory of the processor 906, the memory / storage 914, the peripheral devices 904, and the database 920 are examples of computer-readable and machine-readable media.

[0154] In one or more embodiments, at least one of the components depicted in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, and / or methods as described in the Examples section below. For example, the baseband circuitry described above in connection with one or more of the foregoing figures may be configured to operate according to one or more of the examples described below. As another example, circuitry associated with a UE, a base station, a network element, etc., as described above in connection with one or more of the foregoing figures, may be configured to operate according to one or more of the examples described below in the Examples section. Examples Section

[0155] The following examples relate to further embodiments.

[0156] Example 1 may include a method for determining a physical downlink shared channel (PDSCH) hybrid automatic repeat request-acknowledgement (HARQ-ACK) processing timing. The method may include determining that a user equipment (UE) is configured for single downlink control information (single DCI) multi-transmit / receive point (multi-TRP) PDSCH operation, determining a first PDSCH and a second PDSCH in a slot, where the first PDSCH and the second PDSCH are to be used in the single DCI multi-TRP PDSCH operation, and determining a minimum HARQ-ACK processing timing for the first PDSCH and the second PDSCH using one or more symbols of the first PDSCH or one or more symbols of both the first PDSCH and the second PDSCH.

[0157] Example 2 may include the method of Example 1, in which the single DCI multi-TRP PDSCH operation is TDM mode A operation.

[0158] Example 3 may include the method of Example 1, in which the first PDSCH and the second PDSCH have the same duration.

[0159] Example 4 may include the method of Example 3, in which the first PDSCH and the second PDSCH have the same frequency resource allocation.

[0160] Example 5 may include the method of Example 1, wherein determining the minimum HARQ-ACK processing timing for the first PDSCH and the second PDSCH uses only one or more symbols of the first PDSCH.

[0161] Example 6 may include the method of Example 1, in which determining the minimum HARQ-ACK processing timing for the first PDSCH and the second PDSCH uses one or more symbols of both the first PDSCH and the second PDSCH and one or more blank symbols located between the first PDSCH and the second PDSCH.

[0162] Example 7 may include the method of Example 1, wherein determining the minimum HARQ-ACK processing timing for the first PDSCH and the second PDSCH uses one or more symbols of both the first PDSCH and the second PDSCH, and does not use any blank symbols located between the first PDSCH and the second PDSCH.

[0163] Example 8 may include the method of Example 1, in which determining the minimum HARQ-ACK processing timing for the first PDSCH and the second PDSCH is determining an overall HARQ-ACK processing timing, and further includes: determining an initial minimum HARQ-ACK processing timing (k1_1) for the first PDSCH; determining an initial minimum HARQ-ACK processing timing (k1_2) for the second PDSCH; and determining the overall HARQ-ACK processing timing K1 using the first minimum HARQ-ACK processing timing and the second minimum HARQ-ACK processing timing.

[0164] Example 9 may include the method of Example 8, in which the overall HARQ-ACK processing timing K1 is equal to max(k1_1-Offset,0)+k1_2+C, where the offset value is the offset between the last symbol of the first PDSCH and the first symbol of the second PDSCH, and the C value is a constant.

[0165] Example 10 may include the method of Example 8, in which the overall HARQ-ACK processing timing (K1) is equal to max(k1_1, k1_2)+C, and the value of C is a constant.

[0166] Example 11 may include the method of Example 8, in which the overall HARQ-ACK processing timing (K1) is equal to k1_1+k1_2+C, and the value of C is a constant.

[0167] Example 12 may include a non-transitory computer-readable storage medium comprising: instructions that, when executed by a processor, cause the processor to determine that a user equipment (UE) is configured for single downlink control information (single DCI) multiple transmit / receive (multiple TRP) PDSCH operation; determine a first PDSCH and a second PDSCH having slots, the first PDSCH and the second PDSCH to be used in the single DCI multi-TRP PDSCH operation; and determine minimum hybrid automatic repeat request-acknowledgement (HARQ-ACK) processing timing for the first PDSCH and the second PDSCH using one or more symbols of the first PDSCH or one or more symbols of both the first PDSCH and the second PDSCH.

[0168] Example 13 may include the non-transitory computer-readable storage medium of Example 12, wherein determining the minimum HARQ-ACK processing timing for the first PDSCH and the second PDSCH is determining an overall HARQ-ACK processing timing, and the instructions, when executed by the processor, further cause the processor to determine an initial minimum HARQ-ACK processing timing (k1_1) for the first PDSCH, determine an initial minimum HARQ-ACK processing timing (k1_2) for the second PDSCH, and determine the overall HARQ-ACK processing timing K1 using the first minimum HARQ-ACK processing timing and the second minimum HARQ-ACK processing timing.

[0169] Example 14 may include the non-transitory computer-readable storage medium of Example 13, wherein the overall HARQ-ACK processing timing (K1) is equal to max(k1_1-Offset,0)+k1_2+C, where the offset value is an offset between the last symbol of the first PDSCH and the first symbol of the second PDSCH, and the C value is a constant.

[0170] Example 15 may include the non-transitory computer-readable storage medium of Example 13, wherein the overall HARQ-ACK processing timing (K1) is equal to max(k1_1, k1_2)+C, and the C value is a constant.

[0171] Example 16 may include the non-transitory computer-readable storage medium of Example 13, wherein the overall HARQ-ACK processing timing (K1) is equal to k1_1+k1_2+C, and the C value is a constant.

[0172] Example 17 may include a computing device for determining physical downlink shared channel (PDSCH) hybrid automatic repeat request-acknowledgement (HARQ-ACK) processing timing, the computing device comprising: a processor; and memory storing instructions that, when executed by the processor, configure the device to: determine that a user equipment (UE) is configured for single downlink control information (single DCI) multiple transmit / receive (multiple TRP) PDSCH operation; determine a first PDSCH and a second PDSCH in a slot; and determine minimum HARQ-ACK processing timing for the first PDSCH and the second PDSCH using one or more symbols of the first PDSCH or one or more symbols of both the first PDSCH and the second PDSCH.

[0173] Example 18 may include the computing device of Example 17, wherein determining the minimum HARQ-ACK processing timing for the first PDSCH and the second PDSCH is determining an overall HARQ-ACK processing timing, and the instructions, when executed by the processor, further configure the device to: determine an initial minimum HARQ-ACK processing timing (k1_1) for the first PDSCH, determine an initial minimum HARQ-ACK processing timing (k1_2) for the second PDSCH, and determine the overall HARQ-ACK processing timing K1 using the first minimum HARQ-ACK processing timing and the second minimum HARQ-ACK processing timing.

[0174] Example 19 may include the computing device of Example 18, wherein the overall HARQ-ACK processing timing K1 is equal to max(k1_1-Offset,0)+k1_2+C, where the offset value is an offset between the last symbol of the first PDSCH and the first symbol of the second PDSCH, and the C value is a constant.

[0175] Example 20 may include the computing device of Example 18, wherein the overall HARQ-ACK processing timing K1 is equal to max(k1_1, k1_2)+Cmax(k1_1, k1_2)+C, where the value of C is a constant.

[0176] Example 21 may include the computing device of Example 18, wherein the overall HARQ-ACK processing timing K1 is equal to k1_1+k1_2+C, and the value of C is a constant.

[0177] Example 22 may include a method for user equipment (UE) capability reporting, the method including: determining a UE configuration for one or both of multiple downlink control information (multiple DCI) multiple transmit / receive (multiple TRP) operation and single DCI multi-TRP operation; determining a physical downlink shared channel (PDSCH) processing capability for a timing offset between the PDSCH and HARQ-ACK for one or both of the multi-DCI multi-TRP operation and the single DCI multi-TRP operation; determining a physical uplink shared channel (PUSCH) processing capability for a timing offset between the physical downlink control channel (PDCCH) and the PUSCH for one or both of the multi-DCI multi-TRP operation and the single DCI multi-TRP operation; and generating one or more reports indicating support of the determined PDSCH processing capability and the determined PUSCH processing capability.

[0178] Example 23 may include the method of Example 22, wherein one or more reports are sent by the UE for each feature set for each component carrier.

[0179] Example 24 may include the method of Example 22, wherein the determined UE configuration is for multi-DCI multi-TRP, the determined PDSCH processing capability is not PDSCH processing capability 2, and the PDSCH processing capability 2 uses low latency HARQ-ACK feedback.

[0180] Example 25 may include the method of Example 22, wherein the determined UE configuration is for single DCI multi-TRP, the determined PDSCH processing capability is not PDSCH processing capability 2, and the PDSCH processing capability 2 uses low latency HARQ-ACK feedback.

[0181] Example 26 may include the method of Example 22, wherein the determined UE configuration is for multi-DCI multi-TRP, the determined PUSCH processing capability is not PUSCH processing capability 2, and the PUSCH processing capability 2 uses low-latency PUSCH processing.

[0182] Example 27 may include an apparatus including means for performing one or more elements of a method described in or related to any of the above examples, or any other method or process described herein.

[0183] Example 28 may include one or more non-transitory computer-readable media containing instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of a method described in or related to any of the above examples, or any other method or process described herein.

[0184] Example 29 may include a device comprising logic, modules, or circuitry that performs one or more elements of a method described or related to any of the above examples, or any other method or process described herein.

[0185] Example 30 may include methods, techniques, or processes described in or related to any of the above examples, or portions thereof or parts thereof.

[0186] Example 31 may include an apparatus that includes one or more processors and one or more computer-readable media containing instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process described in or related to any of the above examples, portions thereof.

[0187] Example 32 may include a signal as described in or related to any of the above examples, parts or portions thereof.

[0188] Example 33 may include a datagram, packet, frame, segment, protocol data unit (PDU), or message described or related to any of the above examples, parts or portions thereof, or described in this disclosure.

[0189] Example 34 may include a signal encoded with data as described or related to any of the above examples, parts or portions thereof, or as described in this disclosure.

[0190] Example 35 may include a signal encoded using a datagram, packet, frame, segment, PDU, or message described or related to any of the above examples, parts or portions thereof, or described in this disclosure.

[0191] Example 36 may include an electromagnetic signal carrying computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform a method, technique, or process described in or related to any of the above examples or portions thereof.

[0192] Example 37 may include a computer program comprising instructions that, when executed by a processing element, cause the processing element to perform a method, technique, or process described in or related to any of the above examples or portions thereof.

[0193] Example 38 may include signals within a wireless network as shown and described herein.

[0194] Example 39 may include a method of communicating in a wireless network as shown and described herein.

[0195] Example 40 may include a system for providing wireless communication as shown and described herein.

[0196] Example 41 may include a device for providing wireless communication as shown and described herein.

[0197] Any of the above-described examples can be combined with any other example (or combination of examples) unless otherwise stated. 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 the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be learned from practice of various embodiments.

[0198] Embodiments and implementations of the systems and methods described herein may include various operations that may be embodied in machine-executable instructions executed by a computer system. The computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components that contain specific logic for performing the operations, or may include a combination of hardware, software, and / or firmware.

[0199] It should be appreciated that the systems described herein include descriptions of specific embodiments. These embodiments may be combined into a single system, partially combined into other systems, divided into multiple systems, or otherwise divided or combined. Additionally, it is contemplated that parameters, attributes, aspects, etc. of one embodiment may be used in another embodiment. It is recognized that parameters, attributes, aspects, etc. are described in one or more embodiments for clarity only, and that parameters, attributes, aspects, etc. may be combined with or substituted for parameters, attributes, etc. of other embodiments, unless specifically disclaimed herein.

[0200] It is well understood that use of personal information should comply with generally recognized privacy policies and practices that meet or exceed industry or government requirements for maintaining user privacy. In particular, personal information data should be managed and handled in a manner that minimizes the risk of unintended or unauthorized access or use, and the nature of permitted uses should be clearly indicated to users.

[0201] While the foregoing has been described in some detail for clarity, it will be apparent that certain changes and modifications can be made without departing from the principles thereof. It should be noted that there are many alternative ways of implementing both the processes and apparatus described herein. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the description is not to be limited to the details given herein, but may be modified within the scope of the appended claims and their equivalents.

Claims

1. 1. A method for determining Physical Downlink Shared Channel (PDSCH) Hybrid Automatic Repeat Request-Acknowledgement (HARQ-ACK) processing timing, comprising: Determining that a user equipment (UE) is configured for single downlink control information (single DCI) multiple transmit / receive point (multiple TRP) PDSCH operation; determining a first PDSCH and a second PDSCH in a slot, the first PDSCH and the second PDSCH being used in the single DCI multi-TRP PDSCH operation; determining one minimum HARQ-ACK processing timing for the first PDSCH using one or more symbols of only the first PDSCH, wherein the one minimum HARQ-ACK processing timing is also used to define a duration between the second PDSCH and a corresponding HARQ-ACK.

2. The method of claim 1 , wherein the single DCI multi-TRP PDSCH operation is TDM A operation.

3. 2. The method of claim 1, wherein the first PDSCH and the second PDSCH have the same duration.

4. 4. The method of claim 3, wherein the first PDSCH and the second PDSCH have the same frequency resource allocation.

5. A non-transitory computer-readable storage medium, the computer-readable storage medium, when executed by a processor, causing the processor to: instructions for determining that a user equipment (UE) is configured for single downlink control information (single DCI) multiple transmit / receive (multiple TRP) PDSCH operation; instructions for determining a first PDSCH and a second PDSCH having slots, the first PDSCH and the second PDSCH being used in the single DCI multi-TRP PDSCH operation; and instructions to cause determining one minimum Hybrid Automatic Repeat Request-Acknowledgement (HARQ-ACK) processing timing for the first PDSCH using one or more symbols of only the first PDSCH, the one minimum HARQ-ACK processing timing also being used to define a duration between the second PDSCH and a corresponding HARQ-ACK.

6. 1. A computing device for determining Physical Downlink Shared Channel (PDSCH) Hybrid Automatic Repeat Request-Acknowledgement (HARQ-ACK) processing timing, comprising: a processor; When executed by the processor, determining that a user equipment (UE) is configured for single downlink control information (single DCI) multiple transmit / receive (multiple TRP) PDSCH operation; determining a first PDSCH and a second PDSCH in a slot, the first PDSCH and the second PDSCH being used in the single DCI multi-TRP PDSCH operation; and a memory storing instructions configuring the device to determine one minimum HARQ-ACK processing timing for the first PDSCH using one or more symbols of only the first PDSCH, wherein the one minimum HARQ-ACK processing timing is also used to define a duration between the second PDSCH and a corresponding HARQ-ACK.

7. 1. An apparatus for determining Physical Downlink Shared Channel (PDSCH) Hybrid Automatic Repeat Request-Acknowledgement (HARQ-ACK) processing timing, comprising: Apparatus comprising means for carrying out the operations included in the method of any one of claims 1 to 4.

Images