A method for channel measurement for TRS-based TDCP reporting

Abstract

A system and method for channel measurement for tracking reference signal (TRS)-based time-domain channel characteristic (TDCP) reporting is provided. In some embodiments, the method includes receiving a reporting configuration including a TDCP reporting amount to be reported by a UE for TDCP reporting, receiving a reference signal configuration including one or more TRS samples, receiving signaling indicating a measurement window, receiving signaling limiting the number of TRS samples to be considered, calculating the TDCP reporting amount to be reported using only the TRS samples in the indicated measurement window, receiving a DCI that triggers aperiodic TDCP reporting, and reporting the calculated / updated TDCP reporting amount. In this manner, the UE measurement burden associated with measuring the TRS to derive the TDCP reporting amount can be reduced. The solution is particularly useful when periodic TRS is configured and when the UE is triggered aperiodically for TDCP reporting.

Description

[Technical Field]

[0001] Related Applications This application claims the benefit of Provisional Patent Application No. 63 / 409,144, filed September 22, 2022, the entire disclosure of which is incorporated herein by reference.

[0002] TECHNICAL FIELD This disclosure relates generally to time domain channel characteristic (TDCP) reporting. [Background technology]

[0003] MU-MIMO With multi-user MIMO (MU-MIMO), two or more users in the same cell are co-scheduled on the same time-frequency resources. That is, two or more independent data streams are transmitted simultaneously to different UEs, and the spatial domain can generally be used to separate each stream. By transmitting several streams simultaneously, the system capacity can be increased. However, this comes at the expense of a reduced SINR per stream, since power must be shared between the streams and the streams cause interference to each other.

[0004] Channel State Information Reference Signal (CSI-RS) For CSI measurement and feedback, a CSI-RS is defined. The CSI-RS is transmitted on each antenna port and is used by the UE to measure the downlink channel between each transmit antenna port and each receive antenna port. A transmit antenna port is also referred to as a CSI-RS port. The supported number of antenna ports in NR is {1, 2, 4, 8, 12, 16, 24, 32}. By measuring the received CSI-RS, the UE can estimate the channel traversed by the CSI-RS, including the radio propagation channel and antenna gain. The CSI-RS for this purpose is also referred to as a non-zero power (NZP) CSI-RS.

[0005] The CSI-RS may be configured to be transmitted in some REs in a slot and in some slots. Figure 1 shows an example of CSI-RS REs for 12 antenna ports, where one RE per RB per port is shown.

[0006] Additionally, an interference measurement resource (IMR) for a UE to measure interference is also specified in NR. The IMR resource contains four REs, i.e., either four adjacent REs in frequency in the same OFDM symbol, or 2 × 2 adjacent REs in both time and frequency during a slot. By measuring both the channel based on the NZP CSI-RS and the interference based on the IMR, the UE can estimate the effective channel and noise-plus-interference to determine the CSI, i.e., rank, precoding matrix, and channel quality.

[0007] Moreover, a UE in NR may be configured to measure interference based on one or more NZP CSI-RS resources.

[0008] TRS Due to oscillator imperfections, transmission and reception may not be synchronized in time and / or frequency, which may cause inter-symbol and intra-symbol interference. In NR, a tracking reference signal (TRS) was introduced that can be used by UEs for high-precision time / frequency synchronization.

[0009] In the NR 3GPP specification, TRS can be configured when no CSI reporting setting is configured or when the upper layer parameter "reportQuantity" in the CSI-ReportConfig information element (IE) associated with all reporting settings linked to the CSI-RS resource set containing TRS is set to "none." This means that CSI reporting based on TRS measurements is not supported in NR.

[0010] A TRS is configured via "trs-Info" in the NZP-CSI-RS-ResourceSet IE of 3GPP TS 38.331 associated with a CSI-RS resource set, for which the UE can assume that antenna ports with the same port index of configured NZP CSI-RS resources in said resource set are identical. From the 3GPP specification point of view, a TRS is designated as a special kind of NZP CSI-RS, where the corresponding NZP CSI-RS resource set containing the TRS has the higher layer parameter "trs-info" set to true.

[0011] A TRS is not actually a CSI-RS; rather, it is a resource set consisting of multiple periodic NZP CSI-RSs. More specifically, a TRS consists of four 1-port, density-3 CSI-RSs arranged in two consecutive slots. A periodicity of 10, 20, 40, or 80 ms can be configured for the CSI-RSs within the resource set. Note that the exact set of REs used for the TRS CSI-RSs can vary. There is always a four-symbol time-domain separation between two CSI-RSs within a slot. Figure 2 shows an example of a TRS burst of two TRS symbols in two adjacent slots.

[0012] NR also supports aperiodic TRS.

[0013] In the case of LTE, a cell-specific reference signal (CRS) that serves the same purpose as the TRS as the LTE CRS can be used for synchronization, but the CRS can also be used for CSI reporting, which is not supported for the TRS in NR. However, compared to the LTE CRS, the TRS implies much less overhead, has only one antenna port, and exists in only two slots per TRS period. Figure 3 illustrates the configurability of the TRS symbol position and TRS burst periodicity.

[0014] CSI Framework in NR In NR, a UE may be configured with multiple CSI reporting settings and multiple CSI-RS resource settings. Each resource setting may include multiple resource sets, and each resource set may include up to eight CSI-RS resources. For each CSI reporting setting, the UE feeds back a CSI report.

[0015] Each CSI reporting setting includes at least the following information: ● CSI-RS resource set for channel measurements; ● IMR resource set for interference measurements, Optionally, a CSI-RS resource set for interference measurement; ● Time domain behavior, in other words, periodic, semi-persistent, or aperiodic reporting; ● Frequency granularity, in other words, broadband or subband; ● CSI parameters to be reported, such as RI, PMI, CQI, and CSI-RS resource indicator (CRI), in case of multiple CSI-RS resources in a resource set; ● The codebook type, i.e., type I or II, and the codebook subset restriction; ● Measurement limits, ● Subband size. One of two possible subband sizes is indicated, the value range depends on the bandwidth of the BWP. One CQI / PMI is fed back per subband (if configured for subband reporting).

[0016] Type 1 and Type 2 Codebooks in NR A Type 1 Codebook (CB) is typically used by a UE to report CSI for Single-User MIMO (SU-MIMO) scheduling in NR. A Type 2 CB is typically for more accurate CSI feedback for Multi-User MIMO (MU-MIMO) scheduling.

[0017] For both Type-1 and Type-2 CB, for each rank, a precoding matrix W is defined in the following form: W=W1W2 where: TIFF2025533520000002.tif101702 is an N×2L matrix, and L selected DFT beams {d i , i=1,...,L}, where d i is an N×1 DFT vector, where N is the number of CSI-RS ports per polarization, while W2 is a 2L×v matrix containing cophasing coefficients between the selected beams and also between antenna ports with two different polarizations, where v is the number of layers or ranks. W1 is the same for the entire CSI bandwidth, while W2 can be the same for the entire bandwidth or for each subband.

[0018] For Type-1 CB, the precoding vector for each MIMO layer is associated with a single DFT beam, while for Type-2 CB, the precoding vector for each layer is a linear combination of multiple DFT beams.

[0019] Extended Type 2 Codebook in NR In NR Rel-16, Type-2 CB is extended by applying a frequency-domain (FD) DFT basis across all subbands to reduce CSI feedback overhead and / or improve CSI accuracy. Instead of reporting W for each subband, a linear combination of DFT basis vectors is used to jointly represent W across the entire CSI bandwidth. For each layer, the precoding matrix W across all subbands is in the form: TIFF2025533520000003.tif7170Where, W f =[f1, ..., f M ] is the set of M selected DFT basis vectors [f1,...,f M ], and TIFF2025533520000004.tif7170 is a 2LxM matrix containing the coefficients for each selected DFT beam and each selected FD basis vector.

[0020] QCL and TCI conditions Several signals may be transmitted from different antenna ports of the same base station. These signals may have the same large-scale characteristics, such as Doppler shift / spread, mean delay spread, or mean delay. These antenna ports are then said to be quasi-collocated (QCL).

[0021] If the UE knows that two antenna ports are QCL with respect to a certain parameter (e.g., Doppler spread), the UE can estimate that parameter based on one of those antenna ports and apply that estimate to receive signals on the other antenna port. Typically, the first antenna port is represented by a measurement reference signal, such as a TRS or SSB (known as the source RS), and the second antenna port is a demodulation reference signal (DMRS) (known as the target RS).

[0022] For example, if antenna ports A and B are QCL in terms of average delay, the UE can estimate the average delay from the signal received from antenna port A and assume that the signal received from antenna port B has the same average delay. This is useful for demodulation, for example, because the UE can know in advance the characteristics of the channel which can aid the UE in selecting an appropriate channel estimation filter.

[0023] Information regarding what assumptions can be made regarding the QCL is signaled from the network to the UE. In NR, the following four types of QCL relationships between the transmitted source RS and the transmitted target RS have been defined: Type A: {Doppler shift, Doppler spread, mean delay, delay spread} Type B: {Doppler shift, Doppler spread} Type C: {average delay, Doppler shift} Type D: {Spatial Rx parameters}

[0024] Aperiodic CSI-RS / IM and CSI reporting For both aperiodic CSI-RS / IM resources and aperiodic CSI reporting, triggering is performed jointly by transmitting DCI format 0_1 ​​from the gNB to the UE using the downlink control channel (PDCCH). This is the DCI format that schedules the PUSCH transmission on which the aperiodic CSI reporting is carried. DCI format 0_1 ​​includes a CSI request field that can be configured to be between 0 and 6 bits wide using higher layer configuration (i.e., RRC) from the gNB to the UE.

[0025] The CSI request field is thus limited to at most S c =2 6 DCI_1 can contain 64 code points. If this field is set to all zeros, no CSI is required and DCI 0_1 only schedules regular PUSCH transmissions containing UL data. On the other hand, non-zero code points refer to so-called aperiodic trigger states configured by RRC from the gNB to the UE. An aperiodic trigger state is defined as a list of up to 16 aperiodic CSI reporting settings, each identified by a CSI reporting setting ID, for which the UE should simultaneously calculate and include CSI in scheduled PUSCH transmissions (although typically a much smaller number of reporting settings is used).

[0026] If the CSI reporting setting is linked to a periodic / semi-persistent resource setting, no further information is required since only one resource set is included in the resource setting for channel / interference measurement in this case.

[0027] However, if the CSI reporting setting is linked to an aperiodic resource setting (which may comprise multiple resource sets), which CSI-RS / IM resource set should be used for measurements must be indicated in DCI 0_1. This therefore allows the gNB to dynamically switch which CSI-RS / IM resource should be used for measurements each time an aperiodic report is triggered by DCI 0_1, by configuring it via RRC for a given CSI reporting setting and indicating different aperiodic trigger states via DCI 0_1. This means that the aperiodic NZP CSI-RS resource set for channel measurements, the aperiodic CSI-IM resource set for interference measurements (if used), and the aperiodic NZP CSI-RS resource set for interference measurements (if used) to be used for a given CSI reporting setting are also included in the aperiodic trigger state specification.

[0028] For aperiodic NZP CSI-RS, the QCL source to be used (i.e., the TCI state) is also set during the aperiodic trigger state, which allows the gNB to dynamically switch the UE Rx beam assumption for reception of the NZP CSI-RS.

[0029] The aperiodic trigger state definition is illustrated in FIG.

[0030] It is possible to configure up to 128 aperiodic trigger states via RRC. However, the number of code points of the CSI request bitfield in DCI 0_1 only ranges between 0 and 63. Therefore, more trigger states can be configured in RRC than can be indicated in the DCI field. In other words, in this case, M aperiodic trigger states are configured in RRC, but only M aperiodic trigger states (with a bit width of N TS = 0,...,6) CSI request bitfield TIFF2025533520000005.tif6170 When containing only non-zero code points, intermediate sub-selection, or S c A mapping between the codepoints and the M RRC configuration trigger states needs to be performed. This sub-selection is performed by sending a MAC CE sub-selection command.

[0031] Aperiodic CSI-RS / IM is essentially a one-shot measurement that exists only for a single time instance and is used only to determine the CSI for a single aperiodic report. The time location of the aperiodic CSI-RS / IM is specified as a slot offset relative to the slot in which the trigger-containing DCI is received. The slot offset is specified on the CSI-RS resource set level, and the offset allows the UE some time to complete the CSI measurement and report calculation and prepare the uplink transmission of the report. For aperiodic CSI-IM, there is no explicit slot offset specified; instead, CSI-IM and CSI-RS are assumed to be in the same slot to enable efficient CSI processing in the UE.

[0032] CPU Processing Unit In NR, a UE has a capacity of 5 to 30 CSI processing units (CPUs) that can be used to calculate any type of CSI report. Periodic or semi-persistent CSI reporting (excluding the initial semi-persistent CSI report on the PUSCH after the PDCCH that triggered the report) occupies the CPU from the first symbol of the earliest of each CSI-RS / CSI-IM / SSB resource for channel or interference measurement to the latest CSI-RS / CSI-IM / SSB opportunity for the corresponding CSI reference resource, up to the last symbol of the PUSCH / PUCCH that carries the report. Aperiodic CSI reporting occupies the CPU from the first symbol after the PDCCH that triggers the CSI report to the last symbol of the PUSCH that carries the report. If the UE is triggered / configured to report CSI but does not have an available CPU, the CSI does not need to be updated.

[0033] CSI processing criteria and UE capabilities for CSI reporting In LTE, the concept of CSI processes was introduced in Rel-11 to support CoMP, i.e., feedback of several different CSI reports corresponding to multiple transmission points. Each CSI process is associated with a specific type of reporting configuration (i.e., CSI content and measurement resources), and a UE is assumed to always be capable of providing CSI for all its supported CSI processes on a carrier. Thus, for LTE, the CSI computation capability reported by a UE is support for X reporting configurations. However, such a tight coupling between CSI capability and the configured reporting configuration X was not suitable for the more flexible NR CSI framework.

[0034] Instead, NR CSI computation capability separates the number of supported configured CSI reporting settings from the number of supported simultaneous CSI calculations. That is, the concept of CSI processing is generalized in NR by introducing CSI processing units (CPUs), where the number of CPUs is equal to the number of simultaneous CSI calculations supported by the UE. The CPU can be considered a general CSI calculation engine capable of processing any type of CSI report. That is, the CPU is a pool of computational resources. For example, a UE may indicate support for four configured CSI reporting settings but only support a single simultaneous CSI calculation (in other words, only a single CPU). This means that a gNB can trigger any of four different CSI reports but must time-multiplex the different CSI report calculations. Different configured CSI reporting settings may correspond, for example, to different codebook settings (in other words, type I and type II codebooks), different types of beam reports (e.g., P2 and P3), different CSI hypotheses used in CoMP operation, or CSI reports corresponding to different carriers.

