Vous êtes sur la page 1sur 19

IMS GW R1 (Embedded version) - Application Software High Level Design

19. APPENDIX A LINK ADAPTATION

19.1 GPRS Link Adaptation

19.1.1 Algorithm Description

The GPRS Link Adaptation (LA) algorithm is used to select the optimum channel
coding scheme (CS-1, CS-2, CS-3 or CS-4) for a particular RLC connection.

The LA algorithm is based on the following principles:


The signal quality is measured for each TBF in terms of RXQUAL which
describes the channel quality with the accuracy of eight levels (RXQUAL is
expressed with three bits). Note that RXQUAL is measured for each received
RLC radio block. On a block basis RXQUAL is thus more accurate estimate than
the BLER which has only two levels: 0 and 1.
The PCU determines internally the average BLER separately for each coding
scheme and reported RXQUAL value. This can be done separately for each BTS
by collecting continuously statistics from all the connections in the corresponding
territory.
Based on the statistics, common for all the TBFs in the territory, and the
received RXQUAL estimate, that is specific to the given TBF, the PCU is able to
estimate what would be the BLER if CS1, CS2, CS3 or CS4 was deployed for
this TBF. Moreover, based on these BLER estimates the PCU can compute
which coding scheme would give the best performance, e.g. highest throughput
in RLC acknowledged mode.
The new LA algorithm adapts to the radio characteristics (fast-fading and
interference patterns) of the cell because the BLER is dynamically measured as
a function of RXQUAL and coding scheme. Therefore, there is no need for pre-
determined threshold values.
The new Link Adaptation algorithm can be used both in RLC Acknowledged
and RLC Unacknowledged modes.

The new Link Adaptation Algorithm replaces the current LA algorithm in GPRS
and covers the coding schemes:

CS1 and CS2 if the CS3&CS4 support is not enabled in the territory.
CS1, CS2, CS3 and CS4, if the CS3&CS4 support is enabled in the territory.

Note. The current LA algorithm can be replaced by the new one only if the BTS supports
RXQUAL or similar signal quality information for the UL RLC radio blocks.

Note. The Link Adaptation algorithm, which is presented in this document, has been tested
with the Protocol Simulator. The Protocol Simulator has, however, rather simple modeling for
the radio link characteristics. Therefore, the LA algorithm should be tested also in the network
level simulator, like SMART for further verification.

Downlink direction
Initialisation of RXQUAL: When a new territory is created for (E)GPRS, CHM creates
two 2-dimensional tables, named ACKS and NACKS for the territory (another set of 205
ACKS and NACKS tables is needed for UL direction). The first index refers to the
Version: 16.0 Nokia Networks
Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

coding scheme and the second index refers to the RXQUAL value in those tables. At
the territory creation the ACKS and NACKS tables are initialised to the values
obtained from the simulations, i.e. the operation of the LA algorithm is initially based
on the simulation results as in the traditional LA algorithms where pre-defined
threshold values are used. There should be a separate initialization for hopping and
non-hopping BTSs.

Updation of tables: During the DL data transfer the mobile station measures the
signal quality (RXQUAL) from the RLC radio blocks that are successfully decoded
and addressed to the mobile station. The RXQUAL is averaged over the received
RLC blocks and the averaged RXQUAL estimate is sent to the network within the
Packet DL Ack/Nack messages. There can be eight different values for the RXQUAL.

When RLC receives a valid Packet DL Ack/Nack message for a DL TBF that
operates in RLC acknowledged mode, the received bitmap is analysed and the
corresponding RLC blocks are marked as ACKED, if a positive acknowledgement is
received, or as NACKED, if a negative acknowledgement is received. At this
procedure the RLC updates the ACKS and NACKS tables as follows:
Whenever an RLC block, whose status is other than ACKED, is positively
acknowledged, then ACKS [CS][RXQ] = ACKS [CS][RXQ] + 1, where CS is the
coding scheme with which this RLC block was transmitted and RXQ is the
RXQUAL value that was received in this particular Packet DL Ack/Nack message.
Note that RLC has to keep a record about the coding scheme with which each
RLC radio block was originally transmitted.
Whenever an RLC block having a status other than NACKED is marked as
NACKED, i.e. negative acknowledgement is accepted by the timestamp
comparison, then NACKS [CS][RXQ] = NACKS [CS][RXQ] + 1, where CS is the
coding scheme with which this RLC block was originally transmitted and RXQ is
the RXQUAL value that was received in this particular Packet DL Ack/Nack
message.
Note. The BLER for a given CS and RXQUAL value can be computed as NACKS[CS]
[RXQUAL] / (ACKS[CS][RXQUAL] + NACKS[CS][RXQUAL]).

Note. While processing the Packet DL Ack/Nack message, RLC could first sum up the ACKS
and NACKS increments for each CS separately. The ACKS and NACKS tables could be
updated with a single function call thereafter.

