Patent Description:
For example, one parameter in providing good performance and capacity for a given communications protocol in a communications network is Link Adaptation (LA). LA is used to determine which Modulation and Coding Scheme (MCS) that is optimal for a given set of wireless channel conditions. In case of uplink transmission (i.e., transmission from served terminal devices at the user-side to serving base station at the network-side), the LA scheme relies on signal to interference plus noise ratio (SINR) estimates at the base station to pick the most optimal MCS. On top of measurement inaccuracies, the delay between the measurements and the actual uplink transmission implies that the wireless channel conditions might have changed at the time of actual downlink transmission (i.e., transmission from serving base station at the network-side to served terminal devices at the user-side). Therefore, to compensate for measurement inaccuracies, a correction term is added. This correction term is based on acknowledgement (ACK) feedback and negative-acknowledgement (NACK) feedback from hybrid automatic repeat request (HARQ) processes run at the base station.

Within a given block error rate (BLER) target, an ACK would indicate that the LA could be more aggressive and thus a higher MCS than indicated by the SINR estimates should be selected. A NACK indicates the opposite and thus that the LA could be less aggressive and thus a lower MCS than indicated by the SINR estimates should be selected. In some aspects, LA aims to achieve a certain BLER target so that the outer-loop adjustment is expected to receive one single NACK for every N new transmissions (where N = <NUM> if the BLER is <NUM>%). This implies during a channel coherent interval there should be sufficiently many of ACKs and NACKs for the LA to make reliable outer-loop adjustment. Making such outer-loop adjustments is commonly referred to as Outer-loop Link Adaptation (OLLA).

In some applications, such as ultra-reliable low-latency communication (URLLC) applications, a very high reliability, such as up to <NUM>% reliability is desired, or even required. This implies that a NACK is allowed to be received only once per every <NUM>,<NUM>,<NUM> new transmission. In this respect, the wireless channel conditions vary depending on movements of the terminal device as well as on environmental changes. Therefore, there are in most practical cases not enough NACKs received within the channel coherent time for the LA to reliably know how much further the MCS can be increased within the expected BLER target. Additionally, upon having received one single NACK, this does not guarantee, or even indicate, that the wireless channel conditions will be unfavorable for the next <NUM>,<NUM>,<NUM> new transmissions. The wireless channel conditions could very well be favorable for a significant fraction of the <NUM>,<NUM>,<NUM> new transmissions that follow after one single NACK has been received.

Moreover, existing OLLA aims to maximize system capacity by choosing the highest possible MCS within a given BLER target. For URLLC applications, system capacity is of secondary importance with the primary focus on maintaining the reliability, i.e. the robustness. In other words, maintaining an MCS scheme that reliably delivers ACKs from the HARQ processes is the goal for a robust LA scheme. Therefore, traditional OLLA is not suitable for outer-loop adjustments in the context of URLLC applications.

One approach is for the LA scheme to always pick the most robust MCS to, if possible, avoid any NACKs. However, this approach sometimes results in a much lower MCS being picked than what the wireless channel conditions permit at the time of the transmission and is not suitable for transmissions where capacity also is important.

Another approach presented in <CIT> is to adapt the transmission parameters depending on the reliability of iteratively decoded data on the receiving side of the radio link. <CIT> proposes to use forward error correction FEC code at the transmitter side, and the FEC, the modulation scheme and power is adapted in relation predicted performance (<FIG>). Nevertheless, there is still a need for an improved link adaptation.

An object of embodiments herein is to provide efficient link adaptation that does not suffer from the issues noted above, or at least where the above noted issues are mitigated to reduced.

According to a first aspect there is presented a method for radio link adaptation at a transmit and receive point, as is defined by claim <NUM>.

According to a second aspect there is presented a network node for radio link adaptation at a transmit and receive point, as is defined by claim <NUM>.

According to a third aspect there is presented a computer program for radio link adaptation at a transmit and receive point, as is defined by claim <NUM>. Advantageously, these aspects provide efficient link adaptation.

Advantageously, the proposed link adaptation does not suffer from the issues noted above.