[0035] The framework works as follows: When a CSI report calculation is about to proceed, in other words, when the UE is triggered for an aperiodic CSI report, or when calculation begins for a periodic or semi-persistent CSI report, the CSI report is assigned to one or more available CPUs. If there are not enough available CPUs because the UE already has ongoing processing of other CSI reports, the additional CSI report assigned by the gNB does not need to be calculated by the UE; instead, the UE can report old CSI to the gNB, such as a previously calculated CSI report stored in memory, or simply pad the CSI report with dummy bits. The CSI report is not dropped in this case, but some content is always transmitted to avoid changing the rate matching procedure for PUSCH or PUCCH transmission, which may be error-prone. In practice, the gNB should strive to trigger / configure only as many CSI reports as the UE can handle, so that old CSI does not need to be reported by the UE.

[0036] Each CSI report committed to calculation by the UE is thereby allocated from the start allocation time until the last symbol of the physical channel (i.e., PUCCH or PUSCH) carrying the CSI report to the gNB has finished transmitting from the UE. CPU It occupies CPUs, and In that case, it is released. For aperiodic CSI reporting, the CPU start allocation time is the last symbol of the PDCCH containing the DCI that triggered the report, while for periodic and semi-persistent CSI reporting, the CPU is allocated from the time of the occurrence of the latest CSI-RS / IM resource used to calculate a particular report. That is, for periodic / semi-persistent reporting, the UE can be assumed to start calculating the CSI report as soon as the UE receives the latest occurrence of the measurement resource.

[0037] Number of CPUs occupied by a CSI reportCPU depends on the content of the report. In the case of non-beam-related CSI reporting (in other words, when reportQuantity is not equal to "cri-RSRP", "ssb-Index-RSRP", or "none"), the CSI report occupies as many CPUs as the number of CSI-RS resources in the CSI-RS resource set for channel measurement. This is because the UE may need to calculate a complete CSI report for each CSI-RS resource in parallel to determine, in the worst case, which CSI-RS resource is optimal and should be selected with CRI (of course, UE implementations may use simpler techniques to determine CRI, such as comparing the signal strength of the resources). On the other hand, in the case of beam-related reporting, the required calculations are less complex and can be performed on a single CPU (O CPU = 1) is occupied. The gNB also has the possibility to trigger aperiodic TRS using the triggering mechanism of the CSI framework, but this does not occupy the CPU; instead, the UE is assumed to have dedicated resources for TRS processing.

[0038] If multiple CSI reports are to be allocated for CPU use on a given OFDM symbol, the multiple CSI reports are ordered according to a set of priority rules. CPU L CPUs start occupying their respective CPUs on the same OFDM symbol on which they are not occupied The UE does not need to update the N M requested CSI reports with the lowest priority, where 0≦M≦N. TIFF2025533520000008.tif7170

[0039] The concept of CPU occupancy is illustrated in FIG. 5, where it is assumed that a UE has two available CPUs, where CPU #1 is assigned by the periodic (P) CSI report in slot 0, which is the slot of the latest NZP CSI-RS occurrence (up to the CSI reference resource) used by the P CSI report. While the P CSI report is being calculated, the UE is triggered by two consecutive aperiodic CSI reports #1 and #2 assigned to CPU #2. After both CPUs are released, the UE is triggered by two simultaneous aperiodic CSI reports #3 and #4, which occupy CPU #1 and CPU #2, respectively. Before these CSI reports complete calculation, the UE is triggered by another aperiodic CSI report #5. However, because there are no more available CPUs, that CSI report is not calculated by the UE, and instead, old or dummy CSI is reported for aperiodic CSI report #5.

[0040] Channel Correlation, Doppler Spectrum, and the Jakes Model The wireless channel h(t) between the gNB and the UE may change over time as the UE moves. This is because the signal received at the UE typically comprises many paths of radio waves reflected from objects surrounding the UE (such as trees and buildings), where each path has a different angle of arrival (AOA) at the UE as the UE moves, and thus a different Doppler frequency. It is well known that when the AOA of the paths are uniformly distributed over [-π, π] in azimuth, the Doppler power spectrum for the channel h(t) can be modeled using the Jakes model (in other words, in two dimensions) as follows: TIFF2025533520000009.tif27170

[0041] The autocorrelation of the channel is R hh (τ)=E[h(t)h * (t+τ)]. The normalized autocorrelation R hh (τ) / R hh (0)=J0(2π τ f max) is the inverse Fourier transform of S(f), where J0(·) is the zeroth-order Bessel function of the first kind and E[·] denotes the expectation value.

