Patent Description:
An example of a cellular communication system is an architecture that is being standardized by the <NUM>rd Generation Partnership Project (3GPP). A recent development in this field is often referred to as the long-term evolution (LTE) of the Universal Mobile Telecommunications System (UMTS) radio-access technology. E-UTRA (evolved UMTS Terrestrial Radio Access) is the air interface of 3GPP's Long Term Evolution (LTE) upgrade path for mobile networks. In LTE, base stations or access points (APs), which are referred to as enhanced Node B (eNBs), provide wireless access within a coverage area or cell. In LTE, mobile devices, or mobile stations are referred to as user equipments (UE). LTE has included a number of improvements or developments. Aspects of LTE are also continuing to improve.

<NUM> New Radio (NR) development is part of a continued mobile broadband evolution process to meet the requirements of <NUM>, similar to earlier evolution of <NUM> & <NUM> wireless networks. <NUM> is also targeted at the new emerging use cases in addition to mobile broadband. A goal of <NUM> is to provide significant improvement in wireless performance, which may include new levels of data rate, latency, reliability, and security. <NUM> NR may also scale to efficiently connect the massive Internet of Things (IoT) and may offer new types of mission-critical services. For example, ultra-reliable and low-latency communications (URLLC) devices may require high reliability and very low latency.

Document <CIT> discloses a method for reporting channel information by a user equipment.

The details of one or more examples of embodiments are set forth in the accompanying drawings and the description below.

<FIG> is a block diagram of a wireless network <NUM> according to an example embodiment. In the wireless network <NUM> of <FIG>, user devices <NUM>, <NUM>, <NUM> and <NUM>, which may also be referred to as mobile stations (MSs) or user equipment (UEs), may be connected (and in communication) with a base station (BS) <NUM>, which may also be referred to as an access point (AP), an enhanced Node B (eNB), a BS, next generation Node B (gNB), a next generation enhanced Node B (ng-eNB), or a network node. The terms user device and user equipment (UE) may be used interchangeably. A BS may also include or may be referred to as a RAN (radio access network) node, and may include a portion of a BS or a portion of a RAN node, such as (e.g., such as a centralized unit (CU) and/or a distributed unit (DU) in the case of a split BS). At least part of the functionalities of a BS (e.g., access point (AP), base station (BS) or (e)Node B (eNB), BS, RAN node) may also be carried out by any node, server or host which may be operably coupled to a transceiver, such as a remote radio head. BS (or AP) <NUM> provides wireless coverage within a cell <NUM>, including to user devices (or UEs) <NUM>, <NUM>, <NUM> and <NUM>. Although only four user devices (or UEs) are shown as being connected or attached to BS <NUM>, any number of user devices may be provided. BS <NUM> is also connected to a core network <NUM> via a S1 interface or NG interface <NUM>. This is merely one simple example of a wireless network, and others may be used.

A base station (e.g., such as BS <NUM>) is an example of a radio access network (RAN) node within a wireless network. A BS (or a RAN node) may be or may include (or may alternatively be referred to as), e.g., an access point (AP), a gNB, an eNB, or portion thereof (such as a centralized unit (CU) and/or a distributed unit (DU) in the case of a split BS or split gNB), or other network node.

According to an illustrative example, a BS node (e.g., BS, eNB, gNB, CU/DU,. ) or a radio access network (RAN) may be part of a mobile telecommunication system. A RAN (radio access network) may include one or more BSs or RAN nodes that implement a radio access technology, e.g., to allow one or more UEs to have access to a network or core network. Thus, for example, the RAN (RAN nodes, such as BSs or gNBs) may reside between one or more user devices or UEs and a core network. According to an example embodiment, each RAN node (e.g., BS, eNB, gNB, CU/DU,. ) or BS may provide one or more wireless communication services for one or more UEs or user devices, e.g., to allow the UEs to have wireless access to a network, via the RAN node. Each RAN node or BS may perform or provide wireless communication services, e.g., such as allowing UEs or user devices to establish a wireless connection to the RAN node, and sending data to and/or receiving data from one or more of the UEs. For example, after establishing a connection to a UE, a RAN node (e.g., BS, eNB, gNB, CU/DU,. ) may forward data to the UE that is received from a network or the core network, and/or forward data received from the UE to the network or core network. RAN nodes (e.g., BS, eNB, gNB, CU/DU,. ) may perform a wide variety of other wireless functions or services, e.g., such as broadcasting control information (e.g., such as system information) to UEs, paging UEs when there is data to be delivered to the UE, assisting in handover of a UE between cells, scheduling of resources for uplink data transmission from the UE(s) and downlink data transmission to UE(s), sending control information to configure one or more UEs, and the like. These are a few examples of one or more functions that a RAN node or BS may perform. A base station may also be DU (Distributed Unit) part of IAB (Integrated Access and Backhaul) node (a. a relay node). DU facilitates the access link connection(s) for an IAB node.

A user device (user terminal, user equipment (UE), mobile terminal, handheld wireless device, etc.) may refer to a portable computing device that includes wireless mobile communication devices operating either with or without a subscriber identification module (SIM), including, but not limited to, the following types of devices: a mobile station (MS), a mobile phone, a cell phone, a smartphone, a personal digital assistant (PDA), a handset, a device using a wireless modem (alarm or measurement device, etc.), a laptop and/or touch screen computer, a tablet, a phablet, a game console, a notebook, a vehicle, a sensor, and a multimedia device, as examples, or any other wireless device. It should be appreciated that a user device may also be (or may include) a nearly exclusive uplink only device, of which an example is a camera or video camera loading images or video clips to a network. A user device may be also MT (Mobile Termination) part of IAB (Integrated Access and Backhaul) node (a. a relay node). MT facilitates the backhaul connection for an IAB node.