Advantageously, the proposed link adaptation enables, by means of using granular information as defined by the LLR values, adjustment of the radio link adaptation parameter values on a very fine scale.

Advantageously, the proposed link adaptation is suitable for any BLER target any wireless channel conditions;
Advantageously, the proposed link adaptation is suitable for applications requiring high reliability, such as URLLC applications.

Advantageously, these aspects enable ACKs to be differentiated when performing radio link adaptation of the radio link.

Advantageously, these aspects enable determination of the possibility of a block error, before the error occurs since the LLR values can indicate that wireless channel conditions are worsening, well before a block error occurs. Hence, it is possible to estimate when a NACK might occur, well before the NACK actually occurs.

This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept as defined by the claims to those skilled in the art.

<FIG> is a schematic diagram illustrating a communication network <NUM> where embodiments presented herein can be applied. The communication network <NUM> could be a third generation (<NUM>) telecommunications network, a fourth generation (<NUM>) telecommunications network, or a fifth (<NUM>) telecommunications network, or any advancement thereof, and support any 3GPP telecommunications standard, where applicable.

The communication network <NUM> comprises a network node <NUM> configured to provide network access to terminal devices 150a, 150b over radio links 160a, 160b in a radio access network <NUM>. The radio access network <NUM> is operatively connected to a core network <NUM>. The core network <NUM> is in turn operatively connected to a service network <NUM>, such as the Internet. The terminal devices 150a, 150b are thereby enabled to, via the network node <NUM>, access services of, and exchange data with, the service network <NUM>.

The network node <NUM> comprises, is collocated with, is integrated with, or is in operational communications with, a Transmit and Receive Point (TRP) <NUM>. Examples of network nodes <NUM> are radio access network nodes, radio base stations, base transceiver stations, Node Bs, evolved Node Bs, gNBs, access points, access nodes, and backhaul nodes. Examples of terminal devices 150a, 150b are wireless devices, mobile stations, mobile phones, User Equipment (UE), handsets, wireless local loop phones, smartphones, laptop computers, tablet computers, network equipped sensors, network equipped vehicles, and so-called Internet of Things devices.

As noted above there is still a need for an improved link adaptation of the radio links 160a, 160b.

As a non-limiting illustrative example, consider a low-density parity-check (LDPC) decoder as an example of an information decoder that takes LLR values as input. Let the nth received bit be yn, and the transmitted bit be xn. The LLR value of the nth received bit at the input to the LDPC decoder is denoted <MAT> and is determined as: <MAT>.

The <MAT> values are then used during iterative message parsing between variable nodes and check nodes in the LDPC decoder. For each iteration, the <MAT> values are updated indicating the probability of that bit being <NUM> or <NUM>. After a certain exit criterion has been satisfied, the LDPC decoder stops the message parsing. The LLR values at the output of the decoder, denoted <MAT> and representing the final iteration of the <MAT> values, are then used for deciding on the decoded bits as follows: <MAT>.

Then a CRC checksum is calculated based on the decoded bits. If the CRC checksum is a pass, a HARQ ACK is triggered, and otherwise a HARQ NACK is triggered.

In the existing LA schemes, if a HARQ ACK is triggered, the outer-loop LA will take an incremental (+) adjustment step to the estimated SINR or the estimated MCS. If a HARQ NACK is triggered, a decremental (-) adjustment step is taken. Often the increments are much smaller than the decrements, and the exact step size depends on the BLER target of the LA.

However, as noted above, performing LA based only on ACKs and NACKs might not be sufficient for some applications (such as URLLC applications), for some BLER targets, and/or for some wireless channel conditions since it could result in that the MCS is adjusted too coarsely or that an unnecessary robust MCS is selected.

The embodiments disclosed herein therefore relate to mechanisms for radio link adaptation at a transmit and receive point <NUM>. In order to obtain such mechanisms there is provided a network node <NUM>, a method performed by the network node <NUM>, a computer program product comprising code, for example in the form of a computer program, that when run on a network node <NUM>, causes the network node <NUM> to perform the method.

<FIG> is a flowchart illustrating embodiments of methods for radio link adaptation at a transmit and receive point <NUM>. The methods are performed by the network node <NUM>. The methods are advantageously provided as computer programs <NUM>.