[0042] Figure 6 shows the zeroth-order Bessel function of the first kind (the y-axis shows the autocorrelation and the x-axis shows 2π τ f max (This shows that 2π τ f max < 3.8317, and within that range, and for a given τ, the correlation and f max It can be seen that there is a one-to-one mapping between

[0043] Rel-18 Specification for TRS-Based TDCP Reporting At the RAN1#109e meeting, the following agreements were reached: agreement The scope of work for TRS-based TDCP reporting will focus on the following use cases for evaluation purposes: - Targeting medium and high UE speeds, e.g., 10-120 km / h, as well as HST speeds; CSI reporting configuration and CSI-RS resource configuration parameters; A precoding scheme using one of a CSI feedback based precoding scheme or a UL-SRS reciprocity based precoding scheme. - Assist the gNB in ​​determining - To assist gNB-side CSI prediction.

[0044] As agreed above, there are several use cases for the gNB to know the time-domain channel characteristics (TDCP) based on TRS measurements. One use case for TDCP reporting is to enable the gNB to select a transmission scheme that is more robust to channel aging when the channel is fast varying. For example, based on the TRS-based TDCP reported by the UE to the gNB, the gNB may need to decide whether the precoder for the UE should be based on CSI obtained from uplink measurements or on CSI feedback obtained from the UE. Another example is that the gNB may need to decide whether the precoder for scheduling the UE should be based on Type I CSI feedback obtained from the UE or on Type II CSI feedback obtained from the UE.

[0045] Figure 7 shows the average user throughput for a particular scheme relative to the average throughput for feedback-based SU-MIMO precoding (baseline). In Figure 7, the relative average user throughput versus UE speed for reciprocity and feedback-based CSI. The upper case in Figure 7 is for 16 gNB antenna ports, and the lower case is for 32 gNB antenna ports. The throughput was calculated for a traffic load corresponding to 70% resource utilization for the baseline case at each UE speed. Results for both SU-MIMO and MU-MIMO are shown in the figure. The scenario is UMa with a site-to-site distance of 500 m. The carrier frequency is 2 GHz, and the subcarrier spacing is 15 kHz. The CSI periodicity is 20 ms for both feedback and reciprocity-based CSI. The results show that reciprocity-based precoding has better performance at 3 km / h for both SU-MIMO and MU-MIMO. However, at UE speeds around 10 km / h, feedback-based precoding has better performance. Therefore, feedback-based precoding is more robust to fast-varying channels: a speed of 10 km / h corresponds to a channel coherence time longer than two slots.

[0046] Figure 8 shows a comparison of the performance of precoding based on Type I and Type II CSI, respectively. The results show that Type II CSI gives better performance at 3 km / h, but Type I gives better performance at UE speeds around and above 10 km / h.

[0047] These results indicate that it may be beneficial to select a precoding scheme based on some parameter related to the UE speed. Note that the fundamental parameter in this context is not the UE speed itself. Rather, it depends on how fast the channel varies, which also depends on the UE speed and the angle between the UE speed vector and the propagation path seen by the UE. Therefore, selecting a precoding scheme based on some time-domain channel characteristic, such as coherence time or autocorrelation, is a more suitable parameter.

[0048] UE measurement and reporting of time domain correlation based on TRS samples over different time lags is an efficient way to report TDCP based on TRS.

[0049] To define the time-domain correlation measurement across TRS samples, X l Let [n], n=0, 1, ..., N-1 be the received frequency-domain TRS samples after matched filtering and after removing the reference signal sequence. The index l indicates the different OFDM symbols carrying the TRS used for correlation estimation. Note that the TRS used for correlation estimation can be located in the same or different slots. The time starting point of OFDM symbol l is t l (To be precise, t l indicates the start of the non-CP portion of the OFDM symbol). The index n indicates the TRS sample index (assumed to be proportional to the subcarrier index).

[0050] P m (u), m=1...M, u=1, 2, TIFF2025533520000010.tif7170Let l be the index of the M symbol pairs to be used for correlation estimation. The M symbol pairs are assumed to be separated in time by the same distance.

[0051] In one example, a low-complexity estimate of the normalized time-domain correlation for lag τ is calculated in the frequency domain as follows: TIFF2025533520000011.tif12170 In another example, the inverse DFT is calculated for each OFDM symbol l as follows: Y l [k]=ifft(X l [n]) The normalized correlation estimate for the time lag τ is calculated as follows: TIFF2025533520000012.tif12170 where the sum over the time samples is over a set Γ(m) defined to suppress noise, for example by using a noise threshold such as: TIFF2025533520000013.tif26170 where, TIFF2025533520000014.tif7170 Noise estimate.

[0052] Note that at low speeds, the channel variation is small and the variation in correlation at different delays within a TRS burst is very small (note that the TRS burst is defined as in FIG. 2). Within a TRS burst, correlation can be measured for delays of 4 symbols, 10 symbols, 14 symbols, and 18 symbols, as shown in FIG. 9. FIG. 9 shows the delays τ where correlation can be estimated based on intra-TRS burst measurements using the TRS signal. k τ1=4·T OFDM+CP , and τ2=T SLOT =14 T OFDM+CP If , there are two samples in the TRS burst that can be used for measurement, while τ3=18 T OFDM+CP and τ4=10·T OFDM+CP Note that in the case of , there is only one sample in the TRS burst that can be used for measurement.

[0053] Because the change in correlation at different delays within a TRS burst is extremely small for low speeds, intra-TR burst measurements are not sufficient to distinguish between different speeds in the low speed range. Therefore, support for measuring and reporting correlation for time delays corresponding to multiple TRS bursts is needed.

[0054] As an alternative to reporting correlations at different delays, other reporting quantities may be considered for TRS-based TDCP reporting, such as: Doppler spread f defined as the second moment of TIFF2025533520000015.tif7170 d teeth, TIFF2025533520000016.tif14170It is directly related to the second derivative of the autocorrelation at zero autocorrelation lag, thereby giving the form of the autocorrelation function for small autocorrelation lags.

[0055] The measurement of the second moment of Doppler power is most likely to be performed in the time lag domain rather than in the Doppler shift domain. In fact, it is most likely to be based on measuring the autocorrelation for several autocorrelation lags. This makes a definition based on autocorrelation preferable to one based on the Doppler power spectrum when this measure is used. For example, the Doppler spread f d may be defined in terms of the normalized autocorrelation function by: A(τ)=1-2π 2 f d 2 ·τ 2 +σ(τ 4 )

[0056] Currently, there are some challenges. Summary of the Invention

[0057] In some embodiments, the method includes receiving a reporting configuration from a network including a TDCP reporting quantity to be reported by a UE for TDCP reporting, receiving a reference signal configuration from the network including one or more TRS samples, receiving signaling from the network indicating one or more measurement windows, receiving signaling from the network limiting a number of TRS samples to be considered when calculating / updating the TDCP reporting quantity, calculating and / or updating the TDCP reporting quantity to be reported using only the TRS samples in the indicated one or more measurement windows, calculating and / or updating the TDCP reporting quantity to be reported using only the indicated number of TRS samples, receiving a DCI from the network that triggers aperiodic TDCP reporting, reporting the calculated / updated TDCP reporting quantity during the one or more measurement windows as part of the aperiodic TDCP reporting, and reporting the calculated / updated TDCP reporting quantity using only the indicated number of TRS samples as part of the aperiodic TDCP reporting. In this way, the UE measurement burden associated with measuring TRS to derive the TDCP reporting quantity can be reduced. The solution is particularly useful when periodic TRS is configured and when the UE is triggered aperiodically for TDCP reporting. Additionally, some of the proposed autocorrelation measures are robust to phase jumps. Some of the proposed autocorrelation measures are robust to frequency adjustments. In some embodiments, a measurement window that includes multiple measurement occasions and allows the UE to abandon some of the measurement occasions due to phase jumps and / or frequency adjustments provides robustness against such events.

[0058] In the present disclosure, the following aspects are proposed: signaling a measurement window that allows the UE to calculate / update the TDCP reporting quantity, thereby alleviating the need for the UE to constantly calculate / update the TDCP report (thereby reducing the UE measurement / calculation / update burden related to TDCP reporting); a mechanism related to the order of operations (averaging over time, averaging over frequency, taking absolute value, normalization) in defining the autocorrelation measure when autocorrelation should be reported as the TDCP reporting quantity; aspects related to when the UE can abandon some of the measurements or measurement occasions within the measurement window; and rules regarding the number of CPUs occupied for measurements and calculations related to TDCP reporting.

[0059] In some embodiments, a method for TDCP reporting based on measurement of TRS samples comprises receiving from a network a reporting configuration including a TDCP reporting amount to be reported by a UE for TDCP reporting; receiving from the network a reference signal configuration including one or more TRS samples; receiving from the network signaling indicating one or more measurement windows; the UE calculating or updating the TDCP reporting amount to be reported using only the TRS samples in the indicated one or more measurement windows; receiving from the network a DCI triggering aperiodic TDCP reporting; and the UE reporting the calculated / updated TDCP reporting amount during the one or more measurement windows as part of the aperiodic TDCP reporting.

[0060] In some embodiments, a method for TDCP reporting based on measurement of TRS samples comprises receiving a reporting configuration from a network including a TDCP reporting quantity to be reported by a UE for TDCP reporting; receiving a reference signal configuration from the network including one or more TRS samples; receiving signaling from the network limiting a number of TRS samples to be considered when calculating / updating the TDCP reporting quantity; the UE calculating or updating the TDCP reporting quantity to be reported using only the indicated number of TRS samples; receiving a DCI from the network that triggers aperiodic TDCP reporting; and the UE reporting the TDCP reporting quantity calculated / updated using only the indicated number of TRS samples as part of the aperiodic TDCP reporting.

[0061] In some embodiments, the order of operations (averaging over time, averaging over frequency, taking absolute value, normalizing) in defining the autocorrelation measure.

[0062] In some embodiments, aspects relating to when the UE can abandon some of the measurements or measurement occasions within a measurement window.

[0063] In some embodiments, rules regarding the number of CPUs that are dedicated to measurements and calculations related to TDCP reporting.

[0064] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate several aspects of the present disclosure and, together with the description, serve to explain the principles of the disclosure. [Brief explanation of the drawings]

[0065] [Figure 1] FIG. 1 is a diagram illustrating an example of channel state information reference signal (CSI-RS) resource elements (REs) for 12 antenna ports, where one RE per resource block (RB) per port is shown. [Figure 2]FIG. 1 illustrates an example of a tracking reference signal (TRS) burst of two TRS symbols in two adjacent slots. [Figure 3] FIG. 10 illustrates the configurability of TRS symbol position and TRS burst periodicity. [Figure 4] FIG. 1 illustrates a non-periodic trigger state definition. [Figure 5] FIG. 1 is a diagram illustrating the concept of central processing unit (CPU) occupancy, where the UE is assumed to have two available CPUs. [Figure 6] Figure 1 shows the zeroth-order Bessel function of the first kind (y-axis shows autocorrelation, x-axis shows 2π·τ·fmax). [Figure 7] FIG. 1 illustrates the average user throughput for certain schemes relative to the average throughput for feedback-based single-user multiple-input multiple-output (SU-MIMO) precoding (baseline). [Figure 8] 10A and 10B show a comparison of the performance of precoding based on Type-I and Type-II CSI, respectively. [Figure 9] FIG. 10 illustrates a delay τ k for which correlation can be estimated based on intra-TRS burst measurements using a TRS signal. [Figure 10] FIG. 1 illustrates an example showing periodic TRS measurement time configuration (TRS-MTC) in accordance with some embodiments of the present disclosure. [Figure 11] FIG. 10 illustrates an example showing aperiodic triggering of time-domain channel characteristic (TDCP) reporting, in which the amount of TDCP to be reported is measured using periodic TRS-MTC, in accordance with some embodiments of the present disclosure. [Figure 12] FIG. 10 illustrates an example showing aperiodically triggered TRS-MTC according to some embodiments of the present disclosure. [Figure 13] FIG. 1 illustrates a method implemented by a user equipment (UE) for TDCP reporting based on measurements of TRS samples, according to some embodiments of the present disclosure. [Figure 14]FIG. 1 illustrates an example of a communication system, according to some embodiments. [Figure 15] FIG. 1 illustrates a UE, according to some embodiments. [Figure 16] FIG. 1 illustrates a network node, according to some embodiments. [Figure 17] FIG. 15 is a block diagram of a host, which may be an embodiment of the host of FIG. 14, in accordance with various aspects described herein. [Figure 18] FIG. 1 is a block diagram illustrating a virtualization environment in which functionality implemented by some embodiments may be virtualized. [Figure 19] FIG. 2 illustrates a communication diagram of a host communicating with a UE via a network node over a partial wireless connection, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0066] The embodiments described below represent information to enable those skilled in the art to practice the embodiments and to illustrate the best mode of practicing the embodiments. Upon reading the following description with reference to the accompanying drawing figures, those skilled in the art will understand the concepts of the present disclosure and will recognize applications of these concepts not addressed in detail herein. These concepts and applications should be understood to fall within the scope of the present disclosure.

[0067] As discussed above, for tracking reference signal (TRS) based time domain channel characteristic (TDCP) reporting, the TDCP amount to be reported (e.g., different lags or Doppler spread f dThe autocorrelation value at τ may require measurement of the TRS transmitted at different lags. When TDCP reporting is triggered aperiodically via DCI, the UE may need to be ready for the measured TDCP amount to be reported in response to the aperiodic trigger. However, when periodic TRS is configured, the UE does not know in advance when the aperiodic trigger for TDCP reporting will be received, so the UE may need to constantly measure the TRS and calculate / update the TDCP amount every period. This increases the measurement burden on the UE. Therefore, it is an open question how to alleviate the measurement burden when the UE should support aperiodically triggered TDCP reporting.

[0068] Another problem is that phase jumps and RX frequency adjustments may occur in the UE while the TDCP measurements are being performed, which may affect the TDCP measurements.

[0069] Certain aspects of the present disclosure and embodiments thereof may provide solutions to these and other problems.

[0070] A system and method for channel measurement for TRS-based TDCP reporting is provided. In some embodiments, the method includes receiving a reporting configuration from a network including a TDCP reporting quantity to be reported by a UE for TDCP reporting, receiving a reference signal configuration from the network including one or more TRS samples, receiving signaling from the network indicating one or more measurement windows, receiving signaling from the network limiting a number of TRS samples to be considered when calculating / updating the TDCP reporting quantity, calculating and / or updating the TDCP reporting quantity to be reported using only the TRS samples in the indicated measurement window or windows, calculating and / or updating the TDCP reporting quantity to be reported using only the indicated number of TRS samples, receiving a DCI from the network that triggers aperiodic TDCP reporting, reporting the calculated / updated TDCP reporting quantity during the one or more measurement windows as part of the aperiodic TDCP reporting, and reporting the calculated / updated TDCP reporting quantity using only the indicated number of TRS samples as part of the aperiodic TDCP reporting. In this way, the UE measurement burden associated with measuring TRS to derive the TDCP reporting quantity can be reduced. The solution is particularly useful when periodic TRS is configured and when the UE is triggered aperiodically for TDCP reporting. Additionally, some of the proposed autocorrelation measures are robust to phase jumps. Some of the proposed autocorrelation measures are robust to frequency adjustments. In some embodiments, a measurement window that includes multiple measurement occasions and allows the UE to abandon some of the measurement occasions due to phase jumps and / or frequency adjustments provides robustness against such events.

[0071] In one embodiment, a TRS measurement time configuration (TRS-MTC) may be configured in the UE, where the UE is only required to calculate / update the TDCP amount using TRS samples and / or TRS bursts within the configured measurement time. The TRS-MTC may be considered as a measurement window in which the UE calculates / updates the TDCP amount using only TRS samples and / or TRS bursts within each measurement window. Note that the TRS-MTC does not impose any restrictions on when the UE can use TRS samples for high-precision time / frequency synchronization. That is, the UE is allowed to use any TRS samples and / or TRS bursts, regardless of whether they are within or outside the TRS-MTC, to perform high-precision time / frequency synchronization. However, the UE does not calculate / update the TDCP amount using TRS samples and / or TRS bursts outside the TRS-MTC.

[0072] An example illustrating periodic TRS-MTC is depicted in FIG. 10. In this figure, vertical arrows represent periodic TRS bursts with a periodicity of P1 (in other words, two TRS bursts are separated by P1, where P1 may be defined in terms of slots or symbols). A periodicity of P2 is set for the TRS measurement window or TRS-MTC in this example (in other words, the gap between two TRS measurement windows is given by P2, where P2 may be defined in terms of slots or symbols). In that case, the UE may calculate / update the TDCP metric using TRS samples and / or TRS bursts within each periodic TRS measurement window. For example, when autocorrelation with a given lag is used as the TDCP reporting metric, the UE may calculate or update the autocorrelation between two TRS samples belonging to two TRS bursts within the TRS measurement window (indicated by two vertical arrows in each TRS measurement window or TRS-MTC). In some embodiments, the TDCP amount is calculated or updated only during each periodic TRS measurement window (or each TRS-MTC), and the calculated / updated TDCP amount is valid until the next TRS measurement window. In some other embodiments, the TDCP amount is calculated or updated during each TRS measurement window, and the calculated / updated TDCP amount may be a running average or weighted average of the last N1 samples. In one example, N1 may be equal to 3. In some examples, N1 may be equal to 1. In some embodiments, the value of N1 may be dictated by UE capabilities or NW configuration parameters.

[0073] In some embodiments, each TRS measurement window (or TRS-MTC) also has a duration or length T2. The duration or length may be configured via higher layer parameters (e.g., RRC parameters). By configuring an appropriate duration for the TRS measurement window T2, the gNB can control how many TRS bursts are included in each TRS measurement window. This allows the gNB to control for which time lag values ​​TDCP quantities, such as autocorrelation, can be calculated / updated. For example, a larger duration or length of the TRS measurement window allows more TRS bursts to be included in each TRS measurement window, and therefore allows autocorrelation to be calculated for larger time lags. Note that a larger duration or length of the TRS measurement window also allows autocorrelation to be calculated for smaller time lags as well.

[0074] Conversely, a smaller duration or length of the TRS measurement window allows fewer TRS bursts to be included in each TRS measurement window, and therefore allows the autocorrelation to be calculated over a smaller time lag.

[0075] In some embodiments, the length of the TRS measurement window and / or the size of the time lag over which the autocorrelation can be calculated within the TRS measurement window are part of the UE capabilities, and the specific capabilities regarding the length of the TRS measurement window and / or the size of the time lag over which the autocorrelation can be calculated for a given UE are reported to the network as part of the UE capabilities.

[0076] Figure 11 illustrates an example showing aperiodic triggering of TDCP reporting, in which the TDCP amount to be reported is measured using periodic TRS-MTC. Figure 11 shows an example of aperiodic triggered TDCP reporting based on measurements performed using periodic TRS-MTC. As described above, the UE may calculate / update the TDCP amount to be reported in the TRS measurement window (or TRS-MTC). The gNB then triggers a DCI requesting the UE to feedback a TDCP report. The UE then feedbacks the calculated / updated TDCP amount using the latest TRS measurement window (e.g., using the TRS measurement time window shown to the left of the DCI trigger in Figure 11).

[0077] An example illustrating higher layer signaling for periodic TRS-MTC is shown in Figure 10. As shown in the figure, the parameter "periodicityAndOffset" in the TRS-MTC information element provides the periodicity and slot offset for periodic TRS-MTC. The higher layer parameter "duration" provides the duration of each TRS measurement window. In some embodiments, the TRS measurement window may be configured as part of the CSI-ReportConfig IE specified in 3GPP TS 38.331 v17.1.0. Alternatively, the TRS measurement window may be configured as part of the NZP-CSI-RS-ResourceSet IE specified in 3GPP TS 38.331 v17.1.0 or as part of the NZP-CSI-RS-Resource IE specified in 3GPP TS 38.331 v17.1.0.

[0078] An example RRC configuration for periodic TRS-MTC is shown below.

[0079] TRS-MTC information element TIFF2025533520000017.tif92170

[0080] An example illustrating aperiodically triggered TRS-MTC is depicted in FIG. 12. The TRS measurement window or TRS-MTC in this example is triggered by the gNB via a DCI. The UE may then calculate / update the TDCP amount using TRS samples and / or TRS bursts within the aperiodically triggered TRS measurement window. Note that in some embodiments, the DCI that triggers the aperiodic triggered TRS measurement window is different from the DCI that triggers the aperiodic TDCP reporting. In alternative embodiments, the DCI that triggers the aperiodic triggered TRS measurement window is the same as the DCI that triggers the aperiodic TDCP reporting.

[0081] Alternatively, instead of DCI, the gNB may use a MAC CE to activate a TRS measurement window (referred to as a semi-persistent TRS measurement window). In this case, the TRS measurement window (note that the TRS measurement window may have a periodicity and offset as well as a duration in this case) is activated and deactivated by the gNB via the MAC CE. For example, the gNB may send a first MAC CE to activate the semi-persistent TRS measurement window. The TRS measurement window with the periodicity / offset and duration is active until a second MAC CE is sent by the gNB to deactivate the semi-persistent TRS measurement window. In this case, the UE performs TDCP amount calculation / update only when the semi-persistent TRS measurement window is active.

[0082] In one embodiment, the CPU occupancy duration for TDCP reporting is determined with respect to the TRS measurement window. In one example, measurements and / or calculations related to the TDCP reporting quantity occupy the CPU from the first symbol of the earliest TRS burst / resource within the TRS measurement window to the latest symbol of the TRS burst / resource within the TRS measurement window. Several CPUs may be assumed to be consumed for measurements and / or calculations related to the TDCP reporting quantity during this duration. In some cases, a single CPU may be assumed to be consumed for measurements and / or calculations related to the TDCP reporting quantity for the TRS resources configured for TDCP reporting.

[0083] In one embodiment, additional time is added to the last TRS symbol in the TRS measurement window for CPU occupancy. In one embodiment, instead of the last TRS symbol in the active window, the last OFDM or downlink OFDM symbol in the window is used to determine the CPU occupancy duration. In another embodiment, the CPU assumed for measurements and / or calculations related to TDCP reporting quantities is assumed for the entire duration of the TRS measurement window.

[0084] In one embodiment, if there is no CPU available for the TRS measurement window, the TDCP reporting quantity does not need to be calculated / updated.

[0085] In one embodiment, if the UE is configured for DRX and the active measurement window for TDCP reporting is outside the DRX active time, the TDCP amount does not need to be updated.

[0086] In some alternative embodiments, the TDCP amount is calculated or updated during every TRS transmission opportunity (in other words, not only during the TRS measurement window), and the calculated / updated TDCP amount may be a running average or weighted average of the last N1 TDCP measurements. The advantage of this is that the UE can report the measurement immediately after receiving the measurement report trigger. This is especially important if the measurement report trigger prevents another PUSCH from being scheduled until the report is sent. In some embodiments, the value of N1 may depend on UE capabilities and / or NW configuration parameters. In some examples, if it is UE capabilities, the N1 value may depend on the UE capability to store and update N1 TDCP samples. In some examples, if N1 is based on NW configuration parameters, N1 may be 1 if the NW configures the UE to consider only one TDCP measurement for averaging. In some embodiments, N1 may be a fixed value (e.g., 3) if the NW configures the UE to consider an average of two or more TDCP measurements to derive the TDCP measurement update. The NW configuration may be indicated by a parameter called timeRestrictionForTDCPMeasurements in the RRC message. In some other embodiments, if timeRestrictionForTDCPMeasurements is set, N1 is assumed to be 1. Otherwise, N1 is assumed to be some other fixed value (e.g., 3).

[0087] In some other embodiments, N1 may be a variable and may be set by an RRC message.

[0088] Measurement reports are typically based on several measurements made at different time points during a measurement window. Each of these measurements is based on the presence of a TRS in some time symbol. As an example, measuring autocorrelation for a certain autocorrelation lag (or time lag) requires the presence of a TRS in two symbols separated in time by that autocorrelation lag. The presence of a TRS symbol suitable for a measurement is called a measurement occasion.

[0089] In some embodiments, the UE may be configured to receive the following signals for the following reasons: ● A phase jump occurred for the UE that invalidated a measurement or measurement occasion (e.g., between two TRS symbols to be used for an autocorrelation measurement); The UE has performed an RX frequency adjustment that invalidates a measurement or measurement occasion (e.g., between two TRS symbols to be used for an autocorrelation measurement); ● The UE processing capacity is overloaded and other processes are prioritized. One or more of the following causes some of the measurements or measurement opportunities within the measurement window to be discarded:

[0090] In some embodiments, the UE includes information in the measurement report regarding which measurements / measurement occasions were abandoned.

[0091] In some embodiments, the UE includes information in the measurement report regarding which measurement / measurement occasion was used.

[0092] In some embodiments, the TDCP measure is an autocorrelation measure or some quantity calculated based on autocorrelation measures for one or more autocorrelation lags. In some embodiments, the autocorrelation measure is, for example, over time and frequency as follows: TIFF2025533520000018.tif5170 is defined by averaging. TIFF2025533520000019.tif13170where n is the subcarrier index, S is a set of subcarrier indices with |S| elements, k is the time symbol index, M is a set of time symbol indices with |M| elements, and h n (t) is the baseband channel for subcarrier n at time t. Since the summation over both time and frequency is coherent, this definition allows for measurement methods with very good noise suppression.

[0093] The UE may estimate this quantity using the formula above, but the channel h n (t k ) by matched filtering X n (t k ) and, if necessary, restrict the sets M and S to the subcarriers and symbols that carry the TRS. The fact that the sum is coherent may provide some degree of noise suppression. Coherency across frequency also allows the use of additional noise suppression techniques. The UE may, for example, use the X n Y defined as the IDFT of l Based on this, estimation may be performed in the time domain.

[0094] In some other embodiments, the autocorrelation measure is defined as follows (using the same nomenclature): TIFF2025533520000020.tif14170

[0095] This measure is the phase jump that occurs between time t and time t+τ, i.e., h n (t+τ)→e jα h n (t+τ), where the phase is independent of frequency / subcarrier. Such phase jumps can occur, for example, when the UE switches between DL reception and UL transmission, or when it goes in and out of sleep mode, for example, to save energy. Since the summation over subcarriers is coherent, this provision enables a measurement method with good noise suppression.

[0096] The UE may estimate this quantity using the formula above, but the channel h n (t k ) by matched filtering X n (t k) and, if necessary, restrict the sets M and S to the subcarriers and symbols that carry the TRS. The fact that the summation across subcarriers is coherent may provide some degree of noise suppression. Coherency across frequency also allows the use of additional noise suppression techniques. The UE may, for example, use the X n Y defined as the IDFT of l Based on this, estimation may be performed in the time domain.

[0097] In some other embodiments, the autocorrelation measure is defined as follows (using the same nomenclature as above): TIFF2025533520000021.tif13170

[0098] This measure is independent of frequency changes / adjustments made between time t and time t+τ, and is n (t+τ)→e j(α+β·n) h n This results in a frequency dependent phase rotation of the form (t+τ).

[0099] The UE may estimate this quantity using the formula above, but the channel h n (t k ) by matched filtering X n (t k ) with the received frequency-domain TRS samples after , and, if necessary, restrict the sets M and S to the subcarriers and symbols that carry the TRS. The fact that the sum is incoherent makes it difficult to apply noise suppression techniques.

[0100] In one embodiment, the set S includes all subcarriers of a carrier. In another embodiment, S is the set of subcarriers carrying a reference signal (e.g., TRS) used for autocorrelation estimation. This second embodiment has the advantage of being closer to what the UE can actually measure, making it easier to specify requirements for UE measurement accuracy. However, including all subcarriers in S may be considered more theoretically correct since all subcarriers are used for communication, and is also closer to the ideally desired measure. Note that even if all subcarriers are used in specifying the quantity, the UE may utilize a subset of subcarriers for measurements.

[0101] In one embodiment, the set of symbol time indices M is k is all symbol time indexes k within the measurement period [a, b], in other words, t k It consists of an index k ∈ [a, b].

[0102] In another embodiment, M is the number of symbol times t k and therefore the symbol t k and t k Both τ and τ carry reference signals used for estimating the autocorrelation. This second embodiment has the advantage of being closer to what the UE can actually measure, making it easier to specify requirements for UE measurement accuracy. However, including all symbol times within the measurement period may be considered more theoretically correct, since all symbols are used for communication, and is also closer to the ideally desired measure. Note that even if all time symbols within the measurement period are used in specifying the quantity, the UE may utilize a subset of the time symbols for measurement.

[0103] In some embodiments, the UE reports a measurement of one of the following quantities: for one or more autocorrelation lags τ, TIFF2025533520000022.tif30170 Absolute value of the autocorrelation function.

[0104] In yet another set of embodiments, the autocorrelation measure is defined as one of the following: TIFF2025533520000023.tif43170For these measures, normalization is performed before averaging over time, so that c(0)=1. In yet another set of embodiments, the autocorrelation measure is defined as one of the following: TIFF2025533520000024.tif42170

[0105] For these measures, normalization is performed before averaging over time and frequency, so that c(0)=1.

[0106] In another alternative embodiment where the TDCP reporting amount is calculated or updated during a TRS transmission opportunity selected by the UE (in other words, when within a TRS opportunity TDCP should be measured may be up to the UE implementation), the TDCP report sent by the UE at time unit n should be based on n and the TRS opportunity within the n-timeWindow. This means that the UE should not send a measured TDCP report more than a certain time (e.g., timeWindow) from the TDCP request opportunity from the NW node.

[0107] In some embodiments, a combination of the above embodiments may be selected to arrive at a solution.

[0108] 13 illustrates a method implemented by a UE for TDCP reporting based on measurement of TRS samples. In some embodiments, the method includes receiving from the network a reporting configuration including a TDCP reporting amount to be reported by the UE for TDCP reporting (step 1300), receiving from the network a reference signal configuration including one or more TRS samples (step 1302), receiving from the network signaling indicating one or more measurement windows (step 1304A), receiving from the network signaling limiting the number of TRS samples to be considered when calculating / updating the TDCP reporting amount (step 1304B), and calculating / updating the TDCP reporting amount using only the TRS samples in the indicated measurement window or windows. The method includes one or more of: calculating and / or updating a TDCP reporting amount to be reported using only the indicated number of TRS samples (step 1306A); calculating and / or updating a TDCP reporting amount to be reported using only the indicated number of TRS samples (step 1306B); receiving a DCI from the network that triggers aperiodic TDCP reporting (step 1308); reporting the calculated / updated TDCP reporting amount during one or more measurement windows as part of the aperiodic TDCP reporting (step 1310A); and reporting the calculated / updated TDCP reporting amount using only the indicated number of TRS samples as part of the aperiodic TDCP reporting (step 1310B).

[0109] FIG. 14 illustrates an example of a communication system 1400, according to some embodiments.

[0110] In this example, the communications system 1400 includes a communications network 1402 including an access network 1404, such as a radio access network (RAN), and a core network 1406 including one or more core network nodes 1408. The access network 1404 includes one or more access network nodes (one or more of which may be generically referred to as network nodes 1410), such as network nodes 1410A and 1410B, or any other similar Third Generation Partnership Project (3GPP) access nodes or non-3GPP access points (APs). The network nodes 1410 facilitate direct or indirect connectivity of user equipment (UE), such as by connecting UEs 1412A, 1412B, 1412C, and 1412D (one or more of which may be generically referred to as UEs 1412), to the core network 1406 over one or more wireless connections.

[0111] Exemplary wireless communication over a wireless connection includes sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, communication system 1400 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in communication of data and / or signals, whether via wired or wireless connections. Communication system 1400 may include and / or interface with any type of communication, telecommunication, data, cellular, wireless network, and / or other similar type systems.

[0112] The UE 1412 may be any of a wide variety of communication devices, including a wireless device configured, configured, and / or operable to communicate wirelessly with the network node 1410 and other communication devices. Similarly, the network node 1410 is configured, capable of, configured, and / or operable to communicate, directly or indirectly, with the UE 1412 and / or with other network nodes or equipment in the communications network 1402 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration, in the communications network 1402.

[0113] In the depicted example, the core network 1406 connects the network node 1410 to one or more hosts, such as the host 1416. These connections may be direct or indirect via one or more intermediate networks or devices. In other examples, the network node may be directly coupled to the host. The core network 1406 includes one or more core network nodes (e.g., the core network node 1408) structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, and therefore, those descriptions are generally applicable to the corresponding components of the core network node 1408. Exemplary core network nodes include one or more of a Mobile Switching Center (MSC), a Mobility Management Entity (MME), a Home Subscriber Server (HSS), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Subscription Identifier De-concealing Function (SIDF), a Unified Data Management (UDM), a Security Edge Protection Proxy (SEPP), a Network Publishing Function (NEF), and / or a User Plane Function (UPF).

[0114] The host 1416 may be owned or under the control of, and operated by or on behalf of, a service provider other than the operator or provider of the access network 1404 and / or the communication network 1402. The host 1416 may host various applications to provide one or more services. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data about various ambient conditions detected by multiple UEs, analytics functions, social media, functions for controlling or possibly interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0115] 14 enables connectivity between UEs, network nodes, and hosts. In that sense, communication system 1400 may be configured to operate according to predefined rules or procedures, such as a particular standard, including, but not limited to, Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable second-, third-, fourth-, or fifth-generation (2G, 3G, 4G, or 5G) standards, or any applicable next-generation standard (e.g., sixth-generation (6G)); a wireless local area network (WLAN) standard, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and / or any other suitable wireless communication standard, such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communications (NFC), ZigBee, LiFi, and / or any low-power wide area network (LPWAN) standard, such as LoRa and Sigfox.

[0116] In some examples, the communication network 1402 is a cellular network that implements 3GPP standardized features. Thus, the communication network 1402 may support network slicing to provide different logical networks to different devices connected to the communication network 1402. For example, the communication network 1402 may provide Ultra-Reliable Low Latency Communication (URLLC) services to some UEs, while providing enhanced Mobile Broadband (eMBB) services to other UEs and / or providing Massive Machine-Based Communication (mMTC) / Massive Internet of Things (IoT) services to still further UEs.

[0117] In some examples, the UE 1412 is configured to transmit and / or receive information without direct human interaction. For example, the UE may be designed to transmit information to the access network 1404 on a predetermined schedule, when triggered by an internal or external event, or in response to a request from the access network 1404. Additionally, the UE may be configured to operate in a single or multi-radio access technology (RAT) or multi-standard mode. For example, the UE may operate with any one or a combination of Wi-Fi, New Radio (NR), and LTE, in other words, for multi-radio dual connectivity (MR-DC), such as Evolved UMTS Terrestrial RAN (E-UTRAN) NR dual connectivity (EN-DC).

[0118] In this example, a hub 1414 communicates with the access network 1404 to facilitate indirect communication between one or more UEs (e.g., UEs 1412C and / or 1412D) and a network node (e.g., network node 1410B). In some examples, the hub 1414 may be a controller, a router, a content source and analysis, or any of the other communication devices described herein with respect to UEs. For example, the hub 1414 may be a broadband router that enables access to the core network 1406 for the UE. As another example, the hub 1414 may be a controller that sends commands or instructions to one or more actuators in the UE. The commands or instructions may be received from the UE, the network node 1410, or may be due to executable code, scripts, processes, or other instructions in the hub 1414. As another example, the hub 1414 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1414 may be a content source. For example, for a UE that is a virtual reality (VR) headset, display, loudspeaker, or other media distribution device, the hub 1414 may retrieve, via a network node, VR assets, video, audio, or other media or data related to sensory information, which the hub 1414 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In yet another example, the hub 1414 acts as a proxy server or orchestrator for the UEs, particularly if one or more of the UEs are low energy IoT devices.

[0119] The hub 1414 may have a constant / permanent or intermittent connection to the network node 1410B. The hub 1414 may also enable different communication schemes and / or schedules between the hub 1414 and the UEs (e.g., UEs 1412C and / or 1412D) and between the hub 1414 and the core network 1406. In other examples, the hub 1414 is connected to the core network 1406 and / or one or more UEs via a wired connection. Moreover, the hub 1414 may be configured to connect to a machine-to-machine (M2M) service provider over the access network 1404 and / or to another UE over a direct connection. In some scenarios, a UE may establish a wireless connection with the network node 1410 while still connected via a wired or wireless connection through the hub 1414. In some embodiments, the hub 1414 may be a dedicated hub, i.e., a hub whose primary function is to route communications from / to the UE to / from the network node 1410B. In other embodiments, the hub 1414 may be a non-dedicated hub, i.e., a device that is capable of operating to route communications between the UE and the network node 1410B, but is additionally capable of operating as a communication initiation and / or termination point for some data channels.

[0120] Figure 15 illustrates a UE 1500 according to some embodiments. As used herein, a UE refers to a device capable of, set up, configured, and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smartphone, a mobile phone, a cell phone, a Voice over Internet Protocol (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless camera, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop computer, a laptop embedded equipment (LEE), a laptop mounted equipment (LME), a smart device, a wireless customer premises equipment (CPE), a vehicle-mounted or vehicle-embedded / integrated wireless device, etc. Other examples include any UE identified by 3GPP, including a Narrowband Internet of Things (NB-IoT) UE, a Machine Type Communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0121] A UE may support device-to-device (D2D) communications, for example, by implementing 3GPP standards for sidelink communications, dedicated short-range communications (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates an associated device. Instead, a UE may represent a device (e.g., a smart sprinkler controller) that is intended for sale to or operation by a human user, but that may not be associated with or initially associated with a particular human user. Alternatively, a UE may represent a device (e.g., a smart power meter) that is not intended for sale to or operation by an end user, but that may be associated with or operated for the user's benefit.

[0122] The UE 1500 includes a processing circuit 1502 operably coupled to an input / output interface 1506, a power source 1508, a memory 1510, a communication interface 1512, and / or any other components, or any combination thereof, via a bus 1504. Some UEs may utilize all or a subset of the components shown in FIG. 15. The level of integration between components may vary from UE to UE. Additionally, some UEs may include multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0123] The processing circuit 1502 is configured to process instructions and data and may be configured to implement any sequential state machine operable to execute instructions stored in memory 1510 as a machine-readable computer program. The processing circuit 1502 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, a general-purpose processor, such as a microprocessor or digital signal processor (DSP) together with appropriate software; or any combination of the above. For example, the processing circuit 1502 may include multiple central processing units (CPUs).

[0124] In this example, the input / output interface 1506 may be configured to provide one or more interfaces to an input device, an output device, or one or more input and / or output devices. Examples of output devices include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smart card, another output device, or any combination thereof. An input device may allow a user to capture information on the UE 1500. Examples of input devices include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smart card, etc. A presence-sensitive display may include a capacitive or resistive touch sensor for detecting input from a user. The sensor may be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, a light sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as the input device. For example, a universal serial bus (USB) port may be used to accommodate input and output devices.

[0125] In some embodiments, the power source 1508 is constructed as a battery or battery pack. Other types of power sources may be used, such as an external power source (e.g., an electrical outlet), a photovoltaic device, or a battery. The power source 1508 may further include power circuitry for delivering power to various portions of the UE 1500 from the power source 1508 itself and / or from an external power source via an input circuit or an interface such as a power cable. Delivering power may be for charging the power source 1508, for example. The power circuitry may perform any formatting, conversion, or other modification on the power from the power source 1508 to make it suitable for each component of the UE 1500 being powered.

[0126] The memory 1510 may be or be configured to include memory, such as random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrical EPROM (EEPROM), magnetic disk, optical disk, hard disk, removable cartridge, flash drive, etc. In one example, the memory 1510 includes one or more application programs 1514, such as an operating system, a web browser application, a widget, a gadget engine, or other applications, and corresponding data 1516. The memory 1510 may store any of a variety of different operating systems or combinations of operating systems for use by the UE 1500.

[0127] The memory 1510 may be configured to include several physical drive units, such as a redundant array of independent disks (RAID), flash memory, a USB flash drive, an external hard disk drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile disc (HD-DVD) optical disc drive, an internal hard disk drive, a Blu-ray optical disc drive, a holographic digital data storage (HDDS) optical disc drive, an external mini dual in-line memory module (DIMM), a synchronous dynamic random access memory (SDRAM), an external micro-DIMM SDRAM, a smart card memory such as a tamper-resistant module in the form of a subscriber identity module (SIM) such as a universal SIM (USIM) and / or a universal integrated circuit card (UICC) containing one or more SIMs such as an Internet Protocol Multimedia Services Identity Module (ISIM), other memory, or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC, commonly known as a "SIM card." The memory 1510 may enable the UE 1500 to access, offload, or upload data, instructions, application programs, etc. stored on a temporary or non-transitory memory medium. An article of manufacture, such as an article of manufacture utilizing a communication system, may be tangibly embodied as or in the memory 1510, which may be or comprise a device-readable storage medium.

[0128] The processing circuit 1502 may be configured to communicate with an access network or other networks using a communication interface 1512. The communication interface 1512 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1522. The communication interface 1512 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or network node in the access network). Each transceiver may include a transmitter 1518 and / or a receiver 1520 suitable for providing network communication (e.g., optical, electrical, frequency allocation, etc.). Moreover, the transmitter 1518 and receiver 1520 may be coupled to one or more antennas (e.g., antenna 1522) and may share circuit components, software, or firmware or, alternatively, be implemented separately.