In LTE (as an illustrative example), core network <NUM> may be referred to as Evolved Packet Core (EPC), which may include a mobility management entity (MME) which may handle or assist with mobility/handover of user devices between BSs, one or more gateways that may forward data and control signals between the BSs and packet data networks or the Internet, and other control functions or blocks. Other types of wireless networks, such as <NUM> (which may be referred to as New Radio (NR)) may also include a core network.

In addition, by way of illustrative example, the various example embodiments or techniques described herein may be applied to various types of user devices or data service types, or may apply to user devices that may have multiple applications running thereon that may be of different data service types. New Radio (<NUM>) development may support a number of different applications or a number of different data service types, such as for example: machine type communications (MTC), enhanced machine type communication (eMTC), Internet of Things (IoT), and/or narrowband IoT user devices, enhanced mobile broadband (eMBB), and ultra-reliable and low-latency communications (URLLC). Many of these new <NUM> (NR) - related applications may require generally higher performance than previous wireless networks.

IoT may refer to an ever-growing group of objects that may have Internet or network connectivity, so that these objects may send information to and receive information from other network devices. For example, many sensor type applications or devices may monitor a physical condition or a status, and may send a report to a server or other network device, e.g., when an event occurs. Machine Type Communications (MTC, or Machine to Machine communications) may, for example, be characterized by fully automatic data generation, exchange, processing and actuation among intelligent machines, with or without intervention of humans. Enhanced mobile broadband (eMBB) may support much higher data rates than currently available in LTE.

Ultra-reliable and low-latency communications (URLLC) is a new data service type, or new usage scenario, which may be supported for New Radio (<NUM>) systems. This enables emerging new applications and services, such as industrial automations, autonomous driving, vehicular safety, e-health services, and so on. 3GPP targets in providing connectivity with reliability corresponding to block error rate (BLER) of <NUM>-<NUM> and up to <NUM> U-Plane (user/data plane) latency, by way of illustrative example. Thus, for example, URLLC user devices/UEs may require a significantly lower block error rate than other types of user devices/UEs as well as low latency (with or without requirement for simultaneous high reliability). Thus, for example, a URLLC UE (or URLLC application on a UE) may require much shorter latency, as compared to an eMBB UE (or an eMBB application running on a UE).

The various example embodiments may be applied to a wide variety of wireless technologies or wireless networks, such as LTE, LTE-A, <NUM> (New Radio (NR)), cmWave, and/or mmWave band networks, IoT, MTC, eMTC, eMBB, URLLC, NR sidelink communications, etc., or any other wireless network or wireless technology. These example networks, technologies or data service types are provided only as illustrative examples.

A UE may be configured to measure one or more signal parameters or quantities, and then send a measurement report(s) to the network node (e.g., gNB or BS). In an example embodiment, a network node (e.g., gNB or BS) may send a report configuration to a UE, e.g., to cause the UE to carry out signal or radio measurements and reporting of these measurements to the gNB. The report configuration may indicate, e.g., downlink resources on which measurements should be carried out, a quantity or set of quantities to be reported, and/or how often the reporting should be performed (e.g., on demand by the gNB, or periodic reporting, or other reporting condition). In an example embodiment, a UE may be configured to measure a reference signal received power (RSRP) or a channel state information (CSI) based on channel state information-reference signal (CSI-RS) beams and/or synchronization signal blocks (SSBs) beams.

RSRP reports (reports of measured RSRP values from a UE) may, for example, be used (or useful) for a number of different applications or procedures of a network node or by the core network. For example, RSRP values may be used by a radio resource measurement (RRM) function or procedures, or other application, e.g., implemented at the network node, for example. Some of these applications (e.g., RRM procedures and other applications) may be used to adjust or assist with network operation, and/or or improve various aspects of network operation, based on varying or changing channel conditions (e.g., as reflected by the RSRP values reported to the gNB). For example, RRM procedures may include determining a location of a UE, or performing a cell change or UE handover for UE multi-connectivity. A number of RRM procedures may use or may rely upon RSRP reports. For example, an A3 condition, causing the UE to send a RSRP report to the serving gNB, may be triggered when a RSRP value of a neighbor cell/neighbor gNB is, for example, at least a threshold better than a RSRP of the serving cell/serving gNB. Thus, for example, RSRP values may be used to assist in (and useful for) performing cell change or handover decisions for a UE, as some examples. There are a number of other RRM procedures that may use RSRP values (RSRP reports) from UEs to improve or adjust network operation for various nodes or cells.

Furthermore, in an example embodiment, artificial intelligence (AI)/machine learning (ML) techniques (e.g., which may be referred to as AI/ML-neural networks or ML model(s)) may be used to assist or improve various aspects of network operation or network performance, such as radio network management, fault detection, failure monitoring, intrusion detection, channel encoding/decoding, channel estimation/prediction, resource allocation/scheduling, mobility optimization (e.g., improving UE cell change or UE handover), etc. For best performance, such models and/or other network-related applications (e.g., RRM applications or procedures) may be based on a significant amount and/or a steady flow of data (such as RSRP values reported by UEs).