The herein disclosed embodiments are based on LLR-dependent link adaptation. Therefore, the network node <NUM> is configured to perform step S102:
S102: The network node <NUM> obtains LLR values for a block of codewords. The LLR values are output from an information decoder decoding the block of codewords. Hence, in view of the above, these LLR values are the LLR values at the output of the information decoder, denoted <MAT>. The block of codewords has been communicated over a radio link 160a, 160b between the TRP <NUM> and a terminal device 150a, 150b.

Link adaptation is then performed using the obtained LLR values. In particular, the network node <NUM> is configured to perform step S108:
S108: The network node <NUM> performs radio link adaptation of the radio link 160a, 160b depending on the LLR values by selecting radio link adaptation parameter values. Which radio link adaptation parameter values to select depends on the LLR values.

This provides link adaptation that is suitable for applications such as URLLC applications, for all BLER targets, and for all wireless channel conditions since it enables the MCS to be more finely adjusted than when the link adaptation only is dependent on ACKs and NACKs.

The LLR values can be used to predict whether the block of codewords will be correctly decoded or not.

Embodiments relating to further details of radio link adaptation at a transmit and receive point <NUM> as performed by the network node <NUM> will now be disclosed. There could be different types of radio link adaptation that is performed in S108. In some embodiments, the radio link adaptation is an outer-loop radio link adaptation of the transmit and receive point <NUM>. Further, in some embodiments, the radio link adaptation parameter values are defined by modulation and coding scheme values. There could be different ways in which the radio link adaptation parameter values are selected. In some aspects, selecting the radio link adaptation parameter values involves incrementing or decrementing currently used modulation and coding scheme values in steps.

There could be different ways in which the selection of the radio link adaptation parameter values depends on the LLR values. According to the claimed invention, the selection is based on comparing the LLR values to one or more threshold values. That is, in which radio link adaptation parameter values to select depends on whether the LLR values are above or below a threshold value. In this respect, according to the claimed invention, selecting the radio link adaptation parameter values involves incrementing or decrementing currently used modulation and coding scheme values in steps depending on whether the LLR values are above or below the threshold value. Still further in this respect, according to the claimed invention, which step-size to use when incrementing or decrementing the currently used modulation and coding scheme values depends on the LLR values. Although some of the examples disclosed herein relate to LDPC decoders, there could be other types of information decoders from which the LLR values are obtained. For example, the information decoder could be any of: an LDPC decoder, a polar code decoder, a turbo decoder. Further, in some examples the information decoder is an iterative decoder.

When the information decoder is an iterative decoder, the number of iterations used by the information decoder and/or other intermediate outputs of the information decoder could be used as input to the decision of which radio link adaptation parameter values to select. In particular, in some embodiments, which radio link adaptation parameter values to select depends on how many iterations were used by the information decoder to iteratively decode the block of codewords.

In some aspects, a cyclic redundancy check (CRC) checksum is calculated based on the LLR values and information of whether the CRC checksum is a pass or a fail could be used as input to the decision of which radio link adaptation parameter values to select. In particular, in some embodiments, which radio link adaptation parameter values to select depends on whether the LLR values in binary representation passes or fails a CRC. An ACK will be issued when the CRC checksum is a pass, and otherwise (i.e., when the CRC checksum is a fail) a NACK will be issued.

As noted above, the LLR values considered thus far for the radio link adaptation of the radio link 160a, 160b are the LLR values at the output of the information decoder, denoted <MAT>. In further aspects, the radio link adaptation of the radio link 160a, 160b is also based on LLR values at the input of the information decoder, denoted <MAT>. Thus, in some embodiments, which radio link adaptation parameter values to select depends on how much the <MAT> values differ from the <MAT> values being input to the information decoder. In some embodiments, which radio link adaptation parameter values to select depends on how much the <MAT> values differ from the <MAT> values only when the <MAT> values in binary representation passes the cyclic redundancy check.

In some aspects, the radio link adaptation of the radio link 160a, 160b is based on the number of bits flipped by the information decoder. In particular, in some embodiments, which radio link adaptation parameter values to select depends on how many <MAT> values in binary representation have been flipped in comparison to the LLR™ values in binary representation.