[0129] In the illustrated embodiment, the communication capabilities of communication interface 1512 may include cellular communication, WiFi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, NFC, location-based communication such as using a Global Positioning System (GPS) to determine location, another similar communication capability, or any combination thereof. Communications may be implemented in accordance with one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), GSM, LTE, NR, UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Networking (SONET), Asynchronous Transfer Mode (ATM), Quick User Datagram Protocol Internet Connection (QUIC), Hypertext Transfer Protocol (HTTP), etc.

[0130] Regardless of the type of sensor, the UE may provide an output of data captured by the UE's sensors to a network node through the UE's communications interface 1512 or via a wireless connection. Data captured by the UE's sensors may be communicated to a network node via another UE through a wireless connection. The output may be periodic (e.g., once every 15 minutes if the output reports a detected temperature), random (e.g., to even out the load from reports from several sensors), responsive to a triggering event (e.g., when moisture is detected and an alert is sent), responsive to a request (e.g., a user-initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0131] As another example, the UE may include an actuator, motor, or switch associated with a communications interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input, the actuator, motor, or switch may change state. For example, the UE may include a motor that adjusts a control surface or rotor of a drone in flight according to the received input, or adjusts a control surface or rotor of a robotic arm performing a medical procedure according to the received input.

[0132] The UE, when in the form of an IoT device, may be a device for use in one or more application areas, including, but not limited to, urban wearable technology, augmented industrial applications, and healthcare. Non-limiting examples of such IoT devices are devices that are or are embedded in a connected refrigerator or freezer, a television, a connected lighting device, an energy meter, a robotic vacuum cleaner, a voice-controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a water inundation / humidity sensor, an electronic door lock, a connected doorbell, an air conditioning system such as a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for augmented reality (AR) or VR, a wearable for haptic augmentation or sensory augmentation, a water sprinkler, an animal or product tracking device, a sensor for monitoring plants or animals, an industrial robot, an unmanned aerial vehicle (UAV), and any type of medical device such as a heart rate monitor or a remote-controlled surgical robot. A UE in the form of an IoT device comprises circuitry and / or software depending on the intended application of the IoT device, in addition to other components such as those described in relation to UE 1500 shown in FIG. 15.

