Академический Документы
Профессиональный Документы
Культура Документы
Originator
B9 EDGE Optimisation Guide
use and communication of its contents not permitted without
All rights reserved. Passing on and copying of this document,
Pedro Henriques
written authorization from Alcatel-Lucent.
PREDISTRIBUTION
ABSTRACT
This document presents the EDGE optimisation methodologies, for B9 release.
KEYWORDS
GSM, EDGE, EGPRS, B9, Optimisation
Approvals
NE J. ANDRES NE/GSM F. Colin
Date: Signature: Date: Signature:
ED 1 RELEASED 011
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.6 TBF RESOURCE ALLOCATION/REALLOCATION ...................................................................................... 25
2.6.1 TBF RESOURCE ESTABLISHMENT PROCESS............................................................................................................. 25
2.6.2 RADIO RESOURCE ALLOCATION PRINCIPLES........................................................................................................... 26
2.6.3 TRANSMISSION RESOURCE AVAILABILITY STEP ....................................................................................................... 28
2.6.4 TRX LIST COMPUTING .......................................................................................................................................... 28
2.6.5 BEST CANDIDATE ALLOCATION COMPUTATION ....................................................................................................... 28
2.6.6 PDCH CAPACITY ALLOCATION ............................................................................................................................... 31
2.6.7 TBF REALLOCATION CASES ................................................................................................................................... 32
2.7 ENHANCED SUPPORT OF EGPRS IN UL................................................................................................. 34
2.7.1 SUPPORT OF 8-PSK IN UPLINK .............................................................................................................................. 35
2.7.2 SUPPORT OF INCREMENTAL REDUNDANCY AND RESEGMENTATION IN UPLINK.......................................................... 36
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
3 NETWORK DIMENSIONING........................................................................................54
3.1 ABIS ..................................................................................................................................................55
written authorization from Alcatel-Lucent.
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.2 RLC STATISTICS..................................................................................................................................71
5.2.1 (M)CS DISTRIBUTION ............................................................................................................................................71
5.2.2 LLC/RLC TRAFFIC AND RETRANSMISSION...............................................................................................................74
5.3 RADIO RESOURCES .............................................................................................................................76
5.4 TRANSMISSION RESOURCES.................................................................................................................77
5.5 RNO REPORTS....................................................................................................................................77
5.6 END-USER STATISTICS.........................................................................................................................79
ED 1 RELEASED 011
SCOPE
AREA OF APPLICATION
This template should be used within NE and RSC for all ALCATEL-LUCENT, it is an internal document.
ED 1 RELEASED 011
This document is a guideline for EDGE optimization for B9 MR1. It does not include the B9MR4 software
All rights reserved. Passing on and copying of this document,
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.
written authorization from Alcatel-Lucent.
ED 1 RELEASED 011
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 Type 1 ARQ – the decoding of a re-transmitted RLC block does not take into account the previously
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
The RLC Window management also changes in EDGE. While in GPRS the RLC window size is fixed at 64
blocks, in EDGE:
o It is variable and determined for each TBF depending on the MS multi-slot class;
o It varies between 64 and 1024 blocks (512 blocks in Alcatel-Lucent implementation);
o It is increased following an increase on the number of PDCH’s, but not decreased in the case of a
reduction.
Table 4: Power characteristics from the different available TRA (EDGE capable TRE’s).
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 60 W / 47.8 dBm 25 W / 44 dBm 30 W / 44.8 dBm
1800 Medium power 35 W / 45.4 dBm 12 W / 40.8 dBm 30 W / 44.8 dBm
1800 High power 60 W / 47.8 dBm 25 W / 44 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:
“Furthermore, 8-PSK modulated timeslots on the BCCH carrier may use a mean power which is at most 4 dB
3DF 01900 0000 PTZZA – DIAMS
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 1 RELEASED 011
EGCH
EGCH
EGCH
EGCH
EGCH
EGCH
EGCH
M-EGCH link
composed of
composed of
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
GCH
1 to 5 GCHs depending
on the TRX class 1 to 36 GCHs
ED 1 RELEASED 011
The way the RLC/MAC PDU are filling an M-EGCH link is explained by the next figure.
MEGCH header
MEGCH 320 bits 320 bits 320 bits 320 bits (/NHP and addr
layer byte)
framing Dummy Filling
Dummy
sub-layer Filling PDU
320 bits
GCH2
GCH3
Dummy
GCH4 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 1 RELEASED 011
The dynamic transportation of the RLC/MAC PDU brings a more efficient resource usage also due to:
o Instantaneous reaction to radio variations (MCS variations).
o The resources not used by delayed DL TBFs, extended UL TBFs, … are used by other TBFs.
ED 1 RELEASED 011
In this B8 release example, 50% of the Abis resources are wasted, in B9 all the Abis nibbles can be used, as
explained after.
To have a better view of the B9 dynamic Abis concept, see the follow example applied in B9:
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
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.
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
3DF 01900 0000 PTZZA – DIAMS
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 1 RELEASED 011
o GCH_RED_FACTOR_HIGH_ATER_USAGE = 0,5
2) Ater usage = “normal”
written authorization from Alcatel-Lucent.
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 CS-2 CS-4 CS-4+MCS-9
(DRFU) (G3 or M4M) (G4 or M5M)
Enabled < 500 ms Disabled Disabled Enabled
Enabled ≥ 500 ms Disabled Disabled Disabled
Disabled - Disabled 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 1 RELEASED 011
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 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.
o 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.
NB_USED_CS_TS(k)
TCH_INFO_PERIOD = 5s NB_USED_PS_TS(k)
NB_USED_TS(k)
NB_UNUSED_TS(k)
The TCH usage samples calculate by the BSC every TCH_INFO_PERIOD are map in the internal parameters:
o NB_USED_CS_TS(k) - SPDCH State is deallocated
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
o AV_USED_PS_TS(k)
o AV_UNUSED_TS(k)
k- k- k k+ k+
TCH_INFO_PERIOD = 5s
NB_USED_CS_TS(k)
NB_USED_PS_TS(k)
NB_USED_TS(k)
NB_UNUSED_TS(k) RR_ALLOC_PERIOD * TCH_INFO_PERIOD
AV_USED_CS_TS(k) AV_USED_CS_TS(k+2)
LOAD_EV_PERIOD_GPRS = 3
AV_USED_PS_TS(k) AV_USED_PS_TS(k+2)
AV_UNUSED_TS(k) AV_UNUSED_TS(k+2)
Figure 2–7: 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:
MAX_PDCH_HIGH_LOAD
MAX_PDCH AV_USED_CS_TS
MIN_PDCH O&M parameters AV_USED_PS_TS
NB_TS_DEFINED AV_UNUSED_TS
NB_TS_MPDCH
NB_TS_SPDCH
MIN_SPDCH
MAX_SPDCH
Computation of Computation of
NB_TS Thresholds MAX_SPDCH_HIGH_LOAD MAX_SPDCH_LIMIT MAX_SPDCH_LIMIT
MARGIN_PRIORITY_CS
Computation of CS/PS MARGIN_PRIORITY_PS
Margin
ED 1 RELEASED 011
In case there isn’t master channel (NB_TS_MPDCH=0) and there is no TRX failure
(AVAILABILITY_TS_RATIO=100%) then there is simply:
o MAX_SPDCH_HIGH_LOAD = MAX_PDCH_HIGH_LOAD
o MIN_SPDCH = MIN_PDCH
o MAX_SPDCH= MAX_PDCH
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 1 RELEASED 011
MAX_SPDCH_LIMIT_CS(k)
Computation of MAX_SPDCH_LIMIT(k)
MAX_SPDCH_LIMIT
MAX_SPDCH_LIMIT_PS(k)
Computation of
AV_USED_PS_TS(k) MAX_SPDCH_LIMIT_PS
MIN_SPDCH
MARGIN_PRIORITY_PS
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 MAX_SPDCH_LIMIT_PS(k) = MIN_SPDCH(k)
else
o MAX_SPDCH_LIMIT_PS(k) = RoundUp (AV_USED_PS_TS(k) + MARGIN_PRIORITY_PS(k))
ED 1 RELEASED 011
Zone where
MAX_SPDCH_LIMIT = MIN( MAX_SPDCH,
Zone where
MIN_SPDCH MAX_SPDCH_LIMIT = MIN
(MAX_SPDCH_LIMIT_PS,
MAX_SPDCH_HIGH_LOAD)
MAX_SPDCH_LIMIT_PS
0
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 The SPDCHs_Confirmation bitmap is used to update the SPDCH allocation state of each timeslot.
o 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 PS_PREF_BCCH_TRX
o HW TRE capability (G4 HP -> G4 MP -> G3)
o DR TRE capability (FR TRX -> DR TRX)
o E-GSM TRX preference (new in B9, E-GSM TRX -> P-GSM/GSM850/DCS TRX)
o TRX having the maximum number of consecutive SPDCHs
o 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 1 RELEASED 011
o 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
o 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
o PS traffic zone: this zone corresponds to the larger zone between the non pre-emptable PS zone
and the MAX_SPDCH_LIMIT zone
PS traffic zone
MAX_SPDCH_LIMIT zone
PS PS CS PS PS CS PS PS CS CS CS
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
TRX2 TRX1
MAX_SPDCH_HIGH_LOAD zone
This feature should be enhanced, so that the number of allocated PDCH corresponds to MAX_SPDCH_LIMIT
MAX_SPDCH_LIMIT zone
PS PS CS CS PS CS CS CS CS CS CS
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
3DF 01900 0000 PTZZA – DIAMS
TRX2 TRX1
MAX_SPDCH_HIGH_LOAD zone
ED 1 RELEASED 011
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
3DF 01900 0000 PTZZA – DIAMS
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 1 RELEASED 011
4. The CS pre-emption process shall be completed before the TCH_INFO_PERIOD expiry, in order to
use and communication of its contents not permitted without
All rights reserved. Passing on and copying of this document,
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
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).
o 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
DL T1 candidate
UL
0 1 2 3 4 5 6 7
TRX 4 GCHs
The TBFs impacted by the CS preemption are managed by the soft preemption process, the impacted best-
effort TBFs are:
o The best-effort TBFs having their PACCH impacted, i.e. their PACCH is supported by a preempted
3DF 01900 0000 PTZZA – DIAMS
RTS (that case is valid for both Evolium and DRFU BTSs),
o 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 1 RELEASED 011
2.5.1 DEFINITIONS
The following concepts are used in the M-EGCH link management:
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) CS-1/4
G4 (TRE in an Evolium BTS) CS-1/4 + MCS-1/9
o TRX is said “established” if there is an M-EGCH link associated to this TRX with GCHs.
o 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.
o 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 aren’t enough free Abis nibbles, or free Ater nibbles, then GCH preemption will be used:
o The inter-cell GCH preemptions for PS traffic (the “source TRX” and the “target TRX” belong to two
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
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.
ED 1 RELEASED 011
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).
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
Established_Nb_GCH = 10
GCH10 B > HL
3 “unused” GCHs
written authorization from Alcatel-Lucent.
GCH9 B > HL
GCH8 B > HL
Target_Nb_GCH = 7
GCH7 B > HL Established_Nb_GCH = 7 “B > HL”: GCH uses a basic Abis
nibble mapped on a RTS out of the
GCH6 B > HL “non preemptable PS zone” of the
cell.
GCH5 Extra
“Extra”: GCH uses an extra Abis
7 “used” GCHs nibble or a “bonus” basic Abis nibble.
GCH4 Extra
“B ≤ HL”: GCH uses a basic Abis
GCH3 B ≤ HL nibble mapped on a RTS within the
“non preemptable PS zone” of the
GCH2 B ≤ HL cell.
GCH1 B ≤ HL
2. TBF Establishment: if the RR allocation is performed then the TBF establishment is possible according
to the following conditions:
o TBF allocation policy:
3DF 01900 0000 PTZZA – DIAMS
• 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 1 RELEASED 011
Nb_GCH_For_TBF_Estab is the minimum number of GCHs which are required on the TRX (M-EGCH) to serve
the request.
The Radio Resource Allocation Algorithm is used to find the radio and transmission resources in the Evolium
BTS case for (E)GPRS best-effort TBF establishment and in the case of TBF reallocation.
The Radio Resource Allocation Algorithm aims to:
ED 1 RELEASED 011
• Bias
• Traffic type
written authorization from Alcatel-Lucent.
MS class,
TRX list sorted Bias,
Transmission by BSC TRX list Number of radio Traffic type
Resource DSP congestion computing TSs determination
Availability (1) state (2) (3)
Cell Transmission
Equity (5)
Available_Nb_GCH_With_Equity
Test if enough
GCHs (6)
TFI/TAI/USF
allocation (7)
Transmission resource
- rejected request
reservation (8) - or L4 queuing
- or L5/L6 queuing
- or L7 queuing (11)
- or try to change TBF mode EGPRS case (12)
ED 1 RELEASED 011
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 1 RELEASED 011
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.
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.
o 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
o The PDCH shall not be in the “Full” state in the considered direction
ED 1 RELEASED 011
Where:
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
o 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 (n≥1) is computed as follows, for
each direction (XL corresponds to either UL or DL):
n
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
valid candidate timeslot allocations are sorted according to the following list of ordered criteria (from the
highest priority to the lowest). This list of criteria is valid in all cases: for GPRS or EGPRS service (contrary
to the B8 release case where two lists were used), and in a cell belonging to an Evolium BTS or to a DRFU
BTS:
ED 1 RELEASED 011
have the lowest number of PDCHs in the “EGPRS” state are preferred.
o [B]: the candidate timeslot allocations, which have the highest available throughput in the
direction of the bias are preferred.
written authorization from Alcatel-Lucent.
o [C]: the candidate timeslot allocations, which have the highest available throughput in the
direction opposite to the bias are preferred.
o [D]: the candidate timeslot allocations, which are on the TRX with the highest priority, are
preferred.
o [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.
o [F]: combinations with the PDCHs that have the lowest index are preferred.
Remarks:
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)
o 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.
ED 1 RELEASED 011
ED 1 RELEASED 011
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
written authorization from Alcatel-Lucent.
timer expiry.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
DL MSa MSa MSa MSa MSb MSb MSb MSb 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:
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
to use the MCS-5 to MCS-9 coding schemes in the BSS (in B8 only the MCS-1 to MCS-4 are
supported in UL).
o Support of Incremental Redundancy and resegmentation in Uplink
ED 1 RELEASED 011
The feature introduces 8-PSK modulation supported in UL, for more details see [2] The 8-PSK is a
modulation technique that compare to GMSK allows up to 3 times more data to be transmitted over the
GSM air interface. The 8-PSK modulation supports MCS-5 to MCS-9 coding schemes, which permit to achieve
higher throughput when the radio conditions are good enough.
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.
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.
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
3DF 01900 0000 PTZZA – DIAMS
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 1 RELEASED 011
GMSK 8PSK
MCS1 MCS2 MCS3 MCS4 MCS5 MCS6 MCS7 MCS8 MCS9
Family
C
22 22 22
Family 28 28 28 28 28
B
28 28
37 37 37 37 37
Family
A
37 37
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
The aim of this feature is to extend the duration of the UL TBF in order to quickly restart data transmission
in UL if higher layers in the MS deliver new data, without having to re-establish a new UL TBF, after the
countdown procedure has started. E.g. to maintain the UL TBF established, some time after the last block
(CV=0) has been acknowledged by the network. During inactivity period the BSS should keep the USF
scheduling and the reception of uplink RLC data block as long as the uplink TBF is in extended phase.
This feature allows improving access time to the GPRS network. It also improves the throughput in cases
where the traffic is discontinuous. The extended UL TBF mode (EUTM) is supported by mobiles which are
indicating support of 3GPP “GERAN Feature Package 1”. The GERAN Package 1 is mandatory for Rel-4 MS
and optional for Rel-99 MS (so, there can be also MS Rel-99 that supports EUTM), for more details see [2].
The BSS shall indicate to the MS that the network supports the extended uplink TBF mode. The MS is aware
of the BSS capability by the NW_EXT_UTBF parameter that is broadcast on either BCCH (SI13)or PBCCH
(PSI1). So the MS is always aware of the BSS capability before establishing an Uplink TBF. On the contrary
the BSS does not always know the MS radio access capability when the first Uplink TBF is established at the
beginning of a session. The detection whether or not a given MS supports the Extended Uplink TBF Mode is
received at downlink TBF establishment in the first downlink PDU. In case of cell reselection for an uplink
transfer and if the MS radio access capability stays unknown the “Radio Access Capability Update”
procedure is used to obtain the information.
If the MS does not support the Extended Uplink TBF Mode or if the BSS does not know MS capability, the
network will apply the Normal release mode (with delayed final PUAN).
During an UL transfer in a MS having MS context without the support of the Extended Uplink TBF Mode, if a
Radio Access Capability update message is received allowing the Extended Uplink TBF Mode, then the MS
context is overwrite and update.
The Extended uplink TBF mode is activated through an O&M parameter, EN_EXTENDED_UL_TBF and an
inactivity period duration of extended uplink TBF mode is configured T_MAX_EXTENDED_UL by the
parameter.
The release of the uplink TBF is trigger upon the expiry of the timer T_max_extended_UL.
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 MS’s 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
3DF 01900 0000 PTZZA – DIAMS
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 1 RELEASED 011
RLC block,
BSN=n, CV=
0
=n+1, FAI= 0 Enter TBF extended phase.
PUAN, SSN
Start T_max_extended_UL
MS BSS
USF
RLC block,
BSN=n, CV=
0
n+1, FAI=0 Start T_max_extended_UL
PUAN, SSN=
USF
Dummy bloc
k
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 BSS
USF
Dummy bloc T_max_extended
k _UL expiry
1, S/P=1
PUAN, FAI=
PCA
3DF 01900 0000 PTZZA – DIAMS
TBF is release
Nominal case
ED 1 RELEASED 011
MS BSS
written authorization from Alcatel-Lucent.
USF
T_max_extended
Radio block, _UL expiry
BSN=n+1
TBF is active again
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 One MS in extended mode on PACCH: USF scheduled every 20ms
o Two MS in extended mode on PACCH: USF scheduled every 40ms
o 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].
o 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.
ED 1 RELEASED 011
MS Cell A Cell B
T3208n
(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
3DF 01900 0000 PTZZA – DIAMS
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 .
ED 1 RELEASED 011
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).
written authorization from Alcatel-Lucent.
(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.
In case both a UL and a DL TBF exist, PNCDs are sent on the DL TBF.
ED 1 RELEASED 011
C
Ceelll AA CCeellll B
B
Partial Remainin
Sys g
Info. Sys Info.
Packet SI Status
The scenario of the Packet SI Status procedure is described in the next figure:
MS Cell A Cell B
RLC data block (1)
ED 1 RELEASED 011
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
written authorization from Alcatel-Lucent.
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 Cell B
RLC data block (1)
T_PSCD_SCHEDULE_
Packet serving cell data (PSI3 message)
ACK (3)
Packet serving cell data (PSI3bis message) - first instance
(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.
(2) The MS asks the BSS to provide the missing system information by sending a PACKET PSI STATUS message
3DF 01900 0000 PTZZA – DIAMS
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 1 RELEASED 011
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.
∑ (B )
N_PDCH_ALL OCATED
BUL = UL , i
i=1
L
T
B
F
,
i
=
L
,
i
L
T
B
F
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).
Next, it is a example of the Cell load evaluation. It is assumed, he following repartition of the DL TBFs is
used:
o The UL_PS_Used_Bandwidth is lower than the DL_PS_Used_Bandwidth. Thus, it is not computed.
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
2 DL TBF3 CS
1 DL TBF1 DL TBF2
written authorization from Alcatel-Lucent.
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 If the NC2 load average is lower than or equal to the threshold, the cell is considered in a low load
situation.
o 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 priority
PRIORITY_CLASS
3DF 01900 0000 PTZZA – DIAMS
C32NC2
low
ED 1 RELEASED 011
C31NC2
C2NC2
low
(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.
3DF 01900 0000 PTZZA – DIAMS
(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.
ED 1 RELEASED 011
If the flag EN_DL_LLC_PDU_Rerouting is set to enable the MFS behaviour follows the conditions of the next
table:
If the DL LLC PDU rerouting feature is disabled the DL LLC PDU in the old cell will be deleted.
PDCH.
Maximum number of UpLink
MAX_UL_TBF_SPDCH (E)GPRS connections per slave Cell Number 1 to 6 5
PDCH.
ED 1 RELEASED 011
ED 1 RELEASED 011
ED 1 RELEASED 011
hopping TRX.
ED 1 RELEASED 011
ED 1 RELEASED 011
ED 1 RELEASED 011
1 to
All rights reserved. Passing on and copying of this document,
ED 1 RELEASED 011
MT120
GPU board Gb
DSP DSP DSP DSP
TC
MT120
VTCU SMU TRCU TRCU TRCU
A speech
MT120
Air SMU TRCU TRCU TRCU
A-bis MxBSC
CS TRX 1
TCH
TCH CS
traffic
TRX 2 M-EGCH link 1 GCH Basic
CCP
board
CCP
board
CS
GCH Basic
PS M-EGCH link 2 Dynamic
traffic
TRX 3
Abis
GCH Bonus
GCH Extra
SSW TP A-ter mux
allocation board board
TRX n M-EGCH link n GCH Extra
LIU LIU
BTS board board CS+ PS MxMFS
Up to 24 TRXs GP board
data
per BTS with
Twin Modules PS DSP DSP DSP DSP
GP board Gb
DSP DSP DSP DSP
Capacity
1 GP = 4xGPU
(B9 MR4)
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:
3DF 01900 0000 PTZZA – DIAMS
o Abis
o Ater
o GPU/GP
ED 1 RELEASED 011
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
written authorization from Alcatel-Lucent.
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 2 users with Class 10 MS simultaneous in a BTS
o DL data transfer in MCS9
BTS configuration:
o 3 cells with 2 TRX and 1 SDCCH per cell.
o No limitations of radio resources allocation (Max_SPDCH_Limit)
The number of required extra Abis TS is given by the number of GCHs in deficit:
o 22 GCH in deficit (16 kbit/s Abis nibbles) / 4 Abis nibles per Abis TS = 5.5 Extra Abis TS
o As a conclusion: The N_EXTRA_ABIS_TS should be set to 6 to fulfil the requirement
3DF 01900 0000 PTZZA – DIAMS
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 1 RELEASED 011
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:
With:
ED 1 RELEASED 011
o
All rights reserved. Passing on and copying of this document,
P105i
o % DL _ TBF _ Abis _ Cong = × 100%
P91a + P91b + P91c + P91d + P91e + P91 f
written authorization from Alcatel-Lucent.
P105 j
o %UL _ TBF _ Abis _ Cong = × 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 Method 1: driven by the estimation of the required traffic as a function of the measured GCH traffic
and of Ater/GPU congestion
o 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.
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
Where:
o Measured_GCH_Traffic = P100c / 3600
o Congestion = Max(Ater_or_GPU_limitation, 30%)=Max(Max(P383a,P384,P202,P201,P402) / 3600; 30%)
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 1 RELEASED 011
ED 1 RELEASED 011
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
b d
c e
EDGE
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
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
o %_PDCH_EGPRS: % of Radio Resources (PDCH) supporting at least one TBF established in EGPRS
mode on a cell with MAX_EGPRS = MCSx
written authorization from Alcatel-Lucent.
o %_ PDCH_GPRS: % of Radio Resources (PDCH) supporting only TBF established in GPRS mode on a
cell with MAX_GPRS = CSy
o Nb_GCH_per_PDCH_MCSx: given by table 6
o Nb_GCH_per_PDCH_CSy: given by table 5
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 Re quired_GCH_traffic final = Re quired_GCH_trafficcurrent × Increase_factor
For method 2 the impact of the increase factor is applied in the slope, as explained in the next graphic:
Where
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
The GPU_GCH_Capacity is the number of GCH that a GPU/GP can handle. It is given by the minimum of
three variables:
Max_DL_GCH_GPU =
• (%CS1 × max_PDCH_CS1 × max_DL_GCH_CS1) + ...
+ (%MCS1 × max_PDCH_MCS1 × max_DL_GCH_MCS1) + ...
Max_UL_GCH_GPU =
• (%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:
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
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
written authorization from Alcatel-Lucent.
The number of GPU/GP needed is then given by dividing the needed GCH per the GPU_GCH_Capacity.
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
Three different main phases exist for the PS dimensioning and optimisation:
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
3DF 01900 0000 PTZZA – DIAMS
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 1 RELEASED 011
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
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
For DL:
Table 20: DL TBF Establishment
RNO indicator Description Unit Comments
Rate of DL TBF establishment -successes (seized
GPRS_DL_TBF_success_rate %
by the mobile)
The absolute number
of requests is
GPRS_DL_TBF_request Number of DL TBF establishment -requests. nb
important to validate
the statistics
This indicator measure
GPRS_DL_TBF_estab_allocated_rate Rate of DL TBF allocated per cell. % the impact of the
congestion
Rate of DL TBF estab - failures due to BSS problem
GPRS_DL_TBF_estab_fail_BSS_rate 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
Split of failures during
Rate of DL TBF estab -failures due to radio
DL TBF establishment
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 nb
congestion of Abis.
Number of DL establishment failures due to
GPRS_DL_TBF_estab_fail_ater_cong nb Split of the congestion
congestion of Ater(Mux).
failures, this
Number of DL establishment failures due to CPU
GPRS_DL_TBF_estab_fail_cpu_cong nb information is
processing power limitations of the GPU.
important for BSS
Number of DL establishment failures due to dimensioning
GPRS_DL_TBF_estab_fail_dsp_cong nb
3DF 01900 0000 PTZZA – DIAMS
congestion of DSP.
Number of DL TBF establishment failure due to
GPRS_DL_TBF_estab_fail_radio_cong nb
radio congestion per cell.
ED 1 RELEASED 011
GPRS_UL_TBF_success_rate %
Reference: number of UL TBF estab -requests
The absolute number of
Number of UL TBF establishment -requests per
GPRS_UL_TBF_request nb requests is important to
written authorization from Alcatel-Lucent.
cell.
validate the statistics
This indicator measure the
GPRS_UL_TBF_estab_allocated_rate Rate of UL TBF allocated per cell. %
impact of the congestion
Rate of UL TBF estab -failures due to BSS
GPRS_UL_TBF_estab_fail_BSS_rate 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
Split of failures during UL
Rate of UL TBF estab -failures due to radio
TBF establishment
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 nb
congestion of Abis.
Number of UL establishment failures due to
GPRS_UL_TBF_estab_fail_ater_cong nb
congestion of Ater(Mux). Split of the congestion
Number of UL establishment failures due to failures, this information is
GPRS_UL_TBF_estab_fail_cpu_cong nb
CPU processing power limitations of the GPU.. important for BSS
Number of UL establishment failures due to dimensioning
GPRS_UL_TBF_estab_fail_dsp_cong nb
congestion of DSP.
Number of UL TBF establishment failure due to
GPRS_UL_TBF_estab_fail_radio_cong nb
radio congestion per cell.
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 Failures due to Gb – this might indicate problems at Gb link side (no BVC available, which would
affect the cell – this implies that the cell’s operational state is “disabled”);
o 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);
o 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.
o Failures due to radio – might indicate radio problems (e.g. bad frequency plan, bad coverage
planning)
These indicators evaluate the release of a TBF, they reflect possible failures during data transfer and TBF
releases due to reselection for moving MS.
ED 1 RELEASED 011
ED 1 RELEASED 011
For UL:
Table 23: UL TBF Data Transfer
RNO indicator Description Unit Comments
Rate of UL TBF
not impacted by
Rate of UL TBF normal releases.
failures or
GPRS_UL_TBF_normal_release_rate Reference: number of UL TBF %
reselection
establishment - successes
during data
transfer
Rate of UL TBF releases due to: Rate of UL TBF
- TBF release due to radio preemption impacted during
- TBF release due to suspend resume data transfer due
GPRS_UL_TBF_acceptable_release_rate %
procedure to features to
- TBF release due to cell reselection. favour CS or cell
Reference : number of UL TBF success. reselection.
Rate of UL TBF drops.
GPRS_UL_TBF_drop_rate Reference: number of UL TBF %
establishment - successes
GPRS_UL_TBF_normal_release Number of UL TBF normal releases. nb
Number of UL TBF releases due to :
- UL TBF release due to radio preemption
GPRS_UL_TBF_acceptable_release - UL TBF release due to suspend resume nb
procedure
- UL TBF release due to cell reselection
GPRS_UL_TBF_drop Number of UL TBF drop. nb
Rate of UL TBF releases due to fast
preemption in case of need of radio
GPRS_UL_TBF_radio_preemption_release_rate resources. %
Reference: number of UL TBF
establishment successes.
Rate of suspend messages for an UL TBF
received from MS (via BSC).
GPRS_UL_TBF_release_suspend_rate %
Reference: number of UL TBF Split of
establishment successes. acceptable
Rate of UL TBF releases due to NC2 cell release causes
reselection
GPRS_UL_TBF_release_NC2_reselect_rate %
Reference: number of UL TBF
establishment successes
Rate of UL TBF releases due to NC0 cell
reselection
GPRS_UL_TBF_release_NC0_reselect_rate %
Reference: number of UL TBF
establishment successes
Rate of UL TBF drops due to BSS problems.
Split of TBF drop
GPRS_UL_TBF_drop_BSS_rate Reference: number of UL TBF %
causes
establishment - successes
Rate of UL TBF drops due to GB interface
problems.
GPRS_UL_TBF_drop_GB_rate %
Reference: number of UL TBF
establishment - successes
Rate of UL TBF drops due to blocking
situation at the beginning or at the end of
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
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 TBF’s are being abnormally released. The
following causes are possible:
o RLC blocks are being lost during the GPRS connection
o RLC blocks are being retransmitted too many times – check the TBF Retransmission Ratio KPI;
o Connection drop is high – this might be due to 3 other sub-causes:
• System drop – indicating a system problem. Verify other KPI (GSM included);
• Gb drop – indicating problem on Gb interface;
o 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).
ED 1 RELEASED 011
requests is important to
Number of UL TBF candidate for resource
GPRS_UL_TBF_realloc_T3_request nb validate the statistics
reallocation (trigger T3).
Number of UL TBF candidate for resource
GPRS_UL_TBF_realloc_T4_request nb
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 High frequency of occurrence of T1 might indicate that the cell is sub-dimensioned to
accommodate all CS and PS traffic;
o 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.
ED 1 RELEASED 011
For UL:
ED 1 RELEASED 011
ED 1 RELEASED 011
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.
The split of LCC traffic by the Radio Access Capabilities are in the next 2 tables.
For DL:
Table 28: DL LLC traffic
RNO indicator Description Unit
Number of DL LLC bytes transmitted and acknowledge
GPRS_DL_LLC_bytes_EGPRS_ack_mode on established DL TBF in EGPRS mode and RLC nb
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 nb
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 nb
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 nb
unacknowledged mode
For UL:
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
mode
Number of UL LLC bytes received on UL TBFs
GPRS_UL_LLC_bytes_EGPRS_unack_mode established in EGPRS mode and RLC unackowledged nb
written authorization from Alcatel-Lucent.
mode
Number of UL LLC bytes received on UL TBFs
GPRS_UL_LLC_bytes_GPRS_ack_mode nb
established in GPRS mode and RLC ack mode
Number of UL LLC bytes received on UL TBFs
GPRS_UL_LLC_bytes_GPRS_unack_mode established in GPRS mode and RLC unackowledged nb
mode
For UL:
Table 31: UL RLC traffic
RNO indicator Description Unit Comments
Number of useful RLC bytes sent on
GPRS_UL_useful_bytes_CSx_ack nb
PDTCH in GPRS and RLC ack modes
Number of useful RLC bytes sent on
GPRS_UL_useful_bytes_MCSx_ack nb
PDTCH in EGPRS and RLC ack modes
In RLC ack mode, ratio of uplink RLC This indicator is an
bytes retransmitted on PDTCH and overall indication,
encoded in CS-x. however some CS
GPRS_UL_RLC_bytes_CSx_retransmissing_ack_ratio %
Reference : total number of UL RLC may be more
data bytes sent on PDTCH in RLC ack retransmitted than
mode others.
In acknowledged mode, ratio of UL
RLC data bytes encoded in MCS-x and This indicator is an
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
GPRS_PDCH_per_UL_TBF_avg account). nb
An active PDCH with UL transfer is a PDCH carrying at least
one UL TBF.
ED 1 RELEASED 011
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.
• UL TBF establishment
• DL TBF Release
• UL TBF Release
ED 1 RELEASED 011
o 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
ED 1 RELEASED 011
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 Upper layers (TCP/IP and FTP) performance
o Radio conditions (good, normal, radio)
o RF load (high CS traffic, high PS traffic)
o Radio resources allocation (number of PDCHs allocated, number of TBFs per PDCH)
o Transmission resources allocation (number of GCH)
Three different radio conditions are considered and they are based in the indicators RxLev and Mean_BEP.
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
In the expected results is considered that no impact exist from the radio and transmission resources.
ED 1 RELEASED 011
and at RLC layer. In 80% of the cases this issue is not associated with BSS network, the major problems
observed are in the PDP context negotiation and in the FTP server configuration. This complains comes
when non prepared end user tests are done, in services such as FTP download.
FTP is the best option to measure the throughput in a network.
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 Deutrip: Generates application traffic automatically (FTP, WEB, Streaming, etc.) and records
statistics (application throughput, access time, etc.)
o 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)
o Agilent E6474A (Nitro): Tool to collect and process air interface trace
o K12/K15: they are used to collect data from different interfaces, one important for PS analysis is
the Gb.
o 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.
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
ED 1 RELEASED 011
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 1 RELEASED 011
Expected slope
with throughput
= 200kbit/s
Retransmission
of lost data
throughput
is decreasing
(MS going towards
the edge of the
cell,
and MCS are
Good throughput decreasing ?)
with small
perturbations
(high MCS with BLER ?)
ED 1 RELEASED 011
ED 1 RELEASED 011
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.
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"
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 1 RELEASED 011
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.
written authorization from Alcatel-Lucent.
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.
b) GSS Network
o Case: Wrong QoS parameters in the HLR and/or in the client side:
ED 1 RELEASED 011
ED 1 RELEASED 011
MCS9
MCS6
MCS3
Radio 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.
Radio Block
Radio Block
ED 1 RELEASED 011
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 Support of 8-PSK in uplink.
o Support of incremental redundancy and resegmentation.
o 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 En_IR_UL = Disable
o 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.
UL TBF established and to maintain the higher MCS between iteration. For more details see [2].
ED 1 RELEASED 011
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.
ED 1 RELEASED 011
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.
o 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 1 RELEASED 011
At DSP level:
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.
o GPRS_DSP_CPU_overload_percent - Percentage of time during which a DSP is in CPU overload state.
o GPRS_GPU_DSP_cong_time - Time during which a DSP enters the congestion state.
o GPRS_GPU_DSP_cong_percent - Percentage of time during which a DSP enters the congestion state.
In a critical situation the impact of the Ater/GPU(GP)/DSP congestion should be observed in the TBF
establishment indicators:
o For DL:
• 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.
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.
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.
The Ater parameter optimizations recommended are:
3DF 01900 0000 PTZZA – DIAMS
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.
• Changeable by operator at BSS level - Min = 0 TS, Def = 2 TS, Max = 10 TS.
ED 1 RELEASED 011
o 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.
The lower, the faster Ater nibbles are freed when unused (Ater congestion is
reduced).
ED 1 RELEASED 011
ED 1 RELEASED 011
ED 1 RELEASED 011
ED 1 RELEASED 011