In further detail, when the CRC checksum is a pass, a soft indicator, hereinafter denoted S, can be determined as follows. First, let Ln be an indicator that represents if the sign of LLR value n has changed from LLR™ to <MAT> or not. That is: <MAT>.

Then, let Ŝ represent the total number of LLR values where the sign changed from <MAT> to <MAT>. Hence, S can be calculated by summing all indicators Ln. That is: <MAT>.

Essentially Ŝ thus represents the total number of bits flipped by the information decoder. Consider a threshold T, which is a function f<NUM> of the selected MCS and the code block size (CBS), i.e., the size of each block of codewords, of the decoded transmission. That is: <MAT>.

The soft indicator is a function f<NUM> of Ŝ and the threshold T and can thus be calculated as: <MAT>.

The step size can then be determined as a function f<NUM> of S. That is: <MAT>.

Depending on the sign of S, the step size can be positive or negative. This implies an adjustment to increase or to decrease the SINR estimate or the MCS when a HARQ or an ACK is received. This is a distinct difference to the existing LA schemes that generally increase the MCS when an ACK is received.

Intermediate reference is here made to <FIG> that schematically illustrates how the soft indicator S can be generated using an information decoder, here represented by an LDPC decoder <NUM> operating on a code corresponding to six variable nodes and four check nodes.

The bits produced by the LDPC decoder <NUM> are fed to a CRC checksum calculator <NUM> that calculates the CRC checksum on the systematic bits and the parity bits. If the CRC checksum is a fail, the CRC checksum calculator <NUM> sends an indicator to NACK trigger module <NUM> to trigger a NACK to be sent and the SINR estimate and/or MCS to be decremented. If the CRC checksum is a pass, the CRC checksum calculator <NUM> sends an indicator to ACK trigger module <NUM> to trigger an ACK to be sent. However, whether the SINR estimate and/or MCS should be incremented or decremented is controlled by input, in the form of the S value as determined by soft indicator calculator module <NUM>. The <MAT> values and the <MAT> values are therefore fed to soft indicator calculator module <NUM> for calculation of Ŝ and then of S. Whether the SINR estimate and/or MCS should be incremented or decremented in ACK trigger module <NUM> is then dependent by the S value, as fed to the ACK trigger module <NUM>.

If the transport block size (TBS) is smaller than or equal to the CBS, there will be only one block of codewords per each transport block (TB). In this case the herein disclosed radio link adaptation of the radio link 160a, 160b can be applied as is. However, if TBS is larger than the CBS, each TB comprises two or more block of codewords. In case where the information decoder on one block of codewords at a time, this implies running the information decoder more than one time to fully decode the complete TB. In the latter case, one value of the soft indicator is produced per each block of codewords. The soft indicators for all the blocks of codewords might then be combined into one single soft indicator for the complete TB and this single soft indicator is then used as input to the radio link adaptation of the radio link 160a, 160b.

In some aspects, information of the number of bits flipped by the information decoder is only used when the CRC checksum is a pass (i.e., when the decoding of the block of codewords is successful). That is, in some embodiments, which radio link adaptation parameter values to select depends on how many <MAT> values in binary representation have been flipped in comparison to the LLR™ values in binary representation only when the <MAT> values in binary representation passes the cyclic redundancy check.

Similar calculations can be made by instead considering how many <MAT> values in binary representation that have not been flipped in comparison to the <MAT> values in binary representation.

Further, in addition to, or as an alternative to, only observing the <MAT> values and the <MAT> values, the LLR values at the end of each iteration of the information decoder might be considered as input to the radio link adaptation of the radio link 160a, 160b.

In some aspects, the LLR values at the end of each iteration are compared to the <MAT> values and the difference is used as input to the radio link adaptation of the radio link 160a, 160b. That is, in some embodiments, the LLR values output from the information decoder after its final iteration are defined by the <MAT> values, one set of intermediate LLR values are output from the information decoder per each iteration, and where which radio link adaptation parameter values to select depends on how much the intermediate LLR values at each iteration differ from the <MAT> values.