The current reporting of RSRP values, for some situations, may not be adequate for at least some network-related applications, procedures or ML models. There may be a number of drawbacks or disadvantages with respect to the RSRP values and/or the manner in which measured RSRP values are currently reported by UEs to gNBs/BSs, such as, for example: <NUM>) RSRP reports are based on measurement values that are averaged over time, and often times reported by the UE irregularly and/or infrequently. RSRP values are typically averaged over an extended period of time, e.g., which may be hundreds of milliseconds, for example. Also, in some cases, a RSRP report from a UE may be triggered (e.g., caused to be transmitted by the UE) only for specific conditions, such as an A3 handover or cell change condition in which a neighbor cell RSRP is better (stronger) by more than a threshold of the RSRP of the serving cell, as an example. Also, the filtering of RSRP values, or transmission of RSRP reports to a gNBBS only for certain conditions or events, significantly reduces signaling overhead for RSRP reports. However, by decreasing the RSRP report overhead, this also significantly decreases the amount of RSRP values that are available for various network-related applications, procedures and/or ML models. <NUM>) There may be RSRP value inaccuracies or inconsistencies. For example, the actual accuracy of the radio measurements (measurement of RSRP values, for example) may depend on implementation specific physical layer solutions used in each UE (e.g., channel estimation, beam tracking). Information on implementation of the RSRP estimation algorithm and its accuracy may typically be UE chipset vendor specific, for example. These factors may contribute, at least in some situations, to a decrease in reliability and/or accuracy of RSRP values.

Thus, for example, an irregular reporting of RSRP values based on averaging, RSRP value inconsistencies among different UE equipment vendors, and/or other factors, may, at least in some cases, result in an inadequate quality (e.g., reliability and/or accuracy) and/or quantity/frequency of reported RSRP values. Such issues or limitations on RSRP reports may, at least in some cases, limit or inhibit operation of one or more network-related applications, procedures (e.g., RRM procedures) or ML models that may rely on RSRP data to assist with network operation or to improve or adjust parameters or features of one or more nodes within a network. UEs could be configured to more frequently report RSRP values. However, significantly increasing the frequency of RSRP reports may result in increased signaling overhead, and therefore, may not be a preferred option to increase the quality and/or quantity of RSRP reports, at least in some cases.

As noted, a UE may be configured to measure a parameter(s) of a reference signal, such as to determine a channel state information (CSI) based on channel state information-reference signal (CSI-RS) beams and/or synchronization signal blocks (SSBs) beams. CSI reports may be periodic or triggered (by the gNB), and can be wideband (e.g., based on all PRBs (physical resource blocks) of a frequency band) or sub-band (based on a subset of PRBs or specific PRBs) An example CSI report may include, for example, one or more of: a Rank Indicator (RI), providing a recommendation on a transmission rank to use, or a number of layers that should be used for downlink communication with the user device/UE; a Precoder Matrix Indicator (PMI), which may indicate a preferred or suggested precoder to use for downlink communication with the user device, e.g., based on the suggested RI; and a Channel Quality Indicator (CQI) that indicates a highest modulation and coding scheme (MCS) that is suggested for downlink communication with the user device/UE, e.g., based on the selected PMI and RI. In general, precoding may include a node (e.g., BS or gNB) applying a set of precoding weights (each weight including amplitude and/or phase) to a signal or to an antenna (e.g., in order to change the amplitude and/or phase of a transmitted signal), for example, based on the qualities of a channel between the UE and the BS or network node. In an example embodiment, a CSI report (or CSI measurement report) sent by a UE may include one or more of a RI, PMI and/or CQI.

The CSI report may be transmitted by a UE to a gNBBS via a physical uplink control channel (PUCCH) resources allocated to the UE. Alternatively, if a UE has an uplink (UL) grant (e.g., dynamic grant or configured grant) via a physical uplink shared channel (PUSCH), then the UE may (e.g., in addition to transmitting data) may transmit (e.g., or may multiplex) the CSI report via some of the resources of the PUSCH channel. Thus, for example, transmitting a CSI report to a gNBBS may be performed fairly frequently or regularly (e.g., via PUCCH resources that are allocated to each UE, or via PUSCH whenever the UE has an UL grant), using resources that have already been granted or allocated to the UE, which may not typically result in a significant increase in signaling overhead (as the PUCCH and/or PUSCH resources have already been allocated to the UE). RSRP reports may be transmitted via radio resource control (RRC) message/signaling, e.g., from a RRC entity of a UE to a corresponding RRC entity provided at a gNB (or to a RRC entity provided at a centralized unit (CU/gNB-CU) where the gNB is provided with a split architecture including a gNB-CU and at least one gNB-DU). As noted above, RSRP reports are not typically reported on a frequent or regular basis, and doing so may have the drawback of significantly increasing signaling overhead (and may require additional resources) for the UE and/or gNB/BS.

However, it has been determined that a significant correlation exists between CQI values and RSRP values. As noted, a CQI value may be a Channel Quality Indicator (CQI) that indicates a highest (or suggested) modulation and coding scheme (MCS) that is suggested for downlink communication with the user device/UE. The CQI may be determined by the UE based on received DL signals received by the UE from the gNB/BS, such as based on channel state information-reference signal (CSI-RS) beams and/or synchronization signal blocks (SSBs) beams, for example.

For example, live radio measurements were performed within a 3GPP network for RSRP values and CQI values (for multiple cells), and the Pearson correlation coefficient was calculated for CQI and RSRP values. The Pearson correlation coefficient may provide a measure of the linear correlation between two variables X and Y, and may, for example, be defined as: <MAT> Where r is the Pearson correlation coefficient,.