[0133] As yet another particular example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements and transmits results of such monitoring and / or measurements to another UE and / or network node. The UE may in this case be an M2M device, which may be referred to as an MTC device in a 3GPP context. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, bus, truck, ship, airplane, or other equipment capable of monitoring and / or reporting on its operating status or other functionality associated with its operation.

[0134] In practice, any number of UEs may be used together for a single use case. For example, a first UE may be a drone or be integrated in a drone and provide the drone's speed information (obtained through a speed sensor) to a second UE that is a remote controller that operates the drone. When a user makes changes from the remote controller, the first UE may adjust a throttle on the drone (e.g., by controlling an actuator) to increase or decrease the drone's speed. The first and / or second UE may also include two or more of the functions described above. For example, a UE may include a sensor and an actuator and handle communication of data for both the speed sensor and the actuator.

[0135] 16 illustrates a network node 1600 according to some embodiments. As used herein, a network node refers to a device capable of, set up, configured, and / or operable to communicate, directly or indirectly, with UEs and / or other network nodes or devices in a communication network. Examples of network nodes include, but are not limited to, APs (e.g., wireless APs), base stations (BSs) (e.g., wireless BSs, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)).

[0136] BSs may be categorized based on the amount of coverage they provide (or, stated another way, their transmit power level) and may therefore be referred to as femto BSs, pico BSs, micro BSs, or macro BSs depending on the amount of coverage provided. A BS may be a relay node or a relay donor node that controls a relay. A network node may also include one or more (or all) parts of a distributed wireless BS, such as a centralized digital unit and / or a remote radio unit (RRU), sometimes referred to as a remote radio head (RRH). Such RRUs may or may not be integrated with an antenna, such as an antenna-integrated radio. Portions of a distributed wireless BS may also be referred to as nodes in a distributed antenna system (DAS).

[0137] Other examples of network nodes include a multiple transmission point (multi-TRP) 5G access node, MSR equipment such as a multi-standard radio (MSR) BS, a network controller such as a radio network controller (RNC) or BS controller (BSC), a base transceiver station (BTS), a transmission point, a transmitting node, a multi-cell / multicast coordination entity (MCE), an operation and maintenance (O&M) node, an operation support system (OSS) node, a self-organizing network (SON) node, a positioning node (e.g., an evolved serving mobile location center (E-SMLC)), and / or a minimization of drive test (MDT).

[0138] The network node 1600 includes a processing circuit 1602, a memory 1604, a communication interface 1606, and a power source 1608. The network node 1600 may be composed of multiple physically separate components (e.g., a Node B component and an RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In some scenarios in which the network node 1600 comprises multiple separate components (e.g., a BTS component and a BSC component), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple Node Bs. In such scenarios, each unique Node B and RNC pair may, in some instances, be considered a single separate network node. In some embodiments, the network node 1600 may be configured to support multiple RATs. In such embodiments, some components may be duplicated (e.g., separate memory 1604 for different RATs) and some components may be reused (e.g., an antenna 1610 may be shared by different RATs). Network node 1600 may also include multiple sets of the various illustrated components for different wireless technologies, e.g., GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, Long Range Wide Area Network (LoRaWAN), Radio Frequency Identification (RFID), or Bluetooth wireless technologies, integrated into network node 1600. These wireless technologies may be integrated into the same or different chips or sets of chips and other components within network node 1600.

[0139] The processing circuit 1602 may comprise one or more combinations of a microprocessor, controller, microcontroller, CPU, DSP, ASIC, FPGA, or any other suitable computing device, resource, or combination of hardware, software, and / or coded logic operable to provide the network node 1600 functionality, either alone or in conjunction with other network node 1600 components such as memory 1604.

[0140] In some embodiments, the processing circuit 1602 comprises a system on a chip (SOC). In some embodiments, the processing circuit 1602 includes one or more of a radio frequency (RF) transceiver circuit 1612 and a baseband processing circuit 1614. In some embodiments, the RF transceiver circuit 1612 and the baseband processing circuit 1614 may be on separate chips (or sets of chips), boards, or units, such as a radio unit and a digital unit. In alternative embodiments, some or all of the RF transceiver circuit 1612 and the baseband processing circuit 1614 may be on the same chip or set of chips, board, or unit.

[0141] The memory 1604 may comprise any form of volatile or non-volatile computer-readable memory, including, but not limited to, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, RAM, ROM, mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, compact disc (CD) or digital video disc (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable, and / or computer-executable memory device that stores information, data, and / or instructions that may be used by the processing circuit 1602. The memory 1604 may store any suitable instructions, data, or information, including applications including one or more of computer programs, software, logic, rules, code, tables, and / or other instructions that can be executed by the processing circuit 1602 and utilized by the network node 1600. The memory 1604 may be used to store calculations performed by the processing circuit 1602 and / or data received via the communication interface 1606. In some embodiments, the processing circuit 1602 and the memory 1604 are integrated.

[0142] The communication interface 1606 is used in wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, the communication interface 1606 includes a port / terminal 1616 for sending and receiving data to and from a network, for example, over a wired connection. The communication interface 1606 also includes a radio front-end circuit 1618 that is coupled to an antenna 1610 or, in some embodiments, may be part of the antenna 1610. The radio front-end circuit 1618 includes a filter 1620 and an amplifier 1622. The radio front-end circuit 1618 may be connected to the antenna 1610 and the processing circuit 1602. The radio front-end circuit 1618 may be configured to condition signals communicated between the antenna 1610 and the processing circuit 1602. The radio front-end circuit 1618 may receive digital data to be sent to another network node or UE via a wireless connection. The radio front-end circuitry 1618 may convert the digital data into radio signals having appropriate channel and bandwidth parameters using a combination of filters 1620 and / or amplifiers 1622. The radio signals may then be transmitted via the antenna 1610. Similarly, when receiving data, the antenna 1610 may collect the radio signals, which are then converted into digital data by the radio front-end circuitry 1618. The digital data may be passed to the processing circuitry 1602. In other embodiments, the communication interface 1606 may comprise different components and / or different combinations of components.

[0143] In some alternative embodiments, the network node 1600 does not include a separate radio front-end circuit 1618; instead, the processing circuit 1602 includes the radio front-end circuitry and is connected to the antenna 1610. Similarly, in some embodiments, all or a portion of the RF transceiver circuitry 1612 is part of the communications interface 1606. In still other embodiments, the communications interface 1606 includes one or more ports or terminals 1616, the radio front-end circuitry 1618, and the RF transceiver circuitry 1612 as part of a radio unit (not shown), and the communications interface 1606 communicates with baseband processing circuitry 1614 that is part of a digital unit (not shown).

[0144] The antenna 1610 may include one or more antennas or an antenna array configured to transmit and / or receive wireless signals. The antenna 1610 may be coupled to the radio front-end circuitry 1618 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In some embodiments, the antenna 1610 is separate from the network node 1600 and may be connectable to the network node 1600 through an interface or port.

[0145] The antenna 1610, the communication interface 1606, and / or the processing circuit 1602 may be configured to perform any receiving operations and / or some obtaining operations described herein as being performed by the network node 1600. Any information, data, and / or signals may be received from a UE, another network node, and / or any other network equipment. Similarly, the antenna 1610, the communication interface 1606, and / or the processing circuit 1602 may be configured to perform any transmitting operations described herein as being performed by the network node 1600. Any information, data, and / or signals may be transmitted to a UE, another network node, and / or any other network equipment.

[0146] The power supply 1608 provides power to the various components of the network node 1600 in a form suitable for each component (e.g., at the voltage and current levels required for each respective component). The power supply 1608 may further comprise, or be coupled to, power management circuitry for supplying power to the components of the network node 1600 for performing the functions described herein. For example, the network node 1600 may be connectable to an external power source (e.g., a power grid or an electrical outlet) via an input circuit or interface, such as an electrical cable, whereby the external power source supplies power to the power circuitry of the power supply 1608. As a further example, the power supply 1608 may comprise a power source in the form of a battery or battery pack connected to or integrated in the power circuitry. The battery may provide backup power in the event that the external power source fails.

[0147] 16 to provide certain aspects of the network node's functionality, including any of the functionality described herein and / or functionality necessary to support the subject matter described herein. For example, network node 1600 may include user interface devices to enable input of information into network node 1600 and output of information from network node 1600. This may enable a user to perform diagnostic, maintenance, repair, and other administrative functions for network node 1600.

[0148] 17 is a block diagram of a host 1700, which may be an embodiment of the host 1416 of FIG. 14, in accordance with various aspects described herein. As used herein, the host 1700 may be or comprise various combinations of hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, a container, or processing resources in a server farm. The host 1700 may provide one or more services to one or more UEs.

[0149] The host 1700 includes a processing circuit 1702 operably coupled to an input / output interface 1706, a network interface 1708, a power supply 1710, and a memory 1712 via a bus 1704. In other embodiments, other components may be included. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as FIGS. 15 and 16, and therefore, those descriptions are generally applicable to the corresponding components of the host 1700.

[0150] The memory 1712 may include one or more computer programs, including one or more host application programs 1714 and data 1716, which may include user data, e.g., data generated by a UE for the host 1700 or data generated by the host 1700 for the UE. An embodiment of the host 1700 may utilize only a subset or all of the shown components. The host application programs 1714 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), Moving Picture Experts Group (MPEG), VP9) and audio codecs (e.g., Free Lossless Audio Codec (FLAC), Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UE (e.g., handsets, desktop computers, wearable display systems, and heads-up display systems). The host application program 1714 may also provide user authentication and license checks, and may periodically report health, route, and content availability to a central node, such as a device in the core network or a device on the edge of the core network. Thus, the host 1700 may select and / or point to a different host for over-the-top (OTT) services for the UE. The host application program 1714 may support various protocols, such as HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (DASH or MPEG-DASH), etc.

[0151] FIG. 18 is a block diagram illustrating a virtualization environment 1800 in which functionality implemented by some embodiments may be virtualized. In this context, virtualizing means creating a virtual version of an apparatus or device, which may include virtualizing a hardware platform, storage devices, and networking resources. Virtualization, as used herein, may apply to any device described herein, or components thereof, and relates to implementations in which at least a portion of functionality is implemented as one or more virtual components. Some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1800 hosted by one or more of the hardware nodes, such as a network node, a UE, a core network node, or a hardware computing device acting as a host. Furthermore, in embodiments in which the virtual node does not require wireless connectivity (e.g., to a core network node or host), the node may be fully virtualized.

[0152] An application 1802 (which may alternatively be referred to as a software instance, a virtual appliance, a network function, a virtual node, a virtual network function, etc.) is run in the virtualized environment 1700 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0153] Hardware 1804 includes processing circuitry, memory that stores software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices described herein, such as network interfaces, input / output interfaces, etc. Software is executed by the processing circuitry to instantiate one or more virtualization layers 1806 (also referred to as hypervisors or VM monitors (VMMs)), provide VMs 1808A and 1808B (one or more of which may be referred to generically as VMs 1808), and / or implement any of the functions, features, and / or benefits described with respect to some embodiments described herein. Virtualization layer 1806 may present to VMs 1808 a virtual operating platform that appears to be networking hardware.