In some aspects, how much the LLR values change from one iteration to the next is used as input to the radio link adaptation of the radio link 160a, 160b. That is, in some embodiments, one set of intermediate LLR values are output from the information decoder per each iteration, and which radio link adaptation parameter values to select depends on how much the intermediate LLR values change from iteration to iteration.

There could be further ways to select the radio link adaptation parameter values, regardless if the CRC checksum is a pass or a fail. Embodiments relating thereto will now be disclosed in more details with continued reference to <FIG>.

In some aspects, which radio link adaptation parameter values to select is dependent on the estimated bit error probability (BEP) of the block of codewords. In particular, in some embodiments, the network node <NUM> is configured to perform (optional) step S104:
S104: The network node <NUM> estimates the BEP for the block of codewords from the <MAT> values. Which radio link adaptation parameter values to select then depends on the BEP.

In further detail, by using the definition of the LLR, it is possible to estimate the probability that all the systematic bits have been correctly decoded. This measurement is hereinafter referred to as the block error probability (BLEP). The BLEP for the systematic decoded bits can be defined as follows: <MAT>.

The BEP is the probability that a systematic bit, s, is incorrectly decoded. The BEP is derived from the definition of the LLR. That is: <MAT>.

The BLEP measurement will accurately reflect the probability that the decoding output is correct or incorrect.

The pure BLEP value or a filtered, or averaged, value of the BLEP can be used as input to the radio link adaptation of the radio link 160a, 160b. According to one non-limiting example, when BLEP < target BLER, then SINR value used for radio link adaptation of the radio link 160a, 160b is increased by stepping up the outer-loop SINR adjustment value, and otherwise the SINR value used for radio link adaptation of the radio link 160a, 160b is decreased by stepping down the outer-loop SINR adjustment value.

In still further aspects, SINR values are thus used as input to the radio link adaptation of the radio link 160a, 160b. In particular, in some embodiments, the network node <NUM> is configured to perform (optional) step S106:S106: The network node <NUM> estimates the SINR for the block of codewords from the LLR values. Which radio link adaptation parameter values to select then depends on the SINR for the block of codewords.

Simulation results are shown in <FIG>. The simulation results are for simulations performed for Scenario A. <NUM>-<NUM>, indoor hot-spot and factory automation, defined in 3GPP TS <NUM> "Study on physical layer enhancements for NR ultra-reliable and low latency case (URLLC)" V16. During the simulations, values of Ŝ were collected together with the CRC checksum pass/fail status per each block of codewords decoded by the LDPC decoder. The simulations were performed without including any interference, and hence the signal to noise ratio (SNR) is equal to the SINR. As above, let Ŝ represent the total number of LLR values where the sign changed from LLRn to <MAT>.

At <NUM> is shown the mean of Ŝ per SINR point, normalized to the range [<NUM>, <NUM>]. The values in this curve can be used for generating the soft indicator S and the outer-loop adjustment step size. At <NUM> is shown the mean number of blocks of codewords that pass the CRC checksum, i.e., resulting in ACKs, normalized to the same range [<NUM>, <NUM>]. For some applications, such as URLLC applications, operation is performed at reliability levels in the order of <NUM>%. Therefore, consider the two curves <NUM>, <NUM> in the SINR range above -<NUM> dB, i.e., in regions <NUM> and <NUM> of the curves <NUM> and <NUM>, respectively. In region <NUM>, curve <NUM> is almost flat, whereas curve <NUM> has a distinct gradient, or slope, in region <NUM>. Having a gradient, or slope, in this SINR region is key as it allows ACKs to be differentiated with a soft indicator that has a much higher granularity and hence is better suited as input to the radio link adaptation of the radio link 160a, 160b.

<FIG> schematically illustrates, in terms of a number of functional units, the components of a network node <NUM> according to an embodiment. Processing circuitry <NUM> is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product <NUM> (as in <FIG>), e.g. in the form of a storage medium <NUM>. The processing circuitry <NUM> may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