Note that the pending ack transmissions disturb the BLER estimation because the
probability for a positive acknowledgement increases if the block is transmitted
several times before the acknowledgement is transmitted. To avoid this problem the
PCU shall update ACKS and NACKS tables based on only those RLC blocks that
have never been transmitted as pending_ack blocks. This can be implemented so
that RLC keeps a flag for each RLC data block and whenever the RLC transmits an
RLC data block whose status is PENDING, the flag for that data block is turned on. If
a positive or negative acknowledgement is then received for an RLC data block
whose flag has been set, then this positive or negative acknowledgement shall not
contribute to the ACKS and NACKS statistics. The flag is not turned off until the RLC
data block has moved outside the transmit window.

With this mechanism the LA algorithm is able to collect statistics about the actual
206
block error rate as a function of coding scheme and channel quality estimate. Based
Version: 16.0 Nokia Networks
Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

on this statistics it is then possible to select a coding scheme that gives, on the
average, the highest throughput with respect to the specific channel quality estimate.

Note that ACKS and NACKS tables contain ever-increasing figures. This is not
acceptable because in a long run the figures will overflow resulting in erroneous
behavior. This problem can be solved so that when the sum (ACKS [CS][RXQ] +
NACKS [CS][RXQ]) for certain CS and RXQ exceeds a certain Threshold value, then
both figures are divided by 2, for instance:
ACKS [CS][RXQ] = ACKS [CS][RXQ] / 2.
NACKS [CS][RXQ] = NACKS [CS][RXQ] / 2.
The above mentioned threshold value can be decided in the software design phase.

By this the LA algorithm preserves its ability to adjust (slowly) to the radio
characteristics of the cell if the channel characteristics (fast-fading, interference
pattern) happen to change for some reason or another.

After the bitmap is processed by the RLC, the LA algorithm selects the optimal
coding scheme for this particular link as follows:

RLC acknowledged mode


Estimate the throughput of the link for each coding scheme separately (CS =
CS1, CS2, CS3, CS4, if CS3&CS4 support is enabled in the territory, CS = CS1,
CS2, otherwise):
Throughput[CS] = K * ACKS [CS][RXQ] / (ACKS [CS][RXQ] + NACKS [CS]
[RXQ]) * RATE[CS], where K is a correction factor that takes into account the
throughput reduction due to the RLC protocol stalling, RXQ is the RXQUAL value
that was received in the just-processed Packet DL Ack/Nack message and
RATE[4] -table contains the theoretical maximum throughput values for the
available channel coding schemes.
Select the coding scheme that gives the highest throughput with the condition
of BLER(CS) < QC_ACK_BLER_LIMIT_T, where BLER(CS) = NACKS [CS]
[RXQ] / (ACKS[CS] [RXQ] + NACKS [CS] [RXQ]). If no CS fulfills this condition,
then CS1 is selected.
The correction factor K should be a function of BLER and Sch_Rate, which is the
number of RLC radio blocks that are scheduled to the TBF within the RLC
acknowledgement delay (the time interval between the polling and the reception of
the corresponding Packet DL Ack/Nack message). This is because the impact of
RLC protocol stalling depends on those terms. The correction factor can be
implemented as a pre-defined 2-dimensional table where the first index refers to the
BLER, that is NACKS [CS][RXQ] / (ACKS [CS][RXQ] + NACKS [CS][RXQ]), with
suitable discretization, and the second index refers to the Sch_Rate. The numeric
values for the correction factor K can be obtained from the simulations but the
Sch_Rate is something that need be measured for each DL TBF.

One alternative for measuring the Sch_Rate is to have a block counter and a flag
that indicates whether there is a measurement ongoing for the TBF. Whenever the
TBF is polled, the RLC checks whether there is a measurement ongoing. If that is not
the case, then RLC resets the block counter to zero and sets the flag on. Otherwise,
207
no actions are needed. While the flag indicates that a measurement is ongoing, the
Version: 16.0 Nokia Networks
Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

RLC should increment the block counter each time an RLC radio block is scheduled
for that TBF regardless of the status of that block. When the Packet DL Ack/Nack
message then arrives for the polling for which the measurement was set (this can be
a successful reception or a bad frame), the RLC sets the value of the Sch_Rate to
the value of the block counter and turns the flag off.

RLC unacknowledged mode

In unacknowledged mode RLC does not have to update the ACKS and NACKS
tables but it can use the same ACKS and NACKS tables that are updated by the
TBFs in acknowledged mode.

The selection of the coding schemes in unacknowledged mode will be made


according the following formula:
Select the highest CS for which BLER(CS) < QC_UNACK_BLER_LIMIT_T,
where BLER(CS) = NACKS [CS] [RXQ] / (ACKS[CS] [RXQ] + NACKS [CS]
[RXQ]) and RXQ is the RXQUAL estimate that is received in the Packet DL
Ack/Nack message.
If the conditions will not come true then the selected CS is CS1.

Exception 1
An MS might report a RXQUAL value of 7 if it does not have a valid channel quality
estimate available. This can happen especially when CS-4 is deployed (see GSM-
05.08). Therefore, the RXQUAL value of 7 cannot be considered as a reliable
measurement because it can indicate either poor radio conditions or the fact that the
MS is not able to report a valid RXQUAL value. To overcome this the following
modifications are needed:
If the MS reports an RXQUAL value of 7 and the network currently deploys a
coding scheme other than CS-4 for the corresponding TBF, then the coding
scheme need not be changed. The next Packet DL Ack/Nack message will
probably carry a valid channel quality estimate for the LA purposes.
If the MS reports an RXQUAL value of 7 and the network currently deploys
CS-4 for the corresponding TBF, then RLC should estimate the current BLER by
counting the positively and negatively acknowledged CS-4 blocks (cs4_acks and
cs4_nacks) from the Packet Dl Ack/Nack message. Then, by using the ACKS and
NACKS tables, RLC should estimate the RXQUAL value that corresponds to the
current BLER estimate (the procedure for this is shown below). After this RLC
should perform the normal LA procedure using the estimated RXQUAL value.
RxQual = 0;