[0154] The VMs 1808 may comprise virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be run by a corresponding virtualization layer 1806. Different embodiments of instances of virtual appliances 1802 may be implemented on one or more of the VMs 1808, and the implementations may be done in different ways. Hardware virtualization is referred to in some contexts as network functions virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry-standard high-volume server hardware, physical switches, and physical storage, which may be deployed in data centers and customer premises equipment.

[0155] In the context of NFV, a VM 1808 may be a software implementation of a physical machine that runs programs as if they were running on a physical, non-virtual machine. Each VM 1808 and the portion of the hardware 1804 on which it runs, whether the hardware is dedicated to that VM and / or shared by that VM with other VMs in the VMs 1808, form a separate virtual network element. Further in the context of NFV, a virtual network function is responsible for handling a particular network function running in one or more VMs 1808 on the hardware 1804 and corresponds to the application 1802.

[0156] The hardware 1804 may be implemented in a standalone network node with general or specific components. The hardware 1804 may implement some functions via virtualization. Alternatively, the hardware 1804 may be part of a larger cluster of hardware (e.g., in a data center or CPE) where many hardware nodes cooperate and are managed via a management and orchestration 1810 that, among other things, oversees the lifecycle management of the application 1802. In some embodiments, the hardware 1804 is coupled to one or more radio units, each including one or more transmitters and one or more receivers, which may be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with virtual components to provide a virtual node with wireless capabilities, such as a RAN or BS. In some embodiments, some signaling may be provided using a control system 1812, which may alternatively be used for communication between the hardware nodes and the radio units.

[0157] 19 shows a communication diagram of a host 1902 communicating with a UE 1906 via a network node 1904 over a partial wireless connection, according to some embodiments. Exemplary implementations according to various embodiments of a UE (such as the UE 1412A of FIG. 14 and / or the UE 1500 of FIG. 15), a network node (such as the network node 1410A of FIG. 14 and / or the network node 1600 of FIG. 16), and a host (such as the host 1416 of FIG. 14 and / or the host 1700 of FIG. 17) discussed in the previous paragraph will now be described with reference to FIG. 19.

[0158] Similar to the host 1700, an embodiment of the host 1902 includes hardware such as a communications interface, processing circuitry, and memory. The host 1902 also includes software stored on or accessible by the host 1902 and executable by the processing circuitry. The software includes a host application that may be operable to provide services to a remote user, such as a UE 1906, connecting via an OTT connection 1950 extending between the UE 1906 and the host 1902. In providing services to the remote user, the host application may provide user data that is transmitted using the OTT connection 1950.

[0159] The network node 1904 includes hardware that enables the network node 1904 to communicate with the host 1902 and the UE 1906 over a connection 1960. The connection 1960 may be direct or may pass through one or more other intermediate networks, such as a core network (similar to the core network 1406 of FIG. 14 ) and / or one or more public, private, or hosted networks. For example, the intermediate network may be a backbone network or the Internet.

[0160] The UE 1906 includes hardware and software stored on or accessible by the UE 1906 and executable by the UE's processing circuitry. The software includes a client application, such as a web browser or operator-specific "app," which, with the support of the host 1902, may be operable to provide services to a human or non-human user via the UE 1906. An executing host application on the host 1902 may communicate with an executing client application via an OTT connection 1950 that terminates at the UE 1906 and the host 1902. In providing services to the user, the UE's client application may receive request data from the host application on the host and provide user data in response to the request data. The OTT connection 1950 may transfer both the request data and user data. The UE's client application may interact with the user to generate user data that the UE's client application provides to the host application through the OTT connection 1950.

[0161] The OTT connection 1950 may extend via a connection 1960 between the host 1902 and a network node 1904 and via a wireless connection 1970 between the network node 1904 and the UE 1906 to provide connectivity between the host 1902 and the UE 1906. The connections 1960 and wireless connections 1970 over which the OTT connection 1950 may be provided are depicted abstractly to illustrate communication between the host 1902 and the UE 1906 via the network node 1904, without explicit reference to intermediate devices and the precise routing of messages through these devices.

[0162] As an example of transmitting data over the OTT connection 1950, in step 1908, the host 1902 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 1906. In other embodiments, the user data is associated with the UE 1906 sharing data with the host 1902 without explicit human interaction. In step 1910, the host 1902 initiates a transmission carrying the user data toward the UE 1906. The host 1902 may initiate the transmission in response to a request sent by the UE 1906. The request may be caused by human interaction with the UE 1906 or by the operation of a client application executing on the UE 1906. The transmission may proceed via the network node 1904 in accordance with the teachings of the embodiments described throughout this disclosure. Thus, in step 1912, the network node 1904 transmits the user data carried in the transmission initiated by the host 1902 to the UE 1906, in accordance with the teachings of embodiments described throughout this disclosure. In step 1914, the UE 1906 receives the user data carried in the transmission, which may be performed by a client application executing on the UE 1906 associated with the host application executed by the host 1902.

[0163] In some examples, the UE 1906 executes a client application that provides user data to the host 1902. The user data may be provided in reaction or response to data received from the host 1902. Thus, in step 1916, the UE 1906 may provide the user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from a user via an input / output interface of the UE 1906. Regardless of the particular manner in which the user data is provided, the UE 1906 initiates transmission of the user data towards the host 1902 via the network node 1904 in step 1918. In step 1920, the network node 1904 receives the user data from the UE 1906 and initiates transmission of the received user data towards the host 1902, in accordance with the teachings of embodiments described throughout this disclosure. In step 1922, the host 1902 receives the user data carried in the transmission initiated by the UE 1906.

[0164] One or more of the various embodiments improve the performance of the OTT service provided to the UE 1906 using the OTT connection 1950, of which the wireless connection 1970 forms the final segment. More precisely, the teachings of these embodiments may improve, for example, data rates, latency, power consumption, etc., thereby providing benefits such as, for example, reduced user latency, relaxed restrictions on file sizes, improved content resolution, better responsiveness, extended battery life, etc.

