Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
AUTOCORRELATION FUNCTION CHARACTERISTICS ESTIMATION AND REPORTING
Document Type and Number:
WIPO Patent Application WO/2024/033810
Kind Code:
A1
Abstract:
Systems and methods for determining autocorrelation parameters are provided. In some embodiments, a method performed by a User Equipment (UE) includes: receiving a configuration of reference signals that can be used for autocorrelation estimation; receiving a configuration signaling to perform autocorrelation estimation and to estimate and/or report the autocorrelation constant and/or the autocorrelation level crossing point; performing autocorrelation estimation for a number of autocorrelation lags; estimating the autocorrelation constant and/or the autocorrelation level crossing point; and reporting the autocorrelation constant and/or the autocorrelation level crossing point. Certain embodiments might: reduce the signaling load as compared to signaling of the autocorrelation for multiple autocorrelation lags; allow for leaving details of estimation up to UE implementation; allow for the use of thresholds when making decisions; use CSI feedback-based precoding or to use precoding based on SRS and reciprocity; select one of several possible CSI feedback schemes; to select CSI-RS configuration parameters.

Inventors:
ERNSTRÖM PER (SE)
ATHLEY FREDRIK (SE)
MURUGANATHAN SIVA (CA)
ZHANG JIANWEI (SE)
Application Number:
PCT/IB2023/058012
Publication Date:
February 15, 2024
Filing Date:
August 08, 2023
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
ERICSSON TELEFON AB L M (SE)
International Classes:
H04L1/00; H04L25/02; H04B7/02; H04B7/0456; H04L27/26
Domestic Patent References:
WO2012060751A12012-05-10
Other References:
TAVARES GONCALO N: "On the Statistics of the IEEE 802.11n/ac Fading Channel Models", IEEE WIRELESS COMMUNICATIONS LETTERS, IEEE, PISCATAWAY, NJ, USA, vol. 5, no. 3, 1 June 2016 (2016-06-01), pages 272 - 275, XP011614535, ISSN: 2162-2337, [retrieved on 20160617], DOI: 10.1109/LWC.2016.2537336
Attorney, Agent or Firm:
MACENKO, Marc (US)
Download PDF:
Claims:
Claims 1. A method performed by a User Equipment, UE, (1000) for determining autocorrelation parameters, the method comprising: receiving (700) a configuration of reference signals that can be used for autocorrelation estimation; receiving (702) a configuration signaling to perform autocorrelation estimation and to estimate and/or report an autocorrelation constant and/or an autocorrelation level crossing point; performing (704) autocorrelation estimation for a number of autocorrelation lags; estimating (706) the autocorrelation constant and/or the autocorrelation level crossing point; and reporting (708) the autocorrelation constant and/or the autocorrelation level crossing point. 2. The method of claim 1 wherein: the UE (1000) measures the autocorrelation for multiple autocorrelation lags, and based on these measurements, the UE (1000) estimates and reports a coefficient of a second degree term in a Maclaurin expansion of the Autocorrelation seen as a function of the autocorrelation lag. 3. The method of any of claims 1-2 wherein: the coefficient is estimated through a least square fit to the measurements. 4. The method of any of claims 1-3 wherein: the coefficient is estimated through a weighted least square fit to the measurements. 5. The method of any of claims 1-4 wherein: lower weights are used for measurements at higher autocorrelation lags to account for ℴ^ !" deviations. 6. The method of any of claims 1-5 wherein: measurements that are below a certain level are discarded before the coefficient is estimated in order to reduce the effect of ℴ^ !" deviations. 7. The method of any of claims 1-6 wherein: the UE (1000) converts a complex valued autocorrelation estimate #^ " to a real valued estimate $%&'^ " and estimates the coefficient based on the resulting real valued autocorrelation estimate.

8. The method of any of claims 1-7 wherein: measurements $%&'^ " that are above a certain level are discarded before the coefficient is estimated in order to reduce the effect of ℴ^ !" deviations. 9. The method of any of claims 1-8 wherein: the UE (1000) measures and reports the autocorrelation for multiple autocorrelation lags to a network node (1100) to enable the network node (1100) to estimate the coefficient based on the autocorrelation for multiple autocorrelation lags. 10. The method of any of claims 1-9 further comprising: using the coefficient to make a decision on one or more parameters. 11. The method of claim 10 wherein: using the coefficient comprises: using the coefficient to make a decision on how to perform averaging/filtering of raw channel estimates. 12. The method of any of claims 1-11 wherein: the UE (1000) measures the normalized autocorrelation for multiple autocorrelation lags and based on these measurements the UE (1000) estimates and reports the level crossing point for a certain autocorrelation level. 13. The method of any of claims 1-12 wherein: reports the autocorrelation lag for which the normalized autocorrelation becomes smaller than the certain level. 14. The method of any of claims 1-13 wherein: the UE (1000) measures the autocorrelation for multiple autocorrelation lags, and based on these measurements, the UE (1000) estimates and reports a constant k in the expansion $^ " = 1 − O ∙ ^ + ℴ^ !" of the autocorrelation $^ " in powers of the correlation lag . 15. A method performed by a network node (1100) for determining autocorrelation parameters, the method comprising: sending (800) configuration of reference signals that can be used for autocorrelation estimation; sending (802) configuration signaling to perform autocorrelation estimation and to estimate and report an autocorrelation constant or an autocorrelation level crossing point; transmitting (804) reference signals that can be used by a User Equipment, UE, for autocorrelation estimation; receiving (806) the autocorrelation constant and/or the autocorrelation level crossing point; and using (808) the autocorrelation constant and/or autocorrelation level crossing point to make a decision. 16. The method of claim 15, wherein: receiving the autocorrelation for multiple autocorrelation lags from the UE (1000) and the network node (1100) estimates a coefficient of a second degree term in a Maclaurin expansion of the Autocorrelation seen as a function of the autocorrelation lag based on the autocorrelation for multiple autocorrelation lags. 17. The method of any of claims 15-16, wherein: the network uses the coefficient to make a decision on one or more of: the number of additional Demodulation Reference Signal, DMRS, symbols to configure; to use Channel State Information, CSI, feedback-based precoding or to use precoding based on Sounding Reference Signal, SRS, and reciprocity; to select one of several possible CSI feedback schemes; to select Channel State Information Reference Signal, CSI-RS, configuration parameters and CSI-feedback periodicity; and to decide the frequency granularity for precoding based on SRS and reciprocity. 18. The method of any of claims 15-17, wherein: the decision is made based on a threshold for the coefficient. 19. The method of any of claims 15-18, wherein: a hysteresis is used for the coefficient threshold. 20. The method of any of claims 15-19, wherein: the coefficient threshold depends on other information known by the network node (1100). 21. The method of any of claims 15-20, wherein: the coefficient threshold depends on radio channel characteristics.

22. The method of any of claims 15-21, wherein: the network calculates an estimate of the autocorrelation for some choice of autocorrelation lag as $%&'^ " = 1 − O ∙ ^ and uses $%&'^ " to make the decision. 23. The method of any of claims 15-22, wherein: the decision comprises whether to use a threshold for $%&'^ " with or without hysteresis. 24. The method of any of claims 15-23 wherein: the network node (1100) operates in a Fifth Generation, 5G, communications network. 25. The method of any of claims 15-24 wherein: the network node (1100) comprises a New Radio Base Station, gNB. 26. A User Equipment, UE, (1000) for determining autocorrelation parameters, the UE (1000) comprising processing circuitry (1002) and memory (1004), the memory (1004) comprising instructions to cause the UE (1000) to: receive a configuration of reference signals that can be used for autocorrelation estimation; receive a configuration signaling to perform autocorrelation estimation and to estimate and/or report an autocorrelation constant and/or an autocorrelation level crossing point; perform autocorrelation estimation for a number of autocorrelation lags; estimate the autocorrelation constant and/or the autocorrelation level crossing point; and report the autocorrelation constant and/or the autocorrelation level crossing point. 27. The UE (1000) of claim 26 further operable to implement the features of any of claims 2- 14. 28. A network node (1100) for determining autocorrelation parameters, the network node (1100) comprising processing circuitry (1002) and memory (1004), the memory (1004) comprising instructions to cause the network node (1100) to: send a configuration of reference signals that can be used for autocorrelation estimation; send configuration signaling to perform autocorrelation estimation and to estimate and report an autocorrelation constant or an autocorrelation level crossing point; transmit reference signals that can be used by a User Equipment, UE, for autocorrelation estimation; receive the autocorrelation constant and/or the autocorrelation level crossing point; and use the autocorrelation constant and/or autocorrelation level crossing point to make a decision. 29. The network node (1100) of claim 28 further operable to implement the features of any of claims 16-25. 30. A computer-readable medium comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1 to 14. 31. A computer-readable medium comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 15 to 25.