Particularly, the processing circuitry <NUM> is configured to cause the network node <NUM> to perform a set of operations, or steps, as disclosed above. For example, the storage medium <NUM> may store the set of operations, and the processing circuitry <NUM> maybe configured to retrieve the set of operations from the storage medium <NUM> to cause the network node <NUM> to perform the set of operations. The set of operations maybe provided as a set of executable instructions.

The network node <NUM> may further comprise a communications interface <NUM> at least configured for communications with other entities, functions, nodes, and devices in, or served by, the communication network <NUM> of <FIG>, such as the TRP <NUM> and the terminal devices 150a, 150b as well as the core network <NUM>. As such the communications interface <NUM> may comprise one or more transmitters and receivers, comprising analogue and digital components. The processing circuitry <NUM> controls the general operation of the network node <NUM> e.g. by sending data and control signals to the communications interface <NUM> and the storage medium <NUM>, by receiving data and reports from the communications interface <NUM>, and by retrieving data and instructions from the storage medium <NUM>. Other components, as well as the related functionality, of the network node <NUM> are omitted in order not to obscure the concepts presented herein.

<FIG> schematically illustrates, in terms of a number of functional modules, the components of a network node <NUM> according to an embodiment. The network node <NUM> of <FIG> comprises a number of functional modules; an obtain module 210a configured to perform step S102, and an adapt module 210d configured to perform step S108. The network node <NUM> of <FIG> may further comprise a number of optional functional modules, such as any of an (first) estimate module 210b configured to perform step S104, and an (second) estimate module210c configured to perform step S106. In general terms, each functional module 210a-210d may in one embodiment be implemented only in hardware and in another embodiment with the help of software, i.e., the latter embodiment having computer program instructions stored on the storage medium <NUM> which when run on the processing circuitry makes the network node <NUM> perform the corresponding steps mentioned above in conjunction with <FIG>. It should also be mentioned that even though the modules correspond to parts of a computer program, they do not need to be separate modules therein, but the way in which they are implemented in software is dependent on the programming language used. Preferably, one or more or all functional modules 210a-210d may be implemented by the processing circuitry <NUM>, possibly in cooperation with the communications interface <NUM> and/or the storage medium <NUM>. The processing circuitry <NUM> may thus be configured to from the storage medium <NUM> fetch instructions as provided by a functional module 210a-210d and to execute these instructions, thereby performing any steps as disclosed herein.

The network node <NUM> may be provided as a standalone device or as a part of at least one further device. For example, the network node <NUM> may be provided in a node of the radio access network or in a node of the core network. Alternatively, functionality of the network node <NUM> may be distributed between at least two devices, or nodes. These at least two nodes, or devices, may either be part of the same network part (such as the radio access network or the core network) or may be spread between at least two such network parts. In general terms, instructions that are required to be performed in real time may be performed in a device, or node, operatively closer to the cell than instructions that are not required to be performed in real time.

Thus, a first portion of the instructions performed by the network node <NUM> may be executed in a first device, and a second portion of the of the instructions performed by the network node <NUM> may be executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the network node <NUM> may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a network node <NUM> residing in a cloud computational environment. Therefore, although a single processing circuitry <NUM> is illustrated in <FIG> the processing circuitry <NUM> may be distributed among a plurality of devices, or nodes. The same applies to the functional modules 210a-210d of <FIG> and the computer program <NUM> of <FIG>.

<FIG> is a schematic diagram illustrating a telecommunication network connected via an intermediate network <NUM> to a host computer <NUM> in accordance with some embodiments. In accordance with an embodiment, a communication system includes telecommunication network <NUM>, such as a 3GPP-type cellular network, which comprises access network <NUM>, such as radio access network <NUM> in <FIG>, and core network <NUM>, such as core network <NUM> in <FIG>. Access network <NUM> comprises a plurality of radio access network nodes 412a, 412b, 412c, such as NBs, eNBs, gNBs (each corresponding to the network node <NUM> of <FIG>) or other types of wireless access points, each defining a corresponding coverage area, or cell, 413a, 413b, 413c. Each radio access network nodes 412a, 412b, 412c is connectable to core network <NUM> over a wired or wireless connection <NUM>. A first UE <NUM> located in coverage area 413c is configured to wirelessly connect to, or be paged by, the corresponding network node 412c. A second UE <NUM> in coverage area 413a is wirelessly connectable to the corresponding network node 412a. While a plurality of UE <NUM>, <NUM> are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole terminal device is connecting to the corresponding network node <NUM>. The UEs <NUM>, <NUM> correspond to the terminal devices 150a, 150b of <FIG>.