if( (cs4_acks + cs4_nacks) == 0 )

bler = 0.0;

else

bler = (double)(cs4_nacks) / (double)(cs4_acks + cs4_nacks);


208

Version: 16.0 Nokia Networks


Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

Bler = (double)(GPRS_Nakit[Link][CS4][RxQual]) /
(double)(GPRS_Akit[Link][CS4][RxQual] + GPRS_Nakit[Link][CS4][RxQual]);

while( bler > Bler && RxQual < 6 )

RxQual++;

Bler = (double)(GPRS_Nakit[Link][CS4][RxQual]) /
(double)(GPRS_Akit[Link][CS4][RxQual] + GPRS_Nakit[Link][CS4][RxQual]);
}

Exception 2
Since the mobile stations measure RXQUAL based on successfully received RLC
blocks, the RXQUAL estimate may be sometimes optimistic. Especially when CS-4 is
used, the mobile station might report the RXQUAL value of zero even in poor radio
conditions (if it is not reporting the RXQUAL value of 7). This might distort the
collected BLER statistics in such a way that the BLER estimate for a certain coding
scheme gets such a high value that the LA algorithm no more selects that CS for any
TBF in the territory. If a certain CS is not used at all, then there will be no statistics
for that CS either and the BLER estimate will remain the same. This kind of a dead-
lock situation can be avoided if the LA algorithm more eagerly selects a high coding
scheme number when the RXQUAL value of zero is reported:
if the MS reports the RXQUAL value of zero and the LA algorithm selects the
coding scheme CS-x even if the coding scheme CS-(x+1) could be used also,
then CS(x+1) should be selected instead of CS-x. Here x = 1, 2, 3.
This exception should be used only with RLC acknowledged operation mode.

Exception 3

If the MS is not able to decode the transmitted blocks, it will also miss the polling
requests. As a result, the network will receive bad frames instead of the Packet DL
Ack/Nack messages. However, the proposed LA algorithm will not select a more
robust coding scheme because the RXQUAL estimate is not updated. To overcome
this the following modification is needed:_
For each DL TBF RLC should have a counter, n_lost_acks, that is
incremented whenever a bad frame is received instead of a valid Packet DL
Ack/Nack message. The counter is set to zero when the TBF is established or
whenever a valid Packet DL Ack/Nack message is received. If the counter
exceeds a certain threshold value, then the currently used coding scheme should
be reduced as follows:
if( current_CS == CS4 && n_lost_acks >= 1 )