Description:
AUTOCORRELATION FUNCTION CHARACTERISTICS ESTIMATION AND REPORTING Related Applications [0001] This application claims the benefit of provisional patent application serial number 63/396,004, filed August 8, 2022, the disclosure of which is hereby incorporated herein by reference in its entirety. Technical Field [0002] The present disclosure relates generally to estimating autocorrelation function values. Background [0003] MU-MIMO [0004] With multi-user MIMO (MU-MIMO), two or more users in the same cell are co- scheduled on the same time-frequency resource(s). That is, two or more independent data streams are transmitted to different UEs at the same time, and the spatial domain can typically be used to separate the respective streams. By transmitting several streams simultaneously, the capacity of the system can be increased. This, however, comes at the cost of reducing the SINR per stream, as the power must be shared between streams and the streams will cause interference to each other. [0005] Channel State Information Reference Signals (CSI-RS) [0006] For CSI measurement and feedback, CSI-RS are defined. A CSI-RS is transmitted on each antenna port and is used by a UE to measure downlink channel between each of the transmit antenna ports and each of its receive antenna ports. The transmit antenna ports are also referred to as CSI-RS ports. The supported number of antenna ports in NR are {1, 2, 4, 8, 12, 16, 24, 32}. By measuring the received CSI-RS, a UE can estimate the channel that the CSI-RS is traversing, including the radio propagation channel and antenna gains. The CSI-RS for the above purpose is also referred to as Non-Zero Power (NZP) CSI-RS. [0007] CSI-RS can be configured to be transmitted in certain REs in a slot and certain slots. Figure 1 shows an example of CSI-RS REs for 12 antenna ports, where 1 RE per RB per port is shown. [0008] In addition, interference measurement resource (IMR) is also defined in NR for a UE to measure interference. An IMR resource contains 4 REs, either 4 adjacent REs in frequency in the same OFDM symbol or 2 by 2 adjacent REs in both time and frequency in a slot. By measuring both the channel based on NZP CSI-RS and the interference based on an IMR, a UE can estimate the effective channel and noise plus interference to determine the CSI, i.e., rank, precoding matrix, and the channel quality. [0009] Furthermore, a UE in NR may be configured to measure interference based on one or multiple NZP CSI-RS resource. [0010] TRS [0011] Due to oscillator imperfections, transmission and reception may not be synchronized in time and/or frequency, which can cause inter- and intra-symbol interference. In NR, tracking reference signal (TRS) was introduced that can be used by the UE for synchronization. [0012] In NR 3GPP specifications, TRS can be configured when CSI report setting is not configured or when the higher layer parameter ‘reportQuantity’ in the CSI-ReportConfig information element (IE), associated with all the report settings linked with the CSI-RS resource set containing the TRS(s) is set to ‘none’. This means that CSI reporting based in measurements on TRS is not supported in NR. [0013] TRS is configured via ‘trs-Info’ in the NZP-CSI-RS-ResourceSet IE of 3GPP TS 38.331 which is associated with a CSI-RS resource set, for which the UE can assume that the antenna port with the same port index of the configured NZP CSI-RS resources in the said resource set is the same. From 3GPP specifications perspective TRS is specified as a special kind of NZP CSI-RS where the corresponding NZP CSI-RS resource set containing the TRS(s) has a higher layer parameter ‘trs-info’ set to true. [0014] TRS is not really a CSI-RS, rather it is a resource set consisting of multiple periodic NZP CSI-RS. More specifically, a TRS consists of four one-port, density-3 CSI-RSs located within two consecutive slots. The CSI-RS within the said resource set, can be configured with a periodicity of 10, 20, 40, or 80 ms. Note that the exact set of REs used for the TRS CSI-RS may vary. There is always a four-symbol time-domain separation between the two CSI-RS within a slot. Figure 2 shows an example of a TRS burst of two TRS symbols in two adjacent slots. [0015] NR also supports aperiodic TRS. [0016] For LTE, the cell-specific reference signal (CRS) served the same purpose as the TRS as LTE CRS can be used for synchronization, but it can also be used for CSI reporting, which is not supported for TRS in NR. However, compared to the LTE CRS, the TRS implies much less overhead, only having one antenna port and only being present in two slots every TRS period. Figure 3 illustrates configurability of TRS symbol positions and TRS burst periodicity. [0017] CSI framework in NR [0018] In NR, a UE can be configured with multiple CSI reporting settings and multiple CSI- RS resource settings. Each resource setting can contain multiple resource sets, and each resource set can contain up to 8 CSI-RS resources. For each CSI reporting setting, a UE feeds back a CSI report. [0019] Each CSI reporting setting contains at least the following information: • A CSI-RS resource set for channel measurement • An IMR resource set for interference measurement • Optionally, a CSI-RS resource set for interference measurement • Time-domain behavior, i.e., periodic, semi-persistent, or aperiodic reporting • Frequency granularity, i.e., wideband 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 • Codebook types, i.e., Type I or II, and codebook subset restriction • Measurement restriction • Subband size. One out of two possible subband sizes is indicated, the value range depends on the bandwidth of the BWP. One CQI/PMI (if configured for subband reporting) is fed back per subband). [0020] Type 1 and type 2 codebooks in NR [0021] Type 1 codebook (CB) is typically used by a UE to report CSI for single user MIMO (SU-MIMO) scheduling in NR. While type 2 CB is typically for more accurate CSI feedback for multi-user MIMO (MU-MIMO) scheduling. [0022] For both type 1 and type 2 CBs, for each rank, a precoding matrix ^ is defined in the form of: ^ = ^ ^ ^ ^ ^ ^ = ^ ^^ ^^ … ^^ ^ ^ … ^ ^ is a 2Nx2L matrix and contains , ^}, where ^ ^ is a Nx1 DFT vector and N is the number of CSI-RS ports per polarization; while ^ ^ is a 2^ × ^ matrix and contains the co-phasing coefficients between the selected beams and also between antenna ports with two different polarizations, where ^ is the number of layers or rank. ^ ^ is the same for the whole CSI bandwidth while ^ ^ can be for the whole bandwidth or per subband. [0023] In case of 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. [0024] Enhanced Type 2 codebook in NR [0025] In NR Rel-16, type 2 CB is enhanced by applying frequency domain (FD) DFT basis across all subbands to reduced CSI feedback overhead and/or improve CSI accuracy. Instead of reporting ^ ^ for each subband, linear combinations of DFT basis vectors are used to jointly represent ^ ^ across the whole CSI bandwidth. For each layer, a precoding matrix ^ across all subbands is in the form of: ^ = ^ ^ ^ ^ ^ ^ ^ ^ where ^ ^ = [^ ^ , … , ^ ^ ] is a matrix containing M selected DFT basis vectors {^ ^ , … , ^ ^ } , ^ ^ ^ is 2L x M matrix containing the coefficients for each selected DFT beam and FD basis vector. [0026] QCL and TCI states [0027] Several signals can be transmitted from different antenna ports of a same base station. These signals can have the same large-scale properties such as Doppler shift/spread, average delay spread, or average delay. These antenna ports are then said to be quasi co-located (QCL). [0028] 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 the antenna ports and apply that estimate for receiving signal on the other antenna port. Typically, the first antenna port is represented by a measurement reference signal such as TRS or SSB (known as source RS) and the second antenna port is a demodulation reference signal (DMRS) (known as target RS). [0029] For instance, if antenna ports A and B are QCL with respect to 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 since the UE can know beforehand the properties of the channel, which for instance helps the UE in selecting an appropriate channel estimation filter. [0030] Information about what assumptions can be made regarding QCL is signaled to the UE from the network. In NR, four types of QCL relations between a transmitted source RS and transmitted target RS were defined: Type A: {Doppler shift, Doppler spread, average delay, delay spread} Type B: {Doppler shift, Doppler spread} Type C: {average delay, Doppler shift} Type D: {Spatial Rx parameter} [0031] Rel-18 specification of TRS based TDCP reporting [0032] In RAN1#109e meeting, the following agreement was reached: [0033] Agreement [0034] The work scope of TRS-based TDCP reporting focuses on the following use cases for evaluation purposes: - Targeting medium and high UE speed, e.g., 10-120km/h as well as HST speed - Aiding gNB to determine ^ CSI reporting configuration and CSI-RS resource configuration parameters, ^ Precoding scheme, using one of the CSI feedback-based precoding schemes or an UL-SRS reciprocity-based precoding scheme - Aiding gNB-side CSI prediction [0035] As agreed above, there are several use cases for the gNB to know the Time Domain Channel Properties (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 ageing when the channel varies fast. For instance, 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 from CSI feedback obtained from the UE. Another example is that the gNB may need to decide whether the precoder to schedule the UE should be based on Type I CSI feedback obtained from the UE or Type II CSI feedback obtained from the UE. Improved systems and methods for determining autocorrelation parameters are needed. Summary [0036] Systems and methods for determining autocorrelation parameters are provided. In some embodiments, a method performed by a User Equipment (UE) for determining autocorrelation parameters includes: receiving a configuration of reference signals that can be used for autocorrelation estimation; receiving a configuration signaling to perform autocorrelation estimation and to estimate and/or report the autocorrelation constant and/or the autocorrelation level crossing point; performing autocorrelation estimation for a number of autocorrelation lags; estimating the autocorrelation constant and/or the autocorrelation level crossing point; and reporting the autocorrelation constant and/or the autocorrelation level crossing point. Certain embodiments may provide one or more of the following technical advantages. The solutions reduce the signaling load as compared to signaling of the autocorrelation for multiple autocorrelation lags. The solutions allow for leaving details of UE estimation algorithms (such as e.g., for what autocorrelation lags the UE should measure the autocorrelation) up to UE implementation. The solution allows for the use of thresholds (with or without hysteresis) when making decisions on e.g.: The number of additional DMRS symbols to configure. To use CSI feedback-based precoding or to use precoding based on SRS and reciprocity. To select one of several possible CSI feedback schemes. To select CSI-RS configuration parameters and CSI-feedback periodicity. To decide the frequency granularity for precoding based on SRS and reciprocity. [0037] In some embodiments, the UE measures the autocorrelation for multiple autocorrelation lags, and based on these measurements the UE estimates and reports the coefficient of the second degree term in the Maclaurin expansion of the Autocorrelation seen as a function of the autocorrelation lag. [0038] In some embodiments, the coefficient is estimated through a least square fit to the measurements. [0039] In some embodiments, the coefficient is estimated through a weighted least square fit to the measurements. [0040] In some embodiments, lower weights are used for measurements at higher autocorrelation lags to account for ℴ^ ! " deviations. [0041] In some embodiments, measurements that are below a certain level are discarded before k is estimated in order to reduce the effect of ℴ^ ! " deviations. [0042] In some embodiments, the UE converts a complex valued autocorrelation estimate #^ " to a real valued estimate $ %&' ^ " and estimates the coefficient based on the resulting real valued autocorrelation estimate. [0043] In some embodiments, measurements ($ %&' ^ " that are above a certain level are discarded before k is estimated in order to reduce the effect of ℴ^ ! " deviations. [0044] In some embodiments, the UE measures and reports the autocorrelation for multiple autocorrelation lags to a network node to enable the network node to estimate k based on the autocorrelation for multiple autocorrelation lags. [0045] In some embodiments, the method further comprising: using the k-value to make a decision on one or more parameters. [0046] In some embodiments, using the k-value comprises: using the k-value to make a decision on how to perform averaging/filtering of raw channel estimates. [0047] In some embodiments, the UE measures the normalized autocorrelation for multiple autocorrelation lags and based on these measurements the UE estimates and reports the level crossing point for a certain autocorrelation level. [0048] In some embodiments, reports the autocorrelation lag for which the normalized autocorrelation becomes smaller than the certain level. [0049] In some embodiments, the UE operates in a Fifth Generation (5G) communications network. Brief Description of the Drawings [0050] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure. [0051] Figure 1 shows an example of CSI-RS REs for 12 antenna ports, where 1 RE per RB per port is shown; [0052] Figure 2 shows an example of a TRS burst of two TRS symbols in two adjacent slots; [0053] Figure 3 illustrates configurability of TRS symbol positions and TRS burst periodicity; [0054] Figure 4A illustrates 16 gNB antenna ports; [0055] Figure 4B illustrates 32 gNB antenna ports; [0056] Figures 5A and 5B show a comparison of the performance of precoding based on Type I and Type II CSI, respectively; [0057] Figure 6 shows delays ) for which the correlation can be estimated based on intra TRS burst measurements using the TRS signal; [0058] Figure 7 illustrates a method of operating a UE for determining autocorrelation parameters, according to some embodiments of the current disclosure; [0059] Figure 8 illustrates a method of operating a network node (e.g., gNB) for determining autocorrelation parameters, according to some embodiments of the current disclosure; [0060] Figure 9 shows an example of a communication system in accordance with some embodiments; [0061] Figure 10 shows a UE in accordance with some embodiments; [0062] Figure 11 shows a network node in accordance with some embodiments; [0063] Figure 12 is a block diagram of a host, which may be an embodiment of the host of Figure 9, in accordance with various aspects described herein; [0064] Figure 13 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized; and [0065] Figure 14 shows a communication diagram of a host communicating via a network node with a UE over a partially wireless connection in accordance with some embodiments. Detailed Description [0066] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure. [0067] Figures 4A and 4B show mean user throughput for a particular scheme relative to the mean throughput for feedback-based SU-MIMO precoding (the baseline). Figure 4A illustrates 16 gNB antenna ports and Figure 4B illustrates 32 gNB antenna ports. The throughput is 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 500 meter inter-site distance. 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 the feedback- based precoding has better performance. Hence, the feedback-based precoding is more robust to rapidly varying channels. A speed of 10 km/h corresponds to a channel coherence time which is longer than two slots. [0068] Figures 5A and 5B show a comparison of the performance of precoding based on Type I and Type II CSI, respectively. Figures 5A and 5B illustrate relative mean user throughput vs. UE speed for Type I and Type II CSI. Figure 5A illustrates 16 gNB antenna ports and Figure 5B illustrates 32 gNB antenna ports. The results show that Type II CSI gives better performance at 3 km/h but at UE speeds around 10 km/h and higher, type I gives better performance. [0069] These results show that it could be beneficial to select precoding scheme based on some parameter that is related to the UE speed. It should be noted that it is not the UE speed per se that is the fundamental parameter in this context. Rather, it is how fast the channel varies which depends on the UE speed but also on the angle between the UE velocity vector and the propagation paths seen from the UE. Therefore, selection of precoding scheme based on some time domain channel property such as coherence time or autocorrelation is a more suitable parameter. [0070] UE measurement and reporting estimates of time domain correlation of the channel based on TRS samples across different time lags is an efficient way to report TDCP based on TRS. [0071] In order to define the time domain correlation measurement across TRS samples, let * + [,], , = 0,1, … , / − 1 be the received frequency domain TRS samples after matched filtering. Index 1 denote the different OFDM symbols carrying the TRSs used for the correlation estimation. The starting point in time of the OFDM symbol 1 is given by 2 + (to be precise 2 + denotes the start of the non-CP part of the OFDM symbol). Index n denote TRS sample index (assumed to be proportional to subcarrier index). [0072] Let 3 4 ^5", 6 = 1 … 7, 5 = 1, 2 be the 1-indices of 7 symbol pairs to use for the estimation of the correlation for a delay = 2 89^^" − 2 89^^" . It is assumed that the 7 symbol pairs are separated by the same distance in time. times 2 89^:" are also assumed to be within the measurement interval [2 − ∆2, 2]. [0073] In one example, a low-complexity estimate of the normalized time domain correlation for a delay is calculated in the frequency domain as # ∆' ^2, " = ∑J 9HC ∑E GHF IC >? ^ "[A]∙>∗ [A] C 9 @ ?9^C" ] [0074] In another example, the inverse DFT is calculated for each OFDM symbol 1: N + [O] = P^^2^* + [,]" [0075] The estimate of the normalized correlation for time delay is calculated as # ∆' ^2, " = ∑J 9HC ∑R∈T^9" Q? ^ "[)]∙Q∗ [)] C 9 @ ? @ ∙∑J 9^C" 9 HC ∑R∈T^9" KQ?9^C"[)]∙Q∗ ∗ , ? 9^C" [)]LQ?9^@"[)]∙Q?9^@" [)]M where the sum e.g., by using a noise threshold as e.g. ì [N89^^"[O][ ï \ > 2ℎ_`aℎb1( " 89^^" is real-valued but the estimates # ∆' ^2, " are typically complex valued due to the limited averaging and/or due to a To get a real valued autocorrelation estimate $ %&' ^2, " one may use e.g., one of the following methods: $ %&' ^2, " = |# ∆' ^2, " | [0077] Note that at low speeds the change in the channel is small and the change in correlation at different delays within a TRS burst is quite small (note that the TRS burst is defined as in Figure 2). Within a TRS burst, correlation can be measured for delays of 4 symbol, 10 symbol, 14 symbol, and 18 symbols as shown in Figure 6. Figure 6 shows delays ) for which the correlation can be estimated based on intra TRS burst measurements using the TRS signal. Note that for ^ = 4 ∙ g hij^Lk8 and for ^ = g l^hm = 14 ∙ g hij^Lk8 there are two samples within the TRS burst that can be used for the measurement, while for n = 18 ∙ g hij^Lk8 and ! = 10 ∙ g hij^Lk8 there is only one sample within the TRS burst that can be used for the measurement. [0078] As the change in correlation at different delays within a TRS burst is quite small for low velocities, intra TR burst measurements are not enough to distinguish between different velocities in the low velocity region. Based on the results in Figures 4A and 4B and Figures 5A and 5B, to enable the gNB to select a transmission scheme that is more robust against channel aging, the gNB needs to distinguish between rather low UE speeds. Therefore, in order to distinguish between such low speeds from a TDCP report, support for measuring and reporting correlation for time delays corresponding to multiple TRS bursts is needed. [0079] There currently exist certain challenges. Reporting of the autocorrelation function for several autocorrelation lags result in a large signaling load (i.e., a large overhead). [0080] It is not known how to utilize the autocorrelation at multiple autocorrelation lags to make decisions on e.g.,: The number of additional DMRS symbols to configure. To use CSI feedback-based precoding or to use precoding based on SRS and reciprocity. To select one of several possible CSI feedback schemes. To select CSI-RS configuration parameters and CSI- feedback periodicity. To decide the frequency granularity for precoding based on SRS and reciprocity. Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. [0081] Systems and methods for determining autocorrelation parameters are provided. In some embodiments, a method performed by a User Equipment (UE) for determining autocorrelation parameters includes: receiving a configuration of reference signals that can be used for autocorrelation estimation; receiving a configuration signaling to perform autocorrelation estimation and to estimate and/or report the autocorrelation constant and/or the autocorrelation level crossing point; performing autocorrelation estimation for a number of autocorrelation lags; estimating the autocorrelation constant and/or the autocorrelation level crossing point; and reporting the autocorrelation constant and/or the autocorrelation level crossing point. [0082] Certain embodiments may provide one or more of the following technical advantages. The solutions reduce the signaling load as compared to signaling of the autocorrelation for multiple autocorrelation lags. The solutions allow for leaving details of UE estimation algorithms (such as e.g., for what autocorrelation lags the UE should measure the autocorrelation) up to UE implementation. The solution allows for the use of thresholds (with or without hysteresis) when making decisions on e.g.: The number of additional DMRS symbols to configure. To use CSI feedback-based precoding or to use precoding based on SRS and reciprocity. To select one of several possible CSI feedback schemes. To select CSI-RS configuration parameters and CSI-feedback periodicity. To decide the frequency granularity for precoding based on SRS and reciprocity. [0083] First embodiment [0084] UE estimation and reporting of the autocorrelation constant k in the form $^ " = 1 − O ∙ ^ + ℴ^ ! " of the autocorrelation for low autocorrelation lags . This reduces the signaling load relative to reporting of the autocorrelation for multiple autocorrelation lags. In some embodiments, the value estimated and reported is the coefficient of the second degree term in the Maclaurin expansion of the Autocorrelation seen as a function of the autocorrelation lag. In some embodiments, the value is calculated as: minus one times the coefficient of the second degree term in the Maclaurin expansion of the Autocorrelation seen as a function the autocorrelation. Note that the use of Maclaurin expansion rather than Taylor expansion means that the Taylor expansion is around zero correlation lag. [0085] Second embodiment [0086] UE estimation and reporting of the level crossing point q at which the autocorrelation crosses a certain level which is either preconfigured or signaled to the UE. This reduces the signaling load relative to reporting of the autocorrelation for multiple autocorrelation lags. [0087] First embodiment: UE estimation and reporting of the autocorrelation constant k in the form $ ^ " = 1 − O ∙ ^ + ℴ ^ !" of the autocorrelation for low autocorrelation lags . [0088] Second embodiment: UE estimation and reporting of the level crossing point q at which the autocorrelation crosses a certain level. Signaling of the crossing level from the network to the UE. Pre-configuration of the crossing level. [0089] Figure 7 illustrates a method of operating a UE for determining autocorrelation parameters, according to some embodiments of the current disclosure. The method can include receiving configuration of reference signals that can be used for autocorrelation estimation (step 700). The UE can receive configuration signaling to perform autocorrelation estimation and to estimate and report the autocorrelation constant or the autocorrelation level crossing point (step 702). The UE can perform autocorrelation estimation for a number of autocorrelation lags (step 704). The UE can estimate autocorrelation constant or autocorrelation level crossing point (step 706). The UE can report autocorrelation constant or autocorrelation level crossing point (step 708). [0090] Figure 8 illustrates a method of operating a network node (e.g., gNB) for determining autocorrelation parameters, according to some embodiments of the current disclosure. The method can include sending configuration of reference signals that can be used for autocorrelation estimation (step 800). The network node can send configuration signaling to perform autocorrelation estimation and to estimate and report the autocorrelation constant or the autocorrelation level crossing point (step 802). The network node can transmit reference signals that can be used by the UE for autocorrelation estimation (step 804). The network node can receive autocorrelation constant or autocorrelation level crossing point (step 806). The network node can use the autocorrelation constant or autocorrelation level crossing point to make a decision (step 808). [0091] Embodiments based on autocorrelation behavior for small autocorrelation lags: [0092] The exact form of the normalized autocorrelation depends on the channel and can't be known a priori. However, it always has the form: $ ^ " = 1 − O ∙ ^ + ℴ ^ !" [0093] One may also note that the distance ($ of $ from one can be written as: ($^ " ≡ 1 − $^ " = O ∙ ^ + ℴ^ ! " where is the autocorrelation lag. [0094] UE based k-estimation [0095] In one embodiment, the UE measures the autocorrelation for multiple autocorrelation lags, and based on these measurements it estimates and reports the constant k. [0096] In one embodiment, k is estimated through a least square fit to the measurements, [0097] In one embodiment, k is estimated through a weighted least square fit to the measurements. In one sub-embodiment lower weights are used for measurements at higher autocorrelation lags to account for ℴ^ ! " deviations. [0098] In one embodiment, measurements that are below a certain level are discarded before k is estimated in order to reduce the effect of ℴ^ ! " deviations. [0099] Handling of complex valued autocorrelation estimates [0100] In some embodiments the UE converts a complex valued autocorrelation estimate #^ " to a real valued estimate $ %&' ^ " and estimates the constant k based on the resulting real valued autocorrelation estimate as described above. The conversion to a real valued estimate may be performed e.g., by one of the following methods: 1. Taking the absolute value of the complex valued estimate, i.e., $ %&' ^ " = | # ^ " | 2. Taking the real value of the complex valued estimate, i.e., $ %&' ^ " = e`^#^ " " 3. Taking the absolute value of the complex valued estimate and multiplying the result with the sign of the real value of the complex valued estimate, i.e., $ %&' ^ " = |#^ " | ∙ ad, Ke`s# ^ " tM [0101] embodiments the UE calculates the distance in the complex plane from the " to one as: ( $%&' ^ " = | 1 − # ^ " | [0102] The UE measures ($ %&' ^ " for multiple autocorrelation lags , and based on these measurements it estimates and the constant k of the form: ($^ " ≡ 1 − $^ " = O ∙ ^ + ℴ^ ! " [0103] In one embodiment, k is estimated through a least square fit to the measurements. [0104] In one embodiment, k is estimated through a weighted least square fit to the measurements. In one sub-embodiment lower weights are used for measurements at higher autocorrelation lags to account for ℴ^ ! " deviations. [0105] In one embodiment, measurements ($ %&' ^ " that are above a certain level are discarded before k is estimated in order to reduce the effect of ℴ^ ! " deviations. [0106] Network based k-estimation [0107] In one embodiment, the UE measures and reports the autocorrelation for multiple autocorrelation lags to a network node. The network node estimates k based on the autocorrelation for multiple autocorrelation lags (e.g., as described for the UE case above). [0108] Network utilization of k-estimate [0109] The network uses the k-value to make a decision on e.g., 1. The number of additional DMRS symbols to configure 2. To use CSI feedback-based precoding or to use precoding based on SRS and reciprocity 3. To select one of several possible CSI feedback schemes 4. To select CSI-RS configuration parameters and CSI-feedback periodicity 5. To decide the frequency granularity for precoding based on SRS and reciprocity [0110] In one embodiment, the decision is made based on a threshold for the parameter k. [0111] In one embodiment, a hysteresis is used for the parameter k threshold. [0112] In one embodiment, the parameter k threshold depends on other information known by the network node such as e.g., radio channel characteristics. [0113] In one embodiment, the network calculates an estimate of the autocorrelation for some choice of autocorrelation lag as $ %&' ^ " = 1 − O ∙ ^ and use $ %&' ^ " to make the decision, e.g., using a threshold for $ %&' ^ " with or without hysteresis. [0114] UE utilization of k-estimate [0115] The UE use the k-value to make a decision on e.g., how to perform averaging/filtering of raw channel estimates. [0116] Embodiments based on reporting of autocorrelation level crossing point [0117] In one embodiment, the UE measures the normalized autocorrelation for multiple autocorrelation lags, and based on these measurements, it estimates and reports the level crossing point for a certain autocorrelation level, i.e., it reports the autocorrelation lag for which the normalized autocorrelation becomes smaller than the certain level. [0118] In one embodiment, the autocorrelation crossing level is preconfigured. [0119] In one embodiment, the autocorrelation crossing level is signaled to the UE. [0120] Detailed embodiments for estimation of level crossing point [0121] In one embodiment, 1. The UE estimates the autocorrelation $^ " for a number of autocorrelation lags ^ < ^ < ⋯ < A . 2. The UE identifies the smallest autocorrelation lag ) for which $ %&' ^ ) " < $ q where $ q is the autocorrelation crossing level. 3. The UE linearly interpolates the crossing point q between the points s ^x ) w^ , $ %&' ^ )w^ "t and s ) , $ %&' ^ ) "t e.g., as q = yz{^|RFC "wx}"∙|RFC Lsx}wxyz{^|R "t∙|R " [0122] In an alternative embodiment, the UE uses higher order interpolation based on a set of estimation points around the level crossing. [0123] In yet another alternative embodiment, instead of interpolating to find the crossing point q , the UE may follow the following procedure: 1. The UE estimates the autocorrelation $^ " for a number of autocorrelation lags ^ < ^ < ⋯ < A . 2. The UE identifies the smallest autocorrelation lag ) for which $ %&' ^ ) " < $ q where $ q is the autocorrelation crossing level. 3. The UE identifies the smallest autocorrelation lag )L^ for which $ %&' ^ )L^ " > $ q . 4. The UE reports the two identified autocorrelation lags ) and )L^ . [0124] In another embodiment, multiple autocorrelation crossing levels may be configured/signaled to the UE. Based on the autocorrelation measurements, the UE estimates and reports the level crossing points for each of the configured/signaled multiple autocorrelation crossing levels. [0125] In yet another embodiment, the UE estimates the constant k in the autocorrelation form $^ " = 1 − O ∙ ^ as described herein and calculates the crossing point as q = ~ ^wx} ) . [0126] In some embodiments the valued autocorrelation estimate #^ " to a real valued estimate $ %&' ^ " and estimates the crossing point q based on the resulting real valued autocorrelation estimate. The conversion to a real valued estimate may be performed e.g., by one of the following methods: 1. Taking the absolute value of the complex valued estimate, i.e., $ %&' ^ " = |#^ " | 2. Taking the real value of the complex valued estimate, i.e., $ %&' ^ " = e`^#^ " " 3. Taking the absolute value of the complex valued estimate and multiplying the result with the sign of the real value of the complex valued estimate, i.e., $ %&' ^ " = |#^ " | ∙ ad, Ke`s# ^ " tM embodiments the UE calculates the distance in the complex plane from the complex estimate #^ " to one as: ( $%&' ^ " = | 1 − # ^ " | [0128] The UE measures ($ %&' ^ " for multiple autocorrelation lags , and based on these measurements it estimates and reports the crossing point q for which ($ %&' ^ " becomes larger than a certain level (preconfigured or signaled to the UE). The same methods (interpolation, fitting + using analytical formula for level crossing, or signaling the estimates directly before and directly after the crossing point), as described above may be used also here with the only difference that ($^ " increases with while $^ " decreases with . [0129] Figure 9 shows an example of a communication system 900 in accordance with some embodiments. [0130] In the example, the communication system 900 includes a telecommunication network 902 that includes an access network 904, such as a Radio Access Network (RAN), and a core network 906, which includes one or more core network nodes 908. The access network 904 includes one or more access network nodes, such as network nodes 910A and 910B (one or more of which may be generally referred to as network nodes 910), or any other similar Third Generation Partnership Project (3GPP) access node or non-3GPP Access Point (AP). The network nodes 910 facilitate direct or indirect connection of User Equipment (UE), such as by connecting UEs 912A, 912B, 912C, and 912D (one or more of which may be generally referred to as UEs 912) to the core network 906 over one or more wireless connections. [0131] Example wireless communications over a wireless connection include transmitting 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, the communication system 900 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 the communication of data and/or signals whether via wired or wireless connections. The communication system 900 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system. [0132] The UEs 912 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the network nodes 910 and other communication devices. Similarly, the network nodes 910 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 912 and/or with other network nodes or equipment in the telecommunication network 902 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network 902. [0133] In the depicted example, the core network 906 connects the network nodes 910 to one or more hosts, such as host 916. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 906 includes one more core network nodes (e.g., core network node 908) that are 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, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 908. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-Concealing Function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF). [0134] The host 916 may be under the ownership or control of a service provider other than an operator or provider of the access network 904 and/or the telecommunication network 902 and may be operated by the service provider or on behalf of the service provider. The host 916 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio/video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server. [0135] As a whole, the communication system 900 of Figure 9 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system 900 may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are 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 future generation standard (e.g., Sixth Generation (6G)); Wireless Local Area Network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and/or any Low Power Wide Area Network (LPWAN) standards such as LoRa and Sigfox. [0136] In some examples, the telecommunication network 902 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunication network 902 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 902. For example, the telecommunication network 902 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing enhanced Mobile Broadband (eMBB) services to other UEs, and/or massive Machine Type Communication (mMTC)/massive Internet of Things (IoT) services to yet further UEs. [0137] In some examples, the UEs 912 are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 904 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 904. Additionally, a UE may be configured for operating in single- or multi-Radio Access Technology (RAT) or multi-standard mode. For example, a UE may operate with any one or combination of WiFi, New Radio (NR), and LTE, i.e., be configured for Multi-Radio Dual Connectivity (MR-DC), such as Evolved UMTS Terrestrial RAN (E-UTRAN) NR - Dual Connectivity (EN-DC). [0138] In the example, a hub 914 communicates with the access network 904 to facilitate indirect communication between one or more UEs (e.g., UE 912C and/or 912D) and network nodes (e.g., network node 910B). In some examples, the hub 914 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 914 may be a broadband router enabling access to the core network 906 for the UEs. As another example, the hub 914 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 910, or by executable code, script, process, or other instructions in the hub 914. As another example, the hub 914 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 914 may be a content source. For example, for a UE that is a Virtual Reality (VR) headset, display, loudspeaker or other media delivery device, the hub 914 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 914 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub 914 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy IoT devices. [0139] The hub 914 may have a constant/persistent or intermittent connection to the network node 910B. The hub 914 may also allow for a different communication scheme and/or schedule between the hub 914 and UEs (e.g., UE 912C and/or 912D), and between the hub 914 and the core network 906. In other examples, the hub 914 is connected to the core network 906 and/or one or more UEs via a wired connection. Moreover, the hub 914 may be configured to connect to a Machine-to-Machine (M2M) service provider over the access network 904 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 910 while still connected via the hub 914 via a wired or wireless connection. In some embodiments, the hub 914 may be a dedicated hub – that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 910B. In other embodiments, the hub 914 may be a non-dedicated hub – that is, a device which is capable of operating to route communications between the UEs and the network node 910B, but which is additionally capable of operating as a communication start and/or end point for certain data channels. [0140] Figure 10 shows a UE 1000 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged, and/or operable to communicate wirelessly with network nodes and/or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, Voice over Internet Protocol (VoIP) phone, wireless local loop phone, desktop computer, Personal Digital Assistant (PDA), wireless camera, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, Laptop Embedded Equipment (LEE), Laptop Mounted Equipment (LME), smart device, wireless Customer Premise Equipment (CPE), vehicle-mounted or vehicle embedded/integrated wireless device, etc. Other examples include any UE identified by the 3GPP, including a Narrowband Internet of Things (NB-IoT) UE, a Machine Type Communication (MTC) UE, and/or an enhanced MTC (eMTC) UE. [0141] A UE may support Device-to-Device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (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 the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter). [0142] The UE 1000 includes processing circuitry 1002 that is operatively coupled via a bus 1004 to an input/output interface 1006, a power source 1008, memory 1010, a communication interface 1012, and/or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 10. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc. [0143] The processing circuitry 1002 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 1010. The processing circuitry 1002 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general purpose processors, such as a microprocessor or Digital Signal Processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 1002 may include multiple Central Processing Units (CPUs). [0144] In the example, the input/output interface 1006 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and/or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 1000. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device. [0145] In some embodiments, the power source 1008 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 1008 may further include power circuitry for delivering power from the power source 1008 itself, and/or an external power source, to the various parts of the UE 1000 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging the power source 1008. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 1008 to make the power suitable for the respective components of the UE 1000 to which power is supplied. [0146] The memory 1010 may be or be configured to include memory such as Random Access Memory (RAM), Read Only Memory (ROM), Programmable ROM (PROM), Erasable PROM (EPROM), Electrically EPROM (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 1010 includes one or more application programs 1014, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1016. The memory 1010 may store, for use by the UE 1000, any of a variety of various operating systems or combinations of operating systems. [0147] The memory 1010 may be configured to include a number of physical drive units, such as Redundant Array of Independent Disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, High Density Digital Versatile Disc (HD- DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, Holographic Digital Data Storage (HDDS) optical disc drive, external mini Dual In-line Memory Module (DIMM), Synchronous Dynamic RAM (SDRAM), external micro-DIMM SDRAM, smartcard memory such as a tamper resistant module in the form of a Universal Integrated Circuit Card (UICC) including one or more Subscriber Identity Modules (SIMs), such as a Universal SIM (USIM) and/or Internet Protocol Multimedia Services Identity Module (ISIM), other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as a ‘SIM card.’ The memory 1010 may allow the UE 1000 to access instructions, application programs, and the like stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system, may be tangibly embodied as or in the memory 1010, which may be or comprise a device-readable storage medium. [0148] The processing circuitry 1002 may be configured to communicate with an access network or other network using the communication interface 1012. The communication interface 1012 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1022. The communication interface 1012 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 a network node in an access network). Each transceiver may include a transmitter 1018 and/or a receiver 1020 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 1018 and receiver 1020 may be coupled to one or more antennas (e.g., the antenna 1022) and may share circuit components, software, or firmware, or alternatively be implemented separately. [0149] In the illustrated embodiment, communication functions of the communication interface 1012 may include cellular communication, WiFi communication, LPWAN communication, data communication, voice communication, multimedia communication, short- range communications such as Bluetooth, NFC, location-based communication such as the use of the Global Positioning System (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented according to one or more communication protocols and/or standards, such as IEEE 802.11, Code Division Multiplexing 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), and so forth. [0150] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 1012, or via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected, an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient). [0151] As another example, a UE comprises an actuator, a motor, or a switch related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input. [0152] A UE, when in the form of an IoT device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application, and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a television, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door/window sensor, a flood/moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like 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 tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item- tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and/or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE 1000 shown in Figure 10. [0153] As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and/or measurements and transmits the results of such monitoring and/or measurements to another UE and/or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. 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, a bus, a truck, a ship, an airplane, or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. [0154] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be 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 operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g., by controlling an actuator) to increase or decrease the drone’s speed. The first and/or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator and handle communication of data for both the speed sensor and the actuators. [0155] Figure 11 shows a network node 1100 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged, and/or operable to communicate directly or indirectly with a UE and/or with other network nodes or equipment in a telecommunication network. Examples of network nodes include, but are not limited to, APs (e.g., radio APs), Base Stations (BSs) (e.g., radio BSs, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)). [0156] BSs may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto BSs, pico BSs, micro-BSs, or macro BSs. A BS may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio BS such as centralized digital units and/or Remote Radio Units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such RRUs may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio BS may also be referred to as nodes in a Distributed Antenna System (DAS). [0157] Other examples of network nodes include multiple Transmission Point (multi-TRP) 5G access nodes, Multi-Standard Radio (MSR) equipment such as MSR BSs, network controllers such as Radio Network Controllers (RNCs) or BS Controllers (BSCs), Base Transceiver Stations (BTSs), transmission points, transmission nodes, Multi-Cell/Multicast Coordination Entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and/or Minimization of Drive Tests (MDTs). [0158] The network node 1100 includes processing circuitry 1102, memory 1104, a communication interface 1106, and a power source 1108. The network node 1100 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 certain scenarios in which the network node 1100 comprises multiple separate components (e.g., BTS and BSC components), 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 a scenario, each unique Node B and RNC pair may in some instances be considered a single separate network node. In some embodiments, the network node 1100 may be configured to support multiple RATs. In such embodiments, some components may be duplicated (e.g., separate memory 1104 for different RATs) and some components may be reused (e.g., an antenna 1110 may be shared by different RATs). The network node 1100 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1100, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z- wave, Long Range Wide Area Network (LoRaWAN), Radio Frequency Identification (RFID), or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within the network node 1100. [0159] The processing circuitry 1102 may comprise a combination of one or more of a microprocessor, controller, microcontroller, CPU, DSP, ASIC, FPGA, or any other suitable computing device, resource, or combination of hardware, software, and/or encoded logic operable to provide, either alone or in conjunction with other network node 1100 components, such as the memory 1104, to provide network node 1100 functionality. [0160] In some embodiments, the processing circuitry 1102 includes a System on a Chip (SOC). In some embodiments, the processing circuitry 1102 includes one or more of Radio Frequency (RF) transceiver circuitry 1112 and baseband processing circuitry 1114. In some embodiments, the RF transceiver circuitry 1112 and the baseband processing circuitry 1114 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of the RF transceiver circuitry 1112 and the baseband processing circuitry 1114 may be on the same chip or set of chips, boards, or units. [0161] The memory 1104 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid state memory, remotely mounted memory, magnetic media, optical media, RAM, ROM, mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD), or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable, and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the processing circuitry 1102. The memory 1104 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and/or other instructions capable of being executed by the processing circuitry 1102 and utilized by the network node 1100. The memory 1104 may be used to store any calculations made by the processing circuitry 1102 and/or any data received via the communication interface 1106. In some embodiments, the processing circuitry 1102 and the memory 1104 are integrated. [0162] The communication interface 1106 is used in wired or wireless communication of signaling and/or data between a network node, access network, and/or UE. As illustrated, the communication interface 1106 comprises port(s)/terminal(s) 1116 to send and receive data, for example to and from a network over a wired connection. The communication interface 1106 also includes radio front-end circuitry 1118 that may be coupled to, or in certain embodiments a part of, the antenna 1110. The radio front-end circuitry 1118 comprises filters 1120 and amplifiers 1122. The radio front-end circuitry 1118 may be connected to the antenna 1110 and the processing circuitry 1102. The radio front-end circuitry 1118 may be configured to condition signals communicated between the antenna 1110 and the processing circuitry 1102. The radio front-end circuitry 1118 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 1118 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of the filters 1120 and/or the amplifiers 1122. The radio signal may then be transmitted via the antenna 1110. Similarly, when receiving data, the antenna 1110 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1118. The digital data may be passed to the processing circuitry 1102. In other embodiments, the communication interface 1106 may comprise different components and/or different combinations of components. [0163] In certain alternative embodiments, the network node 1100 does not include separate radio front-end circuitry 1118; instead, the processing circuitry 1102 includes radio front-end circuitry and is connected to the antenna 1110. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1112 is part of the communication interface 1106. In still other embodiments, the communication interface 1106 includes the one or more ports or terminals 1116, the radio front-end circuitry 1118, and the RF transceiver circuitry 1112 as part of a radio unit (not shown), and the communication interface 1106 communicates with the baseband processing circuitry 1114, which is part of a digital unit (not shown). [0164] The antenna 1110 may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. The antenna 1110 may be coupled to the radio front-end circuitry 1118 and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In certain embodiments, the antenna 1110 is separate from the network node 1100 and connectable to the network node 1100 through an interface or port. [0165] The antenna 1110, the communication interface 1106, and/or the processing circuitry 1102 may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by the network node 1100. Any information, data, and/or signals may be received from a UE, another network node, and/or any other network equipment. Similarly, the antenna 1110, the communication interface 1106, and/or the processing circuitry 1102 may be configured to perform any transmitting operations described herein as being performed by the network node 1100. Any information, data, and/or signals may be transmitted to a UE, another network node, and/or any other network equipment. [0166] The power source 1108 provides power to the various components of the network node 1100 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 1108 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1100 with power for performing the functionality described herein. For example, the network node 1100 may be connectable to an external power source (e.g., the power grid or an electricity outlet) via input circuitry or an interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 1108. As a further example, the power source 1108 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail. [0167] Embodiments of the network node 1100 may include additional components beyond those shown in Figure 11 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, the network node 1100 may include user interface equipment to allow input of information into the network node 1100 and to allow output of information from the network node 1100. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1100. [0168] Figure 12 is a block diagram of a host 1200, which may be an embodiment of the host 916 of Figure 9, in accordance with various aspects described herein. As used herein, the host 1200 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, container, or processing resources in a server farm. The host 1200 may provide one or more services to one or more UEs. [0169] The host 1200 includes processing circuitry 1202 that is operatively coupled via a bus 1204 to an input/output interface 1206, a network interface 1208, a power source 1210, and memory 1212. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figures 10 and 11, such that the descriptions thereof are generally applicable to the corresponding components of the host 1200. [0170] The memory 1212 may include one or more computer programs including one or more host application programs 1214 and data 1216, which may include user data, e.g., data generated by a UE for the host 1200 or data generated by the host 1200 for a UE. Embodiments of the host 1200 may utilize only a subset or all of the components shown. The host application programs 1214 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 UEs (e.g., handsets, desktop computers, wearable display systems, and heads-up display systems). The host application programs 1214 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host 1200 may select and/or indicate a different host for Over-The-Top (OTT) services for a UE. The host application programs 1214 may support various protocols, such as the 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. [0171] Figure 13 is a block diagram illustrating a virtualization environment 1300 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices, and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more Virtual Machines (VMs) implemented in one or more virtual environments 1300 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. [0172] Applications 1302 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 1200 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein. [0173] Hardware 1304 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1306 (also referred to as hypervisors or VM Monitors (VMMs)), provide VMs 1308A and 1308B (one or more of which may be generally referred to as VMs 1308), and/or perform any of the functions, features, and/or benefits described in relation with some embodiments described herein. The virtualization layer 1306 may present a virtual operating platform that appears like networking hardware to the VMs 1308. [0174] The VMs 1308 comprise virtual processing, virtual memory, virtual networking, or interface and virtual storage, and may be run by a corresponding virtualization layer 1306. Different embodiments of the instance of a virtual appliance 1302 may be implemented on one or more of the VMs 1308, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as Network Function 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 can be located in data centers and customer premise equipment. [0175] In the context of NFV, a VM 1308 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1308, and that part of the hardware 1304 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs 1308, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1308 on top of the hardware 1304 and corresponds to the application 1302. [0176] The hardware 1304 may be implemented in a standalone network node with generic or specific components. The hardware 1304 may implement some functions via virtualization. Alternatively, the hardware 1304 may be part of a larger cluster of hardware (e.g., such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1310, which, among others, oversees lifecycle management of the applications 1302. In some embodiments, the hardware 1304 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a RAN or a BS. In some embodiments, some signaling can be provided with the use of a control system 1312 which may alternatively be used for communication between hardware nodes and radio units. [0177] Figure 14 shows a communication diagram of a host 1402 communicating via a network node 1404 with a UE 1406 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as the UE 912A of Figure 9 and/or the UE 1000 of Figure 10), the network node (such as the network node 910A of Figure 9 and/or the network node 1100 of Figure 11), and the host (such as the host 916 of Figure 9 and/or the host 1200 of Figure 12) discussed in the preceding paragraphs will now be described with reference to Figure 14. [0178] Like the host 1200, embodiments of the host 1402 include hardware, such as a communication interface, processing circuitry, and memory. The host 1402 also includes software, which is stored in or is accessible by the host 1402 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE 1406 connecting via an OTT connection 1450 extending between the UE 1406 and the host 1402. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 1450. [0179] The network node 1404 includes hardware enabling it to communicate with the host 1402 and the UE 1406 via a connection 1460. The connection 1460 may be direct or pass through a core network (like the core network 906 of Figure 9) and/or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet. [0180] The UE 1406 includes hardware and software, which is stored in or accessible by the UE 1406 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via the UE 1406 with the support of the host 1402. In the host 1402, an executing host application may communicate with the executing client application via the OTT connection 1450 terminating at the UE 1406 and the host 1402. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection 1450 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection 1450. [0181] The OTT connection 1450 may extend via the connection 1460 between the host 1402 and the network node 1404 and via a wireless connection 1470 between the network node 1404 and the UE 1406 to provide the connection between the host 1402 and the UE 1406. The connection 1460 and the wireless connection 1470, over which the OTT connection 1450 may be provided, have been drawn abstractly to illustrate the communication between the host 1402 and the UE 1406 via the network node 1404, without explicit reference to any intermediary devices and the precise routing of messages via these devices. [0182] As an example of transmitting data via the OTT connection 1450, in step 1408, the host 1402 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 1406. In other embodiments, the user data is associated with a UE 1406 that shares data with the host 1402 without explicit human interaction. In step 1410, the host 1402 initiates a transmission carrying the user data towards the UE 1406. The host 1402 may initiate the transmission responsive to a request transmitted by the UE 1406. The request may be caused by human interaction with the UE 1406 or by operation of the client application executing on the UE 1406. The transmission may pass via the network node 1404 in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 1412, the network node 1404 transmits to the UE 1406 the user data that was carried in the transmission that the host 1402 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1414, the UE 1406 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 1406 associated with the host application executed by the host 1402. [0183] In some examples, the UE 1406 executes a client application which provides user data to the host 1402. The user data may be provided in reaction or response to the data received from the host 1402. Accordingly, in step 1416, the UE 1406 may provide 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 the user via an input/output interface of the UE 1406. Regardless of the specific manner in which the user data was provided, the UE 1406 initiates, in step 1418, transmission of the user data towards the host 1402 via the network node 1404. In step 1420, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 1404 receives user data from the UE 1406 and initiates transmission of the received user data towards the host 1402. In step 1422, the host 1402 receives the user data carried in the transmission initiated by the UE 1406. [0184] One or more of the various embodiments improve the performance of OTT services provided to the UE 1406 using the OTT connection 1450, in which the wireless connection 1470 forms the last segment. More precisely, the teachings of these embodiments may improve the e.g., data rate, latency, power consumption, etc. and thereby provide benefits such as e.g., reduced user waiting time, relaxed restriction on file size, improved content resolution, better responsiveness, extended battery lifetime, etc. [0185] In an example scenario, factory status information may be collected and analyzed by the host 1402. As another example, the host 1402 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 1402 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 1402 may store surveillance video uploaded by a UE. As another example, the host 1402 may store or control access to media content such as video, audio, VR, or AR which it can broadcast, multicast, or unicast to UEs. As other examples, the host 1402 may be used for energy pricing, remote control of non-time critical electrical load 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. [0186] In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency, and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1450 between the host 1402 and the UE 1406 in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 1450 may be implemented in software and hardware of the host 1402 and/or the UE 1406. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 1450 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or by supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1450 may include message format, retransmission settings, preferred routing, etc.; the reconfiguring need not directly alter the operation of the network node 1404. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency, and the like by the host 1402. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 1450 while monitoring propagation times, errors, etc. [0187] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions, and methods disclosed herein. Determining, calculating, obtaining, or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box or nested within multiple boxes, in practice computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware. [0188] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored in memory, which in certain 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 circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hardwired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry 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 a wireless network generally. [0189] EMBODIMENTS [0190] Group A Embodiments [0191] Embodiment 1: A method performed by a User Equipment, UE, for determining autocorrelation parameters, the method comprising one or more of: a. receiving (700) configuration of reference signals that can be used for autocorrelation estimation; b. receiving (702) a configuration signaling to perform autocorrelation estimation and to estimate and/or report the autocorrelation constant and/or the autocorrelation level crossing point; c. performing (704) autocorrelation estimation for a number of autocorrelation lags; d. estimating (706) the autocorrelation constant and/or the autocorrelation level crossing point; and e. reporting (708) the autocorrelation constant and/or the autocorrelation level crossing point. [0192] Embodiment 2: The method of any of the previous embodiments wherein: the UE measures the autocorrelation for multiple autocorrelation lags, and based on these measurements it estimates and reports the constant k. [0193] Embodiment 3: The method of any of the previous embodiments wherein: the constant k is estimated through a least square fit to the measurements. [0194] Embodiment 4: The method of any of the previous embodiments wherein: the constant k is estimated through a weighted least square fit to the measurements. [0195] Embodiment 5: The method of any of the previous embodiments wherein: lower weights are used for measurements at higher autocorrelation lags to account for ℴ^ ! " deviations. [0196] Embodiment 6: The method of any of the previous embodiments wherein: measurements that are below a certain level are discarded before k is estimated in order to reduce the effect of ℴ^ ! " deviations. [0197] Embodiment 7: The method of any of the previous embodiments wherein: the UE converts a complex valued autocorrelation estimate #^ " to a real valued estimate $ %&' ^ " and estimates the constant k based on the resulting real valued autocorrelation estimate. [0198] Embodiment 8: The method of any of the previous embodiments wherein: measurements ($ %&' ^ " that are above a certain level are discarded before k is estimated in order to reduce the effect of ℴ^ ! " deviations. [0199] Embodiment 9: The method of any of the previous embodiments wherein: the UE measures and reports the autocorrelation for multiple autocorrelation lags to a network node and the network node estimates k based on the autocorrelation for multiple autocorrelation lags. [0200] Embodiment 10: The method of any of the previous embodiments wherein: using the k-value to make a decision on e.g., how to perform averaging/filtering of raw channel estimates. [0201] Embodiment 11: The method of any of the previous embodiments wherein: the UE measures the normalized autocorrelation for multiple autocorrelation lags and based on these measurements it estimates and reports the level crossing point for a certain autocorrelation level. [0202] Embodiment 12: The method of any of the previous embodiments wherein: reports the autocorrelation lag for which the normalized autocorrelation becomes smaller than the certain level. [0203] Embodiment 13: The method of any of the previous embodiments wherein: the UE operates in a Fifth Generation, 5G, communications network. [0204] Embodiment 14: The method of any of the previous embodiments, further comprising: providing user data; and forwarding the user data to a host via the transmission to the network node. [0205] Group B Embodiments [0206] Embodiment 15: A method performed by a network node for determining autocorrelation parameters, the method comprising one or more of: a. sending (800) configuration of reference signals that can be used for autocorrelation estimation; b. sending (802) configuration signaling to perform autocorrelation estimation and to estimate and report the autocorrelation constant or the autocorrelation level crossing point; c. transmitting (804) reference signals that can be used by the UE for autocorrelation estimation; d. receiving (806) the autocorrelation constant and/or the autocorrelation level crossing point; and e. using (808) the autocorrelation constant and/or autocorrelation level crossing point to make a decision. [0207] Embodiment 16: The method of any of the previous embodiments, wherein: the UE measures and reports the autocorrelation for multiple autocorrelation lags to a network node and the network node estimates k based on the autocorrelation for multiple autocorrelation lags. [0208] Embodiment 17: The method of any of the previous embodiments, wherein: the network uses the k-value to make a decision on one or more of: a. the number of additional DMRS symbols to configure; b. to use CSI feedback-based precoding or to use precoding based on SRS and reciprocity; c. to select one of several possible CSI feedback schemes; d. to select CSI-RS configuration parameters and CSI-feedback periodicity; and e. to decide the frequency granularity for precoding based on SRS and reciprocity. [0209] Embodiment 18: The method of any of the previous embodiments, wherein: the decision is made based on a threshold for the parameter k. [0210] Embodiment 19: The method of any of the previous embodiments, wherein: a hysteresis is used for the parameter k threshold. [0211] Embodiment 20: The method of any of the previous embodiments, wherein: the parameter k threshold depends on other information known by the network node such as e.g., radio channel characteristics. [0212] Embodiment 21: The method of any of the previous embodiments, wherein: the network calculates an estimate of the autocorrelation for some choice of autocorrelation lag as $ %&' ^ " = 1 − O ∙ ^ and use $ %&' ^ " to make the decision, e.g., using a threshold for $ %&' ^ " with or without hysteresis. [0213] Embodiment 22: The method of any of the previous embodiments wherein: the network node operates in a Fifth Generation, 5G, communications network. [0214] Embodiment 23: The method of any of the previous embodiments wherein: the network node comprises a gNB. [0215] Embodiment 24: The method of any of the previous embodiments, further comprising: obtaining user data; and forwarding the user data to a host or a user equipment. [0216] Group C Embodiments [0217] Embodiment 25: A user equipment for determining autocorrelation parameters, comprising: processing circuitry configured to perform any of the steps of any of the Group A embodiments; and power supply circuitry configured to supply power to the processing circuitry. [0218] Embodiment 26: A network node for determining autocorrelation parameters, the network node comprising: processing circuitry configured to perform any of the steps of any of the Group B embodiments; power supply circuitry configured to supply power to the processing circuitry. [0219] Embodiment 27: A user equipment (UE) for determining autocorrelation parameters, the UE comprising: an antenna configured to send and receive wireless signals; radio front-end circuitry connected to the antenna and to processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry; the processing circuitry being configured to perform any of the steps of any of the Group A embodiments; an input interface connected to the processing circuitry and configured to allow input of information into the UE to be processed by the processing circuitry; an output interface connected to the processing circuitry and configured to output information from the UE that has been processed by the processing circuitry; and a battery connected to the processing circuitry and configured to supply power to the UE. [0220] Embodiment 28: A host configured to operate in a communication system to provide an over-the-top (OTT) service, 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, the communication interface and processing circuitry of the UE being configured to perform any of the steps of any of the Group A embodiments to receive the user data from the host. [0221] Embodiment 29: The host of the previous embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit the user data to the UE from the host. [0222] Embodiment 30: The host of the previous 2 embodiments, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the 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. [0223] Embodiment 31: A method implemented by a host operating in a communication system that further includes 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 of any of the Group A embodiments to receive the user data from the host. [0224] Embodiment 32: The method of the previous embodiment, further comprising: at the host, executing a host application associated with a client application executing on the UE to receive the user data from the UE. [0225] Embodiment 33: The method of the previous embodiment, further comprising: at the host, transmitting input data to the 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. [0226] Embodiment 34: A host configured to operate in a communication system to provide an over-the-top (OTT) service, 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, the communication interface and processing circuitry of the UE being configured to perform any of the steps of any of the Group A embodiments to transmit the user data to the host. [0227] Embodiment 35: The host of the previous embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit the user data from the UE to the host. [0228] Embodiment 36: The host of the previous 2 embodiments, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the 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. [0229] Embodiment 37: A method implemented by a host configured to operate in a communication system that further includes a network node and a user equipment (UE), the method comprising: at the host, receiving user data transmitted to the host via the network node by the UE, wherein the UE performs any of the steps of any of the Group A embodiments to transmit the user data to the host. [0230] Embodiment 38: The method of the previous embodiment, further comprising: at the host, executing a host application associated with a client application executing on the UE to receive the user data from the UE. [0231] Embodiment 39: The method of the previous embodiment, further comprising: at the host, transmitting input data to the 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. [0232] Embodiment 40: A host configured to operate in a communication system to provide an over-the-top (OTT) service, 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 communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the Group B embodiments to transmit the user data from the host to the UE. [0233] Embodiment 41: The host of the previous embodiment, wherein: the processing circuitry of the host is configured to execute a host application that provides the user data; and the UE comprises processing circuitry configured to execute a client application associated with the host application to receive the transmission of user data from the host. [0234] Embodiment 42: A method implemented in a host configured to operate in a communication system that further includes 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 network node performs any of the operations of any of the Group B embodiments to transmit the user data from the host to the UE. [0235] Embodiment 43: The method of the previous embodiment, further comprising, at the network node, transmitting the user data provided by the host for the UE. [0236] Embodiment 44: The method of any of the previous 2 embodiments, wherein the user data is provided at the host by executing a host application that interacts with a client application executing on the UE, the client application being associated with the host application. [0237] Embodiment 45: A communication system configured to provide an over-the-top service, the communication system comprising: a 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 toward a cellular network node for transmission to the UE, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the Group B embodiments to transmit the user data from the host to the UE. [0238] Embodiment 46: The communication system of the previous embodiment, further comprising: the network node; and/or the user equipment. [0239] Embodiment 47: A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to initiate receipt of user data; and a network interface configured to receive the 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 of any of the Group B embodiments to receive the user data from a user equipment (UE) for the host. [0240] Embodiment 48: The host of the previous 2 embodiments, wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the 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. [0241] Embodiment 49: The host of the any of the previous 2 embodiments, wherein the initiating receipt of the user data comprises requesting the user data. [0242] Embodiment 50: A method implemented by a host configured to operate in a communication system that further includes a network node and a user equipment (UE), the method comprising: at the host, initiating receipt of user data from the UE, the user data originating from a transmission which the network node has received from the UE, wherein the network node performs any of the steps of any of the Group B embodiments to receive the user data from the UE for the host. [0243] Embodiment 51: The method of the previous embodiment, further comprising at the network node, transmitting the received user data to the host. [0244] At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s). • 3GPP Third Generation Partnership Project • 5G Fifth Generation • 5GC Fifth Generation Core • 5GS Fifth Generation System • AF Application Function • AMF Access and Mobility Function • AN Access Network • AP Access Point • ASIC Application Specific Integrated Circuit • AUSF Authentication Server Function • CPU Central Processing Unit • CSI Channel State Information • CSI-RS Channel State Information Reference Signal • DMRS Demodulation Reference Signal • DN Data Network • 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 Radio Base Station • gNB-DU New Radio 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 Exposure Function • NF Network Function • NR New Radio • NRF Network Function Repository Function • NSSF Network Slice Selection Function • 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 • RRH Remote Radio Head • RTT Round Trip Time • SCEF Service Capability Exposure Function • SMF Session Management Function • SRS Sounding Reference Signal • UDM Unified Data Management • UE User Equipment • UPF User Plane Function [0245] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.