Host computer <NUM> maybe under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider.

For example, network node <NUM> may not or need not be informed about the past routing of an incoming downlink communication with data originating from host computer <NUM> to be forwarded (e.g., handed over) to a connected UE <NUM>. Similarly, network node <NUM> need not be aware of the future routing of an outgoing uplink communication originating from the UE <NUM> towards the host computer <NUM>.

<FIG> is a schematic diagram illustrating host computer communicating via a radio access network node with a UE over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with an embodiment, of the UE, radio access network node and host computer discussed in the preceding paragraphs will now be described with reference to <FIG>. The UE <NUM> corresponds to the terminal devices 150a, 150b of <FIG>.

Communication system <NUM> further includes radio access network node <NUM> provided in a telecommunication system and comprising hardware <NUM> enabling it to communicate with host computer <NUM> and with UE <NUM>. The radio access network node <NUM> corresponds to the network node <NUM> of <FIG>. Hardware <NUM> may include communication interface <NUM> for setting up and maintaining a wired or wireless connection with an interface of a different communication device of communication system <NUM>, as well as radio interface <NUM> for setting up and maintaining at least wireless connection <NUM> with UE <NUM> located in a coverage area (not shown in <FIG>) served by radio access network node <NUM>. In the embodiment shown, hardware <NUM> of radio access network node <NUM> further includes processing circuitry <NUM>, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. Radio access network node <NUM> further has software <NUM> stored internally or accessible via an external connection.

Its hardware <NUM> may include radio interface <NUM> configured to set up and maintain wireless connection <NUM> with a radio access network node serving a coverage area in which UE <NUM> is currently located. It is noted that host computer <NUM>, radio access network node <NUM> and UE <NUM> illustrated in <FIG> may be similar or identical to host computer <NUM>, one of network nodes 412a, 412b, 412c and one of UEs <NUM>, <NUM> of <FIG>, respectively.

In <FIG>, OTT connection <NUM> has been drawn abstractly to illustrate the communication between host computer <NUM> and UE <NUM> via network node <NUM>, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

Wireless connection <NUM> between UE <NUM> and radio access network node <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to UE <NUM> using OTT connection <NUM>, in which wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may reduce interference, due to improved classification ability of airborne UEs which can generate significant interference.

The reconfiguring of OTT connection <NUM> may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect network node <NUM>, and it maybe unknown or imperceptible to radio access network node <NUM>. In certain embodiments, measurements may involve proprietary UE signaling facilitating host computer's <NUM> measurements of throughput, propagation times, latency and the like. The measurements maybe implemented in that software <NUM> and <NUM> causes messages to be transmitted, in particular empty or 'dummy' messages, using OTT connection <NUM> while it monitors propagation times, errors etc..

Claim 1:
A method for radio link adaptation at a transmit and receive point (<NUM>), the method being performed by a network node (<NUM>), the method comprising:
obtaining (S102) log-likelihood ratio, LLR, values for a block of codewords, wherein the LLR values are output from an information decoder decoding the block of codewords, and wherein the block of codewords has been communicated over a radio link (160a, 160b) between the transmit and receive point (<NUM>) and a terminal device (150a, 150b); and
performing (S108) radio link adaptation of the radio link (160a, 160b) depending on the LLR values by selecting radio link adaptation parameter values, wherein which radio link adaptation parameter values to select depends on the LLR values, wherein the radio link adaptation parameter values are defined by modulation and coding scheme values, wherein which radio link adaptation parameter values to select depends on whether the LLR values are above or below a threshold value, and wherein selecting radio link adaptation parameter values involves incrementing or decrementing currently used modulation and coding scheme values in steps depending on whether the LLR values are above or below the threshold value, wherein which step-size to use when incrementing or decrementing the currently used modulation and coding scheme values depends on the LLR values.