The Pearson correlation coefficient is a test statistic that measures the statistical relationship, or association (or correlation), between two variables. It provides information about the magnitude of the association, or correlation, as well as the direction of the relationship. Pearson correlation coefficient has a value between +<NUM> and -<NUM>, where +<NUM> is total positive linear correlation, <NUM> is no linear correlation, and -<NUM> is total negative linear correlation.

Based on radio (e.g., RSRP and CQI) measurements for a group of cells (e.g., <NUM> cells in this specific experiment), the Pearson's correlation coefficient metric was calculated indicating the relationship (correlation) between CQI and RSRP measurements based on a real data set collected from the network. The Pearson's correlation coefficient is first performed over the whole set including <NUM> cells and shows that the CQI is highly correlated to the RSRP (with an average Pearson's correlation coefficient of +<NUM> among the <NUM> cells, in this field experiment). Thus, from a statistical point of view, there is a strong correlation between CQI and RSRP.

Focusing on a single cell measurement, for example, at least for some cells, this correlation was even higher, (the Pearson correlation coefficient is <NUM> for one of the cells). This high correlation, and even the average Pearson correlation coefficient of +<NUM>, indicates that supervised learning (or ML model, AI neural network (NN), etc.) may be used in order to predict RSRP values as function of CQI values, for example. To this end, an example of a feedforward neural network was tested. However, other NN based architectures or ML models may be used as well such as recurrent NN where time series inputs are considered. For each cell, dataset is split into <NUM>% to perform the training of the NN model and <NUM>% to test the performance. The prediction error is estimated with root mean square error measure: <MAT>.

Table <NUM> shows results for <NUM> cells, where the Pearson correlation coefficient varies from. <NUM>, which indicates a strong positive correlation between CQI values and RSRP values. Other values or measurements of a CSI report (e.g., the rank indicator (RI) values and/or a precoder matrix indicator (PMI) values, in addition to the CQI) may also have a positive correlation with RSRP values.

Therefore, according to an example embodiment, a network node (e.g., BS or gNB) may determine a plurality of estimated reference signal received power (RSRP) values based at least on a plurality of channel state information (CSI) values reported by a UE/user device (e.g., where each of the CSI values may include a CQI, RI and/or a PMI). For example, each of the reported CSI values may include at least a CQI value reported by the UE (RI and PMI may also be included in the CSI report). In an example embodiment, the network node may determine a plurality of estimated RSRP values based at least on a plurality of CQI values reported by a UE/user device, e.g., which is made possible, or may be based upon, the strong positive correlation between CQI values and RSRP values, as explained above. Also, in an example embodiment, a network node (e.g., BS or gNB), or other node or device, may determine a plurality of estimated RSRP values based at least on a plurality of channel state information (CSI) values reported by a UE and a plurality of measured RSRP values that were measured and reported by the UE.

Thus, for example, a method or technique may include determining a plurality of estimated RSRP values that have been estimated based at least on the plurality of CSI values reported by a UE and a plurality of measured RSRP values reported by the UE. For example, a set of rules, and/or a model (e.g., a model, which may be referred to as a machine learning (ML) model, or an AI/ML neural network) may be trained based on training data, and then used to determine a plurality of estimated RSRP values. Thus, for example, the model may be trained based on a plurality of CSI values (e.g., including CQI values) that were reported by a UE, and a plurality of corresponding measured RSRP values reported by the UE. For example, the reported CSI values may be corresponding to the RSRP values reported by the UE, e.g., where corresponding may mean that these (at least some of these) corresponding CSI values and RSRP values may be within a same limited period of time (since channel conditions for a UE may change over time) and/or may be for or from the same UE. For example, the strong positive correlation between reported RSRP values and reported CQI values may be due to these values being measured or determined for a same UE-BS channel conditions, within a limited period of time, e.g., since such channel may change over time. Also, a set of corresponding RSRP values and reported CQI values may be provided, and used for training the model, for a plurality of UEs, at least in some cases.

Once a ML model (e.g., which may also be referred to as an AI/ML neural network) has been trained, e.g., based on reported CSI (e.g., including CQI) values and/or reported RSRP values, then subsequent data and/or live data (e.g., reported CSI (e.g., including CQI) values and reported RSRP values) may be used as inputs, to determine a plurality of estimated RSRP values, based on the ML model.

<FIG> is a block diagram illustrating a neural network (or machine learning) based system for estimating reference signal received power (RSRP) values according to an example embodiment. As shown in the example embodiment of <FIG>, a machine learning model <NUM> (or AI/ML neural network) may be trained by ML model training block <NUM>, e.g., based on training data received via lines <NUM> and <NUM>, including downlink (DL) channel state information (CSI) values reported by a UE via line <NUM>, and RSRP values measured and reported by the UE via line <NUM>. Based on this training data, the ML model training block <NUM> may train the ML model <NUM>, e.g., to determine (or estimate) estimated RSRP values based on reported RSRP values and reported CSI (e.g., CQI) values. For example, there may be certain reported RSRP values that typically occur or coincide with certain reported CQI values, and the training of the ML model <NUM> may involve the ML model learning how to determine or estimate RSRP values based on reported CSI values (e.g., reported CQI values) and possibly some (e.g., less frequent) reported RSRP values. The training data (which may be input to the ML model training block <NUM> to train ML model <NUM>), may include some reported CQI/CSI values that may correspond to some reported RSRP values, e.g., wherein for at least some of the training data, the reported CSI values and reported RSRP values used for training may be reported from a same UE and/or may be provided (or measured) for a same or similar time period, for example. Also, for example, training may be repeated or performed from time to time, periodically, or when new data is available, e.g., to update ML model <NUM>. A time or clock (time/clock) input <NUM> may be input to ML model training block <NUM>, e.g., so that the ML model training block <NUM> can, e.g., identify reported CSI/CQI values that correspond to (e.g., at around the same time, or within a same limited time period as) one or more measured RSRP values. Thus, the time/clock input <NUM> may allow the ML model training to train the ML model <NUM>, e.g., based on CSI/CQI reports that correspond (e.g., correspond in time, or are provided or reported within the same limited period of time) to one or more measured RSRP values reported by the UE.

The source of RSRP measurements input can be either RSRP reports from the UEs, or alternatively may be Immediate MDT reports. Also, for example, the ML model training block <NUM> can use other inputs as well, depending on the example implementation, such as, for example: pre-labelled reference RSRP values (e.g., determined with high accuracy), time stamps for the input RSRP and /or CSI/CQI values, and/or other UE context information, such as velocity, mobility state, etc..

The trained ML model (<NUM>) may be provided to a ML model RSRP estimation block <NUM>. The ML model RSRP estimation block <NUM> may be provided at (or as part of) a same or a different entity or node as the ML model training block <NUM>. ML model RSRP estimation block <NUM> may receive as inputs some subsequent data or live data, for example, which may include one or more measured RSRP values measured and reported by the UE and input to ML model RSRP estimation block <NUM> via line <NUM>, and CSI values (e.g., CQI values) reported by the UE and input to ML model RSRP estimation block via line <NUM>. After the ML model <NUM> has been trained (e.g., by ML model training block <NUM>), ML model RSRP estimation block <NUM> may determine a plurality of estimated RSRP values that are estimated based at least on the plurality of channel state information (CSI) (or CQI) values reported by the UE/user device (e.g., received as an input via line <NUM>), based on the trained ML model <NUM>. Alternatively, the ML model estimation block <NUM> may determine a plurality of estimated RSRP values that are estimated based at least on the plurality of CSI values reported by the UE/user device (e.g., received as an input via line <NUM>) and the one or more measured RSRP values reported by the UE (e.g., received as an input via line <NUM>), based on the trained ML model <NUM>. The time/clock input <NUM> to ML model RSRP estimation block <NUM> may allow, for example, estimated RSRP values to be output via line <NUM> (e.g., at specific time instances, or having a specific sequence of estimated values).

The plurality of estimated RSRP values, determined by ML model RSRP estimation block <NUM>, may be output via line <NUM> to a RSRP sequence output generator and Type indication generator <NUM> (which may simply be referred to as generator <NUM>). Also, generator <NUM> may receive, as further inputs, one or more measured RSRP values reported by the UE, and then input to generator <NUM> via line <NUM>. Thus, generator <NUM> may receive, as inputs, two types of RSRP values, including: measured and reported RSRP values (via line <NUM>), and estimated RSRP values (e.g., which were estimated based at least on CSI or CQI values, based on the trained ML model) via line <NUM>. A time/clock input <NUM> to generator <NUM> may indicate a time or timing of one or more of the measured RSRP values reported by the UE (input via line <NUM>) and/or a time or timing of one or more of the estimated RSRP values received via line <NUM>, e.g., so that the generator <NUM> may know or determine a time, and/or time order, of the measured RSRP values and the measured RSRP values. The time/clock <NUM> may also be used to estimate a model error afterwards (to be able to determine the correspondence (e.g., in time, such as same time, or within a time window or time threshold) between measured RSRP values and estimated RSRP values, and thus, allow the system to determine an error or difference between these measured and reported RSRP values, for example).

The generator <NUM> may output a sequence (e.g., a time-series sequence, or a regularly spaced time sequence) of RSRP values via line <NUM>, which may include, e.g., a combination of both the plurality of estimated RSRP values and at least one (or even a plurality) of the measured RSRP values reported by the UE. Thus, for example, while the actual measured and reported RSRP values may be infrequent and/or irregular in time, the determining of estimated RSRP values (e.g., based at least on CSI or CQI values) may allow the generator <NUM> to output a sequence of RSRP values that may be, e.g., evenly or regularly spaced (e.g., a RSRP value every time period), or substantially even spaced sequence of RSRP values (e.g., a RSRP value every x ms within a threshold of y ms, such as output a RSRP value every <NUM>, plus or minus <NUM>), or at least which may provide more frequent RSRP values, as compared to the measured and reported RSRP values. Thus, for example, generator <NUM> may output, via line <NUM>, a sequence of RSRP values that include measured RSRP values, and also one or more estimated RSRP values in the time gaps between successive measured RSRP values.

In addition, generator <NUM> may also output (e.g., via line <NUM>) a Type indication that indicates, for one or more of the output RSRP values (e.g., RSRP values output via line <NUM>), whether the output RSRP value is a measured RSRP value that was reported by the UE, or an estimated RSRP value.

<FIG> is a block diagram of a gNB having a split architecture according to an example. A gNB (network node) <NUM> may be connected to core network <NUM> via NG interface. gNB <NUM> may include a centralized unit (gNB-CU) <NUM>, and one or more distributed units (gNB-DUs) <NUM>, <NUM>. gNB-DUs <NUM> and <NUM> are each connected to (or in communication with) gNB-CU <NUM> via F1 interfaces, for example.

<FIG> is a block diagram of a system to perform model training and then to determine reference signal received power (RSRP) estimated values based on a trained model according to an example embodiment. As noted above, a gNB may, for example, be provided as a split architecture with one centralized unit (CU), and one or multiple distributed units (DUs). In an example embodiment, the radio resource control (RRC) entity of the gNB may be located at the CU. One function of the RRC entity is to receive and process RSRP values reported by a UE (RRC protocol entity of CU receives RSRP values from a RRC counterpart protocol entity at the UE). The CSI (e.g., CQI, RI, PMI) values may be received by a DU, and stored in the DU. According to an example embodiment, a gNB distributed unit (DU) <NUM> is shown in <FIG>. In this illustrative example, both the ML model training block <NUM> and the ML model RSRP estimation block <NUM> are provided within or as part of the DU <NUM>. The ML model <NUM> (<FIG>) may also be stored on or within the DU <NUM>, or may be stored at other location, or on other device or system outside the RAN. Thus, in this illustrative example shown in <FIG>, the gNB-DU <NUM> includes (or may include) the ML model training block <NUM>, the ML model RSRP estimation block <NUM>, and the ML model <NUM>.

As shown in <FIG>, UEx RSRP measurement reports <NUM>, indicating or including RSRP values measured by a UEx and reported to the gNB-CU, are input via line <NUM> through the F1 interface to ML model training block <NUM>, and also possibly (in an example embodiment) input via line 313A to ML model RSRP estimation block <NUM>. Also, DL CSI values <NUM> (e.g., which may include CQI values), which are measured and reported by the UEx to DU <NUM>, are input via line <NUM> to both ML model training <NUM> and ML model RSRP estimation block <NUM>. Similar to <FIG>, ML model <NUM> is connected to, or in communication with, both ML model training block <NUM> and ML model RSRP estimation block <NUM> (although the connection between ML model training block <NUM> and ML model <NUM> is not shown in <FIG>).

ML model training <NUM> may perform training of the ML model <NUM>, e.g., based on measured RSRP values <NUM> reported by UEx to the CU, which are forwarded to the DU, and based on CSI values <NUM> (e.g., including CQI values) measured and reported by the UEx to the DU <NUM>. The ML model <NUM> and any ML parameters may be provided by ML model training block <NUM> to the ML model RSRP estimation block <NUM>. Block <NUM> may receive a control signal input <NUM> from gNB-CU indicating if there is a RSRP report available. Block <NUM> may notify (via control signal indicated on line <NUM>) the ML model RSRP estimation block <NUM> if there are any available UE RSRP measurement reports. If there are RSRP reports available, these RSRP reports (measured RSRP values) may be received by ML model RSRP estimation block <NUM> via line 313A, or via other input (not shown). Block <NUM> may also indicate via line <NUM> to block <NUM> that there are no available UE RSRP measurement reports. Also, block <NUM> may confirm via line <NUM> to ML model RSRP estimation block <NUM> that retraining of the ML model <NUM> is not necessary right now. If there are UE RSRP measurement reports available, and, e.g., if retraining of the ML model <NUM> is not required (e.g., ML model RSRP estimation block <NUM> is currently operating with sufficient accuracy or performance level), then the ML model RSRP estimation block <NUM> may determine a plurality of estimated RSRP values, based on the received inputs <NUM>, <NUM>. In the event there are no available UE RSRP measurement reports, block <NUM> may perform a ML model RSRP estimation accuracy estimation, e.g., by comparing one or more estimated RSRP values to actual (measured) RSRP values, and determining an error, or an average error, or other performance measurement. When such error exceeds a threshold (or when performance of block <NUM> degrades to below a threshold level), this may trigger an output via line <NUM> from block <NUM> to cause block <NUM> to trigger or cause, via line <NUM> a retraining of ML model <NUM> to be performed. Thus, the <NUM>-<NUM>-<NUM> chain indicates that when no input RSRP values are available, the block <NUM> monitors the output accuracy and triggers re-training of ML model <NUM> if needed.

In an example embodiment, the ML model RSRP estimation block <NUM> may output, via line <NUM>, a sequence of RSRP values that may include the plurality of estimated RSRP values. Alternatively, the ML model RSRP estimation block <NUM> may output a sequence of RSRP values that includes both the plurality of estimated RSRP values and one or more of the measured RSRP values that were reported by the UEx. The output of the ML model RSRP estimation block <NUM> may also include the Type indication that indicates, for one or more output RSRP values, whether the output RSRP values is a measured RSRP value or an estimated RSRP value. For example, the measured RSRP values may be considered more accurate than the estimated RSRP values, and/or any application or ML models using or relying on RSRP values as inputs may place a higher confidence level on the measured RSRP values, and a lower confidence level on the estimated RSRP values. The output of RSRP values from ML model RSRP estimation block <NUM> may be input to a gNB-DU RRM (radio resource measurement) application or procedure <NUM>, and to one or more applications or algorithms, e.g., ML-based algorithms <NUM> that may use or rely on the sequence of output RSRP values as input.

<FIG> is a diagram illustrating example inputs and outputs for reference signal received power (RSRP) value estimation according to an example embodiment. As shown in <FIG>, a ML model RSRP estimation block <NUM> may receive as inputs, signals <NUM> and <NUM>. As shown, UEx RSRP measurement reports <NUM>, indicating or including RSRP values measured by a UEx and reported to the gNB-CU, and DL CSI values <NUM> (e.g., which may include CQI values), which are measured and reported by the UEx, are input to ML model RSRP estimation block <NUM>. For example, the measured RSRP values <NUM>, reported by the UEx, may include UEx measured RSRP values <NUM>, <NUM> and <NUM>, for example. Also as shown, the reported CSI/CQI values <NUM> reported by the UEx may include a group or set of CSI (e.g., CQI) values <NUM>.

In an example embodiment, ML model RSRP estimation block <NUM> may determine a plurality of estimated RSRP values, based on the received inputs <NUM>, <NUM>. The ML model RSRP estimation block <NUM> may output a sequence of RSRP values that may include a plurality of estimated RSRP values. In an example embodiment, the ML model RSRP estimation block <NUM> may output a sequence of RSRP values <NUM> that may include both one or more of the measured RSRP values (e.g., <NUM>, <NUM>, <NUM>,. ) and a plurality of estimated RSRP values (e.g., <NUM>, <NUM>, <NUM>,. Thus, for example, ML model RSRP estimation block may output a sequence of RSRP values including, for example (in the following time-series or time sequence), the RSRP values of <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc. As shown in the example output sequence <NUM> in <FIG>, some measured RSRP values may be output as part of the output sequence of RSRP values <NUM>. Also, in order to provide a sequence (e.g., a regularly spaced time sequence, within a threshold variation of time) or time-series of RSRP values, e.g., in which RSRP values may be output more frequently, and may be even be regularly spaced (e.g., an RSRP value output every x ms, within a time variation of y ms, such as an RSRP value output every <NUM>, plus or minus <NUM>), the output sequence of RSRP values may include measured RSRP values, and one or more estimated RSRP values that may be, for example, provided in the time gaps or intervals between successive output measured RSRP values, for example.

The output of the ML model RSRP estimation block <NUM> may also include a Type indication that indicates, for one or more output RSRP values, whether the output RSRP value is a measured RSRP value or an estimated RSRP value. For example, the Type indication may provide a signal as part of Type indication output <NUM>, corresponding to each output RSRP value of output sequence <NUM>, indicating whether the corresponding output RSRP value is a measured RSRP value or an estimated RSRP value.

As shown in <FIG>, the output sequence of RSRP values <NUM> may include the RSRP values of <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc. The Type indication output <NUM> may include the following Type indication signals of <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM>, which provide a Type indication for the RSRP output values of <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, respectively. For example, the output RSRP values of <NUM> and <NUM> may be indicated as measured RSRP values by their corresponding Type indications <NUM> and <NUM>, respectively. Similarly, the RSRP output values <NUM> and <NUM> may be indicated by their corresponding Type indication signals <NUM> and <NUM>, respectively, as being estimated RSRP values. This is just an illustrative example, and other types of Type indication signals or Type indications may be provided for this purpose. For example, another technique may be to only provide a Type indication signal for an output RSRP value if that RSRP value is measured. Other alternative signals may be used, e.g., a signal that indicates which output RSRP values are estimated, or a bit map that includes a bit for each RSRP value, wherein each bit may indicate whether the RSRP value is measured or estimated.

As noted above, in the example of <FIG>, a DU (gNB-DU) may include both the ML model training block <NUM> and the ML model RSRP estimation block <NUM>. In this case, the RSRP measurements would be signaled or forwarded by the CU to the DU.

In another example embodiment, a gNB centralized unit (CU) may include the ML model training block <NUM> and the ML model RSRP estimation block <NUM>. In this case, the CQI reports/CSI reports from the UE would be forwarded by the DU to the CU.

In another example embodiment, a gNB-DU may include the ML training block <NUM>, and a gNB-DU may include the ML model RSRP estimation block <NUM>.

Or, in another example embodiment, a gNB-CU may include the ML training block <NUM>, and a gNB-DU may include the ML model RSRP estimation block <NUM>. This configuration may reduce the need for high ML computation power/resources at the gNB-DU. The retraining may be performed at a much lower rate compared to normal RSRP estimation, and thus this configuration may reduce or mitigate a high signaling load due to forwarding of CSI/CQI reports.

In yet another embodiment, the ML model RSRP estimation block is provided at the gNB-DU, where the ML model RSRP estimation block is configured by the gNB-CU (E. , sampling period, time interval, UE transmission/reception mode), so that the RSRP and CQI measurements may be optimally and flexibly utilized.

In yet another embodiment, the ML model RSRP estimation block is provided at the gNB-DU, where the ML model RSRP estimation block is configured to use RSRP measurement reports and CQI/CSI feedback from one or more UEs identified by the gNB-CU or the core network (CN).

Or, in another embodiment, the ML training block and the ML model RSRP estimation block may be provided at an external node or device, such as a device in the cloud, or the core network, or other device.

The network may collect measurements (e.g., CSI/CQI measurements and RSRP measurements) from a plurality (e.g., a group associated) UEs, and then the ML model may be trained based on these measurements. Then, a plurality of estimated RSRP values may be determined based on the trained ML model and data (e.g., CQI values).

For example, the network can instruct a set of UEs to collect RSRP measurements by activating a Trace Session for instance to report Immediate Minimization for Drive Tests (MDT) data. In case of Immediate MDT, measurements could comprise RSRP measurements that are reported, when measured, from the UE to the network. In the Trace Configuration, the network can indicate the area in which the MDT data collection will take place. In an illustrative example, UEs in the specified area will be reporting measurements to the network. This is indicated through an optional parameter in the Trace Configuration, the "Area Scope" parameter. The Area Scope may support the PLMNs (public land mobile networks) of the MDT PLMN list. If Area Scope is not specified in the Configuration, the MDT data collection will be done in the PLMNs of the MDT PLMN list of the Trace Configuration. If Area Scope is specified, the network can narrow down the area in which measurements will be performed instead of per PLMN to a more refined region. For example, in UMTS the Area Scope parameter can be given through a list of cells, identified by Cell Global Identifier (CGI) with a maximum CGI of <NUM> being defined, a list of Routing Area (RA), identified by Routing Area Identification (RAI) with a maximum RAI of <NUM> being defined or a list of Location Area (LA), identified by Location Area Identification (LAI) with a maximum LAI of <NUM> being defined. In LTE and NR, the Area Scope can be given through a list of cells, identified by the E-UTRAN-CGI or NG-RAN CGI, with a maximum CGI value of <NUM> being defined, a list of tracking Area (TA) identified by a Tracking Area Code (TAC) with a maximum TAC value of <NUM> being defined or a list of Tracking Area Identity, identified by TAC with associated plmn-Identity per TAC-List containing the PLMN identity for each TAC and a maximum of <NUM> TAIs being defined.

<FIG> is a block diagram of a wireless station (e.g., AP, BS or user device/UE, or another network node) <NUM> according to an example embodiment. The wireless station <NUM> may include, for example, one or more (e.g., two as shown in <FIG>) RF (radio frequency) or wireless transceivers 1202A, 1202B, where each wireless transceiver includes a transmitter to transmit signals and a receiver to receive signals. The wireless station also includes a processor or control unit/entity (controller) <NUM> to execute instructions or software and control transmission and receptions of signals, and a memory <NUM> to store data and/or instructions.

Processor <NUM> may also make decisions or determinations, generate frames, packets or messages for transmission, decode received frames or messages for further processing, and other tasks or functions described herein. Processor <NUM>, which may be a baseband processor, for example, may generate messages, packets, frames or other signals for transmission via wireless transceiver <NUM> (1202A or 1202B). Processor <NUM> may control transmission of signals or messages over a wireless network, and may control the reception of signals or messages, etc., via a wireless network (e.g., after being down-converted by wireless transceiver <NUM>, for example). Processor <NUM> may be programmable and capable of executing software or other instructions stored in memory or on other computer media to perform the various tasks and functions described above, such as one or more of the tasks or methods described above. Processor <NUM> may be (or may include), for example, hardware, programmable logic, a programmable processor that executes software or firmware, and/or any combination of these. Using other terminology, processor <NUM> and transceiver <NUM> together may be considered as a wireless transmitter/receiver system, for example.

According to another example embodiment, RF or wireless transceiver(s) 1202A/1202B may receive signals or data and/or transmit or send signals or data. Processor <NUM> (and possibly transceivers 1202A/1202B) may control the RF or wireless transceiver 1202A or 1202B to receive, send, broadcast or transmit signals or data.

The embodiments are not, however, restricted to the system that is given as an example, but a person skilled in the art may apply the solution to other communication systems. Another example of a suitable communications system is the <NUM> system. It is assumed that network architecture in <NUM> will be quite similar to that of the LTE-advanced. <NUM> is likely to use multiple input - multiple output (MIMO) antennas, many more base stations or nodes than the LTE (a so-called small cell concept), including macro sites operating in co-operation with smaller stations and perhaps also employing a variety of radio technologies for better coverage and enhanced data rates.

It should be appreciated that future networks will most probably utilise network functions virtualization (NFV) which is a network architecture concept that proposes virtualizing network node functions into "building blocks" or entities that may be operationally connected or linked together to provide services. A virtualized network function (VNF) may comprise one or more virtual machines running computer program codes using standard or general type servers instead of customized hardware. Cloud computing or data storage may also be utilized. In radio communications this may mean node operations may be carried out, at least partly, in a server, host or node operationally coupled to a remote radio head.

Embodiments of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Embodiments may be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, a data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. Embodiments may also be provided on a computer readable medium or computer readable storage medium, which may be a non-transitory medium. Embodiments of the various techniques may also include embodiments provided via transitory signals or media, and/or programs and/or software embodiments that are downloadable via the Internet or other network(s), either wired networks and/or wireless networks. In addition, embodiments may be provided via machine type communications (MTC), and also via an Internet of Things (IOT).

Furthermore, embodiments of the various techniques described herein may use a cyber-physical system (CPS) (a system of collaborating computational elements controlling physical entities). CPS may enable the embodiment and exploitation of massive amounts of interconnected ICT devices (sensors, actuators, processors microcontrollers,. ) embedded in physical objects at different locations. The rise in popularity of smartphones has increased interest in the area of mobile cyber-physical systems. Therefore, various embodiments of techniques described herein may be provided via one or more of these technologies.

To provide for interaction with a user, embodiments may be implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user and a user interface, such as a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer.

Embodiments may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an embodiment, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network.

Claim 1:
An apparatus comprising:
at least one processor; and
at least one memory including computer program code;
at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to:
receive (<NUM>) a plurality of channel state information - CSI - values reported by the user device;
determine (<NUM>) a plurality of estimated reference signal received power - RSRP - values that have been estimated based at least on the plurality of CSI values; and
output (<NUM>) a sequence of RSRP values, including at least the estimated RSRP values,
wherein each CSI value comprises at least a channel quality indicator - CQI - value,
wherein the determination of the estimated RSRP values is based at least on a plurality of CQI values of the CSI values.