[0165] In an exemplary scenario, factory status information may be collected and analyzed by the host 1902. As another example, the host 1902 may process audio and video data that may have been retrieved from UEs for use in creating maps. As another example, the host 1902 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic signals). As another example, the host 1902 may store surveillance video uploaded by UEs. As another example, the host 1902 may store or control access to media content, such as video, audio, VR, or AR, that the host 1902 may broadcast, multicast, or unicast to UEs. As other examples, the host 1902 may be used for energy pricing, remote control of non-time-critical electrical loads to balance power generation needs, location services, presentation services (such as compiling diagrams, etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing, and / or transmitting data.

[0166] In some examples, measurement procedures may be provided for the purpose of monitoring data rates, latency, and other factors that one or more embodiments improve upon. There may further be optional network functionality for reconfiguring the OTT connection 1950 between the host 1902 and the UE 1906 in response to fluctuations in the measurement results. The measurement procedures and / or the network functionality for reconfiguring the OTT connection 1950 may be implemented in software and hardware of the host 1902 and / or the UE 1906. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 1950 passes, and the sensors may participate in the measurement procedures by providing values ​​of the monitored quantities exemplified above, or by providing values ​​of other physical quantities from which software can calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 1950 may include message formats, retransmission settings, preferred routing, etc., and the reconfiguration need not directly change the operation of the network node 1904. Such procedures and functionality may be known and practiced in the art. In some embodiments, the measurements may involve proprietary UE signaling that facilitates measurements by the host 1902 of throughput, propagation time, latency, etc. The measurements may be implemented in software causing messages, particularly empty or "dummy" messages, to be sent using the OTT connection 1950 while monitoring propagation time, errors, etc.

[0167] While the computing devices (e.g., UEs, network nodes, hosts) described herein may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It should be understood that these computing devices may comprise any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determining, calculating, obtaining, or similar operations described herein may be performed by processing circuitry, which may process information by, for example, transforming the obtained information to other information, comparing the obtained or transformed information to information stored in a network node, and / or performing one or more operations based on the obtained or transformed information and as a result of the processing making a decision. Moreover, while components are depicted as a single box disposed within a larger box or nested within multiple boxes, in reality the computing device may comprise multiple different physical components that make up the single illustrated component, and functionality may be partitioned among the separate components. For example, a communications interface may be configured to include any of the components described herein, and / or the functionality of those components may be partitioned between the processing circuitry and the communications interface. In another example, non-computationally intensive functionality of any of such components may be implemented in software or firmware, and computationally intensive functionality may be implemented in hardware.

[0168] In some embodiments, some or all of the functionality described herein may be provided by a processing circuit executing instructions stored in a memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuit without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hardwired manner. In any of these particular embodiments, the processing circuit may be configured to perform the described functionality, regardless of whether or not it executes instructions stored on a non-transitory computer-readable storage medium. Benefits provided by such functionality are not limited to the processing circuit alone or to other components of the computing device, but are enjoyed by the computing device as a whole and / or by end users and wireless networks generally.

[0169] Embodiment

[0170] Group A Embodiments

[0023] Embodiment 1: A method implemented by a user equipment (UE) for time domain channel characteristic (TDCP) reporting based on measurements of tracking reference signal (TRS) samples, the method comprising: a. receiving from a network a reporting configuration including a TDCP reporting amount to be reported by the UE for TDCP reporting (1300); b. receiving from the network a reference signal configuration including one or more TRS samples (1302); c. receiving from the network signaling indicating one or more measurement windows (1304A); d. receiving from the network signaling limiting the number of TRS samples to be considered when calculating / updating the TDCP reporting amount (1304B); and e. calculating / updating the indicated one or more TRS samples. a method comprising one or more of: calculating and / or updating a TDCP reporting quantity to be reported using only TRS samples in a plurality of measurement windows (1306A); f. calculating and / or updating a TDCP reporting quantity to be reported using only an indicated number of TRS samples (1306B); g. receiving a DCI from the network that triggers aperiodic TDCP reporting (1308); h. reporting the TDCP reporting quantity calculated / updated during one or more measurement windows as part of the aperiodic TDCP reporting (1310A); and i. reporting the TDCP reporting quantity calculated / updated using only the indicated number of TRS samples as part of the aperiodic TDCP reporting (1310B).

[0171] Embodiment 2: TDCP reporting is performed using different types of autocorrelation-based reporting, Doppler spread f d , a moving average of the last N1 samples, a weighted average of the last N1 samples, and the like.

[0172] Embodiment 3. The method according to any one of the preceding embodiments, wherein N1 is equal to 3, 1, indicated by the UE capability or indicated by a network configuration parameter.

[0173] Embodiment 4: The method according to any one of the previous embodiments, wherein the network configuration of N1 is indicated by a parameter called timeRestorationForTDCPMeasurements in the RRC message.

[0174] Embodiment 5: The method according to any one of the preceding embodiments, wherein N1 is regarded as 1 if timeRestrcitionForTDCPMeasurements is set.

[0175] Embodiment 6: The method according to any one of the preceding embodiments, wherein N1 is configured by an RRC message.

[0176] Embodiment 7: The method of any one of the previous embodiments, wherein the signaling includes one or more of a periodic measurement window, an aperiodically triggered measurement window, and a semi-persistently activated TRS window.

[0177] Embodiment 8: The method of any one of the previous embodiments, further comprising deciding to discard some of the measurements or measurement occasions within the measurement window.

[0178] Embodiment 9: The method of any one of the preceding embodiments, further comprising determining a number of CPUs to be dedicated for measurements and calculations related to TDCP reporting.

[0179] Embodiment 10: The method of any one of the previous embodiments, wherein the measurement window includes a TRS measurement time setting (TRS-MTC) being set, and wherein the UE is only required to calculate / update the TDCP amount using TRS samples and / or TRS bursts within the set measurement time.

[0180] Embodiment 11: The method of any one of the previous embodiments, wherein the TDCP amount is calculated or updated only during each periodic TRS measurement window, and the calculated / updated TDCP amount is valid until the next TRS measurement window.

[0181] Embodiment 12: The method of any one of the previous embodiments, wherein each TRS measurement window has a duration or length T2.

[0182] Embodiment 13: The method according to any one of the preceding embodiments, wherein the duration or length T2 is configured via a higher layer parameter (e.g., an RRC parameter).

[0183] Embodiment 14: The method of any one of the previous embodiments, wherein the length of the TRS measurement window and / or the size of the time lag over which the autocorrelation may be calculated within the TRS measurement window is part of the UE capabilities.

[0184] Embodiment 15: The method of any one of the previous embodiments, wherein specific capabilities regarding the length of the TRS measurement window and / or the size of the time lag over which autocorrelation can be calculated for a given UE are reported to the network as part of the UE capabilities.

[0185] Embodiment 16: The method according to any one of the preceding embodiments, wherein the TRS measurement window can be configured as part of the CSI-ReportConfig IE.

[0186] Embodiment 17: The method according to any one of the preceding embodiments, wherein the DCI that triggers the aperiodic triggered TRS measurement window is different from the DCI that triggers the aperiodic TDCP report.

[0187] Embodiment 18: The method according to any one of the preceding embodiments, wherein the DCI that triggers the aperiodically triggered TRS measurement window is the same as the DCI that triggers the aperiodic TDCP report.

[0188] Embodiment 19: The method of any one of the previous embodiments, wherein the CPU occupation duration for TDCP reporting is determined with respect to a TRS measurement window.

[0189] Embodiment 20: The method according to any one of the previous embodiments, wherein additional time is added to the last symbol of the TRS in the TRS measurement window for CPU occupancy.

[0190] Embodiment 21: The method of any one of the previous embodiments, wherein the last OFDM or downlink OFDM symbol in the window is used to determine the CPU occupancy duration.

[0191] Embodiment 22: The method according to any one of the previous embodiments, wherein the CPU assumed for measurements and / or calculations related to the TDCP reporting quantity is assumed for the entire duration of the TRS measurement window.

[0192] Embodiment 23: The method according to any one of the previous embodiments, wherein if there is no available CPU for the TRS measurement window, the TDCP reporting amount does not need to be calculated / updated.

[0193] Embodiment 24: The method according to any one of the preceding embodiments, wherein if the UE is configured with DRX and the active measurement window for TDCP reporting is outside the DRX active time, the TDCP amount does not need to be updated.

[0194] Embodiment 25: The method of any one of the previous embodiments, wherein the UE abandons some of the measurements or measurement occasions within the measurement window due to one or more of the following reasons: a. a phase jump occurred for the UE that invalidated the measurement or measurement occasion; b. the UE performed an RX frequency adjustment that invalidated the measurement or measurement occasion; and c. the UE processing capacity became overloaded and other processes were given priority.

[0195]

[0081] Embodiment 26: The method according to any one of the preceding embodiments, wherein the UE includes in the measurement report information about which measurements / measurement occasions have been abandoned.

[0196]

[0081] Embodiment 27: The method according to any one of the preceding embodiments, wherein the UE includes in the measurement report information about which measurement / measurement occasion was used.

[0197] Embodiment 28: The method of any one of the previous embodiments, wherein the TDCP measure is an autocorrelation measure or some quantity calculated based on autocorrelation measures for one or more autocorrelation lags. Embodiment 29: Autocorrelation measures are measured over time and frequency. TIFF2025533520000025.tif5170 The method of any one of the preceding embodiments, wherein the averaging is defined by:

[0198] Embodiment 30: The UE determines the following quantities: TIFF2025533520000026.tif9170For example, the normalized autocorrelation function, TIFF2025533520000027.tif9170For example, the absolute value of the normalized autocorrelation function, and TIFF2025533520000028.tif9170A method according to any one of the preceding embodiments, wherein the method reports one or more measures of, for example, the sign of the real part of the autocorrelation times the absolute value of the normalized autocorrelation function.

[0199]

[0033] Embodiment 31: The method of any one of the preceding embodiments, further comprising providing user data and forwarding the user data to the host via transmission to the network node.

[0200] Group B Embodiments

[0037] Embodiment 32: A method implemented by a network node for receiving a time domain channel characteristic (TDCP) report based on measurements of tracking reference signal (TRS) samples, comprising: a. transmitting to a user equipment (UE) a reporting configuration including a TDCP reporting amount to be reported by the UE for TDCP reporting (1300); b. transmitting to the UE a reference signal configuration including one or more TRS samples (1302); c. transmitting to the UE signaling indicating one or more measurement windows (1304A); and d. transmitting to the UE a TDCP report based on measurements of tracking reference signal (TRS) samples. a. transmitting to the UE signaling (1304B) limiting the number of TRS samples to be considered when calculating / updating a reporting quantity; b. transmitting to the UE a DCI (1308) that triggers aperiodic TDCP reporting; c. receiving as part of the aperiodic TDCP reporting a TDCP reporting quantity calculated / updated during one or more measurement windows (1310A); and d. receiving as part of the aperiodic TDCP reporting a TDCP reporting quantity calculated / updated using only an indicated number of TRS samples (1310B).

[0201] Embodiment 33: TDCP reporting is performed using different types of autocorrelation-based reporting, Doppler spread f d , a moving average of the last N1 samples, a weighted average of the last N1 samples, and the like.

[0202] Embodiment 34: The method according to any one of the preceding embodiments, wherein N1 is equal to 3, 1, indicated by the UE capability or indicated by a network configuration parameter.

[0203] Embodiment 35: The method according to any one of the previous embodiments, wherein the network configuration of N1 is indicated by a parameter called timeRestorationForTDCPMeasurements in the RRC message.

[0204] Embodiment 36: The method according to any one of the preceding embodiments, wherein N1 is considered to be 1 if timeRestrcitionForTDCPMeasurements is set.

[0205]

[0081] Embodiment 37: The method according to any one of the preceding embodiments, wherein N1 is configured by an RRC message.

[0206] Embodiment 38: The method of any one of the previous embodiments, wherein the signaling includes one or more of a periodic measurement window, an aperiodically triggered measurement window, and a semi-persistently activated TRS window.

[0207] Embodiment 39: The method of any one of the previous embodiments, wherein the measurement window includes a TRS measurement time setting (TRS-MTC) being set, and wherein the UE is only required to calculate / update the TDCP amount using TRS samples and / or TRS bursts within the set measurement time.

[0208] Embodiment 40: The method of any one of the previous embodiments, wherein the TDCP amount is calculated or updated only during each periodic TRS measurement window, and the calculated / updated TDCP amount is valid until the next TRS measurement window.

[0209] Embodiment 41: The method of any one of the previous embodiments, wherein each TRS measurement window has a duration or length T2.

[0210] Embodiment 42: The method according to any one of the preceding embodiments, wherein the duration or length T2 is configured via a higher layer parameter (e.g., an RRC parameter).

[0211] Embodiment 43: The method of any one of the previous embodiments, wherein the length of the TRS measurement window and / or the size of the time lag over which the autocorrelation may be calculated within the TRS measurement window is part of the UE capabilities.

[0212] Embodiment 44: The method of any one of the previous embodiments, wherein specific capabilities regarding the length of the TRS measurement window and / or the size of the time lag over which autocorrelation can be calculated for a given UE are reported to the network as part of the UE capabilities.

[0213] Embodiment 45: The method according to any one of the preceding embodiments, wherein the TRS measurement window can be configured as part of the CSI-ReportConfig IE.

[0214] Embodiment 46: The method according to any one of the preceding embodiments, wherein the DCI that triggers the aperiodic triggered TRS measurement window is different from the DCI that triggers the aperiodic TDCP report.

[0215] Embodiment 47: The method according to any one of the preceding embodiments, wherein the DCI that triggers the aperiodically triggered TRS measurement window is the same as the DCI that triggers the aperiodic TDCP report.

[0216] Embodiment 48: The method of any one of the previous embodiments, wherein the CPU occupation duration for TDCP reporting is determined with respect to a TRS measurement window.

[0217] Embodiment 49: The method of any one of the previous embodiments, wherein additional time is added to the last symbol of the TRS in the TRS measurement window for CPU occupancy.

[0218] Embodiment 50: The method of any one of the preceding embodiments, wherein the last OFDM or downlink OFDM symbol in the window is used to determine the CPU occupancy duration.

[0219] Embodiment 51: The method according to any one of the previous embodiments, wherein the CPU assumed for measurements and / or calculations related to the TDCP reporting quantity is assumed for the entire duration of the TRS measurement window.

[0220] Embodiment 52: The method according to any one of the previous embodiments, wherein if there is no available CPU for the TRS measurement window, the TDCP reporting amount does not need to be calculated / updated.

[0221] Embodiment 53: The method according to any one of the preceding embodiments, wherein if the UE is configured with DRX and the active measurement window for TDCP reporting is outside the DRX active time, the TDCP amount does not need to be updated.

[0222]

[0081] Embodiment 54: The method according to any one of the preceding embodiments, wherein the UE includes in the measurement report information about which measurements / measurement occasions have been abandoned.

[0223]

[0081] Embodiment 55: The method of any one of the preceding embodiments, wherein the UE includes information in the measurement report about which measurement / measurement occasion was used.

[0224] Embodiment 56: The method of any one of the previous embodiments, wherein the TDCP measure is an autocorrelation measure or some quantity calculated based on autocorrelation measures for one or more autocorrelation lags.

[0225] Embodiment 57: An autocorrelation measure is calculated over time and frequency. TIFF2025533520000029.tif5170 The method of any one of the preceding embodiments, wherein the averaging is defined by:

[0226] Embodiment 58: The UE determines the following quantities: TIFF2025533520000030.tif9170For example, the normalized autocorrelation function, TIFF2025533520000031.tif9170For example, the absolute value of the normalized autocorrelation function, and TIFF2025533520000032.tif9170A method according to any one of the preceding embodiments, for example reporting one or more measures of the sign of the real part of the autocorrelation times the absolute value of the normalized autocorrelation function.

[0227] Embodiment 59: The method of any one of the preceding embodiments, further comprising obtaining user data and forwarding the user data to a host or user equipment.

[0228] Group C Embodiments Embodiment 60: A user equipment for time domain channel characteristic (TDCP) reporting based on measurement of tracking reference signal (TRS) samples, comprising a processing circuit configured to perform any of the steps described in any one of the embodiments of Group A, and a power supply circuit configured to supply power to the processing circuit.

[0229] Embodiment 61: A network node for receiving a time domain channel characteristic (TDCP) report based on measurements of tracking reference signal (TRS) samples, the network node comprising: a processing circuit configured to perform any of the steps described in any one of the embodiments of Group B; and a power supply circuit configured to supply power to the processing circuit.

[0230] Embodiment 62: A user equipment (UE) for time domain channel characteristic (TDCP) reporting based on measurements of tracking reference signal (TRS) samples, comprising: an antenna configured to send and receive radio signals; a radio front-end circuit connected to the antenna and to a processing circuit and configured to condition signals communicated between the antenna and the processing circuit; a processing circuit configured to perform any of the steps described in any one of the Group A embodiments; an input interface connected to the processing circuit and configured to enable information input to the UE to be processed by the processing circuit; an output interface connected to the processing circuit and configured to output information processed by the processing circuit from the UE; and a battery connected to the processing circuit and configured to provide power to the UE.

[0231] Embodiment 63: A host configured to operate in a communication system for providing over-the-top (OTT) services, the host comprising: processing circuitry configured to provide user data; and a network interface configured to initiate transmission of the user data to a cellular network for transmission to a user equipment (UE), wherein the UE comprises a communication interface and processing circuitry, and the communication interface and processing circuitry of the UE are configured to perform any of the steps described in any one of the embodiments of Group A to receive the user data from the host.

[0232] Embodiment 64: The host according to the previous embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit user data from the host to the UE.

[0233] Embodiment 65: A host as described in the previous two embodiments, wherein the processing circuitry of the host is configured to execute a host application to thereby provide user data, and the host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.

[0234] Embodiment 66: A method implemented by a host operating in a communication system further including a network node and a user equipment (UE), the method comprising: providing user data for the UE; and initiating a transmission carrying the user data to the UE via a cellular network comprising the network node, wherein the UE performs any of the operations described in any one of the embodiments of Group A to receive the user data from the host.

[0235] Embodiment 67: The method of the previous embodiment, further comprising: executing, at the host, a host application associated with the client application executing on the UE to receive user data from the UE.

[0236] Embodiment 68: The method of the previous embodiment, further comprising: at the host, sending input data to a client application executing on the UE, the input data being provided by executing the host application, wherein the user data is provided by the client application in response to the input data from the host application.

[0237] Embodiment 69: A host configured to operate in a communication system for providing over-the-top (OTT) services, the host comprising: processing circuitry configured to provide user data; and a network interface configured to initiate transmission of the user data to a cellular network for transmission to a user equipment (UE), wherein the UE comprises a communication interface and processing circuitry, and the communication interface and processing circuitry of the UE are configured to perform any of the steps described in any one of the embodiments of Group A to transmit the user data to the host.

[0238] Embodiment 70: The host according to the previous embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit user data from the UE to the host.

[0239] Embodiment 71: A host as described in the previous two embodiments, wherein the processing circuitry of the host is configured to execute a host application to thereby provide user data, and the host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.

[0240] Embodiment 72: A method implemented by a host configured to operate in a communication system further including a network node and user equipment (UE), the method including receiving, at the host, user data transmitted by the UE to the host via the network node, wherein the UE performs any of the steps described in any one of the embodiments of Group A to transmit the user data to the host.

[0241] Embodiment 73: The method of the previous embodiment, further comprising: executing, at the host, a host application associated with the client application executing on the UE to receive user data from the UE.

[0242] Embodiment 74: The method of the previous embodiment, further comprising: at the host, sending input data to a client application executing on the UE, the input data being provided by executing the host application, wherein the user data is provided by the client application in response to the input data from the host application.

[0243] Embodiment 75: A host configured to operate in a communications system for providing over-the-top (OTT) services, the host comprising processing circuitry configured to provide user data and a network interface configured to initiate transmission of the user data to a network node in a cellular network for transmission to a user equipment (UE), the network node having a communications interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations described in any one of the embodiments of Group B to transmit the user data from the host to the UE.

[0244] Embodiment 76: The host according to the previous embodiment, wherein the processing circuitry of the host is configured to execute a host application that provides user data, and the UE comprises processing circuitry configured to execute a client application associated with the host application to receive transmissions of the user data from the host.

[0245] Embodiment 77: A method implemented in a host configured to operate in a communication system further including a network node and user equipment (UE), the method comprising: providing user data for the UE; and initiating a transmission carrying the user data to the UE via a cellular network comprising the network node, wherein the network node performs any of the operations described in any one of the embodiments of Group B to transmit the user data from the host to the UE.

[0246] Embodiment 78: The method according to the previous embodiment, further comprising: transmitting, at the network node, user data provided by the host for the UE.

[0247] Embodiment 79: The method according to the previous two embodiments, wherein the user data is provided by executing a host application in the host that interacts with a client application running on the UE, and the client application is associated with the host application.

[0248] Embodiment 80: A communications system configured to provide over-the-top services, the communications system comprising a host, the host comprising processing circuitry configured to provide user data for a user equipment (UE), the user data being associated with the over-the-top service, and a network interface configured to initiate transmission of the user data to a cellular network node for transmission to the UE, the network node having a communications interface and processing circuitry, the network interface configured to perform any of the operations described in any one of the embodiments of Group B to transmit the user data from the host to the UE.

[0249] Embodiment 81: The communication system according to the previous embodiment, further comprising a network node and / or a user equipment.

[0250] Embodiment 82: A host configured to operate in a communication system for providing over-the-top (OTT) services, the host comprising: processing circuitry configured to initiate reception of user data; and a network interface configured to receive user data from a network node in a cellular network, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations described in any one of the embodiments of Group B to receive user data from a user equipment (UE) for the host.

[0251] Embodiment 83: A host as described in the previous two embodiments, wherein the processing circuitry of the host is configured to execute a host application to thereby provide user data, and the host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.

[0252] Embodiment 84: The host of any one of the previous two embodiments, wherein initiating the reception of user data includes requesting the user data.

[0253] Embodiment 85: A method implemented by a host configured to operate in a communication system further including a network node and user equipment (UE), the method including initiating, at the host, reception of user data from the UE, the user data originating from a transmission received by the network node from the UE, wherein the network node performs any of the steps described in any one of the embodiments of Group B to receive the user data from the UE for the host.

[0254] Embodiment 86: The method according to the previous embodiment, further comprising, at the network node, transmitting the received user data to the host.

[0255] At least some of the following abbreviations may be used in this disclosure. In the event of a conflict between abbreviations, the abbreviation as used above should prevail. If listed multiple times below, the first listing should prevail over subsequent listings. ● 3GPP 3rd Generation Partnership Project ● 5G (fifth generation) ● 5GC 5th generation core ● 5GS 5th generation system ● AF application function AMF access and mobility features ● AN Access Network ● AP Access point ● ASIC Application Specific Integrated Circuit ● AUSF authentication server function ● CPU channel status information processing unit ● DCI Downlink Control Information ● DN Data Network ● DRX Intermittent reception ● DSP Digital Signal Processor ● eNB Enhanced or Evolved Node B ● EPS Evolved Packet System ● E-UTRA Evolved Universal Terrestrial Radio Access ● FPGA Field Programmable Gate Array ● gNB New wireless base station ● gNB-DU New Wireless Base Station Distributed Unit ● HSS Home Subscriber Server ● IoT Internet of Things ● IP Internet Protocol ● LTE Long Term Evolution ● MME Mobility Management Entity ● MTC Machine Type Communication ● NEF network publishing function ● NF network function ● NR new radio ● NRF Network Function Repository Function ● NSSF network slice selection function ● OFDM Orthogonal Frequency Division Multiplexing ● OTT (Over-the-Top) ● PC Personal Computer ● PCF policy control function ● P-GW Packet Data Network Gateway ● QoS Quality of Service ● RAM Random Access Memory ● RAN Radio Access Network ● ROM Read-Only Memory ● RRC Radio Resource Control ● RRH Remote Radio Head ● RTT Round Trip Time ● SCEF Service Capability Publication Function ● SMF session management function ● TDCP time domain channel characteristics ● TRS Tracking Reference Signal ● TRS-MTC TRS measurement time setting ● UDM Integrated Data Management ● UE User Equipment ● UPF user plane function

[0256] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure, and all such improvements and modifications are considered to be within the scope of the concepts disclosed herein.

Claims

1. 1. A method implemented by a user equipment (UE) for time domain channel characteristic (TDCP) reporting based on measurements of tracking reference signal (TRS) samples, comprising: receiving 1300 a reporting configuration from a network, the reporting configuration including a TDCP reporting amount to be reported by the UE for TDCP reporting; receiving 1302 a reference signal configuration from the network, the reference signal configuration including one or more TRS samples; receiving signaling from the network (1304A / 1304B), wherein the signaling includes: Pointing to one or more measurement windows; Limiting the number of TRS samples to be considered when calculating / updating TDCP reporting quantities; receiving (1304A / 1304B) signaling including one or more of: the TRS samples in the indicated measurement window or windows; the indicated number of TRS samples; Calculating and / or updating (1306A / 1306B) the TDCP reporting quantity to be reported using only one or more of receiving 1308 downlink control information (DCI) from the network that triggers aperiodic TDCP reporting; Reporting the calculated / updated TDCP reporting quantity (1310A / 1310A); A method comprising:

2. The TDCP reports include different types of autocorrelation-based reports, Doppler spread f ｄ , the last N １ the moving average of the last N samples １ The method of claim 1 , wherein the weighted average of the samples is one or more of:

3. N １ 3. The method of claim 1, wherein r is equal to one of 3, 1 indicated by the UE capability and indicated by the network configuration parameter.

4. N １ The method according to any one of claims 1 to 3, wherein the network configuration is indicated by a parameter called timeRestrictionForTDCPMeasurements in a Radio Resource Control (RRC) message.

5. If timeRestrictionForTDCPMeasurements is set, N １ The method according to claim 1 , wherein is considered to be 1.

6. N １ The method according to claim 1 , wherein the UE_ID is set by an RRC message.

7. 7. The method of claim 1, wherein the signaling includes one or more of a periodic measurement window, an aperiodically triggered measurement window, and a semi-persistently activated TRS window.

8. The method of claim 1 , further comprising deciding to discard some of the measurements or measurement occasions within the measurement window.

9. The method of claim 1 , further comprising determining a number of channel state information processing units (CPUs) to be occupied for measurements and calculations related to TDCP reporting.

10. 10. The method of claim 1, wherein the measurement window comprises a TRS measurement time configuration (TRS-MTC) configured, wherein the UE is only required to calculate / update the TDCP quantity using the TRS samples and / or TRS bursts within the configured measurement time.

11. 11. The method of claim 1, wherein the TDCP amount is calculated or updated only during each periodic TRS measurement window, and the calculated / updated TDCP amount is valid until the next TRS measurement window.

12. Each TRS measurement window has a duration or length T ２ 12. The method of claim 1, wherein

13. Duration or length T ２ 13. The method according to claim 1, wherein is set via higher layer parameters.

14. 14. The method of claim 1, wherein the length of a TRS measurement window and / or the size of the time lag within which autocorrelation can be calculated within the TRS measurement window is part of the UE capabilities.

15. 15. The method of claim 1, wherein specific capabilities regarding the length of a TRS measurement window and / or the size of the time lag over which autocorrelation can be calculated for a given UE are reported to the network as part of UE capabilities.

16. The method of any one of claims 1 to 15, wherein the TRS measurement window can be configured as part of a CSI-ReportConfig information element (IE).

17. 17. The method of claim 1, wherein the DCI that triggers the aperiodic triggered TRS measurement window is different from the DCI that triggers the aperiodic TDCP reporting.

18. 18. The method of claim 1, wherein the DCI that triggers the aperiodically triggered TRS measurement window is the same as the DCI that triggers the aperiodic TDCP reporting.

19. 19. The method of claim 1, wherein the CPU occupancy duration for TDCP reporting is determined with respect to a TRS measurement window.

20. 20. The method of any one of claims 1 to 19, wherein additional time is added to the last symbol of the TRS within the TRS measurement window for CPU occupancy.

21. 21. The method of claim 1, wherein the last orthogonal frequency division multiplexing (OFDM) or downlink OFDM symbol in the window is used to determine CPU occupancy duration.

22. 22. The method according to claim 1, wherein the CPU time taken for measurements and / or calculations relating to TDCP reporting quantities is taken for the entire duration of the TRS measurement window.

23. 23. The method of claim 1, wherein if there is no available CPU for a TRS measurement window, the TDCP reporting quantity does not need to be calculated / updated.

24. 24. The method of claim 1, wherein if the UE is configured for discontinuous reception (DRX) and the active measurement window for TDCP reporting is outside the DRX active time, the TDCP amount does not need to be updated.

25. The UE may be unable to receive the following information for the following reasons: a phase jump has occurred for the UE that invalidates the measurement or measurement occasion; the UE has performed an RX frequency adjustment that invalidates the measurement or measurement occasion; and The UE processing capacity was overloaded and other processes were given priority.

25. The method of claim 1, wherein some of the measurements or measurement occasions within a measurement window are discarded by one or more of:

26. 26. The method of any one of claims 1 to 25, wherein the UE includes in a measurement report information about which measurements / measurement occasions have been abandoned.

27. 27. The method of any one of claims 1 to 26, wherein the UE includes in a measurement report information about which measurements / measurement occasions were used.

28. 28. A method according to any one of claims 1 to 27, wherein the TDCP measure is an autocorrelation measure or any quantity calculated based on autocorrelation measures for one or more autocorrelation lags.

29. The autocorrelation measure is 29. The method of any one of claims 1 to 28, wherein the method is defined by averaging.

30. The UE determines the following quantities: For example, the normalized autocorrelation function, For example, the absolute value of the normalized autocorrelation function, and That is, the sign of the real part of the autocorrelation function times the absolute value of the normalized autocorrelation function, 30. The method of claim 1, wherein the method reports one or more measurements of:

31. 30. The method of claim 1, wherein the UE operates in a fifth generation (5G) system.

32. 1. A method implemented by a network node for receiving a time domain channel characteristic (TDCP) report based on measurements of tracking reference signal (TRS) samples, the method comprising: Sending 1300 a reporting configuration to a user equipment (UE) for TDCP reporting, the reporting configuration including a TDCP reporting amount to be reported by the UE; transmitting 1302 a reference signal configuration including one or more TRS samples to the UE; and transmitting signaling to the UE (1304A / 1304B), wherein the signaling comprises: Pointing to one or more measurement windows; Limiting the number of TRS samples to be considered when calculating / updating TDCP reporting quantities; transmitting (1304A / 1304B) signaling including one or more of: sending 1308 a DCI to the UE that triggers aperiodic TDCP reporting; receiving the calculated / updated TDCP reporting quantity (1310A / 1310A); A method comprising:

33. The TDCP reports include different types of autocorrelation-based reports, Doppler spread f ｄ , the last N １ Moving average of the last N samples １ 33. The method of claim 32, wherein the method comprises one or more of: a weighted average of the samples;

34. N １ 34. The method of claim 32 or 33, wherein is equal to one of 3, 1 indicated by the UE capability and indicated by the network configuration parameter.

35. N １ 35. The method of any one of claims 32 to 34, wherein the network configuration is indicated by a parameter called timeRestrictionForTDCPMeasurements in a Radio Resource Control (RRC) message.

36. If timeRestrictionForTDCPMeasurements is set, N １ 36. The method of any one of claims 32 to 35, wherein is considered to be 1.

37. N １ 37. The method of any one of claims 32 to 36, wherein is configured by an RRC message.

38. 38. The method of any one of claims 32 to 37, wherein the signaling includes one or more of periodic measurement windows, aperiodically triggered measurement windows, and semi-persistently activated TRS windows.

39. 39. The method of claim 32, wherein the measurement window comprises a TRS measurement time configuration (TRS-MTC) configured, wherein the UE is only required to calculate / update the TDCP quantity using the TRS samples and / or TRS bursts within the configured measurement time.

40. 40. The method of any one of claims 32 to 39, wherein the TDCP amount is calculated or updated only during each periodic TRS measurement window, and the calculated / updated TDCP amount is valid until the next TRS measurement window.

41. Each TRS measurement window has a duration or length T ２ 41. The method of any one of claims 32 to 40, comprising:

42. Duration or length T ２ 42. The method of any one of claims 32 to 41, wherein is set via higher layer parameters.

43. 43. The method of any one of claims 32 to 42, wherein the length of a TRS measurement window and / or the size of the time lag within which autocorrelation can be calculated within the TRS measurement window is part of UE capabilities.

44. 44. The method of any one of claims 32 to 43, wherein specific capabilities regarding the length of a TRS measurement window and / or the size of the time lag over which autocorrelation can be calculated for a given UE are reported to the network as part of UE capabilities.

45. 45. The method of any one of claims 32 to 44, wherein the TRS measurement window can be configured as part of the CSI-ReportConfig IE.

46. 46. ​​The method of any one of claims 32 to 45, wherein the DCI that triggers the aperiodic triggered TRS measurement window is different from the DCI that triggers the aperiodic TDCP reporting.

47. 47. The method of any one of claims 32 to 46, wherein the DCI that triggers the aperiodic triggered TRS measurement window is the same as the DCI that triggers the aperiodic TDCP reporting.

48. 48. The method of any one of claims 32 to 47, wherein the CPU occupancy duration for TDCP reporting is determined with respect to a TRS measurement window.

49. 49. The method of any one of claims 32 to 48, wherein additional time is added to the last symbol of the TRS within the TRS measurement window for CPU occupancy.

50. 50. A method according to any one of claims 32 to 49, wherein the last OFDM or downlink OFDM symbol in the window is used to determine CPU occupancy duration.

51. 51. The method of any one of claims 32 to 50, wherein the CPU time spent on measurements and / or calculations related to TDCP reporting quantities is spent on the entire duration of the TRS measurement window.

52. 52. The method of any one of claims 32 to 51, wherein if there is no available CPU for a TRS measurement window, the TDCP reporting quantity does not need to be calculated / updated.

53. 53. The method of any one of claims 32 to 52, wherein if the UE is configured for DRX and the active measurement window for TDCP reporting is outside the DRX active time, the TDCP amount does not need to be updated.

54. 54. The method of any one of claims 32 to 53, wherein the UE includes in a measurement report information about which measurements / measurement occasions have been abandoned.

55. 55. The method of any one of claims 32 to 54, wherein the UE includes in a measurement report information about which measurements / measurement occasions were used.

56. 56. A method according to any one of claims 32 to 55, wherein the TDCP measure is an autocorrelation measure or any quantity calculated based on autocorrelation measures for one or more autocorrelation lags.

57. The autocorrelation measure is 57. The method of any one of claims 32 to 56, wherein the method is defined by averaging.

58. The UE determines the following quantities: For example, the normalized autocorrelation function, For example, the absolute value of the normalized autocorrelation function, and That is, the sign of the real part of the autocorrelation function times the absolute value of the normalized autocorrelation function, 58. The method of any one of claims 32 to 57, wherein the method reports one or more measurements of:

59. 1. A user equipment (UE) (1500) for time domain channel characteristic (TDCP) reporting based on measurements of tracking reference signal (TRS) samples, the UE (1500) comprising a processing circuit (1502) and a memory (1510), the memory (1510) configured to: receiving a reporting configuration from a network, the reporting configuration including a TDCP reporting amount to be reported by the UE for TDCP reporting; receiving a reference signal configuration from the network, the reference signal configuration including one or more TRS samples; receiving signaling from the network, wherein the signaling comprises: Pointing to one or more measurement windows; Limiting the number of TRS samples to be considered when calculating / updating TDCP reporting quantities; receiving signaling including one or more of: the TRS samples in the indicated measurement window or windows; the indicated number of TRS samples; calculating and / or updating the TDCP reporting quantity to be reported using only one or more of: receiving a DCI from the network that triggers an aperiodic TDCP report; reporting the calculated / updated TDCP reporting quantity; and a user equipment (1500) including instructions for causing the user equipment (1500) to execute the steps of:

60. 60. A user equipment (1500) according to claim 59, further operable to implement the features according to any one of claims 2 to 31.

61. 16. A network node (1600) for receiving a time domain channel characteristic (TDCP) report based on measurements of tracking reference signal (TRS) samples, said network node (1600) comprising a processing circuit (1602) and a memory (1604), said memory (1604) configured to cause said network node (1600) to: sending a reporting configuration to a user equipment (UE) for TDCP reporting, the reporting configuration including a TDCP reporting quantity to be reported by the UE; transmitting a reference signal configuration to the UE, the reference signal configuration including one or more TRS samples; transmitting signaling to the UE, the signaling comprising: Pointing to one or more measurement windows; Limiting the number of TRS samples to be considered when calculating / updating TDCP reporting quantities; transmitting signaling, transmitting downlink control information (DCI) to the UE triggering aperiodic TDCP reporting; As part of the aperiodic TDCP reporting, during the one or more measurement windows: using only the indicated number of TRS samples as part of said aperiodic TDCP report; receiving calculated / updated TDCP reporting quantities using one or more of: A network node (1600) including instructions for executing:

62. A network node (800) according to claim 61, further operable to implement the features according to any one of claims 33 to 58.

63. 32. A computer-readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method of any one of claims 1 to 31.

64. 59. A computer readable medium comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method of any one of claims 32 to 58.

Images