{
209
current_CS = CS3;
Version: 16.0 Nokia Networks
Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

n_lost_acks = 0;

if( current_CS == CS3 && n_lost_acks >= 2 )

current_CS = CS2;

n_lost_acks = 0;

if( current_CS == CS2 && n_lost_acks >= 3 )

current_CS = CS1;

n_lost_acks = 0;

Uplink direction
In UL direction the channel quality estimate can be RXQUAL or GMSK_BEP
depending on the Abis interface:
The PCU data frame that is used in non-EDE Abis interface reports the
channel quality in terms of RXQUAL. The RXQUAL is expressed with three bits
and the coding schemes that come into the question are CS-1 and CS-2.
The PCU master data frame that is used in EDGE Abis interface reports the
channel quality in in terms of GMSK_BEP. The GMSK_BEP is expressed with
four bits and the coding schemes that come into the question are CS-1, CS-2,
CS-3 and CS-4.
Initialisation of RXQUAL and GMSK_BEP: When a new territory is created for
(E)GPRS, CHM creates two 2-dimensional tables, named ACKS and NACKS for the
territory (another set of ACKS and NACKS tables is needed for DL direction). The
first index refers to the coding scheme and the second index refers to the RXQUAL
in case of Non-EDGE territory. In case of an EDGE territory, the second index in the
tables mentioned above, refers to GMSK_BEP value. At the territory creation the
ACKS and NACKS tables are initialised to the values obtained from the simulations.
There should be a separate initialization for hopping and non-hopping BTSs.

Updation of tables in RXQUAL case: For each UL TBF the RLC shall average the
RXQUAL estimates that the BTS sends for the correctly received RLC radio blocks.
The averaging should be done on a linear scale using the assumed BER (Bit Error
Rate) values (see Table 1). These values are added to the tables initialised during
territory creation only in case ALA is enabled. After updation of tables, the average210
RXQUAL estimates are initialised to zero.
Version: 16.0 Nokia Networks
Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

RXQUAL Lower BER Limit (%) Assumed BER (%) Upper BER Limit (%)
0 0.0 0.14 0.2
1 0.2 0.28 0.4
2 0.4 0.57 0.8
3 0.8 1.13 1.6
4 1.6 2.26 3.2
5 3.2 4.53 6.4
6 6.4 9.05 12.8
7 12.8 18.1 100.0

Table 19-1 Assumed BER values for RXQUAL averaging [GSM-05.08].

Updation of tables in GMSK_BEP case: For each UL TBF the RLC shall average the
GMSK_BEP estimates that the BTS sends for both correctly and erroneously
received RLC radio blocks. Note that the GMSK_BEP estimate should be noted also
from the bad frames because the GMSK_BEP estimate for successfully received
CS-4 blocks alone approaches zero in all radio conditions (there is no error
correction in CS-4). The averaging should be done on a linear scale using the
assumed BEP values (see Table 2). These values are added to the tables initialised
during territory creation only in case ALA is enabled. After updation of tables, the
average GMSK_BEP estimates are initialised to zero.

GMSK_BEP Lower BEP Limit Assumed BEP Upper BEP Limit


0 0.0 0.0002 0.0004
1 0.0004 0.0005 0.0006
2 0.0006 0.0008 0.001
3 0.001 0.0015 0.002
4 0.002 0.0025 0.003
5 0.003 0.0035 0.004
6 0.004 0.0050 0.006
7 0.006 0.0080 0.01
8 0.01 0.0130 0.016
9 0.016 0.0205 0.025
10 0.025 0.0325 0.04
11 0.04 0.0515 0.063
12 0.063 0.0815 0.1
13 0.1 0.1300 0.16
14 0.16 0.2050 0.25
15 0.25 0.2900 1.0

Table 19-2 Assumed values for GMSK_BEP averaging [Abis L1 Interface Specification].

During the UL data transfer RLC can estimate the number of successfully and
unsuccessfully received RLC radio blocks for BLER estimation purposes as follows
(this need to be done only in RLC acknowledged mode):
Whenever RLC receives an RLC data block that advances the V(R)
parameter and has the same coding scheme, CS, as the block that previously 211

Version: 16.0 Nokia Networks


Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

advanced the V(R) parameter, then RLC updates the following TBF specific
counters:
N_acks[CS] = N_acks[CS] + 1

N_nacks[CS] = N_nacks[CS] + (new_V(R) old_V(R) 1 + SNS) mod SNS,


where SNS is the sequence number space, i.e. 128 in GPRS.

When RLC then constructs a Packet UL Ack/Nack message for an UL TBF that
operates in RLC acknowledged mode, the RLC updates the ACKS and NACKS
tables as follows:
ACKS[CS][RXQ] = ACKS[CS][RXQ] + N_acks[CS], where CS runs through
the available coding schemes and RXQ is the current RXQUAL or GMSK_BEP
estimate for this UL TBF (RXQUAL is derived from the averaged BER estimate
by using the Table 1 and GMSK_BEP is derived from the averaged BEP estimate
by using the Table 2).
NACKS[CS][RXQ] = NACKS[CS][RXQ] + N_nacks[CS], where CS runs
through the available coding schemes and RXQ is the current RXQUAL or
GMSK_BEP estimate for this UL TBF (RXQUAL is derived from the averaged
BER estimate by using the Table 1 and GMSK_BEP is derived from the averaged
BEP estimate by using the Table 2).
After the ACKS and NACKS tables have been updated the counters
N_acks[CS] and N_nacks[CS] are reset to zero.
As in the DL case the figures in the ACKS and NACKS tables are restricted so that
when the sum (ACKS [CS][RXQ] + NACKS [CS][RXQ]) for certain CS and RXQ
exceeds a certain Threshold value, then both figures are divided by 2, for instance:
ACKS [CS][RXQ] = ACKS [CS][RXQ] / 2.

NACKS [CS][RXQ] = NACKS [CS][RXQ] / 2.

The above mentioned threshold value can be decided in the software design phase.

After the bitmap for the Packet UL Ack/Nack message is constructed by the RLC, the
LA algorithm selects the commanded coding scheme for the UL TBF as follows:

RLC acknowledged mode


Estimate the throughput of the link for each coding scheme separately (CS =
CS1, CS2, CS3, CS4, if CS3&CS4 support is enabled in the territory, CS = CS1,
CS2, otherwise):
Throughput[CS] = K * ACKS [CS][RXQ] / (ACKS [CS][RXQ] + NACKS [CS]
[RXQ]) * RATE[CS], where K is a correction factor that takes into account the
throughput reduction due to the RLC protocol stalling, RXQ is the current
RXQUAL or GMSK_BEP estimate for this UL TBF and RATE[4] -table
contains the theoretical maximum throughput values for the available channel
coding schemes.

Select the coding scheme that gives the highest throughput with the condition
of BLER(CS) < QC_ACK_BLER_LIMIT_T, where BLER(CS) = NACKS [CS]
212

Version: 16.0 Nokia Networks


Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

[RXQ] / (ACKS[CS] [RXQ] + NACKS [CS] [RXQ]). If no CS fulfills this condition,


then CS1 is selected.
The same correction factor table K can be used as in the DL case but the Sch_Rate
has to be estimated based on the number of scheduled USFs in a time unit. Since
the RLC acknowledgement delay is known to be about about 200 ms, the RLC could,
for instance, measure the time interval during which, say 20 USFs are scheduled for
the UL TBF and determine the Sch_Rate as follows:

Sch_Rate = 20 * 200 ms / measured_time_interval

RLC unacknowledged mode

In unacknowledged mode RLC does not have to update the ACKS and NACKS
tables but it can use the same ACKS and NACKS tables that are updated by the
TBFs in acknowledged mode.

The selection of the coding schemes in unacknowledged mode will be made


according the following formula:
Select the highest CS for which BLER(CS) < QC_UNACK_BLER_LIMIT_T,
where BLER(CS) = NACKS [CS] [RXQ] / (ACKS[CS] [RXQ] + NACKS [CS]
[RXQ]) and RXQ is the current RXQUAL or GMSK_BEP estimate for this UL TBF.
If the conditions will not come true for any CS, then the selected CS is CS1.
When a (E)GPRS territory is removed by the CHM, the corresponding ACKS and
NACKS tables can be removed as well.

Exception 1

In order to avoid dead-lock situations the following modification is suggested:


if the averaged RXQUAL or GMSK_BEP estimate equals to zero and the LA
algorithm selects the coding scheme CS-x even if the coding scheme CS-(x+1)
could be used also, then CS(x+1) should be selected instead of CS-x. Here x = 1,
2, 3.
This exception should be used only with RLC acknowledged operation mode.

Note. A (E)GPRS territory in the RF hopping BTS may contain timeslots of hopping TRXs as
well as timeslots of a non-hopping TRX. This would be a difficult situation for the adaptive LA
algorithm because the radio link characteristics (fast-fading pattern) is very different on
hopping and non-hopping TRXs. The solution for this requires separate ACKS and NACKS
tables for hopping and non-hopping TBFs.

Note: The interface between RLC and CHM will be defined by HSS because they will
implement the PCU parts to the IMS GW and they also will make the Implementation
Specification about that implementation.

19.2 EGPRS Link Adaptation

213

Version: 16.0 Nokia Networks


Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

19.2.1 Uplink Averaging

The three phases in Uplink Averaging are:


Decoding L1 data
Averaging of the decoded L1 data
BEP value calculating from the averaged data
19.2.1.1 Decoding L1 Data

During EGPRS uplink TBF transfer, the BTS measures the received signal quality
and reports the measurement data to the PCU in Abis L1 inband signalling. Before
the reported values can be used for averaging the RLC converts them as follows
VAR_BEP CV_BEP
received from
BTS
0 0.25
1 0.75
2 1.25
3 1.75

Table 19-3 An incoming VAR_BEP value is converted into CV_BEP.

MEAN_BEP MEAN_BEP_gmsk MEAN_BEP_8psk


received from (if GMSK MCS (if 8-PSK MCS
BTS used) used)
0 0.0002 0.00025
1 0.0005 0.00075
2 0.0008 0.0015
3 0.0015 0.0035
4 0.0025 0.0075
5 0.0035 0.0155
6 0.0050 0.0325
7 0.0080 0.0565
8 0.0130 0.076
9 0.0205 0.0915
10 0.0325 0.11
11 0.0515 0.13
12 0.0815 0.155
13 0.1300 0.19
14 0.2050 0.23
15 0.2900 0.275
214

Version: 16.0 Nokia Networks


Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

Table 19-4 : An incoming MEAN_BEP value is converted for GMSK or 8-PSK depending on MCS
used.

19.2.1.2 Averaging

The PCU performs the same averaging as that done by the MS. (See section 10.2.3,
10.2.4 3GPP TS 45.008).

The PCU averages the quality parameters of the block individually per TBF and per
modulation type as follows [45.008]:

R is calculated for every block period. BEP values are calculated for block periods
carrying block for the TBF.

For block periods carrying block for the TBF the R and BEP values of modulation of
received packet are calculated as follows:
R n (1 e) R n 1 e
e e
MEAN_BEP_TN n (1 ) MEAN_BEP_TN n 1 MEAN_BEPblock,n
Rn Rn
e e
CV_BEP_TN n (1 ) CV_BEP_TN n 1 CV_BEPblock,n
Rn Rn

and for the other modulation the R value is calculated as follows:


R n (1 e) R n 1
Where:n is the iteration index, incremented per each uplink radio block for TBF.

Rn denotes the reliability of the filtered quality parameters.


In the PCU R-1 = 0.25.

e is the forgetting factor. The PCU defines e using BEP_PERIOD [45.008]. The PCU
receives BEP_PERIOD from BSC as bep_period_t, whose range is 0..10. The PCU
defines e using the table below.
Value from DX 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
BEP_PERIOD Reserved 25 20 15 12 10 7 5 4 3 2 1
E - 0.08 0.1 0.15 0.2 0.25 0.3 0.4 0.5 0.65 0.8 1
Table 19-5: Forgetting Factor values

R-value Limit is based on BEP_PERIOD as follows:


Value from 1514131211 10 9 8 7 6 5 4 3 2 1 0
DX
BEP_PERIOD Reserved 25 20 15 12 10 7 5 4 3 2 1
- 4.343885e- 3.486784e- 1.968744e- 1.073742e- 5.631351e- 2.824752e- 6.046618e- 9.765625e- 2.75855e- 1.024e- 0
1 1 1 1 2 2 3 04 5 7
Table 19-6: R-value limit

When an R-value reduces under a limit (as specified in table A-4), BEP values are
not used in Link Adaptation algorithm for that modulation (instead conversion table A-
2 is used).
215

Version: 16.0 Nokia Networks


Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

Table values are calculated from equation:


R n (1 e) n
Where:n is set to 10, Currently n value means number of block periods carrying data
blocks after which BEP values are ignored in LA calculation.

If a block with bad header, or block with wrong TFI is received, only R of both
modulations is calculated per TBF as follows:
R n (1 e) R n 1
If the current modulation cannot be read from the frame then the modulation is
defined as the last commanded MCS. A block with Bad frame Indicator (BFI) equal to
1 is not considered as an error case and will be used for averaging.

19.2.1.3 BEP value calculation

If GMSK MCS was used then new GMSK_MEAN_BEP and GSMK_CV_BEP are
defined from the averaged values using the table below [45.008, 8.25].
Log10(MEAN_BEP_TN) GMSK_MEAN_BEP
-0.6 < log 0
-0.7 < log <= -0.6 1
-0.8 < log <= -0.7 2
-0.9 < log <= -0.8 3
-1.0 < log <= -0.9 4
-1.1 < log <= -1.0 5
-1.2 < log <= -1.1 6
-1.3 < log <= -1.2 7
-1.4 < log <= -1.3 8
-1.5 < log <= -1.4 9
-1.6 < log <= -1.5 10
-1.7 < log <= -1.6 11
-1.8 < log <= -1.7 12
-1.9 < log <= -1.8 13
-2.0 < log <= -1.9 14
-2.1 < log <= -2.0 15
-2.2 < log <= -2.1 16
-2.3 < log <= -2.2 17
-2.4 < log <= -2.3 18
-2.5 < log <= -2.4 19
-2.6 < log <= -2.5 20
-2.7 < log <= -2.6 21
-2.8 < log <= -2.7 22
-2.9 < log <= -2.8 23
-2.0 < log <= -2.9 24
-3.1 < log <= -3.0 25
-3.2 < log <= -3.1 26
-3.3 < log <= -3.2 27
-3.4 < log <= -3.3 28
-3.5 < log <= -3.4 29
-3.6 < log <= -3.5 30
log <= -3.6 31

216

Version: 16.0 Nokia Networks


Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

Table 19-7: GMSK_MEAN_BEP [45.008]

If 8-PSK MCS was used then new 8-PSK _MEAN_BEP and 8-PSK _CV_BEP are
defined from the averaged values using the table below [45.008, 8.25].
Log10(MEAN_BEP_TN) 8-PSK _MEAN_BEP
-0.6 < log 0
-0.64 < log <= -0.60 1
-0.68 < log <= -0.64 2
-0.72 < log <= -0.68 3
-0.76 < log <= -0.72 4
-0.80 < log <= -0.76 5
-0.84 < log <= -0.80 6
-0.88 < log <= -0.84 7
-0.92 < log <= -0.88 8
-0.96 < log <= -0.92 9
-1.00 < log <= -0.96 10
-1.04 < log <= -1.00 11
-1.08 < log <= -1.04 12
-1.12 < log <= -1.08 13
-1.16 < log <= -1.12 14
-1.20 < log <= -1.16 15
-1.36 < log <= -1.20 16
-1.52 < log <= -1.36 17
-1.68 < log <= -1.52 18
-1.84 < log <= -1.68 19
-2.00 < log <= -1.84 20
-2.16 < log <= -2.00 21
-2.32 < log <= -2.16 22
-2.48 < log <= -2.32 23
-2.64 < log <= -2.48 24
-2.80 < log <= -2.64 25
-2.96 < log <= -2.80 26
-3.12 < log <= -2.96 27
-3.28 < log <= -3.12 28
-3.44 < log <= -3.28 29
-3.6 < log <= -3.44 30
log <= -3.6 31
Table 19-8: 8-PSK_MEAN_BEP [45.008]

CV_BEP_TN 8-PSK/GMSK CV_BEP


1.75 < cv <= 2.00 0
1.50 < cv <= 1.75 1
1.25 < cv <= 1.50 2
1.00 < cv <= 1.25 3
0.75 < cv <= 1.00 4
0.50 < cv <= 0.75 5
0.25 < cv <= 0.50 6
0.00 < cv <= 0.25 7
Table 19-9: CV_BEP [45.008]

217

Version: 16.0 Nokia Networks


Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

19.2.2 Link Adaptation Algorithm Description

DOWNLINK UPLINK
The BEPs from the
EGPRS Packet The BEPs from Uplink
averaging are delivered
Downlink Ack/Nack
message are delivered to adaptation algorithm.
to adaptation algorithm.

Adaptation algorithm
START
Handle missing modulation data

Add user-defined mean_bep_offsets

ack unack Define MCS


Define MCS candidate A RLC basing on
basing on BLER limits (*) mode? BLER limits (*)

Define MCS candidate B using (*) While defining uplink MCS,


the output of these phases is
optimal MCS method (*)
a GMSK MCS if the MS is not
8-PSK capable in uplink

Select the smaller of the candidates A and B

Downlink only:
Define retransmission MCS
For BTS s/w CX3.2 only:
Change MCS8/9 to MCS7
Downlink only:
If MS IR memory full then restrict MCSs
READY

Downlink case outputs:


- MCS for current transmission
- MCS for retransmission
Uplink case output:
- MCS for initial transmission

Figure 19-1: Link Adaptation Algorithm

Inputs for algorithm are the BEP values as follows:


GMSK_MEAN_BEP
8-PSK_MEAN_BEP 218

Version: 16.0 Nokia Networks


Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

GMSK_CV_BEP
8-PSK_CV_BEP

Link adaptation algorithm selects MCS using predefined conversion tables based on
link level simulation results.

Link adaptation output MCS values are initialised with operator settings for Initial
MCS.

If the operator has disabled EGPRS link adaptation then the Link adaptation
algorithm does not change the output MCS values. Link adaptation is controlled with
EGPRS Link adaptation enabled parameter that has three values:

0 = EGPRS link adaptation is disabled

1 = EGPRS link adaptation is enabled for RLC acknowledged mode

2 = EGPRS link adaptation is enabled for both RLC acknowledged and RLC
unacknowledged modes

If the operator setting for Initial MCS is bigger than max MCS then Initial MCS is
replaced with max MCS.

19.2.2.1 Handling of missing BEP values of one modulation, ack/unack mode

If BEP for only one modulation is available, the RLC estimates BEP for the other
modulation. The table below is used to convert the MEAN_BEP value to the other
modulation. The same CV_BEP value can be used for both modulations.
Reported GMSK Estimation for 8- Reported 8- Estimation for GMSK
MEAN_BEP PSK PSK MEAN_BEP
MEAN_BEP MEAN_BEP
07 0 0 3
89 1 1 8
10 11 2 2 10
12 13 3 3 12
14 15 4 4 14
16 18 5 5 17
19 20 6 6 19
21 23 7 7 22
24 25 8 8 24
26 28 9 9 27
29 30 10 10 29
31 11 11-31 31
Table 19-10:Relationship of GMSK and 8PSK mean BEP.

19.2.2.2 Handling of user define offsets, ack/unack mode

The user defined offsets are added to the mean bep values.
219
GMSK_MEAN_BEP = GMSK_MEAN_BEP + MEAN_BEP_OFFSET_GMSK;
Version: 16.0 Nokia Networks
Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

8-PSK_MEAN_BEP = 8-PSK_MEAN_BEP + MEAN_BEP_OFFSET_8-PSK;

19.2.2.3 MCS selection based on BLER limits, ack/unack mode

There is a table per MCS that maps the pair (MEAN_BEP, CV_BEP) to BLER. The
BLER values for each MCS are searched and compared to the "Maximum BLER
acknowledged mode" or "Maximum BLER unacknowledged mode" on whether the
mode is ACKed or UNACKed. The Maximum BLER limit for ACK/UNACK mode is
calculated from the ABQP parameter. The RLC ACK mode maximum allowed BLER
is determined from transfer_delay value, if available. In RLC unacknowledged
mode maximum allowed BLER is determined from sdu_error_ratio value, if
available. If the ABQP parameter is not available, BLER values are determined
by the operator parameter QC_UNACK_BLER_LIMIT_T and
QC_ACK_BLER_LIMIT_T for Not Available field. The highest MCS that satisfies
the BLER limit is chosen.

The GMSK _MEAN_BEP and GMSK _CV_BEP are used with GMSK BLER tables
and 8-PSK _MEAN_BEP and 8-PSK _CV_BEP are used with 8-PSK BLER tables.

If MS does not support 8-PSK in the uplink, a GMSK MCS is chosen in the uplink.

For UNACKed mode, this is the selected MCS used for all transmissions.

For ACKed mode, the minimum of this value and the value from optimal MCS
selection is the selected MCS for initial transmissions of each new RLC block.

19.2.2.4 Optimal MCS selection for initial transmission, ack mode

START

Modulation
GMSK selection 8-PSK

Get optimal_MCS Get optimal_MCS


from GMSK table from 8-PSK table

READY

Figure 19-2: Optimal MCS

19.2.2.5 Modulation Selection

Modulation is selected first. Modulation selection is based on 8-PSK MEAN_BEP, 8-


PSK CV_BEP and GMSK_MEAN BEP according to the table below. If MS does not
support 8-PSK in the uplink, GMSK is chosen in the uplink.

220

Version: 16.0 Nokia Networks


Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

8PSK CV_BEP 0 1 2 3 4 5 6 7
8PSKMEAN_BEP
0 4 4 4 4 4 4 4 4
1 6 6 6 6 6 6 5 5
2 9 9 9 9 9 9 7 6
3 32 32 32 32 21 12 11 8
4 32 32 32 32 32 20 13 12
5 32 32 32 32 32 24 21 21
6 31 32 32 32 32 32 32 32 32
Table 19-11:GMSK mean BEP limits for modulation selection.

The items in the table above are the 8PSK MEAN_BEP and CV_BEP values. The
table is used as follows: the algorithm locates an entry in the table based on
measured 8PSK MEAN_BEP and CV_BEP values. This entry is compared to the
measured GMSK MEAN_BEP value. If the measured GMSK value is larger or equal
to the entry from the table, then GMSK is chosen, otherwise 8PSK is chosen.

19.2.2.6 Optimal MCS selection

After the modulation has been selected the MCS is selected. MCS selection is based
on the MEAN_BEP and CV_BEP of the selected modulation. The tables below are
used for MCS selection.
GMSK_CV_BEP 0 1 2 3 4 5 6 7
GMSK_MEAN_BEP
03 1 1 1 1 1 1 1 1
4 2 2 1 1 1 1 1 1
5 2 2 2 1 1 1 1 1
6 2 2 2 2 2 2 1 1
79 2 2 2 2 2 2 2 2
10 19 3 3 3 3 3 3 3 3
20 31 4 4 4 4 4 4 4 4
Table 19-12:MCS selection table for GMSK.
8-PSK_CV_BEP 0 1 2 3 4 5 6 7
8-PSK_MEAN_BEP
03 5 5 5 5 5 5 5 5
4 6 5 5 5 5 5 5 5
5 6 6 5 5 5 5 5 5
6 6 6 6 5 5 5 5 5
7 6 6 6 5 5 5 5 5
8 6 6 6 6 5 5 5 5
9 6 6 6 6 6 5 5 5
10 16 6 6 6 6 6 6 6 6
17 21 7 7 7 7 7 7 7 7
22 25 8 8 8 8 8 8 8 8
26 31 9 9 9 9 9 9 9 9
Table 19-13:MCS selection table for 8-PSK.

221

Version: 16.0 Nokia Networks


Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

19.2.2.7 MCS selection downlink for retransmission, ack mode

For 8-PSK modulation, the table below shows the maximum MCS used for
retransmissions.
8-PSK_CV_BEP 0 1 2 3 4 5 6 7
8-PSK_MEAN_BEP
03 6 6 6 6 6 6 6 6
4 21 7 7 7 7 7 7 7 7
22 31 9 9 9 9 9 9 9 9
Table 19-14:Selection of maximum MCS for retransmissions (only for 8-PSK).

19.2.2.8 MCS reducing for downlink transmission if MS out of memory (IR), ack mode

There is a PRFILE parameter that controls this function. The


PR_NR_T_MEMORY_OUT_FLAG_SUM parameter is used to activate the MS Out
of Memory exception procedure in RLC to reduce the number of MCSs used.
Allowed values for PR_NR_T_MEMORY_OUT_FLAG_SUM are 0 - 7. Value 0
deactivates algorithm use.

During IR operation in downlink packet transfer, MS may report MS Out of Memory


condition in EGPRS PACKET DOWNLINK ACK/NACK Message. If there has been
such report in PR_NR_T_MEMORY_OUT_FLAG_SUM or more consecutive EGPRS
PACKET DOWNLINK ACK/NACK Message the RLC reduces the MCSs given by link
adaptation. The RLC reduces MCSs using the tables below. The reduction is done
until MS reports it has enough memory.
MCS from LA algorithm Reduced MCS
1 1
2 1
3 2
4 3
5 5
6 5
7 6
8 7
9 7
Table 19-15:MCS for initial downlink transmission (MS Out of Memory)
MCS from LA algorithm Reduced MCS
6 6
7 6
9 7
Table 19-16:MCS for downlink retransmission (MS Out of Memory)

The RLC has internal MEMORY_OUT_FLAG_SUM parameter that is used as


follows:

if(MSreportsMSOutofMemorycondition)and
(MEMORY_OUT_FLAG_SUM < PR_NR_T_MEMORY_OUT_FLAG_SUM)then 222
MEMORY_OUT_FLAG_SUM = MEMORY_OUT_FLAG_SUM + 1
Version: 16.0 Nokia Networks
Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia:
IMS GW R1 (Embedded version) - Application Software High Level Design

if(MSreportsMShasenoughmemory)then
MEMORY_OUT_FLAG_SUM=0

if(MEMORY_OUT_FLAG_SUM = PR_NR_T_MEMORY_OUT_FLAG_SUM) then


reducedownlinkMCSs

19.2.2.9 MCS limiting for CX3.2 BTS software

The CX3.2 software does not support MCS-8 and MCS-9.

The DX SW (PUB/GUP) informs the PCU (message pcu_seg_params_rnwdb_s)


about maximum MCS that the RLC is allowed to use in a cell. In the case of UltraSite
CX3.2 the system sets maximum MCS to MCS-7, otherwise to MCS-9. The BSC
internal parameter max_MCS is used for this purpose. The system checks the
UltraSite SW level from the BTS SW package, and makes the decision based on
that.

If the LA has given bigger MCS than the max_MCS then the RLC replaces the MCS
with max_MCS. The RLC does it for both initial transmission MCS and
retransmission MCS.

If the operator setting for Initial MCS is bigger than max_MCS then Initial MCS is
replaced with max_MCS.

223

Version: 16.0 Nokia Networks


Date: 2007-June-11 Company Confidential
Created by: Monisha J, Ruchi M, Monisha M, Rajesh J, Anil S
Approved by: Aricent:Pratyush Dasgupta
Nokia: