ED 1 RELEASED 011 NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 1/2 Y 3DF 01900 0000 PTZZA – DIAMS All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent. Domain : NETWORK OPTIMISATION Product : 2G B9 Division : METHODS Rubric : EDGE Type : GUIDELINE Distrib. codes Internal: External: PREDISTRIBUTION NE J. ANDRES NE/Quality & Partnership LF.GONNOT NE/Romania S. BODEA NE/GSM F. Colin NE/Egypt N. GEORGE NE/GSM/Egypt S. Abdel-Wahab NE/GSM/Romania C. Inta 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: Date: Signature: Date: Signature: Site CASCAIS WIRELESS BUSINESS GROUP NETWORK ENGINEERING Originator Pedro Henriques B9 EDGE Optimisation Guide
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 1/2
Y
3DF 01900 0000 PTZZA – DIAMS
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
Domain : NETWORK OPTIMISATION
Product : 2G B9
Division : METHODS
Rubric : EDGE
Type : GUIDELINE
Distrib. codes Internal: External:
PREDISTRIBUTION
NE J. ANDRES NE/Quality & Partnership LF.GONNOT
NE/Romania S. BODEA NE/GSM F. Colin
NE/Egypt N. GEORGE NE/GSM/Egypt S. Abdel-Wahab
NE/GSM/Romania C. Inta
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:
Date:
Signature:
Date:
Signature:
Site
CASCAIS
WIRELESS BUSINESS GROUP
NETWORK ENGINEERING
Originator
Pedro Henriques B9 EDGE Optimisation Guide
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc 20070629 3DF XXXX XXXX PTZZA 2/2
� 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 Max_GPRS_CS / Max_EGPRS_MCS
(Nb_GCH(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”):
� M–EGCH link of a TRX supporting one 4-TS EGPRS TBF (Max_EGPRS_MCS = MCS-9)
• 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
o 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.
2.5.4 PERIODICAL GCH ESTABLISHMENT PROCESS
A periodical GCH establishment process aims at periodically attempt to increase the M-EGCH link size of
TRXs, which have not yet reached their Target_Nb_GCH. It is defined in each cell of a BTS.
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 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 24/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
o The usage of the free basic Abis nibbles mapped to RTSs out of the “non preemptable PS zone” of
the cell.
o To guarantee that, following some abnormal GCH releases, new GCHs will be established in the
impacted M-EGCH links.
o 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.
o 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.
o To guarantee that some GCHs are always established for the “Fast Initial PS Access” feature
2.5.5 FAST INITIAL PS ACCESS
The aim of the feature Fast Initial PS Access is to speed up the TBF establishment time in a cell. It ensures
that one M-EGCH link is always established on the first TRX of the cell having some allocated TSs, i.e. for
the most PS-prioritary TRX of the cell having some TSs available for PS traffic. The feature is enabled at
cell-level with the EN_FAST_INITIAL_GPRS_ACCESS O&M parameter and the number of GCHs to establish on
this M-EGCH link is tunable by the N_GCH_FAST_PS_ACCESS system parameter.
2.5.6 HANDLING OF UNUSED GCH
When a TBF is released and Target_Nb_GCH of M-EGCH link becomes strictly lower than
Established_Nb_GCH, there is in the M-EGCH link (Established_Nb_GCH- Target_Nb_GCH) unused GCHs, e.g
established GCHs that are considered to be no more needed in the M-EGCH link.
Each time the previous condition happens, the T_GCH_Inactivity timer of the M-EGCH link is started. This
timer is useful to:
o “Anticipate” the arrival of new PS traffic on a given TRX.
o Provide some time for the “radio defragmentation” process to be completed in the cell (cf. T3 TBF
reallocations).
o Optimize ping times.
o Make the Ater nibbles of the released GCHs (on T_GCH_Inactivity timer expiry) usable by other
BTSs, or by other DSPs (if all the 4 nibbles of the 64k Ater TS are freed).
o If there is some PS traffic on another TRX in the cell while the T_GCH_inactivity timer is running,
then the “unused GCHs” can be intra-cell preempted to meet the GCH needs (if any) of that other
TRX. That avoids an Abis-Ater deswitching operation followed by a reswitching operation in the BSC.
This principle is only applicable to intra-cell GCH preemptions, not to inter-cell GCH preemptions.
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
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 25/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
Figure 2–14: Handling of unused GCHs
2.5.7 M-EGCH LINK CAPACITY DECREASE
There can be four reasons to have a M-EGH link capacity decrease, e.g a number of GCH is removed from an
M-EGCH link of a TRX:
o When a TBF is released and Target_Nb_GCH becomes strictly lower than Established_Nb_GCH
(unused GCHs and inactivity timer mechanism).
o GCH preemption: inter-cell and intra-cell.
o CS preemption: a basic Abis nibble used in the M-EGCH link is mapped on a RTS that must be given
back to the BSC (“CS preempted” RTS).
o Abnormal GCH release.
2.6 TBF RESOURCE ALLOCATION/REALLOCATION
In this chapter only Best-effort TBF (Non Real Time) resource allocation is considered.
2.6.1 TBF RESOURCE ESTABLISHMENT PROCESS
The TBF resource establishment process operates in two steps:
1. Radio Resource Allocation Algorithm: the objective of this algorithm is to find the best candidate
timeslot allocation and verify if enough transmission resource are available. This topic is discussed in
the next sub-chapter
2. TBF Establishment: if the RR allocation is performed then the TBF establishment is possible according
to the following conditions:
o 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
M-EGCH link
7 “used” GCHs
GCH1 B ≤ HL
GCH2 B ≤ HL
GCH3 B ≤ HL
GCH5 Extra
GCH4 Extra
GCH7 B > HL
GCH6 B > HL
Established_Nb_GCH = 10
3 “unused” GCHsGCH9 B > HL
GCH8 B > HL
GCH10 B > HL
Established_Nb_GCH = 7
Target_Nb_GCH = 7
M-EGCH link
7 “used” GCHs
GCH1 B ≤ HL
GCH2 B ≤ HL
GCH3 B ≤ HL
GCH5 Extra
GCH4 Extra
GCH7 B > HL
GCH6 B > HL
GCH1 B ≤ HL
GCH2 B ≤ HL
GCH3 B ≤ HL
GCH5 Extra
GCH4 Extra
GCH7 B > HL
GCH6 B > HL
Established_Nb_GCH = 10
3 “unused” GCHsGCH9 B > HL
GCH8 B > HL
GCH10 B > HL
Established_Nb_GCH = 10
3 “unused” GCHsGCH9 B > HL
GCH8 B > HL
GCH10 B > HL
GCH9 B > HL
GCH8 B > HL
GCH10 B > HL
Established_Nb_GCH = 7
Target_Nb_GCH = 7“B > HL”: GCH uses a basic Abisnibble mapped on a RTS out of the “non preemptable PS zone” of the cell.“Extra”: GCH uses an extra Abisnibble or a “bonus” basic Abis nibble.“B ≤ HL”: GCH uses a basic Abisnibble mapped on a RTS within the “non preemptable PS zone” of the cell.
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 26/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
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:
The number of established GCHs: Nb_GCH
Table 9: Maximun allowed CS.
Nb_GCH Max_Allowed_CS
1 CS-2 (UL) / CS-1 (DL)
2 ≥ CS-4
Table 10: Maximun allowed MCS.
Nb_GCH Max_Allowed_MCS
1 MCS-2 (UL) / MCS-1 (DL)
2 MCS-5
3 MCS-6
4 MCS-7
5 ≥ MCS-9
• GPRS / EGPRS TRX capability
• Max_GPRS_CS and Max_EGPRS_MCS (O&M parameters)
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) ASAP 1
TBF establishment (with concurrent) ASAP 1 to 5 (Max_Allowed_(M)CS of concurrent TBF)
T1 TBF reallocation ASAP 1
T4 TBF reallocation ASAP 1 to 2 (Max_Allowed_CS of concurrent TBF)
T3 TBF reallocation Optimal 1 to 5 (Max_Allowed_(M)CS of concurrent TBF)
2.6.2 RADIO RESOURCE ALLOCATION PRINCIPLES
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:
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 27/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
o Find the best candidate timeslot allocation, depending on:
• Type of request (GPRS / EGPRS)
• Multislot class
• Bias
• Traffic type
o 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.
The next figure summarizes the radio resource allocation algorithm.
Figure 2–15: RAE4 diagram
The description can be done by four steps:
o Find the best candidate timeslot allocation (steps 2, 3 and 4)
o Verify if there are enough transmission resources (steps 1, 5 and 6)
TRX list sorted by BSC
DSP congestion state
candidate TS allocation
- rejected request - or L4 queuing - or L5/L6 queuing - or L7 queuing (11) - or try to change TBF mode EGPRS case (12)
Type of the TBF request
n_MS_requested n_MS_requested_concurrent
TRX list
MS class, Bias, Traffic type
Best-effort TBF allocation/reallocation request
Number of radio TSs determination
(3)
TRX list computing
(2)
Best candidate TBF allocation computation (4)
no candidate TS allocation
Cell Transmission Equity (5)
Available_Nb_GCH_With_Equity
Test if enough GCHs (6)
“Enough GCHs “
“ALLOC OK” case “ALLOC FAILED” case
Transmission Resource
Availability (1)
TFI/TAI/USF allocation (7)
Available_Nb_GCH
Transmission resource reservation (8)
“Not enough GCHs “
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 28/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
o Allocate the radio resources (step 7)
o Reserve the transmission resources (step 8)
2.6.3 TRANSMISSION RESOURCE AVAILABILITY STEP
The goal of the Transmission resource availability is to compute the total number of new GCHs which are
possible to be established in a given cell. That number is called Available_Nb_GCH. The process is done by
two steps:
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-Allocation-
Request message on BSCGP interface for G2 BSC
2. Compute the number of possible inter-cell GCH preemptions. The principles of this algorithm are:
o “Source” TRX and “Target” TRX on different cells of the same BTS,
o Only the GCHs using extra or “bonus” Abis nibbles are considered.
o Only cells using more extra or “bonus” basic Abis nibbles are considered.
o On “source” TRX, the following constraints shall be respected:
• Established_Nb_GCH ≥ Min_Nb_GCH
o The iterative process stops when:
• No more GCH to preempt
• Or Available_Nb_GCH = Nb_Free_GCH + Nb_Preempted ≥ 36
2.6.4 TRX LIST COMPUTING
The goal of the TRX list computing step is to determine the TRX list on which the TBF or one UL block
candidate allocations will be searched.
The conditions for a TRX to be inserted into the TRX list are:
o The TRX shall be PS capable.
o If the TRX is not already mapped to a DSP and no DSP can be associated to the TRX, then the TRX
shall not be considered.
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.
2.6.5 BEST CANDIDATE ALLOCATION COMPUTATION
In the radio resource allocation/reallocation algorithm, the computing of the best candidate TBF allocation
consists in searching which are the best PDCHs onto which to establish (or reallocate) the TBF, according to
various radio related criteria.
Once all the usable PDCHs are determined, the different candidate timeslot allocations are sorted
according to their respective “available throughput”, in order to choose the one offering the highest
throughput to serve the considered request. This is a complete change compared to the previous BSS
releases (B6, B7 and B8).
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 29/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
The input data for the best candidate TBF allocation computation are:
o A sorted list of TRXs,
o n_MS_requested and n_MS_requested_concurrent,
o Type of the radio resources allocation request.
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.
Definition: PDCH states
The PDCH states are:
o Allocated:
• new in B9: the PDCH is a SPDCH indicated as usable for PS traffic by the BSC.
• B8 definition: radio resource allocated to the MFS, but associated transmission resources
are not allocated.
o Active:
• new definition in B9: an allocated PDCH is active if it supports at least one radio resource
allocated for a TBF.
• the B8 definition was considering the parameter N_TBF_PER_SPDCH which is removed in B9
release.
o Full:
• As in B8 release
� For GPRS Best Effort TBFs:
• An allocated PDCH is full in a given direction (XL: UL or DL) if and only if:
o Nb_BE_TBF_XL ≥ MAX_XL_TBF_SPDCH.
� For EGPRS Best Effort TBFs:
• An allocated PDCH is full in a given direction (XL: UL or DL) if and only if:
o Nb_BE_EGPRS_TBF_XL ≥ MAX_XL_TBF_SPDCH.
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.
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.
Candidate timeslot allocation:
A candidate timeslot allocation is a double list of contiguous PDCH in a TRX (one list for the direction of the
request, one list for the opposite direction), which verifies the concurrent constraints as defined by the MS
multislot class.
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 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
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 30/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
o The PDCH shall not be “locked” due to a CS pre-emption process
Available throughput of a candidate timeslot allocation:
This is a completely new metric introduced in B9 release and with high impact in the timeslot allocation. In
the past releases the idea was already to give the highest possible throughput to a TBF (allocating the
highest number of TS not busy, if possible) but there was no explicit metric evaluating the available
throughput provided by a candidate TS allocation. The available throughput of a given candidate timeslot
allocation (available_throughput_candidate_XL) is the overall throughput provided by its PDCHs. It depends
on the potential throughput of its PDCHs (potential_throughput_PDCH) and on the available capacity on
each of its PDCHs (available_capacity_PDCH_XL).
The potential throughput of a PDCH (potential_throughput_PDCH) is calculated as follows according to O&M
parameters for the Evolium BTS case:
o GPRS best effort TBF: R_AVERAGE_GPRS ( default = 12kbit/s )
o EGPRS best effort TBF: R_AVERAGE_EGPRS ( default = 30kbit/s )
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
o For an EGPRS TBF (XL corresponds to either UL or DL) :
• 1 / Nb_BE_EGPRS_ TBF_SAME_PRIOR_XL
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):
(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.
C31NC2
NC2_load
C2NC2
high
low
priority
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 47/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
(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 PDU’s according to the conditions defined
above. Otherwise RRM discards the DL LLC PDUs.
(11) RRm sends FLUSH-LL-ACk to SGSN.
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
SGSN INR En_Autonomous_Rerouting FLUSH-LL information MFS behaviour
Old BVCI and New BVCI MS Context rerouted DL LLC PDU rerouted Same RA
Same NSE NA NA
Old BVCI DL LLC PDU deleted
Old BVCI, New BVCI and New NSEI
MS Context rerouted DL LLC PDU rerouted Yes NA
Old BVCI DL LLC PDU deleted
Enable Old BVCI
MS Context autonomous rerouted DL LLC PDU autonomous rerouted
Same RA Different NSE
No
Disable Old BVCI DL LLC PDU deleted
If the DL LLC PDU rerouting feature is disabled the DL LLC PDU in the old cell will be deleted.
2.10 TELECOM PARAMETERS
The telecom parameters associated to the previous description are aggregated in the next table, the
optimised values are the ones were an optimisation is recommended, the optimised values should be
analysed before widely implementation in a network:
Table 16: Telecom parameters
GPRS/EGPRS configuration
Logical name Definition Instance Type Range Default value
Optimised value
TRX_PREF_MARK Preference mark assigned to a TRX to favour or disfavour CS radio resource allocations on a TRX.
TRX Number 0 to 7 1 0
Resource allocation/reallocation
Logical name Definition Instance Type Range Default value
Optimised value
EN_RES_REALLOCATION Enabling / disabling of the resource reallocation feature.
BSS Number 0 to 15 NA
T_PDCH_PREEMPTION
Timer to limit the duration of the soft pre-emption process (at its expiry, a fast pre-emption is undertaken).
Cell Number 0 to 240
NA
MAX_DL_TBF_SPDCH Maximum number of DownLink (E)GPRS connections per Slave PDCH.
Cell Number 1 to 10 8 5
MAX_UL_TBF_SPDCH Maximum number of UpLink (E)GPRS connections per slave PDCH.
Cell Number 1 to 6 5
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 48/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
EN_RETURN_CS_ZONE_HO
Flag enabling the intracell handovers allowing to move TCH from the PS zone to the CS zone of PDCH/TCH allocation
Cell Flag Enable
/ Disable
Enable
R_AVERAGE_GPRS average bitrate per PDCH for non-Edge capable terminals in this cell
Cell Number 0 to 20000
12000
R_AVERAGE_EGPRS average bitrate per PDCH for Edge capable terminals in this cell
Cell Number 0 to 59000
30000
GPRS/EGPRS radio resources
Logical name Definition Instance Type Range Default value
Optimised value
MAX_PDCH Maximum number of slave and master PDCHs that can be established in the cell.
Cell Number 0 to 127
0
MIN_PDCH Minimum number of master and slave PDCHs that are always allocated to the MFS.
Cell Number 0 to 127
0 1
MAX_PDCH_HIGH_LOAD
Maximum number of slave and master PDCHs that can be allocated to the MFS when the CS traffic is high.
Cell Number 0 to 127
0 1
MAX_PDCH_PER_TBF Maximum number of PDCH allocated to a single (E)GPRS connection
Cell Number 1 to 5 5
MAX_PDCH_PER_TBF_High_Ater_Usage
Maximum number of PDCH allocated to a single (E)GPRS connection, when the Ater usage is “high”.
Cell Number 1 to 5 NA
EGPRS activation / TBF handling
Logical name Definition Instance Type Range Default value
Optimised value
ACCESS_BURST_TYPE Format of the access burst used by MS
cell Flag 8 bits or
11 bits 8 bits
BEP_PERIOD Filter constant for EGPRS channel quality measurements.
cell Number 1 to 25 10
EN_EGPRS Enables/Disables EGPRS traffic in the cell.
cell Flag Enable
/ Disable
Disable Enable
MAX_EGPRS_MCS Maximum Modulation and Coding Scheme used for EGPRS traffic in the cell.
cell Number MCS1 to
MCS9 9
MAX_GPRS_CS Maximum coding scheme used for GPRS traffic in the cell.
cell Number 2 to 4 2
NB_EXTRA_ABIS_TS
Number of all extra Abis (64k) timeslots of all the pools defined on the 2 possible sectors on which the cell is mapped.(virtual changeable)
cell Number 0 to 96 NA
N_EXTRA_ABIS_TS Number of extra Abis (64k) timeslots configured for a BTS.
BTS Number 0 to 60 0
NB_TS_MPDCH (BSC) Number of radio timeslots reserved for the primary and secondary master PDCHs defined in the cell.
cell Number 0 to 4 0
PS_PREF_BCCH_TRX
Indicates whether or not the PS requests shall be preferentially served with PDCH(s) of the BCCH TRX
cell Flag Enable
/ Disable
Disable
T_DL_EGPRS_MeasReport Time period to request for an EGPRS Packet Downlink Ack/Nack with measurements.
cell Timer 60 to 3000m
s 200ms
TBF_DL_INIT_CS
Value of the downlink coding scheme when the link adaptation algorithm is disabled or initial value of the coding scheme otherwise.
cell Number CS1 to CS4
CS-2
TBF_UL_INIT_CS
Value of the uplink coding scheme when the link adaptation algorithm is disabled or initial value of the coding scheme otherwise.
cell Number CS1 to CS4
CS-2
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 49/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
TBF_DL_INIT_MCS
Value of the downlink coding scheme when the link adaptation algorithm is disabled or initial value of the coding scheme otherwise.
cell Number MCS1 to
MCS9 MCS-3
TBF_UL_INIT_MCS
Value of the uplink coding scheme when the link adaptation algorithm is disabled or initial value of the coding scheme otherwise.
cell Number MCS1 to
MCS9 MCS-3
NETWORK_CONTROL_ORDER(n) This parameter defines whether the MS or the BSS controls the cell reselections.
cell Number 0 to 4 0
TX_EFFICIENCY_ACK_THR
Threshold below which the TBF is released because of a bad transmission efficiency in acknowledged mode.
cell Percentage 0 to 100
10
TX_EFFICIENCY_NACK_THR
Threshold below which the TBF is released because of a bad transmission efficiency in unacknowledged mode.
cell Percentage 0 to 100
15
EN_EXTENDED_UL_TBF Flag to disable/enable the extended TBF mode feature on the uplink
cell Flag Enable
/ Disable
DISABLE
Enable
T_MAX_EXTENDED_UL Maximum duration of the extended uplink TBF phase
cell Timer [100, 4000]
2000
EN_FAST_USF_UL_EXTENDED Flag to disable/enable the transmission of USF every 20ms in extended mode
BSS Flag Enable
/ Disable
ENABLE Enable
EN_RA_CAP_UPDATE Flag to enable/disable the Radio Access Capability update on Gb
BSS Flag Enable
/ Disable
DISABLE
DRX_TIMER_MAX Maximum value allowed for the MS to request for non-DRX mode after packet transfer mode.
BSS sec 0 to 4 2
BS_CV_MAX
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 to 15 9
Coding scheme and radio link control
Logical name Definition Instance Type Range Default value
Optimised value
CS_QUAL_UL_2_3_FH_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 hopping TRX.
BSS Threshold 0 to 7 4
CS_QUAL_DL_2_3_FH_ACK
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 hopping TRX.
BSS Threshold 0 to 7 4
CS_QUAL_UL_2_3_FH_NACK
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 hopping TRX.
BSS Threshold 0 to 7 2
CS_QUAL_DL_2_3_FH_NACK
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 hopping TRX.
BSS Threshold 0 to 7 2
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 50/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
CS_QUAL_UL_2_3_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 non-hopping TRX.
BSS Theshold 0 to 7 3.5
CS_QUAL_DL_2_3_NFH_ACK
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 non-hopping TRX.
BSS Theshold 0 to 7 3.5
CS_QUAL_UL_2_3_NFH_NACK
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.
BSS Threshold 0 to 7 2
CS_QUAL_DL_2_3_NFH_NACK
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.
BSS Threshold 0 to 7 2
CS_QUAL_UL_3_4_FH_ACK
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.
BSS Threshold 0 to 7 0.5
CS_QUAL_DL_3_4_FH_ACK
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.
BSS Threshold 0 to 7 0.5
CS_QUAL_UL_3_4_FH_NACK
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.
BSS Threshold 0 to 7 0
CS_QUAL_DL_3_4_FH_NACK
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.
BSS Threshold 0 to 7 0
CS_QUAL_UL_3_4_NFH_ACK
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 non-hopping TRX.
BSS Threshold 0 to 7 0.5
CS_QUAL_DL_3_4_NFH_ACK
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 non-hopping TRX.
BSS Threshold 0 to 7 0.5
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 51/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
CS_QUAL_UL_3_4_NFH_NACK
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.
BSS Threshold 0 to 7 0
CS_QUAL_DL_3_4_NFH_NACK
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.
BSS Threshold 0 to 7 0
CS_SIR_DL_3_4_FH_ACK
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.
BSS Threshold 0 to 15 14 10
CS_SIR_DL_3_4_FH_NACK
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.
BSS Threshold 0 to 15 15 10
CS_SIR_DL_3_4_NFH_ACK
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 non-hopping TRX.
BSS Threshold 0 to 15 13 10
CS_SIR_DL_3_4_NFH_NACK
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.
BSS Threshold 0 to 15 15 10
CS_SIR_HST_DL
Signal to Interference Ratio hysteresis used in the link adaptation algorithms to change the Coding Scheme from CS4 to CS3 in the downlink direction.
BSS Number 0 to 15 1
CS_BLER_DL_3_4
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.
BSS Percentage 0 to 100
5
CS_BLER_DL_4_3
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.
BSS Percentage 0 to 100
15
TBF_CS3_BLER_PERIOD
Defines the window size required to estimate the CS3 BLER. The window size is expressed as a number of DL RLC data blocks
BSS Number 1 to 512
32
TBF_CS4_BLER_PERIOD
Defines the window size required to estimate the CS4 BLER. The window size is expressed as a number of DL RLC data blocks
BSS Number 1 to 512
32
EN_FULL_IR_DL Enables/Disables Incremental redundancy for the downlink TBF in the cell.
BSS Flag Enable
/ Disable
DISABLE
Enable
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 52/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
EN_IR_UL Enables/Disables Incremental redundancy for the uplink TBF in the BSS.
BSS Flag Enable
/ Disable
DISABLE
Enable
EN_RESEGMENTATION_UL Enables/Disables the re-segmentation for the uplink TBF in the BSS
BSS Flag Enable
/ Disable
DISABLE
Disable
E_TX_EFFICIENCY_PERIOD Number of received radio blocks for an EGPRS TBF after which E_TX_EFFICIENCY is computed.
BSS Number 0 to 500
200
EN_CS_ADAPTATION_ACK Enables / disables the link adaptation in RLC acknowledged mode.
Cell Flag Enable
/ Disable
Enable
EN_CS_ADAPTATION_NACK Enables / disables the link adaptation in RLC unacknowledged
Cell Flag Enable
/ Disable
Enable
TBF_CS_DL
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 multi-slot TBF or a TBF which shares its PDCH(s), the limit is proportional to the instantaneous bandwidth allocated to the TBF.
BSS Number 0 to 15 8
TBF_CS_UL
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
BSS Number 0 to 64 32
TBF_MCS_DL
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.
BSS Threshold 0 to 15 12
TBF_MCS_UL
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 Threshold 1 to 192
32
GPRS/EGPRS Transmission
Logical name Definition Instance Type Range Default value
Optimised value
EN_FAST_INITIAL_GPRS_ACCESS
This flag indicates whether or not one Slave PDCH for (E)GPRS traffic usage will be statically established in the cell.
cell Flag Enable
/ Disable
Disable
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 53/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
T_GCH_INACTIVITY
- 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
BSS Number 1 to 100
3 2
T_GCH_INACTIVITY_LAST
- 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.
BSS Number 1 to 200
20 8
N_GCH_FAST_PS_ACCESS
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.
MFS Number 1 to 5 1
GPRS_MULTISLOT_CLASS_DEF_VALUE
Default value of the (E)GPRS multislot class assumed at TBF establishment when the actual MS (E)GPRS multislot class is unknown.
BSS Number 1 to 8 8
ATER_USAGE_THRESHOLD Threshold (percentage of used Ater nibbles, in a GPU) above which the Ater usage is said “high”.
BSS Percentage 1 to 100
70
N_ATER_TS_MARGIN_GPU
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.
BSS Number 0 to 10 2
GCH_RED_FACTOR_HIGH_ATER_USAGE Reduction factor of the number of GCHs targeted per PDCH, when the Ater usage is “high”.
cell Number 0 to 1 0.75
Enhanced Packet Cell Reselection
Logical name Definition Instance Type Range Default value
Optimised value
EN_NACC Enables the Network Assisted Cell Change feature.
cell Flag Enable
/ Disable
Disable 1
EN_PSI_STATUS
Enables the Packet SI Status feature in cells w/o PBCCH or the Packet PSI Status feature in cells with a PBCCH.
cell Flag Enable
/ Disable
Disable 1
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 54/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
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:
Figure 3–1: BSS Architecture in B9 release.
And with the introduction of the Mx platform and TWIN TRA:
Figure 3–2: BSS Architecture in B9 release with Mx platform.
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 Abis
o Ater
o GPU/GP
BSC Abis TSU
Ater TSU
Abis TSU
Ater TSU
Abis TSU
Ater TSU
speech
data
A-ter mux
Gb
A
CS
CS+ PS
PS
CS A-bis
Air
MFS
GPU board
DSP DSP DSP DSP
GPU board
DSP DSP DSP DSP
TC
MT120
SMU TRCU TRCU
TRCU
MT120
SMU TRCU
TRCU
TRCU
TRX 2 M-EGCH link 1
PS traffic
TRX 3 M-EGCH link 2
M-EGCH link n
BTS
Dynamic Abis
allocation GCH Extra
GCH Basic
GCH Basic
GCH Extra
GCH Bonus
TCH
TCH TRX 1 CS
traffic
TRX n
TCUC
Up to 12 TRXs per BTS
speech
data
A-ter mux
Gb
A
CS
CS+ PS
PS
CS A-bis
Air
TC
MT120
SMU TRCU TRCU
TRCU
MT120
SMU TRCU
TRCU
TRCU
TRX 2 M-EGCH link 1
PS traffic
TRX 3 M-EGCH link 2
M-EGCH link n
BTS
Dynamic Abis
allocation GCH Extra
GCH Basic
GCH Basic
GCH Extra
GCH Bonus
TCH
TCH TRX 1 CS
traffic
TRX n
MxBSC CCP board
CCP board
SSW board
TP board
LIU board
LIU board
VTCU
MxMFS
GP board
DSP DSP DSP DSP
GP board
DSP DSP DSP DSP
Up to 24 TRXs per BTS with Twin Modules
Capacity 1 GP = 4xGPU
(B9 MR4)
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 55/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
3.1 ABIS
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 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)
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 6 bonus nibbles available for PS (from the 3 BCCH and the 3 SDCCH)
o 4 PDCH per user x 2 users x 1 GCH from basic nibbles = 8 GCH
o 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 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
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
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 56/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
Assumption:
o Each user is alone in one of the cells.
o Cell transmission equity is not possible, since the users are served by different cells
o 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
Where the:
o Total number of GCHs = 6 nibbles + 12 basic + 6*4 extra Abis nibbles = 42 GCH
o 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.
Figure 3–3: Calculation of the Number of Extra Abis TS.
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 57/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
o 3600
466__&_
PTrafficAbisBonusExtraMeasured =
o )___,%___(%__% CongAbisTBFULCongAbisTBFDLMaxCongABISTBF =
o %100919191919191
105___% ×
+++++=
fPePdPcPbPaP
iPCongAbisTBFDL
o %100438626262
105___% ×
−++=
cPcPbPaP
jPCongAbisTBFUL
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).
Figure 3–4: Calculation of the needed GCHs in the Atermux interface.
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.
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 58/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
Figure 3–5: Calculation of the Required_GCH_Traffic by Method 1.
The Required_GCH_Traffic is calculated by the formula:
Congestion
TrafficGCHMeasuredTrafficGCHquired
−=
1
____Re
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.
Figure 3–6: Measured GCH traffic vs Measured PDCH traffic.
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 59/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted 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.
The formula is given by the:
Figure 3–7: Calculation of the Required_GCH_Traffic by Method 2.
With P38b as the PDCH traffic.
3.2.3 NUMBER OF GCH NEEDED
After the Required_GCH_Traffic is calculated, the Erlang C formula should be used to calculate the number
of GCHs needed and by association the number of Atermux to add.
3.2.4 HSDS IMPACT
With the activation of HSHS (EDGE and CS3/CS4) the consumption of AterMux transmission resources (GCH)
per radio resource (PDCH) increases.
The calculation of the Required_GCH_Traffic is impacted by an increase factor if HSDS is activated; the
process is in the next figure:
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 60/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
Figure 3–8: Increase factor
The increase factor will be a function of:
o The transition type
o The target service penetration (i.e. %EDGE with respect to GPRS)
o 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:
Figure 3–9: 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 initial
final
r_PDCH_nb_GCH_peAvg_target
r_PDCH_nb_GCH_peAvg_targetactorIncrease_f =
CS1 / CS2
CS3 / CS4
EDGE
CS3 / CS4 And EDGE
a
b
c
d
e
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
Increase_factor =
increase_factor (reference BSCs)
Execute transition
Dimensioning assessment for
fine tuning
Update reference BSCs set
Does a (set of) reference
BSC(s) Exist?
No
Yes
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 61/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
Where:
o _PDCH_MCSynb_GCH_per S%_PDCH_GPR_PDCH_MCSxnb_GCH_per RS%_PDCH_EGP
r_PDCH_nb_GCH_peAvg_target
×+×==
o %_PDCH_EGPRS: % of Radio Resources (PDCH) supporting at least one TBF established in EGPRS
mode on a cell with MAX_EGPRS = MCSx
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:
Table 17: Increase_factor
Transition Type Increase_factor
a [(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*1,64)]/1
b [1,64]/1
c [(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*1)]/1
d [(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*1,64)]/ 1,64
e (%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*1,64)/(%_PDCH_EGPRS*4,49)+(%_PDCH_GPRS*1)
For method 1 the application of the increase factor is by the simple formula:
o actorIncrease_f_trafficquired_GCH_trafficquired_GCH currentfinal ×= ReRe
For method 2 the impact of the increase factor is applied in the slope, as explained in the next graphic:
Figure 3–10: Method 2 – increase_factor
Where
o a2= a1 * Increase_Factor and b2 = b1 (approximation !)
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 62/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
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:
{ }CapabilitySWHWGPUperGCHULMaxGPUperGCHDLMaxMin
CapacityGCHGPGPU
_/,____,____
__/
∑∑
=
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:
• ( )( ) ...H_MCS1 max_DL_GCMCS1 max_PDCH_%MCS1
...H_CS1 max_DL_GCCS1 max_PDCH_%CS1
_GPUMax_DL_GCH
+××++××
=
• ( )( ) ...H_MCS1 max_UL_GCMCS1 max_PDCH_%MCS1
...H_CS1 max_UL_GCCS1 max_PDCH_%CS1
_GPUMax_UL_GCH
+××++××
=
• 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
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 63/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted 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
Max CS GPU (A9135) & GP (A9130) up
to B9MR1
GP (A9130) from B9MR4 Case 12 E1 links per GP
GP (A9130) from B9MR4 Case 16 E1 links per GP
GP (A9130) from B9MR4 Case 10 E1 links per GP
CS1 240 960 960 896
CS2 240 960 960 896
CS3 224 892 892 716
CS4 200 684 804 544
Table 19: max_PDCH_MCSx per GPU/GP determination for EGPRS
EGPRS max_PDCH_MCSx: Max nb of PDCH per GPU/GP
Max MCS GPU (A9135) & GP (A9130) up
to B9MR1
GP (A9130) from B9MR4 Case 12 E1 links per GP
GP (A9130) from B9MR4 Case 16 E1 links per GP
GP (A9130) from B9MR4 Case 10 E1 links per GP
MCS1 224 860 860 860
MCS2 224 836 836 836
MCS3 208 796 796 672
MCS4 200 748 776 596
MCS5 184 604 704 480
MCS6 172 476 664 380
MCS7 136 320 452 256
MCS8 116 272 380 216
MCS9 108 252 352 200
The number of GPU/GP needed is then given by dividing the needed GCH per the GPU_GCH_Capacity.
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 64/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
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. That’s why, a consistent and rigorous approach has to be considered on this topic.
Three different main phases exist for the PS dimensioning and optimisation:
o Phase 1 - PS implementation/activation, the network is dimensioning for low PS traffic, mainly
signalling traffic.
o Phase 2 - Increase of PS traffic without enough radio and transmission resources – parameters
optimization needed to minimize the impact
o 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:
1. Circuit Switch accessibility
2. Packet Switch performance
3. Packet Switch accessibility
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
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 65/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
optimize the network in accordance. This phase is a transition phase; it should be used for only a short
time.
The PS performance is no longer a major priority, important is to give PS access to all users and the
priorities are redefined as:
1. Circuit Switch accessibility
2. Packet Switch accessibility
3. Packet Switch performance
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:
1. Circuit Switch accessibility
2. Packet Switch performance
3. Packet Switch accessibility
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 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 66/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
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 Alc_Mono_DashBoard_(E)GPRS_QoS
o Alc_Mono_DashBoard_(E)GPRS_Traffic_1
o 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.
5.1 TBF LIFE TIME
5.1.1 TBF ESTABLISHMENT
The next indicators allows to follow the success of the TBF establishment and the possible existing failures,
this ones can be due to radio, transmission interface, BSS internal failures or to congestion. It is not
possible in the current BSS release to distinguish the TBF establishments between GPRS and EDGE TBFs, this
lack of information can hide problems related to only one technology.
For DL:
Table 20: DL TBF Establishment RNO indicator Description Unit Comments
GPRS_DL_TBF_success_rate Rate of DL TBF establishment -successes (seized by the mobile)
%
GPRS_DL_TBF_request Number of DL TBF establishment -requests. nb
The absolute number of requests is important to validate the statistics
GPRS_DL_TBF_estab_allocated_rate Rate of DL TBF allocated per cell. % This indicator measure the impact of the congestion
GPRS_DL_TBF_estab_fail_BSS_rate Rate of DL TBF estab - failures due to BSS problem per cell. Reference: number of DL TBF estab -requests
%
GPRS_DL_TBF_estab_fail_GB_rate Rate of DL TBF estab -failures due to Gb interface problem per cell. Reference: number of DL TBF estab -requests
%
GPRS_DL_TBF_estab_fail_radio_rate Rate of DL TBF estab -failures due to radio problem per cell. Reference: number of DL TBF estab -requests
%
GPRS_DL_TBF_estab_fail_cong_rate
Rate of DL TBF establishment failures due to congestion per cell. Reference: number of DL TBF establishment requests.
%
Split of failures during DL TBF establishment
GPRS_DL_TBF_estab_fail_abis_cong Number of DL establishment failures due to congestion of Abis.
nb
GPRS_DL_TBF_estab_fail_ater_cong Number of DL establishment failures due to congestion of Ater(Mux).
nb
GPRS_DL_TBF_estab_fail_cpu_cong Number of DL establishment failures due to CPU processing power limitations of the GPU.
nb
GPRS_DL_TBF_estab_fail_dsp_cong Number of DL establishment failures due to congestion of DSP.
nb
GPRS_DL_TBF_estab_fail_radio_cong Number of DL TBF establishment failure due to radio congestion per cell.
nb
Split of the congestion failures, this information is important for BSS dimensioning
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 67/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
For UL:
Table 21: UL TBF Establishment RNO indicator Description Unit Comments
GPRS_UL_TBF_success_rate Rate of UL TBF estab success. Reference: number of UL TBF estab -requests
%
GPRS_UL_TBF_request Number of UL TBF establishment -requests per cell.
nb The absolute number of requests is important to validate the statistics
GPRS_UL_TBF_estab_allocated_rate Rate of UL TBF allocated per cell. % This indicator measure the impact of the congestion
GPRS_UL_TBF_estab_fail_BSS_rate Rate of UL TBF estab -failures due to BSS problem per cell. Reference: number of UL TBF estab -requests
%
GPRS_UL_TBF_estab_fail_GB_rate Rate of UL TBF estab -failures due to Gb interface problem per cell. Reference: number of UL TBF estab -requests
%
GPRS_UL_TBF_estab_fail_radio_rate Rate of UL TBF estab -failures due to radio problem per cell. Reference: number of UL TBF estab -requests
%
GPRS_UL_TBF_estab_fail_cong_rate
Rate of UL TBF establishment failures due to congestion per cell. Reference: number of UL TBF establishment requests.
%
Split of failures during UL TBF establishment
GPRS_UL_TBF_estab_fail_abis_cong Number of UL establishment failures due to congestion of Abis.
nb
GPRS_UL_TBF_estab_fail_ater_cong Number of UL establishment failures due to congestion of Ater(Mux).
nb
GPRS_UL_TBF_estab_fail_cpu_cong Number of UL establishment failures due to CPU processing power limitations of the GPU..
nb
GPRS_UL_TBF_estab_fail_dsp_cong Number of UL establishment failures due to congestion of DSP.
nb
GPRS_UL_TBF_estab_fail_radio_cong Number of UL TBF establishment failure due to radio congestion per cell.
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 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)
5.1.2 TBF DATA TRANSFER
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
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 68/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
For DL:
Table 22: DL TBF Data Transfer RNO indicator Description Unit Comments
GPRS_DL_TBF_normal_release_rate Rate of DL TBF normal release. Reference: number of DL TBF establishment - successes
%
Rate of DL TBF not impacted by failures or reselection during data transfer
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 impacted during data transfer due to features to favour CS or cell reselection.
GPRS_DL_TBF_drop_rate Rate of DL TBF drops. Reference: number of DL TBF establishment - successes
%
GPRS_DL_TBF_normal_release Number of DL TBF normal release. nb
GPRS_DL_TBF_acceptable_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
nb
GPRS_DL_TBF_drop Total number of DL TBF drops. nb
GPRS_DL_TBF_radio_preemption_release_rate
Rate of DL TBF releases due to fast preemption in case of need of radio resources. Reference: number of DL TBF establishment successes.
%
GPRS_DL_TBF_release_suspend_rate
Rate of suspend messages for a DL TBF received from MS (via BSC). Reference: number of DL TBF establishment successes.
%
GPRS_DL_TBF_release_NC2_reselect_rate
Rate of DL TBF releases due to NC2 cell reselection Reference: total number of DL TBF establishment success
%
GPRS_DL_TBF_release_NC0_reselect_rate
Rate of DL TBF releases due to NC0 cell reselection Reference: total number of DL TBF establishment success
%
Split of acceptable release causes
GPRS_DL_TBF_drop_BSS_rate Rate of DL TBF drops due to BSS problems. Reference: number of DL TBF establishment - successes
%
GPRS_DL_TBF_drop_GB_rate
Rate of DL TBF drops due to Gb interface problems. Reference: number of DL TBF establishment - successes
%
GPRS_DL_TBF_drop_blocking_rate
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.
%
GPRS_DL_TBF_drop_N_stagnatingWindow_rate
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
%
Split of TBF drop causes
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 69/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
GPRS_DL_TBF_realloc_execution_fail_radio_rate
Rate of DL TBF drops due to radio failures during radio resource reallocation execution. Reference: number of DL TBF establishment successes.
%
GPRS_DL_TBF_drop_radio_rate Rate of DL TBF drops due to radio problems. Reference: number of DL TBF establishment - successes
%
For UL:
Table 23: UL TBF Data Transfer RNO indicator Description Unit Comments
GPRS_UL_TBF_normal_release_rate Rate of UL TBF normal releases. Reference: number of UL TBF establishment - successes
%
Rate of UL TBF not impacted by failures or reselection during data transfer
GPRS_UL_TBF_acceptable_release_rate
Rate of UL TBF releases due to: - TBF release due to radio preemption - TBF release due to suspend resume procedure - TBF release due to cell reselection. Reference : number of UL TBF success.
%
Rate of UL TBF impacted during data transfer due to features to favour CS or cell reselection.
GPRS_UL_TBF_drop_rate Rate of UL TBF drops. Reference: number of UL TBF establishment - successes
%
GPRS_UL_TBF_normal_release Number of UL TBF normal releases. nb
GPRS_UL_TBF_acceptable_release
Number of UL TBF releases due to : - UL TBF release due to radio preemption - UL TBF release due to suspend resume procedure - UL TBF release due to cell reselection
nb
GPRS_UL_TBF_drop Number of UL TBF drop. nb
GPRS_UL_TBF_radio_preemption_release_rate
Rate of UL TBF releases due to fast preemption in case of need of radio resources. Reference: number of UL TBF establishment successes.
%
GPRS_UL_TBF_release_suspend_rate
Rate of suspend messages for an UL TBF received from MS (via BSC). Reference: number of UL TBF establishment successes.
%
GPRS_UL_TBF_release_NC2_reselect_rate
Rate of UL TBF releases due to NC2 cell reselection Reference: number of UL TBF establishment successes
%
GPRS_UL_TBF_release_NC0_reselect_rate
Rate of UL TBF releases due to NC0 cell reselection Reference: number of UL TBF establishment successes
%
Split of acceptable release causes
GPRS_UL_TBF_drop_BSS_rate Rate of UL TBF drops due to BSS problems. Reference: number of UL TBF establishment - successes
%
GPRS_UL_TBF_drop_GB_rate
Rate of UL TBF drops due to GB interface problems. Reference: number of UL TBF establishment - successes
%
GPRS_UL_TBF_drop_blocking_rate
Rate of UL TBF drops due to blocking situation at the beginning or at the end of UL TBF (including blocking situation following NC2 cell reselection). Reference: number of UL TBF establishment successes.
%
Split of TBF drop causes
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 70/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
GPRS_UL_TBF_drop_N_stagnatingWindow_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
%
GPRS_UL_TBF_realloc_execution_fail_radio_rate
Rate of UL TBF drops due to radio problems during radio resource reallocation execution Reference: number of UL TBF establishment successes.
%
GPRS_UL_TBF_drop_radio_rate Rate of UL TBF drops due to radio problems Reference: number of UL TBF establishment - successes
%
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
GPRS_DL_TBF_realloc_T1_request Number of DL TBFs candidate for resource reallocation (trigger T1).
nb
GPRS_DL_TBF_realloc_T2_request Number of DL TBFs candidate for resource reallocation (trigger T2).
nb
GPRS_DL_TBF_realloc_T3_request Number of DL TBF candidate for resource reallocation (trigger T3).
nb
GPRS_DL_TBF_realloc_T4_request Number of DL TBF candidate for resource reallocation (trigger T4).
nb
The absolute number of requests is important to validate the statistics
GPRS_UL_TBF_realloc_T1_success_rate Rate of UL TBF reallocation Trigger 1 success over the number of UL TBF trigger 1 requests
%
GPRS_UL_TBF_realloc_T2_success_rate Rate of UL TBF reallocation Trigger 2 success over the number of UL TBF trigger 2 requests
%
GPRS_UL_TBF_realloc_T3_success_rate Rate of UL TBF reallocation Trigger 3 success over the number of UL TBF trigger 3 requests
%
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 71/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
GPRS_UL_TBF_realloc_T4_success_rate
Rate of UL TBF resource reallocation successes for trigger T4. Reference: number of UL TBF candidate for resource reallocation for trigger T4.
%
GPRS_UL_TBF_realloc_T1_request Number of UL TBF candidate for resource reallocation (trigger T1).
nb
GPRS_UL_TBF_realloc_T2_request Number of UL TBFs candidate for resource reallocation (trigger T2).
nb
GPRS_UL_TBF_realloc_T3_request Number of UL TBF candidate for resource reallocation (trigger T3).
nb
GPRS_UL_TBF_realloc_T4_request Number of UL TBF candidate for resource reallocation (trigger T4).
nb
The absolute number of requests is important to validate the statistics
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.
5.2 RLC STATISTICS
5.2.1 (M)CS DISTRIBUTION
There are large possibilities to calculate/present the distribution of CS and/or MCS blocks. But all
ratios/rates/useful throughput/etc. indicators will be based on the number of useful blocks received per
(M)CS. Here we propose the MCS distribution statistics given its ratio, e.g. the number of transmitted useful
RLC blocks by overall useful RLC blocks, for DL and for UL.
The throughput indicators calculated using the (M)CS distribution are important for stability, since it
doesn’t represent the available maximum or average throughput in the cell, The throughput indicators are
impacted by small amount of data transfer
For DL:
Table 25: DL (M)CS Distribution RNO indicator Description Unit Comments
GPRS_DL_useful_RLC_blocks_CS1_ack_ratio
Ratio of useful DL 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
%
GPRS_DL_useful_RLC_blocks_CS2_ack_ratio
Ratio of useful DL 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
%
Split of the CS distribution
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 72/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
GPRS_DL_useful_RLC_blocks_CS3_ack_ratio
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
%
GPRS_DL_useful_RLC_blocks_CS4_ack_ratio
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
%
GPRS_DL_useful_RLC_blocks_MCS1_ack_ratio
Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-1, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_DL_useful_RLC_blocks_MCS2_ack_ratio
Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-2, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_DL_useful_RLC_blocks_MCS3_ack_ratio
Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-3, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_DL_useful_RLC_blocks_MCS4_ack_ratio
Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-4, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_DL_useful_RLC_blocks_MCS5_ack_ratio
Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-5, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_DL_useful_RLC_blocks_MCS6_ack_ratio
Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-6, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_DL_useful_RLC_blocks_MCS7_ack_ratio
Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-7, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_DL_useful_RLC_blocks_MCS8_ack_ratio
Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-8, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_DL_useful_RLC_blocks_MCS9_ack_ratio
Ratio of useful DL RLC blocks sent on PDTCH encoded in MCS-9, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
Split of the MCS distribution
GPRS_DL_useful_throughput_radio_EGPRS_TBF_avg
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.
kbit/s
GPRS_DL_useful_throughput_radio_GPRS_TBF_avg
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.
kbit/s
High impacted by the small data transfer, such as GMM and SM.
For UL:
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 73/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
Table 26: UL (M)CS Distribution RNO indicator Description Unit Comments
GPRS_UL_useful_RLC_blocks_CS1_ack_ratio
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
%
GPRS_UL_useful_RLC_blocks_CS2_ack_ratio
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
%
GPRS_UL_useful_RLC_blocks_CS3_ack_ratio
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
%
GPRS_UL_useful_RLC_blocks_CS4_ack_ratio
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
%
Split of the CS distribution
GPRS_UL_useful_RLC_blocks_MCS1_ack_ratio
Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-1, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_UL_useful_RLC_blocks_MCS2_ack_ratio
Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-2, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_UL_useful_RLC_blocks_MCS3_ack_ratio
Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-3, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_UL_useful_RLC_blocks_MCS4_ack_ratio
Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-4, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_UL_useful_RLC_blocks_MCS5_ack_ratio
Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-5, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_UL_useful_RLC_blocks_MCS6_ack_ratio
Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-6, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_UL_useful_RLC_blocks_MCS7_ack_ratio
Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-7, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_UL_useful_RLC_blocks_MCS8_ack_ratio
Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-8, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
GPRS_UL_useful_RLC_blocks_MCS9_ack_ratio
Ratio of useful UL RLC blocks sent on PDTCH encoded in MCS-9, in RLC acknowledged mode (the retransmitted blocks are not counted).
%
Split of the MCS distribution
GPRS_UL_useful_throughput_radio_EGPRS_TBF_avg
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.
kbit/s
High impacted by the small data transfer,
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 74/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
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.
kbit/s
such as GMM and SM.
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.
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.
5.2.2 LLC/RLC TRAFFIC AND RETRANSMISSION
The overall user traffic in a cell should be measured by the next 2 indicators one for DL another for UL.
Table 27: LLC traffic
RNO indicator Description Unit Comments
GPRS_DL_LLC_bytes Number of DL LLC bytes received from the SGSN at BSSGP level per cell.
nb Overall DL LLC traffic
GPRS_UL_LLC_bytes Number of UL LLC bytes sent to the SGSN at BSSGP level per cell.
nb Overall UL LCC traffic
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
GPRS_DL_LLC_bytes_EGPRS_ack_mode Number of DL LLC bytes transmitted and acknowledge on established DL TBF in EGPRS mode and RLC acknowledged mode
nb
GPRS_DL_LLC_bytes_EGPRS_unack_mode Number of DL LLC bytes transmitted and acknowledge on established DL TBF in EGPRS mode and RLC unacknowledged mode
nb
GPRS_DL_LLC_bytes_GPRS_ack_mode Number of DL LLC bytes transmitted and acknowledge on established DL TBF in GPRS mode and RLC acknowledged mode
nb
GPRS_DL_LLC_bytes_GPRS_unack_mode Number of DL LLC bytes transmitted and acknowledge on established DL TBF in GPRS mode and RLC unacknowledged mode
nb
For UL:
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 75/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
Table 29: UL LLC traffic
RNO indicator Description Unit
GPRS_UL_LLC_bytes_EGPRS_ack_mode Number of UL LLC bytes received on UL TBFs established in EGPRS mode and RLC ackowledged mode
nb
GPRS_UL_LLC_bytes_EGPRS_unack_mode Number of UL LLC bytes received on UL TBFs established in EGPRS mode and RLC unackowledged mode
nb
GPRS_UL_LLC_bytes_GPRS_ack_mode Number of UL LLC bytes received on UL TBFs established in GPRS mode and RLC ack mode
nb
GPRS_UL_LLC_bytes_GPRS_unack_mode Number of UL LLC bytes received on UL TBFs established in GPRS mode and RLC unackowledged mode
nb
The indicators for RLC traffic are the next tables
For DL:
Table 30: DL RLC traffic RNO indicator Description Unit Comments
GPRS_DL_useful_bytes_CSx_ack Number of useful RLC data bytes sent on PDTCH, in GPRS and RLC ack modes.
nb
GPRS_DL_useful_bytes_MCSx_ack Number of useful RLC data bytes sent on PDTCH, in EGPRS and RLC ack modes.
nb
GPRS_DL_RLC_bytes_PDTCH_CSx_retransmission_ratio
In RLC ack mode, ratio of downlink RLC retransmitted data bytes sent on PDTCH and encoded in CS-x. Reference : overall number of DL RLC data bytes transmitted in GPRS mode
%
This indicator is an overall indication, however some CS may be more retransmitted than others.
GPRS_DL_RLC_bytes_PDTCH_MCSx_retrans_ack_ratio
In RLC acknowledged mode, ratio of DL RLC data bytes encoded in MCS-x and retransmitted due to unacknowledgement of the MS. RLC blocks containing LLC dummy UI commands are not counted. Reference: overall number of DL RLC data bytes transmitted in EGPRS mode.
% This indicator is an overall indication, however some CS may be more retransmitted than others.
For UL:
Table 31: UL RLC traffic
RNO indicator Description Unit Comments
GPRS_UL_useful_bytes_CSx_ack Number of useful RLC bytes sent on PDTCH in GPRS and RLC ack modes
nb
GPRS_UL_useful_bytes_MCSx_ack Number of useful RLC bytes sent on PDTCH in EGPRS and RLC ack modes
nb
GPRS_UL_RLC_bytes_CSx_retransmissing_ack_ratio
In RLC ack mode, ratio of uplink RLC bytes retransmitted on PDTCH and encoded in CS-x. Reference : total number of UL RLC data bytes sent on PDTCH in RLC ack mode
%
This indicator is an overall indication, however some CS may be more retransmitted than others.
GPRS_UL_RLC_bytes_PDTCH_MCSx_retrans_ack_rate
In acknowledged mode, ratio of UL RLC data bytes encoded in MCS-x and retransmitted due to unacknowledgement of the MFS. Reference : overall number of UL RLC data bytes sent on PDTCH encoded in MCSx in RLC ack mode
%
This indicator is an overall indication, however some CS may be more retransmitted than others.
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 76/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
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.
5.3 RADIO RESOURCES
One main reason for the existence of the radio resources indicators is to allow a good PS radio dimensioning
in a cell. It is possible to monitor the use of the PDCH not only the time they are established but also the
number of pilled TBF per PDCH.
Table 32: Radio Resources RNO indicator Description Unit Comments
GPRS_PDCH_EGPRS_traffic_time Cumulative time during which the slave PDCHs are established and carry at least one UL or DL TBF.(established in EGPRS mode)
s
GPRS_PDCH_traffic_time Cumulative time during which the slave PDCHs are established and carry at least one UL or DL TBF.(established in GPRS mode or EGPRS mode).
s
GPRS_PDCH_active_avg
For B8: average number of established slave PDCHs. For B9: average number of slave PDCHs carrying at least one UL or DL TBF.(established in GPRS mode or EGPRS mode). Reference: observation period
nb
GPRS_PDCH_used_max
Maximum number of PDCHs used in the cell Note: B8: It count the established PDCHs. An established PDCH is a PDCH to which one (several) transmission resource(s) is (are) connected. B9: It count the used (active) PDCH. An used PDCH is a PDCH that carries at least one UL or DL TBF. Consolidated in Day/Week/Month with the MAX value.
nb
These indicators are important for radio dimensioning
GPRS_DL_connection_time_avg Average connection time of established DL TBF (active and delayed). Reference : Number of DL TBF successes.
s
GPRS_UL_connection_time_avg Average connection time of established UL TBF. Reference : Number of UL TBF successes.
s
GPRS_DL_TBF_Pilled_avg
Average number of DL TBF on PDCHs active with DL transfers (TBF active and delayed phases are taken into account). An active PDCH with DL transfer is a PDCH carrying at least one DL TBF.
nb
GPRS_UL_TBF_Pilled_avg
Average number of UL TBF on PDCHs active with UL transfers (TBF active and delayed phases are taken into account). This indicator gives a measure of the number of UL TBFs piled up on a PDCH for all the PDCH. An active PDCH with UL transfer is a PDCH carrying at least one UL TBF.
nb
These indicators are important for radio dimensioning
GPRS_DL_TBF_estab_avg Average number of DL TBF simultaneously established over the granularity period. Consolidated in Day/Week/Month with the MAX value.
nb
GPRS_UL_TBF_estab_avg Average number of UL TBF simultaneously estab over the Granularity period. COnsolidated in day-week-month with the MAX value.
nb
GPRS_PDCH_per_DL_TBF_avg
Average number PDCHs (active with DL transfers) per DL TBF (TBF active and delayed phases are taken into account). An active PDCH with DL transfer is a PDCH carrying at least one DL TBF.
nb
GPRS_PDCH_per_UL_TBF_avg
Average number PDCHs (active with UL transfers) per UL TBF (TBF active and delayed phases are taken into account). An active PDCH with UL transfer is a PDCH carrying at least one UL TBF.
nb
These indicators are important for radio dimensioning
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 77/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
GPRS_PDCH_used_DL_TBF_GMM_signalling_time_ratio
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.
%
GPRS_DL_biased_and_DL_optimal_alloc_percent
Percentage of time during which downlink TBFs are granted the maximum number of PDCHs they support and the corresponding MSs are engaged in downlink-biased transfers. Reference: time during which MSs are engaged in downlink-biased transfers and served by DL TBFs.
%
GPRS_UL_biased_and_UL_optimal_alloc_percent
Percentage of time during which uplink TBFs are granted the maximum number of PDCHs they support and the corresponding MSs are engaged in uplink-biased transfers. Reference: time during which MSs are engaged in uplink-biased transfers and served by UL TBFs.
%
GPRS_BSC_high_load_percent Percentage of time during which the BSC is in high load situation in the cell. Reference: Granularity period
%
GPRS_MAX_PDCH_nb_avg
Maximum number of PDCHs that can be allocated in the cell. This indicator is consolidated in Day/Week/Month with the average of Hour/Day/Week values.
nb
This indicator is a function of the parameter Max_PDCH
GPRS_MIN_PDCH_nb_avg
Minimum number of PDCHs that can be preferentially allocated in the cell. This indicator is consolidated in Day/Week/Month with the average of Hour/Day/Week values.
nb
This indicator is a function of the parameter Min_PDCH
The pilled indicators are in restriction up to B9 MR4 ed6.
5.4 TRANSMISSION RESOURCES
The main indicators for transmission resource are impacted by Abis and Ater interface.
Table 33: Transmission Resources
RNO indicator Description Unit Comments
GPRS_transmission_GCH_busy_average Average number of GIC 16k busy (i.e. operational and used).
nb
GPRS_transmission_GCH_deficit_average Average number of GCH resources in deficit in the cell.
nb
Monitor the lack of transmission resources, Abis and Ater interface
GPRS_transmission_GCH_excess_average Average number of GCH resources in excess in the cell.
nb
GPRS_transmission_GCH_use_bonus_and_extra_average
Average number of extra and bonus Abis nibbles used in the cell.
nb
GPRS_transmission_GCH_use_bonus_and_extra_avg_max
Average number of extra and bonus Abis nibbles used in the cell. This indicator is consolidated in Day/Week/Month with the MAX value.
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.
5.5 RNO REPORTS
The RNO reports for (E)GPRS QoS follow up are presented below:
o 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
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 78/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
• 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
o 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
o 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
o 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
o 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
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
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 79/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted 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
o 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
5.6 END-USER STATISTICS
The majority of the EDGE analyses go through the end user tests and their results. Three indicators are
considered as the main ones for QoS follow-up, they are from FTP and Ping test:
o DL FTP Application Throughput
o UL FTP Application Throughput
o Ping Application time
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.
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 80/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
Table 34: Radio Conditions
Radio Conditions RxLev Mean_BEP
Good [-55 dBm, -65 dBm] [31, 25]
Normal [-65 dBm, -85 dBm] [25, 15]
Poor [-85 dBm, -100 dBm] [15, 0]
In the expected results is considered that no impact exist from the radio and transmission resources.
Table 35: Expected Application Throughput
Radio Conditions Expected DL Applic Throughput
per PDCH interval (kbit/s) Expected UL Applic Throughput
per PDCH interval (kbit/s)
Good 40.0 - 53.5 28.9 - 40.0
Normal 35.7 - 43.6 26.5 - 38.1
Poor 28.2 - 38.0 14.9 – 22.8
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 81/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
6 OPTIMISATION METHODS AND CONSTRAINTS
6.1 LOW DL THROUGHPUT OBSERVED
The main “complain”, during end-to-end tests, is the observation of low DL throughput at application layer
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.
6.1.1 END-TO-END ANALYSIS
In end-to-end analysis all parts of a network are analysed and their performance evaluated. The analysis
can be split in two, the impact of the radio layers and the impact of the upper layers (LLC layer up to
Application layer).
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.
Figure 6–1: Network Architecture.
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 82/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
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.
First step: Ethereal trace analysis
The Ethereal gives a global view of the transfer, the light investigation performs in this first step will give a
direction to a deeper analysis:
a) Pollution traffic
Check possible pollution traffic, e.g. packet traffic generated by windows update, anti-virus update, etc.
This extra traffic can have an impact in the end-user application throughput, by “stealing” bandwidth.
Check in the message transfer window the IP Source address and the IP destination address, it should be
only from your PC and from the FTP server.
If polluted traffic is observed, before repeating the test, remove all possible source of background packet
switch traffic. For example disable the windows update.
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):
Figure 6–2: Ethereal example - MSS.
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 83/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
o RWIN is recommended to be set to 64kBytes (64520 Bytes)
• Also this TCP parameter can be checked in the message layer.
Figure 6–3: Ethereal example - RWIN.
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.
Figure 6–4: Dr. TCP example – TCP parameters
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
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 84/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
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.
Figure 6–5: Ethereal example – Time/Sequence graphic 1
Figure 6–6: Ethereal example – Time/Sequence graphic 2
Expected slope with throughput = 200kbit/s
Good throughput with small perturbations
(high MCS with BLER ?)
throughput is decreasing (MS going towards the edge of the cell, and MCS are decreasing ?)
2-3 seconds hole, with TCP losses (radio drop and LLC-FLUSH due
to reselection ?)
Retransmission of lost data
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 85/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
o Upper layers impact, observed by TCP losses and retransmissions.
Figure 6–7: Ethereal example – Time/Sequence graphic 3
Figure 6–8: Ethereal example – Time/Sequence graphic 4
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 86/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
Second step: in-depth analysis
In this step the investigation can follow two different ways, analysis of possible radio impact and analysis of
upper layers impact.
a) For the radio impact the process is to analyse the traces collected in the air interface, for example using
Nitro. The key indicators to investigate are:
o Radio conditions, given by Rx Level, mean_BEP and CV_BEP, define the radio conditions during the
test.
o MCS distribution, typical cases:
• High usage of MCS3, normally associated to TBF_DL_INIT_MCS
o Block Error Rate, high BLER can be due to bad radio conditions or equipment problems.
o 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.
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.
3DF 01900 0000 PTZZA – DIAMS
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 87/96
All rights reserved. Passing on and copying of this document,
use and communication of its contents not perm
itted without
written authorization from Alcatel-Lucent.
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"
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.
Typical cases and solutions
a) BSS Network:
o Case: Less number of the DL PDCH allocated than the MS capability, due to the impact of load in
the cell
• Solution: Check cell configuration and radio dimensioning:
� Cell configuration and parameters such as:
• Number of TRX
• Number of TRA - EDGE capable
• Max_PDCH
• MAX_PDCH_High_Load
• Min_PDCH
• High_Traffic_Load_GPRS
� 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.
• Solution: Check BVC parameters
o Case: Lifetime parameter is changing during DL LLC PDU transfer in the Gb.
• Solution. With Ericsson SGSN
� Set PDU_Lifetime_Order to disable
o Case: Low throughput observed due to lack of transmission resources.
• Solution: Perform BSS architecture and dimensioning, see chapter 3.
b) GSS Network
o Case: Wrong QoS parameters in the HLR and/or in the client side:
ED 1 RELEASED 011
NE B9_EDGE_Optimisation_Guide_ed1.doc2007-06-29 3DF XXXX XXXX PTZZA 88/96
3DF 0
1900 0000 PTZZA – D
IAMS
All rig
hts re
served. P
assin
g on and copying of th
is document,
use and communicatio
n of its c
ontents n
ot p
erm
itted with
out
writte
n authoriz
atio
n fro
m Alcatel-L
ucent.
• 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).
• 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