Professional Documents
Culture Documents
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
: : : : :
PREDISTRIBUTION
NE NE/Romania NE/Egypt J. ANDRES S. BODEA N. GEORGE NE/Quality & Partnership NE/GSM NE/GSM/Egypt NE/GSM/Romania LF.GONNOT F. Colin S. Abdel-Wahab C. Inta
ABSTRACT
This document presents the EDGE optimisation methodologies, for B9 release.
KEYWORDS
GSM, EDGE, EGPRS, B9, Optimisation Approvals NE/GSM Date:
NE Date:
J. ANDRES Signature:
F. Colin Signature:
Date:
Signature:
Date:
Signature:
ED NE
011 1/2
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
HISTORY
Edition 01 1 Status Draft Release Date May. 23rd, 2007 June, 29th, 2007 Comments Draft Creation First edition
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
DISTRIBUTION LIST
NE
END OF DOCUMENT
TABLE OF CONTENTS
1 INTRODUCTION ....................................................................................................... 5 2 ALGORITHMS AND PARAMETERS ................................................................................. 6
2.1 MAIN EDGE CONCEPTS......................................................................................................................... 6 2.2 HARDWARE AND POWER ASPECTS ......................................................................................................... 7 2.3 ENHANCED TRANSMISSION RESOURCE MANAGEMENT ............................................................................. 8
2.3.1 M-EGCH STATISTICAL MULTIPLEXING....................................................................................................................... 8 2.3.2 DYNAMIC ABIS ALLOCATION.................................................................................................................................. 10 2.3.3 ATER RESOURCE MANAGEMENT ............................................................................................................................ 12 2.3.4 DL RETRANSMISSION IN THE BTS .......................................................................................................................... 13
2.4 AUTONOMOUS PACKET RESOURCE ALLOCATION (RAE4) ........................................................................ 13 2.5 M-EGCH LINK MANAGEMENT .............................................................................................................. 22
2.5.1 DEFINITIONS........................................................................................................................................................ 22 2.5.2 ABIS SELECTION IN M-EGCH LINK.......................................................................................................................... 22 2.5.3 M-EGCH LINK SIZE ............................................................................................................................................... 23 2.5.4 PERIODICAL GCH ESTABLISHMENT PROCESS .......................................................................................................... 23 2.5.5 FAST INITIAL PS ACCESS ....................................................................................................................................... 24 2.5.6 HANDLING OF UNUSED GCH ................................................................................................................................. 24 2.5.7 M-EGCH LINK CAPACITY DECREASE ....................................................................................................................... 25
2.8 EXTENDED UL TBF MODE ................................................................................................................... 37 2.9 ENHANCED PACKET CELL RESELECTION............................................................................................... 39
2.9.1 NETWORK ASSISTED CELL CHANGE PROCEDURES (NACC) ...................................................................................... 39 2.9.2 PACKET (P)SI STATUS PROCEDURE ........................................................................................................................ 42
ED NE
011 2/2
B9_EDGE_Optimisation_Guide_ed1.doc 20070629
3 NETWORK DIMENSIONING........................................................................................54
3.1 ABIS ..................................................................................................................................................55 3.2 ATER .................................................................................................................................................57
3.2.1 3.2.2 3.2.3 3.2.4 METHOD 1 ...........................................................................................................................................................57 METHOD 2 ...........................................................................................................................................................58 NUMBER OF GCH NEEDED.....................................................................................................................................59 HSDS IMPACT .......................................................................................................................................................59
4 NETWORK PRIORITIES.............................................................................................64
4.1 PHASE 1 ............................................................................................................................................64 4.2 PHASE 2 ............................................................................................................................................64 4.3 PHASE 3 ............................................................................................................................................65
5 QOS FOLLOW-UP....................................................................................................66
5.1 TBF LIFE TIME ...................................................................................................................................66
5.1.1 TBF ESTABLISHMENT ............................................................................................................................................66 5.1.2 TBF DATA TRANSFER.............................................................................................................................................67 5.1.3 TBF REALLOCATION .............................................................................................................................................70
5.3 RADIO RESOURCES .............................................................................................................................76 5.4 TRANSMISSION RESOURCES.................................................................................................................77 5.5 RNO REPORTS....................................................................................................................................77 5.6 END-USER STATISTICS.........................................................................................................................79
6.3 UL PERFORMANCE..............................................................................................................................90
6.3.1 RESEGMENTATION VS IR .......................................................................................................................................90 6.3.2 EXTENDED UL TBF MODE ......................................................................................................................................90
6.4 ACCESS TIME OPTIMIZATION ...............................................................................................................91 6.5 EDGE PERFORMANCE VERSUS FREQUENCY PLANNING...........................................................................91 6.6 ABIS CONGESTION..............................................................................................................................91 6.7 ATER CONGESTION.............................................................................................................................92 6.8 GSS OPTIMISATION FOR GMM/SM SIGNALLING......................................................................................95
ED NE
011 3/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
REFERENCED DOCUMENTS
Table 1: Referenced Documents [1] [2] [3] EDGE Field Trial Guideline, ed4 B9 MR1 Features Review, Methodology and Field Feedback 3GPP TS 05.08, Radio subsystem link control 3DF 01902 2015 VAZZA 3DF 01906 2913 VAZZA
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
RELATED DOCUMENTS
Table 2: Related Documents [i1] [i2] [i3] (E)GPRS Radio Interface - RLC sub-layer (E)GPRS Radio Interface - RRM sub-layer (PRH) (E)GPRS Radio Interface - RRM sub-layer (PCC) 3BK 11202 0392 DSZZA 3BK 11202 0390 DSZZA 3BK 11202 0391 DSZZA
SCOPE
PURPOSE OF THE DOCUMENT
This document is a guideline of EDGE optimisation methods, for B9 release. It gives the direction for the optimisation process and it tries to focus in the main topics and issues.
AREA OF APPLICATION
This template should be used within NE and RSC for all ALCATEL-LUCENT, it is an internal document.
ED NE
011 4/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
1 INTRODUCTION
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
3DF 01900 0000 PTZZA DIAMS
This document is a guideline for EDGE optimization for B9 MR1. It does not include the B9MR4 software features (PS in extended cell, QoS handling) and the B9MR4 hardware features (Twin module). It has a theoretical introduction of the PS features, follow by a chapter of network dimensioning and QoS follow-up. To finalize there is a chapter explaining possible optimisation methods.
ED NE
011 5/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Coding scheme CS1 CS2 CS3 CS4 MCS1 MCS2 MCS3 MCS4 MCS5 MCS6 MCS7 MCS8 MCS9
Table 3: Coding Schemes Coding scheme Family Modulation Theoretical throughput per PDCH (kbit/s) GMSK 8 GMSK 12 GMSK 14.4 GMSK 20 Family C GMSK 8.8 Family B GMSK 11.2 Family A/ GMSK 14.8 / 13.6 Family A padding Family C GMSK 17.6 Family B 8-PSK 22.4 Family A/ 8-PSK 29.6 / 27.2 Family A padding Family B 8-PSK 44.8 Family A padding 8-PSK 54.4 Family A 8-PSK 59.2
Retransmission mechanism, or ARQ (Automatic Repeat request), has been greatly modified in EDGE. The first modification comes from the introduction of the payload concept. In an EGPRS TBF the RLC block can be retransmitted either by using the same MCS or by using a MCS from the same coding scheme family. A side effect from this is that even if Link Adaptation (algorithm that changes the coding scheme according to radio conditions) is disabled, we can observe RLC blocks with different coding schemes (although always with the same family). Still in the ARQ mechanism, EDGE introduces a new type of ARQ. Now we have: o o Type 1 ARQ the decoding of a re-transmitted RLC block does not take into account the previously transmitted versions of this same RLC block. It is always used in GPRS. Type 2 hybrid ARQ (used only in EGPRS) also known as Incremental Redundancy (IR), it is always used in downlink EGPRS and for uplink, in B9, it can be activated by a flag. This mechanism works as follows: 1 RELEASED 3DF XXXX XXXX PTZZA 011 6/96
3DF 01900 0000 PTZZA DIAMS
ED NE
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
o o
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
The first emission of the RLC block is done with a first puncturing scheme (PS1). If the RLC block needs to be retransmitted, the same MCS or a MCS from the same family will be used. The block may or may not be re-segmented (depending on parameterisation). The transmitter will also select the Puncturing Scheme to use. The receiver will use the information in all versions of the received block to increase its decoding probability.
Note that 3GPP states that: o o o IR is mandatory in MSs receiver; There is no way to activate/de-activate IR in the MS receiver by signalling over the air-interface IR can only be de-activated in the case of insufficient memory in the mobile; The soft combining can be done between MCSx and MCSx blocks (same MCS used), a MCS9 and a MCS6 block (RLC data blocks with the same number of payload units) or between a MCS7 block and a MCS5 block (RLC data blocks with the same number of payload units).
The RLC Window management also changes in EDGE. While in GPRS the RLC window size is fixed at 64 blocks, in EDGE: o o o It is variable and determined for each TBF depending on the MS multi-slot class; It varies between 64 and 1024 blocks (512 blocks in Alcatel-Lucent implementation); It is increased following an increase on the number of PDCHs, but not decreased in the case of a reduction.
Table 4: Power characteristics from the different available TRA (EDGE capable TREs). 8-PSK output power TRA GMSK output power 8-PSK output power (EDGE+ TRA) 900 Medium power 45 W / 46.5 dBm 15 W / 41.8 dBm 30 W / 44.8 dBm 900 High power 1800 Medium power 1800 High power 60 W / 47.8 dBm 35 W / 45.4 dBm 60 W / 47.8 dBm 25 W / 44 dBm 12 W / 40.8 dBm 25 W / 44 dBm 30 W / 44.8 dBm 30 W / 44.8 dBm 30 W / 44.8 dBm
Because GMSK output power is often different from 8-PSK output power, there is a new concept introduced with EDGE the Average Power Decrease (APD). According to the 3GPP specs, there are some constraints on this parameter when the TRE responsible for the EDGE service is also carrying the BCCH. [3] it states that:
3DF 01900 0000 PTZZA DIAMS
Furthermore, 8-PSK modulated timeslots on the BCCH carrier may use a mean power which is at most 4 dB lower than the mean power used for GMSK modulated timeslots, with the exception of the timeslot preceding a slot used for BCCH/CCCH where at most 2 dB lower mean power is allowed. (3GPP 45.008 5.i.0, section 7.1) 3GPP also predicts some specific problems for fast moving mobiles, in [3]: ED NE 1 RELEASED 3DF XXXX XXXX PTZZA 011 7/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
In the case that 8-PSK modulation is allowed on the BCCH carrier and frequency hopping including the BCCH carrier is used, the reception quality in connected mode for some fast moving MS (meaning MS experiencing Doppler frequencies of 100 Hz or more) may be degraded. This may be seen as a backwards compatibility problem for some existing MS, most likely occurring if the used APD is larger than 2 dB. (3GPP 45.008 5.i.0, section 7.1) The field tests performed didnt show any negative impact, which just confirms that only older mobiles are prone to have problems, we can say that: It is possible to use normally the BCCH TRX for EDGE without any re-configuration or output power modification.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
The next figure explains the evolution between B8 and B9 release. The EGCH defined per RTS (PDCH) is swapped by the new concept of the M-EGCH link per TRX, defined in B9. This enhancement allows the dynamic of the GCHs among the PDCHs of a TRX. With the change, it is possible to have better reuse of the existing resources.
1
EGCH GCH GCH
2
EGCH GCH GCH
3
EGCH
6
EGCH
7
EGCH
EGCH
EGCH
M-EGCH link
composed of
composed of GCH
GCH
GCH GCH
GCH
3DF 01900 0000 PTZZA DIAMS
GCH
1 to 36 GCHs
Figure 21: B8 release EGCH vs B9 release M-EGCH ED NE 1 RELEASED 3DF XXXX XXXX PTZZA 011 8/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
The location of the M-EGCH and L1-GCH layers is show in the figure below. The M-EGCH layer offer a service of data transport to the upper layer the RLC/MAC layer.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
The way the RLC/MAC PDU are filling an M-EGCH link is explained by the next figure.
MEGCH header (next segments) SYNC pattern + Z bit indicator 320 bits
Dummy Filling
320 bits
320 bits
320 bits
MEGCH header (/NHP and addr byte) Dummy Filling PDU CRC + Tail bits Padding bits
DBN=x+1
DBN=x+2
Dummy Filling
20 ms
20 ms
20 ms
In this example 2 RLC/MAC PDUs are not enough to fill the 5 GCH, therefore the M-EGCH fills it with padding bits or with a dummy message. Important to mention is the dynamic of the process which lead to a ED NE 1 RELEASED 3DF XXXX XXXX PTZZA 011 9/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
better bandwidth usage. The RLC/MAC PDU is segmented through several M-EGCH frames and one M-EGCH can transport segments from different RLC/MAC PDUs. In B8, due to the static approach the number of GCHs needed per PDCH was higher than in B9, see next two tables. Table 5: Number of GCH per GPRS coding scheme. Nb_GCH in Nb_GCH in Max_GPRS_CS B8 B9 CS-1 1 0,73 CS-2 CS-3 CS-4 1 2 2 1,00 1,25 1,64
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Table 6: Number of GCH per EGPRS coding scheme. Nb_GCH in Nb_GCH in Max_EGPRS_MCS B8 B9 MCS-1 1 0,89 MCS-2 MCS-3 MCS-4 MCS-5 MCS-6 MCS-7 MCS-8 MCS-9 1 2 2 2 3 4 4 5 1,00 1,33 1,50 1,86 2,36 3,49 4,14 4,49
The dynamic transportation of the RLC/MAC PDU brings a more efficient resource usage also due to: o o Instantaneous reaction to radio variations (MCS variations). The resources not used by delayed DL TBFs, extended UL TBFs, are used by other TBFs.
ED NE
011 10/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Figure 24: Abis resources concept in B8 In this B8 release example, 50% of the Abis resources are wasted, in B9 all the Abis nibbles can be used, as explained after.
In B9, the following Abis nibbles are usable for PS traffic: o o The basic Abis nibbles mapped to a RTS currently available for PS traffic (see Autonomous Packet Resource Allocation" feature to know the list of those RTSs) or mapped to a RTS used as MPDCH. The bonus basic Abis nibbles are the ones not used by the BCCH or static SDCCH channels, these channels are mapped in the RSL TS. Depending on the cell configuration more or less bonus Abis nibbles are available. All the extra Abis nibbles of the BTS, can be used by the PS. A number of 64k extra Abis TSs (4x16kbit/s extra Abis nibbles) is defined for each BTS by O&M (N_EXTRA_ABIS_TS). The list of extra Abis TSs of a BTS is provided by the BSC to the MFS.
To have a better view of the B9 dynamic Abis concept, see the follow example applied in B9:
ED NE
011 11/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
The 16kbit/s Abis nibbles can be used/shared between M-EGCH link, the share follows specific rules depending the Abis nibble type: o o o The basic Abis nibbles mapped on a RTS allocated to MFS can be used in the M-EGCH link of any TRX of the CELL. The extra Abis nibbles can be used in the M-EGCH link of any TRX of the BTS. The bonus Abis nibbles can be used in the M-EGCH link of any TRX of the BTS.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
This new algorithm/concept leads into a modification of the GCH establishment and release. Two new scenarios to distribute GCH resources are created: o o Intra-cell GCH pre-emption : between TRXs of a cell Inter-cell GCH pre-emption : between cells of a BTS
To be able to implement the dynamic Abis algorithm new signalling messages were created, they are sent to the BTS via GSL and RSL interface to notify each TRE which Abis nibbles are associated.
In a given GPU the resource management is based on two complementary algorithms: o o GPU Ater TS margin High Ater usage handling.
If Ater usage is high, there is an impact in the packet switch transmission resources. The Target_Nb_GCH values associated to TRXs of the GPU supporting some PS traffic will be reduced, taking in account the parameter GCH_RED_FACTOR_HIGH_ATER_USAGE. The reduction factor is only applied on PDCHs newly open, e.g. no radio resources were previously allocated on this PDCH.
ED NE
011 12/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
o o
2) Ater usage = normal 3) Establishment of an EGPRS DL TBF on RTS0-3 o Target_Nb_GCH = 4 * Nb_GCH(Max_EGPRS_MCS) = 4 * 4,49 = 18
4) Ater usage = high 5) Establishment of an EGPRS DL TBF on RST4-7 (Ater usage high and newly open PDCH => reduction will be applied) o Target_Nb_GCH = = 4 * Nb_GCH(Max_EGPRS_MCS) + 0,5 * 4 * Nb_GCH(Max_EGPRS_MCS) = = 4 * 4,49 + 4 * 0,5 * 4,49 = 27 (< 36)
This mechanism is enabled / disabled at TRX/TRE level, however respecting the following constrains specified in the next table: Table 7: DL retransmission constrains. HW generation of the TRE EN_DL_RETRANS_BTS Round_Trip_Delay Enabled Enabled Disabled < 500 ms 500 ms CS-2 (DRFU) Disabled Disabled Disabled CS-4 (G3 or M4M) Disabled Disabled Disabled CS-4+MCS-9 (G4 or M5M) Enabled Disabled Disabled
With the introduction of the Enhanced Transmission Resource Management feature in B9, a new resource allocation was developed. This new algorithm is named Autonomous Packet Resource Allocation (RAE4) and allows taking all the benefit of the new B9 concepts. ED NE 1 RELEASED 3DF XXXX XXXX PTZZA 011 13/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
The development took in consideration the following new needs: o o Need to know the list of basic Abis nibbles which are currently available to establish GCHs, Need to know which basic Abis nibbles are preemptable / not-preemptable for CS traffic by the BSC. This information is useful: o For the QoS feature (in order to be able to ensure a given GBR for an RT PFC). To define some priorities in the Abis nibble selection (preference is given to the nonpreemptable basic Abis nibbles in order to limit the interaction of CS over PS traffic).
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Need to accelerate TBF establishment times (the B8 round trip delay between MFS and BSC to allocate some PDCHs can be avoided).
In the Autonomous Packet Resource Allocation (RAE4) algorithm the BSC evaluates the CS and PS load at cell level and calculates a number of timeslots that the MFS can use to carry PS traffic (Max_SPDCH_Limit). The resources sharing between the CS and the PS is then based on the evaluation of Max_SPDCH_Limit. The Max_SPDCH_Limit value is a comprised value between the Min_SPDCH and the Max_SPDCH and takes in account the O&M parameters (Max_PDCH, Min_PDCH, Max_PDCH_HIGH_LOAD, HIGH_TRAFFIC_LOAD_GPRS, THR_MARGIN_PRIO_PS).
Exists a periodical exchange of messages between the BSC and the MFS, with the aim to inform the MFS which timeslots can be used to serve a new TBF and to inform the BSC of the present status of PS allocated resources. The periodical exchange of messages has the following information: o o RR Allocation Indication message from BSC to MFS: provide to the MFS the mapping of the allocated SPDCHs, the periodicity of this message is TCH_INFO_PERIOD * RR_ALLOC_PERIOD. RR Usage Indication message from MFS to BSC: With a periodicity of TCH_INFO_PERIOD or in response of the previous message RR Allocation Indication message, informs the BSC with the current usage of the allocated SPDCHs.
TCH_INFO_PERIOD = 5s
The TCH usage samples calculate by the BSC every TCH_INFO_PERIOD are map in the internal parameters: o o o o ED NE NB_USED_CS_TS(k) - SPDCH State is deallocated
3DF 01900 0000 PTZZA DIAMS
NB_USED_PS_TS(k) - SPDCH State is allocated or de-allocating NB_USED_TS(k) = NB_USED_CS_TS(k) + NB_USED_PS_TS(k) NB_UNUSED_TS(k) 1 RELEASED 3DF XXXX XXXX PTZZA 011 14/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Every RR_ALLOC_PERIOD * TCH_INFO_PERIOD, the BSC computes three averaged values through a sliding window of size LOAD_EV_PERIOD_GPRS (default value = 3), these averages of the previous internal parameter give the following internal parameters, used to calculate Max_SPDCH_Limit: o o o
k-
RR_ALLOC_PERIOD * TCH_INFO_PERIOD
LOAD_EV_PERIOD_GPRS = 3
Figure 27: Cyclic calculation of the average usage of the cell resources
MAX_SPDCH_LIMIT CALCULATION
The calculation of the Max_SPDCH_Limit follows the diagram below:
O&M parameters
MIN_SPDCH MAX_SPDCH
NB_TS
Computation of Thresholds
MAX_SPDCH_HIGH_LOAD
Computation of MAX_SPDCH_LIMIT
MAX_SPDCH_LIMIT
MARGIN_PRIORITY_CS MARGIN_PRIORITY_PS
THR_MARGIN_PRIORITY_CS THR_MARGIN_PRIORITY_PS
ED NE
011 15/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
1) Computation of thresholds The calculation of MIN_SPDCH, MAX_SPDCH and MAX_SPDCH_HIGH_LOAD is done every RR_ALLOC_PERIOD * TCH_INFO_PERIOD to take into account possible TRX failures. The O&M parameters (MIN_PDCH, MAX_PDCH and MAX_PDCH_HIGH_LOAD) are multiply by the ratio: o Where: NB_TS: Total number of TCH/VGCH, TCH/SDCCH, or TCH/SPDCH/VGCH timeslots available in the cell. This parameter is re-computed every RR_ALLOC_PERIOD * TCH_INFO_PERIOD to take into account possible TRX failure. NB_TS_DEFINED: total number of TCH, TCH/SDCCH or TCH/SPDCH timeslots available in the cell if there is no TRX failure. This parameter is retrieved from the O&M configuration of the cell.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
In case there isnt master channel (NB_TS_MPDCH=0) (AVAILABILITY_TS_RATIO=100%) then there is simply: o o o MAX_SPDCH_HIGH_LOAD = MAX_PDCH_HIGH_LOAD MIN_SPDCH = MIN_PDCH MAX_SPDCH= MAX_PDCH
and
there
is
no
TRX
failure
2) Computation of CS/PS Margin Two new margins, one for CS traffic and one for PS traffic are introduced to guarantee that a certain number of timeslots are kept available for the arrival of new calls between two transmissions of the RR Allocation Indication message: o the first margin, named MARGIN_PRIORITY_CS (k), is dedicated to CS traffic o Where: THR_MARGIN_PRIO_PS is O&M parameter, It is the margin of radio timeslots reserved for PS traffic between two sendings of the BSCGP RR Allocation Indication messages. The threshold is expressed in percentage of radio timeslots. This margin only applies in case of high CS load and low PS load. THR_MARGIN_PRIO_CS is equal to the 1- High_Traffic_ Load_GPRS. High_Traffic_ Load_GPRS: Load threshold used to determine a certain margin of radio timeslots reserved for CS traffic between two sending of the BSCGP RR Allocation Indication messages. The threshold is expressed in percentage of the radio timeslots available in the cell. These two margins are re-evaluated every RR_ALLOC_PERIOD * TCH_INFO_PERIOD, before the computation of MAX_SPDCH_LIMIT = (THR_MARGIN_PRIO_CS * (NB_TS(k) MAX_SPDCH_HIGH_LOAD(k)) / 100
the second margin, named MARGIN_PRIORITY_PS(k), is dedicated to PS traffic = (THR_MARGIN_PRIO_PS * MAX_SPDCH_HIGH_LOAD(k)) / 100
3) Computation of MAX_SPDCH_LIMIT The basic idea to evaluate MAX_SPDCH_LIMIT is to estimate the number of unused TS and to share them between CS and PS traffic, taking into account both margins (for CS and PS traffics) defined to guarantee a certain number of TS available to serve incoming calls.
3DF 01900 0000 PTZZA DIAMS
ED NE
011 16/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
MARGIN_PRIORITY_CS
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
AV_USED_CS_TS(k) AV_UNUSED_TS(k)
Computation of MAX_SPDCH_LIMIT_CS
MAX_SPDCH MAX_SPDCH_HIGH_LOAD
AV_USED_PS_TS(k)
Computation of MAX_SPDCH_LIMIT_PS
MIN_SPDCH MARGIN_PRIORITY_PS
3.1) Computation of MAX_SPDCH_LIMIT_CS The MAX_SPDCH_LIMIT_CS determines the maximum number of SPDCHs that can be allocated to the MFS in order to ensure that a certain number of timeslots (margin) is kept in the BSC to serve possible incoming CS requests, received between two sends of the RR Allocation Indication message. It is given by: o Where: o MARGIN_CS(k) = max(MARGIN_PRIORITY_CS(k), AV_UNUSED_TS(k) / 2) MAX_SPDCH_LIMIT_CS(k) = RoundDown [ NB_TS(k) AV_USED_CS(k) - MARGIN_CS(k) ]
The MAX_SPDCH_LIMIT_PS determines the minimum number of SPDCHs that should be allocated to the MFS in order to ensure that a certain number of timeslots (margin) is kept in the MFS to possibly serve incoming PS requests. If AV_USED_PS_TS(k) MIN_SPDCH then o else o MAX_SPDCH_LIMIT_PS(k) = RoundUp (AV_USED_PS_TS(k) + MARGIN_PRIORITY_PS(k)) MAX_SPDCH_LIMIT_PS(k) = MIN_SPDCH(k)
3.1) Computation of MAX_SPDCH_LIMIT The MAX_SPDCH_LIMIT calculation can be in the range of [MIN_SPDCH, MAX_SPDCH] and its value can be either MAX_SPDCH_LIMIT_CS or MAX_SPDCH_LIMIT_PS.
ED NE
011 17/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
MAX_SPDCH
MAX_SPDCH_LIMIT_CS
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
MAX_SPDCH_HIGH_LOAD Zone where MAX_SPDCH_LIMIT = MIN (MAX_SPDCH_LIMIT_PS, MAX_SPDCH_HIGH_LOAD) MAX_SPDCH_LIMIT_PS 0 MIN_SPDCH MAX_SPDCH_HIGH_LOAD MAX_SPDCH
MIN_SPDCH
MAX_SPDCH_LIMIT TS SELECTION
Every TCH_INFO_PERIOD * RR_ALLOC_PERIOD, the BSC sent to MFS the Radio Resource Allocation Indication message. This message contains the SPDCHs Allocation bitmap, e.g the information whether a timeslot is allocated to the MFS or not. In response to the RR Allocation Indication message or every TCH_INFO_PERIOD, the MFS sent to BSC the Radio Resource Usage Indication message. The RR Usage Indication message contains 3 different bitmaps, the analysis of the bitmaps gives the present status of the timeslots: o o The SPDCHs_Confirmation bitmap is used to update the SPDCH allocation state of each timeslot. The SPDCHs_Usage and SPDCHs_Radio_Usage bitmaps allow to update the occupancy state of the timeslot at unused or used (from radio and/or transmission point of view for the SPDCHs_Usage bitmap and from radio point of view only for the SPDCHs_Radio_Usage bitmap).
The TS selection, e.g the Radio TCH allocation, uses the TRX ranking table. This table takes in account both HW capability and design O&M parameters. The way to set the priority of the PS capable TRX (TRX_PREF_MARK = 0) is slightly modified in B9 release with the introduction of a frequency band criterion: o o o o o o PS_PREF_BCCH_TRX HW TRE capability (G4 HP -> G4 MP -> G3) DR TRE capability (FR TRX -> DR TRX) E-GSM TRX preference (new in B9, E-GSM TRX -> P-GSM/GSM850/DCS TRX) TRX having the maximum number of consecutive SPDCHs TRX identity (low TRX id -> high TRX id)
3DF 01900 0000 PTZZA DIAMS
With the PS capable TRX list performed, the next step consists in ordering the PS timeslots and the PS capable TRX, to obtain an ordered list of TCH/SPDCH timeslots. The selection of the TRX is done, selecting first the TRX having the lowest rank in the TRX ranking table. Once the TRX has been selected, the
ED NE
011 18/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
TCH/SPDCH timeslots is selected preferentially to the lowest timeslot index, i.e. the one located at the most left side of the TRX is selected first. The SPDCHs are allocated according to the different PS TS zones, the zones definitions are:
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
o o
MAX_SPDCH_HIGH_LOAD zone: this zone corresponds to the MAX_SPDCH_HIGH_LOAD consecutive PS capable TS that are preferred for PS allocation. In this zone, allocated TBFs cannot be pre-empted Non pre-emptable PS zone: this zone is always inside the MAX_SPDCH_HIGH_LOAD zone, in this latter zone, we search for the right most TS allocated to the MFS and used, then all the TS located at its left define the non pre-emptable PS zone. Inside this zone, a TS: remains allocated to the MFS if already allocated to the MFS is allocated to the MFS if previously allocated to the BSC and unused remains allocated to the BSC if already allocated to the BSC and used
MAX_SPDCH_LIMIT zone: this zone corresponds to the MAX_SPDCH_LIMIT consecutive PS capable TS that are preferred for PS allocation. Inside this zone, a TS: remains allocated to the MFS if already allocated to the MFS is allocated to the MFS if previously allocated to the BSC and unused remains allocated to the BSC if already allocated to the BSC and used
PS traffic zone: this zone corresponds to the larger zone between the non pre-emptable PS zone and the MAX_SPDCH_LIMIT zone
As examples of the PS TS zones follows the next two: Example 1: MAX_SPDCH_HIGH_LOAD = 8, MAX_SPDCH_LIMIT = 10
MAX_SPDCH_HIGH_LOAD zone
Figure 211: PS TS zones example 1 This feature should be enhanced, so that the number of allocated PDCH corresponds to MAX_SPDCH_LIMIT
PS 2 3
CS
CS
PS 6
CS 7 8
CS 9
CS 10
CS 11
CS 12 13 TRX1 14 15
CS 16
4 5 TRX2
MAX_SPDCH_HIGH_LOAD zone
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
The selection of the TCH/SPDCH TS begins with the non pre-emptable PS zone. All the TS in this zone, that can be or are allocated to the MFS, will be allocated to the MFS. The verification in terms of number of TS allocated to the MFS is done only when all the TS inside this zone have been handled. If at the end of the non pre-emptable PS zone, the number of selected TS for the MFS is strictly lower than MAX_SPDCH_LIMIT then the process of selection continues in the MAX_SPDCH_LIMIT zone If at the end of the MAX_SPDCH_LIMIT zone, the number of selected TS for the MFS is still lower than MAX_SPDCH_LIMIT, the process continues outside this zone until this number reaches MAX_SPDCH_LIMIT. Once MAX_SPDCH_LIMIT TS have been selected, all the remaining TCH/SPDCH TS are now allocated to the BSC, even if they were previously allocated to the MFS. This means that a TS with a SPDCH allocation state set to allocated has its SPDCH allocation state set to de-allocating.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
1) Pre-reservation mechanism in the PS traffic zone: In order to increase the PS capacity and limit the occurrence of holes in the SPDCHs_Allocation bitmap, each TCH/SPDCH capable TS carrying CS traffic and located inside the PS traffic zone, has its prereservation state set to pre-reserved for PS. No new incoming CS call can be served on this TS, if it becomes unused once it is pre-reserved for PS. This is valid until the TS becomes not pre-reserved for PS again and of course still handled by the BSC. The modification of the value of the pre-reservation state can only occur when the SPDCHs_Allocation bitmap is built, every TCH_INFO_PERIOD * RR_ALLOC_PERIOD seconds.
2) CS calls in the Non pre-emptable PS zone: To speed up the release of TS carrying a CS call inside both the non pre-emptable PS zone and the MAX_SPDCH_LIMIT zone, it is proposed to reallocate the concerned CS call in the CS zone using an intra-cell handover. If EN_RETURN_CS_ZONE_HO = enabled, each time MAX_SPDCH_LIMIT is calculated, the BSC shall check whether TCHs are allocated in both the MAX_SPDCH_LIMIT zone and the non pre-emptable PS zone. In this case, it shall send a Start HO (cause 30) message to the HO Preparation entity, to trigger an intracell handover, to move these TCHs into the CS zone If for any reason, the handover fails, the TCH will remain in the PS zone, until the next calculation of MAX_SPDCH_LIMIT, where a new HO could be triggered, if still needed. The TS will be considered as unused only once the handover will have been successfully performed. As the pre-reservation state of such TS is set to pre-reserved for PS, no new incoming CS call can be allocated on it.
CS PREEMPTION PROCESS
The CS pre-emption process is triggered when some radio TS are reported by the BSC as no longer allocated to the MFS. The principle can be explained by 5 steps: 1. MFS receives a RR Allocation Indication message from the BSC, and uses the SPDCHs_Allocation bitmap to determine which SPDCHs shall be given back to the BSC 2. then, MFS shall immediately send a RR Usage Indication message to the BSC with the SPDCHs_Confirmation bitmap SPDCHs not used are immediately given back to the BSC (Note : SPDCHs are considered not used if no TBF resources are allocated on those SPDCHs and their basic Abis nibbles are free). The associated basic Abis nibbles are also given back and others TBFs using these basic Abis nibbles can be impacted (see below).
3. After RR Usage Indication, TCH_INFO_PERIOD timer is restarted. Remaining impacted SPDCHs, which are in use (at least one TBF is established on those SPDCHs or the basic Abis nibbles of those
ED NE 1 RELEASED 3DF XXXX XXXX PTZZA 011 20/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
SPDCHs are used by a GCH channel), are marked as de-allocating. 4. The CS pre-emption process shall be completed before the TCH_INFO_PERIOD expiry, in order to confirm the deallocation of all the remaining pre-empted SPDCHs in the next RR Usage Indication message to be sent to the BSC. For that purpose, the internal T_PDCH_Preemption timer is set to TCH_INFO_PERIOD - 1s 5. When T_PDCH_Preemption expires, the fast preemption is launched.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Then, once the impacted best-effort TBFs have been determined, the following steps shall be played in sequence: 1) TBF release in case of too high number of TBFs If, due to the CS preemption, the number of best-effort TBFs established on a TRX will become too high according to the remaining number of GCHs in the M-EGCH link of the TRX, then some best-effort TBFs shall be released (in order to guarantee that the T_MAX_FOR_TBF_SCHEDULING constraints / the PACCH signalling traffic constraints will still be possible to fulfil for all the remaining best-effort TBFs established on the TRX). On a given TRX, the number of TBFs to be released in the XL direction is called Nb_TBFs_To_Release_XL. The Nb_TBFs_To_Release_XL TBFs which shall be released are selected as follows: o Release preferentially the best-effort XL TBFs which are impacted by the CS preemption (i.e. the best-effort TBFs established in the XL direction and whose PACCH is impacted or whose on-going max allowed (M)CS is no longer possible to serve). Then, release preferentially the best-effort XL TBFs which were established (or reallocated) on the TRX the most recently (i.e. the newest best-effort TBFs established in the XL direction on the TRX).
2) T1 TBF reallocation The not released TBFs are attempted to be T1 reallocated (soft-preemption process).
0 1 2 3 4 5 6 7
No T1 candidate T1 candidate
DL UL
0 1 2 3 4 5 6 7
Figure 213: T1 reallocation The TBFs impacted by the CS preemption are managed by the soft preemption process, the impacted besteffort TBFs are:
3DF 01900 0000 PTZZA DIAMS
o o
The best-effort TBFs having their PACCH impacted, i.e. their PACCH is supported by a preempted RTS (that case is valid for both Evolium and DRFU BTSs), The best-effort TBFs for which it will no longer be possible to serve their on-going max allowed (M)CS because of the subsequent reduction of the M-EGCH link size of their TRX. Note: the M-EGCH
ED NE
011 21/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
links whose size will be reduced can be on the TRX containing the preempted RTSs or on any of the other TRXs of the cell (because basic Abis nibbles are shareable among all the TRXs of the cell).
TRX capabilities for GPRS (maximum CS) and for EGPRS (EGPRS possible or not, maximum MCS) are defined at MFS side using: HW PS capability for each TRX, Max_GPRS_CS O&M parameter, En_EGPRS O&M parameter, Max_EGPRS_MCS O&M parameter.
Table 8: HW PS capability TRE generation HW PS capability of the TRX G2 (TRE in a DRFU BTS) CS-1/2 G3 (TRE in an Evolium BTS) G4 (TRE in an Evolium BTS) CS-1/4 CS-1/4 + MCS-1/9
o o
TRX is said established if there is an M-EGCH link associated to this TRX with GCHs. Non CS Preemptable GCH: GCH, whose Abis nibble is not CS preemptable: Extra Abis nibble, Bonus Abis nibble, Basic Abis nibble mapped on a RTS inside the Max_SPDCH_High_Load zone.
CS Preemptable GCH: GCH, whose Abis nibble is CS preemptable: Basic Abis nibble mapped on a RTS outside the Max_SPDCH_High_Load zone.
If there arent enough free Abis nibbles, or free Ater nibbles, then GCH preemption will be used: o o The inter-cell GCH preemptions for PS traffic (the source TRX and the target TRX belong to two different cells of the same BTS). The intra-cell GCH preemptions for PS traffic (the source TRX and the target TRX belong to the same cell)
3DF 01900 0000 PTZZA DIAMS
ED NE
011 22/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
As mention in the chapter 2.3.1 the M-EGCH link is defined per TRX, its size in the TRX is expressed in number of GCHs. For each TRX, the following variables are defined:
o o
Established_Nb_GCH: Number of GCHs that are activated in the M-EGCH link. Established_Non_CS_Preemptable_Nb_GCH: Established_Nb_GCH when only GCHs using extra Abis nibbles, bonus basic Abis nibbles and basic Abis nibbles mapped to RTSs within the non preemptable PS zone of the cell are considered. Target_Nb_GCH: An estimation of the number of GCHs necessary in a given M-EGCH link to carry the signalling and data PS traffic. A target number of GCHs, which may of course not be reached in transmission resource (Abis and/or Ater) congestion situations. Target_Nb_GCH is a function of: Number of PDCHs on the TRX, on which radio resources have been allocated for BE TBFs. Max_GPRS_CS and Max_EGPRS_MCS O&M parameter values. Number of GCH needed per PDCH for (Nb_GCH(Max_GPRS_CS / Max_EGPRS_MCS)). Max_GPRS_CS / Max_EGPRS_MCS
Whether Ater Usage in the GPU is high or not. If it is high, the value of Target_Nb_GCH is reduced so as to decrease the global Ater resource consumption in the GPU. The following example explains the Target_Nb_GCH evaluation for a EGPRS TBF and for GPRS TBF (In this example, it is supposed that the Ater usage of the GPU is not high): MEGCH link of a TRX supporting one 4-TS EGPRS TBF (Max_EGPRS_MCS = MCS-9) o Target_Nb_GCH = 4 * 4.49 = 18 GCHs
M-EGCH link of a TRX supporting one 4-TS GPRS TBF (Max_GPRS_CS = CS-4) Target_Nb_GCH = 4 * 1.64 = 7 GCHs
Min_Nb_GCH: An estimation of the minimum number of GCHs, necessary in a given M-EGCH link, is used as threshold when GCH preemption is performed. It ensures that all the TBFs established on the TRX will always be able, on at least one PDCH, to send a Radio Block with their Max_Allowed_(M)CS.
The Target_Nb_GCH and Min_Nb_GCH are updated at TBF allocation / reallocation and at TBF release.
A new M-EGCH link is established each time there is new PS traffic in a TRX without a M-EGCH link established. It can also be due to the Fast Initial PS Access feature. Some GCHs are added to an existing M-EGCH link, when new TBF is allocated on the TRX and Target_Nb_GCH becomes strictly higher than Established_Nb_GCH. Also it can be due to the Fast Initial PS Access feature or when performing the Periodical GCH establishment process.
The periodical GCH establishment process allows: o The usage of the recently freed Abis/Ater transmission resources in the BTS/GPU due to GCH releases.
ED NE
011 23/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
o o o o o
The usage of the free basic Abis nibbles mapped to RTSs out of the non preemptable PS zone of the cell. To guarantee that, following some abnormal GCH releases, new GCHs will be established in the impacted M-EGCH links. To guarantee a balance between the M-EGCH link sizes of the TRXs of a given cell after some TBFs (established on those TRXs) have been released. To guarantee that some GCHs are inter-cell preempted towards the M-EGCH links of the cell. This can be useful for example following the release of an RT PFC in another cell of the same BTS. To guarantee that some GCHs are always established for the Fast Initial PS Access feature
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
At timer expiry, if Target_Nb_GCH is still strictly lower than Established_Nb_GCH, the unused GCHs are released, the choice of GCHs to release is the reverse order than the one used for GCH establishment. If the last TBF in the cell is released, a number of GCHs shall be kept established during the T_GCH_Inactivity_Last time. The number of GCHs is defined at O&M by the parameter N_GCH_Fast_PS_Access_GCH. Those GCHs will be useful in case of (E)GPRS traffic resumption in the cell (when the Fast Initial PS Access feature is not enabled).
ED NE
011 24/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
M-EGCH link
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Established_Nb_GCH = 10
GCH10 B > HL GCH9 B > HL GCH8 B > HL GCH7 B > HL GCH6 B > HL GCH5 Extra GCH4 Extra GCH3 B HL GCH2 B HL GCH1 B HL
7 used GCHs
B > HL: GCH uses a basic Abis nibble mapped on a RTS out of the non preemptable PS zone of the cell. Extra: GCH uses an extra Abis nibble or a bonus basic Abis nibble. B HL: GCH uses a basic Abis nibble mapped on a RTS within the non preemptable PS zone of the cell.
2. TBF Establishment: if the RR allocation is performed then the TBF establishment is possible according to the following conditions: o
3DF 01900 0000 PTZZA DIAMS
TBF allocation policy: ASAP: used for BE (Best Effort) TBF establishment, T1, T2 and T4 reallocation. Its goal is to serve the request as soon as possible. If it is possible, an ASAP request is served immediately on a TRX having already Nb_GCH_For_TBF_Estab established GCHs. Otherwise, the establishment of
ED NE
011 25/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Nb_GCH_For_TBF_Estab GCHs on a TRX of the cell will be necessary to serve the request. OPTIMAL: used for T3 reallocation. Its goal is to ensure that a significant bandwidth will be offered to the MS upon T3 reallocation, even if it takes some time to establish all the necessary GCHs All the possible GCHs (Target_Nb_GCH) are systematically requested to be established before serving the request, and an Optimal request will only be served if the total number of GCHs successfully established on the TRX is greater than Nb_GCH_For_TBF_Estab (see below). o Max allowed (M)CS determination of a TBF depends on the type of TBF (GPRS / EGPRS) and of the direction of the TBF (UL / DL). It is limited by the:
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
The number of established GCHs: Nb_GCH Table 9: Maximun allowed CS. Nb_GCH Max_Allowed_CS 1 2 CS-2 (UL) / CS-1 (DL) CS-4
Table 10: Maximun allowed MCS. Nb_GCH Max_Allowed_MCS 1 2 3 4 5 MCS-2 (UL) / MCS-1 (DL) MCS-5 MCS-6 MCS-7 MCS-9
Nb_GCH_For_TBF_Estab is the minimum number of GCHs which are required on the TRX (M-EGCH) to serve the request.
Table 11: Number of GCH required on the TRX. Type of request Policy Nb_GCH_For_Estab TBF establishment (without concurrent) TBF establishment (with concurrent) T1 TBF reallocation T4 TBF reallocation T3 TBF reallocation ASAP ASAP ASAP ASAP Optimal 1 1 to 5 (Max_Allowed_(M)CS of concurrent TBF) 1 1 to 2 (Max_Allowed_CS of concurrent TBF) 1 to 5 (Max_Allowed_(M)CS of concurrent TBF)
ED NE
011 26/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Find the best candidate timeslot allocation, depending on: Type of request (GPRS / EGPRS) Multislot class Bias Traffic type
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Compute the number of GCHs which can be established: With free Abis and Ater resources, With inter-cell GCH preemptions, With intra-cell GCH preemptions.
Available_Nb_GCH
no candidate TS allocation
ALLOC OK case
ALLOC FAILED case - rejected request - or L4 queuing - or L5/L6 queuing - or L7 queuing (11) - or try to change TBF mode EGPRS case (12)
Find the best candidate timeslot allocation (steps 2, 3 and 4) Verify if there are enough transmission resources (steps 1, 5 and 6)
1 RELEASED 3DF XXXX XXXX PTZZA 011 27/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
o o
Allocate the radio resources (step 7) Reserve the transmission resources (step 8)
1. Compute the number of free Abis and Ater resources: o Nb_Free_GCH = Min( Nb_Free_Basic + Nb_Free_Extra, Nb_Free_Ater, 25) Where 25 is the maximum number of GCHs allowed in the Transmission-AllocationRequest message on BSCGP interface for G2 BSC
2. Compute the number of possible inter-cell GCH preemptions. The principles of this algorithm are: o o o o Source TRX and Target TRX on different cells of the same BTS, Only the GCHs using extra or bonus Abis nibbles are considered. Only cells using more extra or bonus basic Abis nibbles are considered. On source TRX, the following constraints shall be respected: o Established_Nb_GCH Min_Nb_GCH
The iterative process stops when: No more GCH to preempt Or Available_Nb_GCH = Nb_Free_GCH + Nb_Preempted 36
Opposite to B8, in B9 there is no longer some restricted EGPRS capable TRX lists (i.e. selection of the EGPRS TRX of highest class (that is which offer the highest throughput) as long as the maximum number of EGPRS TBF per PDCH on these TRX is not higher than a threshold). Indeed, all the EGPRS capable TRXs can offer the same potential throughput: they are all mapped on G4 TRE, and the B8 concept of TRX pool type has disappeared.
ED NE
011 28/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
The input data for the best candidate TBF allocation computation are: o
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
A sorted list of TRXs, n_MS_requested and n_MS_requested_concurrent, Type of the radio resources allocation request.
o o
The output of the best candidate TBF allocation computation is a candidate TS allocation on a given TRX, as it is defined in the next sub-sections.
For EGPRS Best Effort TBFs: An allocated PDCH is full in a given direction (XL: UL or DL) if and only if: o o EGPRS: An allocated PDCH is in the EGPRS state if some radio resources are allocated in DL, for an EGPRS TBF. Only used when running the radio resource (re)allocation algorithm in GPRS mode and when considering the UL direction of the candidate TBF allocations. Nb_BE_EGPRS_TBF_XL MAX_XL_TBF_SPDCH.
Remark: the busy PDCH state (number of established TBF on the PDCH higher than N_TBF_PER_SPDCH) is no more used by the allocation algorithm.
To be included in a candidate timeslot allocation in order to serve a best effort TBF, a PDCH on a given TRX must verify the following conditions: o o
ED NE
The PDCH shall be allocated in the MFS. This condition is new in B9 release and comes from the fact that the MFS does not request PDCH to the BSC The PDCH shall not be in the Full state in the considered direction
1 RELEASED 3DF XXXX XXXX PTZZA 011 29/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
This potential throughput and its associated parameters are only used in the computation of the best allocation. The available capacity on a given PDCH (available_capacity_PDCH_XL) is calculated as follows: o For a GPRS TBF (XL corresponds to either UL or DL) : 1 / Nb_BE_TBF_SAME_PRIOR_XL
Where: o o Nb_BE_TBF_SAME_PRIOR_XL indicates the total number of Best Effort TBFs (GPRS or EGPRS) which have some radio resources allocated on the considered PDCH in the XL direction Nb_BE_EGPRS_TBF_SAME_PRIOR_XL only take into account EGPRS TBF (the best effort GPRS TBF are not taken into account)
The available capacity of a given candidate timeslot allocation for n PDCH (n1) is computed as follows, for each direction (XL corresponds to either UL or DL): o
available_capacity_candidate_XL = available_capacity_PDCHi_XL
i =1
Finally, the available throughput of a candidate timeslot allocation is computed as follow, for each direction (XL corresponds to either UL or DL): o available_throughput_candidate_XL = potential_throughput_PDCH * available_capacity_candidate_XL
ED NE
011 30/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
o o
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
[ALPHA]: For ASAP policy only: the candidate timeslot allocations, which are on some TRXs for which (Established_Nb_GCH - Nb_MPDCH) is greater than Nb_GCH_For_TBF_Estab are preferred. [A]: For UL GPRS TBF establishment / reallocation only: the candidate timeslot allocations, which have the lowest number of PDCHs in the EGPRS state are preferred. [B]: the candidate timeslot allocations, which have the highest available throughput in the direction of the bias are preferred. [C]: the candidate timeslot allocations, which have the highest available throughput in the direction opposite to the bias are preferred. [D]: the candidate timeslot allocations, which are on the TRX with the highest priority, are preferred. [E]: for EGPRS TBFs establishments only: the candidate timeslot allocations, which have the lowest number of GPRS TBFs in the direction of the bias, are preferred. [F]: combinations with the PDCHs that have the lowest index are preferred.
o o o o o
Remarks: o o The A criterion is only relevant for an UL GPRS TBF establishment / reallocation (i.e. when considering the UL direction of a candidate TS allocation in GPRS mode) When evaluating criterion F, the concurrent constraints imposed by the MS multislot class (if it is known) or by the default multislot class (if the MS multislot class is not known) shall be taken into account
This first step is new in B9 release, the PDCH capacity allocation is performed on the best candidate TS allocation, it has to guarantee a minimum bandwidth for the corresponding TBF(s) (data throughput and throughput generated on PACCH channels in DL and in UL). The PDCH capacity allocation should always succeed, because the candidate TS allocations for which the PDCH capacity allocation cannot be performed have been excluded during the best candidate allocation computation step.
needed_capacity_Best_Effort_XL = 20 / T_MAX_FOR_TBF_SCHEDULING
with T_MAX_FOR_TBF_SCHEDULING an O&M parameter in ms This calculation of needed_capacity_Best_Effort_XL approximates the minimum load which can be generated by the data traffic and the signalling traffic of the TBF (signalling traffic on the PACCH in the direction of the TBF). To simplify, it is considered that:
ED NE 1 RELEASED 3DF XXXX XXXX PTZZA 011 31/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
needed_capacity_Best_Effort_DL = needed_capacity_Best_Effort_UL
T4: reallocation to move an UL GPRS TBF sharing one PDCH with a DL EGPRS TBF onto PDCHs which do not support a DL EGPRS TBF. It concerns only GPRS TBFs.
A T3 TBF reallocation is based on the following principles: o o Computing of a THROUGHPUT_RATIO (= Allocated_Throughput / Optimal_Throughput) to know how sub-optimal a TBF allocation is. A T3 TBF reallocation will only be allowed if a significant THROUGHPUT_RATIO gain is reached. The minimal gain is set by the system parameter: MIN_THROUGHPUT_GAIN (= 40%).
ED NE
011 32/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
T3 reallocation attempts occur at each expiry of the T_CANDIDATE_TBF_REALLOC timer and up to N_MAX_PERIODIC_REALLOC_T3. T3 reallocation attempts can take place at each T_CANDIDATE_TBF_REALLOC timer expiry.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
In case of successful T3 reallocation attempt, no new attempt takes place until the next T_CANDIDATE_TBF_REALLOC timer expiries. Even if less than N_MAX_PERIODIC_REALLOC_T3 attempts have occurred and up to two T3 TBF reallocations can be successfully played at each T_CANDIDATE_TBF_REALLOC timer expiry.
A specific case of T3 reallocation is explained in the next example: Initial situation: o 3 MSs (MSa, MSb, and MSc), all GPRS and (4+1),
6
MSb
UL
MSc
UL DL
DL
o In B8: o In B9: o o
MSc is not candidate for T3 reallocation because its allocation is optimal (4 TS in DL),
MSc is candidate for T3 reallocation, A new TRX will be established (cf. Optimal policy) and MSc will then be reallocated on this new TRX.
0 1 2
MSc
2
MSa
6
MSb
UL DL
UL DL
MSc MSc
MSc
MSc
A second example is a T3 TBF reallocation trigger due to radio defragmentation purpose, as shown in the next figure:
ED NE
011 33/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
TBF TBF
Initial
Final situation
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
In the best candidate allocation computation algorithm: o o o The candidate timeslot allocations do not require having the same number of PDCHs than the current allocation. In the UL direction, the candidate timeslot allocations cannot contain PDCHs in the EGPRS state. The radio resource allocation algorithm is run with the ASAP policy. Thanks to the allocation criterion ALPHA, the candidate TS allocations located on the TRXs having already Nb_GCH_For_TBF_Estab established GCHs are favored.
Upon T_CANDIDATE_TBF_REALLOC timer expiry it shall be attempted to reallocate a maximum of N_MAX_PERIODIC_REALLOC_T4 candidate MSs queued within a list. If a reallocation succeeds, the next request within the list shall be played (up to the N_MAX_PERIODIC_REALLOC_T4 limit).
ED NE
011 34/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
The "Incremental Redundancy in UL" feature proposes to introduce the incremental redundancy in UL which permits to improve the decoding performances of the BTS with EGPRS. This is particularly useful when mobiles are at the border of the cells where a gain up to 15 % of throughput can be expected according to simulations.
Table 12: Theoretical throughput per UL MCS. Coding Throughput Modulation Scheme (kbits/sec) GMSK MCS-1 8.4 GMSK GMSK GMSK 8-PSK 8-PSK 8-PSK 8-PSK 8-PSK MCS-2 MCS-3 MCS-4 MCS-5 MCS-6 MCS-7 MCS-8 MCS-9 11.2 14.8 17.6 22.4 29.6 44.8 54.4 59.2
If an EGPRS mobile station wants to initiate the UL EGPRS TBF establishment and if the mobile supports the 8PSK in uplink, then it shall send an EGPRS Packet Channel Request using TS1 alternative training sequences to request the resources in EGPRS mode. The EGPRS capability is indicated using alternative training sequences (see 3GPP TS 45.002), as presented in the next table.
Table 13: Training sequence. Training sequence TS1 TS2 Packet Channel Access EGPRS with 8PSK capability in uplink EGPRS without 8PSK capability in uplink
The MCS-5 to MCS-9 coding schemes will be used both in RLC acknowledged and unacknowledged mode. The link adaptation mechanism in uplink is based on measurements (MEAN_BEP, CV_BEP) done by the BTS on the radio blocks received from the mobile. To take into account MCS-5 to MCS-9 in uplink, the B9 BSS algorithm for link adaptation has new link adaptation MEAN_BEP/CV_BEP tables, which are the same as the ones already used for downlink. Then, the MCS selected by the BSS is indicated in the "EGPRS modulation and coding" IE included in the PACKET UPLINK ACK/NACK message. The TRX shall transmit the MEAN_BEP and CV_BEP of the RLC data block which is received with a correctly decoded RLC/MAC header, whether the payload is correctly decoded or not. The TRX will discard the RLC/MAC blocks when the header has not been successfully decoded.
3DF 01900 0000 PTZZA DIAMS
The Link Adaptation tables depend on the APD (Average Power Decrease) of the mobile station, the APD of a mobile station is the difference between the maximum output power in GMSK and the maximum output power in 8-PSK and the maximum output powers are known by "GMSK Power Class" and "8-PSK Power Class" fields of the MS Radio Access capability IE. The Link Adaptation tables also depend of the Incremental Redundancy if it is activated or not.
ED NE
011 35/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
As examples of APD in case of GSM 900 and GSM 850, there is the following table:
Table 14: Average Power Decrease. 8-PSK: Power 8-PSK: Power 8-PSK: Power Class E1 Class E2 Class E3 Max. output Max. output Max. output power = 33 dBm power = 27 dBm power = 23 dBm GMSK: Power Class 2 Max. output power = 39 dBm GMSK: Power Class 3 Max. output power = 37 dBm GMSK: Power Class 4 Max. output power = 33 dBm GMSK: Power Class 5 Max. output power = 29 dBm APD = 0 APD = 2 APD = 6 APD = 0 APD = 6 APD = 10 APD = 4 APD = 10 APD = 10
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
APD = 6
APD = 10
APD = 10
GMSK
MCS1 MCS2 Family C MCS3 MCS4 MCS5 MCS6
8PSK
MCS7 MCS8 MCS9
22
22
22
Family B
28
28
28
28 28
28 28
Family A padding
34+3
34+3
34+3
34 34
34 34
37 Family A
37
37
37 37
37 37
28
ED NE
011 36/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
The incremental redundancy cannot be applied when the RLC datablocks are re-segmented with a different number of payloads For more details see [2].
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
3DF 01900 0000 PTZZA DIAMS
The Radio Access Capability Update on the Gb is activated by the flag EN_RA_CAP _UPDATE. If the EN_EXTENDED_UL_TBF is enabled and the Radio Access Capability update is supported by SGSN, it is recommended to enable the flag EN_RA_CAP _UPDATE. At UL TBF establishment, immediately after the contention resolution procedure, the radio access capability update procedure is triggered in the BSS. The BSS request an MSs current Radio Access capability and/or its IMSI by sending to an SGSN a RA_CAPABILITY_UPDATE, which includes the TLLI of the MS and a Tag. Then it starts timer T5_RA_CAPABILITY_UPDATE. In case of the timer expiry, BSS shall repeat the request up to RA_CAPABILITY_UPDATE_RETRIES times (value = 3). The SGSN shall respond by sending a RA_CAPABILITY_UPDATE_ACK, which includes the TLLI of the MS, the Tag received in the corresponding RA_CAPABILITY_UPDATE. When the SGSN answers, the MS Radio Access capability is updated and the Extended UL feature can be used if the GERAN Feature Package 1 bit is set. Otherwise, the MS does not support the extended uplink feature.
If MS supports Extended UL TBF mode and when entering the extended uplink phase the MS begins to run out of LLC data, it begins the countdown normally. When the BSS receives the last RLC block (CV =0), and if all the previous blocks have been correctly received, the BSS sends a Packet Uplink Ack/Nack with Final_Ack_Indicator set to 0, with the SSN incremented like for an active TBF (SSN = last received BSN +1). All RLC numbering variables are kept as TBF was still active. The uplink TBF is now extended and will not be released by the mobile. The BSS starts the timer T_max_extended_UL to monitor the maximum duration of the extended phase.
ED NE 1 RELEASED 3DF XXXX XXXX PTZZA 011 37/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
MS
RLC block, BSN=n, CV=
BSS
0 0
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
The BSS continues to schedule USF, so that the MS is able to resume an uplink transfer when required. While the UL TBF is in extended phase, the reception of an uplink dummy block from the MS, shall not cause the N3101 counter to be incremented in the BSS. Only the reception of an invalid block increment N3101. While the UL TBF is in extended phase, the reception of an uplink dummy block from the MS shall not cause the N_UL_dummy counter to be incremented.
MS
USF
RLC block,
BSS
BSN=n, CV= 0
Start T_max_extended_UL
USF
Dummy bloc k
After the expiry of the timer T_max_extended_UL the network ends the TBF permanently by sending a Packet Uplink Ack/Nack with FAI = 1 and polling. When receiving PUAN with FAI=1 and polling, the MS sends the Packet Control Ack in response to polling, and then aborts the uplink TBF. When the timer T_max_extended_UL expires, the BSS shall wait for all the radio blocks corresponding to already transmitted USF, before transmitting FAI =1.
MS
USF
Dummy bloc k
BSS
ED NE
011 38/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
If the radio blocks corresponding to the last scheduled USF carry RLC data block, then the BSS shall restart the uplink TBF.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
MS
USF
Radio block, BSN=n+1
BSS
USF
Radio block, BSN=n+2, et c
The USF for extended mode are scheduled only on the PDCH, which carries PACCH. IF the PDCH supports uplink TBF, which all are in extended mode and the flag EN_FAST_USF_UL_EXTENDED is enable then the throughput in radio blocks is equally shared between MS (round robin of one RLC block per MS). So USF are scheduled as follows: o o o One MS in extended mode on PACCH: USF scheduled every 20ms Two MS in extended mode on PACCH: USF scheduled every 40ms n MS in extended mode on PACCH: USF scheduled every n x 20m
Otherwise, a polling period T_extended_UL_TBF_POL is used for all MS in extended phase with a default value of 200ms and the remaining bandwidth is used for MS in transfer.
In NC2 mode, the algorithm was improve to take in consideration the cell ranking with load criteria, to prevent MSs to be directed towards high loaded cells, where the MS can be served with non-optimum resources, or even worse, rejected due to congestion. For details see [2].
CCN mode procedure (Cell Change Notification): Procedure in MS to notifies the network when the cell reselection is decided in Packet Transfer Mode and delays the cell reselection to let the network act on need, eventually through the Cell System Information distribution procedure. Cell System Information distribution: Procedure to assist an MS in Packet Transfer Mode with target cell system information required for initial packet access after a cell change. This information is sent to the MS in the serving cell and before the cell change is performed.
1 RELEASED 3DF XXXX XXXX PTZZA 011 39/96
ED NE
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Celll A Ce A
Partial Sys Info. of Cell
Cellll B Ce B
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
MS
Cell A
Ongoing data transfer
Cell B
Target cell choice (1) RLC data block polling Packet Cell Change Notification (2) Retrieval PSI instances of the chosen cell (3) Packet Neighbor Cell Data (PSI14) Packet Neighbor Cell Data (PSI1) T3208 T3208n Packet Neighbor Cell Data (PSI2-first instances) Packet Neighbor Cell Data (PSI2-intermediate instances) Packet Neighbor Cell Data (PSI2-last instances) Packet Cell Change continue (4) T3210 T3206
(1) T3206 monitors the sending of the Packet Cell Change Notification. (2) At receipt of the PACKET CELL CHANGE NOTIFICATION message, the MFS checks whether the proposed cell belongs to the same BSS as the serving cell. If the proposed cell does not belong to the same BSS (BSC_ID(n) (target cell) <> BSC_ID (serving cell)), a PACKET CELL CHANGE CONTINUE (PCCC) message is sent to the mobile station without sending any neighbor cell system information. (3) In the case, the neighbor cell belongs to the same BSS, RRM starts the timer T3208n (T3208 RTD) that monitors the sending of the PCCC and retrieves the SI13 / SI1 / SI3 or PSI14 / PSI1 / PSI2 instances currently broadcast in the neighbor cell and requests MAC to send the relevant (P)SI to the MS o if the target cell supports a PBCCH channel, RRM encodes the PSI14, PSI1 and PSI2 instances of that cell in one or multiple instances of the PACKET NEIGHBOR CELL DATA message which are sent to the MS, followed by a PACKET CELL CHANGE CONTINUE message .
1 RELEASED 3DF XXXX XXXX PTZZA 011 40/96
ED NE
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
o o
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
if the target cell does not support a PBCCH channel, RRM encodes the SI13, SI1 and SI3 instances of that cell in one or multiple instances of the PACKET NEIGHBOR CELL DATA message. When the MS sends the Packet Cell Change Notification message, the MS activates the timer T3210 to wait for a response from the BSS, if timer expiry, the Packet Cell Change Notification is retransmitted. The MS also activates the timer T3208 to wait for PACKET CELL CHANGE CONTINUE from the BSS (at timer expiry, the MS will continue the cell reselection in NC0 mode).
(4) When RLC has sent all the instances of the PACKET NEIGHBOUR CELL DATA message, the PACKET CELL CHANGE CONTINUE (PCCC) message is sent on the PACCH of the MS and the timer T3208n is stopped. It is to be noted that no PCA is requested to acknowledge the PCCC (No T_Ack_Wait timer is launched by the BSS when sending the PCCC because at the timer expiry, the mobile station has already left the CCN mode either because it has received the PCCC or because T3208 has already expired and it is not necessary to send the PCCC again). When the mobile station receives the PACKET CELL CHANGE CONTINUE message, it shall leave CCN mode and continue cell reselection in NC0 mode. Note: The figure above covers the case where there is a PBCCH in the target cell. When there is no PBCCH channel in the target cell, the same scenario takes place with BSS sends the SI13, SI1 and SI3 messages instead of the PSI14, PSI1 and PSI2 messages.
MS
Ongoing UL or DL TBF (1)
Packet Measurement Report / PACCH (2) (3) Packet Neighbor Cell Data / PDCHs (4) Packet Neighbor Cell Data / PDCHs Packet Cell Change Order / PACCH (5) (6) Packet Control Acknowledgement / PACCH (7) T_ACK_WAIT
(1) An UL or DL TBF is assumed on-going. (2) The MS sends a Packet Measurement Report message on one of the allocated UL block on PACCH (3) Upon receipt of the Packet Measurement Report message, the BSS detects that a cell reselection must be triggered. It finds out that the target cell, belongs to the same BSS, and the MS supports the acquisition of neighbor cell (P)SI. (4) The BSS sends the PNCDs to the MS, on all the PDCHs of the TBF, to transmit the (Packet) System Information for the target cell: o o
3DF 01900 0000 PTZZA DIAMS
SI13, SI1 and SI3 for a target cell without PBCCH or PSI14 (containing the same information as SI13), PSI1 and a consistent set of PSI2 for a target cell with a PBCCH.
In case both a UL and a DL TBF exist, PNCDs are sent on the DL TBF.
ED NE
011 41/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
(5) When all the PNCDs have been sent, the BSS orders the MS to reselect a new cell by sending a Packet Cell Change Order message on the PACCH of the DL or UL TBF. If both an UL and a DL TBFs are on-going, the message is preferentially addressed by a DL TFI. The Packet Cell Change Order message is sent in acknowledged mode and contains the ARFCN and the BSIC of the target cell. When sending the Packet Cell Change Order message, the BSS starts the timer T_ACK_WAIT to monitor the receipt of the Packet Control Acknowledgement message.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
(6)-(7) Upon receipt of the Packet Cell Change Order message, the MS aborts its on-going TBF in the serving cell and sends the Packet Control Acknowledgement message, then switches to the new cell.
Celll A Ce A
Partial Sys Info.
Cellll B Ce B
Remainin g Sys Info.
Packet SI Status
The scenario of the Packet SI Status procedure is described in the next figure:
MS Cell A
RLC data block (1) Packet SI status (SI2, SI2bis, SI2ter message type missing) (2)
Cell B
Scheduling of the serving cell SI message to MS T_PSCD_SCHE DULE_ACK (3) Packet serving cell data (SI2 message) (4) Packet serving cell data (SI2bis message) Packet serving cell data (SI2ter message)
Completion of UL LLC PDU transfer RLC data block Packet Uplink ACK/NACK
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
(1) When reselecting a new cell without a PBCCH channel and supporting the PACKET SI STATUS procedure (EN_PSI_STATUS = enable), the MS can immediately request the establishment of an uplink TBF provided it has acquired the SI13, SI3 and SI1 message (if present) of this new cell. It can then send a cell update or restarts its on-going data transfer. (2) The MS asks BSS to provide the missing system information by sending a PACKET SI STATUS message on PACCH. (3) When receiving the MS request, if a downlink TBF is already established, or if a downlink TBF is being established, or if a downlink TBF will soon be established (DL LLC PDU are being rerouted to the new cell), then the BSS shall wait until full establishment of the DL TBF to send requested SIs on all the downlink PDCHs allocated to the MS. Otherwise, SIs are sent on all the PDCHs of the uplink TBF. A supervision timer (T_PSCD_SCHEDULE_ACK) is started to monitor the sending of the SI messages to the mobile. (4) The SI instances are encapsulated in one or multiple instances of a PACKET SERVING CELL DATA message and sent individually to the mobile station. When the last SI is sent to the mobile, T_PSCD_SCHEDULE_ACK is stopped (RLC indicates to RRM that all SIs have been sent).
MS
Cell A
RLC data block (1) Packet PSI status (PSI3, PSI3bis missing) (2) Scheduling of the serving cell PSI messages to MS
Cell B
Packet serving cell data (PSI3 message) Packet serving cell data (PSI3bis message) - first instance Packet serving cell data (PSI3bis message) - intermediate instance Packet serving cell data (PSI3bis message) - last instance Completion of UL LLC PDU transfer RLC data block Packet Uplink ACK/NACK
(1) When reselecting a new cell with a PBCCH channel and supporting the PACKET PSI STATUS procedure (EN_PSI_STATUS = enable), the MS can immediately request the establishment of an UL TBF, provided it has acquired the PSI14, PSI1 and PSI2 messages of this new cell. It can then send a cell update or restarts its on-going data transfer.
3DF 01900 0000 PTZZA DIAMS
(2) The MS asks the BSS to provide the missing system information by sending a PACKET PSI STATUS message on a PACCH block. (3) When receiving the MS request, if a DL TBF is already established, or is being established, or will soon be established (DL LLC PDU are being rerouted to the new cell), then the BSS shall wait until full establishment of the DL TBF to send requested PSIs on all the downlink PDCHs allocated to the MS.
ED NE 1 RELEASED 3DF XXXX XXXX PTZZA 011 43/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Otherwise, PSIs are sent on all the PDCHs of the uplink TBF. A supervision timer (T_PSCD_SCHEDULE_ACK) is started to monitor the sending of the PSI messages to the mobile. (4) When the last PSI is sent to the mobile, T_PSCD_SCHEDULE_ACK is stopped.
The NC2 load is sampled every T_NC2_LOAD_RANKING seconds by dividing the used bandwidth by the total bandwidth available in the cell
with: UL_PS_used_Bandwidth: the bandwidth used by PS traffic in the UL direction, DL_PS_Used_Bandwidth: the bandwidth used by PS traffic in the DL direction, CS_Used_Bandwidth: the bandwidth used by CS traffic, Total_PS_Bandwidth: the total bandwidth available in the cell.
The UL PS used bandwidth is defined as the sum of the bandwidth used by the UL TBFs over all the PDCHs allocated to the MFS.
N_PDCH_ALL OCATED UL , i i=1
BUL =
(B )
=
With: nULTBF,i: defines the number of UL TBFs on the allocated PDCH i. NULTBF: is the maximum number of UL TBFs that can be pilled up on the PDCHs (defined by the parameter MAX_UL_TBF_SPDCH).
In the DL direction, the DL_PS_Used_Bandwidth is computed in a similar way as the UL direction. The bandwidth used by the CS traffic (CS_Used_Bandwidth) is defined by the difference between the maximum number of slave PDCHs that can be allocated in the cell (number of slave PDCHs = MAX_PDCH NB_TS_MPDCH) and the number of slave PDCHs currently allocated to the MFS in the cell
Next, it is a example of the Cell load evaluation. It is assumed, he following repartition of the DL TBFs is used: o o o o
ED NE
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Time Slot 3
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
1 DL TBF3
7 CS
2 1 BDL , i
In this example, the total bandwidth is equal to 8, the DL_PS_used_bandwidth is equal to 4x1/3 + 3x2/3 = 10/3. Therefore, the NC2_load is equal to [(10/3)+ 1]x100/8 = 13x100/24 = 54.16 %
The NC2 load samples are further averaged using a sliding window. The size of the sliding window is defined by the parameter NC2_LOAD_EV_PERIOD. The load evaluation of internal BSS cells is calculated every T_NC2_LOAD_RANKING, the BSS compares the computed NC2 load of the cell to the threshold THR_NC2_LOAD_RANKING: o o If the NC2 load average is lower than or equal to the threshold, the cell is considered in a low load situation. If the NC2 load average is higher than the threshold, the cell is considered in a high load situation.
The MFS shares the NC2 load situation information among the different cells of the BSS (or at least between the cells having a cell reselection link to the serving cell), i.e. low/high load. That exchange of information is taking place every MULTI_GPU_INFO_BROADCAST_PERIOD. All external cells to the BSS will always be considered as in low load situation, because of the threshold THR_NC2_LOAD_RANKING of an external cell is unknown for the BSS.
C31NC2 NC2_load
3DF 01900 0000 PTZZA DIAMS
priority
PRIORITY_CLASS C32NC2
low
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Case 2: there is no PBCCH in the serving cell Cells with C31NC2 > 0 NC2_Load situation [low => high PS load]; C2NC2 [high => low] Cells with C31NC2 < 0 C2NC2 [high => low]
high
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
priority
(1) The MS is in packet idle mode in the serving cell (the old cell). (2) The MS starts it own cell reselection towards the new cell. (3) The MS acquires the SI or PSI of the new cell. (4) While the MS acquires the system information, a DL LLC PDU is received in the old cell for the related MS. (5) RRM initiates the DL TBF establishment procedure upon receipt of the DL LLC PDU. (6) When the MS has finished the system information acquisition in the new cell, it performs an uplink data transfer in the cell in order to inform the SGSN of its new cell location. (7) The BSS forwards the new cell identity to the SGSN. (8) The SGSN analyses the uplink PDU and deduces that the MS has changed of cell.
3DF 01900 0000 PTZZA DIAMS
ED NE
011 46/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
(9) The SGSN sends a Flush message to the old cell. (10) RRM re-routes the MS context and then all the stored DL LLC PDUs according to the conditions defined above. Otherwise RRM discards the DL LLC PDUs.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
If the flag EN_DL_LLC_PDU_Rerouting is set to enable the MFS behaviour follows the conditions of the next table:
Table 15: MFS behaviour with activation of DL LLC PDU rerouting Old and New Cell Same RA Same NSE SGSN INR En_Autonomous_Rerouting FLUSH-LL information NA NA Old BVCI and New BVCI Old BVCI Old BVCI, New BVCI and New NSEI Old BVCI Old BVCI Old BVCI MFS behaviour MS Context rerouted DL LLC PDU rerouted DL LLC PDU deleted MS Context rerouted DL LLC PDU rerouted DL LLC PDU deleted MS Context autonomous rerouted DL LLC PDU autonomous rerouted DL LLC PDU deleted
NA
Enable Disable
If the DL LLC PDU rerouting feature is disabled the DL LLC PDU in the old cell will be deleted.
Resource allocation/reallocation
Logical name EN_RES_REALLOCATION Definition Enabling / disabling of the resource reallocation feature. Timer to limit the duration of the soft pre-emption process (at its expiry, a fast pre-emption is undertaken). Maximum number of DownLink (E)GPRS connections per Slave PDCH. Maximum number of UpLink (E)GPRS connections per slave PDCH. Instance BSS Type Number Range 0 to 15 0 to 240 Default value NA Optimised value
T_PDCH_PREEMPTION
Cell
Number
NA
MAX_DL_TBF_SPDCH
3DF 01900 0000 PTZZA DIAMS
Cell
Number
1 to 10
MAX_UL_TBF_SPDCH
Cell
Number
1 to 6
ED NE
011 47/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
EN_RETURN_CS_ZONE_HO
R_AVERAGE_GPRS R_AVERAGE_EGPRS
Flag enabling the intracell handovers allowing to move TCH from the PS zone to the CS zone of PDCH/TCH allocation average bitrate per PDCH for nonEdge capable terminals in this cell average bitrate per PDCH for Edge capable terminals in this cell
Cell
Flag
Enable
Cell Cell
Number Number
12000 30000
MIN_PDCH
Cell
Number
MAX_PDCH_HIGH_LOAD
Cell
Number
MAX_PDCH_PER_TBF
Cell
Number
1 to 5
MAX_PDCH_PER_TBF_High_Ater_Usage
Cell
Number
1 to 5
NA
MAX_EGPRS_MCS MAX_GPRS_CS
cell cell
Number Number
9 2
NB_EXTRA_ABIS_TS
cell
Number
0 to 96
NA
BTS cell
Number Number
0 0
PS_PREF_BCCH_TRX
cell
Flag
Disable
T_DL_EGPRS_MeasReport
cell
Timer
200ms
TBF_DL_INIT_CS
cell
Number
CS-2
TBF_UL_INIT_CS
cell
Number
CS1 to CS4
CS-2
ED NE
011 48/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
TBF_DL_INIT_MCS All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
TBF_UL_INIT_MCS
NETWORK_CONTROL_ORDER(n)
TX_EFFICIENCY_ACK_THR
TX_EFFICIENCY_NACK_THR
Value of the downlink coding scheme when the link adaptation algorithm is disabled or initial value of the coding scheme otherwise. Value of the uplink coding scheme when the link adaptation algorithm is disabled or initial value of the coding scheme otherwise. This parameter defines whether the MS or the BSS controls the cell reselections. Threshold below which the TBF is released because of a bad transmission efficiency in acknowledged mode. Threshold below which the TBF is released because of a bad transmission efficiency in unacknowledged mode. Flag to disable/enable the extended TBF mode feature on the uplink Maximum duration of the extended uplink TBF phase Flag to disable/enable the transmission of USF every 20ms in extended mode Flag to enable/disable the Radio Access Capability update on Gb Maximum value allowed for the MS to request for non-DRX mode after packet transfer mode. Number of remaining RLC data blocks sent (per assigned PDCH) by the MS, below which the Count Down procedure is entered. One third of the number of RLC data blocks per assigned PDCH before the MS checks if the resolution contention has failed.
cell
Number
MCS-3
cell
Number
MCS-3
cell
Number
cell
Percentage
0 to 100
10
cell
Percentage
0 to 100
15
EN_RA_CAP_UPDATE
BSS
Flag
Enable DISABL / E Disable [100, 2000 4000] Enable / ENABLE Disable Enable DISABL / E Disable 0 to 4 2
Enable
Enable
DRX_TIMER_MAX
BSS
sec
BS_CV_MAX
cell
Number
to 15
CS_QUAL_UL_2_3_FH_ACK
BSS
Threshold
0 to 7
CS_QUAL_DL_2_3_FH_ACK
BSS
Threshold
0 to 7
CS_QUAL_UL_2_3_FH_NACK
BSS
Threshold
0 to 7
CS_QUAL_DL_2_3_FH_NACK
BSS
Threshold
0 to 7
ED NE
011 49/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
CS_QUAL_UL_2_3_NFH_ACK
CS_QUAL_DL_2_3_NFH_ACK
CS_QUAL_UL_2_3_NFH_NACK
CS_QUAL_DL_2_3_NFH_NACK
CS_QUAL_UL_3_4_FH_ACK
CS_QUAL_DL_3_4_FH_ACK
CS_QUAL_UL_3_4_FH_NACK
CS_QUAL_DL_3_4_FH_NACK
CS_QUAL_UL_3_4_NFH_ACK
CS_QUAL_DL_3_4_NFH_ACK
Threshold used in the link adaptation algorithms to change the Coding Scheme from CS2 to CS3 in the uplink direction when the RLC mode is acknowledged and the TBF is established on a nonhopping TRX. Threshold used in the link adaptation algorithms to change the Coding Scheme from CS2 to CS3 in the downlink direction when the RLC mode is acknowledged and the TBF is established on a nonhopping TRX. Threshold used in the link adaptation algorithms to change the Coding Scheme from CS2 to CS3 in the uplink direction when the RLC mode is unacknowledged and the TBF is established on a non-hopping TRX. Threshold used in the link adaptation algorithms to change the Coding Scheme from CS2 to CS3 in the downlink direction when the RLC mode is unacknowledged and the TBF is established on a non-hopping TRX. Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the uplink direction when the RLC mode is acknowledged and the TBF is established on a hopping TRX. Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is acknowledged and the TBF is established on a hopping TRX. Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the uplink direction when the RLC mode is unacknowledged and the TBF is established on a hopping TRX. Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is unacknowledged and the TBF is established on a hopping TRX. Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the uplink direction when the RLC mode is acknowledged and the TBF is established on a nonhopping TRX. Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is acknowledged and the TBF is established on a nonhopping TRX.
BSS
Theshold
0 to 7
3.5
BSS
Theshold
0 to 7
3.5
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
BSS
Threshold
0 to 7
BSS
Threshold
0 to 7
BSS
Threshold
0 to 7
0.5
BSS
Threshold
0 to 7
0.5
BSS
Threshold
0 to 7
BSS
Threshold
0 to 7
BSS
Threshold
0 to 7
0.5
BSS
Threshold
0 to 7
0.5
3DF 01900 0000 PTZZA DIAMS
ED NE
011 50/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
CS_QUAL_UL_3_4_NFH_NACK All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
CS_QUAL_DL_3_4_NFH_NACK
CS_SIR_DL_3_4_FH_ACK
CS_SIR_DL_3_4_FH_NACK
CS_SIR_DL_3_4_NFH_ACK
CS_SIR_DL_3_4_NFH_NACK
CS_SIR_HST_DL
CS_BLER_DL_3_4
CS_BLER_DL_4_3
TBF_CS3_BLER_PERIOD
TBF_CS4_BLER_PERIOD
EN_FULL_IR_DL
Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the uplink direction when the RLC mode is unacknowledged and the TBF is established on a non-hopping TRX. Threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is unacknowledged and the TBF is established on a non-hopping TRX. Signal to Interference Ratio threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is acknowledged and the TBF is established on a hopping TRX. Signal to Interference Ratio threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is unacknowledged and the TBF is established on a hopping TRX. Signal to Interference Ratio threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is acknowledged and the TBF is established on a nonhopping TRX. Signal to Interference Ratio threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the RLC mode is unacknowledged and the TBF is established on a non-hopping TRX. Signal to Interference Ratio hysteresis used in the link adaptation algorithms to change the Coding Scheme from CS4 to CS3 in the downlink direction. CS3 BLER threshold used in the link adaptation algorithms to change the Coding Scheme from CS3 to CS4 in the downlink direction when the SIR measurements are not reported by the MS. CS4 BLER threshold used in the link adaptation algorithms to change the Coding Scheme from CS4 to CS3 in the downlink direction when the SIR measurements are not reported by the MS. Defines the window size required to estimate the CS3 BLER. The window size is expressed as a number of DL RLC data blocks Defines the window size required to estimate the CS4 BLER. The window size is expressed as a number of DL RLC data blocks Enables/Disables Incremental redundancy for the downlink TBF in the cell.
BSS
Threshold
0 to 7
BSS
Threshold
0 to 7
BSS
Threshold
0 to 15
14
10
BSS
Threshold
0 to 15
15
10
BSS
Threshold
0 to 15
13
10
BSS
Threshold
0 to 15
15
10
BSS
Number
0 to 15
BSS
Percentage
0 to 100
BSS
Percentage
0 to 100
15
BSS
Number
1 to 512
32
BSS
Number
32
BSS
Flag
DISABL E
Enable
ED NE
011 51/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
EN_IR_UL
EN_RESEGMENTATION_UL
E_TX_EFFICIENCY_PERIOD
EN_CS_ADAPTATION_ACK
Enables/Disables Incremental redundancy for the uplink TBF in the BSS. Enables/Disables the resegmentation for the uplink TBF in the BSS Number of received radio blocks for an EGPRS TBF after which E_TX_EFFICIENCY is computed. Enables / disables the link adaptation in RLC acknowledged mode. Enables / disables the link adaptation in RLC unacknowledged For a monoslot TBF alone on its PDCH, threshold defining the number of consecutive Packet Downlink Ack/Nack not received above which the coding scheme of a downlink acknowledged or unacknowledged TBF is changed to CS1 (only in downlink). For a multislot TBF or a TBF which shares its PDCH(s), the limit is proportional to the instantaneous bandwidth allocated to the TBF. Threshold defining the maximum number of consecutive times the network receives an invalid UL RLC data block or nothing from the MS having a monoslot GPRS TBF before changing the coding scheme to CS1. For a multislot GPRS TBF, TBF_CS_UL_limit := TBF_CS_UL x n_allocated For a monoslot TBF alone on its PDCH, threshold defining the number of consecutive EGPRS Packet Downlink Ack/Nack not received above which the coding scheme of a downlink acknowledged or unacknowledged TBF is changed to MCS1 (only in downlink). For a multi-slot TBF or a TBF which shares its PDCH, the limit is proportional to the allocated bandwidth at the TBF establisment. Threshold defining the maximum number of consecutive times the network receives an invalid UL RLC data block or nothing from the MS having a monoslot EGPRS TBF before changing the coding scheme to MCS1. For a multislot EGPRS TBF, TBF_MCS_UL_limit := TBF_MCS_UL x n_allocated_timeslots.
BSS
Flag
BSS
Flag
Enable
Disable
BSS
Number
Cell
Flag
Enable
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
EN_CS_ADAPTATION_NACK
Cell
Flag
Enable
TBF_CS_DL
BSS
Number
0 to 15
TBF_CS_UL
BSS
Number
0 to 64
32
TBF_MCS_DL
BSS
Threshold
0 to 15
12
TBF_MCS_UL
BSS
Threshold
1 to 192
32
GPRS/EGPRS Transmission
Logical name Definition This flag indicates whether or not one Slave PDCH for (E)GPRS traffic usage will be statically established in the cell. Instance Type Range Enable / Disable Default value Disable Optimised value
EN_FAST_INITIAL_GPRS_ACCESS
cell
Flag
ED NE
011 52/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
T_GCH_INACTIVITY
T_GCH_INACTIVITY_LAST
N_GCH_FAST_PS_ACCESS
GPRS_MULTISLOT_CLASS_DEF_VALUE
ATER_USAGE_THRESHOLD
N_ATER_TS_MARGIN_GPU
GCH_RED_FACTOR_HIGH_ATER_USAGE
- For Non Evolium BTS : Timer to postpone the release of one slave PDCH, when it does not support any (E)GPRS traffic. - For Evolium BTS : Timer to postpone the release of the "unused" GCHs of the M-EGCH link of a TRX (the condition for some GCHs of the M-EGCH link of a TRX to become "unused" is that some TBFs - For Non Evolium BTS : Timer to postpone the release of the last established slave PDCH of a cell, when it does not support GPRS traffic anymore. - For Evolium BTS : Timer to postpone the release of the last N_GCH_FAST_PS_ACCESS GCHs established in a cell, when the last TBF has been released in the cell. Two definitions are possible : - If EN_FAST_INITIAL_GPRS_ACCESS = enabled : number of GCHs required to be established due to the Fast Initial PS Access feature, - If EN_FAST_INITIAL_GPRS_ACCESS = "disabled : number of GCHs to keep established when there is no more (E)GPRS traffic in a cell (while the T_GCH_INACTIVITY_LAST timer is running). Those GCHs will be useful in case of (E)GPRS traffic resumption in the cell. Default value of the (E)GPRS multislot class assumed at TBF establishment when the actual MS (E)GPRS multislot class is unknown. Threshold (percentage of used Ater nibbles, in a GPU) above which the Ater usage is said high. Number of free 64k Ater TSs that are kept in reserve in order to be able to serve some prioritary requests in cells managed by the GPU. The prioritary requests are the GCH establishment requests launched when the first TBF has to be established in a cell. Reduction factor of the number of GCHs targeted per PDCH, when the Ater usage is high.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
BSS
Number
1 to 100
BSS
Number
1 to 200
20
MFS
Number
1 to 5
BSS
Number
1 to 8
BSS
Percentage
1 to 100
70
BSS
Number
0 to 10
cell
Number
0 to 1
0.75
EN_PSI_STATUS
cell
Flag
Disable
ED NE
011 53/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
3 NETWORK DIMENSIONING
The BSS network architecture and dimension had a high improvement with B9 release. Dynamic Abis and the new Ater resources usage, along with the M-EGCH, allowed the dynamically of the transmission resources and prepared the Alcatel-Lucent BSS to the future. The BSS architecture in B9 can be summarize in the next figure:
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
TC
MT120
TCUC
SMU TRCU TRCU TRCU
speech
MT120
Air
CS traffic PS traffic TRX 1 TRX 2 TRX 3 TRX n
TCH TCH
SMU
A-bis
GCH Basic
BSC
Abis TSU Abis TSU Abis TSU Ater TSU Ater TSU Ater TSU
GCH Basic GCH Bonus GCH Extra
CS
CS
M-EGCH link n
A-ter mux
CS+ PS PS
MFS
GPU board
DSP DSP DSP DSP
GCH Extra
BTS
Up to 12 TRXs per BTS
data
GPU board
DSP DSP DSP DSP
Gb
TC
MT120
VTCU
SMU TRCU TRCU TRCU
speech
MT120
Air
CS traffic PS traffic TRX 1 TRX 2 TRX 3 TRX n
TCH TCH
A-bis
GCH Basic
SMU
MxBSC
GCH Basic GCH Bonus GCH Extra
CS
CS
M-EGCH link n
A-ter mux
CS+ PS PS
MxMFS
GP board
DSP DSP DSP DSP
GCH Extra
BTS
Up to 24 TRXs per BTS with Twin Modules
data
GP board
DSP DSP DSP DSP
Gb
The BSS dimensioning explained in this chapter is only an overview and the document of the reference should be used for a deeper understanding. The traffic profile and the operator objectives are external variables, impacting the network dimensioning. Simple cases will be considered in the examples. The dimensioning will be focus in the 3 main interfaces/equipments: o o o
ED NE
3DF 01900 0000 PTZZA DIAMS
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
3.1 ABIS
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
The Abis dimensioning in B9 is at BTS level, as explained in chapter 2.3.2, this is due to the fact that the bonus and extra Abis nibbles are shared by all TRXs of the BTS. The bonus Abis nibbles are mainly depended of the BTS configuration, number of cells and number of SDCCH configured. The extra Abis nibbles are depended of the Abis resources load and they can be mapped by the parameter N_extra_Abis_TS.
For Abis dimensioning three examples are proposed, the first one is applied to Abis dimensioning computation based on operator requirements; the second presents an impact of the defined dimensioning and the third example is an easy explanation how to dimension an Abis interface based in statistical data.
Example 1 The proposal of this example is to determine the number of extra Abis TS required in a BTS to accomplish the operator objectives.
Operator objectives: o o 2 users with Class 10 MS simultaneous in a BTS DL data transfer in MCS9
BTS configuration: o o 3 cells with 2 TRX and 1 SDCCH per cell. No limitations of radio resources allocation (Max_SPDCH_Limit)
Based on the operator objectives the number of GCH required is: o 4.5 GCH per radio TS in MCS9 x 4 PDCH per user x 2 users = 36 GCH (16 kbit/s Abis nibbles)
The present number of available GCH in the cell is: o o o 6 bonus nibbles available for PS (from the 3 BCCH and the 3 SDCCH) 4 PDCH per user x 2 users x 1 GCH from basic nibbles = 8 GCH 6 nibbles + 8 basic = 14 GCH
The number of GCHs in deficit is: o number of GCH required - number of available GCH in the cell = 36 14 = 22 GCH
The number of required extra Abis TS is given by the number of GCHs in deficit: o o
3DF 01900 0000 PTZZA DIAMS
22 GCH in deficit (16 kbit/s Abis nibbles) / 4 Abis nibles per Abis TS = 5.5 Extra Abis TS As a conclusion: The N_EXTRA_ABIS_TS should be set to 6 to fulfil the requirement
Example 2: For the previous configuration including the N_extra_Abis_TS = 6, the impact in the DL throughput performance of a third user with MS class 10 will be explained in the example:
ED NE
011 55/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Assumption: o o o Each user is alone in one of the cells. Cell transmission equity is not possible, since the users are served by different cells Max_SPDCH_limit = 4 per cell.
The total number of GCHs available in the BTS is: o Total number of GCHs - The number GCH already in use by the 2 users = 42 -36 = 6 GCH
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Where the: o o Total number of GCHs = 6 nibbles + 12 basic + 6*4 extra Abis nibbles = 42 GCH 12 basic = 4 PDCH per user x 3 users x 1 GCH from basic nibbles = 12 GCH
The required number of GCH for the third user is: o 4.5 GCH per radio TS in MCS9 x 4 PDCH per user x 1 users = 18 GCH
The 6 GCH available to be established in the M-EGCH will allowed a maximum MCS of MCS9. The expected DL RLC throughput should be around 6 / 18 = 33.3% of the maximum DL RLC throughout without transmission constrains.
Example 3: This example explains the method to calculate the number of extra Abis nibbles needed for a cell. It is an easy method, however it is only applied for PS dimensioning of the Abis. The method is applied when congestion in the Abis is observed, it takes in consideration that the traffic not allowed due to the congestion should be carry by the extra Abis nibbles. The input variables are indicators from O&M counters.
Where: o o
Measured _ Extra & Bonus _ Abis _ Traffic 1 Min(%TBF _ Abis _ Cong ,30%)
3DF 01900 0000 PTZZA DIAMS
With:
ED NE
011 56/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
o
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
P 466 3600
o o
%TBF _ ABIS _ Cong = Max(% DL _ TBF _ Abis _ Cong ,%UL _ TBF _ Abis _ Cong ) % DL _ TBF _ Abis _ Cong = %UL _ TBF _ Abis _ Cong = P105i 100% P91a + P91b + P91c + P91d + P91e + P91 f P105 j 100% P 62a + P 62b + P 62c P 438c
After the calculation of the number of required extra & Bonus Abis nibbles using the Erlang C formula, it is needed to remove the bonus Abis nibbles and dividing per four the total number of extra Abis TSs needed are found.
3.2 ATER
In the computation of the number of needed AterMux links the capacity of 112 GCH per link is taken in order to be able to support GSL carrying The goal of the AterMux interface dimensioning assessment is to estimate the needed number of GCH resources in order to be able to support the estimated Required_GCH_traffic (the traffic in Erlang that AterMux interface should handle for not having congestion).
The proposal methods for Atermux dimensioning take as input variables the real data. 2 different methods can be used for dimensioning estimation: o o Method 1: driven by the estimation of the required traffic as a function of the measured GCH traffic and of Ater/GPU congestion Method 2: driven by the estimation of the required traffic as a function of the measured GCH and radio PS traffic
3.2.1 METHOD 1
The method 1 is a function of existing GCH traffic and Ater/GPU congestion and it is only valid if the GCH congestion is lower than 30%. The measured GCH traffic is given by the counter P100c and the Ater/GPU congestion is given by the counters P383a, P384, P201, P202 and P404, these counters are explained in the chapter 5.4.
ED NE
011 57/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
3.2.2 METHOD 2
The method 2 is function of the relation between the GCH traffic and the PDCH traffic, if a saturation of the GCH resources is observed a new Ater dimensioning should be performed.
ED NE
011 58/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
The Required_GCH_Traffic is quasi linear relationship of the PDCH traffic, before there is congestion or reduction due to High Ater load. If saturation is observed with n Atermux link some extra links should be added, up to 5 Atermux per GPU. The Required_GCH_traffic can be found doing an extrapolation of the linear relationship between GCH and PDCH traffic and taking the GCH traffic value corresponding to the maximum observed PDCH traffic.
ED NE
011 59/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Yes
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
No
Increase_factor estimated on the basis of the Avg_target_nb_GCH_per_PDCH (depending on the target service penetration) Increase_factor = Avg_target_nb_GCH_per_PDCHfinal / Avg_target_nb_GCH_per_PDCHinitial
Execute transition
Update reference BSCs set Figure 38: Increase factor The increase factor will be a function of: o o o The transition type The target service penetration (i.e. %EDGE with respect to GPRS) The traffic profile
A transition type is explained by the following figure, depending on the path (a, b, c, d and e) different increase factor is applied:
CS3 / CS4
CS1 / CS2
EDGE
Figure 39: Transition type If no reference BSC exists the increase factor is calculated taking in account assumption of the EGPRS penetration at cell level. The increase factor is given by the relation between the number of GCHs per PDCH before and after the service activation: o
Increase_factor =
ED NE
011 60/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Where: o
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
o o o o
For the different transition type the increase factor is given by:
For method 1 the application of the increase factor is by the simple formula: o
For method 2 the impact of the increase factor is applied in the slope, as explained in the next graphic:
ED NE
011 61/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
3.3 GPU/GP
The number of GPU/GP boards can be estimated thanks to the computed Needed GCH and to the computed GPU_GCH_Capacity.
The GPU_GCH_Capacity is the number of GCH that a GPU/GP can handle. It is given by the minimum of three variables:
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Min{ Max _ DL _ GCH _ per _ GPU , Max _ UL _ GCH _ per _ GPU , HW / SW _ Capability}
The variables are defined by: o HW/SW capability - Maximum number of GCH per GPU is: B9MR1: 480 N_ATER_TS_MARGIN_GPU*4 B9MR4: Legacy MFS: 480 N_ATER_TS_MARGIN_GPU*4 MxMFS: 1560 N_ATER_TS_MARGIN_GPU*4 o Max_DL_GCH_per_GPU and Max_DL_GCH_per_GPU The maximum number of GCHs that the GPU will be able to handle can be obtained knowing the (M)CS distribution of the analyzed network:
(%CS1 max_PDCH_CS1 max_DL_GCH_CS1) + ... + (%MCS1 max_PDCH_MCS1 max_DL_GCH_MCS1) + ... (%CS1 max_PDCH_CS1 max_UL_GCH_CS1) + ... + (%MCS1 max_PDCH_MCS1 max_UL_GCH_MCS1) + ...
Where Max_DL/UL_GCH_CSy is defined in table 5. Max_DL/UL_GCH_MCSxP57x is defined in table 6 The maximum number of PDCH per GPU/GP is dynamic depending on the used coding schemes and on the HW/SW capability:
Max_DL_GCH_GPU =
Max_UL_GCH_GPU =
ED NE
011 62/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Table 18: max_PDCH_CSy per GPU/GP determination for GPRS GPRS max_PDCH_CSy: Max nb of PDCH per GPU/GP GP (A9130) GP (A9130) GP (A9130) GPU (A9135) & from B9MR4 from B9MR4 from B9MR4 Max CS GP (A9130) up Case 12 E1 Case 16 E1 Case 10 E1 to B9MR1 links per GP links per GP links per GP CS1 240 960 960 896 CS2 CS3 CS4 240 224 200 960 892 684 960 892 804 896 716 544
EGPRS
Table 19: max_PDCH_MCSx per GPU/GP determination for EGPRS max_PDCH_MCSx: Max nb of PDCH per GPU/GP GPU (A9135) & GP (A9130) up to B9MR1 224 224 208 200 184 172 136 116 108 GP (A9130) from B9MR4 Case 12 E1 links per GP 860 836 796 748 604 476 320 272 252 GP (A9130) from B9MR4 Case 16 E1 links per GP 860 836 796 776 704 664 452 380 352 GP (A9130) from B9MR4 Case 10 E1 links per GP 860 836 672 596 480 380 256 216 200
Max MCS MCS1 MCS2 MCS3 MCS4 MCS5 MCS6 MCS7 MCS8 MCS9
The number of GPU/GP needed is then given by dividing the needed GCH per the GPU_GCH_Capacity.
ED NE
011 63/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
4 NETWORK PRIORITIES
With the introduction of the packet switch, in GSM networks, the radio and transmission resources available have to be shared between the circuit and packet switch, it is a compromise between different variables: the CS accessibility, PS accessibility, PS performance and most important with the operator network capacity. Normally, when PS is activated in a network, the traffic is mainly due to signalling (GMM/SM), with the time and with the new services arriving, the end user customers begin to use these services as a daily routine and the PS traffic starts to have more weight in the network. Two major reasons are associated to a rapidly increase of PS traffic in a network, flat rates and short data traffic (e.g. chat, MMS, etc). With the increase of PS traffic the network architecture and dimensioning have to be reviewed, parameters values implemented during the EDGE activation have to be optimised to the new reality. The increase of capacity in a network, either radio or transmission, impacts the costs and due to that the operators are quite sensitive to this issue. Thats why, a consistent and rigorous approach has to be considered on this topic.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Three different main phases exist for the PS dimensioning and optimisation:
o o o
Phase 1 - PS implementation/activation, the network is dimensioning for low PS traffic, mainly signalling traffic. Phase 2 - Increase of PS traffic without enough radio and transmission resources parameters optimization needed to minimize the impact Phase 3 Re-dimensioning of the network architecture.
In all the three phases the CS is the service with more priority, it is only considered the CS accessibility since the performance is not impacted by PS access and traffic.
4.1 PHASE 1
For the phase 1, the network is carrying the first data traffic, it is mainly signalling (GMM/SM). The few customers using user data service are spread in time and location. The traffic load created by them is low. In this way the operators define their network priorities as:
The operators want to give to the few users the best performance as possible, not only throughput but also small establishment time. Due to this, the configuration and parameterization is optimized to achieve the better performance as possible. In order to reduce the GPRS signalling traffic and their impact in the radio and transmission resources load some GSS optimisations are possible, for more information see sub-chapter 6.8 In this phase the parameters are in their default value, for best performance. For the default parameters values see sub-chapter 2.10.
4.2 PHASE 2
The PS traffic increases with the new services, the capacity dimensioned during the PS implementation is not enough. Congestion problems appear in the transmission and degradation of the PS accessibility and performance begins due to the under dimensioned radio resources. The operator should react and it should
ED NE
011 64/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
optimize the network in accordance. This phase is a transition phase; it should be used for only a short time.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
The PS performance is no longer a major priority, important is to give PS access to all users and the priorities are redefined as:
The BSS parameters should be optimised to able the implementation of the new network priorities. This phase is when the PS traffic had increase to a critical situation; the major problem observed is congestion at transmission level Ater and Abis and at DSP side. The parameter tuning proposed for this situation is explained in chapters 6.6 and 6.7.
4.3 PHASE 3
With the upgrade of the transmission and radio resources, the network priorities are again reordered to similar to phase 1:
The PS performance is again an operator priority, the user want to have his service with a good quality. The BSS parameters should be optimised to allow a better throughput, e.g. more bandwidth in radio and transmission resources. It is proposed to get back the parameter values to the default ones. For the default parameters values see sub-chapter 2.10
ED NE
011 65/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
5 QOS FOLLOW-UP
In this chapter is presented the main RNO indicators for QoS follow-up, they are grouped in three specific RNO reports called dashboards: o o o Alc_Mono_DashBoard_(E)GPRS_QoS Alc_Mono_DashBoard_(E)GPRS_Traffic_1
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Alc_Mono_DashBoard_(E)GPRS_Traffic_2
The Main RNO indicators are also included in several RNO reports and in this way it is also presented in this chapter the main RNO reports to analyse. An overview of end-user statistics is described in the sub-chapter 5.6.
GPRS_DL_TBF_request
nb
GPRS_DL_TBF_estab_allocated_rate
Rate of DL TBF estab - failures due to BSS problem per cell. Reference: number of DL TBF estab -requests Rate of DL TBF estab -failures due to Gb interface GPRS_DL_TBF_estab_fail_GB_rate problem per cell. Reference: number of DL TBF estab -requests Rate of DL TBF estab -failures due to radio GPRS_DL_TBF_estab_fail_radio_rate problem per cell. Reference: number of DL TBF estab -requests Rate of DL TBF establishment failures due to congestion per cell. GPRS_DL_TBF_estab_fail_cong_rate Reference: number of DL TBF establishment requests. Number of DL establishment failures due to GPRS_DL_TBF_estab_fail_abis_cong congestion of Abis. Number of DL establishment failures due to GPRS_DL_TBF_estab_fail_ater_cong congestion of Ater(Mux). Number of DL establishment failures due to CPU GPRS_DL_TBF_estab_fail_cpu_cong processing power limitations of the GPU. Number of DL establishment failures due to GPRS_DL_TBF_estab_fail_dsp_cong congestion of DSP. Number of DL TBF establishment failure due to GPRS_DL_TBF_estab_fail_radio_cong radio congestion per cell. GPRS_DL_TBF_estab_fail_BSS_rate
nb nb nb nb nb Split of the congestion failures, this information is important for BSS dimensioning
ED NE
011 66/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Description Rate of UL TBF estab success. Reference: number of UL TBF estab -requests Number of UL TBF establishment -requests per cell. Rate of UL TBF allocated per cell.
Unit % nb % %
Comments
The absolute number of requests is important to validate the statistics This indicator measure the impact of the congestion
Rate of UL TBF estab -failures due to BSS problem per cell. Reference: number of UL TBF estab -requests Rate of UL TBF estab -failures due to Gb GPRS_UL_TBF_estab_fail_GB_rate interface problem per cell. Reference: number of UL TBF estab -requests Rate of UL TBF estab -failures due to radio GPRS_UL_TBF_estab_fail_radio_rate problem per cell. Reference: number of UL TBF estab -requests Rate of UL TBF establishment failures due to congestion per cell. GPRS_UL_TBF_estab_fail_cong_rate Reference: number of UL TBF establishment requests. Number of UL establishment failures due to GPRS_UL_TBF_estab_fail_abis_cong congestion of Abis. Number of UL establishment failures due to GPRS_UL_TBF_estab_fail_ater_cong congestion of Ater(Mux). Number of UL establishment failures due to GPRS_UL_TBF_estab_fail_cpu_cong CPU processing power limitations of the GPU.. Number of UL establishment failures due to GPRS_UL_TBF_estab_fail_dsp_cong congestion of DSP. Number of UL TBF establishment failure due to GPRS_UL_TBF_estab_fail_radio_cong radio congestion per cell.
nb nb nb nb nb Split of the congestion failures, this information is important for BSS dimensioning
When performing an investigation in the TBF establishment performance, a typical threshold to consider is for DL is 95%, however for UL the threshold is lower 92% mainly due to signalling impact. These values are high depended of the network configuration and overall performance. The different failure causes should be analysed: o o o Failures due to Gb this might indicate problems at Gb link side (no BVC available, which would affect the cell this implies that the cells operational state is disabled); Failures due to BSS this might indicate a system problem (e.g.: faulty board at MFS side). Verify also if CS traffic is being affected due to BSS causes (e.g. TCH assign failures due to BSS); Failures due to congestion: these can also be divided in other sub-causes: Radio congestion this might be due to badly functioning resources (like a TRE not working, with unavailable TS or even 0 available TS), from too much CS traffic, or even from too much PS traffic. Abis congestion, Ater congestion, DSP congestion and CPU congestion either due to lack of GCHs resources or not enough DSP and/or CPU processing power.
Failures due to radio might indicate radio problems (e.g. bad frequency plan, bad coverage planning)
ED NE
011 67/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
GPRS_DL_TBF_normal_release_rate
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
GPRS_DL_TBF_acceptable_release_rate
Rate of DL TBF release due to: - DL TBF release due to radio preemption - DL TBF release due to suspend resume procedure - DL TBF release due to cell reselection. Reference : number of DL TBF successes Rate of DL TBF drops. Reference: number of DL TBF establishment successes Number of DL TBF normal release. Number of DL TBF release due to : - DL TBF release due to radio preemption - DL TBF release due to suspend resume procedure - DL TBF release due to cell reselection Total number of DL TBF drops. Rate of DL TBF releases due to fast preemption in case of need of radio resources. Reference: number of DL TBF establishment successes. Rate of suspend messages for a DL TBF received from MS (via BSC). Reference: number of DL TBF establishment successes. Rate of DL TBF releases due to NC2 cell reselection Reference: total number of DL TBF establishment success Rate of DL TBF releases due to NC0 cell reselection Reference: total number of DL TBF establishment success Rate of DL TBF drops due to BSS problems. Reference: number of DL TBF establishment successes Rate of DL TBF drops due to Gb interface problems. Reference: number of DL TBF establishment successes Rate of DL TBF drops due to blocking situation at the beginning or at the end of DL TBF ( including blocking situation following NC2 cell reselection) . Reference: number of DL TBF establishment successes. Rate of DL TBF drops due to N_StagnatingWindow (including N_StagnatingWindow following cell reselection in transfer mode). Reference: number of DL TBF establishment successes
GPRS_DL_TBF_drop_rate GPRS_DL_TBF_normal_release
% nb
GPRS_DL_TBF_acceptable_release
nb
GPRS_DL_TBF_drop GPRS_DL_TBF_radio_preemption_release_rate
nb %
GPRS_DL_TBF_release_suspend_rate
GPRS_DL_TBF_release_NC2_reselect_rate
GPRS_DL_TBF_release_NC0_reselect_rate
GPRS_DL_TBF_drop_BSS_rate
GPRS_DL_TBF_drop_GB_rate
GPRS_DL_TBF_drop_blocking_rate
GPRS_DL_TBF_drop_N_stagnatingWindow_rate
ED NE
011 68/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
GPRS_DL_TBF_realloc_execution_fail_radio_rate
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
GPRS_DL_TBF_drop_radio_rate
Rate of DL TBF drops due to radio failures during radio resource reallocation execution. Reference: number of DL TBF establishment successes. Rate of DL TBF drops due to radio problems. Reference: number of DL TBF establishment successes
GPRS_UL_TBF_normal_release_rate
GPRS_UL_TBF_acceptable_release_rate
GPRS_UL_TBF_drop_rate GPRS_UL_TBF_normal_release
% nb
GPRS_UL_TBF_acceptable_release
nb
GPRS_UL_TBF_drop
nb
GPRS_UL_TBF_radio_preemption_release_rate
GPRS_UL_TBF_release_suspend_rate
GPRS_UL_TBF_release_NC2_reselect_rate
GPRS_UL_TBF_release_NC0_reselect_rate
GPRS_UL_TBF_drop_BSS_rate
GPRS_UL_TBF_drop_GB_rate
GPRS_UL_TBF_drop_blocking_rate
ED NE
011 69/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
GPRS_UL_TBF_drop_N_stagnatingWindow_rate
GPRS_UL_TBF_realloc_execution_fail_radio_rate
GPRS_UL_TBF_drop_radio_rate
Rate of UL TBF drops due to N_StagnatingWindow (including N_StagnatingWindow following cell reselection in transfer mode). Reference: number of UL TBF establishment successes Rate of UL TBF drops due to radio problems during radio resource reallocation execution Reference: number of UL TBF establishment successes. Rate of UL TBF drops due to radio problems Reference: number of UL TBF establishment - successes
%
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
It is acceptable to have as lower as 95% for DL/UL TBF normal release rate, in case of DL/UL TBF drop rate is expected to have value up to 4%.These value can change with the network design and interference noise level in the network. To perform an investigation in the data transfer, verify how TBFs are being abnormally released. The following causes are possible: o o o RLC blocks are being lost during the GPRS connection RLC blocks are being retransmitted too many times check the TBF Retransmission Ratio KPI; Connection drop is high this might be due to 3 other sub-causes: o System drop indicating a system problem. Verify other KPI (GSM included); Gb drop indicating problem on Gb interface;
Radio drop this might be due either to real radio drops or to acceptable releases (due to cell reselection; suspend/resume procedure; PDCH pre-emption).
Comments
ED NE
011 70/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
GPRS_UL_TBF_realloc_T4_success_rate
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Rate of UL TBF resource reallocation successes for trigger T4. Reference: number of UL TBF candidate for resource reallocation for trigger T4. Number of UL TBF candidate for resource reallocation (trigger T1). Number of UL TBFs candidate for resource reallocation (trigger T2). Number of UL TBF candidate for resource reallocation (trigger T3). Number of UL TBF candidate for resource reallocation (trigger T4).
The investigation of the reallocation indicators is complex due to the high number of variables impacting the reallocation algorithm performance. Depending on the trigger of each reallocation there is impact of the PS traffic type and load, CS traffic load, network architecture, telecom parameters and MS type. For one reallocation the trigger can also be due to two different reasons radio resources or transmission resources, as possible analyses: o o High frequency of occurrence of T1 might indicate that the cell is sub-dimensioned to accommodate all CS and PS traffic; The high number of T2 requests can be a consequence of the value of the parameter GPRS_Multislot_Class_Def_Value and the traffic type (user data or GMM /SM).
For the reallocation indicators is not possible to define global thresholds since the performance of these indicators will change from network to network.
GPRS_DL_useful_RLC_blocks_CS1_ack_ratio
GPRS_DL_useful_RLC_blocks_CS2_ack_ratio
ED NE
011 71/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
GPRS_DL_useful_RLC_blocks_CS3_ack_ratio
GPRS_DL_useful_RLC_blocks_CS4_ack_ratio
GPRS_DL_useful_RLC_blocks_MCS1_ack_ratio
GPRS_DL_useful_RLC_blocks_MCS2_ack_ratio
GPRS_DL_useful_RLC_blocks_MCS3_ack_ratio
GPRS_DL_useful_RLC_blocks_MCS4_ack_ratio
GPRS_DL_useful_RLC_blocks_MCS5_ack_ratio
GPRS_DL_useful_RLC_blocks_MCS6_ack_ratio
GPRS_DL_useful_RLC_blocks_MCS7_ack_ratio
GPRS_DL_useful_RLC_blocks_MCS8_ack_ratio
GPRS_DL_useful_RLC_blocks_MCS9_ack_ratio
GPRS_DL_useful_throughput_radio_EGPRS_TBF_avg
GPRS_DL_useful_throughput_radio_GPRS_TBF_avg
Ratio of useful DL RLC blocks sent on PDTCH encoded in CS-3, in RLC acknowledged mode (the retransmitted blocks are not counted). Overall number of useful RLC data blocks encoded in CS1-2-3-4 Ratio of useful DL RLC blocks sent on PDTCH encoded in CS-4, in RLC acknowledged mode (the retransmitted blocks are not counted). Overall number of useful RLC data blocks encoded in CS1-2-3-4 Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-1, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-2, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-3, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-4, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-5, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-6, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-7, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-8, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-9, in RLC acknowledged mode (the retransmitted blocks are not counted). Average DL useful throughput (in kbit/s) in RLC acknowledged mode. The DL retransmissions are not counted. Reference Time: Cumulated time duration of all active DL TBFs established in EGPRS mode. Average DL useful throughput (in kbit/s) in RLC acknowledged mode. The DL retransmissions are not counted. Reference Time : Cumulated time duration of all active DL TBFs established in GPRS mode.
%
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
kbit/ s
kbit/ s
High impacted by the small data transfer, such as GMM and SM.
For UL:
ED NE
011 72/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
GPRS_UL_useful_RLC_blocks_CS1_ack_ratio
GPRS_UL_useful_RLC_blocks_CS2_ack_ratio
GPRS_UL_useful_RLC_blocks_CS3_ack_ratio
GPRS_UL_useful_RLC_blocks_CS4_ack_ratio
GPRS_UL_useful_RLC_blocks_MCS1_ack_ratio
GPRS_UL_useful_RLC_blocks_MCS2_ack_ratio
GPRS_UL_useful_RLC_blocks_MCS3_ack_ratio
GPRS_UL_useful_RLC_blocks_MCS4_ack_ratio
GPRS_UL_useful_RLC_blocks_MCS5_ack_ratio
GPRS_UL_useful_RLC_blocks_MCS6_ack_ratio
GPRS_UL_useful_RLC_blocks_MCS7_ack_ratio
GPRS_UL_useful_RLC_blocks_MCS8_ack_ratio
GPRS_UL_useful_RLC_blocks_MCS9_ack_ratio
GPRS_UL_useful_throughput_radio_EGPRS_TBF_avg
3DF 01900 0000 PTZZA DIAMS
Description Ratio of useful UL RLC blocks sent on PDTCH encoded in CS-1, in RLC acknowledged mode (the retransmitted blocks are not counted). Overall number of useful RLC data blocks encoded in CS1-2-3-4 Ratio of useful UL RLC blocks sent on PDTCH encoded in CS-2, in RLC acknowledged mode (the retransmitted blocks are not counted). Overall number of useful RLC data blocks encoded in CS1-2-3-4 Ratio of useful UL RLC blocks sent on PDTCH encoded in CS-3, in RLC acknowledged mode (the retransmitted blocks are not counted). Overall number of useful RLC data blocks encoded in CS1-2-3-4 Ratio of useful UL RLC blocks sent on PDTCH encoded in CS-4, in RLC acknowledged mode (the retransmitted blocks are not counted). Overall number of useful RLC data blocks encoded in CS1-2-3-4 Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-1, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-2, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-3, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-4, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-5, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-6, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-7, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-8, in RLC acknowledged mode (the retransmitted blocks are not counted). Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-9, in RLC acknowledged mode (the retransmitted blocks are not counted). Average UL useful throughput (in kbit/s) in RLC acknowledged mode. The UL retransmissions are not counted. Reference: Cumulated time duration of all UL TBFs established in EGPRS mode.
Unit
Comments
ED NE
011 73/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
GPRS_UL_useful_throughput_radio_GPRS_TBF_avg
Average UL useful throughput (in kbit/s) in RLC acknowledged mode. The UL retransmissions are not counted. Reference Time: Cumulated time duration of all UL TBFs established in GPRS mode.
The (M)CS distribution may be impacted by the radio conditions, telecom parameters but they are almost not impacted by the transmission resources in B9 release.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
It is normal to have the major sample in the (M)CS corresponding to the TBF_DL/UL_INIT_(M)CS, default for GPRS is CS2 and for EDGE is MCS3. The impact of the initial (M)CS is high due to the high number of TBFs with small data transferred, GMM/SM and MMS, A high number of MCS1 or CS1 can be due to the existing radio conditions or due to limit transmission resources. In B9 and in cells covering an area with good radio conditions, the MCS9 should have weight in the overall distribution.
The split of LCC traffic by the Radio Access Capabilities are in the next 2 tables. For DL: Table 28: DL LLC traffic
Description Number of DL LLC bytes transmitted and acknowledge GPRS_DL_LLC_bytes_EGPRS_ack_mode on established DL TBF in EGPRS mode and RLC acknowledged mode Number of DL LLC bytes transmitted and acknowledge GPRS_DL_LLC_bytes_EGPRS_unack_mode on established DL TBF in EGPRS mode and RLC unacknowledged mode Number of DL LLC bytes transmitted and acknowledge GPRS_DL_LLC_bytes_GPRS_ack_mode on established DL TBF in GPRS mode and RLC acknowledged mode Number of DL LLC bytes transmitted and acknowledge GPRS_DL_LLC_bytes_GPRS_unack_mode on established DL TBF in GPRS mode and RLC unacknowledged mode RNO indicator Unit nb
nb
nb
nb
For UL:
ED NE
011 74/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
nb nb nb
The indicators for RLC traffic are the next tables For DL: Table 30: DL RLC traffic
Description Unit Comments Number of useful RLC data bytes GPRS_DL_useful_bytes_CSx_ack sent on PDTCH, in GPRS and RLC ack nb modes. Number of useful RLC data bytes GPRS_DL_useful_bytes_MCSx_ack sent on PDTCH, in EGPRS and RLC nb ack modes. In RLC ack mode, ratio of downlink This indicator is an RLC retransmitted data bytes sent overall indication, on PDTCH and encoded in CS-x. however some CS GPRS_DL_RLC_bytes_PDTCH_CSx_retransmission_ratio % Reference : overall number of DL may be more RLC data bytes transmitted in GPRS retransmitted than mode others. In RLC acknowledged mode, ratio of DL RLC data bytes encoded in MCS-x and retransmitted due to This indicator is an unacknowledgement of the MS. RLC GPRS_DL_RLC_bytes_PDTCH_MCSx_retrans_ack_ratio blocks containing LLC dummy UI % overall indication, however some CS commands are not counted. Reference: overall number of DL may be more RLC data bytes transmitted in EGPRS retransmitted than mode. others. RNO indicator
ED NE
011 75/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
For both DL and UL the MCS retransmission rate can be up to 10%, this value is due to the fact of the higher MCS being less robust and so more sensible to interference.
GPRS_PDCH_traffic_time
GPRS_PDCH_active_avg
GPRS_PDCH_used_max
GPRS_DL_connection_time_avg GPRS_UL_connection_time_avg
s s
GPRS_DL_TBF_Pilled_avg
GPRS_UL_TBF_Pilled_avg
GPRS_DL_TBF_estab_avg
nb
GPRS_UL_TBF_estab_avg
nb
GPRS_PDCH_per_DL_TBF_avg
GPRS_PDCH_per_UL_TBF_avg
ED NE
011 76/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
GPRS_PDCH_used_DL_TBF_GMM _signalling_time_ratio
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Ratio of time during which a DL TBF established for GMM signaling purposes uses a PDCH, compared with all DL PDCH established, for all PDCHs and for all the TBFs of the cell. Percentage of time during which downlink TBFs are granted the maximum number of PDCHs they support and the GPRS_DL_biased_and_DL_optima corresponding MSs are engaged in downlink-biased transfers. l_alloc_percent Reference: time during which MSs are engaged in downlinkbiased transfers and served by DL TBFs. Percentage of time during which uplink TBFs are granted the maximum number of PDCHs they support and the GPRS_UL_biased_and_UL_optim corresponding MSs are engaged in uplink-biased transfers. al_alloc_percent Reference: time during which MSs are engaged in uplinkbiased transfers and served by UL TBFs. Percentage of time during which the BSC is in high load GPRS_BSC_high_load_percent situation in the cell. Reference: Granularity period Maximum number of PDCHs that can be allocated in the cell. GPRS_MAX_PDCH_nb_avg This indicator is consolidated in Day/Week/Month with the average of Hour/Day/Week values. Minimum number of PDCHs that can be preferentially allocated in the cell. GPRS_MIN_PDCH_nb_avg This indicator is consolidated in Day/Week/Month with the average of Hour/Day/Week values.
% This indicator is a function of the parameter Max_PDCH This indicator is a function of the parameter Min_PDCH
nb
nb
GPRS_transmission_GCH_deficit_average
nb
nb nb nb
These transmission indicators are very wide and for a deeper investigation there is in RNO a few number of indicators for CELL, BSS and GPU. It is also recommended to read sub-chapters 6.6 and 6.7.
Alc_Mono_GPRS_telecom: This report provides details about main GPRS Telecom procedures. DL TBF establishment UL TBF establishment DL TBF Release UL TBF Release
RELEASED 3DF XXXX XXXX PTZZA 011 77/96
ED NE
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
o o
DL TBF Acceptable Release causes UL TBF Acceptable Release causes DL TBF Drop Causes UL TBF Drop Causes DL TBF state UL TBF state DL session UL session
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Alc_Mono_GPRS_Throughput: This report provides details of GPRS/EGPRS throughputs. Radio throughput per cell DL GPRS radio throughput UL GPRS radio throughput DL EGPRS radio throughput UL EGPRS radio throughput
Alc_Mono_GPRS_Resource_Reallocation_DL: This report provides details about the procedures related to the DL resource reallocation feature DL resource realloc DL resource realloc T1 DL resource realloc T2 DL resource realloc T3 DL resource realloc T4
Alc_Mono_GPRS_Resource_Reallocation_UL: This report provides details about the procedures related to the UL resource reallocation feature UL resource realloc UL resource realloc T1 UL resource realloc T2 UL resource realloc T3 UL resource realloc T4
Alc_Mono_GPRS_RLC_Ack_Traffic_Coding_Schemes: This report provides all the views related to RLC traffic and efficiency in RLC acknowledged mode. RLC traffic in Acknowledge Mode DL EGPRS useful RLC traffic UL EGPRS useful RLC traffic GPRS DL useful RLC traffic GPRS UL useful RLC traffic DL RLC Ack retransmitted traffic per CS UL RLC Ack retransmitted traffic per CS
3DF 01900 0000 PTZZA DIAMS
Alc_Mono_GPRS_PDCH_Use_B9: This report provides all views related to PDCH allocation B9. Load Report Traffic time and Active number of PDCHs
RELEASED 3DF XXXX XXXX PTZZA 011 78/96
ED NE
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
DL TBF Pilled UL TBF Pilled PDCH per DL TBF PDCH per UL TBF DL TBF establishment per MS type UL TBF establishment per MS type GMM Signaling PDCH Preemption
Alc_Mono_GPRS_Transmission_Resources: This report provides details about main GPRS transmission resources. GPRS GCH resources Extra and Bonus Abis nibbles GCH in deficit GCH in excess
The EDGE protocol for end-user tests is detailed in reference [1]. The recommended protocol by NE should be followed to allow the proper support from NE team. A deviation from the protocol may lead to results different from the ones expected. The expected values for these indicators are presented in this subchapter, they are the processed data collected from different field trials. The analysis is based in statistical values and due to that it is highly dependent of samples quality. A method was considered to validate in a first step the samples and then the final results.
During an end-user field trial several external variables can impact the results: o o o o o Upper layers (TCP/IP and FTP) performance Radio conditions (good, normal, radio) RF load (high CS traffic, high PS traffic) Radio resources allocation (number of PDCHs allocated, number of TBFs per PDCH) Transmission resources allocation (number of GCH)
Three different radio conditions are considered and they are based in the indicators RxLev and Mean_BEP.
ED NE
011 79/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Table 34: Radio Conditions RxLev [-55 dBm, -65 dBm] [-65 dBm, -85 dBm] [-85 dBm, -100 dBm]
In the expected results is considered that no impact exist from the radio and transmission resources.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Table 35: Expected Application Throughput Expected DL Applic Throughput Expected UL Applic Throughput per PDCH interval (kbit/s) per PDCH interval (kbit/s) 40.0 - 53.5 35.7 - 43.6 28.2 - 38.0 28.9 - 40.0 26.5 - 38.1 14.9 22.8
ED NE
011 80/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Test preparation
The correct use of tools and test preparation is necessary to have a reliable analysis of the results. When a low DL throughput is observed, the tests should be repeated several times to give as much as possible statistical consistency of the results. A set of tools is proposed: o o o o o Deutrip: Generates application traffic automatically (FTP, WEB, Streaming, etc.) and records statistics (application throughput, access time, etc.) Ethereal: Protocol analysis (TCP/IP but also many others), developed by the Open-source community (GNU license) and works on top of a capture library (WinPcap, for Windows) Agilent E6474A (Nitro): Tool to collect and process air interface trace K12/K15: they are used to collect data from different interfaces, one important for PS analysis is the Gb. Compass: tool used mainly to post-process the data from Gb traces, two possible usages : global analysis of user traffic and deep analysis of traffic generated during tests.
The layer where these tools are used is explained by the figure below.
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
When performing the test, first it is important to eliminate possible impact of the radio conditions and network load (radio and transmission), a way to do it is to perform the test in good coverage cells, well dimensioned and in low traffic hours. Second, the FTP server configuration and location should be verified. With these previous constrains removed, the test is performed and the results can easily be analysed.
b) Main TCP parameters To go deeper in the TCP/IP analyses check the main TCP parameters (MTU, RWIN): o MTU recommended value is 1500 Bytes = MSS + 40 Bytes => MSS = 1460 Bytes. To check the used MSS see as example the figure below (note: MSS is only available in SYN, ACK/SYN messages):
ED NE
011 82/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
RWIN is recommended to be set to 64kBytes (64520 Bytes) Also this TCP parameter can be checked in the message layer.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
If the TCP parameters are not correct checked and if the limitation is in the drive test PC, you can use Dr.TCP (it is freeware tool that can be found in http://www.dslreports.com) to correct the TCP parameters. The setting should be similar to the ones presented in the figure below.
If the TCP parameters are not correct in the PC you can use the same tool to implement the right values. After, it is recommended to repeat the tests. c) FTP transfer - data flow
ED NE
011 83/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
The next step in the investigation is to analyse the overall data flow during FTP transfer. The process is to filter one of the bad FTP download transfer by using the function Follow TCP Stream. These enables 3 main functions which give graphic representation of the round trip time, TCP throughput and packet flow (data and ack). The importance of a graphic representation is to have a better global view of the data transfer and a fast identification of the bottlenecks and problems. The graphic time-sequence as the major information and existing problems can be split in two, the next examples are representative of the most reported issues: o BSS/Radio layers impact, for example due to bad radio conditions or cell-reselections.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
2-3 seconds hole, with TCP losses (radio drop and LLC-FLUSH due to reselection ?)
throughput is decreasing (MS going towards the edge of the cell, and MCS are decreasing ?)
ED NE
011 84/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
o
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
ED NE
011 85/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Block Error Rate, high BLER can be due to bad radio conditions or equipment problems. DL RLC throughput per TS, the value of this indicator is dependent of the previous indicators values and should be compared with the expected throughput per radio conditions presented in the previous chapter.
b) The upper layer investigation is performed by analysing traces from different points, mainly they are from TCP/IP trace at client side, Gb traces and TCP/IP at FTP server side. During a FTP DL, see in Ethereal on the client side that some TCP segments are lost, and retransmitted. This causes a big impact on the throughput. Most often the TCP segments are not lost by the BSS, but by some other elements above it (Frame relay of the Gb interface, SGSN, IP backbone, etc.).
The principle of the analysis is to take an Ethereal trace on the PC client side, simultaneously with a Gb trace (with K12/K15) and preference collect also Ethereal trace at FTP server side First identify the TCP segment lost at client side. Then try to see if they were already lost on Gb interface or not.
-> at client side, it should be seen something like this in DL : A - B - [previous segment lost] - D - E - F - G - H - I - J - K - C - L - M - N - O...
-> at Gb side, either you have: A - B - C - D - E - F - G - H - I - J - K - C - L - M - N - O... (segment not missing, so was lost after Gb) Or: A - B - D - E - F - G - H - I - J - K - C - L - M - N - O... (segment missing, so was lost before Gb).
TCP segments numbers have a unique identifier, which can be seen in both traces. Beware that in Ethereal, it should be set the option to see the absolute value, not the relative one: -> Menu Edit -> Preferences -> Protocols -> TCP -> Unselect "Relative sequence numbers and window scaling"
The steps of the analysis are: a) In Ethereal, click on any DL frame with FTP-DATA.
3DF 01900 0000 PTZZA DIAMS
b) Menu Statistics -> TCP Stream graph -> Time-sequence graph (tcptrace) c) Identify in the trace a TCP segment lost and retransmitted. Click hold CTRL and click a segment in the graph to go to the position in the trace.
ED NE
011 86/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
d) Identify the segment number of the retransmitted (lost) segment. (which was called "C" in the example earlier). e) Identify also the segment numbers "B" and "D"
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
NB: There should be: B = C - MSS, and D = C + MSS, with MSS=Max segment size, often 1380 or 1460. f) Open the Gb trace for example with K12 record viewer and look for the TCP segments number B, C, D. NB: in K12 record viewer, once the correct decoding stack is used, it should be possible to see the decoding of TCP layer, and the TCP segments number. Find the TCP segment number (be careful to choose a DL one, and to select the Segment number, not the ACK number). Then right mouse button click -> Add column. That way you get the TCP segment number as a new column in the synthetic view. g) check if there is : A - B - C - D - E - F - G - H - I - J - K - C - L - M - N - O... (segment not missing, so was lost after Gb) A - B - D - E - F - G - H - I - J - K - C - L - M - N - O... (segment missing, so was lost before Gb).
If the problem is before Gb, e.g. in the CN or IP network, forward the problem to the GSS team. If the problem is after Gb it can be associated with the LLC layer parameterization and configuration.
Check number of T1 reallocation GSM indicators, traffic load and congestion GPRS Radio resources allocation indicators, see sub-chapter 5.3 o Case: Gb Congestion noticed by NSE (UL congestion control), pre-emption of one PDCH per each T_UL_Congestion seconds until the end of the Gb congestion. o Solution: Check BVC parameters
Case: Lifetime parameter is changing during DL LLC PDU transfer in the Gb. Solution. With Ericsson SGSN Set PDU_Lifetime_Order to disable
o
3DF 01900 0000 PTZZA DIAMS
Case: Low throughput observed due to lack of transmission resources. Solution: Perform BSS architecture and dimensioning, see chapter 3.
b) GSS Network o
ED NE
Case: Wrong QoS parameters in the HLR and/or in the client side:
1 RELEASED 3DF XXXX XXXX PTZZA 011 87/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Solution: The QoS parameters are negotiated during the PDP context activation; they are defined by the minimum of the client or the network. Check in the PDP context negotiation L3 messages the QoS parameters: RLC: ack LLC: unack Mean Throughput: Best-effort Peak throughput: Up to 256 000 octets/s (2 048 kbit/s).
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
In the client side the QoS parameters can be tuning by the AT command: +CGDCONT=1,"IP","APN";+CGQREQ=1,3,4,3,0,0
c) IP Network o Case: Wrong TCP/IP parameters, client side and FTP side. Solution: Using Dr. TCP correct the parameters values MTU = MSS + 40 = 1460 + 40 = 1500 Bytes RWIN > RTT * Bandwidth, recommended RWIN = 64520 Bytes o Case: MTU bottleneck in IP network Solution: Find the largest non-fragment MTU in the network. Test the network by pinging the server: ping l MSS f target_name Find the largest possible non-fragmented packet to compensate the difference between ICMP and TCP headers, o o o add 28 Bytes (ICMP 8 Bytes & IP 20 Bytes headers) to the MSS to get the MTU the MSS for TCP/IP to be configured for FTP DL or UL is MTU 40 Bytes for headers (TCP 20 Bytes & IP 20 Bytes).
Case: FTP server misconfigured: Solution: Check buffer size Solution: TCP parameters Solution: Check the FTP server load, number of clients connected, etc.
ED NE
011 88/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
RLC Block
In case of RLC block is not well decoded from the MCS9 radio block, only this block will be retransmitted and using MCS6. In the next example, it is considered that RLC block 1 is not well decoded and so it will be retransmitted.
37 Bytes
37 Bytes
37 Bytes
37 Bytes
MCS9
RLC Block 2
37 Bytes
3DF 01900 0000 PTZZA DIAMS
37 Bytes
MCS6
RLC Block 1 - Retransmitted Radio Block Figure 610: RLC block not well decoded
ED NE 1 RELEASED 3DF XXXX XXXX PTZZA 011 89/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
To confirm the DL MCS fluctuation is due to radio conditions the BLER should be check.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
6.3 UL PERFORMANCE
As explained in sub-chapters 2.7 and 2.8, in B9 there was an improvement in the UL performance due to three new features: o o o Support of 8-PSK in uplink. Support of incremental redundancy and resegmentation. Extended UL TBF mode.
The feature support of 8-PSK in uplink is subject to optimisation as for DL, in terms of usage of highest MCS.
6.3.1 RESEGMENTATION VS IR
With the introduction of 8-PSK modulation in uplink, two sub-features were introduced the incremental redundancy and resegmentation, the first one is activated by the flag En_IR_UL and the second by the flag En_Resegmentation_UL. The default values for these parameters are: o o En_IR_UL = Disable En_Resegmentation_UL= Disable
Based in results from field trials, a NE recommendation is proposed: o o En_IR_UL = Enable En_Resegmentation_UL= Disable
This parameter set provides the best performances, whatever the radio conditions. The significant gain is observed in medium and bad radio conditions. In good radio conditions the performance impact of the parameter setting is neglected.
ED NE
011 90/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
The access time of a network is measured by the application service ping, a few parameter optimizations are possible to improve ping performance, however all the parameter proposals have impact in the transmission resources and there will be increase of load if applied: o For all pings: TBF_DL/UL_Init_MCS - Increase the initial MCS from MCS3 to MCS6. Better throughput in the first blocks and lower ping time. Ping test are to be performed in good radio condition, so no impact in the tests are expected due to radio conditions, for example retransmission due to a not well decoded RLC block. o Mainly for ping with small interval between iteration: o EN_EXTENDED_UL_TBF Enable the Extended UL TBF mode feature to maintain the UL TBF alive T_MAX_EXTENDED_UL The default is 2s, but can be increase if need for better ping performance.
Mainly for ping with medium and large interval between iteration: EN_FAST_INITIAL_GPRS_ACCESS The feature will guarantee transmission resources are keep established for the cell, along with the next parameter it will be possible to optimize the transmission for the cell having ping test. It consume transmission resource even without PS traffic in the cell N_GCH_FAST_PS_ACCESS The increase of the parameter value from 1 to 5 will guarantee enough resources in the cell for allowing good ping performances.
When an operator plans to implement EDGE several dimensioning decisions has to be done, such as the radio resources and transmission resources, these major decisions have higher impact in the EDGE performance than the frequency type. For example, 2 TBFs sharing the same PDCHs degraded 50% in the EDGE performance, 3 PDCHs allocated in DL instead of 4 PDCHs have 25% of impact. To conclude the design and the parameterization in a network have higher importance in the EDGE performance, than the frequency hopping and so this last one can be neglected, if it is not too aggressive.
GPRS_transmission_GCH_deficit_time - Cumulated time during which there is a deficit of GCH resources in the cell. GPRS_transmission_GCH_deficit_average - Average number of GCH resources in deficit in the cell.
1 RELEASED 3DF XXXX XXXX PTZZA 011 91/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
At Abis level: o o GPRS_transmission_deficit_extra_and_bonus_time - Cumulated time during which there are extra and bonus Abis nibbles in deficit in the BTS. GPRS_transmission_deficit_extra_and_bonus_average - Average number of extra and bonus Abis nibbles in deficit in the BTS.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
As remark the deficit given by the counter P470, used in the previous indicators, is a "relative" deficit because it depends on the configuration of two parameters R_AVERAGE_GPRS and R_AVERAGE_EGPRS. The counter P470 is in the restriction list with the FR 3BKA13FBR181686, the correction was done in MR4 Ed02 Patch 30CP_00E. In a critical situation the impact of the Abis congestion should be observed in the TBF establishment indicators: o For DL: o For UL: GPRS_UL_TBF_estab_fail_abis_cong - Number of UL establishment failures due to congestion of Abis. GPRS_DL_TBF_estab_fail_abis_cong - Number of DL establishment failures due to congestion of Abis.
Few parameters can be optimized to decrease congestion in the Abis, however they have end-user performance impact. For a permanent solution consider a new dimensioning study in the network. o T_GCH_Inactivity - Timer to postpone the release of the unused GCHs of a TRX after TBF release(s). Changeable by operator at BSS level - Min = 1s, Def = 3s, Max = 100s. Recommendation for congestion situation: Decrease the parameter value for 2s to save transmission resources.
T_GCH_Inactivity_Last - Timer to postpone the release of the last N_GCH_FAST_PS_ACCESS unused GCHs in a cell, when the last TBF has been released in the cell (launched after T_GCH_Inactivity). Changeable by operator at BSS level - Min = 1s, Def = 20s, Max = 200s. Recommendation for congestion situation: Decrease the parameter value for 8s to save transmission resources.
GPRS_GPU_Ater_cong_time - Time during which AterMux interface (GICs) for this GPU is congested (at least one PDCH group impacted). By congestion, in this case is defined as the time during which the number of used AterMux nibbles is greater than (available Atermux nibbles N_ATER_TS_MARGIN_GPU).
ED NE
011 92/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
GPRS_GPU_Ater_cong_percent - Percentage of time during which AterMux interface (GICs) for this GPU is congested (at least one PDCH group impacted).
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
o o
GPRS_transmission_GCH_deficit_ater_nibbles_time - Cumulated time during which there are Ater nibbles in deficit in the GPU. GPRS_transmission_GCH_deficit_ater_nibbles_average - Average number of Ater nibbles which are in deficit in the GPU.
At DSP level: o o o o GPRS_DSP_CPU_overload_time - Time during which at least a DSP is in CPU overload state. A DSP is said overloaded when its CPU load is > =DSP_LOAD_THR2. GPRS_DSP_CPU_overload_percent - Percentage of time during which a DSP is in CPU overload state. GPRS_GPU_DSP_cong_time - Time during which a DSP enters the congestion state. GPRS_GPU_DSP_cong_percent - Percentage of time during which a DSP enters the congestion state.
At transmission (Abis/Ater) level: o o GPRS_transmission_GCH_deficit_time - Cumulated time during which there is a deficit of GCH resources in the cell. GPRS_transmission_GCH_deficit_average - Average number of GCH resources in deficit in the cell.
In a critical situation the impact of the Ater/GPU(GP)/DSP congestion should be observed in the TBF establishment indicators: o For DL: o For UL: GPRS_UL_TBF_estab_fail_ater_cong - Number of DL establishment failures due to congestion of Ater(Mux). GPRS_UL_TBF_estab_fail_cpu_cong - Number of DL establishment failures due to CPU processing power limitations of the GPU. GPRS_UL_TBF_estab_fail_dsp_cong - Number of DL establishment failures due to congestion of DSP. GPRS_DL_TBF_estab_fail_ater_cong - Number of DL establishment failures due to congestion of Ater(Mux). GPRS_DL_TBF_estab_fail_cpu_cong - Number of DL establishment failures due to CPU processing power limitations of the GPU. GPRS_DL_TBF_estab_fail_dsp_cong - Number of DL establishment failures due to congestion of DSP.
If relevant congestion is found in the previous indicators a set of NE recommendation are proposed. In a first phase, e.g. the congestion is relevant but not critical a few parameter optimizations are proposed, otherwise a new dimensioning is needed.
3DF 01900 0000 PTZZA DIAMS
The Ater parameter optimizations recommended are: o N_ATER_TS_MARGIN_GPU - Number of free 64k Ater TSs that are kept in reserve in order to be able to serve some priority requests (first PS traffic) in the cells of the GPU.
ED NE 1
Changeable by operator at BSS level - Min = 0 TS, Def = 2 TS, Max = 10 TS.
RELEASED 3DF XXXX XXXX PTZZA 011 93/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
Parameter impact: Increasing the value of this parameter can increase the average number of unused Ater nibbles in the GPU (only first PS accesses will benefit from the margin, not the on-going TBF traffic). Remark: if the value is increased there will be more GPRS_GPU_Ater_Cong_Time, due to the definition of GPRS_GPU_Ater_Cong_Time. But on the other hand, a high value will increase the probability of not serving priority requests in the GPU (cases where several priority requests have to be served in a short period of time in different cells). Setting N_ATER_TS_MARGIN_GPU to 0 can lead to situations where priority requests cannot be served at all.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Recommendation for congestion situation: The parameter value should be kept at least equal to 2 TS
Ater_Usage_Threshold - Threshold (percentage of used Ater nibbles, in a GPU) above which the Ater usage is said high. Changeable by operator at BSS level - Min = 1%, Def = 70%, Max = 100%. Recommendation for congestion situation: Decrease the threshold for a more reactive algorithm in case of critical situations. Available atermux nibbles - (Available Atermux nibbles * Ater_Usage_Threshold) > N_ATER_TS_MARGIN_GPU in order to enter in "high load" condition before entering in congestion.
GCH_RED_FACTOR_HIGH_ATER_USAGE - Reduction factor of the number of GCHs targeted per PDCH, when the Ater usage is high. Changeable by operator at cell level - Min = 0.1, Def = 0.75, Max = 1. Parameter impact: A low value of GCH_RED_Factor_High_Ater_Usage can be coherent with a high value of Ater_Usage_Threshold (it will avoid reaching the saturation point of 100% of the Ater resources used at the same moment in the GPU). Reciprocally, a high value of GCH_RED_Factor_High_Ater_Usage can be coherent with a low value of Ater_Usage_Threshold (it will limit the risks of wasting, i.e. of not using, Ater resources in the GPU). Recommendation for congestion situation: In critical situations where the transmission resources are always congested, decrease the value to reduce the impact of congestion and save resources for new PS access.
The global transmission parameter optimizations are: o T_GCH_Inactivity - Timer to postpone the release of the unused GCHs of a TRX after TBF release(s). Changeable by operator at BSS level - Min = 1s, Def = 3s, Max = 100s. Parameter impact: The lower, the faster Ater nibbles are freed when unused (Ater congestion is reduced).
3DF 01900 0000 PTZZA DIAMS
ED NE
011 94/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
A too low timer value will increase GSL/CPU loads due to numerous GCH releases & reestablishments. It may also not anticipate traffic resumption on TRXs in an optimal way (only MSC2 usable at TBF resumption).
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
Recommendation for congestion situation: Decrease the parameter value for 2s to save transmission resources.
T_GCH_Inactivity_Last - Timer to postpone the release of the last N_GCH_FAST_PS_ACCESS unused GCHs in a cell, when the last TBF has been released in the cell (launched after T_GCH_Inactivity). Changeable by operator at BSS level - Min = 1s, Def = 20s, Max = 200s. Parameter impact: The lower the T_GCH_Inactivity_Last vaule will be, the faster Ater nibbles are freed when unused (Ater congestion is reduced). A too low timer value will however poorly anticipate traffic resumption on TRXs (higher average duration of TBF establishments) and increase GSL/CPU loads due to numerous GCH releases & reestablishments. Recommendation for congestion situation: Decrease the parameter value for 8s to save transmission resources.
Fast initial PS access feature. EN_FAST_INITIAL_GPRS_ACCESS: Changeable by operator at cell level Def = off. N_GCH_FAST_PS_ACCESS: Customizable at MFS level Min = Def = 1 GCH, Max = 5 GCHs. Parameter impact: No "fast initial PS access" avoids Ater resource consumption and wastes. But "fast initial PS access" guarantees PS traffic in all the cells in which it is activated (at radio & Abis/Ater levels).
a) Optimisation by the procedure Suspend/Resume: The procedure suspend/resume should be activated at BSS (it is activated in default) and at GSS level in order to avoid that mobiles trigger a RA update procedure at the end of each CS connections, in order to warn SGSN that they are re-available for PS services. With Suspend/Resume, this is done directly by the BSS at the end of each CS connections.
2 modes of Attach at GSS level are possible: - attach sent at "switch on" of the mobile - attach "on demand" when the user wants to activate a PDP context
ED NE
011 95/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
It is preferable to "force" the configuration of the mobiles towards the second mode in order to avoid all the GPRS attach procedure not useful as they are not followed by user traffic.
GPRS attach repetitions: A strong number of GPRS attach can be followed by GPRS attach reject because they are generated by users having GPRS mobiles but no GPRS subscription. The failure cause "GPRS service not allowed" sent by the GSS in the GPRS attach reject message should prevent from repeating GPRS attach attempts in such case.
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
c) Optimisation of the procedure RA update: The timer T3312 within SGSN manages the periodicity of the sending of RA update request. In order to avoid a too strong load coming from this procedure, it is preferable to increase the value of this timer. However, no value can be recommended as it can depend on the GSS vendor implementation. It has been seen in several networks that this values is set to 54 min, although this value can be increase up to 3 hours, reducing number of periodic RAU.
ED NE
011 96/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29
A TABLE OF FIGURES
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent.
3DF 01900 0000 PTZZA DIAMS
Figure 21: B8 release EGCH vs B9 release M-EGCH........................................................................................ 8 Figure 22: M-EGCH and L1-GCH layers location ............................................................................................ 9 Figure 23: GCH filling with RLC/MAC PDUs ................................................................................................... 9 Figure 24: Abis resources concept in B8 ...................................................................................................... 11 Figure 25: Abis resources concept in B9 ...................................................................................................... 11 Figure 26: Cyclic calculation of the usage of the cell resources ................................................................. 14 Figure 27: Cyclic calculation of the average usage of the cell resources .................................................... 15 Figure 28: General diagram of the Max_SPDCH_Limit calculation ............................................................... 15 Figure 29: Detailed diagram of the Max_SPDCH_Limit calculation .............................................................. 17 Figure 210: Max_SPDCH_Limit CS and PS zones .......................................................................................... 18 Figure 211: PS TS zones example 1 ........................................................................................................... 19 Figure 212: PS TS zones example 2 ........................................................................................................... 19 Figure 213: T1 reallocation ......................................................................................................................... 21 Figure 214: Handling of unused GCHs ......................................................................................................... 25 Figure 215: RAE4 diagram ........................................................................................................................... 27 Figure 216: T3 reallocation - initial MSs allocation. .................................................................................... 33 Figure 217: T3 reallocation - final MSs allocation for B9............................................................................. 33 Figure 218: T3 reallocation - defragmentation purpose. ............................................................................. 34 Figure 219: Coding scheme families. .......................................................................................................... 36 Figure 220: Trigger of the timer T_max_extended_UL. ............................................................................... 38 Figure 221: Schedule USF. ........................................................................................................................... 38 Figure 222: Expiry of the timer T_max_extended_UL. ................................................................................ 38 Figure 223: Restart the uplink TBF. ............................................................................................................. 39 Figure 224: NACC. ...................................................................................................................................... 40 Figure 225: NACC procedure in NC0 mode. ................................................................................................. 40 Figure 226: NACC procedure in NC2 mode. ................................................................................................. 41 Figure 227: Packet (P)SI status. .................................................................................................................. 42 Figure 228: Packet SI Status procedure. ..................................................................................................... 42 Figure 229: Packet PSI Status procedure. ................................................................................................... 43 Figure 230: PS used bandwidth. .................................................................................................................. 45 Figure 231: NC2 cell ranking process case 1. ............................................................................................ 45 Figure 232: NC2 cell ranking process case 2. ............................................................................................ 46 Figure 233: DL LLC PDU rerouting feature process. .................................................................................... 46 Figure 31: BSS Architecture in B9 release. .................................................................................................. 54 Figure 32: BSS Architecture in B9 release with Mx platform. ...................................................................... 54 Figure 33: Calculation of the Number of Extra Abis TS. .............................................................................. 56 Figure 34: Calculation of the needed GCHs in the Atermux interface. ........................................................ 57 Figure 35: Calculation of the Required_GCH_Traffic by Method 1. ............................................................. 58 Figure 36: Measured GCH traffic vs Measured PDCH traffic. ....................................................................... 58 Figure 37: Calculation of the Required_GCH_Traffic by Method 2. ............................................................. 59 Figure 38: Increase factor........................................................................................................................... 60 Figure 39: Transition type ........................................................................................................................... 60 Figure 310: Method 2 increase_factor ...................................................................................................... 61 Figure 61: Network Architecture. ............................................................................................................... 81 Figure 62: Ethereal example - MSS. ............................................................................................................ 82 Figure 63: Ethereal example - RWIN. .......................................................................................................... 83 Figure 64: Dr. TCP example TCP parameters ............................................................................................ 83 Figure 65: Ethereal example Time/Sequence graphic 1 ............................................................................ 84 Figure 66: Ethereal example Time/Sequence graphic 2 ............................................................................ 84 Figure 67: Ethereal example Time/Sequence graphic 3 ............................................................................ 85 Figure 68: Ethereal example Time/Sequence graphic 4 ............................................................................ 85 Figure 69: Radio Block structure ................................................................................................................. 89 Figure 610: RLC block not well decoded ..................................................................................................... 89
END OF DOCUMENT
ED NE
011 97/96
B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29